Threat Modeling: General Overview and Guideline of the OCTAVE Method in Cybersecurity

During a technical cybersecurity review, it is not unlikely that someone missed something; a vulnerability that is overlooked in their object of analysis. Without a proper process with purposeful methods, it would be very difficult to minimize the number of mistakes made. This is where threat modeling and the OCTAVE method can come into play during a technical security review.

What is Threat Modeling?

Threat modeling is a process of creating a model around the object of analysis, specifying its operating components, to identify and understand possible attack vectors while categorizing the risk found by their impact, likelihood, recreation, and mitigation difficulty. After understanding all the risks found, the technical team can move on to create countermeasures, starting with the most potent and repeatable vulnerability exploits.

One of the most important factors of threat modeling is knowing the general structure of the target through data flow diagrams (DFD) to understand how each operating component connects with each other and the data flows through them. Using a DFD of a web application in Figure 1 as an example, it is possible to see which component acts as a bridge between the user and the database server, along with the types of data being transmitted. 

Currently, there are many different methods and standards used for threat modeling. Noteworthy and popular names include STRIDE, DREAD, and OCTAVE. STRIDE is the most well-known standard used to help categorize the threats found within a system. Accompanying STRIDE is DREAD, which is used to score those threats by their damage, repeatability, severity, and more. STRIDE has been known to be less used as a threat modeling method and is created with a pure security view, which might hinder business operations and desired functions. While DREAD is considered to be outdated, as well as inconsistent with their scoring. These flaws led to the creation of OCTAVE. 

What is the OCTAVE method?

OCTAVE is an acronym for Operationally Critical Threat, Asset, and Vulnerability Evaluation. Its development was primed due to the need for organizational priorities to be included along with technological requirements during technical assessments. At the time, the developers considered other threat modeling approaches uncomprehensive and lacking organizational involvement. OCTAVE was also developed with strategic issues in mind rather than tactical, meaning it attempts to have an overview of a significantly longer time frame. Other methods were also created to be used solely by outside experts. This method allows for self-direction for the organization to make its evaluations to be later used in security decisions. 

OCTAVE categorizes its three main elements of concern into the following:

• Threat: they are potential actions that could exploit vulnerabilities and harm assets.

  • Internal threat: threats coming from inside the organization, be it intentional or not.

  • External threat: threats coming from outside the organization.

• Assets: resources that hold value to the organization and require protection.

  • Informational: includes objects like sensitive data and confidential documentation.

  • Infrastructure: physical devices and equipment that form the organization’s IT operations.

  • Human: employees within the company who may protect or damage the system.

  • Critical: most important assets among the previously identified assets.

• Vulnerabilities: generally, technological weaknesses within the operational systems.

  • Organizational: vulnerability that exists outside of technologies and inside the organizational structure itself.

  • Technological: vulnerability in either the hardware property or software configuration of a device or system.

The threat modeling phases of OCTAVE are as follows:

• Phase 1: Build Asset-Based Threat Profiles. Using staff knowledge from multiple organizational levels along with a standard information catalog of threats and practices, the analysis team can categorize and discover assets, threats, and security requirements of the organization.

• Phase 2: Identify Infrastructure Vulnerabilities. Rechanneling the information created after the first phase into this phase to be combined with infrastructure components to result in the understanding of which are high-priority components, existing misconfigurations, malpractices, and vulnerabilities.

• Phase 3: Develop Security Strategy and Plans. This is where the organization uses the previously organized information to decide its next course of action. Addressing risks with mitigation plans and coming up with protection strategies are all part of this phase.

What is the OCTAVE Criteria?

The OCTAVE Criteria is a set of outputs and principles followed by their attributes. It was created as a standard to guide the evaluation process and for the organization to understand the results. It contains requirements needed to make OCTAVE, or other methods that follow this criteria, a self-directed method of threat modeling.

The three main categories of the OCTAVE Criteria are as follows:

• Principle: It is the fundamental basis and purpose of an evaluation.

• Attribute: it is a distinctive characteristic that works as a requirement and an evaluation’s success indicator.

• Output: it works as an objective or result requirement of each evaluation phase to help the team understand what their analysis must achieve during them. 

Case Study

Willow Creek University was looking to deploy a web application called MediaWiki on their intranet to help regulate information about their various newly built and existing facilities, as well as past events they have hosted at those locations. During their security analysis process, they opted to use the OCTAVE method for threat modeling to understand critical assets and how they could be vulnerable.  

Deriving from the Level 1 DFD (Figure 1), a more detailed DFD Level can be drawn to specify types of data flows that may occur during the web application’s usage. One type of request that both a normal user and the administrator can make is query-type requests. Through MediaWiki’s documentation, the development team can figure out which application features send these types of requests and draw an appropriate DFD Level 2 (Figure 5). 

Using that DFD Level 2 as a base, the security team is able to pinpoint threats that may happen due to that specific request. After listing all the threats that they are aware of, they can rank the threats by their risk severity and repeatability. A general description of the threat is also given to help Willow Creek University’s non-technical teams to further involved in the threat modeling process. Figure 6 provides the first three table entries of the threats found based on DFD Level 2 – Query-type Requests (Figure 5). 

Once the risks are listed, the security team can use their knowledge along with open-source information to come up with a mitigation strategy appropriate to the threat listed. The ID numbers are used to help connect the threat table and the mitigation strategy table. This can be seen using Figure 7, where the threat name column is used to further connect with the threat table in Figure 6. 

The OCTAVE report produced as a result of the process allowed Willow Creek University’s development team to have a detailed understanding of the organization's priorities, existing threats, and appropriate countermeasures. It led to a successful and secure deployment of MediaWiki while being operational to the specific needs of the university. 

Conclusion

Threat modeling is an essential part of a technical cybersecurity review. It helps remove the chances of overlooking vulnerabilities and risks. The OCTAVE method introduces step-by-step instructions to be deployed on a full scale, as well as incorporates organizational needs into security analysis. The OCTAVE Criteria provides expected results and works as a success confirmation. Not using the OCTAVE method could lead to lackluster or unsuccessful threat modeling, and without threat modeling in general, it is likely impossible to know if the object of analysis is secure.