After more than 5 years working in SIEM projects, I've decided to move into the GRC space. In this last post, I'd like to summarized the most important lesson I've learned during my SIEM journey.
During this time I've been able to see from a first row seat the evolution from purely compliance-driven projects to more security focused initiatives. Despite compliance/regulations/internal revisions still are the most common driver here in Norway, more and more organizations understand that log management is necessary as underlying technology to be able to dig into all the information is generated in the different systems.
Many organizations have taken a step forward in their strategy and start to see at SIEM as the tool to support and centralize the company's security monitoring efforts.
There are 3 critical factors I've consistently seen affecting the outcome of SIEM initiatives:
1. Understand the components. SIEM is very different from other security technologies where the product is the key. Here three components needs to collaborate together:
- PEOPLE. The first component to understand is who is going to use the solution. What are their needs, what this technology can do for helping them?
- PROCESSES. The second factor is define how this technology is going to be used. How is going to be handle a high level incident? And a monthly report?
- TECHNOLOGY. The last component is the technology used. It's critical that it enable the user to let their imagination run wild instead of been the limitation of what it can be done. And this lead directly to the next factor.
2. Top down initiatives works best. The most successful projects I've seen have taken an approach where they started defining the use cases instead of just defining the project in terms of integrate thousand of systems without a clear idea why they are needed or what they will be used for. Down-to-top approach is complex and has a bigger cost than top-to-down which produces a much faster return of investment.
Top-down approach can be seen a sequential process where you start from the logical use case definition. It's as "high level" scenario where involved critical assets are identified. Over these critical assets a set of controls are defined. These are the control that need to be monitored. Then an incident response procedure is defined for resolving the incident and mitigate the associate risk if possible. This approach makes also easy to identify the last critical factor.
3. Logs contain enough information. It seems obvious, but sometime the information available is just not enough. Most of the times, the controls we defined have their specific set of information that can be provided. Be sure that the information you can get is enough to solve your use case or at least identify it as soon as possible to find an alternate workaround.
With these three pieces in place, your chances of having a successful SIEM project are maximal.
But remember that SIEM projects should be in continuous evolution. Not only to unsure that the use cases previously defined continue being relevant, but also because new use cases will appear to respond to the changing threat landscape.
But remember that SIEM projects should be in continuous evolution. Not only to unsure that the use cases previously defined continue being relevant, but also because new use cases will appear to respond to the changing threat landscape.
Good luck!
Thanks for been following this blog. From now on I will continue writing on mnemonic's web site blog.
See you soon,
/Alonso
