Incentives in security
May 18, 2017  

There’s an old strain of wishful thinking in security involving incentives. The idea is that some outside force (regulation, liability, lawsuits, bad publicity, occupational licensing, insurance) can be designed to punish bad security practices and thus act as an incentive for good security. Essentially, these incentives are supposed to act as some kind of judo move that redirects human nature (greed) to serve the cause of justice (security).

This is a seductive dream. It would mean that we security professionals don’t actually have to do anything—once the incentive is in place, better security follows because humans can’t help their nature.

This Blackhat Asia 2017 Keynote by Halvar Flake, Why We are Not Building a Defendable Internet, is a typical specimen. He makes a couple of amusing observations about incentives in security:

  1. A CISO has no way to influence vendors to produce secure products because no single company has much market power over IT industries, which are near-monopolies (Intel in cpus, a handful of wifi chipset manufacturers, etc.). In other words, a company like Intel has no incentive to remove risky features like Intel ME.

  2. Therefore, a CISO can identify risks but not properly address them, which gives an incentive for others to produce products to hedge these risks: products like anti-virus which in fact do not work well and which introduce a large attack surface of their own.

  3. CISOs buy these (ineffective, dangerous) products because they have an incentive to cover their butts: if/when a breach occurs, the CISO can say they correctly identified the risk but the product failed. In other words, these products are scapegoats.

So far so good, but then comes the classic blunder: the idea that we can win by changing this broken incentive structure. In this case, the suggestion is that the cyber insurance industry can save us by charging more to insure enterprises that buy insecure products. This, theoretically, causes all enterprises to uniformly demand secure products, which in turn causes vendors to produce them.

Incentives are complicated

Unfortunately, the incentive structure is always broken, in security and in all other fields. And we (security professionals, economists, politicians, regulators, game theorists, self-help gurus, etc.) have very little idea how to design and implement effective incentives.

Some of the problems: there is never only one incentive, only tradeoffs between multiple incentives; perverse incentives are pervasive in security (as everywhere); people are not rational actors and they act against their own interests; and incentives can be, and routinely are, gamed.

Examples of these problems are legion, but for my audience let me just point to the health industry in the United States, which is full of incentive mechanisms, but which is entirely broken. We have insurance that does not result in lower costs or better health outcomes; we have pharmaceutical patents that do not seem to encourage innovation so much as higher prices; we have occupational licensing which seems to limit supply (and inflate salaries) of medical professionals instead of increasing quality and quantity; we have FDA regulations which retard innovation and hence harm health; and we have frivolous and expensive medical malpractice lawsuits which increase malpractice insurance payments which increase medical insurance prices for patients.

Bandwagons instead of incentives

It’s fun to think about incentives, and I don’t discourage anyone from trying to engineer incentives to improve security. But given how badly we understand incentives, I don’t place much hope in these efforts.

What we should do instead is get on useful bandwagons. A bandwagon is a mass movement in the industry towards some technology or methodology. Usually it is hard to see why bandwagons take off; they seem to arise out of nowhere, spontaneously. However, one thing you can be sure of is that they are aligned with the incentive structure of the industry—otherwise they could not be mass movements!

The key thing about bandwagons in IT is that, while they are never about security (security is always way down the list of things that people care about), there is often something about them that aligns with security. Therefore, it can be very useful for security people to hop on the bandwagon and push the security aspects as far and fast as possible.

With security in mind, here are the important bandwagons I see in IT today.


The DevOps movement has increased the velocity of cloud deployment. DevOps teams are pushing dozens of changes to their production systems daily. Some of the benefits are that teams can introduce features and fix bugs quickly, and they can incrementally deploy and test new code before making site-wide changes.

The benefits of DevOps are not directly motivated by security but they also benefit security. One of the most important things you can do to stay secure is to keep your software up to date with security patches, but patching is hard.

DevOps has vastly improved the technologies for remote automated updates at scale. If security teams have a place on DevOps teams, security will benefit.


Most people working in security consider the Internet of Things a nightmare: the Internet of Insecure Things. On the contrary, I think that IoT will have a great positive effect on security. The reason is that the security of IoT devices today is actually pretty much the same as it is for the old school devices we have been using for decades (e.g., PCs and routers). IoT makes things look a lot worse because there are just many, many more IoT devices.

In other words, IoT takes the existing problem of N insecure devices and turns it into the much bigger problem of a million times N insecure devices. It turns out that we have mostly ignored the problem of the N insecure devices but my hope is that it will not be possible to do this with a million times N insecure devices.

Problems that can be ignored are going to be ignored. Problems that cannot be ignored are going to be addressed. That doesn’t mean that they’ll be solved—there’s work to do!—but we are actually going to get resources devoted to the problem.

From a vendor’s perspective, a fleet of IoT devices in the field looks like a bunch of VMs or containers in the cloud. They’re different in that they are sitting in a home environment instead of a data center, but they can be administered by many of the same techniques. And fortunately, with DevOps, we have a lot of solid techniques that we can apply to the problem, particularly in keeping devices up to date.

Best of all, once IoT vendors adopt these techniques, they’ll eventually make their way into the crappy legacy infrastructure (PCs etc.) that we’ve been suffering with.

(See also 1, 2, 3.)

Safe languages

A lot of security professionals are in the trenches, spending all day, every day defending against memory corruption attacks. From the trenches, this seems to be a war without end. However, if you get your head out of the trenches, it becomes clear that safe languages are going to solve this problem. I’ve written extensively on this issue (start here) so I won’t repeat myself. We need (more) security people to jump on this bandwagon.


Just kidding.