When Writing Software, Security Counts

Matt's written an interesting article sharing his experience "from the coal face" gained during years of exerience advising the military and leading companies in writing more secure software. I share Matt's view that it's far less expensive to fix security at the inital development stage rather than to retro-fit it. IMHO there are direct parallels with the cost of changing functionality once the code is complete - clearly it's a nightmare if your customer mandates a change during acceptance testing!

Here's a really rough sketch to show what I mean:

This article is not purely for the attention of developers though. Matt's informal style lends itself well to informing business and IT Professionals in the reasons WHY much code is inherently insecure - just blaming the dev guys(and gals!) isn't fair. For security to be effective it has to be part of the culture of all involved, from the end user through to implementation team, operations and development. Just think about it for a moment, if the user is asked a "security question" by the application but not given enough information (in their terms) to make a sensible decision then it's hardly surprising if they make a bad choice.

Something that I know Matt's passionate about is incorporating assessment of code security at user acceptance testing and indeed specifing it at the functional definition stage too. Personally I think this is essential - consumers have the right to expect code to be secure BUT they should be able to clearly state what they mean by "secure" and therefore enable the developers to incorporate the appropriate security controls to mitigate the expressed risk.