This
is
another
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:
fact.check.baker@gmail.com. If you're dying to order the book, send
mail to the same address.
--Stewart Baker
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.
Comments