Risk Management Strategy – SAMPLE – ACME company

 

Scope

This document defines how cybersecurity risks associated with the ACME operational systems will be identified, analyzed, and managed.

This document can be used by the Chief Operating officer and senior management to forecast risks, evaluate impacts, and provide responses.

 

Risk Management Process

Risk Management is an iterative process. As the implementation of the risk management program progresses, more information will be gained about the program, and the risk statement will be adjusted to reflect the current understanding. The overall process involves Identifying, Analysis, Categorizing, Remediating, and Reporting. A Risk Management Log is maintained to track known risks and remediation efforts.

The current risk management process has been inspired by and adapted from NIST SP 800-30/ NISTIR 8183A.

 

Identification

Risks will be identified as early as possible in the project to minimize their impact. For the purposes of this process, risks are threats exploiting vulnerabilities or weaknesses in technology, processes, or policy that may cause an adverse impact or harm to the organizational operations, organizational assets, or individuals.

There are many different types of threats that can affect IT infrastructure. Common threat sources include:

• Adversarial — individuals, groups, organizations, or states that seek to exploit the organization’s dependence on cyber resources.
• Accidental — Erroneous actions taken by individuals in the course of executing their everyday responsibility
• Structural — Failure of equipment, environmental controls, or software due to gaining, resource depletion, or other circumstances which exceed expected operating parameters.
• Environmental — Natural disasters and failures of critical infrastructures on which the organization depends, but which are outside the control of the organization.

 

The Chief Operating officer  and IT Team will coordinate the formal IT system annual risk assessments in accordance with the latest version of the NIST SP 800-30 guidance. During this process, specific organizational threat events will be identified and defined for use in assessing vulnerabilities and weaknesses to determine if a risk exists.

 

For continuous monitoring and risk management, ACME’s employees or external contractors must report any potential risk following the risk notification process described below. Additionally, software tools including, but not limited to, Nessus and CSET29 are used to support the risk assessment process by identifying vulnerabilities and weaknesses in the technology, processes, or policies for the organization.

 

The Chief Operating officer will perform a CSET assessment at least annually. Due to the potential impact to manufacturing processes, scans are performed only during scheduled preventive maintenance periods. Nessus results will be imported into NamicSoft and reports generated and distributed to the Chief Operating officer  and the IT Manager. Additionally, other types of risks, such as hardware based, physical, or environmental will be identified and documented manually.

 

Note: Any software-based vulnerabilities that cannot be remediated per the Vulnerability Management Plan will be included in the risk analysis process to determine the appropriate corrective action.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Risk Notification Process for ACME:

 

- Any employee or external vendor who identifies a potential risk should immediately report it to their immediate supervisor or the IT help desk.

- The immediate supervisor or IT help desk will assess the risk and determine if it is a valid concern that needs to be escalated. If so, they will notify the IT manager.

- The IT manager will assess the risk and determine if it needs to be escalated to the Chief Operating officer .

- If the Chief Operating officer  determines that the risk is significant and could impact the business operations, they will notify the CEO and the IT management team.

- The IT management team will analyze the risk and develop a plan for remediation. They will also document the risk in the risk management system and assign a risk owner.

- The risk owner will be responsible for implementing the plan for remediation, tracking progress, and reporting updates to the IT management team.

- The IT management team will provide regular updates to the Chief Operating officer  and the CEO until the risk has been fully remediated.

- Once the risk has been remediated, the risk owner will update the risk management system and close out the risk.

 

It is important to ensure that all employees and external vendors are aware of this process and understand their role in reporting potential risks. Regular training and awareness campaigns can be conducted to reinforce the importance of risk reporting and to encourage a culture of risk awareness and mitigation.

 

 

 

 

 

 

 

 

 

 

 

 

 

Analysis

 

To begin the analysis process, each vulnerability must be assigned a vulnerability score from 1 to 10. Vulnerabilities identify by CSET will be manually assigned a score from 1 to 10 based on the severity of the finding by the assessor. For vulnerabilities identified through scanning tools such as Nessus, the CVSS associated with the vulnerability will be used as the vulnerability score.

 

At a minimum, vulnerabilities with a score in at the high (vulnerability score: 7.0 to 8.9) and critical (vulnerability score of 9.0 to 10) range will be analyzed to determine if an associated

threat or threat event exists that has a probability of occurrence greater than zero. For each vulnerability, threat pairs, an impact on operations will be estimated. A qualitative risk analysis process will be used to determine the overall probability and impact levels using the guidance in the tables below. These factors are then combined to provide an estimated quantitative risk score for use in reporting and prioritization.

 

 

Probability	Description	Quantitative Value
High	Greater than <70 %> probability of occurrence in a year	0.8
Medium	Between <30 %> and <70 %> probability of occurrence in a year	0.5
Low	Below <30 %> probability of occurrence in a year	0.3

 

 

 

Note: At the discretion of the assessor or the Chief Operating officer , the probability quantitative value may be adjusted to more accurately represent the probability of occurrence up to a maximum of 1 representing 100 % probability of occurrence and to a minimum of 0 representing 0 % probability due to no identified threat or threat event being identified for the vulnerability or weakness.

 

Impact	Description	Quantitative Value
High	Risk that has the potential to seriously impact production cost, production schedule or performance	1
Medium	Risk that has the potential to moderately impact production cost, production schedule or performance	0.5
Low	Risk that has relatively minor impact on cost, schedule or performance	0.1

 

Notes: Overall impact scores are the product of the qualitative level from the impact table and the asset criticality as defined below resulting in an impact range of 1-10. If an asset criticality has not been defined, then assume an asset criticality of 10 until the asset can be properly categorized.

 

 

Asset Criticality Matrix

Once a list of ACME assets or systems requiring protection have been identified by the Hardware Inventory process, they will be assigned a value. Asset Value is the degree of impact that would be caused by the unavailability, malfunctioning or destruction of the asset.

ACME will use the following scale to calculate Asset value.

 

 

Criticality	Description	Asset Value
Critical	Loss or damage of this asset would have grave / serious impact to the operations of the systems directly impacting production. This can result in total loss of primary services, core processes or functions.	10
High	Loss or damage of this asset would have serious impact to the operations of the system directly impacting production. This can result in major loss of primary services, core processes or functions.	7 to 9
Medium	Loss or damage of this asset would have moderate impact to the operations of the system or Production. This can result in some loss of primary services, core processes or functions.	3 to 6
Low	Loss or damage of this asset would have minor to no impact on the Operations of the system or Production. This can result in little or no loss of primary services, core processes or functions.	1 to 2

 

 

 

Categorization

 

Categorization of risks begins by computing the overall risk score. The overall risk score is computed using the following equation:

Risk Score = Vulnerability Score X Probability X Impact X Asset Criticality

 

The resulting risk score (1 to 100) is then used for determining the overall risk level (adapted from NIST SP 800-3030) which is utilize for prioritizing remediation efforts.

 

Risk Level	Description	Risk Score
Very High	Very high risk means that the identified vulnerability could be expected to have multiple severe or catastrophic adverse effects on organizational operations, organizational assets, or individuals.	96 to 100
High	High risk means that the identified vulnerability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals	80 to 95
Medium	Moderate risk means that the identified vulnerability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.	21 to 79
Low	Low risk means that the identified vulnerability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.	5 to 20
Very Low	Very low risk means that the identified vulnerability could be expected to have a negligible adverse effect on organizational operations, organizational assets, or individuals.	0 to 4

 

 

The resulting risk information is then entered into the risk management log for tracking and for coordinating remediation.

 

 

Remediation

For each risk rated moderate or higher, one of the following approaches will be selected for remediation:

• Avoid – eliminate the threat by eliminating the cause
• Mitigate – Identify ways to reduce the probability or the impact of the risk
• Accept – accept the risk
• Transfer – transfer the risk by having another party responsible for the risk (buy insurance, outsourcing, etc.)

 

Risk mitigations and transfer efforts may require additional research and time to implement. As necessary, the Chief Operating officer  will reach out to IT Vendor for any risks and request remediation assistance. For any corrective actions taken, including risk acceptance, the risk management log must be updated.

Each risk mitigation and transfer effort will be maintained on the Risk Management log and tracked by the Director of Operation until completed. Once completed, an assessment of the implemented mitigation will be performed to assess the new residual risk level for the vulnerability and determine if the residual risk is within an acceptable range for continued operations.

 

Any risk acceptances must documented and should follow the process established in the Remediation Management and Priorities and Exception Management procedure.

 

Reporting

This table describes the frequency and format of how the Director of Operations or IT Manager will document, analyze, communicate, and escalate outcomes of the risk management processes.

 

Reporting Method	Description	Frequency
Risk Management log	A document to report the results of risk identification, analysis, and response planning	Yearly
CSET Report	A document describing Risk assessment results	Yearly
NamicSoft report	A document containing results of Nessus vulnerability scans	Manual/Post vulnerability assessment The Director of Operations will share the results of risk assessments (either the Risk Management Log or CSET Report) with the CEO.

 

 

 

 

Risk Management log – sample

 

 

Risk	Category (Technical, Management, Contractual, External)	Probability	Impact	Risk Score	Risk Mitigation Strategy	Actions required	Status (Open, closed, In Progress)	Due Date