Implementing SIEM
While assessing my infrastructure, I came to the conclusion that it is time to start making work of a few things:
Anyone familiar with the field will see that this a textbook use case to start looking for a log management solution, an event management solution, or maybe even a full SIEM.
Since I have done SIEM projects in a previous job, I was a little reluctant to start a new one. SIEM projects typically involve many operational groups, which makes them complicated to execute, and the SIEM market is generally on the pricey side. Adding a SIEM will also add a layer of complexity, if done wrong.
However, after some consideration, I decided that it was time to do start a new project. In order to avoid wasting my time, I built several go/no-go decisions into my expected timeline.
Like many IT projects, a SIEM project is not something that can be rushed. From the point of project initiation, I decided to take 1 year to go through the process of research, budget acquisition, requirements formulation, scoping, vendor presentations, contract negotiations, etc. to the point where a product has been purchased and implementation could start.
Twelve months is a long time, but it is necessary to take the time and to do it right. Once you commit to a SIEM product, you had better take it serious, or else it will fail.
While I am now at about 3/4 of my project, and my potential vendor list has been narrowed down quite a bit, I have not yet made a final selection about which product/vendor to select, if I select one at all.
After an overdose of sales rep speak ("single glass pane", "drill down", "30 thousand feet overview", "customizable dashboard", etc.), I can say that most products that I have reviewed have made some nice progress since I looked at them 5 years ago. Interesting to see is that, while I followed the same evaluation process back then, the outcome is completely different this year. That difference can be explained by a combination of market movements, a different workplace, SIEM technologies maturing, and a better understanding on the implications of doing something like this on my part.
The SIEM market seems to be developing nicely, and is slowly reaching a level of maturity.
It seems that I am not the only one thinking about these things lately. The guys over at Securosis have been posting a nice series of posts on SIEM selection, as has Rocky DeStefano over at Security Operations by Visible Risk. In the midst of this, Andrew Hay takes a job at the 451 Group as the Senior Analyst primarily responsible for the SIEM, Log Management, GRC, Forensics, Vulnerability Analysis, and Penetration Testing portfolios; the Gartner Group decided to release is 2010 magic quadrant for Security Information and Event Management; and LogLogic announced that they are cutting their pricing in an attempt to push the market towards a more cost effective solution for SEM/SIEM.
We live in interesting times.
- increasing operational efficiency by selective and targeted automation of log review, thereby freeing up valuable human resources to work on more interesting projects;
- increasing (near) real-time situational awareness of my infrastructure;
- increasing the ability to conduct log-based forensics;
- increased scrutiny and enforcement of log retention policies.
Anyone familiar with the field will see that this a textbook use case to start looking for a log management solution, an event management solution, or maybe even a full SIEM.
Since I have done SIEM projects in a previous job, I was a little reluctant to start a new one. SIEM projects typically involve many operational groups, which makes them complicated to execute, and the SIEM market is generally on the pricey side. Adding a SIEM will also add a layer of complexity, if done wrong.
However, after some consideration, I decided that it was time to do start a new project. In order to avoid wasting my time, I built several go/no-go decisions into my expected timeline.
Like many IT projects, a SIEM project is not something that can be rushed. From the point of project initiation, I decided to take 1 year to go through the process of research, budget acquisition, requirements formulation, scoping, vendor presentations, contract negotiations, etc. to the point where a product has been purchased and implementation could start.
Twelve months is a long time, but it is necessary to take the time and to do it right. Once you commit to a SIEM product, you had better take it serious, or else it will fail.
While I am now at about 3/4 of my project, and my potential vendor list has been narrowed down quite a bit, I have not yet made a final selection about which product/vendor to select, if I select one at all.
After an overdose of sales rep speak ("single glass pane", "drill down", "30 thousand feet overview", "customizable dashboard", etc.), I can say that most products that I have reviewed have made some nice progress since I looked at them 5 years ago. Interesting to see is that, while I followed the same evaluation process back then, the outcome is completely different this year. That difference can be explained by a combination of market movements, a different workplace, SIEM technologies maturing, and a better understanding on the implications of doing something like this on my part.
The SIEM market seems to be developing nicely, and is slowly reaching a level of maturity.
It seems that I am not the only one thinking about these things lately. The guys over at Securosis have been posting a nice series of posts on SIEM selection, as has Rocky DeStefano over at Security Operations by Visible Risk. In the midst of this, Andrew Hay takes a job at the 451 Group as the Senior Analyst primarily responsible for the SIEM, Log Management, GRC, Forensics, Vulnerability Analysis, and Penetration Testing portfolios; the Gartner Group decided to release is 2010 magic quadrant for Security Information and Event Management; and LogLogic announced that they are cutting their pricing in an attempt to push the market towards a more cost effective solution for SEM/SIEM.
We live in interesting times.