As we resume our series on Evolving to Security Decision Support, let’s review where we’ve been so far. The first step in making better security decisions is ensuring you have full visibility of your enterprise assets, because if you don’t know assets exist, you cannot make intelligent decision about protecting them. Next we discussed how threat intelligence and security analytics can be brought to bear to get both internal and external views of your attack environment, again with the goal of turning data into information you can use to better prioritize efforts.

Once you get to this stage, you have the basic capabilities to make better security decisions. Then the key is to integrate these practices into your day-to-day activities. This requires process changes and a focus on instrumentation within your security program to track effectiveness in order to constantly improve performance.

Implementing SDS

To implement Security Decision Support you need a dashboard of sorts to help track all the information coming into your environment, to help decide what to do and why. You need a place to visualize alerts and determine their relative priority. This entails tuning your monitors to your particular environment so prioritization improves over time.

We know – the last thing you want is another dashboard to deal with. Yet another place to collect security data, which you need to keep current and tuned. But we aren’t saying this needs to be a new system. You have a bunch of tools in place which certainly could provide these capabilities. Your existing SIEM, security analytics product, and vulnerability management service, just to name a few. So you may already have a platform in place, but these advanced capabilities have yet to be implemented or fully utilized. That’s where the process changes come into play.

But first things first. Before you worry about what tool will to do this work, let’s go through the capabilities required to implement this vision.

The first thing you need in a decision support platform to visualize security issues is, well, data. So what will feed this system? You need to understand your technology environment so integration with your organizational asset inventory (usually a CMDB) provides devices and IP addresses. You’ll also want information from your enterprise directory, which provides people and can be used to understand a specific user’s role and what their entitlements should be. Finally you need security data from security monitors – including any SIEM, analytics, vulnerability management, EDR, hunting, IPS/IDS, etc.

You’ll also need to categorize both devices and users based on their importance and risk to the organization. Not to say some employees are more important than others as humans (everyone is important – how’s that for political correctness?). But some employees pose more risk to the organization than others. That’s what you need to understand, because attacks against high-risk employees and systems should be dealt with first.

We tend to opt for simplicity here, suggesting 3-4 different categories with very original names:

1. High: These are the folks and systems which, if compromised, would cause a bad day for pretty much everyone. Senior management fits into this category, as well as resources and systems with access to the most sensitive data in your enterprise. This category poses risk to the entire enterprise.
2. Medium: These employees and systems will cause problems if stolen or compromised. The difference is that the damage would be contained. Meaning these folks can only access data for a business unit or location, not the entire enterprise.
3. Low: These people and systems don’t really have access to much of import. To be clear, there is enterprise risk associated with this category, but it’s indirect. Meaning an adversary could use a low-risk device or system to gain a foothold in your organization, and then attack stuff in a higher-risk category.

We recommend you categorize adversaries and attack types as well. Threat intelligence can help you determine which tactics are associated with which adversaries, and perhaps prioritize specific attackers (and tactics) by motivation to attack your environment.

Once this is implemented you will have a clear sense of what needs to happen first, based on the type of attack and adversary; and the importance of the device, user and/or system. It’s a kind of priority score but security marketeers call it a risk score. This is analogous to a quantitative financial trading system. You want to take most of the emotion out of decisions, so you can get down to what is best for the organization. Many experienced practitioners push back on this concept, preferring to make decisions based on their gut – or even worse, using a FIFO (First In, First Out) model.

We’ll just point out that pretty much every major breach over the last 5 years produced multiple alerts of attack in progress, and opportunities to deal with it, before it became a catastrophe. But for whatever reason, those attacks weren’t dealt with. So having a machine tell you what to focus on can go a long way toward ensuring you don’t miss major attacks.

The final output of a Security Decision Support process is a decision about what needs to happen – meaning you will need to actually do the work. So integration with a security orchestration and automation platform can help make changes faster and more reliable. You will probably want to send the required task(s) to a work management system (trouble ticketing, etc.) to route to Operations, and to track remediation.

Feedback Loop

We call Security Decision Support a process, which means it needs to adapt and evolve to both your changing environment and new attacks and adversaries. You want a feedback loop integrated with your operational platform, learning over time. As with tuning any other system, you should pay attention to:

1. False Negatives: Where did the system miss? Why? A false negative is something to take very seriously, because it means you didn’t catch a legitimate attack. Unfortunately you might not know about a false negative until you get a breach notification. Many organizations have started threat hunting to find active adversaries their security monitoring system miss.
2. False Positives: A bit more visible and source of much annoyance is the false positive. These are generated by the system, which turned out to not be real security issues (they are certainly workflow issues). They crop up particularly when you try to tighten detection. Work on false positives to ensure you have proper thresholds.
3. Time to Response: You are trying to improve your operations, so you will want to track duration as part of your decision support process. How long did it take to detect an issue? To remediate and close out the problem? This is an area where more sophisticated organizations can start setting service levels – within both security (how quickly you detect) and operations (how quickly you remediate), especially for higher risk attacks.
4. Data Source Effectiveness: As much as we like to collect and analyze more data, rather than less, at some point you will reach a point of diminishing returns on adding more analytic data. This is especially important for external threat intel, which typically carries a financial cost. Although of course false positives from unreliable data sources carry opportunity cost and distract from real attacks.

As you see, an key requirement for better decisions is quantification. Always provide sufficient instrumentation for any new control or tactic, ensuring that you can substantiate whether to do more or less, given the need to more effectively allocate resources.

Over time the ability to benchmark your performance against similar organizations provides yet another way to gauge the effectiveness of your operations. This is aspirational at this point, because what needs to be tracked is still an open question, and how to anonymize and share that data also hasn’t yet been defined. But clearly there is value in being able to clearly pinpoint areas of under and over performance to focus continuing investment.

Picking the System

Now that you know what your decision support system needs to do, the next question is how do you get one? Can you go to the local computer store and pick one up? Can you just check out your favorite analyst’s quadrant chart and send over a PO#? Alas, it’s not that easy – yet. You already probably have pieces of the puzzle, but not all of them in one environment.

As we alluded above, three main technologies may evolve to provide the Security Decision Support platform:

1. SIEM: The SIEM already is the aggregation point for security data, and can integrate threat intelligence for simple alerting to current attacks. Depending on the tool there may be some visualization capability, as well as minimal asset tracking and risk scoring. The SIEM has key pieces and is therefore a possibility, but you’ll need to bolt on the analytics, and perhaps even enlist an enhanced means of visualization. Additionally, the data management requirements of SDS require substantial advancement from existing SIEM products.
2. Security Analytics: By definition analytics tools have the advanced math capabilities, and can ingest a subset of security data and threat intel. We call it a subset due to performance limitations of the data model. Advanced analytics doesn’t lend itself to massive security data collection. So the main concern for analytics platforms is how to scale internal and external data collection and analysis. Additionally, analytics tools typically include decent visualization to drill down into security data after an alert.
3. Vulnerability Management: Vulnerability management tools aren’t really limited to their original scope any more. These vendors have been actively broadening their offerings for the past few years – focusing on analytics, systems management, reporting, and simple automation. These tools are very asset-focused, with a sense of prioritization, so those capabilities are baked in.
4. GRC (whatever that means): Governance, Risk, and Compliance tools include central aggregation with visualization and dashboards, offering a basis to manage a security program. But security programs aren’t generic and interchangeable, so these tools require significant customization to fit any organization’s program. Customizability includes some scope for adding capabilities, such as more sophisticated analytics and threat intelligence integration.

So with a few types of options to consider, how do you decide? It depends on which aspect of SDS is most interesting to you, and how much customization you want to perform. If you are focused on better alerts you will lean towards analytics and SIEM offerings. If you want more effective visualization and dashboards, vulnerability management may be a better initial choice.

But regardless which direction you choose, there will be compromises. None of the available tools satisfies all the requirements today. But if there is one thing we’ve seen over the past 20 years in security, sooner rather than later tools mature and add capabilities to meet more generalized needs. This environment will be no different, and within a few years these various types of tools will almost totally overlap into a more general security management umbrella, offering what we have described as Security Decision Support.