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

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

There is a growing appreciation, perhaps even consensus in the field that information risk management - or indeed risk management in general - is not simply a matter of predicting or controlling the future, at least not in a rational and deterministic manner. Given that the future is inherently complex and uncertain (= risky!), the best we can reasonably hope for is to reduce somewhat the number and negative impacts of disruptive events and incidents, while simultaneously hopefully increasing the chances and value of positive, beneficial outcomes. Both objectives are asymptotic: the effort and investment required to progress increase exponentially as we get ever closer to those two goals, ultimately putting them both beyond our means given finite resources (oh and one or two other things to pour our money into!). In other words, despite our best intentions, we know we are doomed to fail at some point.  Doomed I tell you. That's not merely a pessimistic outlook: I'm an optimist ...

Truly effective deception isn't even recognised as such - it passes completely unnoticed.  There is no shortage of now-recognised examples that the deceived didn't spot at the time and maybe still haven't noticed. Here's a sample: A stick insect appears to a predator to be an inedible stick, not a tasty insect Spotted from an enemy's reconnaisance biplane, an inflatable tank or field gun may appear solid, a credible threat at least While an accomplice distracts a resident by knocking at the front door on a pretext, the cunning thief slips around the back Phishers emulate the look and feel of legitimate emails, senders and websites to dupe victims into visiting and disclosing their credentials, using spurious urgency to shortcut or bypass checks, specific timing and wording, and sheer volume to exploit the offguard vulnerables

For decades, I have appreciated  Peter Sandman 's approach to outrage - the social phenomenon in which groups of people react strongly to some perceived threat, issue, concern or whatever, drawing-in other like-minded individuals via social media. The echo chamber (positive feedback loop) can rapidly escalate emotions to an unreasonable degree with a lack of reasoned, critical thinking - according to those allegedly responsible for the issue anyway.    In the case of, say, the placing of 5G cell towers in/near schools, the outraged can become furious that the risk (as they see it) is being 'callously ignored' by the equipment suppliers, site developers, authorities and scientists, and enraged that they are 'not being taken seriously'. From their perspective,  thanks to group think (social endorsement),  the  perceived   risks are portrayed and understood to be deadly serious .  Leaders within the outraged community gain notoriety, influence and p...

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

Full-on business continuity exercises can be big, intimidating, lengthy, costly (although hopefully still valuable!) and (to some extent) risky affairs for complex organisations or industry groups that really go to town on them ... but that's not the only way. Alternatives include: Solitary plan review/maintenance update - where the person responsible for a particular part of the whole plan (such as a section or department head) sits quietly in a dark corner imagining how things would play out in practice, carefully checking their part, liaising with colleagues as appropriate ( e.g . on interfaces, coordination and reporting), taking advantage of their knowledge of that part of the business and any results from previous checks, working within the constraint of agreed strategies, policies and objectives .

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

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.

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.

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