Data-driven Vulnerability Management: Graph Theory based Reachability Analysis (1/2)
This post describes the recipe for creating a reachability metric to prioritize vulnerability remediation: Combine vulnerability data and firewall ACLs in a graph, mix it with a pinch of trust and calculate the in-degree centrality. Can be served together with CISA KEV, CVSS and EPSS.
The problem
Most Vulnerability Management (VM) practitioners struggle with the vast amount of vulnerabilities that need to be addressed within the IT environment of their organisation. And although frameworks like CVSS and EPSS and initiatives like the CISA KEV list help in remediation prioritization, the organizational context is often missing.
Most VM solutions allow you to provide context by assigning a business impact value or criticality value per asset. This approach however does not take into account if a vulnerability is actually exploitable in your IT environment, it is also labour intensive and does not scale very well. Who has continuous insight into the (critical) business process — IT asset mapping? And what about the exploitation of a vulnerability in a non-critical asset, leading to compromise of a highly critical asset? Without a good approach to determine the business impact, the impact side of the risk equation in risk based VM is basically limited to the technical impact.
Solution direction
This post describes my attempt to use graph theory and specifically in-degree centrality to create a reachability metric for vulnerability remediation prioritization. Reachability analysis allows you to pick the ‘right’ 10% of vulnerabilities your IT team is able to remediate every month. Part 2 includes Python based PoC code using the Networkx library to calculate the reachability of network based vulnerabilities on IT assets, by using data from firewall (management) solutions, vulnerability management solutions and DHCP servers.
Reachability analysis
When adversaries breach a (zero trust) network and gain initial foothold via a phishing email, an appliance at the edge of the network, drive-by download or USB media, one of their first goals is to get the lay of the land. They are in essence “new hires” but without the onboarding process/program (1) resulting in limited knowledge and visibility about the IT environment. Based on their Discovery techniques, software vulnerabilities or misconfiguration are used to perform next steps.
Reachability analysis, similar to Attack Path Management, is an approach to “see” your network from the perspective of an adversary including critical paths they might choose. This approach can help security teams to prioritize security measures. In other words, remediate vulnerabilities with a higher reachability score first. It could also be used to determine the ‘blast radius’ on a network when a certain vulnerability is exploited.
The data used to build the graph and perform the reachability analysis can either be static or dynamic in nature. For this PoC both options where considered: using captured network traffic vs firewall ACL config. Both approaches have their advantages and disadvantages. Due to the sheer amount of required traffic to build a graph and the inevitable blind spots in the traffic, the firewall ACLs option was chosen. An advantage of using the captured network traffic option is that you probably no longer need the DHCP logs. More on this in the next paragraph.
Graph Theory
Graph theory is often used to solve practical challenges by modeling relationships between objects. It’s used for analyzing social networks, planning optimization, for security solutions and for this PoC to calculate and visualize reachability. In order to calculate the reachability of a vulnerability, I have chosen to utilize in-degree centrality. In-degree centrality measures how many other nodes are directly connected to a particular node. Nodes with a higher number of incoming connections tend to be more central or influential within the network because they are more frequently referenced or interacted with by other nodes. The amount of “source” nodes, in the graph are used as a weighting factor to calculate the in-degree centrality. This approach accommodates the fact that some firewall ACLs contain a handful of source addresses and sometimes entire subnets or zones (a grouping of vlan’s/subnets). Insight into the online assets per subnet (from the DHCP logs) is needed to calculate a realistic weight.
(Zero) Trust
To further give meaning to a reachability metric we need a “trust” element. For example, when an IT asset (PRINTER01) with a vulnerability (CVSS: 9.8) is only reachable from a couple of hosts on a subnet or zone that has an equal or higher trust value than the subnet/zone that this assets resides in, an argument can be made that reachability from a subnet with a lower trust value is more risky.
In order to make this work a trust score per zone is needed. For this PoC a fictitious mapping between existing security controls and the different zones was created including a classification scheme using a 4-point trust scale (high, medium, low, zero). For example:
- the Internet zone is assigned the zero-trust score
- the zone that contains all endpoint a low-trust score
- the zone that contains all printers the medium-trust score
- the zone that contains all database servers a high-trust score
This trust score is then included incorporated into the in-degree centrality calculation.
You can find part 2 here
- Paraphrased from a Haroon Meer quote
