An interesting topic cropped up on the ISO27k Forum this week. In essence, the issue is whether a small, immature company without an I nformation S ecurity M anagement S ystem could or should have an information security policy. ​ Speaking as an infosec pro, the knee-jerk response is "Yes, of course!". Why do I say that? If SmallCo's CEO or owner asked me to explain, how would I justify my recommendation to have a policy? Hmmm. Tag along or watch from the precipice as I dive into another rabbit warren.

There are information risks associated with people joining any corporate function – information risks that deserve to be identified, assessed, evaluated and treated appropriately like any other. If your organisation currently pays little if any attention to these risks, how about developing and trialling a suitable strategy and approach for, say, the information risk and security management function, as a pilot or demonstrator for other corporate functions and rôles that place a high reliance on the personal integrity of their people?

This morning, Greg asked us on the ISO27k Forum for advice on ISO/IEC 27001:2022 security control A.5.7 Threat Intelligence. "I've read the details in ISO 27002 and understand it in theory. But what does a threat intelligence program consist of and look like when implemented? What tools would a infosec team use to collect threat intel, how would they analyze it and use it, etc? What have you seen in your own environments or those of clients?" FWIW here's my response: I agree with you Greg: the page of advice on threat intel in '27002 is all well and good, but what does this look like in practice? It's not entirely obvious. At a basic level, it starts with 'situational awareness' - someone simply watching out for potential or actual threats in the organisation's external and internal environments, spotting them, tracking them, thinking about and maybe responding to them. Threats become evident when incidents occur, of course, but also events and ne...

Whereas ISO/IEC 27001 indicates that only fourteen (14) types of ISMS documentation are strictly required  (mandatory), they are barely a start, even for a barebones ISMS.  In practice,  both mandatory and  discretionary documents are valuable . ISO/IEC 27001 c lause 4.4   states: “The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document.” Documentation (termed 'documented information' in the standard - see clause 7.5) is generally the best way for management to inform workers about their information security responsibilities  e.g. through written policies, procedures/work instructions and job/role descriptions, accompanied by awareness and training materials such as guidelines and briefings. In addition, many security-related processes generate 'records' such as completed forms, ...

Denis Yakimov ​shared this on LinkeDin: " Imagine your ISMS as a battlefield: Context : The battlefield terrain—topography, weather, and conditions. Issues : Your main enemies. ​Controls and SoA : Troops, tools, and fortifications. Each control is a soldier with a specific purpose. ​Leadership : The chain of command, setting the battle’s tone and ensuring everyone understands their role. ​ Planning : The war strategy how to deploy soldiers (controls) to address issues under current conditions. ​Operation : Execution of the battle plan where soldiers confront issues directly. ​ Internal Audit : A field hospital that identifies wounded soldiers and offers opportunities to remediate them. Improvement : Lessons learned applied to strengthen future engagements.” ​Google Gemini made a reasonable if naive attempt to draw a military analogy for me too: ​ " Imagine a military base: ​ The Base : Represents the organization and its information assets. ​ The General : Top management, se...

Inspired by these pizza baking instructions, I thought I'd have a go at condensing an entire ISO/IEC 27001 implementation project to its absolute fundamentals.  So here goes ...

In a discussion thread on the ISO27k Forum about selecting appropriate information security controls, a member told us: "As far as software development is concerned, we really need the controls A8.25 and following". I queried that determination, guessing  their thought process may have been along these lines:  We do software development. Controls A8.25+ concern software development. Therefore, for conformity with ISO/IEC 27001, controls A8.25+ are applicable and cannot be excluded. #3 is patently a false conclusion, a logical error. The Annex A controls are  not  formally required for conformity with the standard. They are not mandatory - none of them, not one. If you believe otherwise, kindly explain which specific clause from ISO/IEC 27001 contains that explicit requirement because, despite hunting high and low over many years, and despite numerous claims from so-called experts in the field, I simply can't find it. There  is , however, a formal req...

Implementing and using an ISO/IEC 27001 I nformation S ecurity M anagement S ystem can be tricky, especially given limited resources or in complex or dynamic business and technology environments.   While largely-manual approaches may suffice for small, simple, stable organisations, dedicated ISMS support tools (computer applications and cloud services) are well worth considering.   With dozens of ISMS tools on the market, the obvious question is which to choose.   Here are some commonplace requirements or factors to consider: Support information risk identification, evaluation, treatment and monitoring, of course. Support compliance/conformity with applicable standards, regs, laws and contractual obligations. Interoperable with existing systems/processes for asset management, risk management, business continuity management, incident management, vulnerability scanning, anti-malware etc . Support the identification, investigation and resolution of security incidents. Supp...

In the past few days, I have been triggered yet again by someone fearing that ISO/IEC 27001 certification auditors may insist that various Annex A controls are applicable and must therefore be implemented for conformity. Apocryphal nightmares about auditors doing exactly that tend to stoke the fear and prolong the myth. Myth, yes, myth. I've said it before and no doubt I'll say it again: the Annex A information security controls are not formally required for conformity with the standard - none of them, not even one. If you or your auditors believe otherwise, kindly tell us which clause of the standard applies. What are the exact words leading to that conclusion? Spoiler alert: there are none. There is no such requirement. IT DOES NOT EXIST. There is , however, a conformity requirement to check through Annex A for any controls that might reduce otherwise untreated information risks, but even then there is no (repeat, no ) obligation to implement the controls as stated in A...

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?

First, two definitions: " Certification " is the process of checking something against defined criteria, and if it passes (meets the criteria), issuing a certificate of compliance or conformity or assurance or whatever. Certification gives some assurance that the certified organisation or individual meets the criteria ... provided the certification body or person is competent and trustworthy, the checks were done properly, and the certificate itself is authentic. Hmmm, quite a few caveats there ... " Accreditation " is the process of confirming that whoever is checking and issuing certificates is properly qualified, competent and trusted to issue meaningful certificates by following prescribed processes. It adds credibility, meaning and value to the certification and issued certificates ... provided the accreditation body or person is competent and trustworthy, the checks were done properly, and the a...

ISO+IEC have been working hard to develop, pilot, refine, document and now release a new system for developing standards collaboratively .  " O nline S tandards D evelopment" allows editors, expert contributors, reviewers, proofreaders, project managers, officers and the ISO Secretariat  etc . to work on the same document at the same time as a globally-distributed/virtual team.

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.

ISO/IEC 27403 " Cybersecurity – IoT security and privacy – Guidelines for IoT-domotics " was published at the very end of last month. “Domotics” is a neologism for smart homes. This  new   standard  covers the cybersecurity and privacy aspects of thing -to- thing interactions ( e.g. home hubs and entertainment subsystems) as well as human-to- thing  plus  thing -to-sensors/actuators that physically interact with the home ( e.g . smart door locks and thermostats) and networking both within the home ( e.g . WiFi, Bluetooth) and beyond ( e.g . fibre or wireless broadband). The  standard  is aimed squarely at guiding the designers, manufacturers and security or privacy assessors of IoT domotics, as oppoed to retail customers and users. It provides examples of information risks that should (in theory at least) have been identified, evaluated and addressed by IoT suppliers baking-in suitable security controls to protect their valued customers' interests. I...

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, disinfor...

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

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.

This morning on the ISO27k forum, Vurendar told us:  "I saw your pragmatic book but I was confused on the way criteria and no’s were assigned. If you could guide will really help.  I’m doing a RBI Based compliance assessment where regulator has asked for such metrics. Help would be really appreciated."   Here's my reply.   For guidance on choosing which metrics to take a look at and maybe score, I recommend Lance Hayden's book " IT Security Metrics " which describes the  G oal- Q uestion- M etric approach. 

This checklist is appended to a SecAware guideline on implementing an ISMS , elaborating clause-by-clause on ISO/IEC 27001 - essentially, our version of ISO/IEC 27003 .   It offers  pragmatic guidance for information security managers and CISOs - nothing too obscure or complex. ---oooOOOooo--- Project definition, justification, scoping and planning ⬚   Study the standards, in depth: complete lead implementer training if possible. ⬚   Study the business, in depth, to understand its objectives, strategies, culture, governance arrangements, existing information risk and security management etc . ⬚   If the organisation has a defined, structured approach for this phase, use it! ⬚   Build a business case that identifies and promotes the business benefits of the ISMS. ⬚   Look beyond ‘security’ and ‘compliance’ e.g . helping management to manage business risks, supporting/enabling other business initiatives and strategies.

Like other ISO management systems standards, ISO/IEC 27001:2022 has just been amended to incorporate two small wording changes : “The organization shall determine whether climate change is a relevant issue” (clause 4.1); “NOTE: Relevant interested parties can have requirements related to climate change.” (clause 4.2). So, it is fair to ask what has climate change got to do with information risk and security? Is it even relevant? Having been been mulling that over for quite some while now, I've come up with a dozen points of relevance: For more on those twelve, read " Secure the Planet " - a FREE white paper. The clock in that image is a reminder that time is pressing, so here are half-a-dozen things information risk and security professionals can do to help.