BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Before even looking at available security information and event management products or talking to vendors, it's...
critical that enterprises fully understand the problems they are trying to solve rather than making new -- or additional -- investments in a hurry. Accurately assessing business and technical requirements and taking a long, hard look in the mirror at your organization plays a key role in successful SIEM deployments.
Sure, SIEM platforms have matured and offer greater capabilities in security event detection, scalability and management. But unless you understand what data and policies your compliance department needs, what threats your security team is really worried about and what resources your operations team can devote to your SIEM, it is impossible to gauge whether a vendor can meet your needs.
While just about every enterprise has these same use cases -- with many having all three (security event detection, scalability and management) at the same time -- how each company goes about fulfilling its requirements is different. Two businesses within the same industry will have radically different internal processes, systems and approaches to corporate governance. This means your company may have the same use cases as similar firms in your industry, but your requirements will not necessarily be the same. A universal list of requirements is not something you can pick up in a trade magazine or from an industry analyst; those requirements are unique to your company. One of the most common reasons SIEM platform deployments fall short of expectations is the failure to fully identify what each stakeholder needs.
Finding out what your organization needs from SIEM
In practice, the proper approach involves little more than asking how to address the use cases we care about. Some questions to ask include:
- If it's compliance, what specific summary, detailed and verification reports do you need?
- Who is responsible for policy setting, implementation and review?
- What data needs to be collected for each of the reports?
- If something goes wrong, who does the analysis and what tools will they need?
- Is separation of duties required, and if so, what model do you want to follow?
Be sure to gather the list of key stakeholders and have them help with planning and requirements definitions. What compliance requirements must be met, and what reports do you need? What risks do you need to detect, and what information and tools will the security operations team need to do its job? How can you reduce the time spent with system deployment and administration? Who will deploy the product? Who is responsible for implementing policies? What is the timeframe for rollout?
Keep in mind this is where it gets personal; you are asking for both requirements and commitments from the team. You need to get as specific as possible in each case, and you'll need to fully document what must be accomplished and who will do the work. Finally, get some consensus as to the features that are critical, needed and nice to have.
If this sounds like a lot of work, it is. There are a lot of moving parts to security information and event management as it's used to monitor a vast number of disparate applications and devices, and must make sense of all these events in one common platform. It's important to mention this because setting expectations in regard to what SIEM features are most important will sway your buying decision. Prioritizing requirements is important because you may have to pick and choose between different platforms based upon the features and deployment options of each product. And when it comes to deployment, establishing priorities is critical in managing expectations; rolling out a SIEM platform takes time, with new capabilities rolled out over the course of many months, and all stakeholders will want their stuff first.
Enterprises must also consider how this project will be budgeted. It's a tough question, but now that everyone has added their two cents on what the product needs to do, you need to understand who pays for the product and who budgets their resources to deploy and manage it over time. You may find that if resources are lacking, you reduce the total number of features to be rolled out or scale back expectations. If no one has the resources to manage the SIEM platform, be realistic and place these on the "nice-to-have" list.
Establishing requirements is a little easier if you have an existing SIEM platform in place. In this case, you can catalog what you have and then ask the stakeholders what's missing. This will provide a pretty good overview of what's needed, and most people who use the incumbent system will have some sort of wish list (or list of things that make them really angry) that they'll be more than happy to share. Then ask senior management what sort of long-term improvements or changes they want in the IT environment, especially those around evolving business lines that will need support. Between the three lists (what you have, what's deficient and what will be needed in the future), you're in pretty good shape to move on to mapping requirements to features.
As a final thought, if you're considering augmentation or replacement of an existing system, then be honest with yourself about what the incumbent platform does well and what it does not. Replacement is a costly, time-intensive process. It should be undertaken only if the current system is a complete failure and your research has proven that a replacement system exists that won't fail just as miserably as the last one. Many companies augment existing log management systems with a specialized SIEM to accomplish compliance reporting or security management. We've witnessed successful SIEM replacements, but it requires a lot of time, planning and investment to pull it off.
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 firstname.lastname@example.org.
Learn how next-gen SIEM systems to boost network visibility
Rethink how you use your SIEM product