Risk management and risk assessments, in particular, are complex – they require cross-domain knowledge and generally don’t deal in absolutes. Threats, vulnerabilities, and asset intelligence is combined, weighed, and assessed, leading to the construct of a risk assessment document.
It can be easy for security or IT service management (ITSM) pros to overcomplicate this process, which in turn (in my experience) often leads to far wider-reaching consequences (the business starts to bypass security management or take short cuts), so this short article is offered to share what I’ve seen working well out in the real world.
To start, let’s try to align on what exactly a risk is.
What is a risk?
The following, based on NIST (the National Institute of Standards and Technology) terminology, is a definition of an information security risk:
Risk is a function of the likelihood of a given threat-source exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.
Note – the ITIL 4 risk management practice also offers risk-based definitions.
This leads us to need to understand threats and vulnerabilities:
- Threat – The potential for a threat source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.
- Vulnerability – A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.
Risk management is then the combination of risk assessment and risk treatment.
Quantitative vs. qualitative risk assessments
Risks assessments are not black and white, they’re many shades of gray.
There are many different frameworks that can be leveraged such as:
- OCTAVE – the Operationally Critical Threat, Asset, and Vulnerability Evaluation
- FAIR – Factor Analysis of Information Risk
- NIST RMF – NIST’s Risk Management Framework
- TARA – Transference, Avoidance, Reduction, or Acceptance.
Risk management and real-world experience
Over the years that I’ve been consulting and working on many sensitive IT projects, some key risk management principals seem to apply to improving security posture while also ensuring business flow is enabled.
To help others, I’ve created a list of ten key elements that I think enable risk management to bring about business value (and of course to increase the security posture I so love!):
- Construct a risk appetite statement, this will set out the organization’s risk tolerances and define a risk acceptance policy.
- Risk assessment should be preceded by asset discovery, “crown jewel analysis,” data flow modelling, and threat modelling.
- Leverage a risk assessment method that works with your organization’s stakeholders, overly complex formulae for risk assessment and a convoluted process will greatly reduce the value of the risk management process.
- Risk statements must be relevant to the audience/business.
- The risk management discovery process should include views and viewpoints from a range of areas.
- Risks statements should be pragmatic and deal with relevant threats and vulnerabilities.
- A risk assessment should be conducted with a sound understating of the business and equally a sound technical discovery.
- Risks assessments should include a statement of the current-state controls.
- Risk assessment must include risk treatment plans, without these the output of the risk management process has severely limited value.
- Risk management needs a working group/committee etc. to review and work through the risks, it’s important there is sufficient representation across domains so that focus is not only in one area, e.g. availability.
There’s no one definitive way to manage risk. Each organization should adapt and adopt good practices and I’d strongly recommend tailoring a risk management and assessment framework (oh and keep it as simple as it can be to achieve the goal).
Generally, the key aims of risk management are to provide a view on current state assets, threats, and vulnerabilities and to enable the business to deliver its mission of ensuring that all corporate, legal, and regulatory requirements are met.
Hopefully, some of the ten tips in this article will help you avoid a messy risk management meeting or two! What else would you add to my list?
Daniel Card began his career within the IT support arena over 17 years ago, and he rapidly worked his way up from frontline services to technical and solution architecture within the first few years of his career, working with a broad range of global companies. This helped him to develop skills in a wide range of both business and technology domains, spanning technical operations, service management, and solution architecture.
Daniel has spent the last 11 years consulting, with a focus on IT strategy, IT business management, enterprise architecture, service management, and cybersecurity.
As the Owner and Principal Consultant at Xservus Advisory Services, Daniel’s mission is to empower businesses to leverage people, process, and technology to reach their ultimate business objectives.
Good set of pointers on having a less risky Information-Security Risk Management in place…