In the previous two posts we discussed Threat Modeling with Open FAIR^TM and Threat Modeling using ArchiMate^TM. The natural next step is to consider how to integrate all three methods. The FAIR risk analysis example used in this section is constructed using ArchiMate. Use the ArchiMate Specification Reference Cards to understand the symbology. The risk analysis example used in this section is found in Section 2.2 of the Open FAIR Risk Analysis Example Guide. The following image depicts the FAIR Taxonomy with relevant narrative from the Example Guide.

Member of cleaning crew using the authentication credentials written on the sticky-note to log into the HR executive’s computer and gaining unauthorized access to the information they are intended to protect.

Each image in the following shows a portion of the FAIR Taxonomy depicted in ArchiMate. The Distribution notes display Properties contained in the Assessment (a Motivation Element – Represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.) The Distribution values are the Minimum, Most Likely and Maximum values recorded as percent values.

This example shows how a FAIR model can be constructed using ArchiMate. The benefit of this approach is that the FAIR model can be added to views of existing ArchiMate models developed by enterprise architects within an organization. In this way, proposed control improvements can be directly related to the components of the architecture that are being adjusted. Thus, the benefits relate to the entire enterprise architecture, not just one application as is the case with current threat modeling approaches. For example, consider the possible views:

• Enterprise
• Multiple application systems
• Shared infrastructure components
• Mapping all system related to each enterprise risk
• Relate components to infrastructure security control requirements

Of course, this benefit cannot be realized until there is a capability with ArchiMate to perform the math associated with FAIR.

This series aimed to ensure understanding by providing Definitions – architecture, FAIR and threat modeling terms, and demonstrate threat model example using ArchiMate – diagram views, control analysis with FAIR.

Return to Introduction

4 – Leveraging Assessment Management

Risk Management, Policy Management, Assessment Management and Incident Management are the four components of an Information Security Management System described in How to Manage Cyber Security Risk – A Security Leader’s Roadmap with Open FAIR. “The ideal is to deliver a periodic census of the security requirements compliance status for all instances of all controls.” This post will briefly examine measuring compliance status for the infrastructure and applications in scope for an enterprises’ risk analysis. This data helps inform estimating risistance strength for a FAIR analysis of relevant enterprise risk. Content of the next two sections are from How to Manage Cybersecurity Risk.

Assess Hosts and Networks

Compliance tests for hosts can be performed by vendor-provided or locally developed tools which are implemented to fulfill the control testing requirements. Requirements involving computing and network hardware drive inspection to test implementation. The assessment management system also receives periodic updates to control requirements, including occasional immediate change notifications. Obviously, these updates also need to trigger changes to the assessment tests. Less obvious is the need for assessment status reporting to distinguish when requirement changes have occurred. For example, a control may have been in compliance for many months, then suddenly fall out of compliance. The reader should easily understand the cause of non-compliance is the requirement change, and perhaps have indication of the schedule for bringing the control into compliance. {words about how this is used in risk analysis}

Assess Applications

Assessing applications ties directly to the security development life cycle. Manual or automated testing is used in the latter stages of development to discover or confirm the absence of security defects. These testing methods change over time in response to discoveries of potentially common code weaknesses, so periodic retesting is prudent. Compliance reporting can summarize quantities and severities of assessment findings with corrective action due dates. Security control requirements can mandate corrective action timelines based on severity. One challenge today is associating severity ratings from testing tools to the organization’s quantitative risk analysis. Consider the difference between an application that has users only within the organization’s intranet compared with an Internet-facing application: the threat event frequency is vastly different.

Host and Network Security Compliance

Security policy for hosts and networks specifies conditions that must be met. Compliance testing, automated where possible, measures server and network component instances to confirm compliance or to gather data about the non-compliant state. The test results are provided in human readable dashboards, from high-level summaries to the most minute drill-down detail.

An enterprise FAIR analysis may have a scope that includes all instances of the enterprise’s servers and networks, or may be a subset. For example, if the risk is related to the availability of customer-facing services, only the compliance testing results for the servers and networks related to the customer-facing service are relevant.

There are two characteristics to consider when estimating Resistance Strength (RS) for the FAIR analysis. First, estimate the RS based on the design specified in the security control requirement. Next, estimate how the RS is degraded by the non-compiant instances.

Now the organization has a basis to compare RS for the required compliance to the actual degradedation from non-compliance. A corrective action plan for the non-compliance state can be estiblished and its costs estimated. This can be compared to the difference between the expected risk and the actual risk (accounting for non-compliance), thereby providing a business case.

Application Security Compliance

Security policy for applications is integrated in the enterprise’s standard application development process, regardless of the methodology involved. The confidentiality, integrity and availability requirements muct be specifically defined. For example, a requirements phase includes considerations like what information requires access controls and what types of users are permitted which kind of actions. In addition, there are requirements to ensure the strength of interfaces, particularly user-system interfaces. Threat modeling is one technique that can be incorporated in the enterprise’s standard application development process.

Ideally, as each requirement is instantiated in the system design, a test is defined to exercise the requirement. There are also vendor-provided testing tools that mimic threat actions.

In contrast to host and network compliance testing, which is performed periodically, application security compliance testing is performed as a part of the development and maintenance life cycles. Similar to host and network compliance testing, the application security compliance testing can be displayed in dashboards with drill-down capability. One essential design for compliance reporting is that the enterprise maintain application and host inventories indexed to each other, to enable non-compliance resolution, particularly where a non-compliant host configuration is necessary based on the hosted application, which must be modified to resolve the issue.

Just as with host and networks, there are two characteristics to consider when estimating Resistance Strength (RS) for the FAIR analysis. First, estimate the RS based on the design specified in the security control requirement. Next, estimate how the RS is degraded by the non-compiant instances.

Now the organization has a basis to compare RS for the required compliance to the actual degradedation from non-compliance. A corrective action plan for the non-compliance state can be estiblished and its costs estimated. This can be compared to the difference between the expected risk and the actual risk (accounting for non-compliance), thereby providing a business case.

Implication for Threat Modeling with ArchiMate and Open FAIR

Threat Modeling can be an important technique in the development of an application, providing a view of the security posture of an application. But on its own, threat modelng cannot support developing a business case for enterprise security control improvements.

Application systems rely on host and network security which are ideally managed organization-wide, with a single security control compliance monitoring system employed. These elements can and should be included in threat models. Standard ratings can be established so the threat modeling team need only be concerned with applications’ user and component interfaces.

What remains are interactions among processes and external interactions. It would appear that the more these interactions can be standardized, the fewer instances of relative resistance strength (RS) need to be understood. Where the RS is too low relative to a FAIR scenario, it now becomes possible to identify the organization-wide cost to improve RS to have a business case for enterprise risk reduction.

Summary and Next Steps

These ideas are provided as inspiration for improving the ability of threat modeling to influence enterprise funding for risk reduction projects. Readers are encouraged to provide suggesting to improve accuracy and clarity.

Should the concept be supported, the next step is to propose an Open Group Security Forum project potentially titled: Threat Modeling with ArchiMate and FAIR Guide. I recommend the project be lead by the Security Forum and to be a joint project with the ArchiMate forum.

Back to Introduction

In the last post we discussed how the STRIDE attack categories, which developers use to find ‘threats to our products’, can be integrated with Factors Analysis of Information Risk (FAIR). Now we will deal with the issue some developers may face when they have already used their enterprise system design modeling method then are faced with having to essentially duplicate that effort building a threat model. The following describes a potential alternative.

ArchiMate^TM is defined by the ArchiMate Specification Standard (ArchiMate 3.1 Specification). The document’s objective explains that “…the ArchiMate Enterprise Architecture modeling language (is) a visual language with a set of default iconography for describing, analyzing, and communicating many concerns of Enterprise Architectures as they change over time. The standard provides a set of entities and relationships with their corresponding iconography for the representation of Architecture Descriptions.”

It goes on to introduce that “The ArchiMate Enterprise Architecture modeling language provides a uniform representation for diagrams that describe Enterprise Architectures. It includes concepts for specifying inter-related architectures, specific viewpoints for selected stakeholders, and language customization mechanisms. It offers an integrated architectural approach that describes and visualizes different architecture domains and their underlying relations and dependencies. Its language framework provides a structuring mechanism for architecture domains, layers, and aspects. It distinguishes between the model elements and their notation, to allow for varied, stakeholder-oriented depictions of architecture information. The language uses service-orientation to distinguish and relate the Business, Application, and Technology Layers of Enterprise Architectures, and uses realization relationships to relate concrete elements to more abstract elements across these layers.”

Here are a few key terms:

Attribute – A property associated with an ArchiMate language element or relationship.

Layer – An abstraction of the ArchiMate framework at which an enterprise can be modeled.

Consider that developers in organizations using ArchiMate may be required by their security group to model their system again using a threat modeling tool. The underlined text above suggests that it is possible to use ArchiMate to prepare a Threat Model view for an enterprise architecture, using available Custom Properties for recording threat model attribute data.

I participated in a few meetings between the Open Group’s Security Forum and the ArchiMate Forum that demonstrated how the robust ArchiMate capabilities including Attributes and Layers can be used to model a FAIR analysis.  I understand it is possible to augment current ArchiMate capabilities to perform quantitative FAIR analysis. It seems likely that ArchiMate capabilities can be extended to analyze Threat Models.

While the two modeling approaches result in different looking diagrams, they capture the same information. The key difference is that the Microsoft tool individually depicts the to and from logical communications between processes, where ArchiMate records the communication-related attributes with the processes themselves and depicts the Communication Network as a separate element.

We’ll close with the premise that ArchiMate can potentially be augmented to perform threat modeling analysis. Using ArchiMate for threat modeling can reducing potentially duplicate modeling by the development team (assuming they use ArchiMate through the development process).

Back to Introduction

3 – Threat Modeling using ArchiMate with Open FAIR

This series applies “the STRIDE approach to threat modeling (which) was introduced in 1999 at Microsoft, providing a mnemonic for developers to find ‘threats to our products’. STRIDE, Patterns and Practices, and Asset/entry point were amongst the threat modeling approaches developed and published by Microsoft. References to “the” Microsoft methodology commonly mean STRIDE and Data Flow Diagrams.” (https://en.wikipedia.org/wiki/Threat_model ).

Factors Analysis of Information Risk (FAIR) is defined in the Open Risk Taxonomy and Open Risk Analysis Standards (https://www.opengroup.org/forum/security/riskanalysis ). Related Guides, White Papers and Tools are also available. This post relies on your previous knowledge of both FAIR and Threat Modeling.

FAIR is designed to analyze enterprise risks, such as theft of intellectual property or loss of revenue due to ransomware attacks affecting online services. By contrast, threat modeling is typically scoped to individual application systems. While threat modeling is helpful in identifying potential mitigations for expected threats given the current system design, it lacks a means to quantify the value of the mitigations’ risk reduction.

The following shows how threat modeling concepts relate to FAIR. This article introduces the idea of how threat modeling concepts can be related to enterprise risk analysis with FAIR.

The Microsoft Threat Modeling Tool contains a stencil for objects which have attributes with selections (often yes/no) that vary by attribute. Attribute labels (e.g., different communications protocols) have different attributes lists). The Tool scans the model to produce a Threat View based on analyzing the model. STRIDE is the acronym for the categories of attack techniques employed during Threat events on applications systems.

At the beginning of threat modeling, it is assumed that no Mitigations are in place. From a FAIR perspective, mitigations increase Resistance Strength thereby reducing Vulnerability (which is proportional to the Threat Capability).

The FAIR enterprise view begins with identifying the (few) risk scenarios. Each scenario identifies potential losses and the associated threat, leading to baseline calibrated estimates of Threat Event Frequency and Threat Capability along with Loss Magnitude, all stated as ranges of values.

Threat intelligence may help guide which STRIDE techniques are associated with a threat actor; it may also provide insight necessary to develop a calibrated estimate of Threat Capability which is recorded as a scalar value of 0-99. Also needed is a library of Mitigations with associated Resistance Strength, also recorded as a scalar value of 0-99.

Analyzing Example Enterprise Risk

The following are example brief risk titles followed by a structured description statement.

1. PI Theft – Theft of propriety information resulting in loss of competitive advantage
2. Online Disruption – Disruption of online service resulting in lost revenue and added PR costs

The risk analysist can work with appropriate business and technical experts to decompose the risk statements into calibrated FAIR estimates and STRIDE categories. The values in the following table illustrate the results but are examples not intended to represent calibrated estimates for a specific business scenario.

The following shows PI Theft risk factor inputs to the FAIR Tool for an information disclosure STRIDE category. The values for Threat Capability and Resistance Strength are arbitrary 5% above and below the values from the table above. The analysis includes a proposed improvement that increases Resistance Strength by 1%.

The following shows the FAIR Tool risk analysis results. Notice the chance of loss exceeding $5M is 43% for the current situation and is reduced to 23% with the proposed control improvement.  The average loss is reduced from about $5M per year to about $3M per year, and average risk reduction is about $1.8M annually. A business case can be made for the control improvement project in relation to this risk reduction.

Back to Top

2 – Threat Modeling using Archimate

The security development lifecycle, including threat modeling, is a concept described by Microsoft around 2006 in a book of that title. While use of the threat modeling technique typicall produces recommended improvements to the code and supporting infrastructure, it lacks the means of providing financial justification for the sometimes significant cost for making improvements. It is notable that nobody owns the threat modeling technique, so evolution is likely occuring down various paths.

This series of posts explores threat modeling as it could relate to standard methodologies published by The Open Group. The goal:

Improving Justification for Mitigations identified by Threat Modeling

• 1 – Threat Modeling with Open FAIR
• 2 – Threat Modeling using ArchiMate
• 3 – Threat Modeling using ArchiMate and Open FAIR
• 4 – Leveraging Assessment Management