Layer 2
Threats & Controls
Building upon the high-level assessments that produce Vectors and Guidance, organizations and consortiums both frequently execute Risk Assessments that remain in the hypothetical realm — not yet considering a Risk Catalog, but instead focusing on technology-specific Threat-informed Controls with Objectives that are supported by clear Assessment Requirements. Similar to the activities described in Layer 1, these are hypothetical Risk Assessments which can be fully operationalized later, in the context of the organization’s Risk Catalog.
The frequent overloading of Threat and Control terminology in the information technology ecosystem has caused ambiguity. When generic and specific assets are produced, they are both frequently referred to as Controls, causing disparate outcomes and inconsistent quality in Policies. The definitions for Threats and Controls provided in Section 2 are selected from the many different ways these terms are used.
Threats, ideally, 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 should 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 CCC, and the OSPS Baseline.
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 (FINOS CCC) “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.