It is often the case in risk practice that the risk assessment becomes an activity in going-through-the-motions: because so many risks are well known and theoretically well-controlled. This certainly cannot be said for the cyber risk domain, which is a novel and evolving field of risk. Dealing with novel types of risk can often be a good catalyst for novel uses of risk techniques, and the use of bowtie risk assessments for cyber security are a good example of this.
The ISO 27000 family of standards provides a solid backbone for information security risk management. It takes many of the tried-and-true approaches from other quality system standards (such as ISO 9000), and introduces some new ideas to assist with managing the complex world of cyber security.
The ISO 27005 standard for information security risk assessment is fairly non-prescriptive as to which risk tools to use. The standard talks about qualitative and quantitative risk analysis options without delving into the detail of how these methods can be applied.
This is where bowtie risk analysis tools can be a real asset. Bowties can use qualitative or quantitative analysis modes. Some of the typical benefits of using bowtie together with ISO 27005 include:
- A good bowtie analysis tool supports all the requirements of 27005 for identifying assets, cyber threats and vulnerabilities, assessing risk, etc.
- The bowtie itself is a far better tool for modelling cyber risk than table-based methods. The bowtie maps out the threat lines which can drive cyber security incidents, giving the practitioner better visibility of how the unfolding risk event can be controlled.
- The bowtie allows the practitioner to use qualitative or quantitative analysis interchangeably using the same overall threat model. This provides flexibility along with robustness of the analysis itself.
The remainder of this article will look at how bowtie risk assessments can be used within the ISO 27005 structure. For an overview of how bowties actually work, read our quick start guide or check out the value of using bowtie risk analysis. For a fuller picture of cyber security risk management, we recommend reading the ISO 27000 standards in detail, and also the links at the end of this article.
Risk identification – assets, threats and vulnerabilities
(ISO 27005 section 8.2)
The process of risk identification can be viewed as pre-populating some of the data that will need to find it’s way onto the bowtie. What we’re looking to accomplish is:
- Identification of the assets: which are the reason we care about the risk event. Our bowtie models a risk event affecting a valued asset, and the consequences of the event are defined in terms of the harm to the asset.
- Identification of the threats: which are the drivers of the risk event. Our bowtie will consider these threats as potential incoming causes of a risk event, and we need to consider all threats as part of our analysis of the vent.
- Identification of the vulnerabilities: which are the precise interactions through which the threats can cause harm to the assets. The vulnerabilities often define the risk events for the bowties themselves, or shape the range of scenarios that a bowtie is intended to cover.
- Identification of the consequences: which are the impacts of the threats on the valued assets, giving us a tangible measure of the harm itself.
The mapping is not always one-to-one. However, a good starting point is to consider that:
Every asset has a series of risk events associated with it, with the consequences defined in terms of harm to the asset.
For example: our servers contain sensitive data, and we would be concerned about unauthorised access to that data.
Every vulnerability becomes a risk event which contains both threats and harm to assets.
For example: our data storage servers can be vulnerable to unauthorised virtual or physical access. This might be through undocumented back-doors, lack of physical controls, etc.
Every threat becomes a cause of certain types of consequence.
For example: malicious software (malware), which is a threat that can exploit back-doors which have not been closed off.
Every consequence is a tangible definition of the impact, fleshing out how the asset harm translates into tangible loss.
For example: our servers can suffer loss of data confidentiality, meaning we suffer financial or legal losses by allowing the data to be compromised.
From these examples, our bowtie starts to look like the above. We’re simply pre-populating our bowtie with the elements of risk that we have identified.
Bowtie risk analysis in a cyber context
(ISO 27005 sections 8.3 & 8.4)
The goal of our bowtie risk analysis is to build a realistic model of the scenario which can also be used to analyse and evaluate the risk. The standard works to the same model provided by ISO 31000:
risk = consequence x likelihood
The selection of qualitative or quantitative risk analysis simply determines the way that we input our assessment into the model (and the output thereafter).
- In qualitative analysis, our likelihood and consequence are defined in terms of a scale. Our selections on the scale correspond to intersections on a risk matrix, giving us our risk rating.
- In quantitative analysis, our likelihood is defined in terms of frequency (x times per year) and our consequence in terms of quantitative severity (pre-determined by the risk team). If we still want to have a risk rating, we can map these onto a risk matrix (this is called semi-quantitative risk analysis).
If you’re using a good bowtie analysis tool, this whole process should be straightforward.
Carrying over our earlier example, qualitative risk analysis looks like the above. We rate incident likelihood according to our scale. In many cases we would want to have descriptions on our scale (e.g. possible = could occur in the next 5 years). Our consequence is set in terms of a consequence category, and then the level of harm within that category.
The thick and thin lines in the example above show that our qualitative bowtie is actually being underpinned by some background maths. The combined likelihood of all the different causes (any of which could lead to the risk event) is used against the consequence to produce a risk rating.
The obvious value of this particular bowtie tool is that we can swap across to quantitative analysis with ease, because of the maths going on in the background.
In the semi-quantitative example shown above, we’re now defining our cause likelihood in terms of frequency. We’re still using the consequence scale, but the consequence ratings correspond to defined number values.
What we’re left with is some sobering numbers: in the absence of any controls, we’re looking at between 2 and 3 incidents of unauthorised access to our servers every year. Each cyber incident potentially costs us between $1 and $5 million in contractual penalties.
It becomes logical to follow through on this risk assessment to the risk evaluation process. Following the ISO 27005 guidance, our evaluation should consider:
- The value of the asset concerned: we can see that the security of this asset is particularly crucial, given that a single incident can cause up to $5 million worth of loss.
- The business impact of the event: we can see that this event would have a relatively confined range of impacts, mainly limited to harm to our finances and business relationships. This risk event would probably be more concerning for us if we had, for example, identified that we would expect denial of service which would impact on our ability to continue operating the business.
We would need to have a complete library of risk assessments like this before we could fully evaluate our risk priorities. For the purposes of this exercise, we can probably fall back on the logic that any risk rated as “high” is unlikely to be tolerable for the business without proper controls.
Risk treatment and cyber risk controls
(ISO 27005 sections 9.1 & 9.2)
We move now into evaluating the best strategy for managing this risk. According to the standard, we have four basic options:
- Risk sharing: unlikely to be a viable option, as we are already sharing the client’s data security risks. We could outsource security but it may not be the best alternative. Conventional risk sharing or risk transfer in the form of insurance is not likely to be sufficient given the scale and frequency of the potential loss.
- Risk avoidance: data security is part of the data storage service we offer. We cannot avoid it or move to an alternate type of operation. Our servers need to store client data, and we need to be able to access those servers via a network with internet connection.
- Risk retention: the risk is rated as high, with up to $15 million in losses occurring per year in the absence of controls. Retention without further modification does not present as a viable option.
- Risk modification: the logical (and only remaining) option. We already have some existing controls. We may need more.
In the bowtie software we’re using for this exercise we can flag risks as “monitored” or not. We can also set the risk strategy. This bowtie would be set to “risk modification” and “monitored”. Once we have a few risk assessments in there (see below), there will be only a handful that we will be monitoring. Risks that we choose to avoid entirely or substantially share are much lower in our risk management priorities.
In our example above, we’ve already started to delve into the risk modification process. Our risks relating to office break-ins and unauthorised disclosures have already been brought down to a tolerable “medium” level of risk.
Our risk treatment for the data storage servers risk bowtie therefore needs to bring the risk down to a comparable level. An inadvertent data disclosure has a higher consequence according to our assessment, but is much less likely. The servers can therefore be seen as a higher priority for risk treatment.
Going by the standard, we need to consider constraints such as technical limitations, budget, and operational constraints. In the example of our little data storage company, ethical constraints are less of an issue because we are unlikely to go down the path of “hot pursuit” of hackers.
A good approach to bowtie analysis is to work on the cause side (line-by-line), and then the same on the consequence side. Cyber security risk is similar in many ways to process risk: we’re dealing with process-driven risks, with opportunities for layers of protection which will likely be effective against several different types of failure.
In our example above, we’ve gone to the extent of describing the control strategy using the 27005 descriptions. This helps to validate our risk treatment selections: if we have a good balance of prevention, detection, and recovery, we are far better protected than if we rely on one type of risk treatment. We’re also rating control effectiveness so that our bowtie software can automatically calculate the residual risk.
So for our threat of physical attack on the servers, we have a deterrent control in the form of CCTV monitoring of server room access. It’s only partially effective, because it relies on human behaviour (i.e. the responsiveness of the attacker to be deterred). The physical access controls are a better control, because they physically prevent access. They are mostly effective but can still fail if an attacker is determined to break through. One of our last controls in the sequence is locking down of device interfaces, such as USB ports. This is an elimination control which is partially effective: it eliminates one method of physical attack, but not all.
Moving to the consequence side, we have cyber insurances helping to offset financial loss. Our risk treatment here can only minimise the impact. It’s mostly effective (given that we’re still likely to suffer financial loss in the form of excess or increased insurance premiums). To help mitigate the reputational loss, we’re implementing some credible recovery methods. Our re-establishment of data security is a mostly effective recovery control that renders the environment safe again. We can then apply our restoration of data integrity control, which is a corrective control, and is only partially effective given that corruption of data is only one of the problems that our clients would be concerned about.
Applying this logic throughout the bowtie, we arrive at a residual risk position of low. That is an acceptable risk position for us, but it is dependent on the controls being effective as we suppose them to be.
So our acceptance of the residual risk is, as always, conditional on the verification of control performance and monitoring of changes to the risk. Those activities can actually pull data from the bowtie as their basis.
In our bowtie software, we can extract the critical controls from our bowtie to be audited at regular intervals. We’ve already set the risk to be monitored, which means we will be regularly reviewing the risk position.
This straightforward application of bowtie analysis to ISO 27005 practice makes the whole cyber risk assessment process substantially more robust (and efficient). We have a balance of qualitative and quantitative analysis, and we have far better visibility of the threat pathways than if we used a conventional spreadsheet-style risk assessment template.
To complete the ISO 27005 risk picture we need to use the risk management software elements of our bowtie software. This takes us into in-field auditing, risk review, and live dashboard reporting. You can read more about this approach in a critical control management context in this article.