The Risk Acceptance Myth

The notion of "Risk Acceptance" has always challenged me. For the uninitiated, Risk Acceptance is a concept often discussed in cybersecurity leadership when it comes to accountability for cyber debt. The idea is that cybersecurity leaders and other professionals identify risks and recommend mitigating actions that would reduce that risk, but recognize that it is always up to business leadership to weigh the costs and benefits of change and make a final decision. Risk Acceptance has always come up during CISO conversations in contexts such as "well you can tell them they are crazy all you want, but if they won't accept your advice you need that CEO/CIO/CFO to sign off and show they are accepting the risk so you can prove you did your job". The concept is tied to the ideas that when things go wrong, you will have the opportunity to make your case and show "Risk Acceptance" as proof that it was not your fault - but the incompetence of business leadership - that led to disaster.

I think that's a farce.

The Risk Acceptance myth works against a perpetual business truth:

Cyber leaders need to digest that and carry it top of mind at all times. After a cyber disaster, nobody follows the headlines around with a set of footnotes about the proper people to blame. If there is a security issue, the fingers will - and should - be pointed to the Chief with "security" in their title.

Yet time and time again, we hear about cyber and risk professionals in a conundrum around disagreement with whether proposed initiatives are worth pursuing. I've had over 25 years of opportunity to observe this phenomenon. Sometimes I saw it when my own teams bellyached about their identified risks going overdue. Even more times I heard it in CISO roundtables and conference discussions about their day to day pains. And in light of the current litigation around Tim Brown - embattled CISO of Solarwinds - it gets brought up anew. But it never sat well with me.

The "Risk Acceptance" idea is that a CEO or similar business leaders signs a memo saying something esoteric like "We understand and accept the risks identified around running 2,348 assets that have identified vulnerability scan results with CVSS scores exceeding 7.0". That, of course, means absolutely nothing to a lay person. But it is portrayed as the equivalent of "We understand the front door is unlocked, the windows are wide open, there are piles of cash in view from the street, and there is poor lighting around the entrance of the house".

Many feel the issue is in communicating "to the business" that such an esoteric technical statement is as serious as the simple metaphor I painted above. The idea is that the threat of formal "Risk Acceptance" will beat the insanity of such an agreement into the executive's head and lead them to reverse course and free the resources needed to stop business and get 2,348 things patched. But it never happens. And the eye-rolling and bellyaching continues.

But the undocumented part of the story is that NOTHING BAD HAPPENS. These thousands of risk acceptances don't lead to the ransomware incident, the big wire transfer heist, the massive PII breach, or more. While every incident can point out some missed opportunity for improvement or hygiene lapse, I can't recall a single "Risk Acceptance" memo dragged into court.

Acceptance and disagreement are dramatically different things. CISOs leave the room thinking their memo says "Dear CISO - we understand that we might get hacked at any minute and are fine with that. Love, The Business." But in reality, these memos are saying "Dear CISO - we think you are totally off your rocker and letting perfect be the enemy of good again. This is real life, and we can't affort to patch every little thing when our own engineers tell us your findings are devoid of context and unexploitable in real life. This will never come back to bite us, and it's easier to sign off here than try to get you up to speed on reality. Love, The Business".

Many organizations log hundreds or even thousands of Risk Acceptance tickets, memos-to-file, or similar sign-offs each year, and that is extraordinarily unhealthy. Organizations need room to recognize Risk Challenge and Risk Disagreement to bring sanity to the conversation. The fact is that the software developers, technical account managers, and site reliability engineers know the facts on the ground. There must be a way for their input to get fed into the risk assessment process for scoring to have a chance at accuracy. A security organization issuing pronouncements on prioritization from on high will never achieve high fidelity scoring.

Tips:

• Align your risk scoring team - likely Governance, Risk, and Compliance (GRC) closely with hand-on technical testers like the Red Team or Application Security.
• Hire people from "the business" into security. Someone on your SOC should have worked the phones before. Someone in AppSec better have been coding your product at some point. And someone operations should be involved in your architectural review process.
• Pictures or it didn't happen. Before you issue a "critical" finding, reproduce the exploit and share screenshots of video. Use those friends in the Red Team if you have to. Or just trash your vuln scanners for a Bug Bounty program and get video recordings alongside every submission.
• Build an unemotional "challenge" process into your risk issuance process. Teams on the receiving end should be permitted and encouraged to explain why a risk is overrated and educate the issuing team. If you are in the camp of "too many findings to test and screenshot every one" then this is your force multipler moment. GRC can't dig into every tiny item, but when you allow the receiving parties to challenge them, they have a much smaller number of findings per team and much more motivation and access to test them for you.
• Collaborate on compensating controls. Work with engineering and IT to identify low-cost simple moves that can materially reduce the risk rating without the dramatic high-impact initiative you are pressing. Move systems off the Internet. Kill egress from unpatched devices. Use Enterprise Browsers to inject step-up MFA in front of frozen legacy codebases.

Eliminate "Risk Acceptance". Encourage "Risk Disagreement" and build the relationships you need to get risk scoring right.