Former Assistant Secretary of DHS for Policy Proposes ‘Adversary-Based’ Approach to Cyber Security

Stewart A. Baker
GSN: Government Security News
April 17, 2012

The drumbeat of concern about cyber security is almost deafening today.  And corporations have good cause for concern.  Recent high profile attacks at all types of firms — even ones that specialize in security — show that no one is safe.

The government has taken notice, and pressure on companies to address the problem is on the rise.  In my experience, though, corporate boards and general counsels don't get the strategic help they need from their corporate security and IT departments.

The problem, as I see it, is that companies treat cyber security like workplace safety or advertising, where following a checklist or making sure you spend as much as your competitor is enough to get by.  Unfortunately, while checklists may work for safety issues, they aren't much good against an adaptable, thinking adversary.  And keeping up with competitors only works in situations where, in the words of the old joke, you don't have to outrun the bear.  Again, that won't work in cyberspace, where the attackers have the numbers and the appetite to eat everyone.

So, why not treat cyber security like litigation? In planning for litigation, you begin by asking, "Who might sue us?"  You might look at personal injury lawyers, or patent holders, or state regulatory commissions, asking for each, "What companies are they targeting, and am I in their sights?"  If you are, you next look at the tools and tactics each of them uses to go after the companies they target.  Finally, you take steps to blunt their likely tactics — starting with a plan for who you’ll call and what you’ll do when they show up on your doorstep.

That same approach also works in the adversarial world of cyber security.  There is an entire ecosystem of attackers today: cyber-criminals looking to make a buck; hacktivists trying to make a statement; state-sponsored cyber-spies looking to steal the hottest secrets; and disgruntled insiders wanting to steal information or leave behind code that sabotages corporate operations.  What's new in the last year or two is how much we know about each of them.

And so, for the first time, it's possible for a company to analyze its risk by first asking, "Am I of interest to any of these hackers?"  If so, the company can then ask, "What's the worst that can happen to me if one of these hackers compromises my network?"  The final step is to ask what it will take to defeat the hackers.  By focusing on the adversary, we can begin to assemble a tailored set of security measures, prioritized according to the risks presented by each attacker.

What I find most appealing about this adversary-focused security framework is that it allows corporate boards and general counsels to approach the cyber security problem strategically.  By looking separately at each adversary's goals, it is possible for general counsels and corporate boards to analyze the potential cost associated with a successful attack.  That cost provides a guide for the board and top executives to the kinds of security measures that make economic sense.  And it allows the board to set broad goals and priorities at a strategic level, such as, "Above all, make sure no nation-state can modify the source code that serves our customers."

Why isn't this approach already the standard, insisted upon by corporate boards, executives and lawyers?  I think the problem is mainly a lack of information.  Boards are used to cyber security briefings that either make their hair stand on end or their eyes glaze over.  Either way, they suspect that they're being asked to approve expenditures without any real ability to measure the expenditures' value.  As they begin to discover how much we know about even nation-state attackers, the value of an adversary-based security analysis will become obvious and the switch will happen quickly.

Stewart Baker, a partner at Steptoe & Johnson LLP, is former Assistant Secretary of Policy at DHS. He can be reached at: