Secure Coding Principles

Building it to support security

Don’t settle for “what”, ask “why”.

There are core pillars…

… and there are more specific ones.

o  Minimal attack surface area o  Secure defaults o  Principle of least privilege o  Principle of defense in depth o  Fail securely o  External systems are insecure o  Separation of duties o  No security by obscurity o  Simplicity o  Fix security issues correctly

Minimize attack

surface area

o  Fewer features mean fewer attack vectors.

o  Example: Eliminate the search function by making the site easier to use.

Use secure defaults

o  Better to start with high security options and allow the user to lower it than vice-versa.

o  Example: Passwords expire in 90 days.

Principle of least privilege

o  All user accounts should have the least privilege we can afford. •  User rights •  CPU •  Memory •  Database authority •  File permissions •  … and the like

Defense in depth

o  If one control is good, two are better.

o  Makes attacks very tough to carry out.

Fail securely

o  Failures should not break security. o  Example isAdmin = true; try { doStuff(); isAdmin = isUserInRole("Administrator"); } catch (Exception ex) { … }

o  If doStuff() fails, the user is an admin always.

Separation of duties

o  Example: an admin can add/remove users but shouldn’t be able to buy goods for others.

Security by obscurity isn’t

Must rely on other measures as well.

Simplicity

o  Complex code and systems tend to have security holes.

o  The simpler the code, the fewer holes.

Fix security issues correctly

o  After a hole has been found, find the root cause.

o  Don’t patch the hole. o  Fix the real cause.

Summary

o  Security can only be valid if it is backed by principles.

o  Learn the tasks, but more importantly learn the "whys" behind the tasks.

o  Extrapolate them in all areas.

Further study

o  Microsoft's Security Development Lifecycle: •  http://www.microsoft.com/security/sdl

o  OWASP Secure Coding Principles: o  http://bit.ly/OWASPSecureCodingPrinciples