Reading Time: 6 minutes
The current crop of Best Practice tagging schemes and recommendations don’t describe the context required for people or tools to assess security or manage risk easily. But I never explained why risk management is important nor how to assess risk.
Let’s start with an introduction to the process of managing risk before we jump into describing the incremental information teams using the Cloud need to do that.
The Risk Management Process
The risk management process described here is extracted from the United States’ National Institute of Standards and Technology’s (NIST) guidance for conducting risk assessments, NIST Special publication 800-30, hereafter called the Guide. The Guide is a good introduction to the topic and its 95 pages go by quickly.
There’s a good chance your organization is using something like this process (or trying to) and your Information Security colleagues are at least familiar with it.
Let’s start with the question of why perform a risk assessment at all.
The purpose of a risk assessment is to identify:
- threats to the organization operations, assets, or individuals
- both internal and external vulnerabilities
- the adverse impact(s) that may occur given the potential for threats exploiting vulnerabilities
- the likelihood(s) that that adverse impact(s) will occur
Sounds good! That statement of purpose is full of terminology with specific meanings. And that’s a clue that ‘assessment’ is not the first step in the risk management process.
Indeed, NIST 800-30 recommends a risk management process with four major components:
Frame
First, Frame risk by establishing the context in which risk-based decisions are made. Framing produces a strategy for how the organization intends to assess, respond, and monitor risk. The strategy should explicitly and transparently define expectations for how risk will be managed for the organization as a whole. The strategy must also address areas that have specific security needs, such as a business unit that handles personal health or cardholder information. The strategy should cover important factors like how:
- frequently risk should be assessed and at what cost
- teams should respond to an incident, starting with internal communications
- risks will be prioritized and efforts allocated for improvement
- risk information will be gathered and monitored from across the org
Assess
Second, Assess risk within the organizational risk frame. The Guide defines “risk assessment is the process for identifying, estimating, and prioritizing information security risks,” and helpfully defines a general definition of Risk:
Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
and a specific definition for Information Security Risk:
Information security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation.
This definition of information security risks provides a useful starting point for modeling risk in information system deployments in the Cloud or elsewhere. For example, we might model that risk in compute and data resource tags.
NIST’s risk assessment methodology relies on a risk model, assessment approach, and analysis approach, and more that we’ll dig into in the next section.
Respond
Third, the risk management process requires that you Respond to identified risks consistently and in accordance with the organization’s risk frame by:
- developing courses of action to respond to an identified risk
- evaluating and determining the appropriate courses of action consistent with organizational risk tolerance
- implementing risk responses based on selected courses of action
Monitor
Fourth, Monitor the organization’s accumulated risks over time by:
- determining ongoing effectiveness of risk responses
- identifying risk-impacting changes to information systems and operating environments
- verifying that planned risk responses are implemented
- verifying that information security requirements are derived from and traceable to the organization’s mission/business functions
These four components of the risk management process orchestrates set the strategy, gather information, and orchestrate responses from multiple teams and many systems within large organizations. These teams and systems in this system have varying levels of dependency on each other. The risk management process operates within a Complex system and so we will need an appropriately rich and coupled process for it to operate well.
Let’s dig into what is arguably the most challenging component, Risk Assessment.
The Risk Assessment Process
The risk assessment process is a component within a risk management process. The risk assessment process identifies, estimates, and prioritizes information security risks. The following figure depicts my view of the risk assessment process in a rough value-stream form, including the information that must be supplied to the ‘Assess Risk’ process as inputs, the outputs, and people involved:
Nothing says shared process and shared fate like two teams being both suppliers and consumers of a process’ inputs and outputs like we have with ‘Assess Risk’. This diagram illustrates the practical reality of how Security and Cloud Platform or Delivery Teams both supply and consume information to the Risk Assessment process for most Cloud delivery models.
The risk assessment process’ main inputs are:
A risk model defines key terms, risk factors, and relationships between risk factors that matter to the organization
An assessment approach defines whether you will classify risk into qualitative categories like high/moderate/low or a quantitative approach estimating a range of financial impact. Also, the assessment approach must define the scales and examples used within the assessment process to estimate the impact of a threat to the organization.
An analysis approach defines the primary perspective you will assess from: threats, assets, vulnerabilities; the approach should also provide examples of each.
You won’t find ‘domain knowledge’ and ‘current configuration’ on the NIST’s illustration of the process because it’s baked into the ‘Prepare’ step. This information is required when preparing for a risk assessment:
TASK 1-4: Identify the sources of descriptive, threat, vulnerability, and impact information to be used in the risk assessment. Descriptive information enables organizations to be able to determine the relevance of threat and vulnerability information (emphasis added)
‘Domain knowledge’ describes the resources and environment being assessed in sufficient detail for us to analyze it within a risk context.
This looks like the context that’s missing from many risk assessments: descriptive information that enables assessors and tools to determine relevance.
Returning to the definition of Risk, we need to understand what stakeholders’ confidentiality, integrity, and availability requirements are so that we can estimate the impact of not meeting those requirements.
The domain knowledge and system configurations of Cloud deployments using modern delivery practices in 2020 change much faster than when NIST published this guide in 2012 — 10x or more.
So while it may have been reasonable to encode the domain knowledge of what infrastructure and application components in a CMDB and update it once a quarter in 2012, that doesn’t work anymore.
Engineers trying to understand and assess the security or risk of their Cloud deployments will need an an inexpensive way to determine their system configuration and generate a current asset and control configuration inventory to prepare for the risk assessment. It’s nonsensical to collect or maintain that data manually when you’re changing it via automation a few times per month, week, or day.
Takeaways
This post provides a foundation for understanding why, how, and what engineers need perform a risk assessment and some challenges you may encounter when doing that for your own Cloud deployment. For example, you might notice that you don’t have a risk model or an up-to-date asset inventory, or know where to find it. That could lead to a productive conversations with colleagues about how and when that should be addressed.
Now that we’ve got a grounding in what is required to perform a risk assessment, we can move on to doing that efficiently. In the next post, I’ll propose a model for describing the risk context for each of your Cloud components and keeping that synchronized with your asset inventory by tagging resources.
Stephen
#NoDrama
