Madness: The Art of Not Caring

Using risk as a tool

One of the biggest challenges in security is the overwhelming number of problems that there are to solve. It doesn’t matter which field of security you specialise in – I’m sure you’re able to create a laundry list of “sus” activities and problems that you would qualify as sub-prime. Paranoia, or at least the assumption that something is wrong somewhere is arguably part of the mindset of being a security professional.

This challenge is even more daunting when you’re the CISO. Security problems are complex and nuanced, and they grow in number exponentially with the size and complexity of your business. Often, these are problems that you didn’t create, but as the leader of the security function, you’re “de facto” on the hook. If a security risk materialises that you did not adequately identify or address, you may find yourself on the business end of the boom stick when it comes to the consequences. There are too many problems for a security function to single-handedly address, but you can’t afford to ignore them because one day, the closet’s gonna open and people will see the skeletons.

So, what’s the solution to this? Solid risk management. I know… to some people the words “risk management” sound like the most boring thing in the world, but I’m convinced that done properly it’s pure genius. “Why so?” you may ask. The answer is simple: good risk management gives you a common language that you can use to communicate to the rest of the business in a way that makes sense to them, helps you to filter out unnecessary noise and focuses on decision making. I’ve found a model that I think works well, and while there’s tons of room for improvement, I think it establishes a good foundation for how to manage risk.

What should a risk management framework do for you?

At the risk of this being a career killing statement, let me make my position on risk clear: As a head of security, I reject the notion that I should be wholly responsible for risks that the business may hold where a) I have committed effort to identify those risks and b) I do not have the ability to directly (or even indirectly) mitigate that risk.

If you’re driving, and I tell you that we’re going to run out of fuel in 50 kilometers and that there’s a gas station before we run out, and you choose to not to refuel – that’s a “you problem.” Fundamentally, a good risk management framework must allow you to adequately delegate risks to those risk owners who have the authority or the agency to mitigate a risk. While that might sound simple in our car analogy, it’s not as easy to execute in our “security world,” because while everyone gets the concept of fuel, not everyone grasps the finer details of risk management, nor do they understand what to do when you say something is high or low risk.

To make that easier, you want your risk framework to do the following:

Create a common language of risk (especially the impacts of risk) that is both granular and consistent so that risks in one area of the business can be meaningfully compared and measured against risks in other areas of the business
Establish and encourage quantitative measurement and analysis over qualitative or subjective definitions
Measure big risks (strategic or enterprise risk) & small risks (operational and dynamic) by making use of a risk formula with a shared number space that allows you to easily differentiate between differently sized risks
Differentiate between high impact/low likelihood risks vs low impact/high likelihood risks by giving your impact greater weight than your likelihood

A framework with this criterion should allow you to create an environment whereby risk owners understand the gravity of the risks they own, with respect to the business, and are empowered to make decisions about them, independent of the constant handholding of a security / GRC function.

Risk is the tool

A key part of my system of security assurance involves the automatic creation of risks for any security issues that you discover. As I implied, you want to assign these risks to the asset & application owners, so that they are aware of them, and can resolve them. Security assurance is therefore less about ensuring applications are 100% secure (an unrealistic goal), and more about ensuring that security gaps are discovered, recorded and communicated to those who have the agency to address them.

A key benefit is that this then positions security subject matter experts as consultants within your business, rather than owners of problems they often can’t resolve. This also creates space for security to assure a wider scope in the business, because they’re there to find, prioritise, and offer advice on how to resolve problems.

Materiality

On the surface, it would seem that I’m proposing that we create as many risks as we can, for every problem we can see. And while you can do that, you will hit an unmanageable wall of risk. The more of something you have, the more mundane it becomes, and you want risks to be meaningful. If everything is a risk application owners will see risks as unimportant, because they don’t reflect the reality of the situation. You need to be cut-throat with how you define a risk and you need to ensure that they are grounded in reality. As a general rule, you shouldn’t raise risks that don’t have a clear material impact to the application or to the business. This implies that risks should be specific, measurable, and generally controllable. If a risk doesn’t have these attributes, I would argue that it’s not a very valuable risk.

Generally, I have found that it helps to write risks formulaically where the threat and vulnerability are clearly articulated. I like the “due to X there is a risk that Y will occur, resulting in Z.” For example: “Due to the front door being unlocked at all times there is a risk that anyone can walk into the front door and steal items. This will result in a loss of property.” This makes clear what the issue is that’s causing the risk, what the impact will be, and gives some path to resolution (making sure the door is locked).

This stands in contrast to an overly generic risk like this: “Due to the fact that there are other motorists on the road there is a risk that employees could be involved in accidents which could result in the inability to work, or death.” Sure, this is real, and true, but for most businesses it’s not very useful. You cannot really control other motorists, or the ways that employees arrive to work. While I’m exaggerating here with the obviousness of this risk, the point remains that you should avoid having a risk register of overly generic risks which don’t lead to any resolution or improvement.

Operational & Strategic

The materiality test makes for a good first “filter” for your risks. If it’s not material, it shouldn’t be a risk. There is however, an exception to this, and that’s when using the second filter becomes helpful – the classification of risks as operational or strategic. For the most part, we’ve been talking about operational risks: those that arise from the specific context of an asset or activity within the business, rather than those that arise from a set of assets and activities – trends in your business that aren’t easy to perceive from an individual risk. This latter category is what I like to call strategic risk, and we need to make space to model and track it as well.

Take for example this strategic risk: “Due to the lack of specific visibility and certainty of controls over our processing of personal data, there is a risk of inappropriate data processing which may result in actions from the regulator on our business.” This is a very real risk for many businesses, however it’s really difficult to manage as a statement. How do you measure your controls on data processing? Well, we have the answer – through operational risk! By correlating all the context (asset, application, etc.) specific risks you have around data processing into a parent/child relationship with this strategic risk, you create a place by which you can describe an overall problem in the business, and measure the rate of change of that problem space through the changes to all the related operational risks.

There’s a couple of wins you get with this approach. First is that you can focus on strategic risks as the key health metric for your business and use that at the senior management and board levels. This is something that operational risks aren’t well suited for because they are dynamic, being created and closed on a regular basis. What senior management cares about is the aggregate position on those problems, and strategic risks allow you to measure that without digging into the minutiae of all the operational risks.

The second win is that your strategic risks are fundamentally grounded in the reality of your operations. They aren’t static or dead because the approach of making strategic risks a sum of operational risks (or at least creating a strong relationship) means that you can still see them change, as the underlying risks arising from individual assets change. This makes strategic risk management valuable, as you can use it to identify larger problems and create larger programmes of work to tackle them.

Functional Risk Appetite

If you recall in an earlier post in the series, I talked about being pragmatic. We can’t avoid risk, it’s part of life, and part of business. However, we also can’t ignore it, nor can we mitigate all of it. Resources are finite, so we need to define how much risk we’re going to accept as part of doing business, and how much is too much. This is called risk appetite.

Following the operational and strategic classification of risks, risk appetite should be defined on 2 different levels. There’s the high-level strategic risk appetite, generally expressed as one or two numbers which says how much total risk you should accept as a whole business. Then there’s the low-level operational risk appetite, which is there to give the average risk owner a threshold for when they can decide the treatment of a risk, versus when they can’t – like when their risk is big enough to impact multiple areas of the business and therefore crossing into a territory where they shouldn’t unilaterally prioritise or decide treatment on their own.

This separation is important because the appetite threshold for a strategic risk is for managing your business, and not for managing individual risk. It’s a health metric for steering. It’s also a litmus test for your framework, because if the average risk owner manages risks that exceed your overall business appetite, something is dreadfully wrong about either your model or your appetite for risk.

With sufficient automation, your operational risk appetite can allow your risk owners to self-police. If they decide to accept or not deal with a risk that’s below the threshold – that’s ok. You’ve empowered them to make decisions with the resources they have, and they can fully own that problem. The risk owners now get to prioritise their risks with respect to their impacts, taking into consideration the other business risks and priorities they have, and you, as a CISO, can be comfortable in the knowledge that a risk was identified, attributed and acknowledged – which means you don’t have to care about it anymore.

The use of risk appetite is also why it’s really important to create a common language of risk across all areas of the business, and why it’s implicitly important to get all areas of the business to double-down on risk management. Fundamentally risk management isn’t a tool for security, it’s a tool for the business. The business needs to weigh up security risks (and the associated costs of mitigation) with commercial risks, legal risks, and any other potential areas of risk.

We’re going to need a bigger boat

If you haven’t sussed it out yet, you’re going to need some tooling and a workflow to really accomplish this. Excel or Sheets just won’t cut it, and I would generally advise that a Governance Risk and Compliance tool is critical to the success of this systematic approach to security assurance. A GRC tool is what allows you to make a record of your assets, and a record of your risks. A good GRC tool will allow you to create relationships between your records and automate things such as risk discovery. But there’s a lot to unpack in terms of tooling, establishing a workflow and getting to a stage where you can effectively assess things and create risks. Unfortunately, that’s too much for this article, so we’ll have to explore all of that in the next one. Stay tuned!