Would the real Michael Howard stand up!

SESSION 2
The Security Development Lifecycle

When I heard that Michael Howard was making a presentation here at TechEd regarding security, I feared the worst. What would the MP for Folkestone and Hythe be doing here for heavens sake (and I have'nt even brought my blue rossette with me). Imagine my relief when the man taking the stage was none other than Michael Howard the Co-Author of Writing Secure Code.

Michael set out his stall be outlining the scope of the presentation. Specifically, this was "Security as a threat to software and the process of building secure applications"

He launched into a bit of an attack on security professionals: "Security people are antagonists who annoy people. They are good at telling you when someing doesnt work right but not much good at coming up with solutions." he claimed to a somewhat stunned audience.

He strongly suggested that most vunrabilities come into the system as data. And gave us a snippet of information regarding the software release process: "When something is not on by default, it is usually a feature that has not been tested enough and hence the vendor are not 100% confident about. However, he also made the point that tere are shades of grey in system security. Its not always black and white. Yet this is often something that the security guys refuse to take on board.

We next went into the topic of the day - The Security Developer Lifecycle. In a nutshell, these are a bunch of requirements/recommendations that deal with design/development/testing/post-release security/privicy and whose goal is to improve security by reducing severity or vulnrabilities.

The key message that Michael pushed here was "Secure by Design, Secure by default". There is no evidence whatsoever to support the case that if you increase the quality of the software, then security will improve. Or put another way, you must focus on security in order to deal with security!

The speaker then looked at security requirements and recommendations. Put simply, requirements are things that MUST be done prior to software release whilst recommendations are things that we may want to incorporate but will not delay software release.

I must be honest and say that the remaining half of the presentation was something of a disapointment to me as the focus was clearly on the area of unmanaged code and more specifically the vulnrabilities of the C and C++ language.

I shall bullet point the following snippets and hope that some of what was said may be of interest:

• vs2005 provides warning for unsafe functions still in use.
• Banned function replacements - safe crt (included in vs2005) and Strsafe (included in VS2005 and Windows SDK).
• VS2005 automatically migrates banned/unsafe functions into safe versions in object code.
• SAL (Standard Annotation Language) Used by static anaysis tools.
• example of SAL in use __out__ecount(cchBuf) allows the compiler to link buffer size variable with buffer.
  

The speaker then went on to discuss cryptography and stated that no new code must use md4, md5, sha1, des, rc3 (without crypto review), althogh Michael did conceed that Microsoft will sometimes allow weakended security for reasons of compatability. e.g. triple des within ssl.