RMF — The Five Stages of Activity | Building Secure Software
The purpose of an RMF like this is to allow a consistent and repeatable expertise-driven approach to risk management.
The basic idea is simple: identity, rank, track, and understands software security risk as it changes over time.
5 Fundamental Activities:
1. understand the business context
2. Identify the business technical risks
3. Synthesize and prioritize the risks, producing a ranked set
4. Define the risk mitigation strategy
5. Carry out required fixes and validate that they are correct
Stage 1: Business Context
Risks are unavoidable and are a necessary part of software development. Risk aversion and technical tradeoffs are deeply impacted by business motivation.
During this stage you should do the following:
1. Analysts extract and describe business goals
3. Circumstances to understand what kinds of software risks to care about
1. Increase revenue
2. Meet service-level agreements (SLAs)
3. Reduce development costs
4. Return on investment (ROI)
Measuring and Reporting on Risk
Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. A master list of risks should be maintained during all stages of RMF execution and continually revisited.
Stage 2: Identify Business and Technical Risk
Business risks help define and impact the use of technical methods for extracting, measuring, and mitigating software risk. The risks threaten one or more business goals. Identifying the risk helps clarify and quantify how they will impact our goals is important.
The key to making risk management work for any business lies in tying technical risks to the business context in a meaningful way. Central to this stage of the RMF is the ability to discover and describe technical risks and map them through business risks to business goals.
Business risks impact:
1. Direct financial loss
2. Damage to brand or reputation
3. Violation of customer agreements
4. Exposure to liability such as law suites
5. Increased costs like development costs
Stage 3: Synthesize and Prioritize Risks
Establish a relationship between business goals, business risks, and technical data. Prioritization of risk leads directly to the creation of value. The question ‘Who cares’ must be answered during this stage. This stage creates as its output lists of all the risks and their appropriate weighting for resolution. Parts of this process can be automated over time.
“What shall we do first given the current risk situation?”
“What is the best allocation of resources, especially in terms of risk mitigation activities?”
Stage 4: Define the Risk Mitigation Strategy
In this stage, it is time to create a coherent strategy for cost-effectively mitigating the risks. Technical issues can be found easily but figuring out how to fix them tends to be more difficult from a technical perspective. When addressing mitigation strategies, it is important to take into account cost, implementation time, the likelihood of success, completeness, and impact over the entire corpus of risks. It is important to keep all mitigation activities in line with the business’s goals and abilities. The process needs to have identity validation techniques that can be used to demonstrate that risks are properly mitigated.
Stage 5: Carrying Out Fixes and Validating
Risk mitigation is carried out according to the strategy defined in stage 4. Progress at this stage should be measured in terms of completeness against the risk mitigation strategy. The central concern at this stage is to validate that software artifacts and processes no longer bear unacceptable risks. This stage should define and leave in place a repeatable, measurable, verifiable validation process that can be run from time to time to continually verify artifact quality.