PRIDE: How to make cyber risk decisions without pulling your hair out

A redux of the RAPID framework.

Business - rather than information security - leaders should make cyber risk management decisions.

If you read my last note, you’ll understand why I believe this. Assuming you are with me, your next question should be “how do I structure these decisions?”

Well, I’m happy you asked.

To answer this question, I’ll turn to a framework from the management consultants at Bain & Company. They have developed a tool called RAPID, upon which I will attempt to improve slightly.

Please read the above-linked article for a detailed explanation of RAPID, but to summarize, the acronym breaks down the relevant parties into the categories of those recommending a decision, those agreeing to it, those performing the task(s) resulting from the decision, those whose input is considered, and the one (and exactly one) person who makes the final decision. It also provides a structure for how the various parties should move towards achieving such a decision.

I think this model is generally sound, with one exception: I really don’t like the “agree” part. Per Bain, those who must agree to a decision are “those who must sign off on it before it can move forward—executives with legal or regulatory compliance responsibilities, for instance.”

Unfortunately, in my opinion, this requirement puts us right back into the position of having advisors without holistic responsibility for the business controlling (by blocking) decisions that can be make-or-break for the organization.

Broadly speaking, the incentives for these advisors to “agree” to any given decision (especially if it involves risk acceptance) appear slight while those for being excessively risk averse are strong. I doubt many chief information security officers (CISO) or general counsels have been fired for saying “well, there is a small chance we might get hacked/sued” and then torpedoing an otherwise sound plan. Conversely, examples abound of CISOs losing their jobs for lax security practices (in some cases justifiably, because these were implementation failures). As a result of this dynamic, these advisors are likely to oppose - actively or passively - any measure that could put their jobs in jeopardy.

On top of this problem is the tendency of people to value negative outcomes more substantially when compared to equal but opposite positive outcomes (a phenomenon explored in prospect theory).

These psychological tendencies can thus cause organizations to miss huge opportunities, incur massive second-order (but not immediately apparent) losses, and/or spend huge amounts of time and energy debating what should be relatively simple decisions. If you have veto authority but are not accountable for the final decision (i.e. you are in the “agree” group but not the “decider”), however, these aren’t necessarily your biggest concerns.

Most importantly, it’s not clear how an organization using the original RAPID framework would be able to react to a situation where it is on the horns of a dilemma. It’s conceivable that there might be a situation where it would face legal/security/compliance risk when pursuing any available course of action. As a result, requiring “agreement” from multiple risk management advisors could paralyze a company.

For example, a firm might have previously signed a contract agreeing to not disclose - either publicly or to its customers - information regarding a certain type of security vulnerability in a third-party service or piece of software. At the same time, the company or its customers could suffer a cyber attack if it fails to disclose this information in the face of imminent exploitation of such a vulnerability. Although the theory of efficient breach might allow for some flexibility on the legal side, the “agree” requirement from the RAPID model could potentially freeze an organization in place and prevent it from avoiding a catastrophic outcome (allowing many of its customers to be maliciously exploited via the vulnerability) by accepting a moderate level of risk (breaching a contract term where the counter-party would not be keen to litigate due to the circumstances).

Even if this paralysis does not occur and the organization is able to make the best decision available, the RAPID model could still require the legal representative to “agree” with the analysis of the information security advisor, and vice versa. This would put both parties in the sub-optimal position of having to sign off on analyses outside of their areas of expertise in order to allow the organization to move forward.

Many people are aghast when I suggest that lawyers or cybersecurity advisors should not have the final say with respect to decisions that might incur any sort of legal or information security risk (reminder: I am not not a lawyer, so please read this disclaimer). Assuming that I haven’t convinced them yet, I would propose a hypothetical situation.

Suppose you own and operate a messenger service, and you have an extremely urgent and valuable delivery to make. Also suppose that you have a $10,000 bonus at stake, which you will be paid on the spot if you deliver the package before noon on a given day. If you are one second late, you will be paid none of the bonus.

It is now 11:55am on the delivery date and you are frantically circling the delivery address in your van but cannot find any open parking spaces. Thankfully, you finally see an opening on the curb and pull up...only to find that there is a fire hydrant there.

What do you do?

I think most people already know, but I’ll continue the hypothetical to drive home my point.

Suppose that you decide to call your trusty general counsel to figure out how to proceed. Thankfully, she answers, and you desperately explain the situation, asking if there is some way you can legally park in front of the hydrant without any risk of getting towed or ticketed. Unfortunately, after a lightning legal analysis, she cannot suggest any way for you to do so, even for just a minute so that you can run in and deliver your package.

I am pretty confident that 99% of people would simply accept the minor risk, quickly run inside to deliver the package, claim the bonus, and leave.

Although an extreme example, this scenario illustrates the fact that in the real world, business necessities can sometimes trump recommendations from specialized advisors. There will always be gray areas, and if you want to run a business - or frankly do anything - you will need to contend with this uncertainty on regular basis. Furthermore, you may on rare occasions decide to override advice from these advisors because of your understanding of the totality of the circumstances.

Now - let me be clear. I am NOT telling anyone to break the law or wantonly disregard the advice of counsel. But the important point is this: it is merely counsel, not a substitute for your own judgment.

Back to my main point and to iterate on RAPID, I would propose the PRIDE model. Everything is the same as in RAPID except for the A, which becomes an E, for “ensure consultation” with these people. They are different than the “input” group in that soliciting and receiving their advice is mandatory, rather than optional.

For critical decisions involving cyber risk, you should absolutely seek the opinion and analysis of advisors and take their views to heart. Furthermore, if you are in the “recommend” role, you should have an airtight rationale if you are suggesting proceeding over the objections of such advisors.

They cannot, however, have veto authority.

I look forward to hearing contrary opinions in the comments section, but will assume the above to be true and proceed to discussing the logistics of implementing the PRIDE model.

As your cyber risk management program matures, you should make these types of decisions systematic. One thing you can do for commonly-faced issues is to identify - by job title - who will take which roles in the PRIDE framework. For example, it would probably make sense to create a pre-built template for situations when a product manager wants to maintain a certain legacy offering or feature for a small group of customers even though it does not meet all of the requirements of your secure software development lifecycle. To address these situations, it would make sense to always run the same decision process, such as:

Perform

• VP of Engineering

Recommend

• Product Manager for legacy offering/feature

Input

• VP of Engineering

• VP of Technical Support

• VP of Sales

Decide

• Business-line general manager

Ensure consultation

• VP of Information Security

• VP of Legal

Building this type of structure gives you a repeatable process that facilitates rational analysis of common situations. It also allows you to compare similar types of risk decisions across time, potentially even facilitating quantitative analysis of the tradeoffs made.

In any case, it likely beats participating in an agonizing series of meetings where no one knows how to proceed or achieve a decision. In my experience, I find that these bureaucratic scrums eventually arrive at a “consensus” that no one explicitly signs off on or formally objects to. This leads to a muddled understanding of how to proceed and ultimately results in slow and/or poor execution. Accountability is equally obscured when something goes wrong.

Finally, make sure you consolidate everyone’s written input in one place. I’ll elaborate on the logistics of recording decisions in a subsequent post, but trying to track the genesis and rationale of previously made decisions can be challenging months after the fact. And especially so when you are under extreme time pressure, as you invariably will be.

If all of this talk about decision-making frameworks and the like seems tangential to cybersecurity, please stick with me! How you make choices regarding potential costs and benefits is fundamental to effective risk management. I have seen organizations get tied in knots due to a lack of understanding of these principles or processes, and it is well worth your time to grapple with them. Once you have a clear model for how you are going to approach problems, it is much easier to decide on and implement solutions addressing them.