Standard tensions

When drafting technical standards, there are natural tensions concerning the audience, purpose and language used.

On the one hand, 'technical' implies complexities and precision in the content, with details relating to science and engineering. This generally means writing for a competent and knowledgeable professional audience, providing specific details to guide and enable them to get to grips with the subject matter. A technical standard on, say, nuts and bolts would typically specify all relevant parameters (such as size, thread pitch, strength, durability and physical material), in sufficient detail for industrial engineers to design, construct, operate and maintain the nut and bolt manufacturing machinery and quality control tests, accordingly.

On the other hand, 'standards' implies readily-understandable content that can be applied consistently by a wider range of users - not just those 'competent and knowledgeable professionals'. The manufacturing managers, for instance, should appreciate the purpose and value of making standardised nuts and bolts, and understand the need for product quality (e.g. manufacturing within permitted tolerances, consistently, creating as little out-of-specification waste as possible). If a company is to invest in the nut-and-bolt manufacturing capability, there has to be a reasonable expectation of profitable sales, requiring a businesslike approach, complementing the engineering aspects.

On the third hand (!), ISO is an international organisation with a global brief, so its standards have to be comprehensible and usable in various contries. This means translating them into various languages, implying care to avoid obscure, ambiguous or difficult-to-translate terms in the original drafting language (English). [There's more to say on this. I will blog-on about 'plain English' soon.]

The tension, as I've called it, causes much effort, review and re-work by the committees responsible for producing and maintaining standards. That, in turn, makes the standards processes slow and costly. In addition to developing and agreeing on technical content such as the engineering specifications, the authors must also take care over the descriptions. Expressive details such as the formal writing style and format, plus legal aspects relating to intellectual property, add to the readability, understandability and translatability challenges mentioned earlier. So, on the fourth hand (!!), there is pressure to address all the issues, achieve consensus and publish standards within a reasonable timeframe, otherwise all that effort is essentially wasted.

With me so far?

OK, now let's consider standards for information security. The 'machinery' being specified here is primarily a set of processes relating to the proactive management of risks relating to information. The technicalities involved in doing that are every bit as complex and important as in nut-and-bolt manufacture. For example, inconsistent security controls may create or expose exploitable vulnerabilities - in other words, there are risks associated with the management of risks! Time and again we have witnessed the fallout from technical issues within, say, cryptography standards such as WEP: once discovered and exploited, vulnerabilities can all but destroy the value and utility of security standards ... hinting at yet another tension: standards need to generate sufficient value over their anticipated lifetimes to justify the investment required to produce and adopt them, ideally being future-proof.

And finally, for today, there is a fifth tension relating to consistent application of standards around the globe. It is relatively straightforward to test nuts and bolts for conformity with the associated engineering specifications in the associated standards. Size, pitch, strength etc. of a sample of nuts and bolts can be measured by a suitably-equipped laboratory staffed by competent and diligent testers - and that raises yet another consideration: the assurance concerning conformity with standards is part of their value.

However, in order for standards to have real meaning and value, there is a necessary division of responsibilities between standards-setting and conformity assessment. ISO standards are written in such a way that conformity can be assessed appropriately (meaning competently and consistently to generate the required level of assurance), but the actual assessment is out of scope for ISO.

In respect of information security, since the standards specify processes, conformity assessment is primarily procedural rather than physical. Measuring the force needed to break open a padlock is rather different to assessing the processes for managing the associated keys or combinations, or the technical security arrangements protecting a digital access control system.

Given all those tensions and hands, it's remarkable that ISO standards are so popular and successful worldwide. There are thousands of them covering all manner of subjects, produced and maintained by teamwork involving thousands of experts from hundreds of countries. Although I often whine about problems with the ISO27k standards, particularly the delays and language issues, I am nevertheless proud of the achievements of my colleagues within ISO/IEC JTC 1/SC 27. We done good: I know we can do better.