When you look at deploying a SIEM, there are really a couple of things that you want to consider, and that is compliance. There are some mandates that you need to measure against things like GDPR or many regulations in the United States like HIPAA, the Health Information Portability and Privacy Act, PCI which is what credit card processors measure against. There are all kinds of regulations and compliance metrics that need to be measured against and a SIEM can help do that. There's also a cost-benefit analysis of course. Anytime you invest in a new technology, what is the benefit you're getting? What business value does it provide to the business? Then of course, the cybersecurity aspect. As technology becomes more prevalent in our lives, there are more bad actors that can try to cause issues within the environment for monetary gain or foreign affair other nefarious purposes. Cybersecurity is also an important consideration. We want to protect the data within our environment obviously. I'm going to give you a brief example of a QRadar deployment. This is really very similar for any SIEM. Whether the IBMs, QRadar or any of the other SIEMs on the market. When you look at the deployment scenario, what you will typically have is flows coming in from a network source like a span or tap or a router, and that gets translated into what we call QFlow which is the format that QRadar can read and then that's sent to a flow processor. These can all be either hardware appliances or they can be software. Then that is brought into the console for the SOC analysts to look at. The event and log sources are done exactly the same way. They go to an event collector and then event processor and into the console. In smaller environments, all of these appliances can be a single appliance. A small implementation may only have one appliance that is doing the work of all the things that you see here. Let's go into a little bit more detail about the event collector and the event processor. The event collector collects the events from local and remote log sources and normalizes that log source events to a format that QRadar can read. Now, the event collector is really used in remote locations. If you have multiple locations or multiple data centers, you may have an event collector in each of those data centers that feeds in on event processor, and the event processor processes those event as its name implies, that come from one or more event collectors. Then those events are processed using what we call a custom rules engine, rules or how we determine if behavior is anomalous essentially. The event is processed, it goes through the custom rules engine, someone sees, "Oh yeah, this is behavior that doesn't look right. So we're going to flag it as an off funds." That's what happens on the event processor. Flows are done in a similar fashion. The flow collector collect slow data from packets and those are collected from monitored reports like a span or a tap or sessions like that. Then, they can also be collected from sources like netflow or sflow or jflow. Then it is converted into the QRadar format which is QFlow, and then it's sent to the event flow processor for processing. As with an event collector a flow collector would be put in a remote data center. You might have multiple flow collectors depending on your data center architecture. You may have a data center in one city and another one in another city. So you could put event in flow collectors in each of those data centers to then feed into a flow processor in your main data center. It's depends on how large the organization is? How many sources they have and their geographic distribution, when we look at sizing a SIEM. The flow processor then duplicate those flows if those sources are coming into a different flow collectors but it's the same source. The flow process will dedupe that. Then it will do things like asymmetric recombination which is combining the two sides of the flow when the data is provided asymmetrically. It recognizes flows from each subside and then combine them in to one record. However, you may not always get both sides of the flow. You may only get that I went out to a specific network host and not the information from back in. But when you get it from both, we can recognize those two different flows and combine them into one. There may be some reasons why you want to. We talked earlier about an all-in-one deployment, which is a single appliance that would be used for in this case, QRadar deployments. So if your data collection requirements exceed the collection capability of your all-in-one compliance? Excuse me, all-in-one appliance. If you want to collect events and flows from different locations and you're not getting good throughput to the directly to the all-in-one appliance. If you're monitoring packet-based flow sources, you might want to add a flow collector. As your deployment grows, your workload may in fact exceed what you can do with an all-in-one appliance. So those are factors to consider as well as the search speed. So if you have more analyst and then can do concurrent searches that the all-in-one appliance can handle, that would lead one to a more distributed architecture as opposed to doing everything on a single appliance, as well as things like retention period. Many organizations have a mandate for how long they need to retain this data. So if the storage requirements for your data retention periods get too large for a single appliance, that may require a deployment of multiple appliances. As your team grows, you might require better search performance. So those are all things that will lead to moving from a single appliance to a multi appliance deployment. Here's what we talk about the SIEM and how it fits into the concept of a security operation center or SOC. So the security operations really as you would expect is the people, the process, and the technology. Of course the SIEM fits into the technology piece. So that would be things like other things in the technology piece endpoints your flow, your network monitoring, any Internet forensics you're going to do, and threat InteI. Then of course the people are probably the most important component of the SOC because they are really what takes the data that the SIEM is providing and provides intelligence around that to determine if an event or offense need to be investigated with more detail. So your formal training, your internal training. Of course on the job experience, nothing can compete with that. If you have vendor-specific training for the tools that you leverage within the environment. Then the process that goes into your SOCs. So what is the process for what you do when an event turns into an offense and when that offense needs to be investigated, and it really is a close loop thing, from preparation to identification. How do we contain it, get rid of it, recover from it, and then lessons learned. That goes back into the preparation steps. So the process is a very important part of the SOC component as well. Here's how we talk about SOC Data Collection for improved incident handling. So we want to talk about the visibility because we're centralizing all those data sources into a SIEM or security monitoring system. Then by getting all the information from things like network traffic, your system logs, your endpoint data, your external threat Intel feeds and your events all go into the SIEM. We want to make sure that everything that we have in the environment is visible. So we really want to feed as many data sources as we can into the SIEM so that we have visibility across the entire environment. Obviously, there are things like licensing considerations and budget and those things that will dictate how many sources we can bring into the SIEM. But when we have determined all of the sources that we want to bring into our SIEM, we look at the monitoring system or the SIEM for the analysis. We want the SIEM to provide as much data, and as much intelligence around that as possible, so that when the security analyst actually analyzes it, they're filtering out all the noise and really only looking at the things that should be and need to be investigated and then the action around that. So once we have our findings and we determine what the correct investigation processes and then what the correct remediation processes, whether it be patching, modifying the firewall rules, quarantining a system to do further investigation or even potential re-imaging the action is what you're going to do to take care of the issue that was found during the analysis and the investigation. So I hope over the last few minutes we've given you some introduction to what a SIEM is and what it can do to help protect the environment.
