Structural Security Posture
Polaris is a tool to analyze the structural security posture of a system’s design. In this section, we explain the concept of structural security posture and how it can be useful in analyzing the security of a system’s design.
A system’s security posture is described as its security state at a specific point in time that reflects its ability to defend against knowable threats that affect it [QRS2021]. The concept of security posture recognizes the need for system designs to be evaluated based on a given view of the system (such as structural, behavioural, functional) since each view focuses on specific attributes of the system which we can use to quantitatively evaluate the system’s security for that view. These quantitative metrics serve as indicators of a system’s security posture for a given view. Polaris helps system designers evaluate the security posture of system in the structural view, called the structural security posture.
A system is comprised of several elements, which refer to any assets of the system such as components, channels, datastores, etc. Structural security posture is an approach consisting of a collection of system-level and element-level metrics affected by specific parameters that help us evaluate a system’s security posture based on its structural view. Since structural security posture incorporates both system-level and element-level metrics, we can use correlations between these metrics to evaluate ‘what-if’ scenarios by analyzing the effect of different component configurations on the overall system’s security and element-level security. It is important to note that structural security posture is not a metric, but a security evaluation approach to provide a broader characterization of a system’s security level.
The structural view of a system illustrates the composition of elements that make up the system. It provides the terminologies associated with the system’s elements and its interfaces. The structural view of the system can be modeled in a number of ways, one of which is using a Unified Modeling Language (UML) class diagram. This view helps us to evaluate security properties related to the overall structure of the system such as the structural attack surface of a system [CMU2012].
We model a system’s structural view as a graph \(\mathcal{G} = (N, E)\) where \(N\) is a set of nodes and \(E\) is a set of edges. We consider directed edges in the graph to reflect the relationship of system elements and undirected edges in the graph to reflect the communication between them. We focus our efforts on the communication between system elements (undirected edges).
Attack Surface Metric
We use the attack surface as a system-level metric to evaluate a system’s structural security posture. A system’s attack surface is described as the sum of attack vectors where an unauthorized user attempts to manipulate data inputs or extract data from the system. The intuition behind measuring a system’s attack surface is based on the idea that the more extensive and exposed the system’s attack surface, the more opportunity for a malicious adversary to conduct an attack [IEEE2010].
The attack surface metric quantifies a system’s interaction with its external environment using three types of system elements:
Components (\(C\)): These are the entry and exit point system elements (nodes in the graph) that accept/process data originating from the system environment. Gennari and Garlan’s work refers to components of the system as methods.
Links (\(L\)): These refer to the communication links (edges in the graph) connecting a system to its environment. Gennari and Garlan’s work refers to links of the system as channels.
Datastore Items (\(D\)): These are the data types of items stored in datastores (also nodes in the graph) used by the system. Gennari and Garlan’s work refers to datastore items as untrusted data items.
Given these system elements, the graph representation of a system’s structure is captured by \(\mathcal{G} = (C \cup D, L)\) where the set of components \(C\) and set of datastore items \(D\) are disjoint.
Each element is evaluated for its attractiveness to an attacker, i.e., the likelihood an attacker will use that component in an attack. This attractiveness of a component to an attacker is quantified as a ratio of the potential damage the attacker can inflict on the system by exploiting that component over the amount of effort needed to access that component (determined by the component’s access rights). This ratio is called the Damage Effort Ratio (DER) and it corresponds to the intuition that an attacker will select the component offering the highest damage potential with the least amount of effort.
In the following, we describe the DER for each of the three different element types described above.
DER for Components
Damage potential for components that serve as entry/exit points is evaluated in terms of their privilege since an attacker is likely to acquire the privileges assigned to that component post-compromise.
DER for Links
Damage potential for links is evaluated based on the restrictions placed on the data that a link can transmit given its protocol. Protocols with reduced restrictions on the types of data that a link can transmit increase the advantage for an attacker as there are more ways to exploit the link. For example, the link can be used to transmit unauthorized executable code to a database as done in SQL injection attacks.
DER for Datastore Items
Damage potential for items in datastores is evaluated based on the type of data they store. The more permissive (less restrictive) the data type, the higher the likelihood of its exploitation by an attacker to execute unauthorized commands.
It is important to note that a numerical, ordered scale of values is attributed to the parameters of DER. For example, the root privilege of a component may be the highest level of privilege and therefore be assigned a higher numeric value than the guest privilege for that component.
The system’s attack surface is presented as a triple that corresponds to the total contributions across the three element types calculated by aggregating the DER for each element type as shown below.
Eigenvector Centrality Metric
We can use centrality metrics as element-level metrics in the evaluation of a system’s structural security posture. In graph theory, centrality is associated with how important a node in a graph is by ranking it based on how ‘central’ it is. The more central the nodes, the more important they are likely to be in the system. Formally, we can define centrality as a function \(c: N \to \mathbb{R}\) that induces a total order on the set of graph nodes \(N\) and where \(c\) refers to any type of node centrality such as degree centrality or eigenvector centrality. A node \(n_i \in N\) is considered to be at least as central as node \(n_j \in N\) if \(c(n_i) \geq c(n_j)\) for some function \(c\) corresponding to a specific type of centrality metric. Centrality metrics differ based on how they compute the importance of nodes. Some of these metrics can be applied on both directed and undirected graphs while others apply to one or the other. We focus our efforts on the communication between components (undirected edges) and therefore select a centrality metric that can be applied in an undirected graph.
The simplest way to compute centrality for a graph is to evaluate the degree (number of edges) for each node in the graph. This metric is called degree centrality. The higher the degree centrality of a node, the more important it is. However, in this work, we express the central behaviour of system elements using the eigenvector centrality metric, which builds on the notion of degree centrality [OXFORD2018]. Eigenvector centrality measures a node’s centrality by evaluating the centrality of its neighbours rather than just the number of edges incident with the node [JOURNAL1987]. Eigenvector centrality assigns a relative rank or score to reflect the importance of a node in the graph based on the importance of its neighbours. A node with a high eigenvector centrality rank is one that is connected to many other high-ranking nodes in the graph. For the structural security posture evaluation, computing a system component’s eigenvector centrality helps us to identify important (attractive) components that the attacker may target due to its proximity to other important system components.
The eigenvector centrality for a node \(n_i\) is the \(i\)-th element of the eigenvector \(x\) in the following equation:
where \(A\) is the adjacency matrix representing the graph with eigenvalue \(\lambda\). According to the Perron-Frobenius theorem, a unique solution for \(x\) exists if \(\lambda\) is the largest eigenvalue in \(A\) [OXFORD2018].
Data-driven Threat Metrics
Since a system’s security posture is defined within the scope of the knowable threats of a system, we incorporate the data-driven metrics provided by Merak, a Compass tool to analyze threats and requirements for a given component of the system [IEEE2021]. Merak leverages multiple external data sources such as the National Vulnerability Database (NVD) [NVD], MITRE ATT&CK [MITRE2018], CCCS Alerts and Advisories [CCCS] to ascertain threats that are likely to affect a system component based on its security requirements and design specifications. Polaris incorporates the following Merak metrics:
Unmitigated threats: Identified threats for which there are currently no security requirements.
Mitigated threats: Identified threats addressed by the provided security requirements.
Extraneous requirements: Provided security requirements for which no relevant threats were found.