“Log Management”, “SIEM”, “Correlation”, “Incident Management”, more and more organizations have a SIEM project in the pipe. SIEM means “Security Incident & Event Management“. Just to remind you, a SIEM is a set of tools which helps to collect and analyze logs from several sources on a corporate network. Basic functions of a SIEM are:
- Event collection;
- Normalization;
- Indexation;
- Analyze.
There are two ways to jump into the SIEM world: Some organizations are forced to deploy a SIEM solution to reach compliance requirements and others are starting a project in a due diligence and due care way.
At the moment, I’m involved in several SIEM projects (starting from pre-sales, proof-of-concept and real deployment) and I’m always a bit afraid of what customers will ask to me or what they expect from their SIEM solution. First of all, a SIEM is not a simply tool deployed on a network. It will not “automagically” work out-of-the-box. a SIEM is a project. I always split the project into three major phases:
- Collecting the events
- Analyze the events (getting their real value)
- Maintenance
The first phase (“collection”) is almost the same in all projects. It is sub-divided in several major steps like:
- Define which events must be collected and from which devices.
- Design the architecture to collect events in the best way to keep a good balance between security and performance.
- Deploy the SIEM components (agents, collectors, storage, etc)
About the event collection, let me insist in an important point. To reduce storage requirements, some filters may be defined to keep only relevant information. Always keep in mind that an event received at time “x” may seem worthless but may be really valuable in the future when you’ll have to investigate a security incident at time “x+y”.
The above steps are independent of the chosen SIEM solution. It is definitively not my goal to promote one solution or another one here. If you’d like to discuss about specific tools, contact me.
Now that your SIEM is up’n’running and collecting a lot of events from your infrastructure, it’s time to get the real value of them. Like any tool, a SIEM must be used in the right way. You won’t use a hammer to remove a screw! Things will become more complicated. If your organization implemented a SIEM solution in a pure compliance way, all SIEM vendors provide out-of-the-box “packages” to generate alerts and reports based on the compliance requirements. All standards like PCI-DSS, SOX, HIPAA and all their friends are supported.
Along with compliance needs, things will become more complicated for the consultant. He must carefully listen to the customer and analyze the organization business to help them to extract the right value from the (huge!) amount of collected data. Another consultant’s goal is to train the customer how to use his brand new toolbox. It is impossible to replace the customer. He can at most help to use the tool in the best way. All implementation differ starting from the second step of the project.
A few words about “correlation”. Do you really need it? In a SIEM context, correlation rules triggers actions (alerts, scripts, etc) based on the way events generated by one or more devices occurred in a specific order with or without time constraints. Correlation is a complex process and the rules definition may require a lot of time (definition, test, debugging). Before deploying correlation rules, you must be assured of the quality of the collected events. Often log management tools already propose powerful alerting features and correlation is not mandatory but may help the organization which is facing a precise operational issue.
Finally, the last step is to define all the mandatory procedures to keep the SIEM environment update and powerful:
- Incident management procedures: how to process alerts generated by the SIEM.
- Change management procedures: configuration of new devices and applications to send events to the SIEM and decommissioning of all old components.
- Assets management procedures: plus-value can be added on events by running vulnerability scanners or linking to an online vulnerability database.
Conclusion: Before implementing a SIEM, you must have clearly identified needs! Define a scope and stick to it during the whole project. The “KISS” principle (“Keep It Simple and Stupid“) is a golden rule! Collect events from a limited number of devices (ex: a public DMZ). The deployment will be a success if the SIEM is able to improve your daily operations: Reduction of time required to investigate incidents or immediate notification in case of suspicious activity. Even if a SIEM is a based on highly technical tools, it remains a business tool. Its ROI (“Return On Investment“) must be proven to the management.