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

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

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.

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.

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.

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

Among all the other bad news in the excellent Cy-Xplorer 2023 report from Orange Cyberdefense , this nugget of threat intelligence poked me in the eye: I've become increasingly concerned about the information risks relating to professional services in recent years. They seem obvious targets for malicious cyber attacks, given:

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

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.

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? 

This Sunday morning, fueled by two strong coffees, I'm cogitating on the issue of workers thoughtlessly disclosing all manner of sensitive personal or proprietary information in their queries to AI/ML/LLM systems and services run by third parties, such as ChatGPT. This is clearly topical given : (1) the deluge of publicity and chatter around ChatGPT right now, coupled with  (2) our natural human curiosity to explore new tech toys, plus  (3) limited appreciation of the associated information risks, and  (4) the rarity of controls such as policies and Data Leakage Protection technologies.  Furthermore, even if we do persuade our colleagues (and, let's be honest, ourselves!) to be more careful and circumspect about whatever we are typing or pasting into various online systems, the possibility remains that the general nature of our interests and queries is often sensitive.

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

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!

... "any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service"  [source:  NIST SP800-30r1 ] ... "a person, situation or event (whether deliberate or accidental, targeted or generic in nature) that is hazardous or dangerous, capable of causing an  information   security  incident" [source:  SecAware glossary ] ... "potential cause of an unwanted incident, which can result in harm to a system or organization" [source:  ISO/IEC 27000:2018 ] ... a competitor's unexpected shift of tactics ... an ominous promise to cause harm ... an accident waiting to happen ... the cause of a  really  bad day ... nature red in tooth and claw ... storm clouds on the horizon .....