Developing an approach to Attack Path Analysis for Security Posture Management

The biggest problem with most vulnerability management solutions is they overload you with data.

Attack path analysis takes that disconnected data and calculates the relationships between entities. This allows you to ask questions of your environment when verifying control effectiveness; rather than looking at thousands of vulnerabilities.

Security posture management looks to understand if the organisation struggles to keep pace with patching, if environment configuration drifts over time, and if complexity affects authorisation.

We commonly refer to this trio as the holy grail of security hygiene.  Microsoft estimates that 90% of breaches occur not because of elite hackers, but opportunistic criminals taking advantage of organisations who have neglected their security posture.

The problem I’m noticing with most platforms who claim to solve the problem in this space is they fail to enrich the data with context, and therefore, are unable to exploit its potential correctly. They only give a data overload experience filtered and ranked by criticality…

I want a platform not to give me security data, but instead tell me what to do.

Give me intelligent actions!

Security Data Vs Intelligent Action Enabled by Attack Path Analysis

Intelligent actions enabled via attack path analysis would provide two distinct benefits when analysing your organisation’s security posture. Instead of having a list of security flaws, you could:

• Proactively computed high-value attack paths.
  • e.g. there is an exploit path from the user zone to the SCCM server, this is being actively targeted by threat actions and similar organisations have been ransomwared because of this control failure.
• Validate the environment against key use cases and have them recalculated daily.
  • e.g. Can anyone in the user zone gain access to any production data in the database zone? Could a breached front office work terminal put the critical servers at risk?

In both of these scenarios, we would look to understand if a combination of possible network connections, patch vulnerability data, misconfiguration and broken authorisation could create a toxic combination where controls are no longer effective and a real attack path exists.

We can do this by using a graph database to create a digital twin of our environment. Think of each server or workstation in your environment as a node. A possible network connection between them creates an edge relationship and a remotely exploitable server could be a condition of the edge relationship. This would then allow you to query paths through your graph database.

To map this fully and be effective we need to collect 5 key data sources:

1. Network connection information
2. Asset context via tagging
3. Patch vulnerability data
4. Environment misconfigurations data
5. Authorisation data

1. Network connection information

Using a host-based agent, record the current connections and fuzz the network to understand other possible network connections:

• Understand every connection which is currently occurring
• Understand every node with an agent and the open ports
• Over several days allow every node with an agent to attempt a connection to every other node’s services to map possible connections.

This will allow you to create a Graph map of the environment where edge relationships map connections which can occur.

2. Asset context via tagging

It’s very easy to tell if something exists. The harder part is knowing WHY it exists.

Embedding organisational context at an early stage is imperative. At a minimum, the graph database should have an understanding of:

• SCCM / Intune / Domain Controllers / Backups
• User zone laptops
• DEV zone
• UAT zone
• PROD zone
• Databases
• DMZ
• Critical assets

3. Patch Vulnerability data

What vulnerabilities could cause remote compromise of a node?

• Pull vulnerability information and filter on the ones known to cause remote compromise of nodes.
• Understand the protocol/port on which this vulnerability exists.
• Create a new edge relationship between nodes which are vulnerable and all the known devices on the network which can create a connection to them on that port.

Now we understand all the remotely exploitable boxes and the relationships which could take advantage of the vulnerability.

4. Environment misconfiguration data

What misconfigurations could cause remote compromise of a node?

• Pull the information of misconfigurations in the environment which are known to cause remote compromise of nodes.
• Understand the protocol/port on which this vulnerability exists.
• Create a new edge relationship between nodes which are vulnerable and all the known devices on the network which can create a connection to them on that port.

Now we understand all the remotely exploitable boxes and the relationships which could take advantage of the misconfigurations.

We’re starting to form a very rich view of the organisation’s security posture and the workstation and server components which could take advantage of each other.

5. Authorisation data

The final piece of the puzzle is to understand broken trust relationships. What authentication information could cause remote compromise of a node:

• Pull the information of:
• Active directory trusts
• Local accounts on the hosts
• Cached accounts via Windows login
• Keys/secrets/passwords held on the host’s filesystem or console history
• AD credentials easily cracked via ”rockyou”.
• Create a new edge relationship between nodes

Now we understand all the authentication relationships which could take advantage of the misconfiguration.

An example of how Attack Path Analysis works

Now that we have a digital twin of our environment we’re able to visualise it and ask questions…

Question: Can an attack path leveraging patching, misconfiguration and authorisation allow a user who has been phished to gain access to the production Payment service?

Answer: YES, an attack path does exist from the user’s zone to the payment service. The current security controls are ineffective.

• 1->2: Lateral movement share local account
• 2->3: Lateral movement missed patch
• 3->4: Lateral movement misconfiguration
• 3->4: Breaks organisation's segregation policy
• 4->5: Lateral movement creds found on the host

Simples. Now you know enough to build your digital twin 😄