Risky Risk Exception
One of the biggest danger of any large organization is creating risky risk exception, especially by people who are not experts in security and risk management. I will mostly focus on security risks (but my concern should apply to other forms of risks).
The classic definition of risk is given by the following formula:
Risk = Probability of a Bad Event X Impact or Loss due to the Bad Event
R = P X L
For security risk we will use a different formula that is closer to reality of security. Let us begin with NIST 800–37r2 on Risk Management Framework (RMF). The following figure illustrates the basic steps of RMF.
Prepare to execute the RMF from an organization and system-level perspective by establishing a context along with priorities for managing security and privacy risk.
Categorize the system and the information processed, stored, and transmitted by the system based on an analysis of the impact of loss.
Select an initial set of controls for the system and tailor the controls as needed to reduce risk to an acceptable level based on an assessment of risk.
Implement the controls and describe how the controls are employed within the system and its environment of operation.
Assess the controls to determine if the controls are implemented correctly, operating as intended, and producing the desired outcomes with respect to satisfying the security and privacy requirements.
Authorize the system or common controls based on a determination that the risk to organizational operations and assets, individuals, other organizations, and the Nation is acceptable.
Monitor the system and the associated controls on an ongoing basis to include assessing control effectiveness, documenting changes to the system and environment of operation, conducting risk assessments and impact analyses, and reporting the security and privacy posture of the system.
The first step in the RMF is Prepare, and the steps after that need not be sequential. We will not repeat what is already described in NIST 800–37r2. The goal here is to focus on security exception and risk authority. We mainly identify two types of organization : (1) CISO who define security policies and identify security controls that need to be implemented and (2) Services Organization (SO) who owns a scoped solution/services and implement the identified and defined security controls. Risk management is dependent on how the two organizations work together to manage the risk.
Security Risk = Defined Security Controls — Implemented Security Controls
SR = (DSC — ISC)/DSC
Defined Security Controls are a set of security controls that have been selected by CISO for implementation. Implemented Security Controls are a set of security controls that have been implemented by the solution or services organization. SR is a value between 0 and 1, with 0 being zero risk and 1 being high risk. All Security Risks must be documented as Risk Exception and management approval or authority is needed for risk exceptions. This simple risk formula is more useful than what is traditionally used since the formula tells how many security have been implemented, which is important for auditing.
Risk Appetite is the type and amount of risk that CISO and the SO management are willing to accept for a period of time in pursuit of value. This notion of risk appetite is from the Committee of Sponsoring Organizations Enterprise Risk Management (COSO ERM) except that we added “period of time”, which can be “forever”, “one month”, “three months”, etc. We are also using NISTIR 8286 for risk definitions. NISTIR 8286 also follows COSO ERM.
Risk Response is how both the CISO and SO work together to keep risk within tolerable levels. Negative risks can be accepted, transferred, mitigated, or avoided. Positive risks can be realized, shared, enhanced, or accepted.
Risk Tolerance is the risk that CISO and SO are willing to bear the remaining risk after any risk response (mitigation) in order to achieve its business objectives, without violating regulatory requirements.
A risk can be a known or unknown. Just because we are not aware of a risk does not mean the risk does not exist, or that attackers do not know about the risk. From a regulatory compliance point of view all known risks should be documented and the management must be informed. A (known) risk can be further classified into two cases: (1) a risk that should be mitigated within a finite time or (2) a risk that can be tolerated without additional implementation of controls. The latter is needed for regulatory compliance, which expects management awareness of the tolerated risk. Whether our customer(s) accept the tolerated risks is a business decision, and usually falls under business risk. There are of course some risk types that our auditors and customers will not tolerate (e.g., risks related to NIST 800–53 AC family).
Risk exception is a misunderstood concept and so becomes a risky risk exception. Documenting risk exception is necessary but what is more important is mitigating and eliminating the risks. It is also important that risk exceptions are written by security experts working with services team and consulting with the CISO team. Risk exception should not be written by project/program managers, solution architect, and other non-security experts. A security risk exception should include detailed security analysis, including threat model, the context of security controls, system security plan (SSP), Plan of Action & Milestone (POA&M), etc. A security risk exception should be treated as a serious security risk gap, and ensure that they are mitigated in a timely fashion. We cannot be creating a Risky Risk Exceptions.
