About 10 years ago I began a short contract working as a programmer for a bank. On beginning the role, my very first task was to read the programming standards manual. This was a custom written 400 page folder describing every allowable way of writing code such as how to lay out loops and variable naming conventions. Not a single line of code went into production without it being peer reviewed against those standards. So, was the product secure? You bet it was. Strict adherence to documented standards might be frustrating but it gets results.
Such adherence to procedure is something I all too rarely encounter and finding the right compromise between procedure and business requirements to deliver fast is an ongoing challenge. I’m told over and over again that security is considered an expensive and often unnecessary overhead however, a few days ago the people giving me that message were the very same whose product had been found to contain vulnerabilities and potentially be at risk.
What frustrates me most is when software or network “engineers” inform me that they don’t have the time to work within the bounds of a formal process. Sorry guys but that’s just not systems engineering. I looked up a few academic definitions of Systems Engineering and settled on this one from the Open University.
Systems engineering is a set of principles, methods and techniques applied to all the tasks involved in all the life cycle stages of a complex system.
The point I’m making is that if you don’t apply the principles of systems engineering throughout the entire lifecycle of a product then you are not designing a product that will fail gracefully. Here’s an example for you that has nothing to do with IT. Remember the Millenium Bridge in London that wobbled? Somewhere during the design process the engineers forgot to take into account the well known effects of people actually walking across it – they achieved the beautiful design but “lost sight of the function.” Sound like any project that you’ve worked on lately?
If you are working within a complex and risky environment then you cannot have an expectation that security is something that has zero cost and time attached to it. Refer back to David Lacey’s blog entry about the importance of including security within the SDLC. It’s not just a suggestion, it’s vital and if you’re not doing it then I know, sitting here now, that you have security problems.