Jon Collins, originally published on The Register
Thanks for some great comments from the article about making applications more secure. One of my favourites was, “It’s all very well trying to make your software idiot proof, but the problem is that the world keeps creating bigger and better idiots.” How true this often appears.
Meanwhile, from secure applications we can turn our attention to the development process itself. Much as we would like them to be otherwise, developers themselves are only human – and fallible. When we conducted some research into security around development and test last year, we identified four areas of risk:
Sourcing – i.e. who is involved in the development process
Geography – where people are, and how they are organised
Environment – what tools and systems are in place for developers
Data – what information is being used or managed as part of development/test
Of course these areas are inter-related. Few organisations these days have the benefit of an entirely in-house development team these days, and we have all seen the issue of having a key developer move on, potentially subcontracted in as a consultant, from some far-flung place. Meanwhile, data and environment are tightly knit: in our research we were surprised to see how many organisations actually run test applications on the same systems as the live environment, for example. While this may sound like a recipe for disaster there may be no choice, if costs to replicate an environment are prohibitive.
Risks can be divided into three types, based around the old stalwart confidentiality-integrity-availability acronym.
For availability, it’s clear that here we are thinking wider than security – in the above example, a potential outcome is that the test system crashes, pulling the live system down with it.
Integrity and confidentiality are just as much of a concern for protecting information itself, as for the possible compliance damage (and legal exposure) that may be caused if data is lost or damaged. And of course, source code represents a company’s IP, and needs its own protection.