Model-based threat analysis

It used to be that most systems were isolated and disconnected; the only way to attack such a system required a physical presence. Those days are long gone.

These days, most systems are internet-enabled and connected via apps to cloud-based servers and social media. This presents opportunities to attack these systems, compromise their security, violate their privacy, steal their information, and cause damage through malicious software.

Unfortunately, little has been done to protect systems in a systematic fashion. The most common response I hear when consulting is " Security. Yeah, I need me some of that," and the issue is ignored thereafter. Sometimes, some thought is given to applying security tests ex post facto, or perhaps doing some code scans for software vulnerabilities, but very little is done to methodically analyze a system from a cyber-physical security posture standpoint. This recipe addresses that specific need.

Basics of cyber-physical security

Security is the second pillar of dependability. The first, safety, was discussed in the previous recipe. Reliability, the remaining pillar, is discussed in the next recipe. Key concepts for a systematic approach to cyber-security needs are as follows:

Security – Resilience to attack.

Asset – A security-relevant feature of a system that the system is responsible for protecting. Assets have the following properties:

• Access Level Permitted
• Accountability
• Asset Kind:

  a. Actor

  b. Information Asset

  c. Current Asset

  d. Resource Asset

  e. Physical Asset

  f. Service Asset

  g. Security Asset

  h. Tangible Asset

  i. Intangible Asset

• Availability
• Clearance Required
• ID
• Integrity
• Value

Asset Context – The system or extra-system elements enshrouding one or more assets; a safe in which money is kept is a simple example of an asset context. An asset context may be decomposed into contained asset context elements.

Security field – The set of assets, asset contexts, vulnerabilities, and countermeasures for a system (also known as the system security posture).

Vulnerability – A weakness in the security field of an asset that may be exploited by an attack.

Threat – The means by which a vulnerability of the security field of an asset may be exploited.

Attack – The realization of a threat invoked by a threat agent.

Attack chain – A type of attack that is composed of sub-attacks, sometimes known as a cyber killchain. Most modern attacks are of this type.

Threat agent – A human or automated threat source that invokes an attack, typically intentionally.

Security countermeasure – A means by which a vulnerability is protected from attack. Countermeasures may be passive or active, and may be implemented by design elements, policies, procedures, labeling, training, or obviation. Countermeasure types include the following:

• Access control
• Accounting
• Active detection
• Authentication
• Recovery
• Boundary control
• Backup
• Encryption
• Deterrence
• Obviation
• Nonrepudiation
• Policy action
• Response
• Scanning detection

Role – A part a person plays in a context, such as a user, administrator, or trusted advisor.

Authenticated role – A role with explicit authentication, which typically includes a set of permissions.

Permission – The right or ability to perform an action that deals with an asset. A role may be granted permissions to perform different kinds of access to an asset.

Access – A type of action that can be performed on a resource. This includes the following:

• No access
• Unrestricted access
• Read access
• Modify access
• Open access
• Close access
• Entry access
• Exit access
• Create access
• Delete access
• Remove access
• Invoke access
• Configure access
• Interrupt access
• Stop access

Security violation – The undesired intrusion into, interference with, or theft of an asset; this may be the result of an attack (intentional) or a failure (unintentional).

Risk – The possibility of an undesirable event occurring or an undesirable situation manifesting. Risk is the product of (at least) two values: likelihood and severity. Severity in this case is a measure of the asset value.

Risk Number – The numeric value associated with a risk (likelihood multiplied by severity).

Modeling for security analysis

The UML Dependability Profile used in the previous recipe also includes cyber-physical threat modeling using the previously mentioned concepts. The security information can be captured and visualized in a number of diagrammatic and tabular views. It may be downloaded at https://www.bruce-douglass.com/safety-analysis-and-design.

Security Analysis Diagram

The Security Analysis Diagram (SAD) is a logical causality diagram very similar to the FTA diagram used in the previous recipe. A SAD shows how assets, events, and conditions combine to express vulnerabilities, how countermeasures address vulnerabilities, and how attacks cause security violations. The intention is to identify when and where countermeasures are or should be added to improve system security. This diagram uses logical operations (AND, OR, NOT, XOR, and so on) to combine the presence of assets, asset context, situations, and events. Figure 2.62 shows a typical SAD. You can identify the kind of element by the stereotype, such as «Asset», «Asset Context», «Countermeasure», «Vulnerability», and «Threat»

Figure 2.62 – A typical SAD

Asset diagram

Another useful diagram is the asset diagram. The asset diagram is meant to show the relationships between assets, asset contexts, vulnerabilities, countermeasures, supporting security requirements, and security-relevant design elements. Figure 2.63 shows an asset diagram in use:

Figure 2.63 – Asset diagram

Attack flow diagram

The last diagram of particular interest is the attack flow diagram. It is a specialized activity diagram with stereotyped actions to match the canonical attack chain, shown in Figure 2.64:

Figure 2.64 – Canonical attack chain

The purpose of this diagram is to allow us to reason about how attacks unfold so that we can identify appropriate spots to insert security countermeasure actions. Figure 2.65 shows an example of its use:

Figure 2.65 – Example attack flow diagram

The stereotyped actions either identify the action as a part of the attack chain or identify the action as a countermeasure. The actions without stereotypes are normal user actions.

Tabular views

Tables and matrices can easily be constructed to summarize the threat analysis. The Security Posture Table, for example, is a tabular summary for assets, asset context, vulnerabilities, and countermeasures and their important security-relevant metadata, including Name, Description, Risk Number, Severity, Probability, Consequence, and Impact.

Purpose

The purpose of this recipe is to identify system assets subject to attack, how they can be attacked, and where to best apply countermeasures.

Inputs and preconditions

A use case naming a capability of the system from an actor-use point of view that has been identified, described, and for which relevant actors have been identified. Note: this recipe is normally performed in parallel with one of the functional analysis recipes from earlier in this chapter.

Outputs and postconditions

The most important outcome is a set of requirements specifying how the system will mitigate or manage the security concerns of the system. Additionally, a security posture concept is identifying the need for a set of security control measures, which is summarized in a cyber-physical threat analysis.

How to do it…

The workflow for this recipe is shown in Figure 2.66:

Figure 2.66 – Security analysis workflow

Identify assets and asset contexts

Assets are system or environmental features of value that the system is charged to protect. Assets can be classified as being one of several types, including the following:

• Information: Information of value, such as a credit card number
• Currency: Money, whether in physical or virtual form
• Resource: A capability, means, source, system, or feature of value, such as access to GPS for vehicle navigation
• Physical: A tangible resource that can be physically compromised, threatened, or damaged, such as a gas supply for a medical ventilator
• Service: A behavior of the system that provides value, such as delivering cardiac therapy
• Security: A security measure that can be compromised as a part of an attack chain, such as a firewall

Of course, these categories overlap to a degree, so categorize your assets in a way that makes sense to you and your stakeholders.

Assets are system or environmental features that have value that your system is responsible for protecting. Create one or more asset diagrams to capture the assets and asset contexts. You can optionally add access roles, permissions, and vulnerabilities, but the primary purpose is to identify and understand the assets.

Describe assets and asset contexts

Assets have a number of properties you may want to represent. At a minimum, you want to identify the asset kind and the value of the asset. Asset value is important because you will be willing to spend greater cost and effort to protect more valuable assets. You may also want to specify the asset availability, clearance, or access level required.

Identify vulnerabilities

Vulnerabilities are weaknesses in the system security field; in this context, we are especially concerned with vulnerabilities specific to assets and asset contexts. If you are using known technology, then sources such as the Common Vulnerability Enumeration (CVE) or Common Weakness Enumeration (CWE) are good sources of information.

Note

Refer to https://cve.mitre.org/cve/ and https://cwe.mitre.org/ for further reading.

Specify attack chains

Most attacks are not a single action, but an orchestrated series of actions meant to defeat countermeasures, gain access, compromise a system, and then perform actions on objective to exploit the asset. Use the attack flow diagram or attack scenario diagrams to model and understand how an attack achieves its goals and where countermeasures might be effective.

Create a causality tree

Express your understanding of the causal relations between attacks, vulnerabilities, and countermeasures on security analysis diagrams. These diagrams are similar to FTAs and are used in safety analysis.

Add countermeasures

Once a good understanding is achieved of the assets, their vulnerabilities, the attack chains used to penetrate the security field, and the causality model, you're ready to identify what security countermeasures are appropriate and where in the security field they belong.

Review the security posture

Review the updated security posture to ensure that you've identified the correct set of vulnerabilities, attack vectors, and countermeasures. It is especially important to review this in the context of the CVE and CWE.

Add security requirements

When you're satisfied that the proposed countermeasures, add requirements for them. As with all requirements, these should specify what needs to be done and not specifically how, since the latter concern is one of design.

Add trace links

Add trace links from your security analysis to the newly added requirements, from the associated use case to the requirements, and from the use case to the security analysis. If an architecture already exists, also add trace links from the architectural elements to the security requirements, as appropriate.

Perform a use case and requirements review

This final step of the recipe reviews the set of requirements for the use case, including any requirements added as a result of this recipe.

Next, let's see an example.

Example

For this example, we'll consider the use case Measure Performance Metrics. This use case is about measuring metrics such as heart rate, cadence, power, (virtual) speed, and (virtual) distance and uploading them to the connected app. The use case is shown in Figure 2.67:

Figure 2.67 – Measure Performance Metrics use case

Identify assets and asset contexts

There are two kinds of assets that might be exposed; the login ID and password used during the connection to the app and the rider's privacy-sensitive performance data. The assets of concern are the Ride Login Data and Rider Performance Metrics.

Other use cases potentially expose other assets, such as the Update Firmware use case exposing the system to malware, but those concerns would be dealt with during the analysis of the latter use case.

Describe assets and asset contexts

The asset metadata is captured during the analysis. It is shown in Figure 2.68. Both assets are of the INFORMATION_ASSET asset kind. The Rider Login Data is a high-valued asset, while the Rider Performance Data is of medium value:

Figure 2.68 – Asset metadata

Identify vulnerabilities

Next, we look to see how the assets express vulnerabilities. We can identify three vulnerabilities that apply to both assets: impersonation of a network, impersonation of the connected app, and sniffing the data as it is sent between the system and the app. See Figure 2.69:

Figure 2.69 – Asset vulnerabilities

Specify attack chains

Figure 2.70 shows the attack chain for the Measure Performance Metrics use case. These attack chains show the normal processing behavior along with the attack behaviors of the adversary and the mitigation behaviors of the system:

Figure 2.70 – Measure Performance Metrics attack chain

The attack chain is further decomposed into a call behavior, shown in Figure 2.71:

Figure 2.71 – Process Messages attack chain

Create a causality tree

Now that we've identified and characterized the assets, vulnerabilities, and attacks, we can put together a causality model. This is shown in Figure 2.72 for compromising login data and credentials:

Figure 2.72 – SAD for rider login data

We also have a casualty model in Figure 2.73 for the rider metric data:

Figure 2.73 – SAD for rider metric data

Add countermeasures

We can see in the previous two figures that our causality diagram has identified two security countermeasures: the use of credentials for Bluetooth connections and the addition of encryption for message data.

Review the security posture

In this step, we review our security posture. The security posture is the set of assets, asset contexts, vulnerabilities, and countermeasures. In this case, the assets are the rider login data and the rider metrics data. The login data includes the username and password. The metrics data includes all the metrics gathered, including speed, distance, elapsed time, date and time of workout, power, cadence, and heart rate.

There are two asset contexts: the system itself and the phone hosting the app. The latter context is out of the system's scope and we have limited ability to influence its security, but we can require the use of the protections it provides. Notably, this includes Bluetooth credentials and the encryption of data during transmission. Other use cases may allow us better control over the security measures in this asset context. For example, the Configure System use case uses a configuration app of our own design that we can ensure stores data internally in encrypted form; we have no such control over the third-party training apps.

We have identified three vulnerabilities. During login, the system can be compromised either by network or app impersonation. By pretending to be a trusted conduit or trusted actor, an adversary can steal login information. We address these concerns with two explicit countermeasures: message encryption and the use of credentials. Security could be further enhanced by requiring multi-factor authentication, but that was not considered necessary in this case. During rides, the system transmits metric data to the app for storage, display, and virtual simulation. An adversary could monitor such communications and steal that data. This is addressed by encrypting messages between the system and the app.

Add security requirements

The security requirements are simply statements requiring the countermeasure design and implementation. In this case, there are only two such requirements:

• The system shall require the use of a Bluetooth credentials agreement between the system and the app to permit message traffic.
• The system shall encrypt all traffic between itself and the app with at least 128-bit encryption.

Add trace links

The new requirements trace to the Measure Performance Metrics use case. Further, trace links are added from the countermeasures to the requirements, linking our analysis to the requirements.

Perform a use case and requirements review

We can now review the use case, functional analysis, and dependability analyses for completeness, accuracy, and correctness.