Zero-based risk assessment

In a thread on the ISO27k Forum, Ed Hodgson said:

"There are many security controls we have already implemented that already manage risk to an acceptable level e.g. my building has a roof which helps ensure my papers don't get wet, soggy  and illegible.  But I don't tend to include the risk of papers getting damaged by rain in my risk assessment".

Should we consider or ignore our existing information security controls when assessing information risks for an ISO27k ISMS? 

That question took me back to the origins of ISO27k, pre-BS7799 even. As I recall, Donn Parker originally suggested a standard laying out typical or commonplace controls providing a security baseline, a generally-applicable foundation or bedrock of basic or fundamental controls. The idea was to bypass the trivial justification for baseline controls: simply get on with implementing them, saving thinking-time and brain-power to consider the need for additional controls where the baseline controls are insufficient to mitigate the risks.  [I’m hazy on the details now: that was ~30 years ago after all.]

I have previous used and still have a soft-spot for the baseline concept … and yet it’s no easier to define a generic baseline today than it was way back then.  

In deciding how to go about information risk analysis, should we:

• Go right back to basics and assume there are no controls at all - a zero-based assessment? This is challenging and tedious but gives us the opportunity to reconsider whether we still need all the controls we already have, or whether there might be better ways to address the risks, today;
• Ignore the existing controls comprising our baseline, focusing on the current information risks to identify any need for supra-baseline controls?This incremental risk analysis is easier and quicker, but relies on our foundational controls which might not, after all, be as solid as we presume;
• Compromise: if we use the baseline/incremental approach routinely, maybe we should occasionally review and reconsider our baselines too. In practice, we are likely to want to add even more controls to the baseline each time we do that but still we should really take a cold hard look at those baseline controls. In particular, I like to tease out and review the “key” controls, the ones we are heavily reliant upon: as such, we really ought to make more of an effort to be assured of their effectiveness, rather than just presuming it, with implications for oversight, monitoring, testing and metrics.

And that, by the way, is an area where ISO/IEC27002 could really help by clarifying what are the “key” controls, which takes us full circle back to the idea of a common/universal baseline. I have in mind defining the baseline through a set of general axioms, principles or security objectives rather than what we normally call controls - things such as ‘accountability’, ‘responsibility’, ‘role’, ‘trustworthiness’, ‘reliability’ and so on. 

Unfortunately, the ISO/IEC 27002 revision project is probably too engrossed with reorganizing and rewriting hundreds of controls to even consider such an idea at this point, but maybe I should suggest it for one of the other ISO27k standards - or just write it up as a suggestion.