CSOonline

Before I ever held a security title, I was a software engineer implementing vertically integrated automation systems for industrial manufacturing, warehouse-scale conveyor networks, robotic material handling, physical infrastructure controlled by software on increasingly connected networks. I learned early that tightly coupled systems produce tightly coupled failures. When a single software fault could halt a distribution center, you designed for graceful degradation. You assumed components would break and built the system to absorb it. That instinct followed me into cybersecurity and eventually into CISO roles across healthcare, financial services and global manufacturing. These industries operate under different regulatory regimes, face different threat profiles and define risk in different terms. But in every one of them, I encountered the same structural problem: Cyber risk wasn’t governed as a unified discipline. It was adopted piecemeal by systems that already existed, product markets, regulators, auditors, insurers and boards, each building frameworks on its own timeline, in its own language, toward its own definition of “secure.” The pattern rhymes with early actuarial science, where separate branches of insurance each modeled risk in isolation before discovering that correlated losses were the real threat. Within any individual silo, the logic was sound. But the seams between them were never reconciled. Where one system’s blind spot becomes another’s unpriced exposure, there was no shared language to name it. And as digital transformation has accelerated the interconnection between industries, supply chains and critical infrastructure, those seams have widened into the actual modern risk surface. We are spending more and falling further behind In every security program I’ve led, the budget could have ballooned year over year. My approach was always the opposite: Aggressively reduce tool proliferation and capability overlap, simplify the architecture and tie every dollar to a measurable business outcome. Timing and intent. But even with that discipline, the distance between what we spent and what we were exposed to widened, because technological change was rendering our tools and assumptions obsolete faster than we could replace them. The industry-level numbers confirm this isn’t anecdotal. Gartner projected global security spending would exceed $212 billion in 2025. The economic impact of cybercrime, by most estimates, has surpassed $10 trillion annually. Those curves are diverging, not converging. I first felt this acutely in healthcare. As CISO at a global benefits administrator processing sensitive health data for millions of members, I operated under HIPAA, state-level privacy mandates and contractual obligations from plan sponsors. We could satisfy every audit and still know the real risk lived in the handoffs, the interfaces between our claims platform and external provider networks, data flowing between systems governed by different standards. The auditors checked their boxes. The seams went unmeasured. Later, leading global security engineering at a major asset management firm, I saw the same gap in financial services. Different controls, different regulators, identical blind spot. The fragmentation was even more visible internationally. Regional regulatory bodies, data sovereignty requirements that varied by jurisdiction, vendor ecosystems that differed across geographies. Every regulator had its own definition of adequate security. None described the interconnected reality we were defending. Researchers at the Federal Reserve have documented how the financial system’s exposure to correlated cyber events is growing in ways that traditional risk models weren’t built to capture. I lived that gap daily. What connected these experiences was a pattern in the insurance market that troubled me more than any single threat. I watched premiums soften even as breach frequency and severity climbed. Insurers were underwriting individual, uncorrelated incidents while the actual risk was becoming systemic. Digital transformation had stitched these industries together: Healthcare platforms connected to financial clearinghouses connected to manufacturing supply chains all connected to hyperscalers, but the actuarial models still treated each policyholder as an island. When a single vendor failure can cascade across thousands of organizations simultaneously, that pricing model stops making sense. A black swan is lurking in our digital pond. The normal choices are the dangerous ones Consider the stack a typical large enterprise was running in 2024: One vendor for ERP and supply chain, another for perimeter enforcement, another for networking and another for endpoint protection. Standard choices, responsibly made. Within a twelve-month window, each of those categories experienced significant disruptions, from zero-day exploits to update failures that disrupted global operations. Any single event was survivable. The accumulation was something else entirely. I lived this as a Global CISO. My team planned for sequential crises with recovery time between them. What we got was overlapping disruptions across interdependent systems. One week, we were triaging an emergency patch on our perimeter while a second advisory was escalating on a different platform. The assumption that these events would arrive one at a time, that we’d have breathing room, turned out to be a planning fiction. When you are sustaining the operation itself, crises expose the seams in real time. A firewall vulnerability isn’t just a network issue when the ERP behind it processes every financial transaction. An endpoint agent failure isn’t just a security tool outage when it takes down the operating systems running your logistics. These platforms don’t fail in isolation because they don’t operate in isolation. Increasingly, neither do the industries that depend on them. A disruption to a cloud provider ripples through healthcare systems processing claims, financial institutions settling trades and manufacturers coordinating supply chains on the same platform. The July 2024 CrowdStrike incident made this impossible to dismiss. A routine content update, no attacker, no exploit, bricked millions of Windows systems worldwide. Airlines grounded flights. Hospitals diverted patients. Financial services went dark. The protective tool itself became the failure vector. That should have ended the debate about whether cybersecurity is a technical problem contained within organizational boundaries or a systemic risk that spans them. My background in industrial automation made this grimly familiar. In material handling, we knew the integration layer was the highest-risk surface. We designed systems assuming any component could fail and built degradation paths so the operation didn’t stop. Enterprise cybersecurity had somehow convinced itself that assembling best-of-breed tools was the same as building a resilient system. It isn’t. And as digital transformation pushes more critical infrastructure, from energy grids and water systems to transportation networks and medical devices, onto the same interconnected platforms, the consequences of that confusion multiply. Resilience is a design problem, not a compliance problem Across healthcare, financial services and manufacturing, I watched the same pattern. The compliance apparatus measured whether controls existed. It rarely measured whether the organization, or the broader infrastructure it depended on, could survive its failure. In healthcare, we demonstrate compliance while knowing our resilience to a coordinated supply-chain attack is largely untested. In financial services, we pass examinations while the insurers underwriting our risk price off the same compliance signals the examiners accept — and neither captures the systemic interdependencies between our platforms and our counterparties. In manufacturing, we secure the IT network while operational technology controlling physical processes is increasingly exposed through the same digital transformation the business is accelerating. We are weak at the seams. The question that followed me from role to role was simple: If a critical platform failed tomorrow, not breached, just failed, could the business keep operating? Could the critical services it provides keep functioning? The paper processes and theoretical exercises always existed, but never in a way that could forecast the cascading impacts. The internet itself offers a better model. It was engineered to survive the loss of any individual node. Routes break and traffic finds another path. Organizations need that same architectural quality, and so does the interconnected infrastructure that sits on top of them. The goal can’t be preventing every compromise. It has to ensure that no single failure cascades into systemic disruption that takes critical services offline across industries. This sets the priority. You can’t audit your way to that. You have to build it. The external pressures are converging on this conclusion. Insurance is becoming harder to buy at meaningful coverage levels and carriers are grappling with correlated risk they can’t yet price. Regulators are pushing accountability to the C-suite. Boards want evidence of survivability, not maturity scores. And the scope of what “cybersecurity” is expected to protect keeps expanding, from AI and enterprise data to operational technology to the critical infrastructure communities depend on. The industry built an economy around demonstrating that organizations are secure. It is optimized for audits, certifications and framework alignment. What it never solved for was proving that an organization, and the infrastructure around it, can absorb serious disruption and keep running. That is the seam that matters most. Digital transformation didn’t just increase each organization’s attack surface. It wove those surfaces together into an emergent network of interdependency that spans sectors and borders. The question every security and risk leader should be asking themselves is no longer whether their controls are sufficient. It’s whether they are, along with their programs or offerings, aligned to a sustainable future, or holding together an increasingly heavy past. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

dotshock | shutterstock.com Angenommen, Ihr Unternehmen wird von Cyberkriminellen angegriffen, kommt dabei aber mit einem blauen Auge davon, weil die Attacke zwar spät, aber noch rechtzeitig entdeckt und abgewehrt werden konnte – ohne größeren Business Impact. Jetzt einfach wie bisher weiterzumachen und die Sache zu vergessen, wäre allerdings kontraproduktiv. Schließlich haben die Angreifer einen Weg gefunden, Ihre Systeme zu kompromittieren und dabei Abwehrmaßnahmen zu umgehen. Deshalb ist an dieser Stelle ein Post-Incident Review essenziell: Ein strukturierter Prozess, in dessen Rahmen das Unternehmen analysiert, was gut gelaufen ist, was nicht, und wie die Performance in Zukunft verbessert werden kann. Das klingt erst einmal simpel – allerdings gilt es einige wichtige Dinge zu beachten, um eine robuste Post-Incident-Review-Strategie zu entwickeln. Welche das sind, haben wir im Gespräch mit verschiedenen Sicherheitsexperten herausgearbeitet. 1. Zeitnah handeln Nicht nur wenn es um die Analyse geht, ist Timing bei Security Incidents von entscheidender Bedeutung. Lassen Sie erst einmal Wochen oder Monate ins Land ziehen, bevor Sie ein Post-Incident Review anberaumen, steigt das Risiko, dass wichtige Elemente in Vergessenheit geraten – und Sicherheitsentscheider und ihre Teams sich kein vollständiges Bild von dem Angriff mehr machen können. David Taylor, Managing Director bei der IT-Beratung Protiviti, rät deshalb dazu, möglichst zeitnah tätig zu werden: “Ein Review kurz nach einem Incident gewährleistet, dass alle Details noch frisch in den Köpfen sind und vermittelt zudem ein Gefühl von Dringlichkeit”. Zudem könnten die Review-Beteiligten auf diese Weise auch eine akkurate Timeline der Ereignisse erarbeiten, so der Chefberater. Wie diese Timeline ausgestaltet werden sollte, weiß Heather Clauson Haughian, Mitbegründerin und geschäftsführende Partnerin der auf Datenschutz spezialisierten Anwaltskanzlei CM Law: “Zunächst gilt es, festzuhalten, was genau passiert ist – von den ersten Anzeichen eines Problems bis hin zu seiner Bewältigung.” Das unterstütze alle Beteiligten dabei, nachzuvollziehen, an welchen Stellen es zu Verzögerungen oder Fehlern gekommen ist – und an welchen nicht. “Es geht im Grunde darum, den Vorfall in eine verständliche ‚Story‘ zu gießen und daraus entsprechende Lehren zu ziehen”, erklärt die Rechtsexpertin. 2. Ursachenanalyse fahren Pflichtbestandteil eines Post-Incident Reviews ist zudem eine Ursachenanalyse (auch Root Cause Analysis) – zumindest wenn Ihnen daran gelegen ist, künftige Incidents zu verhindern. Dieser Überzeugung ist auch Michael Brown, Field CISO beim IT-Dienstleister Presidio: “Die Grundursache eines Vorfalls zu identifizieren, ist essenziell. Die Teams müssen herausfinden, ob es sich dabei um eine technische Schwachstelle, menschliches Versagen oder Prozess- beziehungsweise Technologielücken handelt. Nur so lässt sich sicherstellen, dass nicht nur Symptome behandelt werden.” 3. Lücken identifizieren Ein Post-Incident Review sollte darüber hinaus auch beinhalten, die Performance des Sicherheitsteams mit Blick auf etablierte Prozesse (etwa den Incident-Response-Plan) zu evaluieren. Das ist laut Protiviti-Manager Taylor unerlässlich, um die Team-Fähigkeiten sukzessive zu verbessern: “Es kann wertvolle Informationen für innovative Optimierungen liefern, Schulungslücken identifizieren und Ineffizienzen in der Reaktionsphase beseitigen.” Presidio geht diesbezüglich mit gutem Beispiel voran, wie Field CISO Brown verrät: “Im Rahmen unserer Post-Incident Reviews bewerten wir die Leistung unseres Incident-Response-Teams in unterschiedlichen Bereichen – etwa Detection, Reaktionszeit, Kommunikation, Koordination oder Prozesstreue.” 4. Business Impact analysieren Die Auswirkungen eines Sicherheitsvorfalls vollumfänglich zu durchdringen, ist eine vielschichtige Angelegenheit, die sowohl quantitative als auch qualitative Analysen umfassen sollte. Ersteres sollte laut Sicherheitsentscheider Brown beispielsweise Aspekte wie finanzielle Einbußen, verlorene Marktanteile oder Kundenaufträge beinhalten. Zweiteres sich hingegen mit Fragen befassen wie: Wurde die Business Continuity nachhaltig beeinträchtigt? Wurden die zuständigen Behörden rechtzeitig informiert? Sind Reputationsschäden entstanden? 5. Kontext erfassen Ein weiterer Schlüsselfaktor für Post-Incident-Analysen ist außerdem der Kontext des Sicherheitsvorfalls. Ihn zu erfassen, ist entscheidend, wenn es darum geht, eine Timeline für den Incident aufzusetzen, aus der alle Beteiligten lernen können. “Allzu oft wird bei Nachbesprechungen der Kontext, in dem Entscheidungen getroffen wurden, übersprungen”, kritisiert Security-Forscher Eireann Leverett und ergänzt: “Dokumentieren Sie den Vorfall so, wie er sich entwickelt hat – nicht nur das Ergebnis. Incidents entwickeln sich im Zeitverlauf – und das Team, das diesen bearbeitet, kann selten vorab auf sämtliche Fakten zugreifen.” Jede neue Entdeckung – etwa mit Blick auf das Einfallstor für den Angriff, seinen Scope oder die von den Angreifern verwendeten Tools, könnten die Untersuchungsziele des Teams verändern, so Leverett: “Was als Containment-Vorhaben beginnt, kann schnell zum umfänglichen Recovery-Projekt ausarten. Nur wenn Sie tracken, wann und warum Veränderungen stattgefunden haben, ist später auch nachvollziehbar, welche Maßnahmen ergriffen wurden.” 6. Abteilungsübergreifend kollaborieren Ein Post-Incident Review zu leiten, ist Sache des CISO – oder anderer Security- oder IT-Führungskräfte. Allerdings ist es empfehlenswert, auch Personen aus anderen Abteilungen einzubinden, die potenziell Insights beitragen können. So empfiehlt etwa Sicherheitsexperte Leverett, das Post-Incident-Team um Kollegen aus den Bereichen Governance, Recht und Risikomanagement zu erweitern: “Diese können die Grundursache des Incidents möglicherweise mit allgemeinen, breiter angelegten Richtlinienlücken in Verbindung bringen.” Sinnvoll ist nach Meinung von Leverett außerdem, die Finanz- und Personalabteilung einzubinden, sowie – je nach Art und Schwere des Vorfalls – auch Vorstandsmitglieder. Letzteres signalisiere eine strategische Priorisierung und unterstütze dabei, technische Erkenntnisse mit Risiko-Diskussionen auf Governance-Ebene zu verknüpfen, ist der Experte überzeugt. “Wichtig ist dabei, dass alle Beteiligten gleichberechtigt zu Wort kommen – unabhängig von ihrer Position oder Rolle”, ergänzt Protiviti-Mann Taylor. Das trage nicht nur dazu bei, Security-Vorfälle besser zu durchdringen, sondern etabliere auch ein kooperatives Umfeld. 7. Schuldzuweisungen vermeiden Im Rahmen eines Post-Incident Reviews “Fingerpointing” zu betreiben, ist mit hoher Wahrscheinlichkeit nicht produktiv. Deshalb empfiehlt auch IT-Anwältin Haughian, den Fokus darauf zu legen, zu lernen und zu optimieren: “Schuldzuweisungen bringen Sie nicht weiter. Es gilt, den tatsächlichen Ablauf der Ereignisse aufzudecken, Entscheidungsprozesse zu verstehen und alle Faktoren zu identifizieren, die zu Fehlern beigetragen haben. Dieser Ansatz kann dabei helfen, künftige strategische Entscheidungen in Zusammenhang mit Tools, Schulungen und Richtlinien zu treffen.” Auch Leverett hält nichts von einer Kultur der Schuldzuweisung: “Es geht nicht darum, ob ein bestimmtes Individuum die richtige Entscheidung getroffen hat oder nicht. Vielmehr gilt es Fragen zu klären wie: ‚War das Team unter den gegebenen Umständen in der Lage, gute Entscheidungen zu treffen?‘ Oder: ‚Hätten eine bessere Dokumentation, andere Tools oder mehr Budget für schnellere und bessere Ergebnisse gesorgt?‘” 8. Aktiv werden Sämtliche Erkenntnisse, die im Rahmen eines Post-Incident Reviews gewonnen werden, sind relativ nutzlos, wenn im Nachgang nichts passiert. Soll heißen: Den Erkenntnissen müssen konkrete Maßnahmen folgen. Um das bestmöglich umzusetzen, empfiehlt Rechtsexpertin Haughian, schriftlich genau festzuhalten, an welchen Stellen optimiert werden muss, wann das geschehen soll und wer dafür verantwortlich zeichnet: “Diese Verbesserungen können etwa Softwareaktualisierungen, Richtlinienänderungen oder neue Schulungsinitiativen sein. Unabhängig davon macht diese Nachbereitung ein Post-Incident Review erst wirklich nützlich. Bleibt sie aus, entfallen damit auch umsetzbare Empfehlungen – und das Ganze ist nicht mehr als eine akademische Übung”, hält die Datenschutzexpertin fest. (fm) Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

dotshock | shutterstock.com Angenommen, Ihr Unternehmen wird von Cyberkriminellen angegriffen, kommt dabei aber mit einem blauen Auge davon, weil die Attacke zwar spät, aber noch rechtzeitig entdeckt und abgewehrt werden konnte – ohne größeren Business Impact. Jetzt einfach wie bisher weiterzumachen und die Sache zu vergessen, wäre allerdings kontraproduktiv. Schließlich haben die Angreifer einen Weg gefunden, Ihre Systeme zu kompromittieren und dabei Abwehrmaßnahmen zu umgehen. Deshalb ist an dieser Stelle ein Post-Incident Review essenziell: Ein strukturierter Prozess, in dessen Rahmen das Unternehmen analysiert, was gut gelaufen ist, was nicht, und wie die Performance in Zukunft verbessert werden kann. Das klingt erst einmal simpel – allerdings gilt es einige wichtige Dinge zu beachten, um eine robuste Post-Incident-Review-Strategie zu entwickeln. Welche das sind, haben wir im Gespräch mit verschiedenen Sicherheitsexperten herausgearbeitet. 1. Zeitnah handeln Nicht nur wenn es um die Analyse geht, ist Timing bei Security Incidents von entscheidender Bedeutung. Lassen Sie erst einmal Wochen oder Monate ins Land ziehen, bevor Sie ein Post-Incident Review anberaumen, steigt das Risiko, dass wichtige Elemente in Vergessenheit geraten – und Sicherheitsentscheider und ihre Teams sich kein vollständiges Bild von dem Angriff mehr machen können. David Taylor, Managing Director bei der IT-Beratung Protiviti, rät deshalb dazu, möglichst zeitnah tätig zu werden: “Ein Review kurz nach einem Incident gewährleistet, dass alle Details noch frisch in den Köpfen sind und vermittelt zudem ein Gefühl von Dringlichkeit”. Zudem könnten die Review-Beteiligten auf diese Weise auch eine akkurate Timeline der Ereignisse erarbeiten, so der Chefberater. Wie diese Timeline ausgestaltet werden sollte, weiß Heather Clauson Haughian, Mitbegründerin und geschäftsführende Partnerin der auf Datenschutz spezialisierten Anwaltskanzlei CM Law: “Zunächst gilt es, festzuhalten, was genau passiert ist – von den ersten Anzeichen eines Problems bis hin zu seiner Bewältigung.” Das unterstütze alle Beteiligten dabei, nachzuvollziehen, an welchen Stellen es zu Verzögerungen oder Fehlern gekommen ist – und an welchen nicht. “Es geht im Grunde darum, den Vorfall in eine verständliche ‚Story‘ zu gießen und daraus entsprechende Lehren zu ziehen”, erklärt die Rechtsexpertin. 2. Ursachenanalyse fahren Pflichtbestandteil eines Post-Incident Reviews ist zudem eine Ursachenanalyse (auch Root Cause Analysis) – zumindest wenn Ihnen daran gelegen ist, künftige Incidents zu verhindern. Dieser Überzeugung ist auch Michael Brown, Field CISO beim IT-Dienstleister Presidio: “Die Grundursache eines Vorfalls zu identifizieren, ist essenziell. Die Teams müssen herausfinden, ob es sich dabei um eine technische Schwachstelle, menschliches Versagen oder Prozess- beziehungsweise Technologielücken handelt. Nur so lässt sich sicherstellen, dass nicht nur Symptome behandelt werden.” 3. Lücken identifizieren Ein Post-Incident Review sollte darüber hinaus auch beinhalten, die Performance des Sicherheitsteams mit Blick auf etablierte Prozesse (etwa den Incident-Response-Plan) zu evaluieren. Das ist laut Protiviti-Manager Taylor unerlässlich, um die Team-Fähigkeiten sukzessive zu verbessern: “Es kann wertvolle Informationen für innovative Optimierungen liefern, Schulungslücken identifizieren und Ineffizienzen in der Reaktionsphase beseitigen.” Presidio geht diesbezüglich mit gutem Beispiel voran, wie Field CISO Brown verrät: “Im Rahmen unserer Post-Incident Reviews bewerten wir die Leistung unseres Incident-Response-Teams in unterschiedlichen Bereichen – etwa Detection, Reaktionszeit, Kommunikation, Koordination oder Prozesstreue.” 4. Business Impact analysieren Die Auswirkungen eines Sicherheitsvorfalls vollumfänglich zu durchdringen, ist eine vielschichtige Angelegenheit, die sowohl quantitative als auch qualitative Analysen umfassen sollte. Ersteres sollte laut Sicherheitsentscheider Brown beispielsweise Aspekte wie finanzielle Einbußen, verlorene Marktanteile oder Kundenaufträge beinhalten. Zweiteres sich hingegen mit Fragen befassen wie: Wurde die Business Continuity nachhaltig beeinträchtigt? Wurden die zuständigen Behörden rechtzeitig informiert? Sind Reputationsschäden entstanden? 5. Kontext erfassen Ein weiterer Schlüsselfaktor für Post-Incident-Analysen ist außerdem der Kontext des Sicherheitsvorfalls. Ihn zu erfassen, ist entscheidend, wenn es darum geht, eine Timeline für den Incident aufzusetzen, aus der alle Beteiligten lernen können. “Allzu oft wird bei Nachbesprechungen der Kontext, in dem Entscheidungen getroffen wurden, übersprungen”, kritisiert Security-Forscher Eireann Leverett und ergänzt: “Dokumentieren Sie den Vorfall so, wie er sich entwickelt hat – nicht nur das Ergebnis. Incidents entwickeln sich im Zeitverlauf – und das Team, das diesen bearbeitet, kann selten vorab auf sämtliche Fakten zugreifen.” Jede neue Entdeckung – etwa mit Blick auf das Einfallstor für den Angriff, seinen Scope oder die von den Angreifern verwendeten Tools, könnten die Untersuchungsziele des Teams verändern, so Leverett: “Was als Containment-Vorhaben beginnt, kann schnell zum umfänglichen Recovery-Projekt ausarten. Nur wenn Sie tracken, wann und warum Veränderungen stattgefunden haben, ist später auch nachvollziehbar, welche Maßnahmen ergriffen wurden.” 6. Abteilungsübergreifend kollaborieren Ein Post-Incident Review zu leiten, ist Sache des CISO – oder anderer Security- oder IT-Führungskräfte. Allerdings ist es empfehlenswert, auch Personen aus anderen Abteilungen einzubinden, die potenziell Insights beitragen können. So empfiehlt etwa Sicherheitsexperte Leverett, das Post-Incident-Team um Kollegen aus den Bereichen Governance, Recht und Risikomanagement zu erweitern: “Diese können die Grundursache des Incidents möglicherweise mit allgemeinen, breiter angelegten Richtlinienlücken in Verbindung bringen.” Sinnvoll ist nach Meinung von Leverett außerdem, die Finanz- und Personalabteilung einzubinden, sowie – je nach Art und Schwere des Vorfalls – auch Vorstandsmitglieder. Letzteres signalisiere eine strategische Priorisierung und unterstütze dabei, technische Erkenntnisse mit Risiko-Diskussionen auf Governance-Ebene zu verknüpfen, ist der Experte überzeugt. “Wichtig ist dabei, dass alle Beteiligten gleichberechtigt zu Wort kommen – unabhängig von ihrer Position oder Rolle”, ergänzt Protiviti-Mann Taylor. Das trage nicht nur dazu bei, Security-Vorfälle besser zu durchdringen, sondern etabliere auch ein kooperatives Umfeld. 7. Schuldzuweisungen vermeiden Im Rahmen eines Post-Incident Reviews “Fingerpointing” zu betreiben, ist mit hoher Wahrscheinlichkeit nicht produktiv. Deshalb empfiehlt auch IT-Anwältin Haughian, den Fokus darauf zu legen, zu lernen und zu optimieren: “Schuldzuweisungen bringen Sie nicht weiter. Es gilt, den tatsächlichen Ablauf der Ereignisse aufzudecken, Entscheidungsprozesse zu verstehen und alle Faktoren zu identifizieren, die zu Fehlern beigetragen haben. Dieser Ansatz kann dabei helfen, künftige strategische Entscheidungen in Zusammenhang mit Tools, Schulungen und Richtlinien zu treffen.” Auch Leverett hält nichts von einer Kultur der Schuldzuweisung: “Es geht nicht darum, ob ein bestimmtes Individuum die richtige Entscheidung getroffen hat oder nicht. Vielmehr gilt es Fragen zu klären wie: ‚War das Team unter den gegebenen Umständen in der Lage, gute Entscheidungen zu treffen?‘ Oder: ‚Hätten eine bessere Dokumentation, andere Tools oder mehr Budget für schnellere und bessere Ergebnisse gesorgt?‘” 8. Aktiv werden Sämtliche Erkenntnisse, die im Rahmen eines Post-Incident Reviews gewonnen werden, sind relativ nutzlos, wenn im Nachgang nichts passiert. Soll heißen: Den Erkenntnissen müssen konkrete Maßnahmen folgen. Um das bestmöglich umzusetzen, empfiehlt Rechtsexpertin Haughian, schriftlich genau festzuhalten, an welchen Stellen optimiert werden muss, wann das geschehen soll und wer dafür verantwortlich zeichnet: “Diese Verbesserungen können etwa Softwareaktualisierungen, Richtlinienänderungen oder neue Schulungsinitiativen sein. Unabhängig davon macht diese Nachbereitung ein Post-Incident Review erst wirklich nützlich. Bleibt sie aus, entfallen damit auch umsetzbare Empfehlungen – und das Ganze ist nicht mehr als eine akademische Übung”, hält die Datenschutzexpertin fest. (fm) Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

Through LinkedIn’s more than one billion business users, the Microsoft unit has access to a vast array of personally-identifiable information, including data that could identify religious and political positions. What is less clear is what LinkedIn does with all of that data. A small European company that sells a browser extension to leverage different aspects of LinkedIn data is running a campaign, which it calls BrowserGate, that accuses LinkedIn of “illegally searching your computer” and “running one of the largest corporate espionage operations in modern history.” “Every time any of LinkedIn’s one billion users visits linkedin.com, hidden code searches their computer for installed software, collects the results, and transmits them to LinkedIn’s servers and to third-party companies including an American-Israeli cybersecurity firm,” the company claimed. “The user is never asked. Never told. LinkedIn’s privacy policy does not mention it,” the BrowserGate site said. “Because LinkedIn knows each user’s real name, employer, and job title, it is not searching for anonymous visitors. It is searching identified people at identified companies.” LinkedIn denies some of those accusations, and avoids addressing the remainder. “This [accusation] is a house of cards built entirely upon a fabrication,” said a LinkedIn statement emailed to CSOonline. “We do disclose that we scan for browser extensions in our privacy policy, in order to detect abuse and provide defense for site stability.” When asked whether it uses that data solely to do those things, LinkedIn did not reply. Possible misuse The key person behind the allegations calls himself Steven Morrell (not his legal name, which he asked CsoOnline to not publish). The company he represents also has different names, including Teamfluence and Fairlinked. Morrell said that LinkedIn is gathering data that includes sensitive details, including information that he argued could be used to determine religious and political leanings. Gathering such data, Morrell said, could violate European privacy rules. But Morrell is not saying that LinkedIn is in fact using the data to determine those preferences, but merely that they could. Much the same could be said for almost all large companies. Morell isn’t exactly unbiased, however. He and LinkedIn are also involved in a legal dispute in Germany, in which Morrell said that LinkedIn violated EU rules and that it improperly kicked him, and others, off the service. LinkedIn countered that Morell and the other plaintiffs had violated its terms of service with their plugins. Last month, a judge in Munich sided with LinkedIn, dismissing the motion for a preliminary injunction. Might cause compliance issues Safayat Moahamad, research director at Info-Tech Research Group, said that compliance approaches throughout the European Union and the UK could indeed have some issues with this deep a level of data collection. “European courts are likely to support platforms that restrict automated data harvesting, when they can plausibly link organization-level policy enforcement actions to consumer protection and regulatory compliance,” Moahamad said. Advice for CIOs Cybersecurity consultant Brian Levine, executive director of FormerGov, said enterprise CIOs should use these allegations, even if they prove to be untrue, to help them tweak their data strategy and privacy policies for 2026. “Assuming the BrowserGate allegations are true, LinkedIn users should consider reducing the amount of identifiable, trackable, or sensitive data their browser exposes, and organizations should treat LinkedIn as a potentially hostile web environment until facts are verified,” Levine said. “Even if BrowserGate is exaggerated, browser fingerprinting is a real, widespread practice across the web. Treat LinkedIn like any other third-party data collector. LinkedIn has historically been treated as safe, [but] that assumption may need to be revisited.” Levine said IT executives should “assume that LinkedIn can map your tech stack” and that, if the claims are accurate, LinkedIn could infer “which SaaS tools your employees use, which competitors you rely on, which job search tools your staff is using and which political/religious extensions appear inside your workforce.” He added that IT should consider blocking LinkedIn on sensitive networks, or require it to only be accessed through VDI, as well as employing browser isolation techniques. Some companies might even want to use a separate isolated browser solely for LinkedIn, or, he said, “use a sandboxed browser session, such as Browserling or other cloud-isolated browsers.” View the full article

Arelion operates the world’s best-connected IP fiber backbone, providing high-capacity transit services to a variety of the globe’s leading ISPs as well as many large enterprises. They provide an award-winning customer experience to clients in 129 countries worldwide, and their global Internet services connect more than 700 cloud, security, and content providers with low-latency transit. Furthermore, Arelion’s private Cloud Connect service connects directly to Amazon Web Services, Microsoft Azure, Google Cloud, IBM Cloud, and Oracle Cloud across North America, Europe, and Asia. The challenge To get a clearer picture of their current DDoS protection infrastructure, Arelion reached out to NETSCOUT®, which had been providing DDoS protection with NETSCOUT Arbor Sightline and the Threat Mitigation System (TMS) for over 16 years. Arelion wanted a better understanding of the efficiency of the system and how it was bringing value to their internal security strategy as well as the protection services for their customers. Once NETSCOUT provided the required information regarding the infrastructure and configuration of their current product portfolio, the project manager initiated a research activity to gain clarity on what new developments and solutions in the DDoS space could be implemented to enhance the DDoS protection of internal systems as well as the offering they provide to their customers. The goal for this action was to increase the efficiency of the DDoS protection both internally and for their customer base. “As a Tier-1 Internet carrier supporting the majority of global Internet traffic, this continued collaboration reflects our ongoing investment in best-of-breed network security solutions to protect the technology ecosystem. Our partnership combines Arelion’s global network performance and NETSCOUT’s leading Arbor DDoS attack protection solutions to provide world-class experiences for our customers.” – Scott Nichols, Chief Commercial Officer at Arelion The solution Once Arelion completed its due diligence in the effort to gain more clarity around the current DDoS protection landscape, the NETSCOUT team initiated conversations regarding improvements in the NETSCOUT DDoS defense capabilities, including threat intelligence, mitigation orchestration, automation and reporting. The team also helped Arelion see the value that these capabilities could provide to their internal security teams, but more importantly, to their protection services customers. The NETSCOUT team introduced Arelion to three new offerings that provided the emphasized capabilities that they had identified during the discovery process to improve the DDoS protection for them and their customers. The first product introduced was an add-on to Sightline called Sentinel. Sightline with Sentinel understands the capabilities of the routers and other security devices in the security stack within Arelion’s multi-vendor infrastructure and uses the capabilities of those devices (i.e., flowspec and other technologies) in combination with TMS to orchestrate defenses to automatically mitigate any DDoS attack, regardless of size and complexity, stopping them nearer to their source. This feature spreads the mitigation load of large volumetric attacks over all potential system mitigation capabilities, lightening the load across the entire system. The second offering NETSCOUT suggested was the ATLAS Intelligence Feed (AIF) for TMS. AIF taps into the best threat intelligence offered in the DDoS space, which provides deterministically accurate and actionable Threat Intelligence to enhance DDoS detection at every level of Arelion’s network. As cyber threats continue to increase in frequency and sophistication, mature security teams will not only rely on the latest cybersecurity technology but also on the highly curated threat intelligence that arms these products. NETSCOUT’s unmatched monitoring of over 50% of all internet traffic, our AI-powered analysis processes, and the expertise of NETSCOUT’s ASERT Team have enabled NETSCOUT to automatically arm all NETSCOUT Arbor DDoS attack protection products with the latest DDoS attack tactics and methodologies, known sources of DDoS attacks, and Indicators of Compromise so organizations, such as Arelion, can protect themselves and their customers from DDoS attacks and other cyber threats and automatically adapt protections as those attacks change vectors. The third offering NETSCOUT suggested, Adaptive DDoS protection (ADP), adds significant automation and targets newly detected attacks that require changes to configurations to mitigate. Once an attack is detected and classified, AI-driven intelligence determines the optimal mitigation strategy—whether via RTBH, BGP, Flowspec, ACLs, or TMS. The attack is continually monitored, and mitigations are adapted in real-time as the attack evolves, ensuring that mitigation strategies remain effective even as attackers shift tactics. This combination of intelligence, detection, and automation provides significantly improved protection against carpet bombing attacks. The faster aggregate detection, as well as automation of mitigations on selected subnets and hosts within the targeted network, keeps external services and internal protections active while not over-mitigating. This intelligent, automated, and adaptive approach ensures that Arelion’s team stays ahead of increasingly sophisticated DDoS threats with minimal manual effort and maximum efficiency. This expanded partnership enables Arelion to support the network security requirements of its customers amid rising attacks on critical infrastructure. By enhancing its capabilities with NETSCOUT, Arelion improves network security across its #1-ranked global Internet backbone, empowering enterprise customers with resilient, high-performance connectivity services. “Financial services, government, utilities, and other vital sectors are experiencing increased risk from more sophisticated and frequent DDoS attacks, reinforcing the need for comprehensive DDoS protection,” stated Darren Anstee, chief security technologist, NETSCOUT. “Our latest DDoS Threat Intelligence Report echoes Arelion’s experience of increasing numbers of application-layer and volumetric attacks, as well as greater attack sophistication. This partnership will help Arelion enhance the protection it can provide to enterprises facing more frequent cyberattacks on their businesses.” The results Arelion has experienced an increase in visibility into their network, meaning they can protect their internal systems and their customers’ critical business applications and services against all types of attacks. This also gives them confidence in adopting all types of customers, no matter if it is the largest service providers or a multi-homed enterprise. Overarching benefit Arelion believes that to provide proven and trusted DDoS protection to their customers, they needed to do two things. First was to partner with a world-class DDoS defense organization, and second was to project confidence in the chosen solution and strategy by employing it internally to protect their systems. The partnership with NETSCOUT and its proven DDoS protection products and threat intelligence provides Arelion and its customers with the confidence that their systems are protected by a best-of-breed DDoS-specific solution. Arelion customers value their services more because of the trust they have in the collaboration between Arelion and NETSCOUT. Learn more For more information about NETSCOUT’s Arbor DDoS Protection Solutions visit: https://www.netscout.com/arbor View the full article

NETSCOUT’s Arbor Threat Mitigation System (TMS) was honored with five badges, while Arbor Sightline earned one badge on G2 for the winter 2026 quarter. These badges span multiple categories. Arbor TMS was awarded badges in the following categories for winter 2026: Leader – Enterprise DDoS Protection Momentum Leader – DDoS Protection Regional Leader (Asia) – DDoS Protection Leader – DDoS Protection Leader – Web Security Arbor Sightline was also recognized as a leader in enterprise network management. NETSCOUT What NETSCOUT Customers Are Saying About TMS “The Arbor Threat Mitigation System allows us to defend not only our internal systems, but our customers.— Darren G.” “NETSCOUT delivers unmatched network visibility and carrier-grade DDoS protection, ideal for large enterprises and service providers that need real-time insights, forensic analysis, and hybrid/cloud coverage. — Bruno O.” “The constant evolution of the Arbor Threat Mitigation System in conjunction with the cybersecurity market would also make me consider it again in the future. — Mauro L.” Evaluation criteria These badges were earned from a criteria that relies heavily on positive user reviews from real, verified NETSCOUT customers. The experience users have had with TMS and Sightline, paired with the market presence of NETSCOUT, have led to further recognition as leading solutions in the DDoS protection and network management marketplace. Validating NETSCOUT’s experience in the industry The decades of experience NETSCOUT Arbor DDoS solutions have in the industry is validated by our customer feedback. The industry-leading DDoS protection solutions, powered by artificial intelligence/machine learning (AI/ML), take the guesswork out of mitigating DDoS attacks. With automated defenses and unparalleled threat intelligence from its ATLAS Intelligence Feed (AIF), NETSCOUT protects the largest, most complex networks from the latest advanced DDoS threats. Learn more: Read customer reviews for Arbor Threat Mitigation System on G2. Read customer reviews for Arbor Sightline on G2. See how Arbor Threat Mitigation System and Arbor Sightline can protect you from DDoS attacks. View the full article

The second half of 2025 marked a pivotal shift in the world of distributed denial-of-service (DDoS) attacks. Organizations across the globe faced a perfect storm: Artificial intelligence (AI) matured as an offensive weapon, botnet infrastructure reached new heights with multiterabit attack capacity, and DDoS-for-hire services became more accessible—even to nontechnical adversaries. NETSCOUT’s ATLAS global threat intelligence platform, which monitored more than 8 million DDoS attacks in 203 countries and territories during this period, reveals a threat landscape where the line between intent and capability has all but disappeared. Attacks reaching up to 30 terabits per second are now possible, and conversational AI interfaces are guiding even unskilled attackers through complex operations. Executive summary Between July and December 2025, the number of DDoS attacks remained steady compared to the first half of the year—but the nature of these attacks changed dramatically: Massive attack capacity: Demonstration attacks peaked at 30Tbps and 4 gigapackets per second, primarily launched by Internet of Things (IoT) botnets such as Aisuru and TurboMirai variants. AI integration: The use of AI, including dark-web large language models (LLMs), moved from emerging trend to operational reality, making sophisticated attacks accessible to a wider range of threat actors. Persistent threat actors: Despite international law enforcement efforts, hacktivist groups and commodity botnets maintained high pressure. For example, NoName057(16) claimed more than 200 attacks in July alone, showing resilience even after infrastructure seizures. Critical infrastructure under pressure: DNS root servers and Network Time Protocol (NTP) services faced relentless attacks, with more than 45,000 NTP-related alerts. Well-architected systems proved resilient, but the persistence of threats was clear. Targeted sectors and regions: Government, finance, telecom, transportation, and hospitality were the most targeted sectors. Regionally, EMEA led with 3.3 million attacks, followed by APAC, North America, and Latin America. The latter half of 2025 was not just an evolutionary step, but a fundamental shift in who can launch sophisticated DDoS attacks, how quickly they adapt, and the scale of impact they can achieve. Key findings 1. Global scale and attack volume More than 8 million DDoS attacks were recorded across 203 countries and territories, highlighting the persistent and growing operational risk for digitally connected organizations worldwide. The attack count remained stable compared to the first half of the year, but the nature and sophistication of attacks changed dramatically. 2. Rise of IoT botnets and outbound risk Massive direct-path attacks in 2025 demonstrated that compromised customer-premises equipment (CPE) can generate outbound floods exceeding 1Tbps, creating significant liability and service-availability risks for broadband providers. The TurboMirai class of IoT botnets, including Aisuru and Eleven11 (RapperBot), emerged as a major force, capable of launching attacks up to 30Tbps and 4Gpps. Eleven11 alone was linked to more than 3,600 DDoS events between 2021 and mid-2025. 3. AI-enhanced DDoS-for-hire services DDoS-for-hire platforms are now integrating dark-web LLMs and conversational AI, lowering the technical barrier for launching complex, multivector attacks. Even unskilled threat actors can now orchestrate sophisticated campaigns using natural-language prompts, increasing risk for all industries. 4. Threat actor collaboration and scale July 2025 saw a surge of more than 20,000 botnet-driven attacks, with coordinated threat activity overwhelming defenses and disrupting essential services in government, finance, and transportation. Groups such as Keymous+ demonstrated how partnerships between threat actors can amplify attack power, with collaborative events reaching up to 44Gbps. 5. Critical infrastructure under sustained pressure High-value services such as DNS root servers and NTP faced continuous attack pressure. At least 38 significant DNS root events were recorded, including a 21Gbps flood against the A root server. More than 45,000 NTP-related attack alerts were generated, underscoring the need for resilient, globally distributed architectures and robust mitigation strategies. 6. Geographic and sectoral targeting The most targeted sectors were government agencies, financial services, telecommunications, transportation, and hospitality. Regionally, EMEA led with 3.3 million attacks, followed by APAC (1.9 million), North America (1.27 million), and Latin America (1.01 million). 7. Multivector and carpet-bombing attacks More than half of all attacks were multivector, with 42 percent using two to five vectors. Carpet-bombing attacks increased, averaging between 750 and 830 per day in the latter half of 2025. Attackers frequently blended methods such as DNS amplification, SSDP, SNMP, mDNS, memcached, CLDAP, and mixed TCP floods to maximize disruption. 8. Defensive successes and ongoing challenges Well-architected systems, especially those using anycast-based defenses, demonstrated resilience and maintained high availability despite continuous attack pressure. However, the persistence of vulnerable devices and the rapid adaptation of threat actors mean that organizations must remain vigilant and proactive in their defense strategies. Conclusion The DDoS threat landscape in late 2025 was defined by sustained global attack volume, increasingly capable IoT botnets, sophisticated threat-actor campaigns, and a decisive move toward AI-enhanced DDoS-for-hire operations. Although the largest attacks remain rare, they continue to shape defensive strategies. The average attack is now short, intense, and multisector, targeting a wide range of industries and geographies. Organizations must recognize that the democratization of attack tools, especially with AI integration, has lowered the barrier to entry for cybercriminals. Defending against these threats requires not just robust infrastructure, but also adaptive, intelligence-driven strategies that can keep pace with the evolving tactics of adversaries. To learn more, read NETSCOUT’s 2H 2025 DDoS Threat Intelligence Report View the full article

New York, NY: Minimus, a provider of hardened container images and secure container images designed to reduce CVE risk, today announced the appointment of Yael Nardi as Chief Business Officer (CBO). In this newly created role, Nardi will lead the company’s next phase of operations, overseeing top-of-funnel growth strategy, strategic operations, and future corporate development. As the market landscape evolves and AI affects customer acquisition, Minimus is implementing an operational model to scale marketing and strategic alliances, which will be managed by Nardi. “We are entering a phase of aggressive expansion that requires rigorous execution and a completely new playbook. Traditional marketing strategies are no longer enough in today’s fast-moving environment. We need an operational powerhouse at the helm. Yael is a world-class operator accustomed to zero-error environments and high-stakes execution. We are choosing intelligence, speed, and strategic alignment, and there is no one I trust more to run this machine.” – Ben Bernstein, CEO at Minimus Nardi brings a multidisciplinary background to Minimus, with over 15 years of experience advising high-growth startups, global investors, and technology corporations. Most recently, she served as Director at Meitar NY Inc. and Partner at Meitar Law Offices. Yael was leading the significant M&A transaction of Twistlock’s acquisition by Palo Alto Networks and others, (PANW)—a foundational deal in the container image hardening and runtime security space—as well as transactions involving Wiz, JFrog, Salesforce, and others. “I have worked with the Minimus team through some of their most critical milestones, and I know firsthand the massive potential of their technology. The demand for near-zero CVE container images and minimal container images with built-in security is only accelerating. Scaling a company in today’s environment requires the same 24/7 rigor, vendor accountability, and strategic precision as closing a major M&A deal. I am thrilled to step into this operational role and build the growth engine that will drive Minimus’s next chapter.” – Yael Nardi, Chief Business Officer, Minimus Nardi holds a Bachelor of Laws (LLB) from Tel Aviv University and will be based in Minimus’s New York City office. She will work with the executive leadership team to execute the company’s growth targets. About Minimus Minimus provides hardened container images and hardened Docker images engineered to achieve near-zero CVE exposure. Built continuously from source with the latest patches and security updates, Minimus images undergo rigorous container image hardening and attack surface reduction, delivering secure container imageswith seamless supply chain security and built-in compliance for FedRAMP, FIPS 140-3, CIS, and STIG standards. Through automatically generated SBOMs and real-time threat intelligence, Minimus empowers teams to prioritize remediation and avoid over 97% of container vulnerabilities – making it a compelling Chainguard alternative for teams seeking production-hardened, distroless container images at scale. For more information, visit minimus.io. Minimus Public Relations [email protected] View the full article

Threat actors have found a way to inject arbitrary JavaScript into the Flowise low-code platform for building custom LLM and agentic systems. The code injection was possible due to a design oversight, rated at max-severity, in the platform’s custom MCP node, which acts as a plug-in connector for an application’s AI agent to talk to external tools via MCP servers. According to a recent VulnCheck alert, hackers have already started exploiting the flaw to insert malicious JavaScript code, with analysis showing close to 15000 Flowise instances exposed on the public internet. The flaw was patched in the AI development platform’s version 3.0.6, the latest rollout being v 3.1.1, released last month. Improper validation of MCP configurations Flowise is a drag-and-drop service to build a customized large language model (LLM) flow. It allows users to drag the Custom MCP node into their workflows and paste necessary configurations (JSON) to point to an external MCP server. The Custom MCP node that lets the application connect to any external MCP server using user-supplied configurations is where the problem lies. In version 3.0.5, these configurations are not properly validated against malicious code, allowing remote code execution. “This node parses the user-provided mcpServerConfig string to build the MCP server configuration,” reads an NVD description of the flaw. “However, during this process, it executes JavaScript code without any security validation. Specifically, inside the convertToValidJSONString function, user input is directly passed to the Function() constructor, which evaluates and executes the input as JavaScript code.” As the named function runs with full Node.js runtime privileges, “it can access dangerous modules such as child_process and fs,” the description adds. The flaw is tracked under CVE-2025-59528, and was assigned a critical rating of CVSS 10.0 at the time of disclosure in September, 2025. The flaw was categorized under “Improper Control of Generation of Code (code Injection).” Hackers exploit unpatched instances While a patch has been available for months, a recent VulnCheck finding places the first in-the-wild exploitation on April 6. Caitlin Condon, VP of Security Research at the vulnerability intelligence company, warned of the abuse through a LinkedIn post. “Early this morning, VulnCheck’s Canary network began detecting first-time exploitation of CVE-2025-59528, an arbitrary JavaScript code injection vulnerability in Flowise,” she wrote. “Observed activity so far originates from a single Starlink IP.” Around 12000 to 15000 instances remained exposed at the time, she noted in her post, although it is unclear how many of them were running a vulnerable Flowise version. Condon added two more critical Flowise vulnerabilities, a missing authentication (CVE-2025-8943) and an arbitrary file upload (CVE-2025-26319), in the post that she said were also flagged against active exploitation by the Canary network. Exclusive exploitation details, including full payload and request data, were promised to the Canary Intelligence customers. Additionally, an exploit, PCAP, YARA rule, network signatures, and target Docker container have been available to its Initial Access Intelligence customers. View the full article

As the US and Iran agreed to a ceasefire on Tuesday, six US federal agencies have warned that Iran-affiliated threat actors have compromised internet-exposed programmable logic controllers at critical infrastructure facilities in the US. The attacks, which the agencies linked to escalating hostilities between Iran and the US and Israel, targeted Rockwell Automation and Allen-Bradley PLCs at water and wastewater, energy, and government facilities, including local municipalities, and have been active since at least March 2026, according to the advisory, co-authored by the FBI, CISA, NSA, EPA, Department of Energy, and US Cyber Command’s Cyber National Mission Force, and published on Tuesday. “Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT-group that disrupted the function of PLCs,” the advisory said. “These PLCs were deployed across multiple US critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy sectors) within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.” How attackers gained access To carry out those manipulations, the actors used leased overseas infrastructure and legitimate Rockwell Automation configuration software to connect to victim PLCs, specifically CompactLogix and Micro850 devices that were left directly exposed to the public internet, the advisory said. Once inside, they extracted project files, altered SCADA and HMI display data, and installed remote access software to maintain a persistent foothold, it added. The advisory also warned that port activity associated with Siemens S7 PLC protocols “suggests these actors may also be targeting devices manufactured by companies other than Rockwell Automation/Allen-Bradley.” Steve Povolny, VP of AI strategy and security research at Exabeam, said the campaign reflects longstanding structural weaknesses in OT environments. “Programmable logic controllers and supporting HMI stacks are often deployed on aging hardware, run outdated firmware for years at a time, and sit inside operational networks that were never designed with adversarial persistence in mind,” he said. Gabrielle Hempel, security operations strategist at Exabeam, said the attacks exposed a fundamental design problem. “The most concerning thing about this report is that Iranian actors aren’t using sophisticated malware or new zero-days, but leveraging accessible PLCs and low-hanging fruit to manipulate systems and cause disruption,” she said. “If an OT environment is reachable from the internet, that is an inherent design flaw and not a nation-state problem.” A recurring Iranian playbook The advisory linked the current campaign to a pattern of Iranian state-affiliated targeting of US industrial control systems. The authoring agencies have previously reported similar activity by CyberAv3ngers, affiliated with Iran’s Islamic Revolutionary Guard Corps Cyber Electronic Command, which compromised at least 75 Unitronics PLC devices across water, wastewater, and other critical infrastructure sectors beginning in November 2023. The current activity is attributed to a separate, though related, group of Iranian-affiliated APT actors, the advisory said. The authoring agencies assessed that the group is “conducting this activity to cause disruptive effects within the United States.” The advisory said the escalation is likely tied to ongoing US-Iran-Israel hostilities. Ross Filipek, CISO at Corsica Technologies, said the consequences of even partial compromises extend well beyond individual victim organizations. “If a municipal utility goes down, suppliers, hospitals, and regional partners feel it,” he said. “Each successful or even partially successful campaign lowers the barrier for the next one, and emboldens actors to move from nuisance-level defacement into real operational interference.” Indicators of compromise and recommended actions The advisory listed eight IP addresses linked to the threat actors, active as far back as January 2025, along with downloadable indicators of compromise, and recommended organizations query their logs for any matching activity, particularly traffic on OT-associated ports originating from overseas hosting providers. “Ensure all access is mediated, monitored, and controlled,” the advisory said. For Rockwell Automation controllers with a physical mode switch, it is recommended to place the switch in run position to block remote modification. The advisory also placed responsibility on device manufacturers, stating: “It is ultimately the responsibility of the device manufacturer to build products that are secure by design and default.” Hempel said that the principle needs to become an enforced baseline. “‘Secure by design’ needs to be enforced as a baseline expectation across the board,” she said. Povolny said organizations should treat the advisory as an active warning, not a routine notification. “Adversaries are signaling intent, capability, and access patterns, and defenders should respond with the assumption that probing activity is already underway,” he said. View the full article

Two independent research programs, one from AI security firm Irregular, one from Kaspersky, have now converged on the same conclusion: Every frontier LLM generates structurally predictable passwords that standard entropy meters catastrophically overrate. AI coding agents are autonomously embedding those credentials in production infrastructure, and conventional secret scanners have no mechanism to detect them. As a security professional who has spent considerable time scrutinizing how generative AI integrates into enterprise development workflows, I confess that the quantification of what I already suspected still gave me pause. Irregular, an AI security evaluation firm, prompted Claude Opus 4.6 to generate passwords in 50 independent sessions. Only 30 distinct strings emerged from those 50 attempts. One specific sequence, G7$kL9#mQ2&xP4!w, recurred 18 times, a repetition rate of 36 percent. Over a genuinely uniform distribution across a 94-character printable ASCII alphabet, the probability of any specific 16-character sequence appearing even twice in 50 draws approaches the vanishingly infinitesimal. The model is not generating passwords; it is retrieving them. That distinction is the crux of an emerging and underappreciated threat class. LLM-generated passwords satisfy every superficial heuristic we have trained practitioners to apply requisite length, case heterogeneity, numerical and symbolic admixture, absence of recognizable dictionary fragments. Automated checkers consistently rate them excellent. The peril is not in how they appear to tools designed for a different threat model; it is in how they function against an adversary who understands the distributional peculiarities of autoregressive generation. The architectural incompatibility The root pathology is architectural rather than configural, a distinction of considerable practical significance because it forecloses remediation through tuning. A cryptographically secure pseudorandom number generator (CSPRNG), as mandated by NIST SP 800-90A Rev. 1 for all security-sensitive entropy generation, produces each character with statistically equal probability drawn from a truly uniform distribution. No character is preferentially weighted. No positional bias exists. Every token is independent of every antecedent token. Large language models operate on a fundamentally antithetical principle. They are trained to assign maximal probability to the most plausible successor token given an accumulated context, a mechanism that is simultaneously the source of their remarkable generative fluency and their categorical unsuitability for cryptographic applications. When prompted to produce a password, an LLM draws upon its internalized distributional knowledge of what human-generated passwords characteristically look like: The prevalence of uppercase initiation, the clustering of numerals in medial positions, the predilection for terminal exclamation marks. These are not aberrations; they are the faithful expression of training-corpus statistics. Irregular’s research quantifies this chasm using Shannon entropy applied to observed character-frequency distributions across generation corpora. A 16-character password drawn from a genuine CSPRNG over the full 94-character ASCII set carries approximately 98 bits of entropy by this measure. Claude Opus 4.6 achieves roughly 27 bits, a deficit of approximately 72 percent relative to the cryptographic baseline. GPT-5.2’s 20-character passwords, evaluated via the log-probability method, exhibit entropy closer to 20 bits. Conventional strength estimators, including the widely deployed zxcvbn library, characterize these same passwords at 98 to 100 bits. The divergence is not marginal; it is nearly an order of magnitude. Temperature is not a remedy A reflexive objection from practitioners familiar with LLM configuration holds that increasing sampling temperature would attenuate these distributional biases by flattening the probability landscape from which characters are drawn. Irregular’s empirical results are unambiguous in refuting this intuition. Testing conducted at temperature 1.0, the maximum setting on Claude, produces no statistically meaningful improvement in effective entropy. The character-position biases are encoded in model weights, not in sampling parameters, and temperature modulation operates downstream of those weight-instantiated distributions. Separately, Kaspersky’s Data Science Team Lead Alexey Antonov conducted a complementary investigation analyzing 1,000 passwords generated by ChatGPT, Meta’s Llama, and DeepSeek. The character-frequency histograms disclosed pronounced non-uniformity across all three models: ChatGPT exhibits a systematic preference for the characters x, p, and L; Llama for the hash symbol and the letter p; DeepSeek for t and w. At temperature 0.0, Claude produces the identical string on every invocation. These findings are consistent across different model families and measurement methodologies, corroborating the structural rather than incidental nature of the vulnerability. The practical corollary is that an adversary who has identified the LLM used to generate a target credential need not attempt exhaustive brute-force against a 94^16 keyspace. They can construct a model-specific attack dictionary, ordering candidates by their empirical generation frequency, and execute a probabilistically optimized search against a keyspace several orders of magnitude smaller. Kaspersky’s cracking tests found that 88 percent of DeepSeek passwords and 87 percent of Llama passwords failed to withstand targeted attack, as did 33 percent of ChatGPT passwords, all using standard GPU hardware. The agentic injection problem The portion of this problem amenable to user education, practitioners being counselled not to solicit passwords from conversational AI interfaces, represents a fraction of the aggregate exposure. The more consequential and considerably less tractable vector is autonomous credential generation by AI coding agents embedded in professional development toolchains. When an AI coding agent such as GitHub Copilot, Claude Code, or an analogous instrument receives a task specification entailing database initialization, containerized service configuration, or API bootstrapping, it generates credentials as a functional prerequisite of task completion. No explicit instruction to produce a password is required; the agent infers necessity from context. The resulting credential is embedded in a Docker Compose environment variable, a .env configuration file, or a Kubernetes secret manifest and is committed to version control by a developer whose attentional resources are directed at functional correctness, not credential provenance. The OWASP Top 10 for LLM Applications 2025 designates insecure output handling as a critical risk category, one that encompasses precisely this failure mode, wherein LLM-generated content is consumed without appropriate validation by downstream systems and processes. The credential thus introduced is not flagged by Gitleaks or Trufflehog, because those tools employ pattern-matching against known secret formats and have no capacity to evaluate the character-position entropy distribution that distinguishes a CSPRNG-derived credential from an LLM-derived one. Organizational response priorities The remediation landscape is tractable for organizations prepared to act methodically. The following priorities are sequenced by immediacy of risk reduction. Conduct a retrospective audit of all AI-assisted repositories dating to early 2023, when agentic coding tools achieved widespread enterprise adoption. Particular scrutiny should be directed at configuration files, Docker Compose YAML, and .env entries. Credentials exhibiting LLM-characteristic distributional signatures, consistent uppercase initialization, medial numeral clustering, terminal special characters, warrant investigation regardless of their apparent complexity. Rotate every credential whose provenance cannot be affirmatively traced to a CSPRNG invocation. The canonical CSPRNG interfaces, Python’s secrets.token_urlsafe(), openssl rand -base64, /dev/urandom, are the only acceptable sources. An audit trail establishing provenance is operationally valuable; absent such a trail, the presumption should favor rotation. Amend AI coding tool system prompts and secure development guidelines to mandate explicit CSPRNG invocation for all credential generation. The instruction must be categorical: The agent generates no password strings; it calls the appropriate platform function. This single-sentence policy amendment, consistently enforced, prevents the class of agentic injection at its origination point. Augment static secret scanning with entropy-aware analysis capable of evaluating character-position distributions rather than merely pattern-matching against known formats. This capability gap is currently the central technical challenge in operationalizing detection for this threat class. Escalate to LLM vendors through enterprise agreement channels. The architectural fix, routing password generation requests to a CSPRNG backend rather than processing them through the autoregressive generation pipeline, is an engineering decision available to AI providers. NIST SP 800-63B Revision 4, released in August 2025, establishes unambiguous guidance on entropy requirements for authentication credentials. Vendor accountability to that standard is a legitimate contractual expectation. The broader epistemological challenge The phenomenon of LLM-generated passwords, now being called ‘vibe passwords’ in security community discourse, an appellation that captures the verisimilitude without the substance, is a specific instantiation of a broader epistemological challenge that will recur as AI-generated content becomes more deeply entangled with security-sensitive infrastructure. The training objective that makes large language models extraordinarily capable of producing contextually appropriate, humanistically plausible outputs is structurally incompatible with the mathematical requirements of cryptographic security, which demand genuine unpredictability precisely where pattern and plausibility offer no traction. The diagnostic tools and remediation pathways exist. What the security community requires, with some urgency, is the systematic awareness that the problem has already propagated into production environments at a scale that warrants immediate and deliberate organizational response, not anticipatory policy, but retrospective investigation. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Russian threat actor Forest Blizzard has been exploiting unsecured home and small-office internet equipment, such as routers, to redirect traffic through attacker-controlled DNS servers. The group has leveraged this DNS hijacking activity to support post-compromise adversary-in-the-middle (AiTM) attacks on Transport Layer Security (TLS) connections, targeting Microsoft Outlook on the web domains, according to a Microsoft Threat Intelligence report. By compromising upstream edge devices, the attackers are able to exploit less monitored networks and use them as a pathway to access enterprise environments. More than 200 organizations and over 5,000 consumer devices have already been impacted by Forest Blizzard’s malicious DNS infrastructure, which Microsoft says is primarily used to collect intelligence in support of the Russian government’s foreign policy objectives. The activity enables interception of cloud-hosted content, with government, IT, telecommunications, and energy sectors among the primary targets. While the number of organizations specifically targeted for TLS AiTM is only a subset of the networks with vulnerable SOHO devices, the threat actor’s broad access could enable larger-scale AiTM attacks, which might include active traffic interception, Microsoft said in the blog post. Hijacked routers, stolen sessions Forest Blizzard, also called APT28 by the UK’s National Cyber Security Center, broke into home and small-office routers and changed their network settings so that internet traffic was sent through their own DNS servers. For this, the threat actor almost certainly used the dnsmasq utility to perform DNS resolution and provide responses while listening to port 53 for DNS queries, Microsoft Threat Intelligence noted. Most of the time, attackers quietly monitored traffic without disrupting connections. But for specific targets, they spoofed DNS responses and actively redirected users to the fake infrastructure they controlled. These included a subset of domains associated with Microsoft Outlook on the web. Separate AiTM activity targeting non-Microsoft hosted servers in at least three government organizations in Africa was also identified. “The actor-controlled malicious infrastructure would then present an invalid TLS certificate to the victim, spoofing the legitimate Microsoft service. If the compromised user ignored warnings about the invalid TLS certificate, the threat actor could then actively intercept the underlying plaintext traffic — potentially including emails and other customer content — within the TLS connection,” claimed the blog post. Invisible path to enterprise systems This attack poses a serious risk to enterprises because, instead of beginning at the corporate perimeter, it starts from employee environments that are often less secure. Threat actors target vulnerable home or small office routers, which often have weak default passwords or unpatched software. The shift to remote work has dramatically expanded the corporate attack surface, allowing attackers to create a pathway into enterprise accounts without directly breaching corporate systems. “The real-world impact is profound. Attackers can intercept credentials, reroute traffic to malicious sites, or inject malware, all without ever breaching the corporate firewall. This can lead to data breaches, financial theft, or even ransomware incidents originating from an employee’s living room,” said Apeksha Kaushik, senior principal analyst at Gartner. “Moreover, the lack of visibility and control over home networks means these attacks can persist undetected, undermining even the most robust corporate security programs. In essence, every unsecured home network becomes a potential backdoor into the enterprise, amplifying risk and complicating incident response.” Defending beyond corporate networks For CISOs, this broadens the focus area beyond merely securing corporate networks and even addressing risks in employee home environments and unmanaged devices. “First, stop using passwords. Robust two-step verification systems that do not allow for phishing attacks, especially hardware tokens, could prevent most of these attacks despite credentials being obtained,” said Devroop Dhar, CEO and co-founder at Primus Partners. Dhar added that CISOs should look at controlling the behaviour of identities. For instance, if there is an unusual location or device involved in the login procedure, additional warnings or checks need to be generated. “Enforce secure DNS solutions by utilizing corporate VPNs with split tunneling disabled or enforcing DNS over HTTPS to ensure all DNS queries bypass the local home router and go directly to trusted corporate servers,” suggested Amit Jaju, global partner at Ankura Consulting. “Also, implement strict conditional access policies that require devices to be enrolled in mobile device management and marked as compliant before granting access to corporate cloud resources.” Experts also warn that even after taking all precautions and defence measures, educating employees should be the utmost priority, as they must be trained to recognize suspicious behaviour during login procedures. View the full article

A zero-day is not frightening because it is sophisticated. It is frightening because it is unknown. There is no patch in the moment it matters most. That single condition undermines the comfort most security programs rely on: time. In the past, attackers didn’t need zero-days because they relied on predictable failures in patching and credential hygiene. The sheer labor required to find new vulnerabilities acted as a natural throttler on advanced attacks. Agentic AI removes that friction. By automating the trial-and-error cycle, AI transforms vulnerability research into a high-speed, 24/7 operation, making the once-rare zero-day a scalable threat. What a zero day is and why it matters A zero-day is a flaw that the vendor and defenders do not yet know exists. And because a zero-day vulnerability is unknown to the manufacturer, it exists in a defensive vacuum where there is no patch to deploy and no proven strategy to follow. Exploitation forces a shift from “business as usual” to an “emergency operational event.” In these scenarios, the organization loses its autonomy, as external stakeholders and the attackers themselves set the pace of recovery. While Stuxnet showed that cyberattacks could have physical consequences, and Heartbleed demonstrated the fragility of the internet’s cryptographic backbone, Log4Shell in late 2021 changed the game by revealing the risk posed by modern dependencies. A logging library embedded into thousands of packages created a global response effort, and government agencies warned that exploitation would persist over time. Those incidents also underline that when the vulnerable component is ubiquitous, your risk surface includes software you did not write, do not inventory cleanly and may not even realize you run. Scaling vulnerability discovery to machine speed Agentic AI is AI that can act, not just advise. Give it an objective, and it will plan steps, run them, learn from what happens and adjust until it succeeds or hits a hard stop. In cybersecurity, that looks like an automated operator. It can probe an application, test multiple attack paths, change tactics when defenses hold and keep iterating without waiting for a human to re-aim it. We already have credible public signals that AI-assisted systems can help discover real-world vulnerabilities in widely used open source components. Google Project Zero and Google DeepMind disclosed that an AI agent called Big Sleep found an exploitable vulnerability in SQLite, and maintainers fixed it the same day it was reported. Google’s security team also described AI-assisted fuzzing work that reported new vulnerabilities to open source maintainers, including one in OpenSSL. DARPA’s AI Cyber Challenge was built around the same direction of travel, which is automated vulnerability discovery and patching at scale. As discovery accelerates, the time between unknown and exploited compresses. That weakens any security model built around periodic assurance. Annual penetration tests and quarterly scans still matter, but they cannot be the backbone of resilience when a motivated adversary can probe continuously, adapt quickly and never get tired. Reducing the value of the inevitable breach Resilience begins with data minimization. If an internet-facing service does not need raw sensitive data, it should not be able to retrieve it. Tokenization and non-reversible storage, among other approaches, reduce the value of a successful breach. You cannot lose what you never collected, and you cannot leak what the service cannot see. Next comes API discipline. APIs are the nervous system of the enterprise. They are also an ideal interface for automated probing because an attacker does not need a UI to harvest what an endpoint returns. Ensure every endpoint response is a deliberate security decision. If a client does not need a field, the API should not return it. Keeping attackers out is only half the battle. The real test of security is what happens after they get in. The goal is to ensure that if a door is forced open, the intruder finds themselves in a room with no exit. Use least-privilege access and strong authentication to kill their momentum. Then, use micro-segmentation to lock down the hallways. By blocking lateral movement, a single compromised system stays isolated. This helps protect core data and keeps operations running. Operational resilience is the best security strategy Security does not sit on top of a fragile environment and “work harder” to make it safe. Security must be baked into IT operations—from system design to change control. This is why CIO and CISO agendas must merge. When the pressure is on, they can rely on accurate inventories, secure-by-design architecture and disciplined change management. Recovery plans are useless if they are only documented; they must be practiced. Agentic AI raises the stakes because it leaves no lead time. It finds and hits a weakness almost instantly. You do not win that race with promises of perfect prevention. You win by reducing what is exposed, limiting how far an intruder can move and continuously validating that your controls still work as your environment changes. In an era where attackers can probe without pause, is your organization built to absorb that test without breaking? This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Microsoft has quietly introduced the Agent Governance Toolkit, an open-source project designed to monitor and control AI agents during execution as enterprises try to move them into production workflows. The toolkit, which is a response to the Open Worldwide Application Security Project’s (OWASP) emerging focus on AI and LLM security risks, adds a runtime security layer that enforces policies to mitigate issues such as prompt injection, and improves visibility into agent behavior across complex, multi-step workflows, Imran Siddique, principal group engineering manager at Microsoft wrote in a blog post. More specifically, the toolkit maps to OWASP’s top 10 risks for agentic systems, including goal hijacking, tool misuse, identity abuse, supply chain risks, code execution, memory poisoning, insecure communications, cascading failures, human-agent trust exploitation, and rogue agents. The rationale behind the toolkit, Siddique wrote, stems from how AI systems increasingly resemble loosely governed distributed environments, where multiple untrusted components share resources, make decisions, and interact externally with minimal oversight. That prompted Microsoft to apply proven design patterns from operating systems, service meshes, and site reliability engineering to bring structure, isolation, and control to these environments, Siddique added. The result was the Redmond-headquartered giant packaging these principles into the toolkit comprising seven components available in Python, TypeScript, Rust, Go, and .NET. The cross-language approach, Siddique explained, is aimed at meeting developers where they are and enabling integration across heterogeneous enterprise stacks. As for the components, the toolkit includes modules such as a policy enforcement layer named Agent OS, a secure communication and identity framework named Agent Mesh, an execution control environment named Agent Runtime, and additional components, such as Agent SRE, Agent Compliance, and Agent Lightning, covering reliability, compliance, marketplace governance, and reinforcement learning oversight. Beyond its modular design, Siddique further wrote that the toolkit is built to work with existing development ecosystems: “We designed the toolkit to be framework-agnostic from day one. Each integration hooks into a framework’s native extension points, LangChain’s callback handlers, CrewAI’s task decorators, Google ADK’s plugin system, Microsoft Agent Framework’s middleware pipeline, so adding governance doesn’t require rewriting agent code.” This approach, the senior executive explained, would reduce integration overhead and risk, allowing developers to introduce governance controls into production systems without disrupting existing workflows or incurring the cost and complexity of rearchitecting applications. Siddique even went on to give examples of several framework integrations that are already deployed in production workloads, including LlamaIndex’s TrustedAgentWorker integration. For those wishing to explore the toolkit, which is currently in public preview, it is available under an MIT license and structured as a monorepo with independently installable components. Microsoft, in the future, plans to transition the project to a foundation-led model and is already engaging with the OWASP agentic AI community to support broader governance and stewardship, Siddique wrote. The article originally appeared in InfoWorld. View the full article

In the early 1800s, Prussian officers began rehearsing battles around sand tables. They called it Kriegsspiel, and it worked because it forced them to make high-stakes decisions under pressure. Fast forward to today, and that same concept has become cybersecurity’s go-to tool for crisis preparedness: the tabletop exercise. For good reason: it still works. Full disclosure: we are actively building in this space. That’s partly why we’ve spent so much time dissecting where these exercises fall short. The observations below come directly from the trenches. Lee and I have spent years facilitating these scenarios for everyone from growth-stage technology startups to massive global enterprises in highly regulated industries. What we’ve observed consistently is that tabletops deliver genuine value. But at the same time, we both noticed that tabletop exercises also have a ceiling most experienced practitioners quietly acknowledge and rarely discuss openly. What tabletops built and where they stop Here is what we like about tabletops: they put people in a room and force them to talk through a crisis before one arrives. It builds shared understanding of roles and escalation paths. It surfaces gaps between the documented plan and operational reality: the outdated contact list, the ambiguous chain of authority, the runbook written for infrastructure the organization no longer runs. It develops cross-functional trust between security, legal, communications and the executive team. And it satisfies compliance frameworks, including SOC 2, ISO 27001 and NIST that require documented evidence of incident response testing. Getting the extended team (e.g., legal, privacy, comms, support, engineering, infra) together results in genuine benefits to the shared understanding of roles, responsibilities and how an incident impacts all areas of a company. But traditional exercises carry a fundamental limitation of the medium. Most tabletops test knowledge of the plan. They do not test the ability to execute it. Scenarios are scripted. Injects arrive on a fixed schedule regardless of what the team decides. The crisis communications plan sits in a shared drive, but nobody has tested whether the holding statement holds up when a reporter calls. The incident response plan defines roles, but nobody has observed whether those roles function when three things go wrong at once. Participants discuss theory and knowledge of a plan. It’s about what they would do. They do not do it. Every experienced facilitator knows the moment: someone in the room challenges the premise and the facilitator asks participants to “suspend disbelief.” That phrase should give us pause. If the scenario requires suspension of disbelief, it is not building preparedness. It is building familiarity with a document. The gap between documentation and execution is well-documented. CISA’s cyber exercise guidance notes that discussion-based exercises alone are insufficient for validating operational readiness, yet that is what most organizations rely on. The Ponemon Institute reports that just over half of security teams believe their incident response plans are effective. Most face real incidents having never practiced under conditions that resemble one. Bring tabletops to life with AI Advancement in AI agentic capabilities make it possible to address the traditional tabletop’s primary limitation: the inability to respond dynamically to what the team actually does. For every action, there should be a reaction instead of a series of predefined injects that completely ignore the actions a team would take. Imagine if the roles that were previously absent (e.g., the threat actor, the journalist, the regulator, the customer) could respond to the team’s decisions in real time rather than following a fixed sequence. Until recently, approximating this required hiring a crew of trained actors, which nobody does. AI allows us to have an adversary that adapts to defensive decisions rather than following a script. Now it’s possible to have simulated stakeholders (e.g., press, regulators, customers) that react to the timing and substance of the team’s communications. The possibility is that every decision could produce consequences that cascade forward, a fidelity of simulation that simply wasn’t achievable at scale before. Using AI, we can change the nature of the exercise from discussion to practice. Organizations could observe whether their crisis processes hold up under realistic pressure. Is the incident response plan followed, or merely referenced? Does the incident commander maintain situational awareness while the team works parallel problems? Instead of self-reported intentions, observed behaviors could be logged, timestamped and mapped to frameworks like MITRE ATT&CK and NIST CSF instead of assumptions carried forward into the next exercise? The frequency problem could also shift. When a traditionally facilitated exercise costs tens of thousands of dollars and requires weeks of preparation, most organizations run one annually at best. Skills atrophy between cycles. New team members never participate. The IBM and Ponemon Institute 2025 Cost of a Data Breach Report, which surveyed more than 600 organizations across 17 industries, found that organizations testing incident response at least twice a year reduced breach costs by $1.49 million on average. If AI compresses preparation time and cost significantly, more frequent exercises become viable. Beyond frequency, there are possibilities traditional exercises structurally cannot offer. A well-configured AI-augmented exercise could be built around an organization’s actual environment rather than a generic scenario. Generic scenarios produce generic learning. The gap between a simulated crisis and the real one is where preparedness quietly erodes. Perhaps most importantly, the nature of the scenario itself could change. Traditional exercises tend toward resolution: the team works the problem; the facilitator guides them through it and the exercise ends on a manageable note. An AI-driven approach could introduce compounding failures, unexpected escalations and realistic time pressure without a facilitator needing to manage the room’s morale. The goal would be to find where the plan actually breaks instead of confirming it exists. And unlike a single annual exercise that produces a snapshot, repeated cycles could generate longitudinal data: whether response times improve, whether the same gaps recur, whether the program is measurably stronger than it was six months ago. That kind of trend data has been difficult to produce. It’s also easy to over-index on. Metrics that show improving response times don’t necessarily mean an organization is better prepared. They may mean the team is getting better at the simulation. The next step The tabletop exercise has served our profession well. It brought structure to crisis preparedness, created a common language between security teams and business leadership and gave us a way to prepare before the real thing arrived. AI-augmented approaches offer the next step in that tradition: the ability to move from discussing a crisis to experiencing one. To test the communication materials that have never been tested. To observe whether the incident response plan is followed or merely referenced. To surface the gaps that scripted scenarios never reach. We do not think this replaces the skilled facilitator (the company CISO or consultant). The judgment-intensive post-mortem debrief that follows a well-run exercise is absolutely essential. Think of it like basketball: a coach can only give you meaningful feedback if they’ve seen you play. The AI-augmented exercise is the game; the post-mortem debrief is the coaching. What AI does is raise the floor so that the work of a good facilitator starts from a richer baseline of observed behavior rather than participant recall and self-assessment. The tabletop is ready to grow up. Whether your program is ready to grow with it depends less on the technology than on your organization’s willingness to test its processes against something that actually pushes back. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

AI giant Anthropic has unveiled Project Glasswing, a cybersecurity initiative built around Claude Mythos Preview, a model it describes as “cybersecurity in the age of AI” that can autonomously identify software vulnerabilities at scale. Rather than release the model publicly, Anthropic is restricting access to a closed consortium of more than 40 companies that includes Amazon, Microsoft, Apple, Alphabet-owned Google, and the Linux Foundation, along with a small group of security vendors such as CrowdStrike, Palo Alto Networks, and Cisco. “Mythos makes the first domino clearer: Once frontier AI can do large-scale bug hunting, the logic of paying humans for routine discovery starts to break down,” says Jeff Williams, founder of OWASP and CTO of Contrast Security. According to Anthropic, the goal is to apply these capabilities in a controlled, defensive setting, enabling participating organizations to test and improve the security of widely used software and infrastructure. The economics of bug hunting shift In early testing, Anthropic claims the model identified thousands of high-severity vulnerabilities across operating systems, browsers, and other widely used software. Some had persisted despite extensive prior review — including a 27-year-old flaw in OpenBSD, long considered one of the most security-hardened operating systems and widely used in critical infrastructure. As with many early AI capability claims, the results are largely self-reported and only partially externally verifiable, but they point to a clear direction: Vulnerability discovery is becoming more automated and scalable. That shift raises questions about how security work is organized and valued. For OWASP’s Williams, the disruption begins with economics. If AI systems can perform large-scale vulnerability discovery, the rationale for relying on human-driven bug hunting — particularly for routine discovery — erodes. But the implications extend beyond bug bounty programs. “This does not just threaten bug bounties,” he says. “It threatens the whole idea that security can remain a find-and-fix afterthought. The era of the security backlog is coming to a welcome end.” From backlog management to exposure-window risk The issue, as Williams frames it, is not simply how many vulnerabilities exist, but how they are managed. “Mythos makes one thing painfully clear,” he says. “This is not a prioritization problem. It’s an exposure-window problem.” Traditional vulnerability management has been built around prioritization — ranking issues by severity, exploitability, and business impact, then working through remediation over time. Williams argues that the limiting factor is no longer how well organizations prioritize, but how long vulnerabilities remain exposed. Adapting to AI-powered cyber defense Anthony Grieco, SVP and chief security and trust officer at Cisco, places the development in a broader operational context. In a blog post, Grieco argues that organizations must “rise to the era of AI-powered cyber defense,” reflecting a shift in both the threat landscape and the capabilities required to respond. Cisco is among the organizations participating in Project Glasswing, joining what Anthropic describes as a collaborative effort to apply advanced AI capabilities to defensive security use cases. Grieco emphasizes that security programs will need to evolve alongside rapidly advancing AI capabilities. “AI capabilities will continue to advance, the threat surface will evolve, and the organizations that protect the internet will need to operate at the speed of machines and the scale of networks,” Grieco says. “Much of what we are now experiencing would have been unimaginable just a few years ago. There is no finish line, only a commitment to do everything possible to stay ahead of adversaries.” For security leaders, that combination — more scalable discovery and the need to operate at greater speed — challenges longstanding assumptions about how risk is handled. Backlogs, long treated as an unavoidable operational reality, become harder to justify if vulnerabilities can be identified more quickly and comprehensively. A shift upstream — and open questions about control “The future belongs to software factories that can reliably produce secure code and the assurance case to prove it,” Williams says, pointing to a model in which security is built into development processes rather than addressed primarily after deployment. Grieco’s emphasis on adapting to AI-powered threats aligns with that direction, underscoring the need for organizations to evolve both their tools and their assumptions about how quickly security-relevant conditions can change. At the same time, questions remain about how broadly these capabilities will spread. Anthropic has chosen to limit access to Mythos Preview, reflecting the dual-use nature of systems that can identify software vulnerabilities at scale but could also accelerate their exploitation. “It’s highly questionable that Anthropic will be able to limit the malicious uses of this model,” Williams says. Anthropic has committed $100 million in model usage credits to Project Glasswing, with participants expected to contribute additional usage during the research preview. Claude Mythos Preview will be available through the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. The company has also pledged funding to open-source security efforts, including donations to Alpha-Omega, OpenSSF, and the Apache Software Foundation to support maintainers responding to these changes. Maintainers interested in access can apply through the Claude for Open Source program. View the full article

Hackers have been exploiting a critical vulnerability in FortiClient Endpoint Management Server (FortiClient EMS) since at least the end of March. Fortinet has published an advisory and released an emergency hotfix that can be applied to affected deployments until a patched version can be released. The vulnerability, now tracked as CVE-2026-35616, allows unauthenticated attackers to remotely execute arbitrary code on FortiClient EMS, which organizations use to manage, monitor, provision, patch, quarantine, and monitor endpoint systems. The flaw is rated 9.1 (critical) in the Common Vulnerability Scoring System and was added by the US Cybersecurity and Infrastructure Security Agency (CISA) to its Know Exploited Vulnerabilities catalog on Monday. The vulnerability affects FortiClient EMS 7.4.5 and 7.4.6. The company plans to patch the vulnerability in upcoming version 7.4.7. In the meantime, a hotfix can be applied to the EMS Linux Server via the command line. The issue has been patched server-side on FortiClient Cloud and FortiSASE, so only on-premises deployments are impacted. Researchers from security firm watchTowr first saw exploitation of this vulnerability on March 31, days before Fortinet released its advisory and hotfix. Due to this zero-day status, users should check deployments for possible compromise, in addition to applying the patch. “The timing of the ramp-up of in-the-wild exploitation of this zero-day is likely not coincidental,” watchTowr CEO Benjamin Harris told CSO. “Attackers have shown repeatedly that holiday weekends are the best time to move. Security teams are at half strength, on-call engineers are distracted, and the window between compromise and detection stretches from hours to days. Easter, like any other holiday, represents opportunity.” Second FortiClient EMS RCE this year This zero-day incident comes after Fortinet patched a different flaw in FortiClient EMS in February that attackers also began exploiting in the wild. That vulnerability, tracked as CVE-2026-21643, was an SQL injection flaw that allowed unauthenticated attackers to execute arbitrary commands. The new vulnerability is an authentication bypass issue that stems from improper access control in the FortiClient EMS API. It allows attackers to execute code on the underlying server without valid credentials or user interaction. “The two vulnerabilities have not been confirmed as linked, and attribution to a specific threat actor has not been established,” the watchTowr researchers said. Mitigation and response In addition to the hotfix, organizations should review their available logs for any suspicious API requests and activity. Unfortunately, there are no published indicators of compromise for this malicious activity yet, so watchTowr recommends auditing all recent changes made to endpoint security policies, VPN configuration profiles, application firewall rules, administrator accounts and access controls, and endpoint compliance configurations. “If compromise is suspected, do not attempt to clean the affected instance in place,” the researchers said. “Restore from a known-good backup taken before the likely compromise window, or rebuild the EMS instance and migrate the data to it. Where integrity cannot be confidently verified, a full rebuild is the most defensible approach.” View the full article

Every asset you manage expands your attack surface. Internet‑facing applications, cloud workloads, credentials, endpoints, and third‑party integrations all represent potential entry points for attackers. As environments grow more distributed, that exposure expands faster than most security teams can track manually. Attack surface management (ASM) helps answer a critical question for IT security teams: What can attackers actually reach right now? By continuously identifying and prioritizing exposure across your environment, ASM transforms raw visibility into measurable cyber resilience. Below are five practical steps security teams can take to strengthen attack resilience using attack surface management principles. 1. Identify and monitor every attack surface category Effective attack surface management starts with complete visibility. Security gaps often appear because teams focus on only one or two asset types while attackers exploit others. A comprehensive ASM program maintains visibility across: External attack surfaces such as web applications, APIs, VPNs, DNS services, and email gateways Internal attack surfaces including Active Directory, file shares, internal databases, and privileged systems. The NIST Cybersecurity Framework 2.0 addresses internal surfaces through identity management, authentication, and access control functions. Digital attack surfaces like cloud workloads, containers, CI/CD pipelines, and code repositories. For MSPs managing multi-cloud environments, this category represents the largest and most complex attack surface. Physical attack surfaces such as endpoints, network devices, IoT systems, and removable media Human attack surfaces driven by phishing, social engineering, and credential abuse Cloud and hybrid environments where shared responsibility and misconfigurations increase risk. Multi-cloud credential management and heterogeneous environment visibility create challenges requiring CNAPP solutions and centralized asset inventory management. Gaps in any category create blind spots attackers exploit. Continuous discovery across all surfaces is foundational to resilience. 2. Focus on the attack vectors that break resilience fastest Understanding how attackers gain access helps security teams prioritize the right controls. Recent breach analysis consistently shows a few vectors responsible for most successful intrusions: Credential‑based attacks targeting VPNs, RDP, admin accounts, and RMM platforms Vulnerability exploitation, especially in public‑facing services and unpatched systems Third‑party compromise affecting shared tools, credentials, and infrastructure Cloud misconfigurations exposing services through overly permissive access or weak authentication Attack surface management helps surface where these risks exist across your environment, so remediation efforts focus on exposures that attackers actively exploit. 3. Move from periodic assessments to continuous exposure management Traditional quarterly scans cannot keep pace with modern infrastructure. Cloud deployments, configuration changes, and software updates happen daily. ASM requires continuous processes rather than point‑in‑time assessments. Effective programs follow four ongoing cycles: Discovery to identify known and unknown assets across on‑premises, cloud, and third‑party environments Assessment to detect vulnerabilities, misconfigurations, and exposed services continuously Prioritization based on exploitability, asset criticality, and active threat intelligence Remediation using automation for routine fixes and orchestration for critical exposures This approach aligns closely with modern continuous exposure management models and shifts teams from reactive firefighting to proactive risk reduction. 4. Prioritize what attackers are most likely to exploit Not every vulnerability represents the same level of risk. ASM becomes effective when prioritization reflects real‑world attacker behavior. Strong prioritization combines: CVSS severity for technical impact Exploit probability scoring to assess the likelihood of exploitation Asset criticality based on business impact Known exploited vulnerabilities tracked by government and industry sources This risk‑based approach ensures teams focus remediation efforts where they deliver the greatest resilience improvement. Automated patching and vulnerability management within tools like N-central RMM™ help close these gaps faster by connecting discovery, prioritization, and remediation in a single workflow. N‑central patches systems automatically across Windows and 100+ third-party applications, while built-in vulnerability management with CVSS scoring identifies exposures requiring immediate attention. 5. Integrate ASM with detection, response, and recovery Attack surface management alone does not stop attacks. Resilience improves when ASM is integrated into a broader before‑during‑after strategy. Before: Reduce exposure through patch automation, configuration management, and access controls During: Detect and contain active threats using continuous monitoring and threat detection After: Recover quickly using immutable backups and tested restoration processes Adlumin MDR™ adds 24/7 detection and response by monitoring endpoints and identities for malicious behavior, while Cove Data Protection™ supports rapid recovery with cloud‑first, immutable backups that remain protected even during ransomware events. Together, these capabilities help ensure that when attackers find an opening, the impact is contained and business operations continue. From visibility to resilience Attack surface management shifts security from guessing where risk exists to knowing what is exposed and acting on it continuously. For IT security teams managing complex, distributed environments, ASM provides the visibility and prioritization needed to reduce exposure at scale. When integrated with endpoint management, threat detection, and recovery capabilities, ASM becomes a critical driver of cyber resilience rather than just another security metric. To learn more, visit us here. View the full article

Supply chain attacks have rapidly become one of the most damaging and difficult threats facing IT and security teams. When an adversary compromises a trusted vendor, software component, cloud service, or MSP tool, they bypass traditional defenses and enter through the front door. For organizations managing distributed environments, and for MSPs supporting dozens or hundreds of clients, the impact can cascade quickly. Strengthening supply chain security is no longer an isolated risk management exercise. It is a core component of cyber resilience and business continuity. Below are five practical steps security teams can take to reduce exposure, improve visibility, and recover faster when a supplier is compromised. 1. Map your supply chain and prioritize critical dependencies Modern environments depend on complex webs of software, cloud providers, infrastructure services, and third‑party integrations. Visibility into that ecosystem is often incomplete, especially when open‑source libraries and inherited components are involved. Start by building a full inventory of your supply chain: All software vendors and SaaS platforms Open‑source components embedded in your applications MSP or IT service providers Cloud infrastructure and authentication services API integrations and automation workflows Once documented, classify each supplier by the impact they would have if compromised. A remote monitoring tool or authentication platform represents far greater risk than a basic productivity app. This prioritization helps you allocate time, resources, and enhanced scrutiny where it matters. 2. Evaluate and monitor supplier security posture continuously A one‑time vendor questionnaire cannot keep pace with evolving threats. Supply chain risk must be measured continuously using clear, repeatable criteria. Key areas to evaluate include: Frequency and transparency of security updates Secure development practices Patch and vulnerability remediation programs SBOM (software bill of materials) availability Incident response processes and communication expectations Automated monitoring is essential. SIEM, EDR, and behavioral analytics can reveal anomalies in vendor activity far earlier than manual checks. Treat every supplier as an external, untrusted entity. Even when a vendor is integrated deeply into your environment, apply Zero Trust principles by validating activity continuously and limiting access to only what is necessary. 3. Reduce blast radius with strong access controls Supplier credentials have been central to some of the most damaging breaches in recent years. If an attacker acquires a vendor’s account or API token, they often gain privileged access and freedom of movement. To reduce the blast radius of vendor compromise: Require MFA for all vendor accounts Apply least‑privilege permissions and segment vendor access Use just‑in‑time access for sensitive operations Regularly audit and remove stale permissions Monitor authentication behavior for anomalies This applies equally to MSPs managing large client portfolios. A breach that compromises tooling across your stack affects every environment you support. Proactive access governance is essential to limiting downstream impact. 4. Detect supply chain intrusions early with unified telemetry When a supplier is compromised, early detection is the key to containing risk. Attackers often exploit trusted update mechanisms, open‑source components, remote management tools, or cloud integrations in ways that appear legitimate at first. To catch these attacks quickly, you need telemetry across endpoints, identity, network behavior, email, and backups. Platform‑level visibility helps connect subtle signals across multiple systems. This is where products like N-able’s Security Solutions provide value. Centralized monitoring, AI‑driven detection, and automated response actions help remove blind spots and accelerate containment. For organizations without dedicated SOC teams, managed detection services scale expertise without expanding headcount. 5. Build recovery into your supply chain security strategy Even with strong preventive controls, supply chain compromise remains a high‑probability risk. Recovery speed determines whether the incident is a setback or a business‑disrupting event. A resilience‑first approach focuses on: Fast isolation of compromised endpoints Reliable, immutable backups protected from ransomware Automated recovery testing for confidence in restore readiness Playbooks for supply‑chain‑driven attacks Cross‑team coordination between IT operations, security, and leadership This is where N-able Cove Data Protection™ strengthens supply chain resilience. Because backups are isolated by default and stored in the cloud, they remain protected even when production infrastructure is compromised. Rapid, flexible restore options reduce downtime and minimize customer impact. For MSPs, this unified recovery capability ensures you can support multiple clients simultaneously during cascading supply chain incidents. For internal IT teams with limited staff, automation and cloud‑based recovery help maintain business continuity without significant additional overhead. Adopting a before‑during‑after defense strategy Supply chain threats require a layered approach. A before‑during‑after framework brings structure to your program: Before: Reduce exposure with patch automation, configuration management, and dependency visibility. RMM platforms help close vulnerabilities before attackers exploit them. During: Detect and contain threats through integrated EDR, DNS protection, and security operations. Unified telemetry improves accuracy and reduces noise. After: Restore operations quickly with cloud‑based, immutable backups and tested recovery processes. Business continuity depends on recovery that works reliably under pressure. This approach improves resilience not only for supply chain attacks but across your entire threat landscape. Strengthen your supply chain security with a unified platform As supply chain attacks grow in scale and sophistication, organizations must be prepared to identify risks quickly, contain compromise, and maintain continuity. Mapping dependencies, assessing supplier posture, enforcing strong access controls, unifying detection, and prioritizing recovery create a practical, achievable roadmap for IT and security teams. N-able’s integrated tools across endpoint management, security operations, and data protection help deliver the visibility, automation, and resilience needed to stay ahead of supply‑chain‑driven threats. View the full article

Identity compromise has become one of the most effective ways for attackers to infiltrate business systems. Firewalls, endpoint protection, and monitoring tools mean little once an attacker logs in using valid credentials. For MSPs and corporate IT teams, strengthening identity security and enforcing least privilege access are two of the most powerful ways to reduce blast radius and stop attacks earlier. This article outlines five practical steps to improve identity security across human, machine, and workload identities, while also building attack resilience through least privilege and continuous validation. 1. Enforce MFA everywhere—starting with high-privilege accounts Multi-factor authentication remains one of the most effective defenses against credential-based attacks. Passwords alone cannot protect critical systems, particularly when phishing and infostealer malware continue to accelerate. Start with the identities that carry the most risk: Admin accounts MSP technician accounts Cloud infrastructure accounts External-facing applications Remote access tools Any MFA deployment is better than none, but phishing-resistant methods offer the strongest protection. Once privileged accounts are enforced, expand MFA to all users over the next 30 days. Doing so reduces the likelihood that compromised credentials lead directly to unauthorized access. 2. Implement privileged access management to control admin permissions Least privilege is the second half of effective identity security. Even when a user successfully authenticates, they should only have access to the minimum resources required for their role. Privileged Access Management (PAM) helps enforce this by centralizing credential storage, eliminating shared administrative passwords, and controlling privilege elevation on endpoints. N-able Passportal™ helps teams vault and rotate privileged credentials automatically and integrate credential hygiene with Microsoft Active Directory. This reduces the risk of privilege creep, orphaned accounts, and long-lived passwords that attackers routinely exploit. For MSPs, centralized credential management prevents a compromised technician credential from granting access across dozens of client environments. For corporate IT teams, PAM reduces the likelihood that attackers can escalate privileges after gaining initial access. 3. Inventory every identity—human, machine, and workload You cannot protect the identities you do not know exist. Most environments have far more machine and service accounts than human users, and these non-human identities often carry higher privileges with far less scrutiny. A complete identity inventory should include: Employees, contractors, and vendor accounts Service accounts for scheduled tasks and automation API keys used in integrations Certificates supporting encrypted communication Application and workload identities used in cloud-native environments Machine and workload identities need special attention because they rarely trigger alerts when abused. Attackers increasingly target them to escalate privileges quietly. Maintaining this inventory helps IT teams identify shadow identities, remove unnecessary permissions, and reduce pathways attackers use for lateral movement. 4. Establish continuous validation to detect compromise earlier Credential compromise often goes undetected for months. Continuous validation helps reduce that window by monitoring identity behavior in real time, such as: Impossible travel logins Sudden privilege escalations Activity from unmanaged devices Unusual authentication patterns Unexpected API usage Modern identity attacks frequently blend automation, AI-driven phishing, and tactics that bypass traditional alerting. Continuous validation helps security teams catch these anomalies earlier and contain attacks before they spread. Tools such as Adlumin ITDR™ support identity threat detection by monitoring Microsoft 365 logins, detecting abnormal identity behavior, and automatically taking action based on severity. 5. Build zero trust foundations by combining identity, devices, networks, applications, and data Identity security is the first pillar of Zero Trust, but it cannot operate in isolation. Strong authentication means little if endpoints are unpatched or privileges are overly broad. To reduce lateral movement and strengthen attack resilience, Zero Trust requires continuous verification across five domains: Identity – authenticate every user and entity Devices – ensure endpoints meet security requirements Networks – limit movement using segmentation Applications – enforce granular permissions Data – protect sensitive information at the access layer Identity compromise often becomes dangerous because organizations have uneven maturity across these pillars. For example, enforcing MFA but allowing unmanaged endpoints still gives attackers footholds they can use after initial access. Tools like N-able N-central RMM™ help secure the device pillar by providing patch management, vulnerability scanning, and continuous endpoint monitoring. Cove Data Protection™ strengthens the data pillar by ensuring reliable recovery if identity compromise leads to ransomware or destructive activity. Building identity-driven attack resilience Identity security is not a one-time implementation. It is a continuous process of enforcing stronger authentication, removing unnecessary privileges, validating each access request, and monitoring for misuse. A practical roadmap for IT and security teams includes: Enforce MFA for all identities, starting with privileged accounts. Deploy PAM to manage and secure administrative credentials. Document all identity types and remove or restrict unnecessary accounts. Monitor authentication behavior continuously to detect compromise early. Extend Zero Trust practices across devices, networks, applications, and data. Taken together, these steps significantly reduce the likelihood that attackers can use valid credentials to gain broad access across your environment. They also help contain the impact when identity compromise does occur. Download the new 2026 State of the SOC report and get a data-driven playbook for resilience across identity, endpoint, cloud, network, and perimeter layers. View the full article

Indirect prompt injection is possible on AI-powered dashboards, allowing exfiltration of sensitive enterprise data without user authentication. Security researchers are warning about a critical Grafana issue, dubbed GrafanaGhost, that allows attackers to leak sensitive data from Grafana environments, including financial metrics, infrastructure health data, private customer data, and operational logs, among others. Noma Security disclosed the flaw to the Grafana team, which reportedly validated the flaw and rolled out a fix. Grafana is a widely used open-source data visualization and observability platform that enables organizations to monitor systems, applications and business metrics in real time. “GrafanaGhost perfectly illustrates how AI integration creates a massive security blind spot,” said Ram Varadarajan, CEO at Acalvio. “Because indirect prompt injection bypasses traditional defenses, requiring no credentials or user interaction, it allows attackers to silently exfiltrate sensitive operational telemetry.” Tricking Grafana AI into leaking sensitive data GrafanaGhost is essentially not a single bug but a chained exploit that combines multiple bypasses across application logic and AI guardrails. The attack begins with identifying an injection point, locations where user-controlled input can be stored and later processed by Grafana’s AI components. Noma researchers found that crafted paths embedded with indirect prompts could persist in the system and later be interpreted as legitimate inputs. From there, attackers use indirect prompt injection techniques to manipulate the AI into executing malicious instructions. The model is tricked into generating requests that include sensitive data while interpreting the instructions as benign. In a disclosure, Noma said that the key technical breakthrough came from bypassing client-side protections designed to block external image loading. By exploiting a flaw in URL validation, specifically using protocol-relative URLs like //attacker.com, the system mistakenly treats malicious external resources as safe, allowing outbound requests to the attacker’s infrastructure. Finally, the attack evades AI guardrails themselves by inserting specific keywords, such as INTENT, into prompts to convince the model that the request was legitimate. Once processed, the system attempts to render an image, embedding sensitive data into the request sent to the attacker’s server. The chain effectively enables automated, zero-click data exfiltration that blends into the normal dashboard workflow. Varadrajan pointed this out, saying attackers exploit the blind spot “using system components exactly as designed, but with instructions the model cannot verify as malicious.” Responding to CSO’s queries, Grafana Labs’ CISO Joe McManus disputed Noma’s claim that this finding constitutes either a “zero-click” attack or that it could operate silently, autonomously, or in the background. “Any successful execution of this exploit would have required significant user interaction: specifically, the end user would have to repeatedly instruct our AI assistant to follow malicious instructions contained in logs, even after the AI assistant made the user aware of the malicious instructions. We emphasize that there is no evidence of this bug having been exploited in the wild, and no data was leaked from Grafana Cloud,” McManus said. Real risk or overhyped edge case? Not everyone is convinced the finding represents a newfound threat. Bradley Smith, SVP and deputy CISO at BeyondTrust, described the underlying technique as “well documented,” noting that indirect prompt injection leading to data exfiltration is a known risk across AI-enabled platforms. “This seems like mostly hype to me,” Smith said, adding that “what’s less clear here is the practical exploitability against a hardened Grafana deployment with standard enterprise network controls.” Still, Smith acknowledged the broader implications. “This isn’t a universal bypass of Grafana,” he said. “It’s a demonstration of what can happen when AI components process untrusted input without sufficient architectural controls.” Identifying exposure to GrafanaGhost by checking whether Grafana AI/LLM features are enabled, patching to the latest version, restricting “img-src” to known domains, and applying egress controls can help defend against exposure, he added. View the full article

Indirect prompt injection is possible on AI-powered dashboards, allowing exfiltration of sensitive enterprise data without user authentication. Security researchers are warning about a critical Grafana issue, dubbed GrafanaGhost, that allows attackers to leak sensitive data from Grafana environments, including financial metrics, infrastructure health data, private customer data, and operational logs, among others. Noma Security disclosed the flaw to the Grafana team, which reportedly validated the flaw and rolled out a fix. Grafana did not immediately respond to CSO’s request for comments. Grafana is a widely used open-source data visualization and observability platform that enables organizations to monitor systems, applications and business metrics in real time. “GrafanaGhost perfectly illustrates how AI integration creates a massive security blind spot,” said Ram Varadarajan, CEO at Activio. “Because indirect prompt injection bypasses traditional defenses, requiring no credentials or user interaction, it allows attackers to silently exfiltrate sensitive operational telemetry.” Tricking Grafana AI into leaking sensitive data GrafanaGhost is essentially not a single bug but a chained exploit that combines multiple bypasses across application logic and AI guardrails. The attack begins with identifying an injection point, locations where user-controlled input can be stored and later processed by Grafana’s AI components. Noma researchers found that crafted paths embedded with indirect prompts could persist in the system and later be interpreted as legitimate inputs. From there, attackers use indirect prompt injection techniques to manipulate the AI into executing malicious instructions. The model is tricked into generating requests that include sensitive data while interpreting the instructions as benign. In a disclosure, Noma said that the key technical breakthrough came from bypassing client-side protections designed to block external image loading. By exploiting a flaw in URL validation, specifically using protocol-relative URLs like //attacker.com, the system mistakenly treats malicious external resources as safe, allowing outbound requests to the attacker’s infrastructure. Finally, the attack evades AI guardrails themselves by inserting specific keywords, such as INTENT, into prompts to convince the model that the request was legitimate. Once processed, the system attempts to render an image, embedding sensitive data into the request sent to the attacker’s server. The chain effectively enables automated, zero-click data exfiltration that blends into the normal dashboard workflow. Varadrajan pointed this out, saying attackers exploit the blind spot “using system components exactly as designed, but with instructions the model cannot verify as malicious.” Real risk or overhyped edge case? Not everyone is convinced the finding represents a newfound threat. Bradley Smith, SVP and deputy CISO at BeyondTrust, described the underlying technique as “well documented,” noting that indirect prompt injection leading to data exfiltration is a known risk across AI-enabled platforms. “This seems like mostly hype to me,” Smith said, adding that “what’s less clear here is the practical exploitability against a hardened Grafana deployment with standard enterprise network controls.” Still, Smith acknowledged the broader implications. “This isn’t a universal bypass of Grafana,” he said. “It’s a demonstration of what can happen when AI components process untrusted input without sufficient architectural controls.” Identifying exposure to GrafanaGhost by checking whether Grafana AI/LLM features are enabled, patching to the latest version, restricting “img-src” to known domains, and applying egress controls can help defend against exposure, he added. View the full article

Microsoft has warned that Storm-1175, a cybercrime group linked to Medusa ransomware, is exploiting vulnerable web-facing systems in fast-moving attacks, at times moving from initial access to data theft and ransomware deployment within 24 hours. The company said the group has heavily targeted organizations in healthcare, education, professional services, and finance across Australia, the UK, and the US, showing how quickly ransomware affiliates can exploit exposed perimeter systems before defenders patch or even spot the breach. Microsoft also said Storm-1175 has, in some cases, used zero-day flaws before they were publicly disclosed. “While the threat actor typically uses N-day vulnerabilities, we have also observed Storm-1175 leveraging zero-day exploits, in some cases a full week before public vulnerability disclosure,” Microsoft said in a blog post. “The threat actor has also been observed chaining together multiple exploits to enable post-compromise activity.” Microsoft said the group has exploited more than 16 vulnerabilities across widely used enterprise products since 2023 and, in several cases, chained exploits to establish persistence, steal credentials, tamper with security tools, and speed ransomware deployment. “What we’re seeing here is the death of the traditional ‘dwell time’ narrative,” said Sakshi Grover, senior research manager for security services at IDC Asia Pacific. “This is no longer about attackers sitting quietly in the network. It is about speed and disciplined execution. Storm-1175 is operating like a well-oiled pipeline. Initial access, escalation, lateral movement, exfiltration, and ransomware deployment, all compressed into a day. Most enterprises are simply not built for that pace.” Grover said the bigger weakness for many organizations is not detection but response. She said many companies still take too long to isolate affected systems and revoke access, which gives attackers more time to move through networks before teams can contain them. Cybersecurity analyst Sunil Varkey said the shift to faster ransomware operations means traditional detection-and-response models that assume multi-day or week-long dwell times are no longer sufficient, especially when companies remain slow to patch internet-exposed assets and contain lateral movement after initial access. “The most effective response is a proactive strategy centered on aggressive attack surface reduction, prioritizing rapid remediation of vulnerabilities and misconfigurations on all web-facing and critical systems, combined with strong network segmentation and isolation,” Varkey said. Where enterprises lag Many enterprises still lack a real-time view of what is exposed to the internet, said Sanchit Vir Gogia, chief analyst at Greyhound Research. He called this a basic weakness in how companies manage cyber risk. “The way attack surface management is run today still reflects an older mindset,” Gogia said. “Discover assets, scan them, prioritize issues, schedule fixes. It is orderly and logical, but not fast enough. Environments are changing all the time. Systems are spun up for projects, opened to the internet for convenience, and then left behind. Over time, these become invisible to central teams, even though they remain visible to attackers.” Gogia said the problem is compounded by fragmented ownership. Internet-facing systems often cut across different teams, blurring accountability and slowing the response when risks emerge. Storm-1175 appears to be exploiting exactly that gap. Its rapid shifts between vulnerabilities and use of chained exploits suggest attackers are taking advantage of enterprises that lack an up-to-date view of their external exposure. Keith Prabhu, founder and CEO of Confidis, said the widespread use of open-source libraries and other components that need constant tracking and patching makes the job even harder. “A smart attacker like Storm-1175 can quickly fingerprint such systems and develop custom attacks chaining multiple exploits,” Prabhu said. “Efficient patch management of this complex technology stack is the biggest weakness in enterprise attack surface management today, especially for internet-exposed systems.” View the full article

For many years, supply chain security was viewed purely as a technical concern. However, with high-profile vulnerabilities and regulations, it is now a board-level issue that requires organizations to rethink how to build resiliency and insulate their operations. The changing regulatory landscape has been a key driver of the C-suite’s focus, as legislation such as the European Cyber Resilience Act (CRA) includes fines of up to 2.5% of global turnover for non-compliance. Additionally, the proliferation of open-source software, coupled with complex global supply chains, has created a perfect storm transforming how CSOs must approach supply chain security. The pervasiveness of open-source software has upended the security landscape. According to Synopsys’ 2025 Open Source Security and Risk Analysis report, 97% of commercial applications contain open-source software, with 86% containing vulnerabilities, 81% of which are categorized as high- or critical-risk. Five years ago, statistics like this were foreign to corporate boards but now they’re the data behind imperatives. The Log4Shell vulnerability in 2021 highlighted the problem. A critical flaw in the open-source Apache Log4j 2 Java library enabled attackers to execute code remotely, affecting millions of applications, cloud services and physical endpoints, including servers. Hackers exploited the vulnerability to steal data, install ransomware and capture devices for botnets with breathtaking speed. This dispelled the assumption that open source was secure, as the situation highlighted the interconnected nature of software ecosystems and the speed at which exploitation of a single vulnerability can spread. If, like me, you were responsible for any products when Log4Shell happened, you can feel my pain. It felt a lot like Y2K but without the advance warning. And who else suddenly wondered if they needed to shut off their corporate website? Why supply chain security became a C-suite priority Legislative changes have elevated security from a technical issue to a business issue. The CRA views software security as a product safety concern, and penalties reflect this reality. Federal legislation, including EO14028, requires agencies to maintain complete software and hardware inventories and develop assurance policies. Similar regulations are underway or have been finalized in countries including India and South Korea. One example of industry regulatory focus is the FDA requiring medical devices to have software bills of materials (SBOMs), recognizing that software security directly impacts patient safety. Before the FDA SBOM requirement, a vulnerability was discovered in an FDA-approved cardiac monitor. This device would never have made it to market without remediation if an SBOM had been provided and cross-referenced with vulnerability databases. The challenge for CSOs is that managing supply chain security is fundamentally different from traditional security. If a supplier’s code causes a breach, indemnity clauses may mean they pay the fine, but you remain responsible for customer notification, reputational damage and the operational burden of response. You must manage these risks across all of your customers, who are now asking detailed questions about your supply chain security posture before they sign contracts. The hidden complexity that drowns security teams SBOMs are no longer used solely to track software licensing; they are key to managing supply chain security as they enable the identification and tracking of vulnerabilities across ecosystems. Finding a problem is just the start — you need to determine if the vulnerability affects your implementation. For example, if an SSL library contains 100 functions and your application uses 60 of them, and the flaw is in one of the unused 40, there is no risk. However, traditional scanning tools may flag it as critical, and your team will waste time investigating a non-issue. To put this in perspective, Cornell found that code vulnerability tools have a 97.5% false-positive rate. Anyone who has spent any time in cybersecurity knows that false positives are the bane of our existence, whether you’re looking at firewall alerts or EDR or library vulnerability correlation. It’s important to note that even if there is no risk, you still need to publish that information so that your customers are aware that you have validated that you are not vulnerable. This uses significant resources, with developers spending 3.5 hours per week manually reviewing security scan findings due to false positives. This delays new features and slows market entry. Security teams lose credibility, developers become desensitized and dismiss alerts as noise and real threats can get lost. Alert fatigue is a real thing. Due to the complexity and different development environments involved, there is no panacea for strengthening your supply chain security posture. Source code analysis works well when you have access to code and build processes, but it can’t review third-party binaries or legacy firmware and often can’t identify which code branches will be compiled into the final binary. Build-time analysis identifies issues during compilation, but it doesn’t work on components added later and often stumbles with dynamically linked libraries. Binary and firmware analysis addresses these gaps but requires sophisticated tooling to reverse-engineer compiled code. The right solution depends on your specific environment and must account for the types of products you build, how the development pipeline operates and whether you work more with source code or third-party components. There is never a one-size-fits-all solution; companies must evaluate various tools to find the right fit for their situation. Workflow integration, supply chain complexity and deployment platforms such as rich OS vs. bare metal all impact tool applicability. What CSOs should demand from their tools and processes Conducting a bake-off with at least three solutions is vital to finding the right option. It’s essential to test against your code to validate accuracy, rather than relying on samples from the vendor. The goal is to understand how each potential option performs in your environment. One aspect to consider is where the software or firmware will run — is it on Windows, Linux, Android or another rich OS? Or is it bare metal as is often seen in space-constrained or industrial environments? There aren’t many firmware analysis tools available for the latter, so those environments may lean toward source- or build-based tools even though binary analysis solutions are often better for rich OS firmware. As you review, focus on the accuracy of identifying vulnerabilities and the false-positive rate. A tool may catch every vulnerability, but if it flags too many phantom issues, your team will waste countless hours on wild goose chases. Conversely, if it fails to identify critical vulnerabilities, your organization remains exposed. Additionally, the product must integrate with existing ticketing systems, such as Jira. Automation is non-negotiable, as manual dashboard checks are not viable given the complexity and risk involved. Tasks should be prioritized so developers don’t have to hunt for information. When a vulnerability is found, it should automatically create tickets in your developers’ existing workflow outlining what’s at risk, where it’s used, whether it’s exploitable in your implementation and the required action. The goal is to make responding to supply chain vulnerabilities as seamless as fixing any other bug. If developers need to switch between different tools or manually correlate information, response times will slow, increasing risk. Supply chain communication capabilities are another vital component to mitigate risk and meet regulatory requirements. The solution must be able to receive automated updates from upstream suppliers and rapidly notify downstream customers. In addition to alerting, the communication should include the required mitigation steps. You need to quickly confirm that a library has been patched or that the vulnerability has been determined to be unreachable or not exploitable. Documentation is another important evaluation criterion. Contractual and regulatory obligations necessitate real-time information sharing. If a zero-day attack happens, documented best practices protect you from fines. Customers should be informed immediately, not days or weeks later, with the required mitigation steps they need to take. Having survived the ordeal of shipping a product with an encryption library that was discovered to be vulnerable, I can promise you that customer inquiries will come in faster than you can answer them and they will become more strident by the minute. Your supply chain security infrastructure must be able to identify which customers are impacted and what they need to do to protect themselves. A thorough audit trail showing the steps taken to address flaws can help you avoid punitive fines. The CRA is more forgiving when you can prove you kept software current, followed deployment guidelines, evaluated tools, chose approaches appropriate to your environment and responded promptly. The goal is to demonstrate responsible software security stewardship, as even the most stringent regulatory bodies know that there will always be software bugs. The path forward Supply chain security will only intensify. The FDA couldn’t define what an SBOM was 18 months ago; now it’s mandatory for medical device approval. Similar regulations are emerging across industries and jurisdictions as software supply chains become recognized as critical to product security and safety. CSOs must treat this as a strategic priority that impacts the bottom line, rather than a security checkbox. Executives who recognize the risks and act accordingly will position their organizations not just for compliance but for competitive advantage in an increasingly security-conscious market. Those who delay will find themselves managing crises, facing regulatory penalties and losing customer trust. The question is no longer whether to prioritize supply chain security, but how quickly you can build the capabilities to do it well. View the full article

For many years, supply chain security was viewed purely as a technical concern. However, with high-profile vulnerabilities and regulations, it is now a board-level issue that requires organizations to rethink how to build resiliency and insulate their operations. The changing regulatory landscape has been a key driver of the C-suite’s focus, as legislation such as the European Cyber Resilience Act (CRA) includes fines of up to 2.5% of global turnover for non-compliance. Additionally, the proliferation of open-source software, coupled with complex global supply chains, has created a perfect storm transforming how CSOs must approach supply chain security. The pervasiveness of open-source software has upended the security landscape. According to Synopsys’ 2025 Open Source Security and Risk Analysis report, 97% of commercial applications contain open-source software, with 86% containing vulnerabilities, 81% of which are categorized as high- or critical-risk. Five years ago, statistics like this were foreign to corporate boards but now they’re the data behind imperatives. The Log4Shell vulnerability in 2021 highlighted the problem. A critical flaw in the open-source Apache Log4j 2 Java library enabled attackers to execute code remotely, affecting millions of applications, cloud services and physical endpoints, including servers. Hackers exploited the vulnerability to steal data, install ransomware and capture devices for botnets with breathtaking speed. This dispelled the assumption that open source was secure, as the situation highlighted the interconnected nature of software ecosystems and the speed at which exploitation of a single vulnerability can spread. If, like me, you were responsible for any products when Log4Shell happened, you can feel my pain. It felt a lot like Y2K but without the advance warning. And who else suddenly wondered if they needed to shut off their corporate website? Why supply chain security became a C-suite priority Legislative changes have elevated security from a technical issue to a business issue. The CRA views software security as a product safety concern, and penalties reflect this reality. Federal legislation, including EO14028, requires agencies to maintain complete software and hardware inventories and develop assurance policies. Similar regulations are underway or have been finalized in countries including India and South Korea. One example of industry regulatory focus is the FDA requiring medical devices to have software bills of materials (SBOMs), recognizing that software security directly impacts patient safety. Before the FDA SBOM requirement, a vulnerability was discovered in an FDA-approved cardiac monitor. This device would never have made it to market without remediation if an SBOM had been provided and cross-referenced with vulnerability databases. The challenge for CSOs is that managing supply chain security is fundamentally different from traditional security. If a supplier’s code causes a breach, indemnity clauses may mean they pay the fine, but you remain responsible for customer notification, reputational damage and the operational burden of response. You must manage these risks across all of your customers, who are now asking detailed questions about your supply chain security posture before they sign contracts. The hidden complexity that drowns security teams SBOMs are no longer used solely to track software licensing; they are key to managing supply chain security as they enable the identification and tracking of vulnerabilities across ecosystems. Finding a problem is just the start — you need to determine if the vulnerability affects your implementation. For example, if an SSL library contains 100 functions and your application uses 60 of them, and the flaw is in one of the unused 40, there is no risk. However, traditional scanning tools may flag it as critical, and your team will waste time investigating a non-issue. To put this in perspective, Cornell found that code vulnerability tools have a 97.5% false-positive rate. Anyone who has spent any time in cybersecurity knows that false positives are the bane of our existence, whether you’re looking at firewall alerts or EDR or library vulnerability correlation. It’s important to note that even if there is no risk, you still need to publish that information so that your customers are aware that you have validated that you are not vulnerable. This uses significant resources, with developers spending 3.5 hours per week manually reviewing security scan findings due to false positives. This delays new features and slows market entry. Security teams lose credibility, developers become desensitized and dismiss alerts as noise and real threats can get lost. Alert fatigue is a real thing. Due to the complexity and different development environments involved, there is no panacea for strengthening your supply chain security posture. Source code analysis works well when you have access to code and build processes, but it can’t review third-party binaries or legacy firmware and often can’t identify which code branches will be compiled into the final binary. Build-time analysis identifies issues during compilation, but it doesn’t work on components added later and often stumbles with dynamically linked libraries. Binary and firmware analysis addresses these gaps but requires sophisticated tooling to reverse-engineer compiled code. The right solution depends on your specific environment and must account for the types of products you build, how the development pipeline operates and whether you work more with source code or third-party components. There is never a one-size-fits-all solution; companies must evaluate various tools to find the right fit for their situation. Workflow integration, supply chain complexity and deployment platforms such as rich OS vs. bare metal all impact tool applicability. What CSOs should demand from their tools and processes Conducting a bake-off with at least three solutions is vital to finding the right option. It’s essential to test against your code to validate accuracy, rather than relying on samples from the vendor. The goal is to understand how each potential option performs in your environment. One aspect to consider is where the software or firmware will run — is it on Windows, Linux, Android or another rich OS? Or is it bare metal as is often seen in space-constrained or industrial environments? There aren’t many firmware analysis tools available for the latter, so those environments may lean toward source- or build-based tools even though binary analysis solutions are often better for rich OS firmware. As you review, focus on the accuracy of identifying vulnerabilities and the false-positive rate. A tool may catch every vulnerability, but if it flags too many phantom issues, your team will waste countless hours on wild goose chases. Conversely, if it fails to identify critical vulnerabilities, your organization remains exposed. Additionally, the product must integrate with existing ticketing systems, such as Jira. Automation is non-negotiable, as manual dashboard checks are not viable given the complexity and risk involved. Tasks should be prioritized so developers don’t have to hunt for information. When a vulnerability is found, it should automatically create tickets in your developers’ existing workflow outlining what’s at risk, where it’s used, whether it’s exploitable in your implementation and the required action. The goal is to make responding to supply chain vulnerabilities as seamless as fixing any other bug. If developers need to switch between different tools or manually correlate information, response times will slow, increasing risk. Supply chain communication capabilities are another vital component to mitigate risk and meet regulatory requirements. The solution must be able to receive automated updates from upstream suppliers and rapidly notify downstream customers. In addition to alerting, the communication should include the required mitigation steps. You need to quickly confirm that a library has been patched or that the vulnerability has been determined to be unreachable or not exploitable. Documentation is another important evaluation criterion. Contractual and regulatory obligations necessitate real-time information sharing. If a zero-day attack happens, documented best practices protect you from fines. Customers should be informed immediately, not days or weeks later, with the required mitigation steps they need to take. Having survived the ordeal of shipping a product with an encryption library that was discovered to be vulnerable, I can promise you that customer inquiries will come in faster than you can answer them and they will become more strident by the minute. Your supply chain security infrastructure must be able to identify which customers are impacted and what they need to do to protect themselves. A thorough audit trail showing the steps taken to address flaws can help you avoid punitive fines. The CRA is more forgiving when you can prove you kept software current, followed deployment guidelines, evaluated tools, chose approaches appropriate to your environment and responded promptly. The goal is to demonstrate responsible software security stewardship, as even the most stringent regulatory bodies know that there will always be software bugs. The path forward Supply chain security will only intensify. The FDA couldn’t define what an SBOM was 18 months ago; now it’s mandatory for medical device approval. Similar regulations are emerging across industries and jurisdictions as software supply chains become recognized as critical to product security and safety. CSOs must treat this as a strategic priority that impacts the bottom line, rather than a security checkbox. Executives who recognize the risks and act accordingly will position their organizations not just for compliance but for competitive advantage in an increasingly security-conscious market. Those who delay will find themselves managing crises, facing regulatory penalties and losing customer trust. The question is no longer whether to prioritize supply chain security, but how quickly you can build the capabilities to do it well. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article