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 it?

• Rules: You can’t ditch your rules – don’t even think about it. Actually you could – but you’d likely miss a bunch of attacks you should catch because you know their patterns. The behavioral models are focused on stuff you don’t know about, not optimized to find known bad stuff. Similar to endpoint protection, rules (signatures) are not an either/or proposition. If you already know about an attack, shame on you if you miss it.
• Threat Intelligence: With attacks you hadn’t seen yet, in the old days you were out of luck. But today there is a decent chance someone else has been attacked by it, so that’s where threat intelligence comes into play. You pump a threat feed into your security monitoring platform – someone else has already seen the attack, and you want to be ready when it comes at you. Make sure you can categorize threat intelligence alerts differently so you can track the effectiveness of the information from various threat feeds to determine value and make sure you aren’t increasing alert noise.
• Security Analytics: The final approach you need to consider is based on advanced math. You’ll hear terms like security big data, machine learning, and the generic “It’s fancy math, trust us!” to describe these techniques. Regardless of description security analytics involves profiling devices, networks, and applications to baseline normal activity – and then looking for deviations from that profile as indicators of malicious activity. It’s very difficult to discern the differences between one analytics approach and another, so understanding what will work for your organization requires actually trying them out. We’ll discuss procurement in our next post.

After a few years of using security monitoring technology, hopefully by this point you realize this isn’t (and likely will never be) a set it and forget it scenario. You’ll need to keep the system current and tune it, because not only are adversaries constantly changing and evolving their tactics, but your environment is constantly changing, requiring ongoing maintenance.

So you’ll want to build a learning and tuning step into your operational processes, ensuring you improve detection based on false positives (alerts which weren’t real attacks) and negatives (attacks you missed). If you want to be successful at detecting attacks, a feedback loop is critical.

Forensics and Response

Obviously you cannot prevent every attack, and even if you do fire an alert about a specific attack your Security Ops team might miss it. So your security monitoring platform will also play a major role in your incident response process. The challenge is less gathering the data or trying to link it together, but instead how to make sense of the information at your disposal in a structured fashion – which is what you need to accelerate identification of the root cause of attacks. As we discussed in Future of Security Operations paper, many aspects of the response process can be automated, so ensuring support for that is essential.

Key capabilities include:

• Search: Modern attacks do not limit themselves to a single machine, so you need to quickly figure out how many devices have been attacked as part of a broader campaign. Some of that takes place during validation/triage as the analyst pivots, but determining the breadth of an attack requires them to search the entire environment for attack indicators, typically via metadata.
  • Natural Language/Cognitive Search: An emerging capability is the use of natural language search terms instead of arcane Boolean operators. This helps less sophisticated analysts be more productive without having to learn a new language.
  • Retrospective Search: Responders often have a sense of what caused an attack, so they should be able to search through historical security data to find activity which did not trigger an alert because it wasn’t recognized at the time.
• Case Management: The objective is to make each analyst as effective and efficient as possible, so you should have a place to store all information related to each incident. This includes enrichment data from threat intel and other artifacts gathered during validation. This should also feed into a broader incident response platform if the forensics/response team uses one.
• Visualization: To reliably and quickly validate an alert, it is very helpful to see a timeline of all activity related to ab incident. That way you can see what actually happened across devices and get a broader understanding of the issue’s depth. An analyst can take a quick look at the timeline and figure out what requires further investigation. Visualization can present all sorts of information but be wary of overcomplicating the console. It is definitely possible to present too much.
• Drill down: Once an analyst has figured out which activity in the timeline raises concerns, they drill into it. At each stage of the attack they find other things to investigate, so being able to jump between events and devices helps identify the root causes of attacks quickly. There is also a decision to be made regarding how much data to collect and have at the ready. Obviously the more granular the available telemetry, the more accurate the validation and root cause analysis. But with increasingly granular metadata available you might not need full capture of networks or endpoints.
• Workflows and Automation: The more structured you can make your response function, the better a shot junior analysts have of finding the root cause of an attack, and figuring out how to contain and remediate it. Given the skills gap every organization faces, every bit of assistance helps. Response playbooks for a variety of different kinds of attacks within the security monitoring environment can help standardize and structure the response process. Additionally, being able to integrate with automation platforms (now called SOAR – Security Orchestration, Automation, and Response) to streamline response – at least initial phases – dramatically improves effectiveness.
• Integration with Malware Tools: During validation you will also want to check whether an executed file is actually malware. A security monitoring platform can store executables and integrate with network-based sandboxes to explode and analyze files – to figure out both whether a file is malicious and what it does. This provides context for eventual containment and remediation. Ideally this integration will be native, enabling you to select an executable within the response console to send to the sandbox, with the verdict and report filed with the case.
• Hunting: Threat hunting has come into vogue over the past few years, as mature organizations decided they no longer wanted to be at the mercy of security monitoring, desiring a more active role finding attackers. So their more accomplished analysts started looking for trouble. They went hunting for adversaries rather than waiting for security monitors to report attacks in progress. Analysts need to figure out which behaviors and activities to hunt, then seek them out in your environment. The hunter starts with a hypothesis, and then runs through scenarios to either prove or disprove it. If the hunter finds suspicious activity then more traditional response functions – including searching, drilling down into available security data, and pivoting to other devices, all help to follow the trail.

Compliance and Reporting

As we have mentioned, compliance reporting is extremely resource intensive and doesn’t add a lot of value to an organization. But if you screw up it can cost a lot of money in fines or other problems. The idea is to streamline the process of substantiating your controls to the greatest degree possible, so you can get the reports done as quickly as possible and back to real work.

This distinctly unsexy requirement is admittedly old hat, but you don’t want to go back to preparing for your assessments by wading through reams of log printouts and assembling data in Excel, do you? You want your security monitoring tool to ship with dozens of reports to show your controls in place, and map them to compliance requirements – so you don’t need to do it manually.

You’ll want the ability to customize the reports which come with the tool, as well as develop your own reports when needed.

Scalability

Over the past few years, as you added mobile and cloud services and possibly endpoint data to your security data collection, you have been dealing with a lot more data – and there are no signs of abatement in the volume of security data. So you need to plan for scale.

• Security Data: Does your existing security monitoring platform keep pace with the increase in data and continue to perform smoothly? This is where the solution’s underlying architecture shows through. Is the data aggregated on an appliance which gets bogged down at high insertion rates? Does the offering leverage a cloud-based architecture, so you don’t know how it scales – it just does? Does it combine both to support both on-premise assets and cloud-native technology stacks? The architecture you select must match your requirements – make sure any solution you consider can double in size within a reasonable timeframe without a forklift upgrade. Because the only surety in technology is that you will be dealing with more data sooner than you expect.
• Pricing Scalability: Security monitoring can be priced based on events per second, a historical metric from when all the data was collected by network sensors. We increasingly see pricing based on the volume of data aggregated per day. Either way you have a disincentive to collect more data, which is a problem when visibility into a sprawling IT environment is essential to your ability to detect attacks. So consider how the monitoring platform’s pricing scales.

Intangibles

As much as we’d like to rely solely on technical requirements to select the best security monitoring platform, other factors always come into play.

• Integration with Broader Product Line: This is the age-old choice between big security company and focused upstart. We know smaller companies innovate faster, but many larger organizations are actively trying to reduce the number of vendors they deal with. A key question is: can you gain leverage by adopting a security monitoring platfrom from a big vendor which already provides various other solutions in your environment? One thing to check is that promised integration really exists. We don’t say that facetiously – just because a vendor acquired a smaller company, or signed an OEM technology agreement, doesn’t mean their solutions have been integrated beyond procurement. That’s something to confirm during PoC.
• Ease of Management: How easy is it to manage the platform? To archive older data? To roll out new collectors, both on-premise and in the cloud? How about adding new use cases and customizing correlation rules? Are policy management screens easy to use, or do they consist of 500 checkboxes you don’t fully understand? Make sure you have good answers to these questions during the PoC, to make sure your new tool doesn’t create more work.
• Vendor Viability: Have you ever bought a product from a smaller innovative company which didn’t make it for whatever reason, and been left holding the bag? We all have, so keep in mind that vendor fortunes change dramatically and quickly. Your innovative small company may get acquired by a big IT shop and run into the ground. Conversely, many larger security companies have struggled to scale (and show Wall Street growth and profits), forcing them to cut resources and miss huge innovations in the market. So buying from a big company isn’t always a safe bet either. Always consider each vendor’s ongoing viability and ability to deliver on its roadmap, to ensure it lines up with what you need going forward.

Now that you have an idea about what you need to look for in a security monitoring solution, it’s time to talk to vendors and figure out what to buy. We will wrap up this series with the procurement process, which is how you figure out what’s real and what’s not – before you write a large check.