The controls required for implementation and subsequent assessment are selected based upon the anticipated risk stemming from one or more threats. In many instances, the perceived risk directly correlates to the observation of occurrences of the activities associated with a threat as those activities become known. It is not reasonable, though, to presume that the frequency of occurrence of threat activities in the various kill chains relevant to these threats remains static. Rather, it is widely understood that certain threat activities occur more frequently or less frequently over time. The relative importance of a particular threat or threat activity may also change over time, and there may be other factors that contribute to its importance as well. Consequently, the ability of an organization to address these threats, and the corresponding assurances provided by assessment, can become less effective or meaningful over time.
To illustrate, the figure on the next page provides a basic example of the CTA approach applied to an assessment.
With respect to the figure, a control specification for an organizational assessment (100) specifies different threats (150), and each of these prospective threats is modeled with one or more kill chains (140A, 140B, … ,140n-1, 140n). Each of these activities could include ‘meta-data’ such as the frequency, probability of success, criticality, and other relevant information associated with the activities. Further, each of the prospective threats (150) are mapped to a corresponding set of one or more controls (110), each of which mitigate at least one of the threat activities (140A, 140B, … , 140n-1, 140n) in a related kill chain for one or more of the threats (150).
Threat intelligence (120) is received periodically and includes a listing of observed threat activities (140A, 140B, 140n-1, 140n), which is subjected to analysis (130). The resulting statistical analysis (160) includes, for example, a frequency distribution of the observed threat activities (140A, 140B, … , 140n-1, 140n) or, in a more complex implementation, an analysis of the frequency distribution of threat intelligence (120) received and stored over time (not shown).
To the extent the statistical analysis (160) indicates a threshold change in the observation of one of the threat activities (140A, 140B, … , 140n-1, 140n), a threat modeler (180) may propose a control set modification (170) for the controls (110) specifically mapped to one or more threat activities to address potential changes in the probability of a threat occurrence implicated by the observed statistical characterization of the threat activity. Modifications could include:
- A change to one or more parameters to existing controls (110), e.g., reducing the number of failed login attempts before locking out a user account;
- Enhancement of one or more existing controls (110), e.g., additional audit logging requirements for a server;
- Replacement of one or more existing controls (110), e.g., requiring the white-listing of approved websites rather than black-listing prohibited websites; and
- The addition of one or more new controls (110), e.g., adding bias-related controls to existing integrity controls.
Figure 21. Notional Implementation of CTA
Many of the elements in the CTA process outlined above could be performed manually; however, HITRUST automates the overall process as much as practicable.
The figure on the following page helps illustrate the logic for modifying a control specification used for an assessment (100) according to observed threat activity (140A, 140B, … , 140n-1, 140n) by the threat modeler (180) in the context of a single related threat kill chain (150) for the purpose of simplicity.
Figure 22. Notional CTA-based Modification Process
An observed threat activity is selected for processing (410) and a determination is made whether the observed frequency of the threat activity exceeds a threshold (415). If not, it is determined whether additional threat activities have been observed (455) and, if so, the process repeats with the selection of a new observed threat activity (410). However, if it is determined that the observed frequency of the threat activity exceeds a threshold (415), a threat model is queried to identify a kill chain related to the threat activity (420).
A query then executes against the control specification to determine if an enhancement can be made to the control specification to address the risk posed by the change in selected threat activity (425), for example, by reducing the likelihood the threat activity will successfully exploit a vulnerability. If an enhancement for the control specification is available from the control library (430), the enhancement is added to a candidate list for analysis (435). If not, it is determined if additional threat activities are associated with the kill chain and have not yet been processed (440).
If additional threat activities remain, the process returns to querying of the control specification to determine if an enhancement can be made to the control specification to address the risk posed by the change in the next selected threat activity (425). Otherwise, it is determined if at least one enhancement is present in the candidate list (445).
If not, a query for an enhancement is transmitted to a general catalog of controls not tied to any specific underlying control specification (450). If an enhancement is located within the general catalog responsive to the threat activity (470), the enhancement is added to the candidate list (475). Otherwise, an intervention flag is generated (480) indicating to an analyst that a review is required of the threat activities and controls associated with the threat kill chain (420) to determine if new enhancements can be designed and added to the control library. In either circumstance, the process advances.
If it is determined if additional threat activities have yet to be processed (455), the process of selecting observed threat activity (410) repeats itself. However, if all threat activities have been processed, one or more of the enhancements in the candidate list are selected for inclusion in the control specification (460). For instance, the enhancements can be selected according to meta-information specifying a probability of mitigation and a cost of implementation so that the selection of the enhancements can be optimized. As a final step, the selected set of enhancements can then be added to the control specification.