Lately I’ve been having loads of conversations with both GRC and Engineering folks about both Risk Analysis (RA) and Threat Modelling (TM).

Opinions diverge on the usefulness and scope of each, and the risk-inclined often reference they achieve the same outcomes of TM with their RA, and the engineering-inclined tend to say that their TM’s already helps them address risks, so many feel these are redundant practices and that organisations maybe don’t need both.

I disagree with those views and explain my thinking in this blog post. I believe we need to look at the Genesis and drivers for each of the practices if we’re to understand the. role they both play in organisations.

First, I’d like to acknowledge that both. RA and TM have things in common. They’re both practices meant to identify things that can go wrong and aim to come up with plans which help mitigate those identified things.

But whilst, theoretically, they may seem similar, in practice they’re usually quite different and serve different purposes for different audiences.

Let’s discuss the Genesis and drivers for each of them.

RA is. typically a stage of Risk Management (RM). RM has it’s roots (as a discipline) in finance and insurance and, as such, the methods and practices it involves tend to be top-down approaches to manage medium to long-term business risks, and ensure business profitability. RM is an integral component and expectation of business and corporate governance which is expected to adhere to well accepted auditing standards, record-keeping and corporate definitions of “accountability”, with a focus on identifying exposures (inherent and residual risk) and liabilities, considering both controls (right of *boom*) and mitigations (left of *boom*). In practice, it tends to translate as CYA (cover your ass), and in my experience one of the reasons why the engineering-inclined tend to dislike it, as they see higher-ups just accept risks (things within “tolerance” or “appetite”) and most often still get their security certifications anyway. It’s practice satisfies the needs of management systems, not engineering needs per-se (this Venn diagram is NOT a circle), and it tends to use language that is focused on control, and deficit (financial language) which the engineering-inclined tend to dislike. From experience, GRC functions often spend more time and resources trying to justify why an organisation shouldn’t need to fix something, then it would take to actually fix it.

TM has a different genesis and drivers. TM emerges as a practice within Microsoft and with a focus on engineering secure systems. Systems which are to be robust, meaning they can withstand the typical threats, attacks and failure modes which Engineers can foresee or predict that their systems are likely to be exposed to. It’s a practice which emerges bottom-up, not top-down like RA/RM, and as such tends tto be more facilitated amongst peers, or at the very least between people who share common engineering language and goals, as opposed to being something mandated by the business as a requirement for good corporate governance. In terms of how TM tends to be integrated in organisational practices, is usually optimised to build a secure feature and identifying what needs to be done within the scope of a feature creation, to do it securely and not a medium or long term view of managing risks which may or may not materialise. As Adam Shostack originally wrote, the 4 questions of TM are “what are you building ? what can go wrong ? what are we going to do about it ? how good a job have we done”, so it’s grounded in WHAT WE ARE BUILDING now.

An often found problem with applying RA practices to the scope of Agile delivery practices, is that of ‘scope creep’ in that the ones mandating or facilitating RA will often identify issues which aren’t in the scope of what’s being built. This tends to generate an organisational dynamic between GRC functions (those usually leading RA) which has them being perceived as not adding much value to the Agile delivery process they’re trying to influence, as they keep asking and identifying things which aren’t in the scope of what’s being built but often other systems or concerns which are already existing problems that the Agile teams aren’t tasked with addressing at that point.

This isn’t to say that RA can’t be useful in an Agile process, but from experience, I’d argue that it’s success will largely depend on the social capital or technical expertise of the facilitator and if we’re trying to build sustainable practices, we shouldn’t be designing them in ways which are reliant on individuals possessing both business and engineering skills, as there aren’t many out there.

So, in my opinion, we shouldn’t be trying to choose between one or the other. Instead, we should be trying to ensure we’re talking Risk, RA, RM with the stakeholders whose timespan of discretion spans medium and long term cycles, and ensuring that the OUTPUTS of RA/RM become INPUTs to TM. Not as “this is all you should worry about from a security / privacy perspective” but as “at a bare minimum, please explore these areas of concern but do go ahead and complement it with your own exploration and modelling of what can go wrong here”. I call this “risk-informed threat modelling”

This approach guarantees the best of both. Satisfies the needs of the bureaucratic system of accountability of corporate governance, while promoting and connecting it (making it traceable) to an engineering practice designed to build more robust systems by elicitation and modelling of common threats to the things we build

Sorry for the long post, but the train ride was long so… 🙂