SIEM Optimization Strategies

Hello. My name is Robert Meyers. I am the Channel Solutions Architect for One Identity, and I am also a privacy professional. Today, we're going to talk about SIEM optimization strategies. So a security information and event management system are products that are used to combine security information and security events correlated in real time, and help you deal with events that occur. It's very simple, it's very important, and a cornerstone of security today. So let's talk about how they actually work. They collect logs so that they can analyze events. So logs are a little piece of data that's stored for identification of events. The problem is that you start collecting lots of information, and every time you use one you're building up costs. And there are a lot of compliance issues there, because certain bits of data should not be in a publicly accessible or even a restricted access environment. And you're creating leaks of data, literally huge data leaks like you would use for big data, to ingest and create this analyzation. So there's a lot of problems with the way a SIEM works. But at the same time, you really need to be able to control what's happening. So it's not an almost there, it's a necessity today. When you're talking about this though, think about what's changed in recent days. So the world changed. We all went to work from home as being a new normal. SaaS is currently the standard. IaaS is currently standard. But this has all been additive. Build more, add more. And what that means is there are more logs. Constantly more and more things logging information. And they're coming from everywhere. So you when you're dealing with SIEMs, you have to have a strategy. Now, I brought these into three different categories. There's the basic SIEM, which is the one we normally talk about. A compliance safe SIEM. It's a new concept for a lot of people, but it's really important in today's world. And then there's the data highway. The key here is to use the configuration that your company needs. So in order to help you do that, I broke them into phases. So phase one, that's where we start. And remember, everything here is phase or iterative. It involves both. Now we've got compliance safe SIEM, that's your phase two. And lastly we have the data highway. That data highway is the next generation. So in phase one, we're really talking about identifying relevant logs, finding your shortfalls, expanding your log sources. The more logs, the more effective a SIEM is. Always remember that. And then you have to constantly review and expand what you're collecting. So what kind of logs you really need to collect. Well, you've got security logs. Here's a few examples. Your IDS, your antivirus. Really the things that you think of when you start talking about security. These are really relevant, and you really need to keep them identified and growing. You bring in more things, they have to be brought in. At the same time, the networking tools. The most common thing I see that people ignore are things like IPAM. That thing that tells you what IP address you have. Your DNS systems. They need to be in there also. And of course, you always have to have your infrastructure. So if you look there, as we're floating through here we're seeing all types of server types. Then applications that you need to be collecting logs. Yes, you need your logs from Office 365. And then you move on to phases. You're now in phase two. Start thinking about compliance. So the key to compliance is that you have to redact information prior to it going into a SIEM. Now you may still need to have a copy of unredacted logs. This causes a problem. And that's where you end up looking at outside tools than the SIEM. But all that data has to have a lifecycle. If you don't have a lifecycle, you can never be compliant. And you have to constantly be looking at how the laws and regulations are changing. If you do not, they will catch you and you will not be prepared. So think about how important are regulations. Pretty important. Have you ever had a HITECH? It's a layer on top HIPAA. It actually directly requires logging, but most of us don't really think about that because, well, I have my SIEM. A SIEM is not a log collector. It is not just all your logs. It's meant for security. So think about all the different ways you can deal with regulations. And these regulations and compliance requirements are pretty large. I mean you look here, you've got your PCI requirements, your California Consumer Privacy Act, your FCC regulations, which is pretty huge, by the way. HIPAA. LGPD, which is in Brazil. You've got GDPR. PIPEDA in Canada. FERPA, thinking about education. And of course all those tons of banking laws. They are a huge amount of regulation, and you don't have a choice but to be compliant. It's not worth fighting. You have to figure out a way to do it. And this is where making a compliance safe SIEM is important. But there's always phase three. Phase three is something else. It's a little bit more forward thinking. The idea is you replace all your collectors. All those logging tools that you have for different applications. You use one. You centralize all that data into one pass through one data highway. And you send the relevant data, and just the relevant data, to each of those targets. For example, am I sending to Splunk? Yes. Am I sending to Elastic, maybe the Elk Stack? Yes. What are the others, could it be the Azure data link? Send what you need. And you know what, use not just the forwarder that's going in installing an application to forward. A lot of applications have syslog-ng, rsyslog, or even Windows has an old event forwarder. Use them. These are in embedded systems, they're in mainframes, devices. And sometimes, you'll have data that just goes in and has to be made compliant. Now, to make this really work, I mentioned before a little bit, you need centralized log management. And the key to that is our product syslog-ng. It's the granddaddy of syslogs. It actually uses the term of course, but it is the granddaddy of centralized log management. So when you think about log management, what do you really think about? Well, you talk about managing volume, right. We are trying to build up our volume, but not overwhelm services. So it's got to be usable. And that's where velocity comes in. We have to have normalization. That means giving the right bits of data. Parsing out, transforming, that type of thing. And giving just the right data to the right target. And just remember, this centralized log management, the CLM, and does not equal a SIEM. Instead, it's really set up to collect logs, which are events recorded by piece of software. A syslog is quite often referred when people are talking about our application, the format, or even the protocol. But syslog-ng is the most widely adopted log management solution, by far. It's for taking normal data and making it useful. Makes it information. This is an example of pouring in into our store box, which is our syslog-ng with a GUI. But it can go to Splunk, it can go to QRadar, ArcSight, Sentinel, Azure, wherever it needs to go. It could be going to puppet tasking and kicking off a service. But what's the real impact of having a CLM with the SIEM? Well, I had the opportunity to sit with a customer. They implemented it for their retail chain. And they showed me what they had. Now, I have to go back in my head, and go, well, what do logs really hold? My last look through on a Windows machine showed about 22% of the data was useful for security. There was a little bit in this case, about 3% of restricted data things with things that should not be shared. And then a plethora of non-security information. You got to remember, IP addresses in some locales are actually considered PII. And you strip all that unnecessary stuff out to send to the SIEM, and it changes the game. That client went from 600 gigs a day to Splunk, to 200 gigs a day. But by creating a data highway, they expanded the collection from 600 gigs to a terabyte a day. So all of a sudden they're getting more, and they're just starting out. Look at these targets they sent to. These are the 12 that were done. Note, they've got three that are planned. MongoDB, SQL, Python, Stackdriver. I'm sorry, it wasn't three, it was four. They're going to be the 16 targets. This is a real company doing real work. And this is how they came into it. But remember, targets and sources can quite often be one or the other, or both. Anything that outputs logs, that inputs logs, that can be parsed or transformed into a log, anything that can be written to a text file can be turned into a log. And that means you can build stories around it with your company. Do you want to integrate it into Puppet. Do you want to implement it integrating in it with some other systems management tool? So they took their SIEM and they added syslog-ng PE in store box. And what did they get? They went from basic SIEM, which gives you that expanded visibility and control when you throw it in sys-log. Then they go to compliance and start doing that transformation and parsing. And then they remove the other collectors and made their real data highway. And that's when you have simplified management at a lower cost. Note the plus. Every step of the way you're gaining on what it does. You're gaining on everything you're doing. So what does it take to really do this? What is syslog-ng? Well, that's where we're going to go here. But just look at this and understand, this is the picture you need in your head. So the syslog-ng is our centralized log management system. We started out in the open source world. The open source world gave us syslog-ng OSE. That's supported by the community. There is a huge amount of data out there. You will find information on it being used all around the world. It is the number one log management solution. And then we created a Professional Edition, otherwise known as Premium. So Premium Edition added in 0 message loss, secure storage, one identity professional support, executables, and Windows support. Then we tacked on the next layer, which is syslog-ng Store Box. Store Box is a GUI centric version of syslog with true controls. So let's talk a little bit about that, because this twists the story a little bit. Most log management solutions don't deal with GUIs. They just deal with data. Now, take a look at this. Understand what the components are. OK, syslog-ng Store Box. syslog-ng Store Box is the cornerstone for business compliance. It takes syslog-ng, gives it a GUI. Easy to use. Discrete and capable policies, access controls. I can give a user or group give finite controls. Be compliant happy. And I use syslog-ng Premium Edition for relays. It keeps things simple. And you have the graphical impact here that you get from a log. So the thing of it is here, you can use it beyond just the black screen. You've got a turnkey solution. Where you're doing 1,000 logs a second sustained, that tells you something's impressive. You've got your integration with LDAP, with Radius. Just remember, AD is an LDAP. Your archiving capabilities are huge. And of course, like all of our other products, they have an API. So think about how much this could change things. Remember, operations can use that, too. But it leads us back to syslog-ng Premium. Premium Edition is the cornerstone, because it can be ran in three ways. As a client, as a relay, and as a server. Same application. But the key here is that you choose which component and how it's used to send the data to where it needs to go. Now thinking about this, how does that really look? Getting that data. Well, you have things that you go create data. Then you forward it to a relay. The screen is showing it now, look at that. All the way, left to right, I don't really care if we flip it around and make it right to left, but it would work. You choose your destination. I see Elastic search. I see a Sentinel. I see Puppet. I see SQL. I see Splunk. I see whatever you define. Parse it, classify it, normalize it, filter the right information to the right target. Sounds like identity management. You're getting the right information to the right resource at the right time in the right way. That's simple, right? Maybe I said too many rights, there. But remember, it can be routed from anywhere in the world. You can be grabbing data from the Cloud, from network devices, on storage devices. Old legacy syslog servers. Possibly syslog-ng servers. Forward them out. Get them to the right target. You can do this, it's really simple, because you can have data come from anywhere. Hit the relay or use a client and go lossless. When you use that RLTP, you're talking about something that guarantees delivery. Here we've got an example where we're getting data from Denver, you're getting data from Dallas, and you're getting data from AWS. Doesn't matter if you're going to syslog-ng PE or Store Box, get the data in. And now, the number one thing we talk about is Splunk today. OK, with Splunk they have a new concept. It's called the ATTP event collector. Everybody just calls it HEC. We support Splunk HEC with PE today. Not tomorrow, not down the road, we do it right now. Because we really are meant to take a product from anywhere, convert it into data, turn it into a log, and reliably deliver it. In fact, we created two protocols, RLTP and ALTP, simply to guarantee delivery of logs. Because if you miss a log, and that was a breach of your security, it's a disaster. So RLTP is reliable log transfer protocol. ALTP, advanced log transfer protocol. But we have to deal with Windows as well. This is something a lot of log software does not do. You're either all Windows, or you're all Linux. We're not, we do both. We have an option for Windows Agent. You can install it directly. You can configure it via GPO. We can make a script, use XML. Simple, deploy it quickly. But it's a very functional agent. But an agent's only one option. I wonder what the agent looks like. Have any you ever installed a logging agent on a Windows server? It's got to have flexibility, and this one does. See that little Add button? Add stuff, you can. You can configure things. You can add additional logs. It's all built in. Note event sources, foul sources, destinations. I can send it once this log server, I can send in multiple, I can do what I need to do to get the data there. But we keep it simple. And that's key. This looks like every other agent you're going to run into with Windows. And that's a huge deal, because it's hard to train staff to something absolutely new. Just look at how simple these are. They're straightforward. But you know what? As straightforward as these are, they're not the only option. There's also the Windows Event Collector. So this is something in Windows where you forward out information through subscriptions. Now, quite often you do this inside Windows environments to another Windows server. But in this case, we're sending to a syslog-ng server, so that we can create our data highway and stop having this segregation. Get things into Splunk, get things into Sentinel. So in this case, when you look at it, how it's grabbing it. It's getting the Windows source event, it's parsed. We keep the pieces that we need, we send the right pieces across. But the number one thing I want you to think about on this is, it's 100% native functionality. This is not something we created for subscriptions. This was already there. There's certificate based security already available for this. And it's easy. Your engineers have probably already created a subscription at some point in the past to another server. Well now, we just direct it into our syslog-ng, and we have control. We use this syslog-ng to collect it, and we forward it to a SIEM. Because in the end, what's key here? syslog-ng plus SIEM gives you basic SIEM to compliance safe SIEM to the data highway. And that's really what you need to remember. Thank you for joining me for this session. Once again, my name is Robert Meyers. I hope you enjoy the remainder of your night.