In my work I will often challenge people to describe what they mean, specifically, when they say they can’t do something because of risk. The criteria often seems to be, “does risk exist?”, which explains why they never do anything—the answer to that question will always be yes.
A more salient question is, “is the risk material?”. Many don’t know how to answer that question and the ambiguity leads to either decision-making paralysis, or an overly-complex controls environment which does not serve the needs of the business (because it’s not designed to—it’s designed to cover the a** of the security organisation).
The ambiguity of materiality is an invitation to risk management maturity. Yes it is contextual, but so is everything else about risk and decision-making. Materiality is simply a fancy word for a subject you already understand: articulating the impact of a cyber breach, and its relevance to your business. Something that (hopefully) your 1st and 2nd line risk functions are already experts at.
This has got a lot more important lately, because the language of materiality is so key in the SEC’s 8-K filing requirements. You will find no concrete definition of materiality, only that it depends on the impact of the breach to your business, shareholders, and your broader regulatory and legal landscape. If you look to the regulators to answer the question “is this material?” they will only look back at you and say, “you tell me.”
So cultivating a more sophisticated relationship with risk, which already has constructs for how to understand the material impact of breaches, is the best way forward. Two practical questions to consider:
–Do we have the right preventative controls in place to take commodity attacks off the table, and significantly increase the complexity required to successfully breach our organisation (and therefore increase the likelihood of discovery for the attacker)?
(Fun exercise: ask your security leaders this question, then go ask the security engineers and analysts on the ground, and compare their answers. You may find, as physicist Richard Feynman did in his famous report on the Challenger disaster, that the risk assessment of the leaders vs the engineers differs by a factor of 1000.)
–Do our detective controls give us the data we need to assess materiality, i.e. what was touched, when, by whom, etc? If not, what are your vendors doing about that? Here’s a very practical example: many people depend on capabilities like screen recording (in PAM tools, for example), but there’s no screen to record in an infrastructure-as-code world. Can you tell the story using data instead? If not, what are your vendors doing about that?