More on documenting security requirements

I was involved in an interesting debate today around the value of documenting a good set of security requirements. The debate was the result of report written where it was stated that deficient security requirements resulted in increased risk. No-one disagreed with the conclusion however, what was asked was something more than hearsay to back up the statement: especially as a number of the security requirements being prescribed are likely to cost time and money to implement.

I can point to a good deal of anecdotal evidence showing insecure products where no requirements have been documented and secure products where they are. But to what degree do requirements need to be documented – and followed – in order to begin having a positive impact on security status? In other words, how much of what we are prescribing really needs to be done and can we prove it?

There is plenty of textbook quotes in support of the value of having well documented requirements. For example in “Building Secure Software” by John Viega and Gary McGraw (ISBN 0-321-42523-5) it’s stated (page 34) that “the security engineer should be sure to craft requirements well.”

Now, here’s where we come up against business level push-back because if I mandate a high level requirement that is subsequently not implemented, and then if I perform a risk assessment where the outcome of not implementing that requirement is “low risk” then should the requirement have been stated in the first place and whose time is being wasted?

There’s a fine line here between being seen to be providing quality guidance that development groups will follow and being ring-fenced for saying that the sky’s falling down.

Clearly, in my ideal, ultra-secure world, I want a clean path from a to b where requirements are pristinely written and everyone follows them. In the real world, the business wants to deliver to it’s customers against a fixed, often limited, timeline and budget, and if we want to tell them to spend more money on security then we’d sure as better be able to back up what we’re saying with a crisp arguement and lots of supporting evidence.