Of haze and fog and the visibility of risks

The hazy fog in Beijing has triggered many local radio stations and TV news to constantly remind drivers to slow down, turn on the head lamps, and drive with extra care in view of the poor visibility of the road conditions. On the way to the hotel yesterday’s evening, from the Xi’an airport, the driver reported that the fog in Xi’an in the past two days have also resulted in a few major accidents and incidents in the city. One involved a chained collision of 32 vehicles at a highway, and the other was a women being robbed on a side road during the day (blaming both on the poor visibility).

 

Contrary to this, in the logical world, when there is little or no visible knowledge of the inventory of information assets and their vulnerabilities and potential exposures (or threats), users and managers would not be able to see or feel the risk, unlike what the fog can do to let us know that we are at risk. They therefore may feel that their information assets are not at risk. When losses have been incurred, in most instances, only the folks who are involved in the investigation, and the managers/staff responsible are abreast of the related incident and associate exposures. To others, the lack of exposure to the incidents again provide a sense of safety.

 

The nature of digital or logical systems is such that risks are often invisible, until they materialized. With all the challenges that business managements need to manage, lack of visibility would also translate into no action. In information security risk management, one of the important tasks is to therefore make the risks visible. This could then bring about better awareness, and enable actions to be taken based on the risk situations.

Progress at Redmond

This is not about Windows 7 or Microsoft, but to have a tail to the head that I started while at Redmond in early November 2009, about the progress of the 7th meeting of WG 4 and what lies ahead for the 8th meeting in less than six months time.

From a progress standpoint, let’s say if someone is tracking WG 4’s performance by the speed of it’s standard development, then I think we are on track. Two projects have moved to FCD balloting (27031 and 27033-3), two have moved from WD to CD balloting (27032, and 27033-2), and two new items have started work in good progress into their first working draft (27034-2 and 27033-4). If we track also the number of national bodies’ comments, there were substantial number of contributions as well. A quick sampling revealed that project 27031 received 148 comments, 27032 has 248, 27035 has 171, and 27036 has 128. Overall (counting all projects’ comments), there were more than a thousand comments resolved within the week.

 

While we may use some logics between the number of comments and the rate of progress from one stage to another to gain certain assurance on whether the standard is on the right path, those numbers however do not necessary translate into quality standards. For example, after going through the many rounds of editing on WG 4 Standing Document 1 (SD1) on WG 4 Roadmap, I noticed that majority of the comments received over the three years period, broken down by their types, i.e., editorial versus technical, we see a very low percentage of technical contributions. Much efforts were invested in the document just to keep the status of various projects updated, and then they become obsolete shortly after. So for the next revision, I’ll be removing all status details from the roadmap and basically organize the list of projects by three broad categories: Published standards, Standards in development stages, and potential and future work items. This also addresses a consistency issue between SD1 status updates and SC 27 SD 4, which is a document that has a consolidation of all project status across the entire sub-committee. With this change, perhaps the NB has less things to review in SD1 and could have a better focus on the roadmap proper. Would this help in improvement of the roadmap henceforth? I think it is a small step forward, and we shall see.  

With regards to other projects in WG 4, perhaps one of the things that we could do going forward is to pay more attentions on the breakdown between the technical and editorial comments, and also how often structure get changed and contents get removed and placed back later. By driving for more focus on technical contributions, at least at the early stage of the development, perhaps we could get better quality standard (technical-wise). Again, such metrics would probably indicate the proportion of attentions into the meat of the standards in development rather than the dressing and presentation. 

On the first day of the meeting, I had the rare opportunity to sit in and observed two WG 1 project meetings on the revision of the ISMS standards, i.e., 27001 and 27002. At both meetings were two groups of NBs debating on what to revise, in particular, the extent of changes to make in the revision. A few NBs proposed that the structure of the documents should be changed, and the focus of the standard should be specifically on the information security domains, reducing or eliminating sections from 27002 that are not directly parts of information security management. Speaking to some delegates, I gathered that these changes were introduced as a results of learning and experience from certain implementations of the standards. However, other NBs were strongly against this approach for several reasons relating to the current growing population of certified companies involved. For one, major changes to structure and contents would invalidate the current base of certified companies, which require them to go through a complete recertification. While this could mean good business to the ISMS consultants and auditors, it also raises questions on the maturity of the certification scheme as a whole. Not many companies may one to go through a complete recertification and if that’s the outcome, then many consultants and auditors’ jobs may actually be at stake. If major change of this nature can proceed just after a few years of the standards publication, what is there to stop another major overhaul in another few years? Many companies would not welcome such disruption introduced by a certification that they have embarked upon. For those who were not so concerned about the certification itself, the issue they have was about the holistic nature of the standard. Would the revision make the standard so narrowly focused that it becomes applicable only to enterprise or organization of certain size or characteristics? Can, for example, 27002 continue to be used as a reference guide for quick assessment purposes? I could not see an easy resolution to these concerns. Someone will have to lose, it seems. Unfortunately, I didn’t have the capacity to look more closely into this development during the week due to the busy schedule that WG 4 is already engaged with. I will have to read the meeting report to find out the conclusion. 

The irony that’s perhaps worth highlighting here is the influence of these externalities to the development of the standards, in both it’s evolution process and it’s contents and structure. What is a good quality standard given these influences and constraints? Interestingly, we are often taught that standards are an important tool for achieving quality. Yet, in developing standards, we are faced with the challenges of ensuring quality in standards, which is not an easy undertaking given the externalities involved.

Unlike many things that undergo standardization, security has a peculiar characteristic that perhaps makes it challenging to be standardized. Security does not stay still. It changes as it’s environment change. What we can capture from an environment is only a snapshot of a given time, which is likely to have changed when we are reviewing that snapshot. Projects 27031 (ICT Readiness), 27032 (Cybersecurity), and 27037 (Digital Evidence) are attempts to establish suitable frameworks and provide guidance to help organizations prepare for undesirable changes to occur (failure events, emerging risks, incidents-to-be-happened, etc). The success of these standards, when available, however, still depends very much on how the practitioners adaptation to their respective operating environment.

 

At the Redmond meeting, the study period on Digital Redaction has also been closed successfully, in which a new work item proposal for “Guidelines for Digital Redaction” will be put up for NB ballot in the next few weeks. In addition, two new study periods have also been initiated in the WG, on Storage Security, and Supply Chain Security Controls, respectively. The next meeting will be hosted by the Malaysian NB at Malacca in April 2010. Between now and then, the editors and NB experts have a lot to update, review, comment, and contribute. I’m certainly looking forward to all of these to come.

7th meeting of WG 4 at Redmond, WA

Six months have passed since the Beijing meeting. This week, we commence the 7th meeting of the ISO/IEC JTC 1/SC 27/WG 4 at Redmond, Washington, USA. The meeting is hosted by the US national body (NB), represented by NIST, and sponsored by Microsoft, hence at the MS conference center in Redmond. With autumn coming to an end, the streets in Redmond are covered with falling leaves of various colors–red, yellow, and amber—and franked by trees of beautiful shades of the same all over.

In attendance are delegates from a number of NB, including Africa, Brazil, Canada, France, Germany, Japan, Korea, Malaysia, Singapore, Spain, Sweden, UK, and US (as far as I can recall). Liaison organizations representing FIRST, SC 7, and ITU-T/SG17 are also in the meeting to contribute to the various projects. In terms of the agenda this week, WG 4’s focus remains at development of the usual projects, from 27031 to 27037. The good news is that part one of 27033 on network security has reached FDIS status after the follow-up teleconference meeting that was held in early June 2009, so this is now outside of WG 4 agenda, awaiting for JTC 1 ballot for its final publication. All the projects have continued to receive substantial contributions from NBs to improve their contents and structure. There are however much editorial work and discussion required of the respective project editors to go through in the week to bring the projects to the next stage as appropriate. At critical juncture (requiring to move from WD to CD, or CD to FCD) are 27032 (Guidelines for Cybersecurity, at its 3rd WD), 27033-2 (part two of network security, at its 4th WD), and 27035 (information security incident management, at its 2nd CD). These projects run the risk of being cancelled if they cannot elevate to the next level, and could not justify for extension.

In addition to these projects that are in development, the meeting will convene a study period on the subject of Redaction, and review new proposal on Storage Security (referring to network storage in particular), and security baseline relating to supply chain management. The latter is relating to the Guidelines for Outsourcing (27036), but some felt that it is a specific area that requires a focused standard. Something for discussion anyway.

In parallel to the WG 4 meeting is the WG 1 meeting, in which much focus have been directed on the revision of the ISO/IEC 27001 and 27002 standards for information security risk management. These two standards have achieved unprecedented success in the past years in terms of its adoption worldwide. As a result, the group has gained much understanding of the strength and weaknesses of the standards. With the experience gained, a number of proposals (a few major ones, and a number of minor ones) have been suggested by various NBs for significant changes to the structure and contents of the standards. The success of these standards however mean that any changes to them are likely to impact the users community, including those organizations that have been certified and are relying on the standards to demonstrate information security governance to their management and customers. As the convener for WG 1 put it, it now has an economic consequent to consider.