The TEN controls ISO/IEC 27002 missed

Despite the excellent work done to restructure and update the standard, I still feel some commonplace 'good practice' information security controls are either Missing In Action or inadequately covered by ISO/IEC 27002:2022, these nine TEN for example:

1. Business continuity controls, covering resilience, recovery and contingency aspects in general, not just in the IT security or IT domains. ISO 22301 is an excellent reference here, enabling organisations to identify, rationally evaluate and sensibly treat both high probability x low impact and low probability x high impact information risks (the orange zone on probability impact graphics), not just the obvious double-highs (the reds and flashing crimsons!). Therefore, '27002 could usefully introduce/summarise the approach and refer readers to '22301 and other sources for the details.
   
   
2. Availability and integrity controls supporting/enabling the exploitation of high-quality, up-to-date, trustworthy business information and opportunities for legitimate purposes within the constraints of applicable policies, laws, regulations etc., even when this means deliberately taking chances (accepting risks!) to secure business opportunities. Also, I'd like to see, somewhere in the ISO27k series, clearer advice on how to tackle the trade-off between control and utility: information that is too tightly secured loses its value, just as it does if inadequately secured ... and that in turn leads to the idea of at least mentioning financial and general business controls relating to information risk and security (e.g. budgeting, project investments, resourcing, cost accounting, incident and impact costing, valuing intangible assets, directing and motivating specialists: these are all important but tricky areas to address, so advice would help improve the effectiveness and efficiency of information security). [Some of this is covered, albeit quite academically rather than pragmatically, in ISO/IEC 27014 and '27016, and outside the ISO27k realm.]
   
   
3. Health and safety controls protecting 'our most valuable assets', providing a supportive work environment that is conducive to getting the most out of our people, and ensuring the safety of our customers using our products. As with business continuity, H&S is pretty well covered by other standards plus laws and regs ... although, arguably, there's much more left to say, yet, on mental health (e.g. the long-term adverse health effects of excessive stress, both on and off the job), with significant implications for information risks (e.g. managers making inappropriate decisions, or delaying/refusing/being unable to decide at all) and security controls (e.g. the importance of workload and stress management).
   
   
4. Controls against fraud perpetrated by insiders (managers or staff), partners, outsiders/unknown parties, and potentially several (collusion) is another weak area in the standard.  I have in mind controls such as 'trust but verify'; discreet monitoring/surveillance, both general and targeted at fraud-prone groups, roles, individuals or situations; explicitly designing business processes and information systems to deter, avoid, detect and alert on, or at the very least securely log fraudulent activities; identifying, reporting and following-up on various fraud indicators; encouraging and facilitating whistleblowers etc.
   
   
5. Ethics in general - another human issue inadequately covered by the controls in the standard, despite the opportunity offered by section 6.
   
   
6. Assurance controls in general: although there are some assurance controls in the ISO27k standards, they are mostly constrained to compliance auditing for accredited certification purposes. Oversight, for instance, is a valuable control (or rather, a cloud of related controls) that is almost universally applicable.
   
   
7. Security architecture plus security engineering: once more, there are already useful standards and methods in this area, so '27002 need not reinvent the wheel - rather I feel it should introduce the concepts (perhaps with some version of the diagram above, or any of the many excellent alternatives documented in various other framework standards and methods), explaining their value as an integral part of information risk and security management, and cite the appropriate reference sources.
   
   
8. Professional services other than the provision of IT/networks/cloud: many organisations rely on third parties for strategic, legal, accounting, HR, marketing and/or other specialist services (advice or full outsourcing), hence they are giving, receiving and using very valuable and sensitive information.  [This is such a significant omission from the current ISO27k suite that it deserves its own ISO27k standard, in my opinion.]
   
   
9. Information security controls mitigating information risks affecting the Information Security Management System itself, plus other 'management systems' and in fact management information in general e.g. governance arrangements such as structures, roles and responsibilities, reporting lines, delegation and oversight; change controls for policies and procedures; access controls for sensitive ISMS-related information such as risk registers, logs, incident reports, strategies, budgets and plans.
   
   
10. Diverse archives - for long-term secure archival of valuable information, duplicated across multiple storage locations to reduce the possibility of single site disasters. Since the control cost is roughly doubled compared to traditional single-site archives, it is even more important to ensure that only essential information is archived, implying the need for policies and procedures plus authorisation and assurance measures (e.g. regularly confirming that archived information can, in fact, be retreived successfully) using available technology.  [Control 8.13 mentions "archive copies", in the plural, but it takes a keen eye to and experience to spot and mitigate the risks.]

The good news, however, is that '27002 is a popular, generic, advisory standard that adequately catalogues and describes the basics. We are free to interpret and apply the standard as we wish, even within the constraints of a ISO/IEC 27001 certified ISMS. The controls outlined in Annex A of '27001 are discretionary and not necessarily comprehensive - in other words, if you accept some or all what I've said above, determine that various other valuable controls are MIA or weak in '27002, or decide that the suggested controls (as described) are inappropriate in your particular business situation, you are positively encouraged to use the specified information risk management process to select, use, manage and maintain whichever controls are most relevant and valuable to your organisation, becoming integral parts of your unique ISMS.

Don't feel constrained by ISO/IEC 27001 Annex A and ISO/IEC 27002:2022. Do what's best for your organisation, for business, for Pete's sake!

Information risk and security management reporting

Last Thursday, a member of the ISO27k Forum launched a new discussion thread with this poser (lightly edited):

"Having recently become an ISMS coordinator, I must prepare a monthly report to management. How does one write an information security report?  What should be reported?" 

Over the weekend we've raised and debated a bunch of ideas, such as a tiered approach, starting at the detailed operational level with effectiveness metrics for the selected information security controls, then aggregating and summarising information for less frequent reports to higher management, emphasising the business perspective (e.g. reporting not just the number of incidents, but a breakdown by severity level mapping to business impacts for senior management).

Using appropriate metrics makes sense, of course. It also occurs to me that, aside from structuring the reports according to the information security controls and incidents, you could use the information risks in a similar way. The themes and control attributes from ISO/IEC 27002:2022 (and/or your custom attributes) might also be a rational basis for grouping and reporting on the ‘ISMS things that are somehow related’, particularly for the more detailed reports.

As well as reporting historical and current status information, I would probably add some analysis of the current situation, resourcing(budgets and people) and priorities plus a forward view of planswith a time horizon that again reflects the outlook of the audiences. So, for the higher levels of management, the reports would focus on fewer, more significant issues (bigger/existential risks, key business-related objectives, major projects/initiatives etc. with the supporting details possibly relegated to appendices or simply cited in lower-level reports) and look further forward towards more distant horizons.

Generalising, I envisage a reporting structure along these lines:

• Continual/daily information used for routine, contemporaneous operational activities within the information risk and security management function, with weekly/monthly summaries fed into other reporting streams and formats e.g. ‘status reports’ and ‘ongoing activities’ (things completed in the most recent reporting period, things in progress now, and things planned for the next reporting period/s) and ‘current concerns’ (watchpoints) on the function’s intranet site;
• Monthly reports exchanged with management colleagues in related specialisms such as risk, IT, HR and compliance, used to agree priorities and so coordinate approaches, dealing with any conflicts or concerns and avoiding things ‘falling between the cracks’;
• Quarterly business-related executive summaries for the C-suite, including notes on everything significant (initiatives, projects, budgets & resourcing, incidents …) and mid-term plans (looking ahead maybe a year or two);
• Annual high-level summary reports to senior management (C-suite and Board) and, if appropriate, other significant stakeholders (owners, auditors, regulators, business partners …) presenting only the most significant information and longer term/strategic plans stretching a few years ahead.

In addition to these planned, regular reports, there may also be a need for ad hoc reporting on specific areas and particular audiences, such as:

• ISMS management reports, internal audits and external audits;
• Significant incidents and near-misses (corrective actions), plus ISMS improvement opportunities (preventive actions) i.e. projects and initiatives, including proposals for new investments;
• Anything else that deserves to be ‘escalated’ up through the management layers, or needs to involve and gain wider support e.g. policies and governance aspects;
• Whatever other reporting various audiences require e.g.for planning, structuring and coordinating infosec-related activities that cross departments, business units and/or businesses e.g. mergers and acquisitions, restructuring, new products …

I am tempted to turn this into a set of reporting templates for the ISO27k Toolkit, incorporating some of the other ideas debated on the Forum, but I'm not sure it's worth the effort. Every organisation has its own preferred management reporting styles, hence the templates would need to be customised anyway. Alternatively, an FAQ would capture the wisdom well enough for some readers. For now, I hope we have addressed the original poser and provided plenty of food for thought. As always, comments are welcome.

Infomation security control attributes

Today I published a 20-page white paper about 'control attributes', inspired by those presented in ISO/IEC 27002:2022

The concept behind the paper has been quietly brewing for a couple of months or more, taking the past few weeks to crystallise into words in a form that I'm happy to share publicly.

In a nutshell, 'attributes' are characteristics or features that can be used to categorise, sort or rank information security controls by various criteria. That simplistic concept turns out to unlock some powerful possibilities, described pragmatically in the paper. 

It's a more innovative and valuable technique than it may appear.

Along the way, I regret inadvertently upsetting the team of JTC 1/SC 27 editors working on ISO/IEC 27028 by sharing an incomplete draft with them in the hope it might become the basis of the initial draft of the new standard.  

During a Zoom meeting. At 3:00am, NZ time. I wasn't at my best. Ooops.

Anyway, now the paper is published, I'm hoping to prompt debate and insightful comments, gathering useful feedback and especially improvement suggestions from readers, leading in turn to a better document to submit (through the proper process, this time!) to the SC 27 project team. We may unfortunately have missed our opportunity to deliver a complete 'donor document' to use as the first working draft of the new standard but all is not lost. The paper's suggestions on how to use attributes will, I hope, make a substantial contribution to the second working draft, and in time inform the issued standard.

It is published under a Creative Commons licence. Exposure, discussion and insightful comment is what I'm after so, in addition to this blog, I have notified the 4,500 members of the ISO27k Forum about the paper and released it to an unknown number of LinkeDinners.

Care to join the gang? Download the latest version of the paper here.  It is refined and updated occasionally, hence it may never be 'finished'.

Share and discuss it with your peers and colleagues.

Rip it to shreds. 

 

Find creative angles to expand on it. 

 

Imagine even better ways to milk every last drop of value from those control attributes.

Then email me: Gary@isect.com

 

The first working draft of ISO/IEC 27028 accompanying a formal proposal for SC 27 to develop the standard is due out this month for voting and comments by mid-April.

PS  A while (7 years!) ago, I blogged about a suggestion to evaluate the organisation's information security budget according to the proportions of spending on preventive, detective and corrective controls. I was unimpressed with the low PRAGMATIC value of the metric ... but nevertheless the idea of using control attributes to review budgets remains intriguing.