Regulating Stopgap Security

I wrote previously about stopgap security, a scenario in which there is no feasible long-term defense against a security threat, but instead one resorts to a sequence of measures that have only short-term efficacy. Today I want to close the loop on that topic, by discussing how government might regulate fields that rely on stopgap security. I’ll assume throughout that government has some reason (which may be wise or unwise) to regulate, and that the regulation is intended to support those deploying stopgap measures to defend their systems.

The first thing to note is that stopgap areas are inherently difficult to regulate, as stopgap security causes the technological landscape to change even faster than usual. The security strategy is to switch rapidly between short-term measures; and, because adversaries tend to defeat whole families of measures at once, the measures adopted tend to vary widely over time. It is very difficult for any regulatory scheme to keep up. In stopgap areas, regulation should be viewed with even more skepticism than usual.

If we must regulate stopgap areas, the regulation must strive to be technology-neutral. Regulation that mandates one technical approach, or even one family of approaches, is likely to block necessary adaptation. Even if no technology is mandated, regulations tend to encode technological assumptions, in their basic structure or in how they define terms; and these assumptions are likely to become invalid before long, making the regulatory scheme fit the defensive technology poorly.

One of the rules for stopgap security technology is to avoid approaches that impose a long-term cost in order to get a short-term benefit. The same is true for regulation. A regulatory approach should not impose long-term costs (such as compliance costs) in order to bolster a technical approach that offers only short-term benefits. Any regulation that requires all devices to do something, for the indefinite future, would therefore be suspect. Equally so, any regulation that creates compatibility barriers between compliant devices and non-compliant devices would be suspect, since the incompatibility would frustrate attempts to stop using the compliant technology once it becomes ineffective.

Finally, it is important not to shift the costs of a security strategy away from the people who decide whether to adopt that strategy. Stopgap measures carry an unusually high risk of having a disastrous cost-benefit ratio; in the worst case they impose significant long-term costs in exchange for limited, short-term benefit. If the party choosing which stopgap to use is also the party who has to absorb any long-term cost, then that party will be suitably cautious. But if regulation shifts the potential long-term cost onto somebody else, then the risk of disastrous technical choices gets much larger.

By this point, alert readers will be thinking “This sounds like an argument against the broadcast flag.” Indeed, the FCC’s broadcast flag violates most of these rules: it mandates one technical approach (providing flexibility only within that approach), it creates compatibility barriers between compliant and non-compliant devices, and it shifts the long-term cost of compliance onto technology makers. How can the FCC have made this mistake? My guess is that they didn’t, and still don’t, realize that the broadcast flag is only a short-term stopgap.