Evolving to Security Decision Support: Laying the Foundation

Posted under: Research and Analysis

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

Once you get to this stage, you’ve built the basic capabilities to make better security decisions. But the key now is to integrate these practices into your day to day activities. This is going to require some process changes and a focus on instrumentation within your security program to track effectiveness to constantly improve your performance.

Implementing SDS

In order to implement Security Decision Support you’ll need a dashboard of sorts to help you track all of the information coming into your environment and to decide what to do and why. Basically you need a place to visualize the alerts and determine their relative priority. This also involves tuning your monitors to your specific environment, so that the prioritization gets better over time.

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

But first things first. Before you worry about what tool is possibly going to do this, let’s go through the capabilities that are required to implement this vision.

The first thing you need in a decision support platform to visualize security issues is, well, data. So what is going to feed this system? You need to understand the technology environment, so integrating with the organizational asset inventory (usually a CMDB) provides the view of devices and IP addresses. You’ll also want information from the enterprise directory, which provides the people view and can be used to understand a specific user’s role and what their entitlements should be. Finally, you need the security data which is information from the security monitors in place, 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/risk to the organization. Not to say that some employees are more important than others as humans (everyone is important – how’s that for political correctness?). Objectively some employees present more risk to the organization than others. That’s what you want to understand, since potential attacks against high risk employees or systems should be dealt with first.

We tend to opt for simplicity here and suggest maybe 3 or 4 different categories with very original names:

1. High: These are the folks and systems that if compromised would cause a bad day for pretty much everyone. Yes, the senior management team fits into this category, as well as, resources/systems that have access to the most sensitive data in your enterprise. This category presents risk to the entire enterprise.
2. Medium: These employees and systems will cause problems if stolen or compromised. The difference is the damage would be contained. Meaning these folks only can access specifics for a business unit or a 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 can use a low risk device/system to gain a foothold in your organization and then go after the stuff in a higher risk category.

We also recommend you categorize adversaries and attack types as well. Via threat intelligence you can determine which tactics are associated with which adversaries and possibly prioritize those from specific attackers, given their motivation to access your environment.

Once implemented, you have a clear sense of what needs to happen first based on the type of attack/adversary and the importance of the device, user and/or system. It’s kind of a priority score, but that will be referred to as a risk score by the security marketeers. This is analogous to an quantitative financial trading system. You want to take most of the emotion out of the decisions, and get down to what is best for the organization. Many experienced practitioners push back on this concept, preferring making decisions based on their gut. Or even worse, based on a FIFO (first in, first out) model.

Let’s just say, pretty much every major breach of the last 5 years provided multiple alerts of the attack in progress and opportunities to deal with it before it became a catastrophe. But for whatever reason, the attack wasn’t dealt with. So having a machine to tell you what you should focus on goes a long way towards ensuring you don’t miss major attacks.

Finally, the output of a security decision support process is a decision about what needs to happen, so you’ll need to actually do the work. Thus integration with a security orchestration and automation platform can help make changes faster and more reliably. You also probably want to send the required task(s) to a work management system (trouble ticketing, etc.) to route to the operations team and track the remediation of the issue.

Feedback Loop

We refer to Security Decision Support as a process, and that means it needs to adapt and evolve to both your changing environment and to deal with new attacks and adversaries. Thus, you want a feedback loop in place with the operational platform to learn as time goes on. Similar to tuning any other system, you should be paying 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 may not know about a false negative until you get a breach notification. Many organizations have started threat hunting to find active adversaries that the security monitoring system missed.
2. False Positives: A bit more visible and quite annoying is the false positive. These are situations that were triggered by the system, but turned out to not be issues. To be clear, this happens especially as you try to tighten the detection. But all the same, you should be factoring in the false positives to make sure your thresholds are set properly.
3. Time to Response: Given you are trying to improve your operations, you’ll want to track time as part of the decision support process. How long did it take to detect an issue? Remediate and close out the problem? This is an area where more sophisticated organizations can start setting service levels both within security (how quickly will you detect) and operations (how quickly to remediate), especially for higher risk attacks.
4. Data Source Effectiveness: As much as we like to collect and analyze more data, rather than less data, at some point you hit the point of diminishing returns of adding more data to the analytics. This is especially important for external threat intel, since that typically involves a economic investment. Although having unreliable data sources causing false positives does incur opportunity cost of those resources focusing on attacks that matter.

As you can tell, an underlying aspect to making better decisions is quantification. So always look to provide sufficient instrumentation for any new control or tactic that is implemented, ensuring that you can substantiate whether to do more or less, given the need to more effective allocate resources.

Over time, being able to compare your performance to other similar companies in a benchmark would provide yet another way of gauging the effectiveness of your operations. This is aspirational at this point, since what needs to be tracked is still an outstanding question and how to anonymize and share that data also hasn’t been defined. But clearly there is value in being able to clearly pinpoint areas of under and over performance to drive areas of continued investment.

Picking the System

Now that you know what the 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 to above, you have 3 main technologies that can potentially 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 simplistic alerting on current attacks. Depending on the tool, there are some visualization capability as well as a minimal concept of assets and risk scoring. Thus the SIEM has the pieces and therefore is a possibility, but you’ll need to bolt on the analytics and maybe even enlist an enhanced means of visualization. Additionally, the data management requirements of the SDS platform will require advancement on the part of the existing SIEM products.
2. Security Analytics: By definition, the analytics tools have the advanced math capabilities and can ingest a subset of security data and threat intel. We characterize it as a subset of the data due to the performance of the data model. Advanced analytics doesn’t lend itself to massive security data collection. Thus, the main concern with the analytics platforms is how to scale the internal and external data collection and analysis. Additionally, the analytics tools typically have decent visualization due to the need to drill down into the security data after an alert.
3. Vulnerability Management: The vulnerability management tools aren’t really constrained to just vulnerability management anymore. The vendors in this space have been actively broadening their offerings for the past few years, focusing on analytics, systems management, reporting, and some simple automation. These tools are very asset focused and do have a sense of prioritization, so those capabilities are baked into the tools.
4. GRC (whatever that means): Governance, risk and compliance tools also provide a central place for aggregation and provide visualization/dashboards to provide the basis to manage a security program. Yet, running a security program isn’t a generic thing, so these tools require significant customization to fit an organization’s program. With the ability to customize is the ability to add some of the capabilities, like more sophisticated analytics and threat intel integration.

So with a few categories of options, how to you decide? Basically, it depends on which aspect of SDS is most interesting to you and how much customization you want to do. If you are more focused on getting better alerts, then you’d lean towards the analytics and/or SIEM offerings. If you want more effective visualization and dashboards, the vulnerability management space may be a better initial choice.

Yet, regardless of the direction you choose, there will be compromises involved. None of the specific tools meet all of the needs at this point in time. 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 categories of tools will almost totally overlap into a more general security management umbrella offering what we’ve described as Security Decision Support.

– Mike Rothman
(0) Comments
Subscribe to our daily email digest

*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: http://securosis.com/blog/evolving-to-security-decision-support-laying-the-foundation