When performing a TARA; threats and controls that should be considered are stored within their corresponding catalog. Unlike the threat catalog that has a variety of different well-defined formatting structures such as STRIDE, MITRE, or Killchains. The control catalog does not have a popular format. This can make it difficult to maintain as the lack of format means that additional entries can only increase the complexity of the catalog and make queries difficult to perform.
While there is currently no established or documented format for the control catalog; there are some best practices that you can follow in order to keep the catalog organized and obtain the most utility from it.
Control Catalog Properties
Within itemis SECURE, the control catalog has the following properties per instance:
- Protects
- Protects Against
- Architecture
- Technologies
- Assumption Classes
- Attack Feasibility
- Refines
Protects
A 1:N relationship that demonstrates which security property the control protects. Within ISO21434; this could be Confidentiality, Integrity, or Availability.
Protects Against
A 1:N relationship that denotes specific threats that the control mitigates. The potential options for this property will entirely depend on the threat catalog.
Architecture
Another 1:N relationship that provides a tag functionality for architecture. Selections for this tag include component, data flow, channel, and data. When a control is paired with an architecture tag; it will always be considered as a potential control within the assistants of itemis SECURE.
Technologies
A 1:N relationship that tags a control as applicable to a particular type of technology. This works in a similar manner to the architecture property, but you are able to customize what types of technology can be tagged through the technology catalog.
Assumption Classes
A 1:N relationship that allows the user to define assumptions that can be made for the threat and subsequent control. Assumptions within the TARA process are used to cover a variety of external factors that are difficult to organize. These factors can include an attack only being possible at run time, an attack requiring specific insider knowledge not available to the general populace, or a declaration that the attacker has already tried one method, and is now attempting another.
Attack Feasibility
A 1:1 relationship that provides numerous different categories to rate the feasibility changes that occur when the control is active. It is possible to modify each of these categories individually or even remove the categories as a whole and simply state that the control makes any threat that runs into it impossible to perform.
Refines
Another 1:N relationship. The refine property allows you to create a parent control and then set children to inherit the values from this parent. This is quite helpful if you are using multiple different types of encryption, but the properties from all of them will be largely the same. In this instance you could simply make one encryption control, set up the default properties, and then have specific instances such as AES refine this encryption class. Then you could make the changes to properties that are specific to AES.
Best Practices
While there is no traditionally outlined model for the control catalog, there are some choices that you can make to make the catalog more manageable, including:
- Using the refine attribute to establish genres of controls
- Minimize redundancy in controls
- Organize control list through their naming conventions
- Complete configuration of other TARA aspects before working on the control catalog
By following these practices, the control catalog can remain as concise as possible while maintaining the maximum amount of utility from its inclusion.
Comments