The first question I ask of a web product risk assessment is whether security requirements have been documented. I think it’s an important question – there is a definate correlation between the diligence put into security documentation and the resulting risk status of a product – but what always surprises me are the reasons given why they are not, and more worryingly that few people seem to understand what “security requirement” means in this context.
A “security requirement” is something that is measurable as opposed to being a statement of intent. For example, stating that a product “shall not contain instances of SQL Injection” is not a security requirement, it’s fundamental to product development. An example of a measurable and specific requirement is more along the lines of “The application shall verify the identity of its user before accepting a credit card payment from that user.” This is a statement that can be tested, it sets an objective, it’s specific to the application, it’s achievable, and it’s a simple, high-level requirement easily translated into a more technical requirement.
There are a number of excuses used by development groups for not documenting security requirements:
1) We don’t have time for documentation
2) We don’t do documentation
3) We don’t need (no) documentation (sung to the tune of “Brick in the wall” of course!)
I’ll take on each of those responses in turn. Firstly, time and resources are a constraint whatever we do but documentation does not need to be a resource intensive process – security requirements begin as simple high level statements such as that shown above. We can easily develop a standard set of such statements to apply as necessary. The key to the process is understanding what requirements apply to a particular product thus if you are processing credit cards then there should be a standard set of security requirements that relate to that particular action.
Secondly, if nothing is documented then it follows that you cannot perform proper testing because no-one will know what requirements to test against. Some development groups claim to be performing “Agile” development and thus also make the claim that documentation is not required. This is utter rubbish. Agile done properly provides plenty of opportunity for documentation throughout the entire SDLC. Check out this article for more information: http://www.ddj.com/dept/architect/184415786?cid=Ambysoft.
Having documented security requirements is not a panacea to security but it does demonstrate due-diligence within the development process. In my risk assessment process I give credit for seeing good documentation and in general I know that if this first stage of process is positive that the rest of the assessment is likely to be equally positive. Conversely, the opposite is just as true.