Process and Security

More evidence presented itself today in support of my message that there is a demonstrable correlation between the security status of web products where development follows a formal process and those where development is ad hoc and “messy”. Last week I read a report from Gartner entitled “Application Developers Should Assume Responsibility for Application Security” (by Joseph Feiman, 16 November 2006) that suggests that application developers themselves should shoulder the blame for poor security. Now, while I agree in principle that skilled developers should take the blame if the quality of their work is shoddy, the fact remains that if the same developers are trying to produce a product where the design has been mapped out on the equivalent of the back of a napkin then any expectation that security requirements are going to be met are ill conceived.

An example of this can be seen in three different security reports that presently sit on my desk. Two of them are glowing testimony to having well defined processes and skilled developers, the third an example of where there are skilled developers but a lack of process with resulting security problems. Should the developers be held responsible in this case? Actually no, because as I read the report it becomes apparent that few of the problems relate to source code, but result from the choice of third party products, or mis-configured hardware.

Granted, I do encounter cases where developers have dropped a stinker – and if there is an expectation that the individual has received training in secure programming then there might be little excuse other than the fact that we all make mistakes from time to time. But should the developer be left alone to shoulder the blame when, surely, peer review and testing should pick up on the issue long before it hits a production server?

If we are encountering security issues then we need to review the entire process and find the source of the problem before we try to fix it. If there is, for example, an SQL Injection issue with the source code then you might want to consider the amount of training being provided to developers and you might want to consider the processes around testing and review. Perhaps you might also discuss security with those stakeholders who hold the purse-strings and make a good case to allocate budget on training.

I’m over-simplifying a complex subject but hopefully getting my point across. I would love to hear your thoughts on this. If you want some good references then check out the excellent book from Microsoft entitled The Security Development Lifecycle (Microsoft Press, 2006) or refer to the excellent OWASP Guide.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.