Continuous Improvement to Enterprise Risk Management: The Risk Register
I recently delivered a presentation to members of ISACA’s Toronto Chapter. I’ve taken the research and feedback from the talk to draft an article about the implementation and management of a risk register. Thank you to those who attended, and I look forward to readers’ views in the comments!
Introduction
Risk has taken on new meaning in recent years. Additional sources of risk, threats, and changes in the regulatory landscape impact businesses (and their consumers) in a myriad of ways not thought possible just five years ago. For example, many businesses now recognize the significance of their digital and physical supply chains as sources of risk that must be appropriately managed. One evolving area of risk that’s received considerable and deserved attention is the ability to track and address deficiencies, such as vulnerabilities and misconfigurations, that if left unaddressed could lead to compromise. As one component of enterprise risk management, a risk register is a proven means to empower a team to undertake remediation in a calculated fashion, thus reducing an organization’s attack surface and corresponding risk profile. This article considers the role of the risk register for organizations seeking to adopt one.
A risk register facilitates the remediation of vulnerable assets in a deliberate and accountable manner. It is a communication tool that clearly articulates ownership, sources of risk, and the means to minimize the effectiveness of threat actors to improve an organization’s overall security hygiene.
Why maintain a risk register?
There are various rationales for maintaining a risk register: compliance, practicality, and as a best practice. Developing a risk register is an explicit means to meet ISACA’s Risk Evaluation (RE) 3.5 as well as Monitor and Evaluate (ME) 2.7 of COBIT. It is the operational output of proven control practice, namely to
· Assess control exceptions
· Design an approach to prioritise and assign responsibility
· Initiate remedial action tasks
· Identify substandard performance
· Escalate continued substandard performance
· Approve remedial action tasks upon satisfactory completion
For those living in the world of ISO, maintaining a risk register achieves aspects of the Compliance domain, especially A15.2, A15.2.2 (technical compliance checking). The ISO framework may be more relevant when it comes to determining treatment for given risks. ISO 27005 “is designed to assist the satisfactory implementation of information security based on a risk management approach.” Ultimately, a risk register will help enormously during an audit to showcase how vulnerabilities and misconfigurations are being addressed in a commonly understood way.
There are other rationales that implicitly drive value. Remediation costs post-compromise are rising: according to Scalar’s 2017 Security Study, costs to businesses to remediate after a compromise reached nearly $875,000 in 2016 (see Figure 1). Additional costs related to operational disruptions and reputational damage are borne as well. Like preventative maintenance for a vehicle, proactive remediation reduces tangible and intangible costs.
The sheer volume of vulnerabilities and misconfigurations is increasing; numerous reports indicate that they remain leading causes of breaches. According to edgescan, “the lack of system patching is still a large source of vulnerabilities. Configuration and maintenance are significant root causes of attacks ranging from Ransomware to data disclosure attacks.” In its 2018 Internet Security Threat Report, Symantec relays that reported vulnerabilities were up by 13% (which may be attributable to bug bounties). Such figures provide a compelling baseline on which to build a business case to invest in a risk register and the underlying processes and headcount, as required.
My interpretation of a risk register, based on ISACA’s and Gartner’s models, is somewhat at odds with FAIR Institute, for which I have great respect. In his March 2017 article, Jack Jones writes that
Risk registers should be used to document the portfolio of potential adverse events an organization is subject to. These entries should describe the event and have fields for the likelihood and impact associated with the event… A separate register (you pick a name) should be used to record the control deficiencies, etc. that contribute to an organization’s risk portfolio.
As part of an organization’s continuous improvement approach to security, this dichotomy is something to strive for. In the beginning, I would submit, both types of risk contributors (events and deficiencies) can coexist on a single risk register, especially for SMB. Be agile: by having such a model and programme in place, a team can then start to parse those contributing factors. A spreadsheet will likely meet initial requirements; automation and integrations can be added over time once the process is validated and stakeholders are on board.
A risk register is not a means to assign blame (asset owners are not ‘points of blame’), but can be used to assess performance, efficacy, program efficiency, or compliance across the enterprise. For example, is a given team applying hardening guidance in the manner prescribed by an organization’s policies and guidelines? Are security governance teams asserting enough influence during project reviews, or are exceptions becoming the norm? The answers to these questions can be found on a well-maintained risk register.
Practical application: Show me what it looks like
A risk register puts vulnerabilities in context and allows for a programme to exist to address them, rather than ad hoc methodologies which might omit those sources or events that pose the greatest risk. If the minimum viable product achieves this strategic aim, the program can launch. I foresee the columns for a minimally viable risk register as the following:
* Asset or process: a serialized system, ideally referencing the CMDB or similar catalog, to log the asset or process of concern
* Risk description: a description of the risk to impart how such a risk source can lead to compromise
* Risk rating: a rating of the risk, typically based on CVSS or CVE ratings
* Business owner: the role or name of an individual that can be contacted to support the remediation effort and provide guidance from the business
* Operational owner: the role or name of an individual that can be contacted to lead the remediation effort
* Criticality: a consistent rating system that is based on the assets’ importance, CVE/CVSS and perhaps internal metrics to provide users with a rapid way to filter across the items in need of immediate attention. This value can take into account the risk rating (above) and exploitability while factoring in how important an asset or process is.
Teams should remain mindful of the little things: Items deemed to be of higher risk can be addressed at the expense of lower-risk vulnerabilities and misconfigurations, which may occupy a register for the long term. The team maintaining the register and providing oversight would benefit from a means to track the aggregate risk to any given system and the notion of vulnerability chaining, whereby an attacker can mount some offensive action made possible by multiple vulnerabilities in series. We tend to discuss vulnerabilities in isolation, and major ones can receive inordinate attention in the news media and security research circles.
According to research by Recorded Future, the three most popular vulnerabilities purportedly leveraged for exploiting vulnerabilities are CVE-2017–0199 (which allows attackers to download and execute a Visual Basic script containing PowerShell commands from a malicious document), CVE-2016–0189 (which is an old Internet Explorer vulnerability that allows attackers to use an exploit kit to drop malware, such as ransomware), and CVE-2017–0022 (which enables data theft).
Not just vulnerabilities…
Misconfiguration often carries far greater implications since vulnerabilities, in most cases, are externally validated and addressed. Disclosure rules, for suppliers, can be negotiated and enforced (in theory). A misconfiguration is highly contextual and applies to the organization in question, whose team may not have applied hardening practices as recommended. Hence, these are likely deserving of greater scrutiny by those maintain a risk register, who may prescribe mitigating controls and scanning until such time that remediation is achieved.
The constituents
Maintaining an effective risk register requires multiple stakeholders. It’s important to identify and understand the entities that will drive inputs to the risk register, and those that will be involved in the treatment of articulated risk. There may be some overlap between the two populations. The following list is not comprehensive but can likely be mapped to most enterprise IT/GRC functions:
Inputs to the risk register are derived from the following entities, who should be encouraged to submit findings to a centralized resource in a formal, templated manner:
· Red teaming, scanning, penetration testing
· Vendor or 3rd party disclosures
· Audit and assurance
· Incident response/security operations center (SOC)
· Info Sharing/cyber threat intelligence (CTI)
· Exceptions during project reviews
Please share others in the comments!
Remediation, or treatment, typically involves representatives from the following teams:
· Data governance
· Architecture and governance
· Change management
· Privacy team
· DevOps
· Project Management Office (depending on complexity and requirement to manage a budget over a period of time)
· Business owners
Treatment can vary depending on the factors articulated above: a system can be patched, taken offline, subject to a mitigating control or additional monitoring, and so on.
Continuous improvement
A risk register represents a best practice; its implementation will shift and evolve. Organizations should seek to constantly improve the processes that support the risk register, which must remain practical throughout its existence and make sense to all users. In the beginning, it might be a static spreadsheet. Over time, it may live in a web application that permits fine grain access to authorized users and connects to an organizations’ CMDB, technical vulnerability management system, risk weather map, and other reporting functions. Such a system is more conducive to tracking the time-to-remediation and an organizational goal should be to reduce this figure month-over-month.
Assign the proper resources to achieve continuous improvement, including establishing objectives for Capability Maturity Model Integration and the building the ability to measure the maturity of your remediation program. Pursue automation, especially in terms of enterprise scanning and reporting. One of the greatest benefits that can be derived from a register is the ability to update guidelines and procedures with findings in mind; for example, hardening guidance can be maintained based on sources of risk that make it to the register. Furthermore, metrics and KPIs can be derived from the register to properly incentivize and rate stakeholders, such as vendors. Lastly, share results with the broader community so businesses can benefit from your best practices, especially via Member ISACs.
Conclusion
The risk landscape is changing and there is greater emphasis placed on an organization’s ability to identify and manage sources of IT risk, which are growing with the increasing pace of digital transformation and the adoption of new technologies.
Vulnerabilities and misconfigurations pose a significant risk to organizations and present opportunities for threat actors. Systems may be deployed in a vulnerable state due to a lack of hardening or ineffective safeguards, or become vulnerable after the fact. In either case, a risk register can shed light on the nature of a given risk to a system and how to address it.
In closing, I recommend acquiring a copy of ISACA’s Risk IT Practitioner Guide — available to members — and reviewing Gartner’s toolkit on this topic. Good luck, and as Jack Jones advises: don’t let the risk register “become a due diligence dumping ground!”
About the author
Nick Deshpande, CISSP, CCSP is a Principal, Product Strategy with Oracle working within the Dyn Global Business Unit to contribute to Oracle’s Cloud Security strategy.
