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

This week, I'm thoroughly engrossed by a deep dive into ISO/IEC 2382, a suite of standards on IT terminology from the 1990's around the end of the previous millennium - ancient history as far as IT goes. "ISO 2382 was initially based mainly on the usage to be found in the Vocabulary of Information Processing which was established and published by the International Federation for Information Processing and the International Computation Centre, and in the American National Dictionary for Information Processing Systems and its earlier editions published by the American National Standards Institute (formerly known as the American Standards Association). Published and Draft International Standards relating to information technology of other international organizations (such as the International Telecommunication Union and the International Electrotechnical Commission) as well as published and draft national standards have also been considered." I say "IT" but it...

The CISO Playbook by Andres Andreu ISBN:  978-1032762074 US $48 from Amazon (softback) GH rating: 70% Summary The CISO Playbook  is a valuable resource for cybersecurity specialists seeking to build on their technical competencies and progress, or for mid-level IT professionals looking to deepen and extend their understanding of cybersecurity technologies. However, aspiring or newly promoted or appointed CISOs seeking practical advice on the leadership and management challenges of a true C-suite role are out of luck.  The book  leans towards technical details rather than leadership and management topics, core parts of the CISO role.   While the technical coverage is commendable, the book would benefit from a broader perspective that encompasses the full scope of a CISO's senior management responsibilities.  Frankly, and despite the title, t he approach described is, I feel, better suited to Cybersecurity or Information Security Managers, heads of department...

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

If, as many security professionals evidently believe, risk concerns the possibility of harm, then surely we ought to do everything possible to reduce the possibility and/or the harm caused, by strengthening and extending security or ideally avoiding it completely by simply not doing risky things - right? OK, so then why do we take risks at all ? Why do we need security to mitigate bad stuff? Security is costly and fallible, so can't we save money by totally avoiding or eliminating risk? Errrrrmmm  ... since it's philosophical phriday, this is an opportunity to explore the issue further, taking a deep dive. But, before I blabber on, dear reader, please take a moment to ponder this for yourself.  No, take several. Take as long as you can. Take the rest of the day off: it's phriday after all. Why do we take risks?  Seriously, why ?   What does it mean to 'take risk'? Grab a pencil or mouse. Jot something down. Think again.  Ponder on. Keep listing, scribbling,...

Last year in the course of collaboratively developing the Adaptive SME Security method , a friendly group of experts from the ISO27k Forum came up with the 'iterative risk assessment' approach. It is a pragmatic way to start a regular security improvement cycle - one that is realistic even for the tiniest of micro-businesses (sole proprietors). The process is a simplified version of conventional information risk management, tackling just one piece of the puzzle at a time. The bite-sized chunks can be picked up and chewed over as-and-when, and parked temporarily if (when!) something more urgent comes up. Each run through the cycle uses a single incident to exemplify and explore the associated risks in a way that any SME can manage - in fact, even larger organisations might benefit from this if their information risks aren't being managed effectively, to re-energise the process, or to share the work throughout the business. Time-boxing the cycle at (say) a month should avo...

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