Security Management 2.0: Revisiting Requirements
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