The tao of secure development

Imagine, for a moment, that you wanted to lose weight and gain better health. To help you out in this endeavor someone hands you a top 10 list of things that you could die from and walks away. When you read through the list, you agree that things like diabetes, cancer and heart attacks all sound bad… but you still haven’t the foggiest clue on how to prevent those things from happening in your life. If you’re committed, you may even do research on how to prevent these things… only to find another top 25 list which contradicts the first, which makes you even more confused and frustrated.

Welcome to the world of secure software development.

While I do believe these lists provide value to the industry, there exists (at least) three fundamental flaws in them.

  1. These lists define generic problems.
  2. The lists of top 10 change with time.
  3. What do you do to fix it?

General problems don’t have any real bearing on YOUR problems.  Custom code creates custom problems (thanks Rich Mogull for that).  Even if you chased them, the lists change.. does that mean you don’t need to care about the ones dropped anymore?  What about the 11th one, is that not important enough to worry about? Lastly, while lists are generically good.. they basically amount to an incoherent laundry list that doesn’t even scratch the surface of the problem.

A way forward

Most people who teach security will give you a list of techniques or tricks that you can utilize to fix your problems.  Some even let you do hands on labs to expose various little vulnerabilities and play with them.  This type of training is, frankly, very limited and often out dated quickly in preventing security issues that crop up.  Sadly, maybe that’s the point.  What do I have to sell you later if you actually learned how to solve problems yourself?

I recently met a gentleman @ defcon who did a presentation I am quite impressed with.  You can read it here.  His basic point is developers should be given real tangible practices and tools to solve security issues.  It’s about what secure code looks and feels like, and less about the diseases you can get by not doing it.  Developers shouldn’t have to be security engineers… but that doesn’t excuse them from negligence.  Developers are not expected to be QA either (hopefully) but they should still know what a unit test is and how to build one.

That said, I think my Ireland based friend is scratching only the tip of the iceberg.  The problem, even deeper than lists, revolves around a lack of philosophy.  Before anyone is qualified to teach you about HOW to secure your applications, they should have first identified the essence of -why- these problems exist.  Then, using that understanding, they could strategically instil the characteristics of secure development into the lessons taught to developers.  Reality is, most trainers don’t.

In other words, the goals we have in accomplishing a task are based on a presumption that the mechanisms we are going utilize to do it are capable of meeting that objective.  Before you can teach a person on how to secure an application, you have to have a reason for believing what you are proposing they do (in a strategic and thought out way) is actually capable of helping them achieve that goal.  As Rich Mogull has pointed out, how do you really know that changing passwords every 30 days actually does ANYTHING for security?  We all say it to people… but how does this help you achieve the goal?

If you asked talented boxers (or boxing managers) about their sport, I am sure they each have a philosophy on how to win.  That philosophy is effectively what they use to govern training and strategy in their schools.  Even though not all of their students would be able to articulate those things, the exposure and time in training should ultimately reflect the various capabilities expected of them.  That is, I would expect a person who has boxed in a school for 6 years to have a better understanding of how to punch than a guy who has done it for 2 days.  But being able to punch is a fundamental aspect of the school and is demonstrated across the board.  (in fact, punching is -essential- to a boxing school 😉 )

In this sense, I am saying that we as trainers must understand our own philosophy of security and how to protect systems in order to teach and grow others.  Lastly, we want to help those who want to become security professionals to chase understanding their software (and the process of creation there of) in such a way that leads them to answer new questions as they come.  This is why and where principle starts to bare it’s fruit and lets you find order in chaos.

If you don’t have principle… you have already lost.


Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: