Bugs Are Bad, But So Are Flaws: IEEE Sponsors Center for Secure Design
There's a difference between a bug and a flaw, and an impressive group of software security mavens thinks it's time to pay more attention to the latter. To shift some of the industry's focus away from finding implementation bugs and toward identifying common design flaws -- "the Achilles' heel" of security engineering -- the IEEE Computer Society has formed the Center for Secure Design (CSD).
The CSD grew out of a foundational workshop, held in April, which brought together software security experts from industry, academia and government to talk about the problem of secure software design. Among the 10 workshop participants were representatives from Twitter, Google, RSA, Intel and Harvard University.
Gary McGraw, CTO of Cigital, hosted a soirée at the Cantina art bar in San Francisco to launch the CSD and to generate interest in its mission. McGraw was among the original workshop members. "The price of admission was a bag of flaws -- a real bag of flaws -- from your practice," McGraw told attendees. "We dumped them all on the table and picked the tallest 10 piles."
That mission, by the way, is to "gather software security expertise from industry, academia and government" to provide guidance on "recognizing software system designs that are likely vulnerable to compromise" and "designing and building software systems with strong, identifiable security properties." And those 10 piles led to the publication of an inaugural CSD report, "Avoiding the Top 10 Software Security Design Flaws."
McGraw, who is author of numerous books about building secure software, called finding and fixing design flaws "the hardest problem that nobody has solved."
"Software security has grown into a $7 or $8 billion industry, and it's continuing to grow very fast," he told me. "But the field seems to be myopically focused on bugs and hackers. And yet, from a technical perspective, half of the problem is a design problem. We're hoping to shepherd the field in the right direction."
The CSD is part of a larger IEEE cybersecurity initiative launched this year "with the aim of expanding its ongoing involvement in cybersecurity." Jim DelGrosso, principal consultant at Cigital, will serve as the CSD's executive director. One of the problems the group will address, DelGrosso said, is the relative opaqueness of the work being done on design flaws.
"We've known about these things for a decade or three," he told attendees, "and yet the problems persist. We also know that this work is being done, but much of it is being done internally, so it's not available to the public. One of the goals of the CSD is to change that. We want people to stop making these mistakes."
Google information engineer Christoph Kern shared an example of such internal work from his own company, where he has been developing Web application frameworks that make it hard for developers to introduce cross-site scripting bugs. One team that adopted the frameworks saw a marked reduction in their bug-tracker stats. "There's a real connection between bugs and design-level considerations," he said.
Here's the list of initial participants in the Center for Secure Design:
- Iván Arce, Sadosky Foundation
- Neil Daswani, Twitter
- Jim DelGrosso, Cigital
- Danny Dhillon, RSA
- Christoph Kern, Google
- Tadayoshi Kohno, University of Washington
- Carl Landwehr, George Washington University
- Gary McGraw, Cigital
- Brook Schoenfield, Intel/McAfee
- Margo Seltzer, Harvard
- Diomidis Spinellis Athens University of Economics and Business
- Izar Tarandach, EMC
- Jacob West, HP
Here are those top 10 security design flaws; each one is fleshed out considerably in the CSD report:
- Earn or give, but never assume, trust
- Use an authentication mechanism that cannot be bypassed or tampered with
- Authorize after you authenticate
- Strictly separate data and control instructions, and never process control instructions received from untrusted sources
- Define an approach that ensures all data are explicitly validated
- Use cryptography correctly
- Identify sensitive data and how they should be handled
- Always consider the users
- Understand how integrating external components changes your attack surface
- Be flexible when considering future changes to objects and actors
Posted by John K. Waters on September 2, 2014