Mitigating Technical Vulnerabilities With Risk Assessment

The cyberthreat landscape has undergone a dynamic evolution due to rapid advances in technology and increased digitalization. With this comes an increase in the volume of sophisticated technical vulnerabilities, exposing enterprises to greater cybersecurity risk with the potential to adversely impact their business objectives. A risk assessment can prioritize which technical vulnerabilities are most critical, allowing an enterprise to allocate the appropriate resources to fix or patch them in a timely manner.

Objectives of a Risk Assessment

The three main objectives when conducting a risk assessment are:

1. Identify the events that could result in a malicious act and potentially lead to undesirable business consequences.
2. Determine risk levels, which allows an enterprise to dedicate adequate attention and resources to risk factors with the highest priority.
3. Create a risk-aware culture by engaging relevant stakeholders, encouraging them to think about how technology risk factors align with business objectives.

Risk Assessment for Technical Vulnerability vs. Vulnerability Assessment

A risk assessment for technical vulnerability should not be confused with a vulnerability assessment. Vulnerability assessment is the process of discovering, identifying and evaluating security vulnerabilities on computer systems, including IT and operational technology (OT) systems or networks.¹ In most cases, software tools are used to conduct a vulnerability scan of a computer system.

In contrast, a risk assessment for technical vulnerability is conducted when a technical vulnerability has been identified or published by a threat intelligence organization (e.g., MITRE Corporation) or a vendor (e.g., Microsoft, Cisco, VMware). In this case, the affected enterprise needs to evaluate risk factors related to the known vulnerability and define appropriate actions.

Prerequisites for Risk Assessment for Technical Vulnerability

Before conducting a risk assessment for technical vulnerability, an enterprise risk management framework must be established, and comprehensive risk assessments must be carried out regularly by the enterprise. Depending on an enterprise’s industry, business goals, organizational structure, technology infrastructure and available resources, it can develop its custom risk management framework using an established risk management framework such as COBIT^®,² the International Organization for Standardization (ISO) 31000:2018 Risk Management—Guidelines³ or the US National Institute of Standards and Technology (NIST) Risk Management Framework.^{4, 5}

Roles and responsibilities should be clearly defined to ensure that stakeholders know what is expected of them during a risk assessment exercise. The enterprise’s risk tolerance must be established to allow management to articulate how much risk is acceptable. Both the asset inventory and the network architecture diagram, which provides a visual representation of the interconnectivity and communication paths between assets, should be regularly reviewed and updated. Most important, the existence of the technical vulnerability should be validated to determine whether a risk assessment for technical vulnerability is required.

The existence of the technical vulnerability should be validated to determine whether a risk assessment for technical vulnerability is required.

Conducting a Risk Assessment for Technical Vulnerability

A risk assessment for technical vulnerability involves a three-step process (figure 1).⁶

Step 1, risk identification, includes determining which assets are affected by the known vulnerability. Tasks include:

• Identify assets—Using the existing asset inventory, determine which assets are affected by the technical vulnerability and determine the assets’ criticality in terms of impact on overall business or system objectives.
• Identify threat events—Using the asset inventory and network architecture diagram, identify the threat events that could exploit the vulnerabilities of the affected assets.
• Create risk scenarios—Create scenarios of what could go wrong to provide realistic and relatable views of the risk based on the business context, system environment and pertinent threats.

Step 2, risk analysis, includes analyzing the elements that make up each risk scenario to determine:

• The likelihood of a risk scenario occurring—The historical or expected occurrence of an event has traditionally been used to measure the risk likelihood (e.g., the event is expected to occur once every year or has occurred once in the past year). The risk assessor should use the likelihood rating established in the enterprise’s existing risk management framework.
• The impact (i.e., magnitude of harm) of the occurrence of a risk scenario—In general, the manifestation of a risk scenario can compromise the confidentiality, integrity or availability of assets (e.g., data, equipment, operations). The risk assessor should use the impact rating established in the enterprise’s existing risk management framework. Depending on the enterprise’s risk management framework, the impact rating could be rated on a scale as low (1), medium (2) or high (3); or negligible (1), minor (2), moderate (3), severe (4) or very severe (5).

Step 3, risk evaluation, includes determining and understanding the significance of the risk level. Tasks include:

• Determine and prioritize risk—Risk is a function of the likelihood of a given threat event exploiting an asset’s potential vulnerability and creating a resulting impact. This can be depicted using a risk matrix (figure 2). Each risk level derived can be compared against the risk tolerance level defined by the enterprise. Risk scenarios with risk levels above the tolerance level must be prioritized for treatment until the risk level falls within acceptable levels. When prioritizing risk for treatment, the expected duration should also be established.
• Document risk—A risk evaluation must be clearly documented in a risk register and communicated to stakeholders. A risk register is a record of all the risk scenarios identified, including their determined risk levels. The risk register is a living document that should be regularly reviewed and amended to ensure that management has an up-to-date picture of the enterprise’s cybersecurity risk factors when making decisions.

Types of Risk Response

After the risk has been assessed, risk response is the next phase in the risk management process. In the risk response phase, the enterprise is required to choose the most appropriate or cost-effective risk response to keep the evaluated risk within the enterprise’s risk tolerance level. There are four commonly accepted options for responding to risk:⁷

1. Acceptance—As long as the risk level is within the enterprise’s risk tolerance and the response is aligned with its business objectives and patch management policy, risk acceptance is the most likely response, as it requires minimal effort.
2. Mitigation—If the risk level is above the enterprise’s risk tolerance and a patch or workaround for the technical vulnerability is available, the enterprise will most likely choose risk mitigation to bring the evaluated risk within the enterprise’s risk tolerance.
3. Transfer—Risk transfer includes transferring the affected activity or operation to a third party or buying cyber insurance. In terms of cost effectiveness, risk transfer is likely to cost more compared to risk mitigation (such as patching or using a technical workaround). Furthermore, for cyberrisk insurance, insurers often want to know that the enterprise is taking steps to understand and act on the known risk. Failure to do so usually results in a higher premium or declined coverage.
4. Avoidance—Risk avoidance is to avoid using the affected information asset, system or activity that would cause the risk event to occur; however, it may not always be feasible to use risk avoidance if the affected information asset or system is already in operation and removing the affected information asset or system would likely trigger a change in architecture design or affect the enterprise’s operation or business objectives.

Risk assessment for technical vulnerability is meant to complement an enterprise’s existing comprehensive security risk assessment, not replace it.

Conclusion

Risk assessment for technical vulnerability is meant to complement an enterprise’s existing comprehensive security risk assessment, not replace it. In accordance with International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) standard ISO/IEC 27001 Information Security Management, an enterprise should perform information security risk assessments at planned intervals or when significant changes are proposed or occur.⁸

Depending on local laws and regulations, it might be mandatory to carry out comprehensive security risk assessments at certain intervals. For example, in Singapore, the owner of a critical information infrastructure must conduct a cybersecurity risk assessment at least once a year in the prescribed form and manner.⁹

In any case, risk assessment should be a continual activity and part of day-to-day operations.

Endnotes

¹ Cybersecurity Agency of Singapore, Cybersecurity Code of Practice for Critical Information Infrastructure, 2^nd Edition, Singapore, 2022, https://www.csa.gov.sg/Legislation/Codes-of-Practice
² ISACA^®, COBIT^®, USA, https://www.isaca.org/resources/cobit
³ International Organization for Standardization (ISO), ISO 31000:2018 Risk management—Guidelines, Switzerland, February 2019, https://www.iso.org/obp/ui/#iso:std:iso:31000:ed-2:V1:en
⁴ National Institute of Standards and Technology (NIST), NIST Risk Management Framework, USA, https://csrc.nist.gov/projects/risk-management/about-rmf
⁵ Marker, A.; “Enterprise Risk Management Frameworks and Models,” Smartsheet, 2 November 2021, https://www.smartsheet.com/content/enterprise-risk-management-framework-model#types-of-enterprise-risk-management-framework
⁶ Cybersecurity Agency of Singapore, Guide to Conducting Cybersecurity Risk Assessment for CII, Singapore, February 2021, https://www.csa.gov.sg/legislation/supplementary-references
⁷ ISACA, CRISC^® Review Manual, 7th Edition, USA, 2021, https://store.isaca.org/s/store#/store/browse/detail/a2S4w000004Ko8XEAS
⁸ International Organization for Standardization/International Electrotechnical Commission (ISO/IEC), ISO/IEC 27001:2013 Information technology—Security techniques—Information security management systems—Requirements, Switzerland, 2013, https://www.iso.org/standard/54534.html
⁹ Singapore Statutes Online, Singapore Cybersecurity Act 2018, 12 March 2018, https://sso.agc.gov.sg/Acts-Supp/9-2018/Published/20180312?DocDate=20180312

TAN SOON CHEW | CISA, CRISC, CISM, CCSP, CISSP, PMP

Is an information security manager at Sita Information Networking Computing (Asia Pacific) Pte Ltd. and an associate lecturer at the School of Engineering and Technology at PSB Academy (Singapore). He can be reached at soonchew.tan@psba.edu.sg.