Things that need to change in information security standards

This is the second in a series of commentaries on what’s wrong with information security and what needs to be changed. My last posting discussed the need for changes in the perception and sponsorship of security. This one looks at how standards need to evolve to better serve the information security community.

There are different views on standards. Some people claim they are highly successful. One or two even claim they promote innovation and agility. Other people see them as a paralysing force that discourages anything new. The answer is that all points of view are possible. Standards can be a help or hindrance. The problem today is that, in my view, they have stopped working in support of better security and they are now killing innovation and progress.     

That’s not to suggest that we should aim to scrap all standards. Standards are useful and we need some of them. The standards business is certainly safe for many years to come. But I believe we need to encourage some changes to tackle a number of growing problems. In my view, the key problems with contemporary security standards are as follows.

There is a gap between the people who set standards and those who use them. Standards today do not seem to reflect the best interests of many enterprises, promoting paperwork (policies and procedures) rather than effective processes.      

Security standards take too long to become established. By the time they are widely used they are well out of date. ISO 27001 is based on work carried out more than 20 years ago. Throughout the first ten years of its life there was very little adoption.  

Security management standards are rooted in outdated quality concepts with excessive emphasis of procedures and tick-box audits. Yet few people today follow written procedures. (They never have in many Eastern countries.)

Leading security management standards such as ISO 27001 are bloated with excessive wording, over-long lists, and unnecessary prescriptive text. They reflect the nit-picking compromises of a committee, rather than a desire to communicate directly and simply.

The excessive amount of paperwork demanded by ISO 27001 is worthless, and potentially counterproductive. Many enterprises have policy portfolios running into more than a hundred pages. Nobody reads them. They are the elephant in the room that can no longer be ignored.

 The standards community is developing too many unnecessary variants of standards. We need a minimum set of documents, not the dozens in the pipeline. This explosion in standards perhaps reflects a different motive in the people who develop standards, rather than the interest of the people who use them.     

The current version of ISO 27001 contains a number of strange demands. Have you ever found a risk assessment process that gives repeatable results? Or a company that measures the cost and effectiveness of security?    

Leading security management standards are not suitable for small companies, those in developing countries, or for high-end applications such as Cloud services. There is a need for a tiered set of standards, and a better understanding of how small companies and those in non-Western cultures operate.    

Certification audit cycles are far too long and do meet the real-time demands of modern infrastructures. How can it be satisfactory to grant a certificate to a services company on the basis that it can remedy its non-conformities over a period of several months? We need a real time response.

The cycle for updating security standards is too slow (around 5 years for an ISO standard). Given the fast-changing risk environment, all standards should be revised at least bi-annually. Otherwise they cannot be relied on.

Compliance sets old standards in stone, preventing new ones from being introduced. This is a fault of compliance, but the standards community needs to recognise and compensate for this brake on innovation.  

Excessive standardisation encourages a herd mentality and breeds a dangerous, predictable monoculture. This is a real and growing danger as enterprises adopt identical measures. Attackers are fully aware of this weakness and they will exploit it.  

I could go on, but I think I’ve presented a sufficient number of points to encourage a broader debate and an appropriate response. Some answers are easy. Many are difficult. Here are some of my own ideas for improvement.

Firstly, we need to engage the user community more in the standard process. There has always been a gulf between standards professionals and those who need to use them. Busy users do not have the time or inclination to contribute to the standards process. Twenty years ago the Department of Trade and Industry recognised and set out to close the gap by bringing standards professionals and potential users together at a conference in London. It worked. The result was the development of BS7799, one of the few standards developed by Industry, and for Industry. We need that kind of initiative to be repeated.  

The problem arising from the success of BS7799 is that we’re now stuck with a 20 year old standard. New standards take far too long to penetrate the market. And old ones become too entrenched in compliance processes. The whole standards cycle should be reviewed and overhauled. It might work fine for quality or safety, but it doesn’t match the needs of security.  

We also need to raise the quality of standards. Some of the wording of current standards suggests that the contributors might lack experience in the subject area. Standards need to reflect best practices in the field, not just the most promising ideas of a working group, or the compromise views of a committee. I’m not convinced we’re trying hard enough to capture the best practices in the field.

Finally, we need better scribes to write these standards. Many are poorly written in passive English with a large degree of repetition, bureaucracy and absolutely no sense of economy or précis.