As Published In
Oracle Magazine
November/December 2009

COMMENT: All Secure

Do No Harm

By Mary Ann Davidson

Cybersecurity legislation needs to follow a few rules.

One of the most interesting parts of my job is the chance to work on public policy issues. I’ve been fortunate to participate in a number of cybersecurity-focused groups (for example, the Center for Strategic and International Studies Commission on Cybersecurity for the 44th Presidency), testify before Congress, and comment on cybersecurity legislation. Anyone can comment on a bill, and particularly because there is a lot of pending cybersecurity legislation, I wish more people would do so. If you don’t lend your voice and your ideas before a bill is passed, you lose the right to complain about the results.

With this in mind, I propose four ironclad rules that members of Congress should follow when drafting legislation:

1. Set limits; don’t overreach. Before writing a law, determine what problem the bill is trying to solve, whether legislation will actually address it, at what cost, and with what unintended consequences.

2. Do no harm. The legislative remedy for an ill shouldn’t kill the problem by maiming the patient.

3. Use precise language. Vague language will be misinterpreted or—worse—lead to people spending a lot of money without knowing if they are “there.” Worst of all are the “no auditor left behind” security bills that create significant work and expenditure without materially improving security.

4. Uphold our current laws and values (for example, the U.S. Constitution).

There is a current draft bill, the Cybersecurity Act of 2009, being put together by U.S. Senators Olympia Snowe (R-ME) and Jay Rockefeller (D-WV) that I’ve spent some time reviewing. Some provisions are pretty good, such as establishing an Office of the National Cybersecurity Advisor within the Executive Office of the President, which would help elevate cybersecurity as a national priority. Unfortunately, the rest of the current draft breaks all four of my rules.

First, the draft bill calls for the National Institute of Standards and Technology (NIST) to develop a machine-readable language so vendors can communicate vulnerability information to users in real time. As written, this idea violates rules 1, 2, and 3. 

Next Steps

READ more Davidson

 LEARN more about Cybersecurity Act of 2009

While the intent is to enable users to understand their “security posture” in real time—a good thing—that’s not what the draft language says. “Vulnerability” is not defined (is it a configuration weakness, a bug that has been fixed and needs a patch applied, or a defect in software that has not yet been fixed?). A vendor telling customers in real time, “We just found a vulnerability, we haven’t fixed it yet, and there is no workaround” is going to do harm, not good. An unintended consequence of this provision is that it would empower bad guys in real time. In short, nobody knows what this means as written, and people could spend a lot of money complying with this provision and make cybersecurity a lot worse.

Second, the draft bill calls for a public-private clearinghouse for sharing vulnerability information that would cover the government and private industry networks . The provision says the secretary of commerce “shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access.” I’m not an attorney, but I recall that the Fourth Amendment prohibits unreasonable search and seizure. Who would want potentially any relevant data on private networks to be accessible without a warrant? Not I. This section breaks rules 1, 2, 3, and 4.

Third, the draft bill directs NIST to create a software configuration specification language. Not all configuration parameters are security relevant: business applications are highly configurable (for example, “set of books” or “chart of accounts”). Why should all application-specific parameters be machine readable, especially if a configuration parameter is not only application-specific but vendor-specific? If the intent is to determine security-relevant “posture,” then the language should reflect that, instead of trying to make a set of books machine-readable. Also, what happens if the U.S. creates a configuration standard, China creates another one, and so on? Asking vendors to do one thing that helps improve security posture is fine. Asking them to do this differently in every single country is a good way to spend money and not improve security, crowding out other security improvements. This one breaks rules 1, 3, and 4.

No doubt, Senators Snowe and Rockefeller have good intentions for improving cybersecurity. As my four rules suggest, good intentions need good language to make good law. A new draft is coming; let’s hope it’s better. 

Mary Ann Davidson is the chief security officer of Oracle, responsible for secure development practices and security evaluations and assessments. She represents Oracle on the board of directors of the Information Technology Information Security Analysis Center (IT-ISAC), has served on the U.S. Defense Science Board, and is on the editorial review board of SC Magazine.

Send us your comments