Layer 2
Threats & Controls
Before a policy is ready to be fully implemented, it must contain a set of threat-informed control objectives which are supported by clear assessment requirements.
As the previous section alluded, Threats and Controls often draw from previous work and form the core elements of a risk-based organizational policy. Ambiguity persists, however, due to the overloading of this terminology in the information technology ecosystem. The following definitions are selected from the different ways these terms are used, and within the context of the model they each have a single definition.
Threats are specifically-scoped opportunities for a negative impact to the organization. Ideally, a threat will draw from known vectors and be mapped to a specific factor such as a capability, location, or action, so that it is clear precisely when or where the threat can be expected to manifest. They may be associated with a specific scenario, business unit, or technology, making them ideal for helping inform organizational policies. In this way, controls can be marked for exclusion if the corresponding factor is no longer present.
Controls are specifically-scoped safeguards or countermeasures containing a clear objective. It will ideally build upon established guidance, and contain assessment requirements that can be directly implemented by evaluators. These are typically developed by an organization for its internal use, or for general purpose by industry groups, government agencies, or international standards bodies. Examples include CIS Benchmarks, FINOS Common Cloud Controls, and the Open Source Project Security (OSPS) Baseline.
 References Threats and [Guidance](02-definitions.html#guidance)](/assets/model-images/figure-5.1-light.png)
 References Threats and [Guidance](02-definitions.html#guidance)](/assets/model-images/figure-5.1-dark.png)
While controls are traditionally delivered in topical batches as control catalogs, there is an emerging trend toward composability, which defines reusable agnostic controls for information systems. These are almost like guidance in their generic prose, but with assessment requirements that are detailed enough to serve as Layer 2 assets. An example of this can be seen in the FINOS Common Cloud Controls “Core Catalog,” which contains both threat and control definitions that are later imported into technology-specific catalogs.
The recommended process to create a control catalog for an information system is to first assess the technology’s capabilities, then identify threats to those capabilities, and finally develop a set of controls to mitigate those threats. However, it is not uncommon for an organization to write controls first based on the author’s experience, and then later backfill threats to solidify a justification or rationale for those controls.