Basing ISO27k standards on risks

While catching up with a backlog of ISO27k emails from SC27 to update www.ISO27001security.com, our ISO27k information site, a new project has me very confused. 

Given the new standard's working title "The Use and Application of ISO/IEC 27001 for Sector/Service-Specific Third-Party Accredited Certifications", what do you think ISO/IEC 27009 will cover? 
Few of the originally-envisaged “sector-specific” variants of ISO/IEC 27001 or 27002 have surfaced since those standards, like BS 7799 that spawned them, are deliberately broad in scope and very generally applicable. At present, we have sector-specific ISMS variants for the telecomms, finance and healthcare industries (ISO/IEC 27011, ISO/IEC TR 27015 and ISO 27799 respectively), with something for the energy industry under development (ISO/IEC TR 27019).
Rather than working on a standard for 'use and application' of sector-specific ISMS standards (whatever that means), and given that the core philosophy of ISO27k is to determine and then treat information security risks, I would argue that there is a far more pressing need for the standards to identify information security risks that are typical or common within various sectors and situations. This would give management a strong steer as to the information security risks that probably ought to feature highly in their risk registers, which in turn would drive the implementation of suitable risk treatments, including mitigating controls. Their actual risks will vary, of course, but do you agree there's value in giving hem a starting point - guidance on the kinds of infosec-related risks that (as a minimum) ought to be analyzed and treated by users of the ISO27k standards under different circumstances?
Come to think of it, how about SC27 making all the ISO27k standards themselves explicitly risk-based, laying out and discussing the risks that they supposedly address?
  • ISO/IEC 27000 should address the concepts of information security risk assessment/analysis and treatment in general terms, and pick up on other relevant risks such as the risks of being at cross purposes when multiple parties are discussing and agreeing information security requirements and obligations, if their fundamental architectural models, vocabularies and understanding differ markedly;
  • ISO/IEC 27001 should address the risks of not managing or mis-managing information risk and security through a management system;
  • ISO/IEC 27002 should address generic information risks (meaning that section 4 of ISO/IEC 17799 and ISO/IEC 27002:2005 should not merely have been retained, but significantly expanded since risk reduction is the rationale for the control objectives and controls that follow);
  • ISO/IEC 27003 should address the risks associated with ISMS implementation projects;
  • ISO/IEC 27004 should address the risks associated with a lack of relevant, reliable and up-to-date information on the status of the information security risks and controls, plus the associated security management processes, information security resources, information security incidents, business continuity arrangements etc. and the extent to which they satisfy strategic objectives and goals for information security;
  • ISO/IEC 27005 should address the risks associated with incorrectly or incompletely identifying and treating information security risks (e.g. emphasizing the need for incident management, business continuity and contingency arrangements to handle information security risks that were not identified or appreciated as such, were inadequately treated, that changed or materialized unexpectedly, or that exceeded the capabilities of the mitigating controls);
  • ISO/IEC 27006 should address the risks relating to compliance assessments and certification (e.g. the possibility of incompetent auditors, collusion/coercion, concealment or fabrication of material facts, misinterpretation of the evidence, questions around scope and purpose of the ISMS, inherent limitations of compliance auditing real-world organizations against generic, formalized standards etc.);
  • ISO/IEC 27007 should address the audit risks associated with management systems auditing (e.g. incompetent, weak or misguided auditors, audit scope and time constraints, changes between audits, limited or misleading information provided by auditees, risks to the certification scheme as a whole if certified organizations prove insecure etc.);
  • ISO/IEC 27008 should address the myriad risks associated with IT auditing (e.g. incompetent, weak or misguided auditors, audit scope and time constraints, changes between audits, limited or misleading information provided by auditees etc.);
  • ISO/IEC 27009 should address the risks relating to this standard, whatever it turns out to be ...;
  • ISO/IEC 27010 should address the risks arising from inadequate communications between organizations on information security matters;
  • ISO/IEC 27011 should address the information risks that are pertinent to the telecomms industry;
  • ISO/IEC 27013 should address the risks associated with integrating, or not integrating, information security and IT service management;
  • ISO/IEC 27014 should address the risks to valuable information assets arising from weak or missing governance, and perhaps excessively strong governance;
  • ISO/IEC 27015 should address the information risks that are pertinent to the finance industry - I understand they have some!;
  • ISO/IEC TR 27016 should address the risks of failing to account properly for the costs and benefits of information security, leading to under- or over-investment;
  • ISO/IEC 27017 should address those information risks floating around in the clouds;
  • ISO/IEC 27018 should address the privacy risks relating to cloud computing;
  • ISO/IEC TR 27019 should address the information risks relating to process controls, SCADA, real-time safety-critical computing, critical infrastructure and all that;
  • ISO/IEC 27031 should address business continuity risks, or rather the risks associated with failing adequately to identify and treat other information risks;
  • ISO/IEC 27032 should address cybersecurity risks, whatever that means;
  • ISO/IEC 27033 should address IT network security risks;
  • ISO/IEC 27034 should address application security risks;
  • ISO/IEC 27035 should address the risks arising from the mismanagement of information security incidents;
  • ISO/IEC 27036 should address the information risks relating to business relationships;
  • ISO/IEC 27037 should address the information risks relating to forensic evidence and the forensics processes;
  • ISO/IEC 27038 should address the risks associated with the redaction process, such as redaction failures, inference, and accidentally releasing the unredacted content;
  • ISO/IEC 27039 should address the risks relating to network, system and site intrusions and the systems that are meant to detect and prevent them;
  • ISO/IEC 27040 should address the risks relating to information storage;
  • ISO/IEC 27041 should address the risks associated with inadequate assurance in forensic processes;
  • ISO/IEC 27042 should address the risks arising from failing adequately to analyse and interpret forensic evidence;
  • ISO/IEC 27043 should address the risks relating to forensic processes;
  • ISO/IEC 27044 should address the risks relating to SIEM;
  • ISO 27799 should address information, health and safety, and privacy risks that are pertinent to the healthcare industry.

Perhaps I should propose this change of approach to SC27, but I just know I would have a hard time getting it discussed, let alone adopted as a policy across all the ISO27k standards.

Being an international committee of experts that meets just twice a year, with no real opportunities for structured discussions or collaborative working between meetings, and with a conspicuous lack of strong leadership direction, SC27 is immensely conservative and slow to change. Such "radical" suggestions typically generate only brief if heated discussions at the committee meetings before being dismissed or ignored, and pretty soon we're back where we started.

To be fair, many of the ISO27k standards kind of mention risks as well as controls, but the linkages are generally tenuous and in most cases the risks are neither explicitly nor comprehensively described.

The issue came to a head for me last year when we came up with eleven information security risks typically associated with redaction: the ISO27k redaction standard ISO/IEC 27038 (due to be published soon) completely fails to address entire classes of risk that are relevant to redaction, having been narrowly scoped with particular redaction scenarios in mind (i.e. redaction of digital documents). The standard will hopefully be a roaring success when it is published but it's yet another golden opportunity lost as far as I'm concerned. Potential customers for the standard who are not myopically focused solely on digital document redaction are unlikely to find much of value in the standard. Worse still, customers who use the advice to formulate corporate redaction policies and procedures may naively believe they have covered all their bases simply by adopting the good practices recommended by an international standard, whereas they probably ought to be treating various other redaction-related risks as well.

To press my point home, consider this topical example. The classified information obtained and published by WikiLeaks and Snowden was unredacted and clearly not intended for publication, but such information commonly is redacted and published following freedom-of-information requests. ISO/IEC 27038 will barely touch on the risk that unredacted original documents might be disclosed, whether by accident or on purpose, as an unwelcome side-effect of the redaction process. A single, somewhat vacuous and unhelpful sentence in the final draft is all I can find on this point: "Original digital documents (e.g. the un-redacted document) shall be retained and be accessible only to those authorized." Note that the risk is merely implied, not stated, while the security advice is at such a high level as to be almost pointless.

Ho hum.

Popular posts from this blog

Pragmatic ISMS implementation guide (FREE!)

Image
Early this morning ( very  early!) I remotely attended an ISO/IEC JTC 1/SC 27/WG 1 editing meeting in London discussing the planned revision of ISO/IEC 27003:2017 . Overall, the meeting was very productive in that we got through a  long  list of expert comments on the preliminary draft standard, debated the objectives of the project and the standard and reached consensus on most points. In summary: 27003 is to be revised to align with the current 2022 releases of ISO/IEC 27001 , 27002 and 27005 : These changes are  mostly  minor aside from the new section 6.3 on ISMS changes.
Read more

Two dozen information risks that ISO forgot

Image
Selecting the wrong controls - controls that are inappropriate, ineffective, too costly, impracticable, fragile, unnecessary, counterproductive or whatever, often as a result of blind faith in fads and fashions of the day and FOMO e.g. MFA, AI, cyber Failing to select the right controls - controls that are ideal for the particular situation, both now and in perpetuity, for whatever reason - mostly ignorance and prejudice Selecting and implementing controls at the wrong time or in the wrong way (where 'wrong' includes ineffective, inappropriate, sub-optimal e.g. bolting on controls rather than designing and building them in) Inept and inaccurate identification, analysis and quantification of risk, including reliance on p oor quality (incomplete, inaccurate, out of date, misleading, unreliable ...) information about actual risks, particularly subtle and emerging risks plus those involving deliberate concealment and misdirection e.g. fraud, misinformation, disinformation, propagan
Read more

Philosophical phriday - compliance risk

Image
According to a vendor's promotional video interview I saw recently, the 'cybersecurity compliance burden' has allegedly become so significant that [customer] organisations are eagerly buying [their] software tools and services to help them manage and fulfil their obligations. The vendor's argument goes that, instead of accumulating a ragtag bunch of policies and other controls relating to user Identification and Authentication (I&A), for instance, it makes sense to:  Identify all the cybersecurity-related laws, regulations and standards that apply to the organisation; Examine them for any security control requirements relating to, say, I&A; Rationalise the I&A controls down to the smallest set that satisfies all the requirements - the lowest common denominator; Design, implement, use, manage and maintain those I&A controls; Have the I&A controls checked or audited to gain assurance that the compliance requirements are met.  OK so far? Sounds reasonab
Read more

ISMS internal audit priorities

Image
A thread on the ISO27k Forum sparked my imagination over coffee this morning. Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan.  Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements. ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the stan
Read more

Reading between the lines of ISO27001 [L O N G]

Image
ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons: It is deliberately generic, being applicable to all manner of organisations regardless of difference in location/s, size, industry, maturity, structure, information risk and security status ... and so on. In effect, it specifies the lowest common denominator - the things that ALL organisations should be doing to manage their information security controls, as a minimum. The hurdle is set low enough that every organisation ought to find value in designing, implementing and operating an I nformation S ecurity M anagement S ystem as laid out in the standard. It is a certifiable standard, explicitly specifying the characteristics that every certified organisation's ISMS is expected to have. Again, it is a minimal specification with no concept of typical, average or maximum security: that is entirely down to the organisations themselves to determine, following the information risk management processes minimally de
Read more

Passionate dispassion

Image
Someone who is actively involved in, or is managing, an activity is patently not independent of it. They may well make a conscious, rational and determined effort to be objective, dispassionately reviewing evidence etc ., but their subconscious/emotional biases/prejudices and beliefs/value-systems will inevitably influence what they do. With the best will in the world, they will struggle to challenge and assess their past decisions and activities, especially if they were "certain" or "determined" or genuinely believed they were "doing the right thing". Furthermore, it is very hard for anyone to review the things they did not do, decisions they did not make or options they did not even consider. Mostly, they remain out of sight or out of the question.
Read more

45 ISO Management Systems Standards

Image
The ISO website  currently lists 45 published M anagement S ystems S tandards: 1. ISO 7101:2023 Healthcare organization management — Management systems for quality in healthcare organizations — Requirements 2. ISO 9001:2015 Quality management systems — Requirements 3. ISO 10012:2003 Measurement management systems — Requirements for measurement processes and measuring equipment 4. ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes 5. ISO 14001:2015 Environmental management systems — Requirements with guidance for use 6. ISO 14298:2021 Graphic technology — Management of security printing processes
Read more

Philosophical phriday - a noncompliance ramble

Image
In a previous philosophical phriday post , I moaned about vendors of security compliance support/management tools and services over-promising and under-delivering - an admittedly biased, even cynical opinion piece about the compliance imperative . A recent article in Corporate Compliance Insights notes that "CISOs are not just defenders against cyber threats but also champions of compliance and operational resilience". Hmmm, are CISOs 'compliance champs', really? Today, I'm discussing alternatives to being compliance-driven. How else can organisations drive their information risk, security and related concerns in a positive direction?
Read more

Adaptive SME security Crowdstrike special

Image
As if on cue, along comes a golden opportunity to consider what the Adaptive SME security  approach has to say regarding the Crowdstrike incident: That's not 20/20 hindsight but foresight: I've picked out the most relevant rows from the security controls table published in the guide 24 hours before the incident.  Although Crowdstrike primarily supplies much larger enterprises than SMEs, the incident could equally have afflicted other security software, or indeed operating systems such as Windows and assorted cloud apps commonly used by SMEs. Regardless of the details, it is a wake-up call, an opportunity to consider and respond to the information risks ... and to adapt , accordingly.
Read more