Adversarial Risk Management

Imagine you are tasked with ensuring a bucket will hold water. You can examine the bucket, turn it carefully and closely examine the surface. You can run your hands across the bucket, hoping to feel any defects. You can hire a professional audit firm to benchmark the bucket against peer buckets. If you are well resourced - or it is a particularly important bucket - you might even X-ray it.

Or you could fill it with water.

As Board Directors and corporate executives around the world grapple with increasing cyber risk, we’ve historically focused on "bottom-up" cyber strategies based on compliance frameworks. We chase concepts that seem simple, such as "basic" network hygiene, asset management, and patching. But these approaches rely on tenets based on traditional operational and financial risk management. Namely, we are working under the supposition that 90% is really good - and certainly twice as good as 45%. While “close enough” works in asset management for financial inventory, it can quickly prove useless in cybersecurity. Likewise, while every reduction in fraud loss provides a quantifiable gain, cybersecurity deals in binary events where a single intrusion may prove an existential event. To fill the bucket, we must shift our mindset away from inch-deep, mile-wide program sweeps and instead focus on laser-targeted specific attack scenarios that are supported by active threat intelligence. To avoid becoming a headline tomorrow, we must practice adversarial risk management.

What is Your Adversary's Goal?

• • Data Theft (further broken into IP theft, PII theft, or Customer Data theft)
  • Financial Fraud
  • Extortion and Sabotage (historically separate but recently bundled to reflect the similarity in tactics)
  • Resource Hijacking
  • Data Manipulation

At the highest level, we need to provide candid analysis and be as smart as our adversaries when we evaluate the likelihood and impact of each Threat Objective at our firms. It is easy to broadly say that all data is strictly confidential, or that you must protect against competitive corporate espionage, but in today's wartime environment those platitudes can divert essential resources from imminent threats. As an accounting firm, is your biggest competitor likely to try and intercept your communications, when they would run the threat of a massive criminal investigation? If you are a consumer SaaS service, would it benefit someone to steal your source code and duplicate your intellectual property, or is your competitive advantage really in execution and customer service?

It can feel neglectful to downplay a risk, but mature risk management must prioritize the probable over the possible. Whether it is from an internal dedicated team, a third-party provider, or even reading the news, the likelihood of Threat Objectives needs to be supported with substantiated facts. And when it comes to assessing the potential impact to your business, only a key business stakeholder can evaluate impact. The junction of threat intelligence with your thoughtful business deliberation will produce a map of the Threat Objectives you really need to focus on and, in turn, your cyber mission. And establishing your cyber mission is a much more effective use of senior management and Board time than looking at charts of the number of laptop thefts or how your patching percentage has been improved from 87% to 94% last quarter.

Put Your Team in Their Shoes 

Armed with a clearly articulated and focused mission, your cybersecurity team can turn to control testing. Rather than beginning with a tick list of 400 compliance and audit-driven program measures, beginning with an intelligence-driven set of top Threat Objectives directs testing activity. Perhaps those objectives are routed to a Bug Bounty program where hundreds of crowdsourced hackers can test your public-facing security, or perhaps it is a commercial Red Team of ethical hackers using the most sophisticated methods to penetrate your networks. Use an "assume breach" methodology - where vetted testers are given the level of access available to an entry-level hire - to compress timelines and perform "what-if'' scenarios as if an employee were phished, socially engineered, or (less likely) a malicious insider. As you pivot from automated scanners and questionnaire-based audits to competent, well-resourced ethical testers armed with specific realistic missions, the findings you identify will gain fidelity and focus on issues that can directly lead to the outcomes you are looking to avoid.

As your testing generates findings, integrate exploitability as a top factor in your risk scoring, so public-facing vulnerabilities are prioritized significantly over those limited to an authorized audience. In the short term, you will detect immediate, exploitable issues that could lead to your nightmare scenario tonight. In the long term, the nature and volume of your findings will expose themes in cultural behavior or technical practices that will drive the most value through remediation. If software bugs are leading to compromise, you can justify a targeted investment in engineering quality assurance. If cloud configuration errors are your top contributor, you can focus efforts on cloud security and change control. If known operating system defects are your leading culprit - they won't be, by the way - you can justify an all-hands effort on patch management. And when they aren't, you can avoid waylaying an engineering organization and undermining credibility sending them on Sisyphean tasks.

Nothing is more powerful for gaining the trust and collaboration of engineering, operations, and business teams that are so critical to remediation than the screenshots and demonstrated exploits that come out of testing. Engineers operating in an Adversarial Risk Management program brag about their security department, race to fix problems, and evangelize cybersecurity across their network. How different is that to historic structures where engineers roll their eyes when tasked with academic findings about changing the encryption cipher suites offered on an internal server or decommissioning an air-gapped, non-critical Windows98 PC?

Cracking the Code of Third-Party Risk Management

The Adversarial approach offers hope for third-party risk management as well. When forced to ask "what plausible scenarios could occur with this supplier?" the result is a set of specific, targeted questions. If a vendor holds critical data off-site, a focus on Data Theft controls such as data leakage protection is warranted. If the vendor provides a mission-critical service, perhaps the focus should be on denial of service, lateral movement and other Extortion and Sabotage related controls. Likewise, when a Board is looking for assurance around an internal program, perhaps it is time to independently engage a Red Team to test specific scenarios at the Risk or Audit Committee level.

Board-commissioned Red Team testing is an aggressive concept today, but the most effective global regulators are already pivoting to that approach. It is only a matter of time until any third-party cyber assurance need - from Board governance to vendor management to insurance quoting - is driven by Red Teaming. We must articulate our scenarios of concern and support them with threat intelligence and hands-on testing to gain meaningful improvements and assurance.

Finally, we need to accept the fact that Adversarial Risk Management is a never-ending process. The sophistication and efficacy of an Adversarial program will be measured not by its end-state, but by its agility and pace of improvement.