As we have discussed through this series, monitoring additional data types can extend the capabilities of SIEM in a number of different ways. But you have lots of options for which direction to go. So the real question is: where do you start? Clearly you are not going to start monitoring all of these data types at once, particularly because most forms require some integration work on your part – often a great deal. Honestly, there are no hard and fast answers on where to start, or what type of monitoring is most important. Those decisions must be based on your specific requirements and objectives. But we can describe a couple common approaches for climbing the monitoring stack.

Get more from SIEM

The first path we’ll describe involves organizations simply looking to do more with what they have, squeezing additional value from the SIEM system they already own. They start by collecting data on the existing monitoring systems already in place, where they already have the data or the ability to easily get it. From there they add capabilities in order, from easiest to hardest. Usually that means file integrity monitoring first. From the standpoint of additional monitoring capabilities, file integrity is a bit of a standalone feature, but critical because most attacks have some impact on critical system files and so can be detected by monitoring file integrity. Next comes identity monitoring – most SIEM platforms coordinate with server/desktop operations management systems, so this capability is relatively straightforward to add. Why do this? Identity monitoring systems include audit capabilities which provide events to SIEM in order to audit access control system activity, and to map local events back to domain identities.

From there it’s a logical progression to add to user activity monitoring. You leverage the combination of SIEM functions and identity monitoring data against a bunch of new rules and dashboards implemented to track user activity. As sophistication increases, 3rd party web security, endpoint agents, and content analysis tools can provide additional data to fill out a comprehensive view of user activity.

Once those activities are mastered, these organizations tackle database and application monitoring. These two data types overlap less in terms of analysis and data collection techniques, provide more specialized analysis, and address detection of a different class of attack. Their implementations also tend to be the most resource intensive, so without a specific catalyst to drive implementation they tend to fall to the bottom of the list.

Responding to Threats

In the second post in this series, we outlined many of the threats that prompt IT organizations to consider monitoring: malware, SQL injection, and other types of system misuse. If managing these threats is the catalyst to extend your monitoring infrastructure, the progression of what data types to add will depend entirely on which attacks you need address. If you’re interested in stopping web attacks, you’ll likely start with application monitoring, followed by database activity and identity monitoring. Malware detection will drive you towards file integrity monitoring initially, and then probably to identity and user activity monitoring, because bad behavior on behalf of users can indicate a malware outbreak. If you want to detect botnets, user activity monitoring and identity monitoring are a good start.

Your data type priorities will be driven by what you want to detect, based on the greatest risk you perceive to your organization. Though it’s a bit beyond the scope of this research project, we are big fans of threat modeling because it provides structure for what you need to worry about and how to defend against it. With a threat model – even on the back of an envelope – you can map the threats to information your SIEM already provides, and then decide which supplementary add-on functions are necessary to detect attacks.

Privileged Users

One area we tend to forget is the folks who hold the keys to the kingdom. Yes, administrators and other folks who hold privileged access to the resources that drive your organization. This is also a favorite for the auditors out there – perhaps something to do with low hanging fruit – but we see a lot of folks look to advanced monitoring to address an audit deficiency. So to monitor activity on the part of your privileged users, you’ll move towards identity and user activity monitoring first. These data types allow you to identify who is doing what, and where, to detect malfeasance.

From there you add file integrity monitoring – changing system files is an easy way for someone with access to make sure they can maintain it, and also to hide their trail. Database monitoring would then come next, as users changing database access roles can indicate something amiss. The point here is you’ve probably been doing security far too long to trust anyone, and enhanced monitoring can provide the data you need to understand what those insiders are really doing on your key systems.

Political Land Mines

Any time new technologies are introduced, someone has to do the work. Monitoring up the Stack is no different, and perhaps a bit harder because it crosses multiple fiefdoms organizations and requires consensus, which translates roughly to politics. And politics means you can’t get anything done without cooperation from your coworkers. We can’t stress this enough: many good projects die not because of need, budget, or technology, but due to a lack of interdepartmental cooperation. And why not? Most of the time the people who need the data – or even fund the project – are not the folks who have to manage things on a day to day basis.

As an example, DAM installation and maintenance falls on the shoulders of database administrators. All they see is more work. Not only do they have to install the product, but they get blamed for any performance and reliability issues it causes. Pouring more salt into the wound, the DAM system is designed to monitor database administrators! Not only is the DBA’s job now harder because they can’t use their favorite shortcuts, but now someone’s looking over their shoulder and asking annoying questions – and demanding their own help to step up the scrutiny! Very quickly, DBAs tend to find ways to scuttle the project as technically infeasible. This is just one example – application and user activity monitors are usually subverted by being labelled as destabilizing the business or being Big Brother.

How can you address these problems? We recommend paving the way for enhanced monitoring internally before you start. Not only sort out who will pay for it, but lay the groundwork for how automation will make the job easier in the long run. Paint these new capabilities as making everyone’s job easier and increasing security. Explain that if rules and reports are automated, the audit staff won’t be knocking on your cubicle wall asking for a whole bunch of stuff every week. Seriously, regulatory requirements don’t just go away, and making it a team effort and giving each stakeholder a say in the process goes a long way. Ultimately you need to sell it as a win/win. Or watch your monitoring project get pulled under by the weight of organizational politics.

Conclusion

Many organizations have embraced SIEM as a way to understand what is happening in their environments and be alerted to potential attacks before catastrophic loss. Whether the catalyst was compliance or a successful attack, those organizations can clearly improve their ability to deal with the myriad of attacks happening each day with this investment – in software, resources, and process.

SIEM has historically focused on analyzing traditional infrastructure devices, such as network and security devices. But as the technology platforms mature and the attack space evolves, many organizations are now looking to extend the reach of their SIEM beyond infrastructure and focus on where most of the attacks happen: up the Stack.

In this series we have focused on identifying the threats we now face and how advanced monitoring techniques including file integrity monitoring, database activity monitoring (part 1 & part 2), application monitoring (part 1 & part 2), identity monitoring, and user activity monitoring can improve an organization’s security posture. We have also discussed how these additional data types impact the SIEM platform and in this post where to get started.

But all these issues kind hint at the main point of the entire series: the need for context. You get alerts all day, every day, from pretty much all your devices. But you don’t have the time or the resources to really understand which attacks are real, which are imagined, and which present a clear and present danger to critical data. A “monitor everything” approach is far from a panacea, but it does provide you with a foundation of data you can use to find the answer. And with a decent amount of elbow grease invested into alerting rules to detect anomalous behavior in your environment, you can get better utilization of your scarce resources and positively impact your security posture.

And best of all, if you’ve already embraced SIEM for network and security monitoring, you are more than halfway there. Now it’s just a matter of taking that next step and we aren’t religious about which advanced monitoring direction you take. Only that you keep moving. You know the bad guys are – for what that’s worth.