SecMon State of the Union: Refreshing Requirements
Now that you understand the use cases for security monitoring, our next step is to translate them into requirements for your strategic security monitoring platform. In other words, now that you have an idea of the problem(s) you need to solve, what capabilities do you need to address them? Part of that discussion is inevitably about what you don’t get from your existing security monitoring approach – this research wouldn’t be very interesting if your existing tools were all peachy. Visibility We made the case that Visibility Is Job #1 in our Security Decision Support series. Maintaining sufficient visibility across all the moving pieces in your environment is getting harder. So when we boil it down to a set of requirements, it looks like this: Aggregate Existing Security Data: We could have called this requirement same as it ever was, because all your security controls generate a bunch of data you need to collect. Kind of like the stuff you were gathering in the early days of SEM (Security Event Management) or log management 15 years ago. Given all the other things on your plate, what you don’t want is to need to worry about integrating your security devices, or figuring out how to scale a solution to the size of your environment. To be clear, security data aggregation has commoditized, so this is really table stakes for whatever solution you consider. Data Management: Amazingly enough, when you aggregate a bunch of security data, you need to manage it. So data management is still a thing. We don’t need to go back to SIEM 101 but aggregating, normalizing, reducing, and archiving security data is a core function for any security monitoring platform – regardless of whether it started life as SIEM or a security analytics product. One thing to consider (which we will dig into more when we get to procurement strategies) is the cost of storage, because some emerging cloud-based pricing models can be punitive when you significantly increase the amount of security data collected. Embracing New Data Sources: In the old days the complaint was that vendors did not support all the devices (security, networking, and computing) in the organization. As explained above, that’s less of an issue now. But consuming and integrating cloud monitoring, threat intelligence, business context (such as asset information and user profiles), and non-syslog events – all drive a clear need for streamlined integration to get value from additional data faster. Seeing into the Cloud When considering the future requirements of a security monitoring platform, you need to understand how it will track what’s happening in the cloud, because it seems the cloud is here to stay (yes, that was facetious). Start with API support, the lingua franca of the cloud. Any platform you choose must be able to make API calls to the services you use, and/or pull information and alerts from a CASB (Cloud Access Security Broker) to track use of SaaS within your organization. You’ll also want to understand the architecture involved in gathering data from multiple cloud sources. You definitely use multiple SaaS services and likely have many IaaS (Infrastructure as a Service) accounts, possibly with multiple providers, to consider. All these environments generate data which needs to be analyzed for security impact, so you should define a standard cloud logging and monitoring approach, and likely centralize aggregation of cloud security data. You also should consider how cloud monitoring integrates with your on-premise solution. For more detail on this please see our paper on Monitoring the Hybrid Cloud. For specific considerations regarding different cloud environments: Private cloud/virtualized data center: There are differences between monitoring your existing data center and a highly virtualized environment. You can tap the physical network within your data center for visibility. But for the abstracted layer above that – which contains virtualized networks, servers, and storage – you need proper access and instrumentation in the cloud environment to see what happens within virtual devices. You can also route network traffic within your private cloud through an inspection point, but the architectural flexibility cost is substantial. The good news is that security monitoring platforms can now generally monitor virtual environments by installing sensors within the private cloud. IaaS: The biggest and most obvious challenge in monitoring IaaS is reduced visibility because you don’t control the physical stack. You are largely restricted to logs provided by your cloud service provider. IaaS vendors abstract the network, limiting your ability to see network traffic and capture network packets. You can run all network traffic through a cloud-based choke point for collection, regaining a faint taste of the visibility available inside your own data center, but again that sacrifices much of the architectural flexibility attracting you to the cloud. You also need to figure out where to aggregate and analyze collected logs from both the cloud service and individual instances. These decisions depend on a number of factors – including where your technology stacks run, the kinds of analyses to perform, and what expertise you have available on staff. SaaS: Basically, you see what your SaaS provider shows you, and not much else. Most SaaS vendors provide logs to pull into your security monitoring environment. They don’t provide visibility into the vendor’s technology stack, but you are able to track your employees’ activity within their service – including administrative changes, record modifications, login history, and increasingly application activity. You can also pull information from a CASB which is polling SaaS APIs and analyzing egress web logs for further detail. Threat Detection The key to threat detection in this new world is the ability to detect both attacks you know about (rules-based), attacks you haven’t seen yet but someone else has (threat intelligence driven), and unknown attacks which cause anomalous activity on behalf of your users or devices (security analytics). The patterns you are trying to detect can be pretty much anything – including command and control, fraud, system misuse, malicious insiders, reconnaissance, and even data exfiltration. So there is no lack of stuff to look for – the question is what do you need to detect
