In Paul’s previous post, Is the Next Generation of Security Monitoring Around the Corner?  , he highlighted that “poor implementation” is one of the core issues with SEM implementation.  With my IDS Analysis background, I approach projects from the perspective of, “How can I augment my analysis with more valuable information (aka: make my life easier ☺)?” 

The purpose of this article is to provide some practical advice on some of the event source requirements, while implementing a SIM from an analytical perspective.  I understand that this approach is not always possible, given the available team/resources/budget, but some of the lessons learnt and recommendations can still be applied.

A SEM is meant to enhance the monitoring capabilities by providing correlation, filtering, aggregation, and a central normalized repository to analyze collected events.  But as Raffy highlighted in his blog, there may be several difficult obstacles to overcome during an implementation.  To augment the core features of a SEM product, and the issues Raffy illustrates, you need to validate the value of and state of the event sources that you want to use.  This greatly determines whether you will be successful in leveraging a SIM to enhance your security.  Maintaining and tuning are two essential ongoing tasks that need to be planned for and executed on an ongoing basis.

“Integrating Your Event Sources”
I have found that a successful strategy for implementing a SIM is to analyze the proposed event sources during the initial testing phase and/or during the first phase.  Analyzing the source data provides a foundation that delivers the information needed to create a valid correlation scenario while using meaningful, valid data.  Just having the right event sources reporting to your SEM is not enough; these reporting devices, in my opinion, need to be tuned for each monitored environment and/or end-point.

This model can generally be applied to most IDS monitoring devices, as well as many other security centric reporting devices.  For example, a single network based IDS device could be monitoring several low bandwidth segments.  It is important that you determine the services, servers, software, etc for each asset within each segment.  Your policy will then reflect what should be monitored.  You might, for example, discover that a particular network segment only has Windows Servers, only running only terminal services.  Based on this information, you will make a better determination on what signatures to apply/disable/modify for that policy.  Taking the time to the analyze and breakdown the services within your devices will make life easier during the process of incorporating this into the SEM, reducing the number of false alerts and really letting you know what should be happening in your environment.  The old axiom “garbage in, garbage out” applies here.  If you do not take the time to remove the “garbage data” from the event source feeds into the SIM, it will produce more events that will undermine the value as you are now chasing non-events down.

What to Monitor
Now placement comes into play.  What are your business needs?  Where are your business risks?  What do want to see?  Could a customer segment attack you?  The business issues and balancing act of what you want from top monitoring has to be taken into account during the tuning and design process and before the SEM implementation.  I am well aware that some tuning/filtering is not possible for certain event types/groups from certain devices.  In these cases, you should leverage the tuning and/or aggregation features of your SEM.

Take for example, an IDS implementation.  There is a lot of temptation to use a SEM device as a tuning tool, but that is the wrong approach.  You will still be throwing a lot of data that you do not necessarily see on the SIM console and that will generate too many false-positives.  In addition, you will STILL have to filter a large amount of “noise” out within the SIM, and still face the possibility of overload with the SIM solution (and your people).  This is just an example for IDS devices.  What about vulnerability scanning?  Do you investigate the reported issues manually to determine validity before importing?  Time should be taken to analyze and tune the data sources for the SIM so that the right alert with the right data is sent.  It should be as detailed, relevant, and accurate as possible.

To be successful, you have to know, before starting the implementation of a SIM, what you want to see from a big picture perspective.  You should also have your devices properly tuned to continue the process of adding value to your analytical capabilities via a SEM device.  The planning phase needs to incorporate choosing the right event sources based on what you want to accomplish, as well as the task of tuning them as much as possible as to provide useful alert data.

Complexity of modeling environment
In my humble opinion, creating a valid IT infrastructure model is the one of the critical tasks and success factors when establishing a SIM.  It can definitely be a daunting task, but I have seen it done right and it definitely makes an extremely significant difference.  A detailed network model will augment correlation and possibly affect various criteria of an event.  A thorough network model does not just consist of your IT IP-ranges (segments, zones, etc…).  It should also contain valid asset information within those ranges about the devices and systems contained within.  This will provide other criteria to be evaluated during the correlation process and will minimize reporting time as it’s incorporated and leveraged with your security program.  Many organizations do not succeed in maintaining an up-to-date network diagram.  The initial view is created, but then they fail to maintain it.  The value of this type of information should not be underestimated.  From understanding risk to responding to an incident, having this information is the “grease” on the rails of response and protection procedures.

False Positives in Correlation rules

Unfortunately you can’t have one without the other and provide meaningful output to the console. Correlation rules are canned/generic enough to attempt to work in most environments. The vendor can’t possibly know your business needs, resources, reporting capabilities, etc.. Understanding what is evaluated during the correlation process will help you in deciding what to change, incorporate, disable, etc… You have to provide this information so that the required criteria for correlation are present. Initially there will be false-positives provided by the correlation engine, although this should not drive the need to “get rid of X correlated events”. This is the wrong approach to tuning your correlation rules. How about “how can I correlate *current* event sources implemented to augment analysis?” Knowing the limitations of your reporting devices can jump start the thoughts on how can you correlate an alert that has no meaningful data (alone) with other supplied event sources to add value to this alert.  Keep in the mind your tuning and policies as these might need to be re-visited as your correlation requirements change. 

Closing Thoughts
These are some of the critical requirements that, in my opinion, need to be addressed to properly tackle correlation.  Properly tuned event sources will provide your SIM with accurate up-to-date event data that can be better tied with the network model.  This needs to be augmented with asset information.  Just knowing the name of the target zone, without understanding what is running inside of it, can result in still having to search for more information.  To be effective, responsive, and successful, you cannot afford to ignore these requirements.