Given the evolution of both the technology and the attacks, it’s time to revisit your specific requirements and use cases – both current and evolving. You also need to be brutally honest about what your existing product or service does and does not do, as well as your team’s ability to support and maintain it. This is essential – you need a fresh look at the environment to understand what you need today and tomorrow, and what kind of resources and expertise you can bring to bear, unconstrained by what you need and do today. Many of you have laundry lists of things you would like to be able to do with current systems, but can’t. Those are a good place to start, but you also need to consider the trends for your industry and look at what’s coming down the road in terms of security and business challenges that will emerge over the next couple years. Capturing the current and foreseeable needs is what our Security Management 2.0 process is all about.

Blank Slate

In order to figure out the best path forward for security management, start with the proverbial blank slate. That means revisiting why you need a security management platform with fresh eyes. It means taking a critical look at use cases and figuring out their relative importance. As we described in our Understanding and Selecting a SIEM/Log Management Platform paper, the main use cases for security management really break down into 3 buckets: Improving security, increasing efficiency, and automating compliance.

When you think about it, security success in today’s environment comes down to a handful of key imperatives. First we need to improve the security of our environment. We are losing ground to the bad guys, and we need to make some inroads on figuring out what’s being attacked more quickly and protecting it. Unfortunately nobody’s selling (working) crystal balls that tell you how and when you will be attacked, so the blank slate strategy entail monitoring more and determining how your detection and response systems will react more quickly.

Next we need to do more with less. It does look like the global economy is improving but we can’t expect to get back to the halcyon days of spend first, ask questions later – ever. And while that may sound like “work smarter, not harder” management double-speak, there are specific automation and divide & conquer strategies that help reduce the burden. With more systems under management, we have more to worry about and less time to spend poring over reports, looking for the proverbial needle in the haystack. Given the number of new attacks – counted by any metric you like – we need to increase the efficiency of resource utilization.

Finally, auditors show up a few times a year, and they want their reports. Summary reports, detail reports, and reports that validate other reports. The entire auditor dance focuses on convincing the audit team that you have the proper security controls implemented and effective. That involves a tremendous amount of data gathering, analysis, and reporting to set up – with continued tweaking required over time. It’s basically a full time job to get ready for the audit, dropped on folks who already have full time jobs. So we must automate those compliance functions to the greatest degree possible.

Increasingly technologies that monitor up the stack are helping in all three areas by collecting additional data types like identity, database activity monitoring, application support, and configuration management – along with different ways of addressing the problems. As attacks target these higher-level functions and require visibility beyond just the core infrastructure, the security management platform needs to detect attacks in the context of the business threat. Don’t forget about the need for advanced forensics, given the folly of thinking you can block every attack. So a security management platform to help React Faster and Better within an incident response context may also be a key requirement moving forward.

You might also be looking for a more integrated user experience across a number of security functions. For example, you may have separate vendors for change detection, vulnerability management, firewall and IDS monitoring, and database activity monitoring. You may be wearing out your swivel chair switching between all the consoles, and simplification via vendor consolidation can be a key driver.

Understand that your general requirements may not have changed dramatically, although you may prioritize the use cases a little differently now. For example, perhaps you first implemented Log Management to crank out some compliance reports. It wouldn’t be the first time we’ve seen that as the primary driver. But you just finished cleaning up a messy security incident your existing SIEM missed. If so, you probably now put a pretty high value on making sure correlation works better.

Once you are pretty clear within your team about the requirements for a security management team, start to discuss the topic a bit with external influencers. You can consult the ops teams, business users, and perhaps the general counsel about their requirements. Doing this confirms the priorities you already know and sets the stage to provide you support if the decision involves moving to a new platform.

Critical Evaluation

Now it’s time to check your ego at the door. Unless you weren’t part of the original selection team – then you can blame the old regime. Okay, we’re kidding. Either way the key to this step involves a brutally honest assessment of how your existing platform meets the needs that drove the initial implementation. This post-mortem type analysis evaluates the platform in terms of each of the main use cases (security, efficiency, compliance automation), as well as some other aspects of real world use.

Even better, you’ll need to determine why the product/service isn’t measuring up. Common reasons we see include:

• Ease of use: Are there issues getting the product/service up and running? Did it require tons of professional services? Were you able to set up sufficiently granular rule sets and reports? This tends to be an issue with the technology platform itself.
• Implementation: Were the rules configured correctly up front? Was the rule base maintained adequately as things changed, or was rule management so painful it tended to lag? Was all the proper data collected by the system to provide a broad view of your infrastructure? These issues tend to be your problems, and you need to own them. While deceiving yourself about how your organization implemented the technology might save a little face, it would only position you for another project failure.
• Scalability: Did your chosen platform just run out of gas when event volume ramped up? Were there architectural or even cost issues that prevented you from deploying a broader infrastructure to meet your needs? Did you have to surround the existing correlation engine with a set of logging devices to control event flow? This might be a technology issue, or it could be a deployment architecture problem. Either way, the existing platform hasn’t scaled to what you need and that’s a big issue.
• Care and feeding: Do you have adequate resources and expertise to optimize the system? Does keeping the back-end database operational require multiple FTEs? Has your staff been gutted to the point you don’t have resources to monitor the system yourself? It’s very important to make a realistic assessment of your team’s ability to support the security management platform moving forward. The best technology in the world doesn’t help much if you can’t keep it up and running with a current rule set.
• Forensics Does ‘drill down’ mean manually looking through raw event logs? Worse, does it always involve going back to the archives to find the events you need? Were events normalized into a useless subset of original data? Despite advancements in detection and alerting, forensic analysis is a common requirement for ascertaining the real severity of detected issues; and making it easier to access important data saves time and frustration.
• Dying on the vine: Has the technology been kept up to date? When was the last major release and did it address some of your issues? Has the vendor told you about the next release’s road map? Have they made good on past promises of new capabilities? After big acquisitions, some products aren’t maintained adequately. Now you have to assess whether things will get better.
• Vendor viability: Did you buy a product from an early leader who has since hit hard times? Did their product roadmap involve driving off the road? Vendor fortunes can change dramatically after you buy their products, and you may need to reassess the vendor’s ongoing viability. It’s a bad day when you have to make a call to get source code delivered from escrow, after creditors locked the vendor’s doors.

Now you see why you need to check your ego at the door and make a brutally honest assessment of your team’s ability to implement and support a security management platform. It would be great if this technology were plug and play, but it isn’t. Regardless of whether you move to a new platform or not, you’ll need to support it. It’s very easy to just blame the vendor if the product hasn’t met expectations, especially if the product has been left to die on the vine. But if there were implementation or maintenance issues on your side, those will still be there even with a modern, up-to-date platform. You can’t blame the vendor for operational failure on your end.

Now that you understand what you need at this point in time, and why your existing platform isn’t meeting your needs, it’s time to evaluate other options. There is a lot of ground to cover, so the next two posts will deal with new features available on these platforms and why some of these new capabilities are worth investigating.