The Backward World of Secure Software Development

My blog postings have been a bit thin this week, as I’ve been awaiting the latest blog software upgrade, which should improve the performance substantially.

I’ve been reflecting on last Friday’s excellent Cyber Security KTN workshop on Secure Software Development. This special interest group has been meeting for some time and I’m pleased say there’s been a fair bit of progress as the sessions are broader, deeper and the group is better joined up with other standards activities, including ISO and OWASP initiatives.

The workshop included parallel streams addressed business cases, good practices, training, and the systems development lifecycle. That illustrates the large scope of the problem space. It’s not just about cutting secure code or developing better testing tools. We need to get things right much earlier in the development process.

It’s a strange phenomenon of security that encourages us to address issues from the end point of a process, rather than its starting point. I noticed this when writing the original BS7799 text. The weakest chapter was the one on systems development. It’s always been the last place we focus our efforts. In fact our development lifecycles have for decades ignored security. And when we do address this area, we start at the end of the cycle, focusing on operational issues first, then testing and then coding standards, with more emphasis on securing the finished product than educating the designers.

Ideally we should have started at the beginning of the cycle: address the business case for security, then the requirements analysis, then the design principles and then the architecture. These are easier areas to improve, and yet they remain the least developed. We could make a big impact by if we could agree a simple set of design principles (such as always use open, secure protocols) and provide guidance on security architecture.