In our last post in this series we discussed what SIEM is, and more importantly what SIEM is not. Much of what we know of SIEM today and it’s ability to solve problems relies on marketing material and real world scenarios from 5+ years ago. To summarize; I like to liken SIEM to a programming IDE, for example Microsoft Visual Studio. Visual Studio is a powerful, and there is literally no programmatic problem that you can’t use the IDE to program a solution for. However, Visual Studio is not in and of itself that solution. It is a means to accomplish that solution, but not one. Think of SIEM this way, there is almost no use case that you can’t attack with SIEM, but know that it will require expertise, time, data and analysts to respond to the incidents.
So understanding that SIEM is not for everyone, the question to ask is clearly… “Is it for you?” To answer this I will give you several key questions to ask of your current security personnel and program that will help you determine whether you are ready for a SIEM deployment.
1. Does my organization currently have tools which give us visibility into: User Internet Activity, Enterprise Authentication, Network Intrusion or Attack Events, Desktop Intrusion or Incident Response?
2. Does my organization have a mature incident response process?
3. Does my organization currently collect and monitor logs in a central repository of any kind?
4. Does my organization currently have the staff to respond the current incidents our security tools detect?
5. Does my organization currently have alignment from Sr. Management for a Security Operations build-out? Is this alignment a long-term commitment and has it been documented?
If you can’t answer yes to the questions above, I wouldn’t necessarily say you don’t need a SIEM tool… but you might not yet be ready for it yet. To backup this point, we examine several of the popular frameworks in existent for security program development; we see that SIEM is not in the top priorities identified for organizations.
If we use the ASD Top 35 we see that the top 4 priorities organizations should focus on for risk mitigation are:
1. Application Control (Whitelisting)
2. Application Patching
3. Operating System Patching
4. Restrict Administrative Privileges.
Rightfully the framework asserts that investment into centralized logging, monitoring and correlation has limited returns if first the enterprise hasn’t prepared itself with strong preventative security. In fact what would qualify as SIEM does not show up on the ASD Top 35 until the 15th and 16th items on the list.
The point of this series is not to argue the value of Security Event Monitoring or SIEM technology. However, organizations should rightfully question where this effort should exist within the priorities of their security program build out. Far too many organizations have attempted to build their security program around a SIEM tool, instead of building a program, requirements, use cases and enumerating risks to the organization and then purchasing the right SIEM which aligns with their current tools, budget and operational capabilities. When organizations being to approach SIEM with this mindset, we will see a return on investment once again from the SIEM products that exist in the market today.
In the end, there is not one answer for all organizations. Some need a SIEM, some do not. The point of all of this is to hopefully cause organizations to look at their capabilities and think long term about Security and SOC development especially related to SIEM. If you would like to discuss these items further or have a conversation with us about your security program, SOC build-out or SIEM deployment please reach out to us at [email protected]