News Stay informed about the latest enterprise technology news and product updates.

Congress should encourage bug fixes, reward secure systems

Cybersecurity policy should encourage bug fixes instead of simply recording and reporting attacks, software security expert Gary McGraw explains.

Any article on the law should include a disclaimer at the top: I am not a lawyer, a Congressman or a lobbyist, nor do I play one on the Internet. Take everything you read here with a largish block of salt. If you need legal advice, this is not it.

Software [In]securityThat said, when it comes to the law, computer security has always had a law enforcement aspect even as it consistently lags behind the technical cutting edge. Advancements in software design and the advent of geographically distributed systems and applications put the law even further behind than usual over the last five years or so. Sniffing packets and hacking protocols is so last decade! What about smart phone hacking, infrared snooping and online banking fraud?

The U.S. Congress has become more serious about looming cyber security risks and has recently pushed to fill the cyberlaw void with a series of bills. (For what it's worth, an analysis by Randy Sabett shows that Congress has been relatively active on cybersecurity since 2003, debating and rewriting but not passing any bills.) Reaction in the technical community to the latest batch of bills has been decidedly mixed. So, where do we stand and what can we expect?

A very brief history of U.S. computer law

The Comprehensive Crime Control Act of 1984 was the first body of law to include a section on cybercrime (Section 1030). It was rewritten in 1986, and computer law in the United States officially began with the Computer Fraud and Abuse Act of 1986 (CFAA, aka 18 U.S.C. Section 1030). The CFAA defines six types of computer crime, mostly centered on unauthorized access to a computer. Network security issues (especially remote access over a network to someone else's computer) make up a majority of the coverage.

The Electronic Communications Privacy Act (ECPA) also was introduced in 1986. It focuses on network attacks, including unauthorized network sniffing and other forms of data interception.

For more about the CFAA and ECPA, see Mark Rasch's excellent introduction to computer security law.

The network-centric focus of early statutes began to fray with the advent and growth of malicious code. The CFAA was amended in 1992 to address perpetrators of malicious code and denial-of-service attacks. Even with this amendment, however, computer security law to this day focuses an inordinate amount of attention on network security, ignoring many aspects of modern computer security (including software security and content protection).

About the [In]security Column:

This monthly security column by Gary McGraw started life in print in IT Architect and Network magazines and was originally called "[In]security." That was in October 2004. The column then moved into Web content at several publications before finding a home at You can always find pointers to the complete [In]security series on McGraw's writing page. Your feedback on the column is greatly appreciated.

The Digital Millennium Copyright Act (DMCA) was enacted in 1998 "to amend Title 17, United States Code, to implement the World Intellectual Property Organization Copyright Treaty and Performances and Phonograms Treaty, and for other purposes." Not surprisingly, the focus of the DMCA is copyright protection. It restricts production and distribution of technology that circumvents copyright protection mechanisms (including digital rights management, or DRM, systems). It also directly addresses copyright infringement on the Internet by laying out penalties. The DMCA and its European equivalent, the EU Copyright Directive, are not without controversy. Many people believe these laws go too far to uphold the rights of copyright holders, to the detriment of innovation and creativity. Computer security practitioners also worry about doing their jobs under the DMCA when it comes to security analysis and penetration testing.

To conclude my very brief legal history lesson, it's important to note that computer security law is evolving through case law that sets precedents. Precedent-setting can involve extending existing bodies of law, such as wire fraud law, to apply to computer security. If done incorrectly (for example, using the wrong analogy to existing law), it can sometimes do more harm than good.

Congress and the Senate make cyber sausage in 2012

In April 2012, the controversial Cyber Intelligence Sharing and Protection Act (CISPA) passed the U.S. House of Representatives (248 for, 168 against). The vote was bipartisan, though more Democrats voted against the legislation, and more Republicans voted for it.

The CISPA was problematic enough to cause seriously negative reactions in the privacy community, especially from the American Civil Liberties Union and the Electronic Frontier Foundation (EFF). Some opponents interpreted portions of the bill as allowing Internet service providers to turn over their network traffic to the government as part of an "information sharing" program. Critics likened this to wiretapping. The EFF circulated a petition signed by prominent security experts that stated, "We take security very seriously, but we fervently believe that strong computer and network security does not require Internet users to sacrifice their privacy and civil liberties." President Obama threatened to veto the bill if it passed the Senate unmodified.

Two competing bills were introduced in the Senate: Sen. John McCain's (R-Ariz.) Secure IT bill and Sen. Joe Lieberman's (I-Conn.) Cybersecurity and Internet Freedom Act. Debate and markup proceeded, and by the end of July pressure was mounting to pass something. Republican opposition to the original Lieberman bill centered on its provisions directing the Department of Homeland Security to create mandatory performance standards, then assess the security of power companies, utilities and other firms that operate critical infrastructure for security problems and create performance standards. These were deemed too restrictive and were addressed in a subsequent markup. Opposition from civil liberties groups around the wiretapping issue was also addressed.

The compromise bill includes seven major provisions:

  1. Establish the National Cybersecurity Council to lead cybersecurity efforts.
  2. Allow private industry groups to identify voluntary security controls and practices to mitigate particular risks (subject to approval by the council).
  3. Create a voluntary program for the owners of critical infrastructure that involves some hurdles for membership but provides incentives including liability limitations and priority assistance as a set of rewards.
  4. Rely on existing regulators and standards, especially with regard to particular industry verticals.
  5. Permit information sharing between the government and the private sector while preserving the privacy and civil liberties of users.
  6. Require certain critical infrastructure providers to report serious cyber incidents.
  7. Require the government to improve federal civilian networks through reform of the Federal Information Security Management Act (FISMA).

The compromise bill, the Cybersecurity Act of 2012 (.pdf), is likely to come up for a vote before the August recess. Of course, you can read a copy of the bill for yourself.

We (still) live in a glass house

In my view, the Cybersecurity Act as currently envisioned does little to address the pressing need for security engineering, software security and built-in security. Instead, it focuses on reactive information-sharing about the inevitable attacks that will occur against systems riddled with vulnerabilities. In a nutshell, this new bill is old-school security come home to roost.

I believe that cybersecurity policy must focus instead on solving the software security problem -- fixing the broken stuff instead of simply watching the broken stuff and reporting when it is attacked. We must refocus our energy on fixing the glass house we find ourselves in. We must identify, understand and mitigate computer-related risks. We must begin to solve the software security problem.

To date, when it comes to software, Apple Chief Information Security Officer David Rice said it best in his book Geekonomics: "Unfortunately, the blunders of government are matched almost equally by the blunders of the market itself, if not more." I believe that the government can and should play a role in building more secure systems. The U.S. government should develop incentives for vendors to build security in and break the endless loop of feature creep and bloatware. The government should publicize security failures so that we know what is really happening and we can learn from our mistakes. Perhaps the government should even grant tax credits for creating better, more secure software.

Equally important is what the government should not do. The government should not legislate cybersecurity excessively. The CFAA has done little to deter the explosive growth of cybercrime. Frankly, the target-rich environment filled with broken software makes it far too easy and too tempting to misbehave criminally. The government should not pretend that its buying power can single-handedly move the software market -- it can't. The government should not build any more overly bureaucratic taxonomies for security evaluation (such as the Common Criteria or the Pentagon's Trusted Computer System Evaluation Criteria) or for security certification and accreditation, such as FISMA. The market does not care.

When bits are money, the invisible hand will move to protect the bits. Of course, the invisible hand must be guided by the sentient mind and slapped hard to correct the grab reflex if and when it occurs. There is an active role for government in all of this, not just through regulation, but also through monitoring and enforcing due process and providing the right incentives and disincentives. In the end, somebody must pay for broken security and somebody must reward good security. Only then will things start to improve. Washington can and should play an important role in this process.


Small portions of this article appeared originally in Online games & the law on the Darkreading website and in Separating the threat from the hype: What Washington needs to know about cyber security in America's Cyber Future: Security and Prosperity in the Information Age from the Center for a New American Security (June 2011). Thanks to Randy Sabett at ZwillGen PLLC for helpful commentary on an early draft.

About the author:
Information Security is pleased to welcome Gary McGraw and his [In] security column as a regular feature. McGraw is chief technology officer at software security consulting firm Cigital Inc. He is a globally recognized authority on software security and the author of eight best-selling books on this topic. Send comments on this column to

This was last published in August 2012

Dig Deeper on Secure software development

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.