Developing an information security strategy using attack graphs

In medium and large organizations, the process of developing and implementing an Information Security Management System (ISMS) as specified in ISO 27001 can take substantial time and resources. But for many organizations, a long-term slow developing program may not be practical.

In this setting it’s important to focus on making existing security data actionable, rather than spending weeks or months generating the information needed to prioritize enterprise risks.

Typically attack graphs aren't used in this context; they’re more often applied as a theoretical threat modeling tool. But because they show relationships between assets, exposures, vulnerabilities and expected threats, they’re perfect for the sort of forced ranking prioritization that a low-overhead ISMS requires.

So what is an attack graph, and how is it useful?

In a nutshell, an attack graph is a map of information assets, infrastructure, applications and systems connected by exploitable vulnerabilities. An attacker who wants to gain access to an information asset will seek the lowest “cost” path through the environment, where cost is measurable in terms of time, effort, or risk of detection or prosecution.

Some vendor tools automate the mapping of network assets, vulnerabilities and exposures between all systems on a network. But the end result is typically a graph with hundreds of systems and thousands of connections – even for relatively small networks.

This generates an enormous amount of data, which must then be reduced to a critical, actionable set. It also tends to bias the analyses towards technical vulnerabilities – while for an insider threat the process and compliance gaps may be more significant.

Instead, the illustration below shows an abstracted attack graph that represents nodes as populations of vulnerable systems, instead of each individual system:


A distinction between nodes is only necessary to the extent that it represents a trade-off from the perspective of the network security manager, and influences the potential effectiveness of an attacker.

This view approaches the environment from a threat perspective. An attacker external to the organization who is going after the customer database doesn’t need to compromise multiple end user devices; just one of them. Once inside the network, they can then use that system to target the database directly (query via user account) or indirectly (compromise the server hosting the database application.)

If each node represents an accountable system owner, or platform manager, and each line between nodes represents an exploitable exposure, the overall view provides a very straightforward model to represent trade-offs that each team can use to determine critical “upstream” and “downstream” exposures. Risk acceptance or mitigation decisions here are as much driven by context as they are by vulnerability ratings – which is exactly the point; a risk should be acceptable to an organization only if the impacted downstream teams are not exposed as a result. The owner of a vulnerable system should not be allowed to accept a risk in isolation on the basis that such a system “doesn’t contain anything important.”

Without much coaching, even to non-technical business managers a few principles and conclusions should quickly become apparent:
Perimeter security matters. Putting an enforced, monitored boundary between the attacker and the assets to be protected improves security.
Defense in depth matters. To the extent that an attacker must compromise several systems without being detected, it greatly reduces their chance of success. For example; assume a 50% chance of success for each of the following three attacks: first to compromise an end user device, then a trusted server in the data center, and finally security measures on the system hosting the database. The probability of success is 0.5 * 0.5 * 0.5 = 12.5%
Least-privilege access matters. Any steps an organization can take to “break” the connections between systems in an environment will improve security by giving an attacker fewer paths to reach a critical asset.
Linear investments in security won't produce linear results. Patching 8 out of 10 servers doesn’t make a company 80% secure. If an attacker can scan for the two vulnerable systems without a high risk of being detected, the cost of attacking the environment hasn’t increased. The asset remains as vulnerable as if only 1 or 2 servers were patched.

Once the planning process has prioritized the key risks, it may be time to graduate to a more formal, more granular view of the network. There are a number of open source and proprietary approaches to visualizing an entire environment and driving remediation down to each specific configuration vulnerability. But if you’ve won over management with a high level model that allows them to participate in the process and drive decision making, the hard part is done.

Risk Management: accept, transfer, avoid, mitigate risk ... or none of the above?

When dealing with information security risks, typically the range of available options are to accept the risk, transfer it, avoid it, or mitigate it by implementing security controls. But these aren't the only options, and in some circumstances there's actually a better choice: transform the risk.

A certain large pharmaceutical organization--which I will not specifically mention--for years manufactured an over-the-counter decongestant which contained an ingredient that criminals discovered could be used to illegally produce methamphetamine. The social and public health impacts of this misuse were so significant that it presented a risk that the company needed to address.

For this particular risk it would harm patients to abandon the product, and it wasn't feasible to transfer or mitigate the risks directly. So instead, the company took a different route: it made the product unusable to criminals by changing the active ingredient and was still able to offer it over the counter to its customers.

From an information security perspective, the same principle applies: risk to an information asset is determined by the seriousness of impact and the likelihood of that impact occuring. And likelihood in turn is driven by the value of that asset to the threats which are targeting it. So any organization that can reduce the value of its assets to attackers, without lowering the value to its customers, can also reduce its risks.

Some examples:

• De-identification of Protected Health Information (PHI) as per the HIPAA Privacy Rule.
  
• Identity Theft. In countries where national IDs aren't used as an all-purpose identifier, rates of identity theft are much lower than in the United States.