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?

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

Yesterday I blogged about ISO/IEC 2382 - Information technology - vocabulary . In particular, one of the ~2,000 ISO definitions stood out enough to catch my beady eye: “ Computer-system audit : examination of the procedures used in a data processing system to evaluate their effectiveness and correctness, and to recommend improvements”. Errrr, that covers  some of the audit work I have undertaken, led/managed, been subjected to or heard about in my career* but omits rather a lot e.g. :   IT governance arrangements, strategies, information risk and security management, direction and oversight, structure, integration with other business functions, rôles and responsibilities, accountabilities, reporting lines, assurance, continuous improvement, barriers and progress; Staffing levels and competencies, recruitment and retention, succession planning, contractors and consultants; Security administration, joiners/movers/leavers, culture, awareness and training, accounts/identif...

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

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

Recently I enjoyed a lecture by a bank's economist to local business leaders concerning the NZ economy. Observing the blizzard of graphs, I was struck by his short timeline , stretching to about a couple of years ahead. Now I'm sure the economist is earning his crust at the bank. Of course they need to keep on top of day-to-day and month-to-month fluctuations in the economic parameters, playing the markets. Equally, I'm sure the bank has other experts with a longer-term outlook, diligently modelling the implications of national and global issues including political, social, environmental and technological, for many years or decades ahead - for at least as long as the bank's mortgages and business loan periods anyway. Nevertheless, that prompted me to think about planning horizons in information risk and security management, within the broader context of budgeting and investment management in any commercial organisation - a pertinent topic as we plummet towards the new c...

The Institute of Directors has just released their Code of Conduct for Directors , promoting six principles: Leading by example. Integrity. Transparency. Accountability. Fairness. Responsible business. So far, so good ... although somehow I feel there's something missing. But what?

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

I am delighted to announce the release of   Adaptive SME Security : The guide describes a pragmatic, five-phased approach for  S mall to  M edium-sized  E nterprises to manage their information risk and security arrangements:

NIST has just released SP 1314 Risk Management Framework (RMF) Small Enterprise Quick Start Guide  as a lightweight form/introduction to the full RMF. ... and, despite having said the steps are not necessarily sequential ... It's interesting to compare and contrast the NIST RMF against the  Adaptive SME Security  approach we released just last week: