Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

McGraw on the IEEE Center for Secure Design

Secure software development expert Gary McGraw says what's great about the IEEE's new design center is that it tackles the thorniest problem.

Because computer security is a popular field, myriad professional organizations want to get involved. The IEEE Computer Society is no exception and has launched a cybersecurity initiative of its own this year.

But there is something different about the IEEE's Cyber Security Initiative. Instead of a "me too" approach to computer security, focused around the usual perimeter defense paradigm, the IEEE Computer Society tackled one of the hardest open problems in computer security and software security -- secure design.

We'll need the cowboy-hat ying-yang picture that we always run with these McGraw pieces, found at:

The idea underlying software security is simply stated: build security in from the beginning. That is, create something secure from the start by anticipating attacks and avoiding defects. This is a far superior approach than "protecting the broken stuff from the bad guys by putting a thing in the way."

From a technical staff perspective, not only does software security involve coders and testers, it also involves (or should, anyway) designers and architects. Though we have made great progress in software security over the last decade, there is plenty of work that remains.

For over a decade, I and other software security experts   have pointed out that security defects come in two primary flavors: bugs in the implementation and flaws in the design and architecture. We have made pretty solid progress addressing the bug problem through training, static analysis and better programming languages. But we have made much less progress on the flaw problem. Architectural analysis and threat modeling is hard and the expertise required to perform these kinds of analyses is rare. The problem remains mostly open.

This is where the Center for Secure Design (CSD) comes in. The CSD was created with a foundational workshop in April 2014. The purpose of the workshop was to bring together software security experts who are real practitioners from industry, academia and government to address the problem of secure design. Participants in the CSD foundational workshop included experts from major corporations such as RSA, Google, Twitter and Intel, along with key academics in the field.

Related Content

Gary McGraw sits down with founding members of the Center for Secure design in this podcast.


The CSD mission

The first order of business at the workshop was to identify a mission. Here is the resulting CSD mission that we came up with:

The IEEE Computer Society's CSD will gather software security expertise from industry, academia and government. The CSD provides guidance on:

  1. Recognizing software system designs that are likely vulnerable to compromise.
  2. Designing and building software systems with strong, identifiable security properties.

The CSD is part of the IEEE Computer Society's larger cybersecurity initiative, launched in 2014.

The top ten software security design flaws

The price of admission to the foundational workshop was completing a homework assignment that involved gathering and organizing real design flaws. Each participant brought along a "bag of flaws" from their organization and experiences which was then dumped onto a collective table for discussion and analysis. This was real world data from software security initiatives in companies with experience creating software that most of us use every day.

Using this real-world raw data, we created a list of the top ten software security design flaws. However, instead of simply foisting our list of flaws on the world, we determined to create a document focused on avoiding these top ten flaws.

In any case, here are the top ten software security design flaws as identified by the IEEE CSD:

  • Incorrect trust assumptions
  • Broken authentication mechanisms that can be bypassed or tampered with
  • Neglecting to authorize after authentication
  • Lack of strict separation between data and control instructions, and as a result processing control instructions received from an untrusted source
  • Not explicitly validating all data
  • Misuse of cryptography
  • Failure to identify sensitive data and how they should be handled
  • Failure to consider the users
  • Misunderstanding how integrating external components change an attack surface
  • Brittleness in the face of future changes made to objects and actors

It's important, of course, to know that these flaws account for half of the defects commonly encountered in software security. But more important still is learning how to avoid these problems when designing a new system or revisiting an existing system.

Please download and read the CSD document Avoiding the Top Ten Software Security Design Flaws from the IEEE CSD website for clear guidance on how to avoid the top ten software security design flaws.

Addressing flaws, secure design and building codes

Of course, a simple list of flaws and basic avoidance techniques will only scratch the surface of the secure design problem. Much work remains to be done.

Identifying techniques for findings flaws in a system design is one major piece of work to complete. Cigital's approach to Architectural Risk Analysis (ARA) and its scaling through security architecture survey is one way to look at the problem. Microsoft's approach to threat modeling is another (exemplified best in Adam Shostack's new book). Both of these approaches, however, rely heavily on expertise. Making ARA and threat modeling easier and figuring out how to make them scale consistently is an important goal of the CSD.

The problem with focusing on finding flaws in an existing system should be obvious -- the very situation assumes (and rightly so) that the design is flawed. But the CSD also wants to focus some attention on getting ahead of the problem! In other words, if you are a designer or an architect, what can you do to avoid design problems in the first place?

Toward that end, a workshop on "building codes" for secure design initially focused on the medical device space is next up on the IEEE Computer Society Cybersecurity Initaitve docket. That workshop is planned for November in New Orleans.

Get involved

There is plenty of work to do when it comes to secure design and the CSD would like your help. Check out the website and follow the CSD on twitter @ieeecsd. If you like what you're reading here or what you see on the Net, be sure to reach out.

This was last published in August 2014

Dig Deeper on Secure software development

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.