Given the evolution of SIEM technology and the security challenges facing organizations, it is time to revisit requirements and use cases. This is an essential part of the evaluation process. You need a fresh and critical look at your security management environment to understand what you need today, how that will change tomorrow, and what kinds of resources and expertise you can harness – unconstrained by your current state. While some requirements may not have changed all that much (such as ease of management and compliance reporting), as we described earlier in this series, the way we use these systems has changed dramatically.

That is our way of saying it is good to start with a laundry list of things you would like to be able to do, but cannot with your current system. And while you are thinking about shiny new capabilities, don’t forget the basic day-to-day operational stuff a SIEM does. Finally, you need to consider what is coming down the road in terms of business challenges (and the resulting security issues) that will emerge over the next couple years. None of us has a crystal ball, but critical business imperatives should give you a foundation for figuring out how things need to change.

A fresh start

Some organizations choose to take a fresh look at their security management infrastructure every so often, while others have the choice thrust upon them. For instance if your organization was breached or infected by malware and your SIEM platform failed to detect it, you need to take a critical look at your security management environment. The current platform may be adequate, or it might be a dog – and you personally might not have even chosen it – but keep in mind that your success is linked to how well your platform meets your requirements. If things go south, blaming your predecessor for choosing a mediocre SIEM won’t save your job.

You also need to face the reality that other groups within the organization have differing needs for the SIEM. Operations only cares that they get the metrics they need, compliance teams only care about getting their reports, and upper management only cares about pushing blame downhill when the company is pwned by hackers. It’s time to roll up your sleeves and figure out what you need.

Every so often it makes sense to critically look at what works and what doesn’t from the standpoint of security management. To find out the best path forward, we recommend starting with the proverbial blank slate. It is helpful to consider the your priorities when you selected the system in the first place, to illuminate how your environment has changed over time and help understand the amount of change to expect in the future. To be more specific, use this opportunity to revisit the priorities of your requirements and use cases for each of the three main drivers for security management spending: improving security, increasing efficiency, and automating compliance.

It’s all about me

Setting requirements is all about you, right? It’s about what you need to get done. It’s about how you want to work. It’s about what you can’t do – at least easily – today. Well, not quite. We jest to make a point: you need to start with a look inward at what your company needs – rather than getting distracted by what the market is offering today. This requires taking a look at your organization, and the other internal teams that use the SIEM. Once your team is clear abou your own requirements, start to discuss requirements with external influencers. Assuming you work in security, you should consult ops teams, business users, compliance, and perhaps the general counsel, about their various requirements. This should confirm the priorities you established earlier, and set the stage for enlisting support if you decide to move to a new platform.

Our research has shown that organizational needs remain constant, as mentioned above: improve security, improve efficiency, and support compliance. But none of these goals has gotten easier. The scale of the problem has grown, so if you have stood still and have not added new capabilities… you actually lost ground. For example, perhaps you first implemented a Log Management capability to crank out compliance reports. We see that as a common initial driver. But as your organization grew and you did more stuff online, you collected more events, and now need a much larger platform to aggregate and analyze all that data. Or perhaps you just finished cleaning up a messy security incident which your existing SIEM missed. If so you probably now want to make sure correlation and monitoring work better, and that you have some kind of threat intelligence to help you know what to look for.

Increasingly SIEM platforms monitor up the stack – collecting additional data types including identity, Database Activity Monitoring, application support, and configuration management. That additional data helps isolate infrastructure attacks, but you cannot afford to stop there. As attacks target higher-level business processes and the systems that automate them, you will need visibility beyond core infrastructure. So your security management platform needs to detect attacks in the context of business threats. Don’t forget about advanced forensics – it would be folly to count on blocking every attack. So you will probably rely on your security management platform to help React Faster and Better with incident response.

You might also be looking for a more integrated user experience across a number of security functions to improve efficiency. For example you might 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 those consoles, and simplification through vendor consolidation might be a key driver as you revisit your requirements. Don’t be hung up on what you have – figure out what you need now. Do a little thinking about what would make your life a lot easier, and use those ideas to develop your requirements. You may not get everything you want – it might not be possible – but you won’t know if you don’t ask.

The platform

The other half of this analysis process – after organizational needs – is considering the technical impediments currently limiting what you need to do. What you have might be perfectly suited for 2008, but that doesn’t make it useful today. Here you need to delve into the functionality gaps of your current platform. The following are the platform deficiencies we hear about most frequently, with some questions to spotlight the relevant issues:

• Advanced Detection: Are you able to detect attacks in a timely fashion, or are you running down false positives most of the time? Changes in attacker behavior require the SIEM to adapt accordingly. It might be attack detection, fraud, system misuse, probing, or even data exfiltration, but advanced detection has emerged a key enterprise priority. Customers need their platforms to either detect attacks as they happen or provide quick identification – within minutes – of system compromise. To keep pace with changing attack tactics, advanced detection requires additional new event sources, analyzed using more advanced queries. Some platforms build baselines to define what’s ‘normal’, and then set activity thresholds in terms of those baselines – alerting when activity deviates from expected usage. Some combine multiple event types (using threat models) to help identify what should not be happening. Still others map externally sourced threat intelligence to look for attack patterns recorded elsewhere. Regardless of the specific approach, the state of the art for threat detection has changed from simple ‘good’ or ‘bad’ analysis of metadata to more complex behavioral and risk-based analysis, in order to detect attackers who are proficient at evading detection.
• Scalability: As your IT systems grew, and you added mobile and cloud services to your supported services, you likely more than doubled the data pushed into your SIEM – in theory at least. Did your SIEM keep pace with that expansion and continue to perform admirably? Are you still trying to get budget for a bigger server and more storage? It’s not like the amount of data you need to analyze will ever be lower than it is today, so you need to make sure the architecture of any platform you choose can keep pace.
• Forensics and analytics: The concept of drill-down on an event almost seems quaint by today’s standards – now that most platforms provide pre-defined aggregated views of user, event, or server activity, pulling this information together automagically. If you are manually looking through log files or enriching existing records to fill out the full activity picture, you should know 2007 called and wants its SIEM back. We don’t always know which specific indicators to watch to detect advanced attacks, so forensic analysis is still a key requirement. That said, forensics keeps changing. The challenge should not be gathering the data, nor trying to link data together, but instead how to make sense of the information at your disposal in a structured fashion – in order to accelerate identification of the root cause of any attack. Included usage profiles for activity baselining, as well as advanced query facilities for quick and easy ad hoc analysis, are essential.
• Compliance: Does your platform have all the compliance reports you need built in? Are they good enough that you don’t need to do major customization and polishing for audits? How many report do you need to build from scratch? Many customers tell us outright that their SIEM/LM platform is essential for compliance reports, and without it audits simply fail to occur. It’s bad enough that your auditor wants to see items in your report which you don’t think need to be there. But spending a lot of time building large numbers of reports from scratch adds insult to injury. Building custom reports is a lot of work, and while a user interface that makes this easy is very useful, better you don’t need to write them at all.
• Ease of Management: How easy is it to manage your platform? To archive older data? To roll out new collectors? How about adding new use cases or customizing the correlation rules? Are policy management screens easy to use, or do they consist of 500 check boxes you don’t fully understand? A huge amount of time is wasted managing difficult platforms. Obviously if you switch platforms you will need to accept some sunk cost to install and configure event collectors for various devices and servers. But that cost may be worthwhile if you can cut day-to-day management tasks down without sacrificing functionality.
• Integration: In the old days the complaint was that vendors did not support all the devices in your organization. Now we hear more about difficulty with integration of new event sources. Cloud monitoring, threat analytics, non-syslog events, and different intelligence feeds – are all fueling demand for streamlined integration, more storage, and better analytics.
• Vendor viability: Did you buy a product from an early leader who has since hit hard times? Did their product roadmap go off into the weeds? Vendor fortunes can change dramatically after you buy products, and shortly after we last discussed this issue (in our SIEM 2.0 paper), they did – several SIEM/LM vendors were subsequently acquired by big IT companies. The goods news is that creditors are much less likely to shutter the lager acquirers – the bad news is that they might not understand (or care) what you need, or devote sufficient resources to keeping the platform current. Either way, you should assess the vendor’s ongoing viability and ability to deliver on its roadmap, to ensure it lines up with with what you need going forward.

The key to defining your requirements is to take a fresh look at your environment to understand what you need for tomorrow, and not to be constrained by what you have today. The next step in evaluation is to take a critical look at your incumbent, and identify what gaps exist between what you need and what they have delivered. So that’s the topic for our next post.