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?

I'm not a fan of new year's resolutions that tend (in my experience) to have limited impact and are often soon forgotten. My cynical self says the same thing applies to pledges, vows and other stated commitments, even agreements and contracts to some extent. They are more symbolic than actual control mechanisms (although I'm sure the lawyers would argue otherwise - on the clock, naturally). The focus is often on avoiding, preventing or stopping bad things, a negative emphasis although the actual language may be positive as in "I will lose weight" and "I will get fit". They can be a last resort, a sharp retrospective reminder of where we thought we were going when we are already heading off-course.

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

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

The last of a dozen learning points I made in a post-incident review of the Crowdstrike incident was: "Unless changes are actually made as a result of an incident, the uncertainties (risks) remain. We have missed out on a valid learning and improvement opportunity." Although I accept that nobody is obliged to learn from incidents, make changes or improve, the Crowdstrike incident was Big News when it occurred back in July, and here we are in October. So it's fair to ask what - if anything - are we doing differently now? [I'm using Crowdstrike here simply as a well-known example. Even if the Crowdstrike incident had no material impacts on your organisation, you have undoubtedly suffered various incidents, possibly something serious or critical. As you read on, by all means substitute some other significant recent incident in place of "Crowdstrike" if that helps you relate to this piece.]  A cyberattack can be a devastating event for any organization. It'...

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.

I blogged about the Crowdstrike incident on July 21st  while it was still playing out. Now, having  d rained the swamp and let the d ust settle, I'm  d ue to d raw out, d econstruct and d ecide what to d o about the Crowdstrike d isaster, so here goes: Design, build and test systems for resilience, where 'systems' means not just IT systems but the totality of interdependent technologies, organisations, people, information flows and other resources necessary to deliver and support critical business activities. Hinson tip : "be prepared" is not just for  boy scouts ! Those dependencies are p otential p inch p lus  p ain p oints. Test software before release. Sounds easy, right? It isn't. There is an infinite amount of testing that could be performed, only a fraction of which realistically should be, while the amount and quality of testing actually performed is resource-constrained and time-boxed for business and uncertainty (risk!) reasons (delaying secu...

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: 

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.

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

This risk analysis process/method blends risk, security, incident and problem management, creatively combining imaginary with actual data and concerns: Imagine you've experienced a 'typical' incident affecting whatever [information] asset/s you are risk-assessing - such as a physical incident affecting the office. Consider various types of incident, of various scales and importance e.g . an office break-in, vandalism, professional hit, insider theft, fire, flood ... or whatever. For now, pick out whatever type/s of incident seems most likely and/or damaging for further consideration - not least, real incidents that have occurred (this analysis might follow an actual incident for maximum reality!). Start exploring the associated threats, vulnerabilities and impacts, using information about actual incidents (under similar circumstances) to inform your analysis - or wing-it using common sense. This step initiates the risk analysis, clarifying the asset/s and risks of most ...

Title: Permanent Record Author: Edward Snowden ISBN: 978-1-250-23723-1 Price: US$18 from Amazon GH rating: 90% Summary Until I read this book, I considered my personal integrity a fundamental strength, core to my very being. It pales in comparison to Ed's extreme courage and intense determination to expose the shocking truth about the NSA's mass surveillance programme and the way it was concealed from Congress.

  "A calamity can often strike without warning. Whether it be generated by humans or a natural disaster, leaders need to be ready to direct their teams in the aftermath. In order to be ready for crisis, leadership skills, like any others, must be practised over and over beforehand. So the way you lead in the quiet times helps to build the skills you need when you have to dig deep." That paragraph plucked from this month's impressive  NZ Airforce newsletter  about the military response to the devastating flooding caused by cyclone Gabrielle here in Hawkes Bay caught my beady eye this morning.  The idea of practicing incident management as well as incident handling or operations  on relatively small incidents makes perfect sense.

ISO/IEC 27001 formally requires just 14 types of "documented information" of  every organisation competently certified conformant with the standard, as a minimum: 1.        ISMS scope (Clause 4.3); 2.        Information security policy (Clause 5.2); 3.        Information security risk assessment procedure (Clause 6.1.2); 4.        Statement of applicability (Clause 6.1.3 d); 5.        Information security risk treatment procedure (Clause 6.1.3); 6.        Information security objectives (Clause 6.2); 7.        Personnel records (Clause 7.2); 8.        ISMS operational information (Clause 8.1); 9.        Risk assessment reports (Clause 8.2); 10.    Risk treatment plan (Clause 8.3); 11. ...

" Seventy Questions to Assess Cybersecurity Risk on a Rapidly Changing Threat Landscape "  is an ISACA 'industry news' article by Patrick Barnett.  Whereas normally I give 'industry news' and checklists a wide berth, Patrick is (according to the article) highly qualified and experienced in the field, so I took  a closer look at this one. The prospect of condensing such a broad topic to a series of questions intrigued me. I'm not totally immune to the gleaming allure of well-conceived checklists. Patrick says: "There are 70 questions that can be asked to determine whether an enterprise has most defensive principles covered and has taken steps to reduce risk (and entropy) associated with cybersecurity. If you can answer “Yes” to the following 70 questions, then you have significantly reduced your cybersecurity risk. Even so, risk still exists, and entropy must be continuously monitored and mitigated. There is no specific number of layers that can remove...

The second edition of ISO/IEC 27032 "Cybersecurity - Guidelines for Internet security" has just been published. The introduction to the new edition commences: "The focus of this document is to address Internet security issues and provide guidance for addressing  common Internet security threats, such as: — social engineering attacks; — zero-day attacks; — privacy attacks; — hacking; and — the proliferation of malicious software (malware), spyware and other potentially unwanted  software." Notice the standard is focused on " Internet security issues " which, in practice, means it covers active attacks perpetrated via the Internet. However:

On LinkeDin this morning, Morten Ingvard asked: "As part of updating and reshaping some parts of our information security management system (ISMS), I'm not convinced that the new categorization of controls in ISO/IEC 27002:2022 (Organizational, people, physical and technical), is the best suit for our organization to rationally identify relevant controls for their work. I understand there is an increased focus on the use of attribution - so controls can be selected based on different perspectives, but I want to have a "default view" that the organization can read and understand, and currently, I'm strongly considering sticking with a categorization structure looking more like the older 2013-version in ISO/IEC 27001." Here's my response to Morten: "The categories are primarily a convenient way to sequence the controls in the standard. It was the 'default view' selected by ISO/IEC JTC1/SC27.

A post on LinkeDin this morning led me to a news piece  about an IT professional's attempt to divert/steal his employer's payoffs for a ransomware infection, back in 2018. According to the article, his attempt ultimately failed, largely due to his inept and naive execution ... but I have not come across this particular insider threat before. It was a new one on me, a man-in-the-middle attack layered on top of the ransomware.

A warning in the New Zealand Information Security Manual  caught my beady eye yesterday: “Electrical and electronic equipment contains a complex mix of materials, components and substances, many which can be poisonous, carcinogenic or toxic in particulate or dust form. Destruction and disposal of WEEE [Waste from Electrical and Electronic Equipment] needs to be managed carefully to avoid the potential of serious health risk or environmental hazard.” Disposing of eWaste presents environmental and safety hazards arising from noxious/toxic/carcinogenic chemicals such as gallium arsenide (GaAs) and polychlorinated biphenyls (PCBs), plus the obvious dangers when handling sharp-edged metal or plastic chassis fragments, wires, printed circuit boards and CD/DVD discs plus  leaky electrolytic capacitors and old batteries . While there may be money to be made by extracting and recycling valuable metals  and reusable components ,  subsystems and modules , that's really a jo...