Recovering from a ransomware incident is costlier, more complicated and much slower that people commonly assume. "Just restore the backups and you're good to go, right?". Spoiler alert: restoring networks and IT systems from backups is only a fraction of this.  Here's a reasonably complete set of ransomware recovery activities that would normally led by general business and IT managers : Wake up and smell the coffee! Deal with the unfolding crisis and a degree of confusion. Invoke the crisis management process. Settle things down. Assemble the business incident management team. Invoke the incident management process. Form the IT incident management team. Contact insurers, law enforcement and security experts for guidance.

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

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

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

We find ourselves in the midst of a classic social response to a significant incident - a heady blend of technobabble, confusion and hyperbole, with a sprinkling of genuinely helpful information, grief and support for those right in the thick of it, and warnings about the likelihood of further exploitation ... of ... the classic social response to a significant incident.  That's a positive feedback loop, amplified by the echo chambers of social media, and traditional news reporters whose job is (in part) to stir the pot and sell papers. "This is HUGE !" they tell us, breathlessly. "Bigger than a really big thing, and still growing!"  According to the din just on LinkeDin over the weekend, the Crowdstrike incident is "a major global outage", a " mass global outage and major impact to services",  "carnage", "cataclysmic", "global chaos", the "patchpocalypse", "digital catastrophe", "the bi...

"Mitigation and adaptation are required together to reduce the risks and impacts of climate change, including extreme weather events. Mitigation refers to actions taken to limit the amount of greenhouse gas emissions, reducing the amount of future climate change. Adaptation refers to actions taken to limit the impacts of a changing climate. Mitigation and adaptation together provide co-benefits for other environmental and social goals." That paragraph by Lizzie Fuller, Climate Science Communicator for the UK's Met Office, plucked from another excellent digest of lessons learned from various UK resilience exercises and initiatives , obviously con cerns climate change ... but it occurs to me that 'mitigate and adapt' might be a novel approach to information risks and impacts as well.

A provocative piece on LinkeDin by Brian Matsinger caught my beady eye and sparked my fertile imagination today. I'm presently busy amplifying the disaster recovery advice in NIS 2 for a client. When I say 'amplifying', I mean generating an entire awareness and training piece on the back of a single mention of 'disaster recovery' in all of NIS 2. Just the one. Blink and you'll miss it. Oh boy. Anyway, Brian points out that recovering from disasters caused by 'cyber attacks' requires a different DR approach than is usual for physical disasters such as storms, fires and floods. Traditional basic DR plans are pretty straightforward: essentially, the plans tell us to grab recent backups and pristine systems, restore the backups onto said systems, do a cursory check then release services to users. Job's a good 'un, off to the pub lads.

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

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.

The conventional focus of risk analysis is to examine the probability of incidents occurring, and their likely impacts if they do - and fair enough, those are obviously key factors ... but not the only ones. Add itional factors to consider include : Quality of information and analysis : risks that are commonplace and conventional are generally better understood than those which are novel or rare (such as AI risks, right now); Volatility : if the threats, vulnerabilities and business are reasonably stable, the risks are more easily determined/predicted than if they are volatile, changing unpredictably; Complexity : ugly, horrendously complicated risks are more likely to involve unrecognised interactions;

I've been thinking about the 'treatment' phase of risk management lately. These are the four conventional and generally-accepted ways of treating (addressing) identified risks: Acceptance : living with the risk, hoping that it doesn't materialise; Avoidance : steering well clear of, or stopping, risky activities; Mitigation : reducing the probability and/or impact of incidents using various types of control;   Sharing : with others, such as business partners, insurers and communities. However, it occurs to me that a further eight risk treatment approaches are possible, whether you consider them alternatives, variants or complementary: Procrastination : delaying decisions and actions ostensibly in order to understand risks and possible treatment options (which, meanwhile, implies risk acceptance). Speedy decision-making is an important part of effective

Since home and mobile workers rely on IT to access critical business systems and corporate data, and to communicate with others, organisations need a robust IT network infrastructure that extends to workers' homes or wherever they hang out. If, in reality, the infrastructure turns out to be fragile and unreliable, business activities are likely to be equally fragile and unreliable, leading to frustration and grief all round. In other words, the extended IT infrastructure is quite likely business-critical. W orking F rom H ome or on the road can increase various information risks relative to conventional office-based work, due to factors such as: Use of cloud computing services*; Workers using their own or shared devices and internet connections for work purposes, raising questions about their suitability and security, ownership of and access to any intellectual property or personal information on them;

Clearly there are some substantial risks associated with using AI/ML systems and services, with some serious incidents having already hit the news headlines within a few months of the release of ChatGPT. However, having been thinking carefully and researching this topic for couple of weeks, I realised there are many more risks than the reported incidents might suggest, so  I've written up what I found. This pragmatic guideline explores the information risks associated with AI/ML,  from the perspective of an organisation whose workers are using ChatGPT (as an example) .   Having identified ~26 threats, ~6 vulnerabilities and dozens of possible impactful incident scenarios, I came up with ~20  information security controls capable of mitigating many of the risks. See what you make of it. Feedback welcome. What have I missed? What controls would you suggest? 

I've long been fascinated by the concept of 'resilience', and surprised that so many people evidently misunderstand and misrepresent it ... so please bear with me as I attempt to put the record straight by explaining my fascination. Resilience is not simply:  Being secure Being strong Recovering effectively, efficiently or simply recovering from incidents Avoiding or mitigating incidents Any specific technical approach or system Any particular human response, action or intent A backstop or ultimate control Heroic acts A construct, something we design and build Something that can simply be mandated or demanded Specific to particular circumstances, situations or applications It's bigger than any of those - in fact bigger than all of them, combined. Resilience is all of those, and more ... Resilience is : A general concept, a philosophy, a belief An engineering and architectural approach

Information risk management is a crucial business issue in the digital age. This piece describes a systematic and proactive approach to information risk management with a healthy dose of pragmatism. It is obvious that serious incidents such as ransomware can disrupt operations, severely damaging an organisation's reputation, brands and customer trust, threatening its financial stability and longevity ... but that's not all. Even relatively minor incidents can accumulate significant costs over time, starving other important business activities of resources. Given that practically everything depends on information, the starting point is to embed information risk management fully into the organisation's business strategy and routine operations. Most organisations have basic information security controls in place. However, a strategic approach is less common, while a truly comprehensive business-oriented  approach to information risk management remains quite rare.  Information ...

Two and a half years ago in March 2020 as we were fast approaching our first lockdown, I published the following P robability I mpact G raph depicting my analysis of the information risks relating to COVID: The PIG reports the information risks I identified at the time, thinking about COVID from the general societal perspective as opposed to a personal or organisational perspective.

There are clearly substantial information risks associated with the redaction of sensitive elements from disclosed reports and other formats, risks that the controls don't necessarily fully mitigate. Yes, controls are fallible and constrained, leaving residual risks. This is hardly Earth-shattering news to any competent professional or enlightened infidel, and yet others are frequently shocked.  A new report* from a research team at the University of Illinois specifically concerns failures in the redaction processes and tools applied to  PDF documents . The physical size of redacted text denoted (covered or replaced) with a variable-length black rectangle may give clues as to the original content, while historically a disappointing number of redaction attempts have failed to prevent the original information being recovered simply by removing the cover images or selecting then pasting the underlying text. Doh!

... "adverse change to the level of business  objectives achieved" [source:  ISO/IEC 27000 ] ... the inertial energy imparted by a moving mass impinging upon an object ... "t he adverse outcome or consequences caused by or arising from an information security incident , leading to direct and/or indirect (consequential) losses/costs to the organisations and/or the individuals concerned" [source:  SecAware glossary ] ... the point when probability functions collapse ... when possibility becomes reality ... when threat meets vulnerability ... short, medium and long-term ... loss of control over an asset ... too late to prevent or avoid ... being smacked in the head ... when p (occurrence) hits 1 ... when gloved fist hits chin ... what we tried to prevent ... what we sought to avoid ... an impressive entrance ... the resonance of a bell ... when risk eventuates ... when shit meets fan ... not too late to react ... being compromised ... a successful attack ... the p...

A member approached the  ISO27k Forum   this morning for advice: " What would you recommend to do if our warnings as ISMS department specialists/auditors are not taken into account?" What can realistically be done if  management isn't paying sufficient attention to information risks that we believe are significant ?  This is a thorny issue and not an uncommon challenge, particularly among relatively inexperienced or naïve but eager information risk and security professionals, fresh out of college and still studying hard for their credentials. It can also afflict the greybeards among us: our passion for knocking down information risks can overtake our abilities to convince managers and clients. Here are ten possible responses to consider: 

This morning I bumped into a marketing/promotional piece announcing PageProof’s certified "compliance" (conformity!) with "ISO 27001" (ISO/IEC 27001!). Naturally, they take the opportunity to mention that information security is an integral part of their products. The promo contrasts SOC2 against '27001 certification, explaining why they chose ‘27001 to gain some specific advantages such as GDPR compliance - and fair enough. In the US, compliance is A Big Thing. I get that. It occurs to me, though, that there are other, broader advantages to ‘27001 which the promo could also have mentioned, further valuable benefits of their newly-certified ISMS.