BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Once your enterprise has decided what problems it needs a security information and event management system (SIEM)...
to solve, it's time to map these requirements to SIEM platform features.
For example, let's say you need to comply with PCI DSS. What do you need from the SIEM? You'll need to write policies that embody your controls and write reports that verify that these controls are in place and working.
In other instances, it's likely that your security team is worried about APTs and malware, so how can a SIEM platform help you detect and quickly react to threats? That means writing the rules that detect misuse and behavioral patterns that are inconsistent with common use cases. It also means sending alerts to security operations teams, and it means providing the drill down capabilities to determine if the threat is real or the alert is a false positive. Finally, it means that you will need to further tune rules to detect new behaviors or weed out poorly written rules to make your security policies more effective.
In general, it does not matter which use cases drive your requirements, rather it's critical that you understand which features and functions support your data collection, analysis and reporting functions, and then document the process on how to handle each use case. Pre-built security and compliance policies will provide some examples and help you get started, but there will be a lot of customization required. The underlying rules that enforce those policies must be tuned to your environment, and the reports that demonstrate compliance will be specific to your environment.
Another facet of your evaluation process is looking at general system issues and constraints. Performance and scalability, for example, are universal requirements. But how a product scales and which deployment models fit within your network framework are the questions you need to ask.
For every requirement you've identified, establish a workflow that shows what data needs to be collected, which policies apply, how data should be managed, what reports and alerts are needed, and who is responsible for various administrative and operational aspects of the requirement. If data needs to be correlated across multiple sources, say all network firewalls, then specify that as part of the requirement. Workflows such as this help identify what data needs to be collected, refine rules to focus your reports and quickly identify if the product UI really presents data in the way you want to consume it.
At the end of this effort, you will begin to notice it's not only important that a vendor offers a specific feature or function set that you need, but also how they deliver those features. It's not good enough that a product scales, it's how it scales. They may offer integration with directory service or trouble-ticketing systems, but how those things are accomplished matters greatly. You cannot simply rely on third-party recommendations to inform you who is "the best," as your requirements will be different from their test criteria. And you cannot rely on graphical representations that divide thought and technical leaders into different categories because those generic estimations are averaged across the entire market and are not very useful on a case-by-case basis.
About the author:
Adrian Lane is CTO of Phoenix-based analyst firm Securosis. Adrian specializes in database security, data security and software development. He is a former executive at security and software companies such as Ingres, Oracle, Unisys and IPLocks, and is a frequent presenter at industry events. Adrian is a graduate of the University of California at Berkeley with post-graduate work in operating systems at Stanford University. Reach Adrian via email at email@example.com.
Learn how SIEM can identify unauthorized access attempts
View SIEM best practices for advanced attach detection