Teaching "Secure by Design"

The canonical resource for the concept of secure-by-design is "The Protection of Information in Computer Systems" by Saltzer and Schroeder. The essence is distilled into their 8 principles of secure design:

  1. Economy of mechanism
  2. Fail-safe defaults
  3. Complete mediation
  4. Open design
  5. Separation of privilege
  6. Least privilege
  7. Least common mechanism
  8. Psychological acceptability

These principles, laid out in 1974, are still fully applicable today.


It will be hard to teach design principles in 30 minutes. I agree with others who say that you have to get them excited in some fashion. I developed the "Elevation of Privilege" card game to get people excited about threat modeling, it might be helpful. (https://blogs.microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/)

Teaching people how to think like an attacker is very challenging, it's easier to teach them about a few attacks like SQL injection or cross-site scripting.

Lastly, if you do want to try to teach principles, I did a series of blog posts illustrating Saltzer and Schroeder with scenes from Star Wars: http://emergentchaos.com/the-security-principles-of-saltzer-and-schroeder


Rather than focus on rules and "follow these 5 rules, and you're secure", I'd focus on teaching developers about attackers, and how they think. You can't really cover 5 different things, each of which requires some in-depth knowledge to really implement properly, so why try?

The developers I've talked to seem to think hacking is "really hard", and don't really understand how easy it can really be. So explaining what people really do to thwart security can be eye-opening.

An example:

A few years ago I was reviewing a 3rd party web based reporting product and we had a developer from the vendor in to create some reports using the product. I asked about security and how it worked in their product. He proceeded to do a "view source" on the report web page, and show me how everything was dynamic HTML, and therefore was unhackable. I sat dumbfounded for a minute, but told him that this wasn't really workable security, that you can't trust the client end, blah blah blah.

He didn't believe me, and asked how anyone could possibly hack this product. I thought for a minute, said that I'd hook up the browser to a proxy server, and examine what the request/response was. (Today I'd just use the tamper-data plugin). He then said this would be "The hack of the century!" At this point I just threw up my hands in defeat, since he'd already decided his product was "secure". The only way to convince him would be to actually hack his product, which wasn't really worth my time since I wasn't going to buy the product anyway.

The point is, you need to start with the need for security and what we're all up against. If they don't understand that, it's game over. At the very least you'll instill a bit of fear in them, which is a good motivator. From what I've seen many developers don't really "get it", and they need to understand what they're up against first. Primarily to be able to understand WHY they need to develop secure applications.

Get people actually interested in security, and you might get something out of it. Otherwise I fear whatever you present in 35 minutes will just fall on deaf ears.