Secure Software Development - Let's make it happen

Clairvoyance is a skill I’d be reluctant to claim, so perhaps there really are morphic fields out there that shape our common thinking. Either way, it seems that at the same time that I was posting my recent blog entry on software development standards, John Harrison was inviting me to join his Cyber Security KTN special interest group on Secure Software Development. For those of you interested in this area there is a first meeting of this important group in London next Tuesday.

It’s a promising development looking to solve a serious problem. When was the last time you encountered a set of software development standards that required practitioners to evaluate risks, consider regulatory compliance, develop security architecture, implement secure coding standards and apply static and dynamic security testing? The answer is almost certainly no.

So what do we have to do to make it work? Not a lot. Just join forces and agree a new set of standards. And there is plenty of good stuff already out there. We just have to bring it together in a palatable form and demand that our software suppliers adopt it.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

David, this addresses the question you posed at the end of your software quality opinion piece (Computer Weekly 20 March 2007) which was wel balanced with Stuart King's column on coding standards. Your column challenged us for an approach to 'lightweight' standards. Here's how we may get there. All route maps have to get you out of the front door and onto the road that 'goes ever on and on' (to quote J R R Tolkien). Security like quality, karma, Koran, Torah etc. is a journey, not a destination (Deming?). Well first we have to dig into some assumptions. We've got a lot security problems because we haven't learnt from the standards that are in place already. For example, if we'd thought about what the users really need and - that means the users really working with the developers not just lobbing over a pile of money, some implied requirements and following it up with a lawsuit rather than a service level agreement. If only we'd heeded the STARTS Purchasers Handbook (published in 1989 and the basis of BSI's TickIT scheme) we'd be talking to each other already. So what I'm saying is that were in a mess but we have been learning lessons. Of course there will still be flaws but let's concentrate on getting them put right rather than shouting yah-boo-sucks-found-one at suppliers. Here's the map (a fledgling standard) for IT developers. Perhaps I'll write (another) one for users because you don't get off lightly. Summary: 1. Work on the uphill struggle of securing the existing embedded problems. Patch if necessary, but try root an branch replacements. Remember complexity and be aware that you can introduce new problems by fixing old ones. Think about what you are doing - yes that means specifications - and review the specs, review the code, test the code . . . with security as a persistent quality attribute. (What's a quality attribute? See ISO/IEC 9126. Some rather helpful people have distilled knowledge and best practice and published them as standards. What's a few hundred pounds spent on buying this knowledge compared to thousands of pounds to correct code and call in the consultants, lawyers etc.? The National Computing Centre guideline 289 (Protect and Survive - Defending against application hacking) is a foundation for reviewing specifications and code against. That's the 'secret' of reviews: the benchmark. 2. Develop all new code to strict standards so that a security architecture is the basis of the application and doesn't rely on patches or external security add ons. Standards are there to help you treat the known risks; let no-one say 'I told you so'. It's helpful to separate product standards (are you building the right product that cares for information security) and process standards (are you building the product in the right way). ISO/IEC 15408 (a.k.a the Common Criteria) is a product standard. ISO/IEC 27001 (a.k.a BS 7799) is a process standard. Big development activities often need small standards but don't think of these behemoths as monoliths (!) but rather as toolboxes of advice into which to dip. This is the approach of the Accredit UK standard for ICT supply which covers the whole concept-to-decommissioning lifecycle but only expects suppliers to comply with the relevant parts. Of course if you are involved in all stages, all stages apply. Governance accepting that responsibility. 3. Remember defence-in-depth strategy. 2 does not do away with antivirus, firewalls, intrusion detection/prevention etc. You're clever application will have to run on hardware. Software is one with the hardware where security is concerned. At the same time each needs to be designed without reference to the other and so each must be secured alone. Light has a split personality; travelling like a wave and reacting like a particle. Don't fight nature. 4. Go back to 2 and design the application with a business continuity/resilience architecture in mind. 5. Go back to 1. You are in a constant battle with the hardware, firmware, operating system, development tools, n-layers of communications before you are allowed to consider your work - or worry about the hackers. If you're an old time Dr Who fan it's the problem of the cyberman welded into the doorway - don't sit back and be pleased because there'll be plenty more blowing a hole in your other defences. Lightweight standards will evolve in to more detailed standards and this is not a bad thing. If we apply the simpler knowledge to the security problem we improve things. We can't practically apply complex standards to the problem because of trying to match the standards to the complexity. However, by chipping away with the simpler standard(s) - or bits of the behemoths we reduce the problem; software becomes more secure by design. Fewer security problems give us the time to apply more lessons learnt until the complexity of the applied standards becomes the protection for our innovative applications. Standards release the creative opportunity by adding controls to the known risks. Just watch out for emerging risks. They'll always be around - so be thankful for ISO/IEC 18044! When that crossover from the flaws of today to the security of tomorrow comes depends on how hard we work our way along the route map. For more on risk management and standards - because application development needs a framework of risk management - see my PhD research page