Security Information and Event Management (SIEM) is a problem space that forms the core of detective controls in an enterprise network, and its importance is growing more and more because of its simplicity, scalability, and effectiveness.
With the emerging IT landscape, appropriate prevention controls need to be identified, architected and deployed, as opposed to deploying a SIEM solution where you just have to enable monitoring of the new technology or architecture and you are done.
The focus of this article is specifically on considerations that help with getting only the actionable events into the SIEM environment and eliminating all the noise. There is a lot of advice everywhere about having actionable events in your SIEM, but none that explains comprehensively how to go about it.
The basic principle is that every event comes with a cost to the SIEM environment, what you have to ensure is that the “benefit” of getting this event outweighs the cost.
Identify Log Source Types
Ok! So we have a SIEM solution and are wondering now what is the best course of action is to integrate various technology platforms and services reporting only “actionable” events. The first thing is to get an enterprise view of the technology platforms and services in your environment.
Let’s start with identifying the various log source types. The list below summarizes a typical enterprise’s log source types you may have. You also want to build the list of log sources for each log source type:
Traffic Types and their Specific Protocols
Now per log source type, lets pattern out all the traffic types that you may envision and would like to monitor, along with the associated protocols or activity that will be monitored.
Overlay this list with your enterprise network diagram to build a reference architecture for all the devices that you think will require monitoring. Below is one example:
Business Abuse Case Development
Now, that we have patterned out the log source types and traffic types, we want to build the specific use cases for each traffic type observed per log source that we would like to integrate with our SIEM.
For example, events that you may want from a firewall that is placed in a user internet traffic segment will be different from the events you may want to see for a firewall that is place between your business logic and data tier, the point being that your business abuse cases are very contextual to the environment in which they are anticipated to occur.
Remember you don’t have to all this at once, you can build your abuse cases as you kick-off the integration effort per each technology platform. The events that will help you to detect these abuse cases serve as the logging standard for this particular integration, so in essence you will have a logging standard per integrated technology platform.
Identify and be very picky in your noisy log source choices – for example, integrating DNS will not make sense unless you have a threat intelligence feed that you are going to correlate it with, or from your Active Directory which include the top 5 abuse cases you want to monitor.
Removing Redundancy of Events
Once you have the list of abuse cases, you want to review them in the context of your enterprise network. A network diagram of your enterprise will be very handy as you look at these abuse cases in their respective context.
Here you will either find that logging from one log source obviates the need to log from another log source OR you may be getting same events tied to a particular abuse case from two different log sources.
In this case you have to make a decision which log source would be more appropriate to integrate based on numerous factors – complexity of integration, log transport security etc. and from which log source you would filter redundant events.
Identifying Log Source Aggregators
Now that you know exactly what events you need from which log source types – you need to determine how to collect the logs from these sources. The goal you are trying to achieve here are: Scalability, Simplicity and Extensibility of your integration architecture.
For example, based on your business use cases you must determine that all the events you need from your end-point devices are collected through a third party client installed on each end-point, like an anti-virus or anti-malware software that has end-point traffic visibility.
In such cases, integrate SIEM with the server of the given end-point security software and you will receive all your needed events from one point instead of integrating each individual end-point and maintaining the thousands of transport channels per end-point.
This also eliminates the need to have a process that needs to track the addition of new end-points in your enterprise. Similarly, you may not want to integrate each and every web application you may have in your enterprise, but instead get the events from a web app firewall or a web authentication service, etc.
Filtering of Un-Needed Events
At this point you know exactly which log sources you want to integrate with your SIEM service, and what specific events you need from the integrated log sources, so the result that comes out of all this is – how to filter events that you do not need, since that was the original point we went down this path, that of getting only Actionable events.
Here are four points of filtering log events for your SIEM solution, in the order of preference:
- Filtering of the event at the source
- Filtering of the events at the collection tier, before normalization
- Filtering the events at the collection/aggregation tier, after normalization
- Filtering the events in your correlation tiers
Event Aggregation is Necessary
Now that you have trimmed down all the events that make it to the SIEM infrastructure, you will want to see the relevancy of the events in their unitary form. Some events individually warrant action and there are other kind of events which would be actionable only when they are occurring a certain number of times.
This is where aggregation of events becomes super important. In order to put an aggregation on a certain security event type, you have to review your abuse case and validate if it would actually be detected based on number of events or a single event.
For example, one event with user authentication failure will not make sense, however if you have multiple user authentication failures from the same source IP address or from various user accounts, you may be encountering a brute force attack from a specific malicious source.
Prioritization of Technology Platforms Integration
Considering the amount of the technical platforms and services you may have in the enterprise and the emerging IT space, you may never be done with the engineering effort for integration with SIEM.
Further, you cannot integrate all technology platforms or services at one time, so in order to cover your enterprise technical space reasonably for monitoring, you may be looking at 2-4 years of integration engineering work depending on the resources and the maturity of the processes you defined originally.
Since you cannot integrate everything at once to your SIEM – you have to prioritize and build an integration roadmap for 1-4 years. The prioritization process should obviously be based on so factors that are based on:
- Compliance and mandates: Any technology platforms or services that require monitoring as mandated by any legal or regulatory directive should automatically be integrated first.
- Business Enablement: This factor may include scenarios where your business client will only do business with your enterprise if their application/service/system processing of their data is being monitored.
- Business Importance: You should be monitoring your systems and services that are the crown jewels of your organization in order to minimize damage.
- Security Threat Space: This is the interesting one and little bit more involved. We will discuss this in detail in the next section.
Once you have ensured only actionable events make it to the SIEM environment, your next primary task is to do a continuous optimization of your correlation rules, performance tuning of received events and also prioritize your list of systems and services for SIEM integration.
There are multiple methods to achieve that, above is one with a threat-focused perspective. This method allows agility with the changing threat landscape that is relevant to your enterprise above and beyond the regular event monitoring.
So next time some vendor comes and asks your CISO, “What are you doing for this new ‘buzzword’ attack?” you have already helped them with an answer.
About the Author: Kapil Assudani (@kapslock) has more than 11 years of experience in multiple security roles as a “Breaker” and “Builder”. After starting his career in network and application penetrating testing for fortune 100 clients as a breaker, Kapil moved onto the builder”side of Information Security, and has since provided consulting on technical architecture lock-downs, building enterprise security solutions like SIEM, PKI, and Web Authentication/Authorization, etc. Kapil has extensive experience in designing and executing information security risk management technical control frameworks, enterprise security architecture and strategy. Currently Kapil is leading the “Technical Security Services” Risk Management Program at one of the country’s largest private health insurers in a Senior Manager role, and is responsible for the execution of a $30 million dollar security capability roadmap.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
- Cyber Security Solutions for the DoD and Intelligence Community
- Advanced Log Intelligence Enables Faster Breach Detection
- Why SIEM Alone is Not Enough
- 20 Critical Security Controls: Control 14 – Maintenance, Monitoring, and Analysis of Audit Logs
P.S. Have you met John Powers, supernatural CISO?
Title image courtesy of ShutterStock