Product security: barking up the wrong tree

AppSec is fine. We're not paying enough attention to corporate infrastructure risks.

We’re going through a period of renewed public interest in information security. We see seemingly endless reports of high-profile breaches, such as the recent Russia-orchestrated Microsoft hack. We hear persistent innuendo about the vulnerability of our critical infrastructure. We’re told that we can’t even trust our smart lightbulbs, Bluetooth-enabled toothbrushes, or internet-connected cars.

I welcome the attention, but I worry that the reporting conflates two distinct aspects of infosec: software engineering and enterprise security. When it comes to proposed solutions, the focus is usually on the former: there are growing calls for government-mandated coding standards or special forms of vendor liability. On these topics, we’re shooting from the hip.

Having been in the trenches, I think that the industry’s approach to product security is broadly sensible. We don’t know how to write bug-free code, but where it matters, major vendors make considerable investments to keep the products robust. Thanks to hardened frameworks, code audits, fuzzing, and sandboxing, key software — such as browsers and operating systems — has gotten quite difficult to attack. When bugs slip through the cracks, automated updates rapidly shield most customers from harm. It’s true that the security of smart lightbulbs and toothbrushes isn’t great — but serious attack scenarios are hard to dream up. I also concede that special considerations exist for certain niche industries; these need to have standards of their own.

In contrast, my view of enterprise security isn’t nearly as optimistic. The purported basics — meaningful asset inventories, privilege reduction, comprehensive access control — are unsolved problems. It doesn’t matter how much you care: there’s no product or policy that lets you address these challenges at scale.

To illustrate, consider that even the most robust asset inventory scheme can be thwarted by a single employee who, for the sake of expediency, puts a bootleg AWS instance on a corporate credit card and does some prototyping there. Similarly, most software restrictions on corporate machines can be upended by a single browser extension — an extension that may be helpful today but goes rogue tomorrow. What stops an employee from setting up an outgoing SSH tunnel on port 443 to more conveniently work from home? And how does one manage the risk of a vendor rep coerced by the security apparatus of a hostile nation?

In a company of 10,000, stuff like that happens with clockwork regularity; your security team is pitted against the sum of human ingenuity. You work to lower the base rate of security lapses, but even with the best tooling and education efforts, there’s that 1% or 5% you’re bound to miss. A breach is only a matter of time; your average CISO is losing sleep over this, not over buffer overflows.

The most successful security programs I've seen are not built around the idea of having perfect defenses. They’re built around the assumption that you’re going to get compromised — and that you need to detect it, respond to it, and contain it faster than the attackers can achieve their goals. But even if you build a corporate panopticon, detection still isn’t a walk in the park — and the attackers are adapting by speeding up their tactics too.

In the end, product security is a red herring; it’s enterprise security that urgently needs a paradigm shift. I know that we’ll end up with more regulation for software development: the narratives of “market failures” are unfalsifiable and it’s the nature of all bureaucracies to amass influence and expand. But I think we’re barking up the wrong tree.

For a thematic list of all articles on this blog, click here.