What Every Engineer Should Know About Threat Risk and Trike

Trike is an open source threat modeling methodology with a distinct threat rating component. It delves beyond threat modeling and into "attack graph[ing]," requiring extensive parsing and detail. For threat rating purposes, however, it is much simpler. In the world of Trike, every attack falls into one of two attack types: elevations of privilege...
  • Trike is an open source threat modeling methodology with a distinct threat rating component. It delves beyond threat modeling and into "attack graph[ing]," requiring extensive parsing and detail.

    For threat rating purposes, however, it is much simpler. In the world of Trike, every attack falls into one of two attack types: elevations of privilege or denials of service. (This solves the cross-correlation problems presented by the more simplistic -- and more redundant -- STRIDE, as discussed in the earlier CRC Press News.)

    With this in mind, Trike assesses the risks of these attacks impacting assets presented by four specific actions, comprising the acronym CRUD:

    • Creating

    • Updating

    • Deleting

    (The creators of Trike acknowledge that a fifth and "exotic" action, "invoking," is possible -- and thereby assessable -- in an environment that "is specifically intended to move around code and execute that same code as part of the core function of the system." But they spend no more than a paragraph discussing and quickly dismissing it because of the rarity of the situation.)

    A threat rating chart using Trike will list all possible assets connected with the system being assessed; external assets are included as well. For each asset, the risk of either attack type is assessed on a five-point scale for each CRUD action.

    Trike also takes human actors into account -- such as an administrator, an account holder or an anonymous user or reader. Separately, actors are rated on a five-point scale for the risk they are assumed to present to a system based on trust. A trusted administrator with full privileges, for example, would get a rating of one, whereas an anonymous user with the most limited access would get a high rating. They are also rated on a three-point scale – always, sometimes, never – for each of the CRUD actions they have access to perform upon each asset. Five-point scales are used throughout the threat modeling aspects of Trike, as well (for instance, for assessing weaknesses).

    Trike threat modeling is a unique, open source threat modeling process focused on satisfying the security auditing process from a cyber risk management perspective. It provides a risk-based approach with unique implementation, and risk modeling process. The foundation of the Trike threat modeling methodology is a “requirements model.” The requirements model ensures the assigned level of risk for each asset is “acceptable” to the various stakeholders.

    With the requirements model in place, the next step in Trike threat modeling is to create a data flow diagram (DFD). System engineers created data flow diagrams in the 1970s to communicate how a system moves, stores and manipulates data. Traditionally they contained only four elements: data stores, processes, data flows, and interactors.

    The concept of trust boundaries was added in the early 2000s to adopt data flow diagrams to threat modeling. In the Trike threat modeling methodology, DFDs are used to illustrate data flow in an implementation model and the actions users can perform in within a system state.

    The implementation model is then analyzed to produce a Trike threat model. As threats are enumerated, appropriate risk values are assigned to them from which the user then creates attack graphs. Users then assign mitigating controls as required to address prioritized threats and the associated risks. Finally, users develop a risk model from the completed threat model based on assets, roles, actions and threat exposure.

    However, because Trike threat modeling requires a person to hold a view of the entire system to conduct an attack surface analysis, it can be challenging to scale to larger systems.

    Trike was created as a security audit framework that uses threat modeling as a technique. It looks at threat modeling from a risk-management and defensive perspective.

    As with many other methods, Trike starts with defining a system. The analyst builds a requirement model by enumerating and understanding the system's actors, assets, intended actions, and rules. This step creates an actor-asset-action matrix in which the columns represent assets and the rows represent actors.

    Each cell of the matrix is divided into four parts, one for each action of CRUD (creating, reading, updating, and deleting). In these cells, the analyst assigns one of three values: allowed action, disallowed action, or action with rules. A rule tree is attached to each cell.

    After defining requirements, a data flow diagram (DFD) is built. Each element is mapped to a selection of actors and assets. Iterating through the DFD, the analyst identifies threats, which fall into one of two categories: elevations of privilege or denials of service. Each discovered threat becomes a root node in an attack tree.

    To assess the risk of attacks that may affect assets through CRUD, Trike uses a five-point scale for each action, based on its probability. Actors are rated on five-point scales for the risks they are assumed to present (lower number = higher risk) to the asset. Also, actors are evaluated on a three-dimensional scale (always, sometimes, never) for each action they may perform on each asset.

    Trike is a unified conceptual framework for security auditing from a risk management perspective through the generation of threat models in a reliable, repeatable manner. A security auditing team can use it to completely and accurately describe the security characteristics of a system from its highlevel architecture to its low-level implementation details.

    Trike also enables communication among security team members and between security teams and other stakeholders by providing a consistent conceptual framework. This document describes the current version of the methodology (currently under heavy development) in sufficient detail to allow its use. In addition to detail on the threat model itself (including automatic threat generation and attack graphs), we cover the two models used in its generation, namely the requirements model and the implementation model, along with notes on risk analysis and work flows. The final version of this paper will include a fully worked example for the entire process. Trike is distinguished from other threat modeling methodologies by the high levels of automation possible within the system, the defensive perspective of the system, and the degree of formalism present in the methodology. Portions of this methodology are currently experimental; as they have not been fully tested against real systems, care should be exercised when using them.

    The focus of the Trike methodology is using threat models as a risk-management tool. Within this framework, threat models are used to satisfy the security auditing process. Threat models are based on a “requirements model.” The requirements model establishes the stakeholder-defined “acceptable” level of risk assigned to each asset class. Analysis of the requirements model yields a threat model from which threats are enumerated and assigned risk values. The completed threat model is used to construct a risk model based on asset, roles, actions, and calculated risk exposure.

    Trike is a threat modeling framework with similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models, instead of using the STRIDE/DREAD aggregated threat model (attacks, threats, and weaknesses). Trike’s goals are:

    • With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.

    • Be able to tell whether we have done this.

    • Communicate what we’ve done and its effects to the stakeholders.

    • Empower stakeholders to understand and reduce the risks to them and other stakeholders implied by their actions within their domains.

Source: www.crcpress.com