excerpt from my book on technology, terrorism, and
DHS, tentatively titled "Skating on Stilts." (If you want to
read the excerpts in a more coherent fashion, try the categories on the
right labeled "Excerpts from the book." I'm afraid I can't fix the bug
in TypePad that prevents me from putting them in the category in
reverse-chronological order, but I have started putting chapters up in
pdf form from time to time.) Comments and factual quibbles
are welcome, either in the comments section or by email:
email@example.com. If you're dying to order the book, send
mail to the same address.
The softest option was to nudge industry toward security measures by offering liability protection in exchange. This is the most comfortable form of regulation for business, because instead of punishing bad behavior it rewards good behavior. This is something we understood at DHS, where we administered the Safety Act. That act provides liability protection to companies who manufacture and sell qualified anti-terrorism technology.
The idea behind the act is simple: Some anti-terrorism technologies work well but not perfectly; they reduce risk but don’t eliminate it. Unfortunately, after a terrorist incident, the people who have been fully protected by the technology will be grateful, and the people who haven't been fully protected will sue, claiming that the technology was defective, since it didn't protect them from all harm. That's not a recipe for encouraging the deployment of new technology.
So, to keep fear of liability from squelching advances in technology, the Safety Act sets a cap on liability for approved technologies. There are a lot of conditions built into the act. Companies must, for example, carry whatever level of liability insurance DHS considers necessary to compensate people who may be harmed in a terrorist attack. But in return, the threat of open-ended, company-killing liability is taken off the table.
We thought that DHS could use the Safety Act itself to encourage companies to adopt some cybersecurity technologies. The protections of the act aren’t limited to physical products; they also cover services and information technology. We thought the act could even be applied to security services and processes, vulnerability assessments, and cybersecurity standards.
But the Safety Act wasn’t perfectly adapted to cybersecurity tools. Most hackers are not terrorists. In addition, network security measures work in layers. There is no single magic bullet that provides all security needs. If many security products fail to prevent an attack, and not all of them are covered by the Act, sorting out which ones caused the damage could require endless, expensive lawsuits. And, because network threats change so often, products designated under the Act would have to be updated frequently. And even with regular updates, the extent to which a particular technology provides protection will likely erode over time as attackers seek ways around the defense. At what point should protection be modified or withdrawn, we wondered, and who will press for that change? Finally, the insurance market for cybersecurity products remains at best a work in progress, so it wasn't clear that adequate coverage was available. For these reasons, we concluded, the Safety Act was probably better as a model of what could be done without regulation than as a tool that could be used immediately to encourage broad cybersecurity measures.
We also noted a second “soft” way to influence business -- government purchasing standards. Many critical infrastructure companies do business with the U.S. Government. The government has great weight as a buyer of technologies, and it can influence the market for security by the standards it sets for its purchases. The government cannot, however, dictate terms to suppliers of technology. The government may be the single largest buyer of some technology, but it is far outweighed in the aggregate by private sector purchasers. Further, without new policies, the government wouldn't really act as a “single” buyer. IT procurement is divided among many agencies, and these agencies would fight security standards that raise costs or reduce competition.
We wanted the government to consider a more unified approach to its procurement of information technologies. We thought the government could establish government-wide contract models that incorporated preferred technologies and security practices requirements into federal contracts. In fact, some steps on this road had already been taken. Federal purchases are required by law to meet certain federal information security standards.
We knew, though, that using procurement to enhance commercial IT security is easier said than done. The U.S. Government’s first efforts to leverage its procurement power for IT security in procurements began in the 1970s, when the government established the Trusted Computer Security Evaluation Criteria—the “Orange Book”—and began to evaluate commercial products that were submitted for review. The idea, then as now, was to use federal contracts as an incentive for vendors to incorporate security measures in their products.
The scheme never had as big a security impact as hoped; the commercial market for computers rapidly outpaced the government market, and private purchasers came to perceive their security needs as different from those of the government. Sellers and buyers alike complained that security evaluation slowed adoption of current IT hardware and software.
For all those reasons, the procurement process has not so far turned out to be an effective way to influence network security.