Trike Threat Modeling as a Risk-Management Tool

With everything moving online, it has become necessary for organizations to stay up to date on the latest cybersecurity threats to their organization. A cybersecurity threat is any malicious activity whose intent is to damage or disrupt digital systems. Common cyber threats include computer viruses, data breaches, and Denial of Service attacks. This is where threat modeling, an important component of the Cyber Threat Intelligence program, comes into play. Threat modeling is a risk analysis method where potential threats are identified, enumerated, and countermeasures developed. The primary purpose of threat modeling is to provide a systematic analysis of what needs to be included in the policies formed to mitigate the threat.

Now that you realize the need for it, how does one go about threat modeling? Currently, there exist numerous threat modeling methodologies, each with its pros and cons. These can be combined in order to provide a more complete overlook of the entire system. One of the major keys to an effective risk management policy is the identification of risks relative to business goals and assets.

Why Trike?

Trike is a unified methodology for carrying out security threat modeling. This is accomplished through the generation of threat models from a risk management perspective. This allows for a more accurate description of the system from the lowest technologies to the highest architecture. Trike is divided into the following stages:

Requirement Model

In this stage of the model process, an understanding of the user application is developed. The security team looks at the people interacting with the system, the things it interacts with, and the actions it is expected to support. The actors are the people and members of staff who interact with the system. This must be in the scope of security threats. The security analysis assets are the data entities or physical objects catered for in the system’s business rules. Actions are things done to assets by the business processes. These are defined to gain an understanding of the system. This is used to generate an Actor-Asset-Action matrix representing and analyzing the modeling process’ requirement model.

Risk Assessment

Once a full understanding of both the application’s implementation and capabilities are determined, a threat model can be generated. This is used to analyze the various risks to the application’s security. The application’s execution is researched for flaws in the technologies and components used to create the system. Once all the potential threats have been identified, the security team begins creating an attack graph and examining the system’s actual vulnerabilities.

Data Flow Diagram

Once the threats have been assessed, there needs to be a reconstruction of how the vulnerabilities would affect the system and its assets. This can be reconstructed using data flow diagrams. The data flow diagram entities could consist of processes, data stores, the flow of data, and external interactions with the environment and external entities. The top level of the DFD would consist of every actor and processes used by the system. As the DFD expands in the lower levels, trust boundaries need to be defined, with the markup being defined to capture as much necessary information as possible.

Assigning Risk Values

Once a DFD has been created, associated risk values can be calculated based on the threat’s severity. An analysis of the impact of the vulnerability on the entire system can rank the vulnerabilities. Using this, the organization’s security team can know what to focus on and what is not urgent. Once the risk values have been assigned, it becomes possible to generate a conclusive security vulnerability report on the application. Policies and mitigations can then be implemented to counter the highlighted threats.

Source: eccouncil.org