CSOonline

European regulators have largely been frozen out of early access to Anthropic’s new Mythos model, Politico reports. The AI technology, aimed at cybersecurity use cases, is said to be able to identify and exploit technical vulnerabilities at a level that surpasses most humans — signaling a structural shift for CISOs and the cybersecurity industry. For security reasons, Anthropic has chosen to initially limit access to a few selected players as part of Project Glasswing. These include primarily US technology giants such as Apple, Microsoft, and Amazon, who have been given the opportunity to analyze the model and address potential security flaws. At the same time, European authorities have been largely left out. In the UK, the country’s AI Security Institute has been allowed to test the model and has already acted on its results. Within the EU, only Germany is currently reported to have initiated a dialogue with Anthropic, but without yet gaining access to the technology. As a result, the EU’s influence over the model is limited, not least because it is not yet widely available. Several experts interviewed by Politico believe that this development is problematic, as private companies in practice decide how and when such powerful technology is shared, rather than independent authorities. Germany’s chief cybersecurity official Claudia Plattner underscored to Politico the “pressing” question of whether a tool like Mythos “of such extraordinary power” will be available on the open market. “That question, in turn, has profound implications for national and European security and sovereignty,” Plattner said. View the full article

Artificial intelligence is rapidly reshaping how security teams detect and hunt cyber threats by helping analyze vast volumes of security data, uncovering subtle signs of malicious activity, and identifying potential attacks faster than traditional tools or human analysts alone. Analyst firm Gartner expects that by 2028, 50% of threat detection, investigation, and response (TDIR) platforms — including technologies such as EDR, XDR, SIEM, and SOAR — will incorporate agentic AI capabilities, up from less than 10% in 2024. The firm says AI could help organizations strengthen threat detection, incident response, and containment while also helping security teams bridge persistent skills shortages and reduce reliance on scarce cybersecurity talent. A matter of scale Much of AI’s impact in threat detection is tied to its ability to process telemetry at a scale that human teams would find challenging, if not impossible, to manage, according to security experts. Modern IT environments can generate billions of logs and events each day across endpoints, networks, cloud services, and identity systems. Machine learning models can correlate those signals in near real-time, and identify behavioral anomalies — such as unusual login patterns, suspicious lateral movement, or data exfiltration attempts — that might otherwise remain buried in the noise. Many enterprise security teams expect such capabilities to significantly bolster their detection capabilities. In a 2025 survey that Anvilogic conducted in collaboration with the SANS Institute, 45% of respondents said their organizations have already integrated AI into their threat detection workflows; 88% believed AI would play a major role in detection engineering within the next three years. Organizations are already using AI to automate many of the routine tasks traditionally handled by Tier 1 and Tier 2 analysts, says Martin Sordilla, senior technology and security architect at Accenture. Much of this work involves reviewing logs, triaging alerts, identifying indicators of compromise, correlating events, and reaching out to system owners during investigations. AI can significantly accelerate these processes — automating tasks such as alert triage, documentation, evidence collection, and chain-of-custody tracking, he adds. Organizations are already seeing efficiency gains of roughly 40-50% for lower-tier SOC tasks, freeing human analysts to focus on more advanced investigations and response activities, Sordilla says. Reducing alert fatigue In alert triage, AI agents are reducing alert fatigue by clustering alert patterns and enabling risk-based prioritization, adds Dipto Chakravarty, chief product and technology officer at Black Duck. For example, natural language processing agents can summarize threat alerts at scale and correlate them with threat intel feeds such as CVE.org and the CISA KEV Catalog, he says. “The general incident response workflow is one of the beneficiaries of AI agents where we are seeing the value of automated playbooks for common incidents,” he notes. AI agents are also playing a role in enriching threat intelligence at scale by ingesting and correlating threat intel from myriad sources and consequently enriching these alerts with value-added context such as CVE data. “AI agents today can effectively accelerate derivation of insights from organized and normalized datasets,” by allowing analysts to ask questions in natural language, says Nicole Bucala, CEO at Databee. They eliminate the need for the specialized queries, analytical dashboards, or manual analysis typically required for the task. Instead of flooding analysts with thousands of low-confidence warnings, AI-enabled detection platforms can score and correlate alerts, group related activity into higher-fidelity incidents, and filter out routine or benign behavior. The result, vendors and analysts say, is a reduction in alert fatigue and a shift in analyst workflows away from manual triage toward deeper investigation and response. “AI is helping SOCs escape ‘activity theater’ by turning raw noise into faster, higher-confidence decisions backed by evidence,” says Craig Jones, chief security officer at Ontinue. SOC burnout is a real concern, Jones notes. The biggest drivers of this in the industry are alert volume, fragmentation, and ambiguity, and those pressures exist for any team operating at scale. Analysts, he says, often end up spending too much of their day working high-alert loads that are low signal and then having to context-switch across multiple tools just to assemble the basics of an investigation. Containing threats sooner The real win with AI isn’t processing more alerts or closing more tickets; it’s about containing real threats sooner, with fewer mistakes, Jones says. “When AI is used to correlate weak signals into coherent incidents, enrich investigations automatically, and recommend safe next actions inside clear guardrails, you stop measuring effort and start proving outcomes,” he explains. Security experts expect AI to change the skills needed in security teams. Rather than eliminating jobs, it will help security teams automate routine tasks and shift roles toward engineering and system design, Accenture’s Sordilla says. The traditional SOC analyst role — focused heavily on manual log review — is likely to evolve into security engineering roles focused on building resilient systems, automation pipelines, and AI-assisted defenses. Early data shows organizations that have deployed AI for detection engineering are seeing some measurable gains. In a Google study of 3,466 senior leaders, nearly seven in ten (67%) early adopters of agentic AI reported seeing it having a positive impact on their security posture. Of this group, 85% reported described AI as having improved their ability to identify threats. Early adopters of AI, Google noted, are seeing quantifiable benefits not just in terms of efficiency, but also in terms of efficacy. At the same time, experts caution that AI-driven detection is not a silver bullet. Adversaries are increasingly experimenting with AI themselves — using it to generate more convincing phishing campaigns, automate reconnaissance, or modify malware to evade signature-based defenses. That dynamic is pushing defenders to treat AI not simply as another security tool, but as part of a broader evolution in security operations where human expertise, threat intelligence, and machine learning must work together. “Cyberattacks have been industrialized at machine speed,” says Ram Varadarajan, CEO at Acalvio “We need to respond in kind.” That means implementing defensive AI that can handle high-volume technical tasks such as triaging phishing emails, analyzing massive network logs for behavioral anomalies, deploying AI-aware cyber deception, and autonomously quarantining compromised endpoints to prevent lateral movement, he says. “When it’s a machine-speed AI attacker, no human will ever be able to keep up, and these complex AI attacks are going to be launched at scale,” he notes. Implementing AI correctly The key to getting the most value out of AI in threat detection is to ensure humans are involved. Any threat finding or resulting remediation action based on those insights, especially those involving nontrivial consequence for business operations, should remain under human oversight, at minimum, says Databee’s Bucala. “Human in the loop is the mantra,” she says. “There’s a lot of business risk that can be incurred through full automation unless the margin of error in machine made decisions is close to zero.” While AI shows promise in threat detection, it still needs refinement. The best practice for organizations is to establish a process that includes human validation, and humans who have the right attention to detail and context to spot check AI summary results and decisions, Bucala notes. AI, adds Accenture’s Sordilla, is not a substitute for basic security hygiene. If an organization already has weak security practices, AI may simply accelerate existing problems. So, companies should first ensure they have strong governance, clear security standards, and mature processes — such as those outlined in frameworks from NIST and International Organization for Standardization — before layering AI into their security programs. “AI is force multiplier,” Sordilla says. “If your company is heading in the wrong direction, you are going down the drain faster,” by deploying AI incorrectly, he cautions. View the full article

AI is no longer a speculative topic for security leaders. It has moved from experimentation to implementation, and increasingly, to measurable production impact. Over the past year, my conversations with CISOs have shifted. The question is no longer whether AI belongs in cybersecurity; it’s about deploying it responsibly, strategically and at scale. For security leaders, this is not simply a technology decision. It is an operating model decision. Organizations that treat AI as another layer added to existing workflows may see incremental efficiency gains. Those that treat it as an inflection point in how security operations conduct investigative work can fundamentally reshape their defensive posture. From these CISO conversations, several realities are emerging that security leaders should confront directly. The threat has accelerated beyond human scale Recent threat intelligence underscores the urgency. CrowdStrike’s 2026 Global Threat Report found an 89% year-over-year increase in AI-enabled adversary activity. More concerning than volume is velocity. The average eCrime breakout time — the interval between initial compromise and lateral movement — dropped to 29 minutes, with the fastest observed breakout occurring in 27 seconds. In one documented intrusion, an attacker gained access, moved laterally and began data exfiltration within four minutes. These timelines compress the window for detection and response to a degree that challenges human-only workflows. Manual triage and sequential investigation processes struggle to keep pace with machine-speed attacks. This is a material shift in tempo, and it requires a corresponding shift in defensive capability. The questions have matured The AI discussion in security has evolved in phases. First came skepticism from security leaders, asking whether AI actually works in security operations. Given years of overpromised technology, the caution was warranted. Experimentation followed, with questions centering on what types of work AI should handle and where it introduces risk. Now, the dominant questions are more operational: How do we deploy AI into production SOC workflows? How do we implement it quickly without disrupting already strained teams? What should our analysts focus on once AI absorbs repetitive tasks? These go beyond theoretical considerations and reflect a recognition that AI has crossed from possibility to implementation. The cyber AI parity window Historically, offensive cyber capabilities have benefited from asymmetry. Nation-state actors often developed and deployed advanced capabilities years before defenders became aware of them. By the time tools were exposed or leaked, adversaries had already compounded their advantage. AI represents a break from that pattern. The same foundational AI advancements powering offensive capabilities are also enabling a new generation of defensive tools. Unlike prior technological shifts, AI was not restricted to classified environments for years before becoming commercially available. It emerged publicly and broadly. For the first time, defenders and adversaries gained access to a transformative technology at roughly the same moment. This creates what I call the Cyber AI Parity Window — a limited period during which defenders are not structurally behind in technological capability. Parity, however, is not the same as advantage. Advantage accrues to those who operationalize AI most effectively and most quickly. This window will not remain open indefinitely. Architecture determines scalability Early enthusiasm around large language models led some to assume that a single, powerful AI system could manage security investigations end to end. Production deployments revealed the limits of that approach. Security investigations are rarely linear. They involve contextual interpretation, cross-tool correlation, iterative reasoning and validation. Single-agent systems often struggle to sustain accuracy under these conditions. More effective deployments rely on coordinated, multi-agent architectures. Specialized agents handle enrichment, reasoning, validation and response orchestration, dynamically adapting to alert type and environment. While this architecture is more complex, it has proven more reliable at scale. For CISOs, architectural transparency should be a priority. Understanding how systems reason, manage ambiguity and maintain accuracy under load is essential. In security operations, reliability is a requirement, not a feature. Context is the control plane Another consistent lesson from early deployments is that AI performance is inseparable from contextual depth. Generic AI models cannot accurately investigate security events without understanding the environment they are protecting. Network architecture, identity models, detection logic, asset criticality and business workflows all shape investigative conclusions. As organizations assign greater responsibility to autonomous systems, contextual misalignment can introduce risk rather than reduce it. Successful implementations treat context as infrastructure. AI systems are deeply integrated with telemetry sources and workflows. Data pipelines are structured deliberately. Environmental fidelity is treated as foundational. AI only amplifies the importance of understanding your environment. From execution to management Public discourse often frames AI in terms of job displacement. Within security organizations, the more relevant discussion is about redefining roles. Security teams face persistent growth in alerts and talent shortages. Analysts spend significant time on repetitive investigations that require diligence but not necessarily strategic judgment. AI creates an opportunity to shift human contribution from execution to management. Rather than manually triaging alerts, analysts can define investigative logic. Instead of performing routine enrichment tasks, they can determine escalation thresholds. Instead of executing playbooks, they can design and refine them. This mirrors transitions seen in other industries as automation matured: human value moves upstream, toward oversight, design and improvement. In organizations that implement this shift thoughtfully, teams report not only reduced backlog but also improved engagement. Analysts work on more complex problems and develop more strategic capabilities. The central question, therefore, is whether AI elevates the way expertise is applied, not whether it reduces headcount. The window requires action Defenders possess structural advantages that attackers do not. Large technology providers process trillions of security signals daily. Empirical research, including IBM’s Cost of a Data Breach Report, shows that organizations extensively using AI and automation experience lower breach costs and faster containment times. But structural advantage compounds only with execution. Every month that security operations remain dependent on manual triage is a month in which AI-enabled adversaries continue to optimize their workflows. The acceleration in breakout times does not pause for budget cycles or extended vendor evaluations. The Cyber AI Parity Window represents a rare strategic opportunity. For once, defenders are not reacting to a capability that adversaries monopolized for years. The question is whether organizations will capitalize on that parity before it narrows. Production metrics over vision Security leaders today evaluate AI platforms with appropriate rigor. Claims of transformative capability are insufficient. Several standard operational metrics matter: Investigations completed autonomously Average investigation time False positive and false negative rates Percentage of cases requiring human override Time to deployment and value realization AI must demonstrate measurable performance in production environments. Trust is built through documented outcomes, not conceptual promise. Leadership in the AI production era AI in cybersecurity represents a structural shift in how investigative work is conducted and how human expertise is applied. CISOs now face a consequential choice: layer AI incrementally onto existing workflows or integrate it as a foundational component of security operations. Organizations that succeed will demand measurable production outcomes, invest in contextual integration, evaluate architectural robustness, redesign workflows to elevate human expertise and act before the Cyber AI Parity Window closes. The industry has moved beyond experimentation. AI is operating in production. Adversaries are leveraging it at machine speed. The inflection point has arrived. What follows depends on execution. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Mdisk – shutterstock.com Hybride Attacken auf kritische Infrastruktur in Deutschland und Bundeswehr-Truppen im Ausland nehmen weiter zu. Spätestens seit 2022 sei ein spürbarer Zuwachs zu verzeichnen, sagte der Bundeswehr-Inspekteur Cyber- und Informationsraum, Vizeadmiral Thomas Daum, bei einem Pressetermin bei der Nato-Cyberabwehrübung «Locked Shields» im niederrheinischen Kalkar. Cyber-Angriffe gegen die Bundeswehr richteten sich gegen Rechenzentren in Deutschland oder gegen Truppen im Ausland – etwa in Litauen, wo Stationierte den Eindruck haben, dass sie am Telefon abgehört werden. In Litauen seien auch Desinformationskampagnen gestartet worden – zum Beispiel mit der falschen Behauptung, dass der Kontingentführer am Wochenende in Moskau gewesen wäre, um sich mit Freunden zu treffen. Größte Übung zur Cybersicherheit Datenschützer registrieren seit Jahren Drohnen-Sichtungen und Ausspähversuche, Eindringversuche in Kasernen, die Beschädigung von Datenkabeln und Versorgungsleitungen in der Ostsee sowie Störungen des GPS-Systems. Die mutmaßlichen Hauptverursacher säßen in Russland, China, Iran und Nordkorea, sagte ein Bundeswehrsprecher in Kalkar. Die Cybertruppe der Bundeswehr beteiligt sich mit rund 40 anderen Nationen an «Locked Shields». Die Unternehmung wird aktuell als weltweit größte und komplexeste multinationale Übung der Nato zur Cybersicherheit bezeichnet. Es werden Echtzeitangriffe eines «Teams Rot» simuliert, die von einem «Team Blau» abgewehrt werden müssen. Aus Deutschland sind auch Polizei- und Sicherheitsbehörden und zivile IT-Fachleute etwa von der Telekom beteiligt. Energieversorger, Banken – und das Einwohnermeldeamt? Zur kritischen Infrastruktur zählen in Deutschland große Energieversorger, Banken und IT-Dienstleister – nach Schätzungen mehr als 29.000 Unternehmen. In den Fokus könnten aber auch Behörden geraten, sagte ein Bundeswehrsprecher. Russland habe beispielsweise kurz vor dem Angriff auf die Ukraine die dortigen Einwohnermeldeämter attackiert, um deren Daten zu löschen und so eine Mobilisierung der Bevölkerung zu erschweren. Die Ukraine habe die Daten aber rechtzeitig gesichert. (dpa/ad) View the full article

Over the past week, reaction to Anthropic’s Glasswing disclosure has split along familiar lines. At one end: alarm over an AI system capable of autonomously identifying and exploiting vulnerabilities. At the other: dismissive hot takes, arguing there is nothing new here. A more grounded view comes from a new briefing by the Cloud Security Alliance (CSA), led by Gadi Evron, CEO of Knostic and CISO-in-Residence for AI at the alliance; Rob T. Lee, chief AI officer and chief of research at SANS Institute; and Rich Mogull, chief analyst at CSA. The paper draws on a deep bench of contributors, including former CISA Director Jen Easterly, Bruce Schneier, former National Cyber Director Chris Inglis, and former Google CISO Phil Venables, along with dozens of CISOs and CEOs. Evron told CSO that assembling that level of input among so many leaders so quickly reflects the nature of cybersecurity itself: “The cybersecurity industry is also a community, and knowing each other, all folks need to have is a good cause, and dispelling noise and spreading good information matters to us.” The group’s conclusion is direct: Glasswing is not an outlier. It is an early example of a capability that will scale, and CISOs should start getting ready for this era. “In the near term, security organizations will likely be overwhelmed by the need to apply patches and respond to AI-discovered vulnerabilities, exploits, and autonomous attacks,” the paper states. “The storm of vulnerability disclosures from Project Glasswing is the first of many large waves.” The shift is speed AI-driven vulnerability discovery is not new. What has changed is speed. Tasks that once took weeks or months — finding a flaw, building an exploit, chaining it into an attack — can now happen in hours. According to the paper, “Anthropic’s Claude Mythos (Preview) represents a step change in that trajectory, autonomously finding thousands of critical vulnerabilities across every major operating system and browser, generating working exploits without human guidance, and empowering autonomous attack orchestration, all at a speed and scale that outpaces any prior capability.” This acceleration deepens a familiar asymmetry: Defenders must be right consistently, whereas attackers only need to succeed once. Moreover, “The window between discovery and weaponization has collapsed to hours. Attackers gain disproportionate benefit, and current patch cycles, response processes, and risk metrics were not built for this environment,” the paper states. “Building a ‘Mythos-ready’ security program is not about reacting to one model or announcement. It is about permanently closing the gap between how fast vulnerabilities are found and how fast your organization can respond.” Claude Mythos Preview is a step up A separate analysis from the UK’s AI Security Institute (AISI) evaluated Mythos Preview itself. The evaluations involved both capture-the-flag (CTF) challenges and more complex ranges designed to simulate multi-step attack scenarios, where the model outperformed other AI systems. Mythos Preview came out on top in a 32-step corporate network attack simulation spanning initial reconnaissance through to full network takeover, which the Institute estimates requires humans 20 hours to complete. AISI’s tests also showed that Mythos Preview is capable of autonomously attacking small, weakly defended enterprise systems once access is obtained. “Our testing shows that Mythos Preview can exploit systems with weak security posture, and more models with these capabilities will likely be developed,” AISI concluded. What CISOs should do now AISI’s recommendation to organizations is that they should strengthen fundamentals, including regular application of security updates, robust access controls, security configuration, and comprehensive logging. It advises, “Future frontier models will be more capable still, so investment now in cyber defence is vital. AI cyber capabilities are dual use; while they pose security challenges, they can also help deliver game-changing improvements in defence.” The CSA paper highlights three predictions for CISOs. Operationally: Expect a surge of patches from the approximate 40 vendors in the early access program, potentially mirroring recent periods where multiple supply chain incidents required response within a two-week window. Risk management: Business risk is shifting, requiring close engagement with stakeholders on risk planning and tolerance. The CISO’s ability to manage risk is becoming more constrained, with potential downstream effects on reporting and projections. Strategically: Conduct longer-term gap analysis and selectively overhaul key functions, including governance processes that enable faster technology onboarding and the deployment of AI-driven security controls. The report also elevates Mythos to a board-level issue, allowing CISOs to frame current capabilities and make the case for further investment. The bottom line, as the CSA paper concludes, is that “AI-based attacks represent a structural shift in how offense and defense work, and it will not change. The cost and capability floor to exploit discovery is dropping, the time between disclosure and weaponization is compressing toward zero, and capabilities that previously required nation-state resources are now becoming broadly accessible.” See also: “Cybersecurity in the age of instant software” View the full article

A critical pre-authentication remote code execution vulnerability in Marimo, an open-source Python notebook platform owned by AI cloud company CoreWeave, was exploited in the wild less than 10 hours after its public disclosure, according to the Sysdig Threat Research Team. The vulnerability, tracked as CVE-2026-39987 with a severity score of 9.3 out of 10, affects all Marimo versions before 0.23.0. It requires no login, no stolen credentials, and no complex exploit. An attacker only needs to send a single connection request to a specific endpoint on an exposed Marimo server to gain complete control of the system, the Sysdig team wrote in a blog post. The flaw allows an unauthenticated attacker to obtain a full interactive shell and execute arbitrary system commands on any exposed Marimo instance through a single connection, with no credentials required, the post said. “Marimo has a Pre-Auth RCE vulnerability,” the Marimo team wrote in its GitHub security advisory. “The terminal WebSocket endpoint /terminal/ws lacks authentication validation, allowing an unauthenticated attacker to obtain a full PTY shell and execute arbitrary system commands.” Marimo is a Python-based reactive notebook with roughly 20,000 stars on GitHub and was acquired by CoreWeave in October 2025. How the flaw works Marimo’s server includes a built-in terminal feature that lets users run commands directly from the browser. That terminal was accessible over the network without any authentication check, while other parts of the same server correctly required users to log in before connecting, the post said. “The terminal endpoint skips this check entirely, accepting connections from any unauthenticated user and granting a full interactive shell running with the privileges of the Marimo process,” the post added. In practical terms, anyone who could reach the server over the internet could walk straight into a live command shell, often with administrator-level access, without ever entering a password, the team at Sysdig said. Credentials stolen in under three minutes To track real-world exploitation, deployed honeypot servers running vulnerable Marimo instances across multiple cloud providers and observed the first exploitation attempt within 9 hours and 41 minutes of disclosure. No ready-made exploit tool existed at the time. The attacker had built one using only the advisory description, Sysdig researchers wrote. The attacker worked in stages across four sessions. A brief first session confirmed the vulnerability was exploitable. A second session involved manually browsing the server’s file system. By the third session, the attacker had located and read an environment file containing AWS access keys and other application credentials. The entire operation took under three minutes, the post said. “This is a complete credential theft operation executed in under 3 minutes,” the Sysdig team wrote. The attacker then returned over an hour later to re-check the same files. The behavior was consistent with a human operator working through a list of targets rather than an automated scanner, the post said. Part of a widening pattern The pace of exploitation aligns with a trend seen across AI and open-source tooling. A critical flaw in Langflow was weaponized within 20 hours of disclosure earlier this year, also tracked by Sysdig. The Marimo case cut that window roughly in half, with no public exploit code in circulation at the time. “Niche or less popular software is not safer software,” the Sysdig post said. Any internet-facing application with a published critical advisory is a target within hours of disclosure, regardless of its install base, it added. The Marimo case had no CVE number assigned at the time of the first attack, meaning organizations dependent on CVE-based scanning would not have flagged the advisory at all, Sysdig noted. The flaw also fits a pattern of critical RCE vulnerabilities in AI-adjacent developer tools — including MLflow, n8n, and Langflow — in which code-execution features built for convenience become dangerous when exposed to the internet without consistent authentication controls. What organizations should do Marimo released a patched version, 0.23.0, which closes the authentication gap in the terminal endpoint. Organizations running any earlier version should update immediately, Sysdig said. Teams that cannot update right away should block external access to Marimo servers using firewall rules or place them behind an authenticated proxy, the post said. Any instance that has been publicly reachable should be treated as potentially compromised. “Credentials stored on those servers, including cloud access keys and API tokens, should be rotated as a precaution,” Sysdig advised. CoreWeave did not immediately respond to a request for comment. View the full article

Security researchers are warning of a set of flaws affecting IBM WebSphere Liberty, a lightweight, modular Java application server, that can be chained into a full server compromise. The flaws, a total of seven, that led to the ultimate compromise of the server were initiated by a newly discovered pre-authentication issue in the platform’s SAML Web SSO component that enables low-privilege access. From there, the chain manipulates authentication, access control, and cryptographic protection to achieve full control. “The 7 flaws we reported to IBM create multiple pathways for attackers to move from network-level exposure or limited access to full server compromise,” Oligo Security researchers said in a blog post. The chain is basically a privilege-escalation path to a critical compromise, protections against which are now available as patches and configuration guidelines. Pre-auth RCE sets the tone The root flaw, also the most recently disclosed, is tracked as CVE-2026-1561, targeting the SAML Web SSO functionality and requires no authentication to exploit. In affected deployments, attackers can reach exposed SAML endpoints and supply crafted serialized payloads, ultimately achieving remote code execution (RCE). Specifically, the application attempts to validate a serialized cookie by appending a secret value, but fails to store the result of the “String.concat()” operation. In Java, this method is non-mutating, meaning the original string remains unchanged, making the integrity check useless. As a result, attackers can tamper with the SSO cookie and supply arbitrary serialized Java objects without triggering validation failures. Because the vulnerable endpoint processes this data before authentication, it opens up the pre-auth RCE vector. SSO endpoints are often internet-facing by design, researchers noted, turning the flaw into a remote entry point and making chaining with additional weaknesses possible. AdminCenter flaws allow further escalation Beyond initial access, the research outlined critical issues within WebSphere Liberty’s administrative controls. The AdminCenter component, designed to enforce role-based access, contains multiple flaws that allow low-privileged users to access sensitive files and secrets. One issue, tracked under CVE-2025-14915, enables “reader”-level users to retrieve critical server files such as authentication keys, which can then be used to forge tokens and impersonate higher privileged users. Another problem (CVE-2025-14917) lies in hardcoded passwords protecting token-signing LTPA keys, alongside encryption utilities that ship with static keys (CVE-2025-14923) across all modes. The rest of the chain includes an archive extraction flaw (CVE-2025-14914) that can be abused to write files outside intended directories, alongside insecure handling (CVE unassigned) of configuration data where sensitive entries, like credentials “in server.xml,” can be retrieved or reused once access is gained. The researchers detailed the full chain, noting that a low-privileged “reader” user can extract or recover admin credentials from exposed configuration data, or alternatively forge an admin token using decrypted LTPA keys, gaining full administrative access. From there, the archive extraction flaw allows arbitrary file writes via Zip Slip-style attack, ultimately leading to remote code execution. IBM did not immediately respond to CSO’s request for comments on the disclosed attack chain. Other than applying necessary patches, Oligo urged organizations to rotate any secrets ever generated using “SecurityUtility,” as default XOR and AES modes make them effectively reversible, and to move to custom encryption keys going forward. It also recommended using auditing and limiting reader-role assignments, since those users can potentially escalate to full administrative access. View the full article

Dale Hoak found himself asking a question that has become familiar to CISOs through the decades: What am I missing? More specifically, Hoak, CISO at software firm RegScale, was wondering what he might be missing around his company’s AI deployments. “The business was moving so fast in using AI, so initially we had some visibility gaps,” he says. Hoak believed his monitoring capabilities weren’t strong enough to identify all the risks and threats associated with the company’s newest AI uses. So he repositioned existing tools and invested in new ones, including products that use intelligence to monitor enterprise AI use, to gain the visibility he needed — a process that took about six months. “Over time I figured out what to look for using logging and SIEM and AI tools, and I feel like we now have the gaps covered,” he notes. Still, he remains apprehensive. “I’m always a little wary,” he admits, about what his security operations might not see. CISOs are right to be concerned. AI is expanding the organization’s attack surface while introducing new types of risk such as those stemming from prompt injection and data poisoning attacks. Security leaders know that. But, as Hoak points out, CISOs are also contending with AI-related security blind spots as their organizations race to implement and scale the technology. According to the AI Security Exposure Survey 2026 Report from security software maker Pentera, 67% of CISOs report limited visibility into where and how AI is operating across their environments. Additionally, 48% of CISOs cited limited visibility into AI usage as a top challenge in securing AI systems, making it their second biggest challenge in this space. (Lack of internal expertise, cited by 50%, came in No. 1.) Myriad blind spots Nitin Raina, global CISO of consultancy Thoughtworks, highlights multiple scenarios that create such visibility gaps. One is shadow AI. “Initially about 12 to 18 months back, we saw people using [unsanctioned versions of] ChatGPT or Gemini or buying their own niche AI tool. That has slowed down, but it’s still one of the risks,” Raina says. Another is the introduction of AI capabilities by software makers whose products are already in use at the company. “The vendors we use are adding AI capabilities and sometimes we don’t have entire visibility into that,” he says, despite his security team’s work to learn how those vendors are handling data and AI-related vulnerabilities. The models supplied by providers also create blind spots, Raina adds, as CISOs typically can do some level of review but cannot perform deep dives into the models to determine whether there are issues that could skew outcomes to unacceptable levels or send data to places where it shouldn’t go. Yet another, Raina says, is agentic AI, whose risks include hallucinations or prompt injections as well as failures that due to their speed and autonomous actions can be difficult to detect with conventional security tools. Many compare the security situation around AI to the early days of cloud, when CISOs similarly experienced shadow deployments, unknown risks, and visibility challenges. The challenges today are more significant, says Nick Kakolowski, senior research director at IANS Research. Executives are scared of falling behind in the race to use AI for competitive advantage, so they’re willing to take more risks, he says. That has led to rapid-fire AI implementations and deployments outside of normal procurement channels. As a result, “blind spots are kind of everywhere.” CISOs also often lack full visibility into fourth-party AI systems and the risks that use entails. Ditto for the accuracy of the outcomes that employees are getting with some AI engines. “No one understands fully how to assess the outcomes of AI and the quality of the content being created by AI,” Kakolowski says. “We’re not going to be able to evaluate the quality and trustworthiness of the outputs of AI, and we don’t know how to equip our people to do so effectively.” Likewise for AI-generated code, which is increasingly being created outside of development teams thanks to the ease of using AI for such purposes. “They’re using vibe coding, and CISOs may not know where that AI-generated code is being integrated,” Kakolowski says. CISOs also may not know if AI agents grant access privileges to other agents as they execute workflows, creating yet another blind spot. And security execs may be in the dark about the ethical implications of their organization’s AI capabilities. “CISOs often get pulled into things that are on the ethical side of risk, and this issue of ethical AI is starting to emerge as one of them,” Kakolowski adds. Another area where CISOs may not have a clear view: where their organizations draw the line on blind spots introduced by their AI strategies. “Guessing at the organization’s risk tolerance is a high-level blind spot,” Kakolowski says, noting that CISOs wanting to close visibility gaps need to start by defining “what the organization considers reasonable versus unreasonable. That helps CISOs figure out the next step.” Gaining visibility CISOs say they’re aware of the consequences of having blind spots, with data leaks and problematic AI outputs being common ones. They’re now working to gain the needed visibility to prevent such issues, says Aaron Momin, CISO and chief risk officer for Synechron, a digital consulting and technology services firm. “The business has a mandate to adopt AI, but the trouble with this is that the business has been moving at lightspeed and CISOs are just catching up,” Momin adds. Like other security chiefs, Momin is leaning on a well-formed security strategy, security and AI frameworks, and a clear understanding of the company’s risk appetite and risk tolerance to do that work. He’s also leaning on people, process, and technology to secure his organization’s AI deployments and improve visibility. Still, he acknowledges blind spots could remain, explaining that traditional security tools, such as URL filtering and data loss prevention (DLP) solutions, provide a layer of control but don’t deliver the comprehensive view of AI use that CISOs need. “They’re not necessarily sufficient. They could get to maybe 80% or 90% of what you need, but to get higher visibility, you have to add additional tools,” Momin says. That, though, presents another challenge for CISOs. “Those tools have to be matured, have to be extended, have to be broader to get full visibility,” Momin says. “Now some vendors are upgrading the capabilities [offered in their security tools,] and new tools are coming on the market. And they’re starting to give you full visibility.” Thoughtworks’ Raina has a similar take to improving visibility, endorsing a multiprong approach to ensure his security team has a full picture of the organization’s AI deployments, their vulnerabilities, and their risks. That approach combines administrative, governance, and technology controls — a combination that has a long history of success in security. But experts say that tried-and-true combination is not enough to gain full visibility when it comes to AI. According to Pentera’s survey, no CISOs reported full visibility and no shadow AI. One-third said they had good visibility with shadow AI likely, while 66% said they had limited visibility with shadow AI a known issue, and 1% said they had no visibility. Full visibility may not be possible — at least not at present, says Jared Oluoch, professor and director of Eastern Michigan University’s School of Information Security and Applied Computing. Today’s tools and security strategies limit blind spots but do not eliminate them completely. “They can minimize the negative effects,” he adds. That’s the goal, says Tal Hornstein, CISO of Cast & Crew, a provider of production software, payroll, and services for the entertainment industry. Like others, Hornstein relies on longstanding security principles, citing the confidentiality, integrity, and availability (CIA) triad as the foundation for his approach to ensure that AI works within established guardrails and that he can observe its behavior. Hornstein is also looking to emerging technologies to deliver better observability and enforcement. But he acknowledges that security tech doesn’t enable full visibility at this time. “They are not fully mature yet,” he says. That has to be enough for now, he adds, saying CISOs can’t let visibility challenges slow down AI adoption. “AI is the most amazing technology, and whoever doesn’t use it will be left behind,” Hornstein says. “So, it’s important for me as a CISO and as a business leader to not put up barriers and block AI but to build up guardrails that allow the organization to move at the velocity it wants and the amount it wants while providing risk mitigation.” View the full article

PeachShutterStock | shutterstock.com Im Kern der Enterprise Security steht die Zerreißprobe zwischen Benutzerkomfort und Security-Anforderungen. Dabei handelt es sich um einen Balanceakt, der regelmäßig auf Authentifizierungsebene ausgetragen wird und sich direkt auf das Onboarding- und Anmeldeerlebnis auswirkt. Geht es darum diesen Konflikt aufzulösen, steht Federated Identity an vorderster Front: Sie kann eine gute User Experience bieten, ohne dabei das Sicherheitsniveau zu beeinträchtigen. Federated Identity Management – Definition Identity & Access Management (IAM) ist der übergeordnete Bereich, in dem es um digitale Identitäten und Zugriffsmanagement geht. Federated Identity Management (oder förderiertes Identitätsmanagement) ist eine IAM-Kategorie, die darauf fokussiert, ein einziges Authentifizierungsereignis sicher zu ermöglichen, um mehrere Interaktionen oder den Austausch von Identitätsinformationen abzudecken. Mit anderen Worten: Federated Identity Management (FIM) ermöglicht vielen Diensten, eine einzige digitale Identität gemeinsam zu nutzen. Ein Beispiel für den praktischen Einsatz von FIM wäre, wenn Sie sich bei Twitter mit ihrem Google-Konto anmelden. Föderiertes Identitätsmanagement kann der Benutzererfahrung, der allgemeinen Sicherheit und der Ausfallsicherheit zuträglich sein. Dafür gilt es, folgende Kompromisse einzugehen: erhöhte architektonische Komplexität, Bindung an einen bestimmten Anbieter und mögliche Servicekosten. Federated Identity Management wird bisweilen mit Single Sign-On (SSO) in einen Topf geworfen. Genau genommen ist SSO allerdings eine Funktion von FIM – und einer seiner wesentlichen Use Cases, den wir im Folgenden näher betrachten. Zuvor noch ein Hinweis: Das Thema Self-Sovereign Identity (oder dezentrale Identität) ist wieder eine andere Baustelle. Anwendungsfall (Federated) Single-Sign On Man unterscheidet zwei Arten von Single Sign-on: Einerseits das, was für Anwendungen innerhalb einer einzelnen Organisation gilt, und andererseits das, was organisationsübergreifend gilt. Ersteres wird in der Regel einfach als Single Sign-on bezeichnet, manchmal auch als “Enterprise Single Sign-on”. Letzteres fällt unter den Begriff Federated Single Sign-on (FSSO). Die High-Level-Architektur, um beide SSO-Formen abzudecken, sieht folgendermaßen aus: Der Blick auf eine High-Level-SSO-Architektur. Foto: Foundry / Matthew Tyson In jedem Fall erfordert Federated Identity Management eine zentrale Institution, die die gemeinsamen Anmeldeinformationen zwischen den verschiedenen Diensten vermittelt. Dabei kann es sich um einen Identity Manager handeln, der: von der Organisation selbst erstellt wurde (etwa unter Verwendung von Active Directory). über einen Identitätsanbieter in unterschiedlichem Umfang bereitgestellt wird. Enterprise Single Sign-on deckt oft Situationen ab, in denen sich Mitarbeiter mehrfach bei internen Systemen anmelden müssen, beispielsweise an HR-Portal und IT-Ticketsystem. Dieses Konzept birgt offensichtliche UX-, aber auch systemische Probleme, weil Identitätsinformationen über heterogene Systeme verteilt werden. Dieser Umstand beeinträchtigt die Sicherheit und erschwert es, Richtlinien durchzusetzen. So müssen etwa bei On- und Off-Boarding eines Mitarbeiters gleich zwei verschiedene Datenspeicher geändert werden. Federated Single Sign-on ermöglicht die gemeinsame Nutzung von Anmeldeinformationen über Unternehmensgrenzen hinweg. Als solches stützt es sich in der Regel auf eine große, gut etablierte Einheit mit weitreichendem Trust – beispielsweise Google, Microsoft oder Amazon. Selbst eine kleine Applikation kann relativ einfach um die Option “Anmelden bei Google” ergänzt werden und den Nutzern eine einfache Anmeldemöglichkeit bieten, bei der sensible Informationen in den Händen der großen Organisation bleiben. Federated SSO implementieren Der Aufbau einer Federated SSO-Lösung richtet sich nach den jeweils spezifischen Anforderungen. Die allgemeinen Schritte sind dabei jedoch identisch: Identity Provider einrichten: Entweder, Sie stellen eine zentralisierte Identity Infrastructure bereit oder Sie richten ein Konto bei einem Federated-Identity-Anbieter ein (Google, Microsoft, Okta). Auch eine Möglichkeit: Sie kreieren eine Mischform. Provider mit Anwendungsinformationen füttern: So konfigurieren Sie den Identity Provider und schaffen die Grundlage, dass sich Applikationen mit dem Anbieter verbinden können. Provider-Anmeldeinformationen hinzufügen: Diese werden Sie im nächsten Schritt verwenden, um Ihren Anwendungen mitzuteilen, wie sie sich authentifizieren sollen. Applikationen einrichten: In Ihrem Anwendungscode fügen Sie Abhängigkeiten für die Authentifizierung und Interaktion mit dem Identity-Provider-Service hinzu. Neue Authentifizierung integrieren: Mit dem konfigurierten SSO-Service haben Ihre Benutzer eine Möglichkeit, sich zu authentifizieren. Das funktioniert auch in “transparent”: Anwendungen erkennen und authentifizieren User mit einer Live-Session bei einem anderen Service automatisch. Weil es eine einfache Lösung ist, entscheiden sich die meisten Unternehmen heute für einen Cloud Identity Provider im Rahmen eines SaaS-Angebots – sowohl, wenn es um Enterprise als auch wenn es um Federated SSO geht. SSO-Protokolle implementieren Für SSO-Interaktionen werden im Wesentlichen drei Protokolle verwendet: SAML, OIDC und OAuth 2.0. Je nachdem, welches Protokoll der von Ihnen verwendete Identity-Anbieter unterstützt, werden Sie eines davon verwenden, um die sicheren Token-Informationen zwischen Ihren Anwendungen zu übermitteln. Jedes der Protokolle stellt einen offenen Standard dar, der auf einen bestimmten Anwendungsfall ausgerichtet ist. SAML ist ein XML-basiertes Protokoll, das häufig in Unternehmen verwendet wird, um Enterprise SSO zu unterstützen oder um zwischen verschiedenen Business-Service-Anbietern hin- und herzuspringen. Es kann auch für die allgemeine gemeinsame Nutzung von Identitäten verwendet werden, einschließlich Federated SSO (insofern der Identity Provider das unterstützt). OAuth 2.0 ist ein Authentifizierungsprotokoll, das die gemeinsame Nutzung von Ressourcendaten zwischen Anbietern auf der Grundlage der Zustimmung des Benutzers ermöglicht. Oauth fokussiert auf die gemeinsame Nutzung der Authentifizierung zwischen Diensten ohne die Angabe von Anmeldeinformationen. OIDC (OpenID Connect) stellt eine auf OAuth 2.0 aufbauende Schicht dar, die in der Regel für Social Logins (etwa “Sign in with GitHub”) verwendet wird. OIDC enthält einige Erweiterungen gegenüber OAuth, einschließlich Identity Assertions, Userinfo API und Standard Discovery – standardisierte Mechanismen für die sichere Bereitstellung und Nutzung von Identitätsinformationen. Diese Protokolle kommen einzeln oder im Kombination mit anderen Technologien zum Einsatz. So können beispielsweise JSON Web Token verwendet werden, um OAuth 2.0 Credential Token-Informationen in einem sichereren Format zu kapseln. Glücklicherweise ist der Prozess zur Implementierung dieser Protokolle umfassend dokumentiert und wird von einer Vielzahl von Technologie-Stacks unterstützt. Der größte Teil der Arbeit wird durch Abstraktionen auf höherer Ebene in vielen Sprachen und Frameworks gekapselt. Spring Security bietet beispielsweise SSO-Unterstützung, ebenso wie Passport im NodeJS/Express-Ökosystem. (fm) View the full article

When voters in the forthcoming Hungarian election assess the current government, its record on internet security will not be one of its proudest achievements. An analysis by open source investigation organization Bellingcat has revealed that the passwords for almost 800 Hungarian government email accounts are circulating online, many of them associated with national security. These breaches in security are not down to high-tech attacks but rather are the result of poor email hygiene among government employees. The security leaks were widespread: 12 out of 13 government departments were affected. Hungarian Prime Minister Viktor Orban’s administration likes to present itself as firm protector of Hungarian borders, resisting foreign interference, but this doesn’t seem to apply to its computing prowess. Among those whose details were revealed were an officer responsible for information security and a counter-terrorism expert. Bellingcat found that government officials have been using weak passwords such as variations of the word “Password” or the number sequence “1234567, while another simply used his surname. The Hungarian government is not alone in its laxity. Earlier this year, Specops found that 6 billion logins had been exposed online and found that number sequences and ‘password’ featured highly in the list of the most compromised logins. The vulnerabilities inherent in the Hungarian example are a warning to all CSOs that they should be reminding their staff to tighten their security credentials. Many choose simple, short memorable passwords because they’re easy to remember but using a password manager or deploying passkeys will immediately strengthen employees’ ability to protect data. View the full article

Anthropic’s Claude dug up a critical remote code execution (RCE) bug that sat quietly inside Apache ActiveMQ Classic for over a decade. Researchers at Horizon3.ai say that it only took minutes for their team to work out an exploit chain for the bug with the help of AI. The researcher behind the work, Naveen Sunkavally, described the process as “80% Claude with 20% gift-wrapping by a human.” The bug, now fixed, could allow an attacker to use ActiveMQ’s Jolokia API to make the server load a malicious configuration file from the internet and execute arbitrary system commands. The issue stems from the integration of multiple components developed independently over time. While each worked efficiently in isolation, together they allowed execution of remote code, a context Sunkavally noted was easier for Claude to spot. “Something that would have probably taken me a week manually took Claude 10 minutes,” the researcher said in a blog post. Management API flaw allowed full RCE The attack chain revolves around ActiveMQ’s management plane. ActiveMQ exposes the Jolokia API at “/api/jolokia/”, allowing authenticated users to invoke broker operations over HTTP. In vulnerable versions, attackers can abuse methods like “addNetworkConnector” to pass a crafted URL that allows the broker to load external configuration data. By embedding a malicious “brokerConfig” parameter, the attacker forces ActiveMQ to fetch and process a remote Spring XML file. When the file loads, it can create and run any Java code, granting the attacker remote execution inside the broker. The flaw is tracked as CVE-2026-34197 and carries a high severity rating (CVSS 8.8). It affects ActiveMQ Classic versions prior to 5.19.4 and several 6.x releases. While, by definition, the exploit requires authentication, Sunkavally pointed out that default credentials like “admin:admin” are still widely deployed in real environments. Worse, in certain ActiveMQ 6.x versions, a separate flaw (CVE-2024-32114) can expose the Jolokia API without any authentication. “In those versions, CVE-2026-34197 is effectively an unauthenticated RCE,” he said. AI accelerated discovery ActiveMQ has been here before. The platform has a track record of high-impact vulnerabilities tied to management surfaces and unsafe assumptions around trusted inputs. From older web console flaws to deserialization bugs and protocol-level RCEs, administrative functionalities have consistently become attack vectors. But none of the previous flaws were found the way CVE-2026-34197 was. The bug sat there for 13 years, with the first rollout of the affected implementation dating back to around 2012, before Claude could map out a multi-step exploit chain. The discovery is already teasing the much-buzzed successor to Claude’s flaw-catching capabilities, Claude Mythos. A vulnerability scanner and exploit generator so dangerous in the wrong hands that it has been restricted under early preview to a handful of companies, with big names of the AI and cybersecurity community coming together under “Project Glasswing” to encourage its controlled usage. CVE-2026-34197 has been addressed in newer ActiveMQ Classic releases (6.2.3 and 5.19.4), and users must upgrade to patched versions to be protected. View the full article

Zero trust has become one of the most widely adopted security models in enterprise environments. Organizations invest heavily in identity systems, access policies, and modern security tooling. On paper, these environments look well-protected. Yet during incidents, a different reality often emerges. I have worked with organizations where zero-trust initiatives were fully implemented from an identity and policy standpoint. Access controls were defined. Authentication flows were strong. Compliance requirements were met. But when something went wrong, the same question kept coming up. How did the traffic get through in the first place? The answer is often uncomfortable. The strategy was sound, but enforcement at the traffic layer was inconsistent. That is where most zero-trust architectures fail. Where zero trust breaks down in practice Zero trust is built on a simple idea: never trust, always verify. In practice, most implementations focus heavily on identity. Users authenticate. Devices are validated. Policies determine access. What is often overlooked is how traffic enters and moves through the environment before those controls are applied. The traffic layer includes ingress paths, load balancers, API gateways, TLS enforcement, request validation, and service-to-service communication. This is where trust is either established or assumed. In several environments I have worked in, these gaps were not due to a lack of tools. They came from inconsistent ownership between networking, security, and application teams. One of the most common patterns is strong identity enforcement combined with permissive entry points. Organizations deploy modern identity providers and multi-factor authentication, yet still allow outdated TLS versions or weak cipher configurations at the edge. Guidance from the National Institute of Standards and Technology recommends secure protocol baselines. Another recurring issue is fragmented ingress. Applications are exposed through different paths such as CDNs, direct load balancers, legacy endpoints, or newly deployed APIs. Each path behaves slightly differently. Mutual TLS is also frequently implemented only partially. Connections are terminated and re-established internally with weaker assumptions. East-west traffic introduces another gap. Once inside, traffic is often treated as safe. Finally, there is the issue of visibility. During incident response, teams often cannot answer which path a request took. Many of these issues align with patterns described by OWASP. Why the traffic layer is the real enforcement point Security programs often succeed at defining policies. They struggle with enforcing them consistently. The traffic layer is where enforcement becomes real. From a leadership perspective, this is not a tooling problem. It is an architectural one. Principles from the Cloud Security Alliance emphasize placing controls at ingress. What works in real environments Organizations that succeed treat the traffic layer as a primary enforcement point. They standardize ingress paths, enforce strict TLS baselines, and eliminate legacy exceptions. They define clear rules for mutual TLS and ensure trust is continuously validated. They normalize and validate requests before application logic. They implement consistent telemetry so security teams can trace requests end-to-end. Final thought Zero trust is often described as a shift in mindset. That is true, but mindset alone does not secure systems. Security is about enforcement. And enforcement begins with how traffic is handled. That is why most zero-trust architectures fail at the traffic layer. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Wirestock Creators – shutterstock.com Drittanbieter-Risikomanagement ist für CISOs und Sicherheitsentscheider eine signifikante Herausforderung. Wird sie nicht (richtig) gestemmt, drohen weitreichende geschäftliche Konsequenzen – bis hin zum Stillstand der Produktion. Das wurde in den vergangenen Monaten von diversen Cyberattacken auf Drittanbieter unterstrichen. Zum Beispiel, als die russische Hackergruppe APT29 (auch bekannt als “Cozy Bear”) im Juni 2024 die kostenlose Remote-Access-Software TeamViewer ins Visier nahm, die im Unternehmensumfeld weit verbreitet ist. Selbst, wenn Sie TeamViewer nicht einsetzen – ähnliche Tools gibt es auch von diversen, anderen Anbietern. Beispielsweise von Perimeter81, AnyDesk, GoToMyPC oder LogMeIn. Die entscheidenden Fragen sind dabei: Welcher Drittanbieter wird als nächstes angegriffen? Und können Sie es sich leisten, diesbezüglich ein Risiko einzugehen? Drittanbieter sind Ihr schwächstes Glied Leider verlassen sich so gut wie alle Unternehmen in zu hohem Maße auf zu viele verschiedene Drittanbieter, die in ihre Softwarelieferketten und Geschäftsprozesse eingebettet sind. Dabei reden wir nicht über zwei oder drei Third-Party-Partner, sondern mit Blick auf populäre Software-as-a-Service-Angebote eher über Hunderte oder Tausende, auf die sich Unternehmen jeden Tag verlassen. Das Risiko, das einer Zusammenarbeit mit Drittanbietern inhärent ist, steigt entsprechend drastisch an – und nicht nur, wenn ihre Anzahl überhandnimmt. Weitere Risikofaktoren in diesem Bereich sind beispielsweise: Eingeschränkte Transparenz. So gut wie alle Anbieter bieten potenziellen Kunden diverse Daten an, um ihre Fähigkeiten anzupreisen. Dabei kommen in einigen Fällen allerdings Informationen zum Einsatz, die nicht aktuell sind und somit die aktuelle Risikolage nicht adäquat widerspiegeln. Mehr Komplexität. Diverse Drittanbieter arbeiten selbst mit Zulieferern und Subunternehmen zusammen, von denen Sie möglicherweise nichts wissen. Unausgereifte Prozesse. Nicht wenige Third-Party-Anbieter arbeiten mit Cybersecurity-Richtlinien und -Standards, die weniger ausgereift sind als Ihre eigenen. Geringere Investitionen. Letztgenannter Punkt hängt oft auch damit zusammen, dass viele Drittanbieter ein begrenztes Budget für Cybersicherheit zur Verfügung haben. Das kann sich auf das Sicherheitsniveau ihrer Tools und Services auswirken. Zwar wurde eine Reihe von Best Practices und Playbooks entwickelt, um diese Lücken zu schließen – diese haben sich in weiten Teilen allerdings nicht bewährt: Vendor Assessments verkommen regelmäßig zu papierbasierten “Ankreuzübungen”, die nur Zeit fressen, aber nicht dazu beitragen, Risiken zu minimieren. Auch im Rahmen von Vertragsverhandlungen dafür sorgen zu wollen, dass strengere Sicherheitsanforderungen bei Drittanbietern angelegt werden, hat in vielen Fällen nichts bewirkt. Einige Unternehmen setzen auf Continuous Monitoring, um einen Überblick und mehr, datengetriebene Einblicke in das Sicherheitsniveau von Drittanbietern zu erhalten. Andere implementieren mit Blick auf Third-Party-Partner Incident-Response-Pläne, um Strategien zu entwickeln und einzuüben, falls es bei diesen zu einem Sicherheitsvorfall kommt. Insbesondere die letzten beiden Punkte können für Unternehmen hilfreich sein. Allerdings adressieren auch diese Maßnahmen das Risiko in Zusammenhang mit Drittanbietern nicht vollumfänglich. Vielmehr stellen sie ein Mittel dar, um zu überwachen und zu reagieren, falls es zu einer Cyberattacke kommt. Die Moschusochsen-Strategie Ich bin stolzes Mitglied des “Financial Services Information Sharing and Analysis Center” (FS-ISAC) und habe zusammen mit anderen CISOs aus der Finanzdienstleistungsbranche den Vorsitz des strategischen Ausschusses in der Asien-Pazifik-Region inne. Das Konsortium bietet Finanzdienstleistern auf der ganzen Welt ein umfassendes Cyber-Intelligence-Netzwerk, um sich untereinander über möglicherweise bevorstehende oder bereits laufende Angriffskampagnen auszutauschen. Weil viele verschiedene Unternehmen der Branche mit unterschiedlich ausgeprägtem Knowhow und Ressourcen an Bord sind, sind die Mitglieder in der Lage, eine umfassende Perspektive zu erhalten, die sie alleine nicht erreichen könnten. Das FS-ISAC ist insofern ein hervorragendes Beispiel dafür, wie wir als Sicherheitsentscheider zusammenarbeiten können, um uns besser gegen Risiken abzusichern. Das ist die Essenz dessen, was ich als “Moschusochsenstrategie” bezeichne. Der Hintergrund: Werden Moschusochsen von Wölfen angegriffen, bildet die Herde einen Kreis, in dessen Mitte sich die schwächeren Mitglieder befinden. Die Hörner der “Frontline”-Tiere sind dabei nach außen positioniert. Für die Angreifer ist dieser gemeinschaftliche Verteidigungswall kaum noch zu überwinden. Ich bin der festen Überzeugung, dass sich diese Strategie auch auf das Drittanbieter-Risikomanagement übertragen lässt. Ähnlich wie bei den Moschusochsen die Kälber sind die Drittanbieter, auf die wir uns verlassen, die schwächsten Herdenmitglieder. Werden Sie in Mitleidenschaft gezogen, wirkt sich das auf unsere kritischen Geschäftsprozesse aus. Der Unterschied zu den Moschusochsen: Wir bilden keinen Kreis, in dessen Mitte sich die Drittanbieter befinden. Stattdessen wäre es angebracht, sich im Kollektiv darüber auszutauschen, wenn die Sorge besteht, dass die Cybersecurity-Maßnahmen bei einem Third-Party-Anbieter zu wünschen übriglassen und verstärkt werden sollten. Noch wichtiger wäre allerdings eine gemeinsame Übereinkunft darüber, den Drittanbieter bei seinen Bemühungen zu unterstützen. Das würde potenziell Koordinationsarbeit und unter Umständen auch eine Neuverhandlung von Verträgen erfordern – hätte aber den Vorteil, diese Schwachstelle, die uns alle betrifft, besser absichern zu können. Von der Theorie zur Praxis Ein solches Zusammenwirken könnte unter Juristen durchaus Bedenken aufwerfen – Stichwort Wettbewerbsrecht. Dennoch hat der Moschusochsenansatz das Potenzial, die Risikolage in Sachen Drittanbieter entscheidend zu verbessern – und Unternehmen dabei zu unterstützen, Third-Party-Risiken besser zu managen. Das könnte – zum Beispiel – folgendermaßen aussehen: Bestimmen Sie, welche Drittanbieter Ihnen am meisten Sorgen bereiten und erstellen Sie eine “Hot List”. Tauschen Sie sich mit anderen Unternehmen aus, um diese Liste abzugleichen und die Kandidaten zu ermitteln, die Sie gemeinsam haben. Verhandeln Sie über einen gemeinschaftlichen “Schutzschild” für diese Anbieter. Denselben Ansatz haben wir bei FS-ISAC als möglichen Weg für die Zukunft diskutiert. Die ersten beiden Schritte sind relativ simpel zu bewerkstelligen – der dritte macht hingegen deutlich mehr Aufwand, aber auch den entscheidenden Unterschied. Ein praktischer Ansatz, um diesen umzusetzen, könnte dabei darin bestehen, dass die größten Unternehmen eine Führungsrolle einnehmen und kleinere unter ihre Fittiche nehmen. Vergessen sollten Sie dabei nicht, dass auch die Moschusochsen-Strategie ihre Grenzen hat: Wenn ein Bär angreift, machen sich auch Moschusochsen aus dem Staub – dann ist jeder auf sich allein gestellt. Das lässt sich ebenfalls auf die Cybersicherheit übertragen: Je mächtiger der Feind, desto wahrscheinlicher ist es, dass der Angriff in einen Kampf ums blanke Überleben ausartet. Aber auch wenn diese Strategie nicht auf jedes Szenario anwendbar ist, könnte sie unser kollektives Risiko erheblich minimieren. (fm) View the full article

Wirestock Creators – shutterstock.com Drittanbieter-Risikomanagement ist für CISOs und Sicherheitsentscheider eine signifikante Herausforderung. Wird sie nicht (richtig) gestemmt, drohen weitreichende geschäftliche Konsequenzen – bis hin zum Stillstand der Produktion. Das wurde in den vergangenen Monaten von diversen Cyberattacken auf Drittanbieter unterstrichen. Zum Beispiel, als die russische Hackergruppe APT29 (auch bekannt als “Cozy Bear”) im Juni 2024 die kostenlose Remote-Access-Software TeamViewer ins Visier nahm, die im Unternehmensumfeld weit verbreitet ist. Selbst, wenn Sie TeamViewer nicht einsetzen – ähnliche Tools gibt es auch von diversen, anderen Anbietern. Beispielsweise von Perimeter81, AnyDesk, GoToMyPC oder LogMeIn. Die entscheidenden Fragen sind dabei: Welcher Drittanbieter wird als nächstes angegriffen? Und können Sie es sich leisten, diesbezüglich ein Risiko einzugehen? Drittanbieter sind Ihr schwächstes Glied Leider verlassen sich so gut wie alle Unternehmen in zu hohem Maße auf zu viele verschiedene Drittanbieter, die in ihre Softwarelieferketten und Geschäftsprozesse eingebettet sind. Dabei reden wir nicht über zwei oder drei Third-Party-Partner, sondern mit Blick auf populäre Software-as-a-Service-Angebote eher über Hunderte oder Tausende, auf die sich Unternehmen jeden Tag verlassen. Das Risiko, das einer Zusammenarbeit mit Drittanbietern inhärent ist, steigt entsprechend drastisch an – und nicht nur, wenn ihre Anzahl überhandnimmt. Weitere Risikofaktoren in diesem Bereich sind beispielsweise: Eingeschränkte Transparenz. So gut wie alle Anbieter bieten potenziellen Kunden diverse Daten an, um ihre Fähigkeiten anzupreisen. Dabei kommen in einigen Fällen allerdings Informationen zum Einsatz, die nicht aktuell sind und somit die aktuelle Risikolage nicht adäquat widerspiegeln. Mehr Komplexität. Diverse Drittanbieter arbeiten selbst mit Zulieferern und Subunternehmen zusammen, von denen Sie möglicherweise nichts wissen. Unausgereifte Prozesse. Nicht wenige Third-Party-Anbieter arbeiten mit Cybersecurity-Richtlinien und -Standards, die weniger ausgereift sind als Ihre eigenen. Geringere Investitionen. Letztgenannter Punkt hängt oft auch damit zusammen, dass viele Drittanbieter ein begrenztes Budget für Cybersicherheit zur Verfügung haben. Das kann sich auf das Sicherheitsniveau ihrer Tools und Services auswirken. Zwar wurde eine Reihe von Best Practices und Playbooks entwickelt, um diese Lücken zu schließen – diese haben sich in weiten Teilen allerdings nicht bewährt: Vendor Assessments verkommen regelmäßig zu papierbasierten “Ankreuzübungen”, die nur Zeit fressen, aber nicht dazu beitragen, Risiken zu minimieren. Auch im Rahmen von Vertragsverhandlungen dafür sorgen zu wollen, dass strengere Sicherheitsanforderungen bei Drittanbietern angelegt werden, hat in vielen Fällen nichts bewirkt. Einige Unternehmen setzen auf Continuous Monitoring, um einen Überblick und mehr, datengetriebene Einblicke in das Sicherheitsniveau von Drittanbietern zu erhalten. Andere implementieren mit Blick auf Third-Party-Partner Incident-Response-Pläne, um Strategien zu entwickeln und einzuüben, falls es bei diesen zu einem Sicherheitsvorfall kommt. Insbesondere die letzten beiden Punkte können für Unternehmen hilfreich sein. Allerdings adressieren auch diese Maßnahmen das Risiko in Zusammenhang mit Drittanbietern nicht vollumfänglich. Vielmehr stellen sie ein Mittel dar, um zu überwachen und zu reagieren, falls es zu einer Cyberattacke kommt. Die Moschusochsen-Strategie Ich bin stolzes Mitglied des “Financial Services Information Sharing and Analysis Center” (FS-ISAC) und habe zusammen mit anderen CISOs aus der Finanzdienstleistungsbranche den Vorsitz des strategischen Ausschusses in der Asien-Pazifik-Region inne. Das Konsortium bietet Finanzdienstleistern auf der ganzen Welt ein umfassendes Cyber-Intelligence-Netzwerk, um sich untereinander über möglicherweise bevorstehende oder bereits laufende Angriffskampagnen auszutauschen. Weil viele verschiedene Unternehmen der Branche mit unterschiedlich ausgeprägtem Knowhow und Ressourcen an Bord sind, sind die Mitglieder in der Lage, eine umfassende Perspektive zu erhalten, die sie alleine nicht erreichen könnten. Das FS-ISAC ist insofern ein hervorragendes Beispiel dafür, wie wir als Sicherheitsentscheider zusammenarbeiten können, um uns besser gegen Risiken abzusichern. Das ist die Essenz dessen, was ich als “Moschusochsenstrategie” bezeichne. Der Hintergrund: Werden Moschusochsen von Wölfen angegriffen, bildet die Herde einen Kreis, in dessen Mitte sich die schwächeren Mitglieder befinden. Die Hörner der “Frontline”-Tiere sind dabei nach außen positioniert. Für die Angreifer ist dieser gemeinschaftliche Verteidigungswall kaum noch zu überwinden. Ich bin der festen Überzeugung, dass sich diese Strategie auch auf das Drittanbieter-Risikomanagement übertragen lässt. Ähnlich wie bei den Moschusochsen die Kälber sind die Drittanbieter, auf die wir uns verlassen, die schwächsten Herdenmitglieder. Werden Sie in Mitleidenschaft gezogen, wirkt sich das auf unsere kritischen Geschäftsprozesse aus. Der Unterschied zu den Moschusochsen: Wir bilden keinen Kreis, in dessen Mitte sich die Drittanbieter befinden. Stattdessen wäre es angebracht, sich im Kollektiv darüber auszutauschen, wenn die Sorge besteht, dass die Cybersecurity-Maßnahmen bei einem Third-Party-Anbieter zu wünschen übriglassen und verstärkt werden sollten. Noch wichtiger wäre allerdings eine gemeinsame Übereinkunft darüber, den Drittanbieter bei seinen Bemühungen zu unterstützen. Das würde potenziell Koordinationsarbeit und unter Umständen auch eine Neuverhandlung von Verträgen erfordern – hätte aber den Vorteil, diese Schwachstelle, die uns alle betrifft, besser absichern zu können. Von der Theorie zur Praxis Ein solches Zusammenwirken könnte unter Juristen durchaus Bedenken aufwerfen – Stichwort Wettbewerbsrecht. Dennoch hat der Moschusochsenansatz das Potenzial, die Risikolage in Sachen Drittanbieter entscheidend zu verbessern – und Unternehmen dabei zu unterstützen, Third-Party-Risiken besser zu managen. Das könnte – zum Beispiel – folgendermaßen aussehen: Bestimmen Sie, welche Drittanbieter Ihnen am meisten Sorgen bereiten und erstellen Sie eine “Hot List”. Tauschen Sie sich mit anderen Unternehmen aus, um diese Liste abzugleichen und die Kandidaten zu ermitteln, die Sie gemeinsam haben. Verhandeln Sie über einen gemeinschaftlichen “Schutzschild” für diese Anbieter. Denselben Ansatz haben wir bei FS-ISAC als möglichen Weg für die Zukunft diskutiert. Die ersten beiden Schritte sind relativ simpel zu bewerkstelligen – der dritte macht hingegen deutlich mehr Aufwand, aber auch den entscheidenden Unterschied. Ein praktischer Ansatz, um diesen umzusetzen, könnte dabei darin bestehen, dass die größten Unternehmen eine Führungsrolle einnehmen und kleinere unter ihre Fittiche nehmen. Vergessen sollten Sie dabei nicht, dass auch die Moschusochsen-Strategie ihre Grenzen hat: Wenn ein Bär angreift, machen sich auch Moschusochsen aus dem Staub – dann ist jeder auf sich allein gestellt. Das lässt sich ebenfalls auf die Cybersicherheit übertragen: Je mächtiger der Feind, desto wahrscheinlicher ist es, dass der Angriff in einen Kampf ums blanke Überleben ausartet. Aber auch wenn diese Strategie nicht auf jedes Szenario anwendbar ist, könnte sie unser kollektives Risiko erheblich minimieren. (fm) View the full article

Adobe Reader vulnerabilities have been exploited for decades by threat actors taking advantage of the universal use of the utility to fool employees into downloading infected PDF documents through phishing lures. Now a security researcher says a Reader hole has been quietly exploited by malware for as long as four months, fingerprinting computers to gather information that will allow attackers to steal data and perform further malicious activities. In a blog this week, Haifei Li said that EXPMON, the publicly-available exploit monitor he runs that scans samples to detect file-based zero-day exploits, had found an initial exploit that abuses the vulnerability in a Reader API. JavaScript code in the malware that automatically executes when the infected PDF is opened reads files on the compromised computer, collecting information including language settings, the Adobe Reader version number, the exact OS version, and the local path of the PDF file. It then sends the data to a remote server. This information will be useful to a threat actor planning on launching future attacks, including the installation of remote access tools, Li noted. Li said in his April 7 report that he tested the malware on what was at the time the latest version of Adobe Reader (26.00121367), and it still worked. In an update the next day, Li added that a variant dating back to last November had been found by another researcher, which suggests the malware had been in use at least since then. Adobe was asked for comment on the report, but no reply was received by deadline. It’s not the first time Adobe Reader has been targeted. Vulnerabilities relating to it date back at least to 2007, when a hole was found in a browser plug-in. Fake Reader updates are another threat actor favorite. User-after-free memory vulnerabilities are also common; researchers at Zeropath last year described one of them, CVE-2025-54257. Traditional tactics In addition to applying patches as soon as they are available, infosec leaders need to ensure employees receive regular security awareness training that includes warnings about opening unexpected PDFs, even those seemingly from trusted sources such as co-workers or managers. Threat actors traditionally use a variety of tactics to trick an employee into opening an email attachment, including using subject lines like “Urgent,” and “Info on bonus.” The attachment itself may be given a name that conveys importance; in this case, the November variant carried the file name “Invoice504.pdf.” According to a report on this new malware filed with malware scanning site VirusTotal, to which anyone can upload suspicious files for scrutiny, the recipient is to open the attachment specifically with Adobe Acrobat Reader. A high risk exploit Kellman Meghu, chief technology officer at Canadian incident response firm DeepCove Security, called the exploit “a very high risk.” So far it looks as though this particular malware just exfiltrates data, he said. But it implies there is an ability or capability to turn it into a vehicle for remote code execution. “It is a zero click [vulnerability],” Meghu added, “meaning just viewing in a browser or email is likely enough to trigger it.” CSOs should meet this threat by disabling Acrobat JavaScript, either by default or until there is a patch, he said. “But to be honest,” he added, “I think JavaScript execution is generally a bad idea in Adobe Reader,” so it should be disabled. Johannes Ullrich, dean of research at the SANS Institute, noted Adobe Acrobat and Reader have often been the targets of sophisticated exploits. These frequently take advantage of features like JavaScript, or leverage the ability to include, or nest, various document types inside a PDF. Many malware filters will detect and flag these types of documents as malicious, he said. “CSOs should ensure that web proxies and email gateways have filters enabled to not allow PDFs that are not fully standards compliant, and to eliminate PDFs taking advance of known problematic features like JavaScript,” he said. “Any attachment like this should also prominently note that it was received from a source outside the organization.” “Sadly,” he added, “PDFs are still very common, and can not be completely eliminated.” Adam Marrè, CISO at Arctic Wolf, said that what makes this new vulnerability particularly concerning is that it’s being actively exploited and appears to work even on fully patched systems. That immediately raises the risk profile. “Even without full visibility into the entire attack chain, the fact that initial access can be gained through something as routine as opening a PDF means organizations should treat this as a real and present security event,” he said. “From there, the potential impact can range from limited data exposure to follow‑on activity if attackers are able to deliver additional payloads.” This becomes a matter of managing risk in real time, he pointed out. “When a trusted tool suddenly falls outside an organization’s acceptable risk threshold, the priority shifts to reducing exposure and increasing visibility. That may mean reassessing where the software is truly necessary, tightening how untrusted content is handled, and ensuring monitoring is in place to quickly detect any abnormal behavior,” he said. “Just as important is what happens after containment,” he added. “Incidents like this are an opportunity to evaluate what controls held up, where gaps surfaced, and how to operationalize those lessons. Threats tied to everyday user behavior aren’t going away, so resilience depends on learning quickly and adapting just as fast.” View the full article

Google’s accelerated post-quantum encryption deadline has spurred other leaders in the industry, including Cloudflare, to consider pushing forward their own plans. The US National Institute of Standards and Technology (NIST) has set a 2030 deadline for depreciating legacy encryption algorithms ahead of their planned retirement in 2035. Late last month Google brought forward its own post-quantum cryptography (PQC) deadline a year to 2029 because advances in quantum computers mean that legacy encryption and digital signature systems are at greater risk sooner than previously anticipated. Google is readying its products and services for PQC by adding support to its Chrome browser, Android mobile operating system, and cloud-based services. Algorithmic breakthrough Bas Westerbaan, principal research engineer at Cloudflare, and an expert in post quantum encryption, told CSO that Google’s decision to pull forward its PQC migration timeline to 2029 is a “very big deal.” “We are starting to see some details of the three breakthroughs that scared Google, but crucial elements are being withheld due to their perceived risk as an aid for adversaries,” says Westerbaan. “Google even went to the effort to publish a state-of-the-art zero-knowledge proof to demonstrate they indeed made an algorithmic breakthrough without spilling the beans.” Cloudflare is “actively adjusting” its priorities and “will share outcomes soon,” Westerbaan explains. Preparations for the migration to PQC by Cloudflare are already well advanced. More than half the traffic on Cloudflare is already secure against the threat of harvest-now/decrypt-later using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, a PQC standard ratified in 2024) as browsers roll out support. To protect browser connections against active attack, Cloudflare is planning to deploy post-quantum certificates in 2027. Quantum threat The existing public key cryptographic systems that protect Internet and mobile transactions, Rivest-Shamir-Adelman (RSA) and Elliptic Curve Cryptography (ECC), are aging cryptosystems, developed in the 1970s and 1980s, respectively. Sufficiently powerful quantum computers pose a threat to legacy cryptographic standards, and specifically to encryption and digital signatures, because they have the capacity to break the mathematical foundations of legacy algorithms. For example, newer and faster algorithms have already been developed, such as the JVG algorithm, that require less quantum computational power (qubits) to factor large prime numbers, on which some legacy cryptosystems such as RSA are based. Google argues that advances in quantum computing, including hardware development, quantum error correction, and quantum factoring resource estimates, are bringing forward the time legacy cryptographic algorithms will become vulnerable to quantum computing, a phenomenon known as Q-Day. “Google’s accelerated 2029 deadline reflects a shift from trying to predict Q-day to managing pre-Q-day risk,” says Mark Pecen, chair of technical committee on quantum technologies at the European Telecommunications Standards Institute (ETSI). “The real concern isn’t when quantum computers arrive; it’s that adversaries are already collecting encrypted data today to decrypt later.” Data with long-term sensitivity, legal records, intellectual property, medical research, and critical infrastructure communications are most at risk. “By moving earlier than government timelines, Google is effectively forcing the industry to treat post-quantum migration as an immediate operational priority rather than a future compliance exercise,” says Pecen. Matt Campagna, chair of the quantum-safe cryptography working group at ETSI, adds: “Businesses must develop their own PQC migration strategies and actively engage with vendors and suppliers to ensure alignment.” Michael Klieman, global vice president for project management at Entrust, says that doubts about how close the industry is to a cryptographically relevant quantum computing breakthrough are creating uncertainty. “Today, there’s no universal way to measure performance across quantum systems, which makes it difficult to separate incremental progress from meaningful milestones toward Q-Day,” according to Klieman. “What the industry needs next are clear, standardized benchmarks for scale, error correction, and algorithmic performance — so organizations can understand where we are on the path to quantum risk, not just where vendors say we are,” Klieman adds. Catalyst Daryl Flack, partner at UK-based managed security service provider Avella Security, argues Google’s accelerated roadmap is likely to act as a catalyst across the industry. Google’s accelerated roadmap has the potential to disrupt a cycle of inaction driven by misaligned incentives: vendors waiting for customer demand, and organizations waiting for regulation, according to Flack. “Google’s decision to accelerate its post-quantum cryptography (PQC) migration to 2029 is a clear signal that the industry is moving from theoretical timelines to operational urgency,” Flack says. “While existing UK and EU roadmaps provide direction, they do not compel action, and that distinction is now becoming a material cybersecurity risk.” Preparations — and in some cases even awareness — about the need to migrate to PQC is lagging amongst many enterprises. “Many enterprises lack visibility into where cryptography is used, have not identified their most sensitive long-lived data, and do not yet have crypto-agility built into their systems,” Flack warns. “Without addressing these fundamentals, any accelerated timeline, whether driven by regulators or vendors, will be difficult to meet.” Enterprise CISOs should take ownership of PQC readiness. “Preparation should start with a structured approach: creating crypto inventories and catalogs, mapping cryptographic dependencies, identifying high-risk systems, and embedding crypto-agility into transformation programmes,” Flack advises. “Just as importantly, organizations must extend this thinking into their supply chains.” View the full article

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

ClickFix malware campaigns are evolving again, with threat actors removing one of their most obvious and user‑dependent steps: convincing victims to paste malicious commands into Terminal. Instead, the latest variant uses a single browser click to trigger script execution, streamlining the infection chain and reducing user hesitation. Researchers at Jamf Threat Labs have identified a new macOS campaign that launches Apple’s native Script Editor directly from the browser, preloaded with malicious code. The technique abuses the applescript:// URL scheme to open Script Editor automatically, sidestepping Terminal entirely and delivering Atomic Stealer payloads with far less friction. “Script Editor has a well-documented history as a malware delivery mechanism, so its presence here isn’t surprising,” the researchers said in a blog post. “What is notable is its role in this ClickFix campaign and the fact that it was invoked via a URL scheme.” The payload isn’t new. It’s Atomic Stealer, a credential-harvesting strain commonly deployed in macOS-focused campaigns. Apple drops protection, attackers go around it Conventionally, ClickFix chains relied on social engineering to get users to paste obfuscated commands into Terminal. Apple’s recent protections introduced scanning and prompts around pasted commands, adding restrictions to disrupt that flow. This campaign routes around it. Victims are directed to an Apple-themed page posing as a system fix or cleanup guide. Instead of copying anything, they click a button that invokes an applescript:// URL. That action opens Script Editor with a pre-populated script, ready to execute. By not directing the user to interact with the Terminal, the attacker has removed a decision point that Apple enforced with macOS Tahoe 26.4. “Apple took direct aim at this in macOS 26.4, introducing a security feature that scans commands pasted into Terminal before they’re executed,” the researchers added. “It’s a meaningful friction point, but as this campaign illustrates, when one door closes, attackers find another.” Script Editor is a native macOS utility and doesn’t carry the same immediate suspicion as Terminal for non-experienced users. However, there is still some non-targeted resistance to this technique. The researchers pointed out that the behavior of the Script Editor may vary depending on the macOS version. “On recent versions of macOS Tahoe, an additional warning prompt is presented, requiring the user to allow the script to be saved to disk before execution,” they said. Lightweight staging for Atomic Stealer Once executed, the AppleScript resolves to an obfuscated shell command. That command decodes a hidden URL, retrieves a remote payload using ‘curl’, and executes it via ‘zsh’. From here, standard info-stealing takes over with a ‘Mach-O’ binary written to a temporary location, its attributes adjusted, permissions set, and execution triggered. This binary is a new variant of the Atomic Stealer. The researchers noted that the staging approach keeps the initial script minimal and less detectable, while the actual malicious logic arrives separately. It is modular, quick to update, and harder to catch at the first stage. Atomic Stealer’s objectives are consistent with earlier macOS infostealer campaigns, which focused on harvesting browser credentials, saved passwords, crypto wallet data, and developer artifacts. Previous reporting has shown that such stealers rarely operate in isolation, as exfiltrated data is almost always funneled into credential reuse attacks and account takeovers. View the full article

The gap between vulnerability disclosure and exploitation is drastically decreasing, putting security teams’ patching practices on notice. According to Rapid7’s latest Cyber Threat Landscape Report, confirmed exploitation of newly disclosed high- and critical-severity vulnerabilities (CVSS 7-10) increased 105% year to 146 in 2025, up from 71 in 2024. Moreover, the median time from vulnerability publication to CISA Known Exploited Vulnerabilities (KEV) inclusion dropped from 8.5 days to 5.0 days, with mean time-to-exploit dropping from 61.0 days to 28.5 days. Zero-day exploits have also been hitting enterprises faster and harder, according to a recent report from Google Threat Intelligence Group. The result is a threat ecosystem that sees twice as many high-impact flaws exploited in half the time — a troubling development for cyber defense. Cybercrime industrial complex Industrialization of the cybercrime ecosystem and increased abuse of AI tools to find and exploit vulnerabilities are key drivers of the increased pace of vulnerability exploitation, according to Rapid7 and other industry observers quizzed by CSO. “Initial access brokers now sell directly to ransomware groups, creating a clear incentive to weaponize new vulnerabilities, harvest credentials, and monetize access,” says Stephen Fewer, senior principal researcher at Rapid7, the firm behind the popular Metasploit penetration-testing tool. “This has accelerated both the pace and sophistication of their operations.” For attackers, familiarity with the target and the technologies involved can greatly reduce the challenge of developing exploits — a factor that is driving repeated exploitation of many enterprise software targets. AI adoption is another important factor in the increased pace of vulnerability discovery and exploitation because it facilitates the process of uncovering software bugs. “It [AI] enables threat actors to close skill gaps and significantly increases operational throughput,” Fewer says. “In practice, AI provides a tactical advantage in analyzing newly disclosed vulnerabilities and generating exploit code at speed.” N-day exploitation Rapid7 Labs validated its findings about a more febrile threat environment by producing both n-day and zero-day exploits using AI-assisted research, substantially reducing development time. In practice, n-day bugs — or the development of exploits against patched software — are a bigger problem than headline-grabbing zero-day vulnerabilities, adds Leeann Nicolo, incident response lead at Coalition, a technology firm that specializes in cyber insurance and cybersecurity tools. “Our incident response team hasn’t seen a lot of zero-day vulnerabilities exploited lately. Instead, threat actors are hitting known issues that already have patches,” Nicolo says. Other industry experts confirmed that Rapid7’s findings reflect what they too are seeing on the ground. “The patch window has effectively collapsed,” says Chris Wysopal, co-founder and chief security evangelist at application security firm Veracode. “That is not a gradual trend; it’s a structural break.” One driver for the increased pace of exploitation is that every patch now acts like a roadmap for attackers, Wysopal says. “Once a fix ships, attackers can differentiate the patch, isolate the vulnerable code path, and use automation and AI to generate working exploit paths far faster than enterprises can test and deploy the fix,” says Wysopal. “In other words, disclosure increasingly starts the race, and defenders are already behind when the starting gun fires.” In addition, AppSec debt widens the exposure window even when a patch exists. “Enterprises are still carrying too much legacy code, too many internet-facing dependencies, and too many fragile change processes to remediate at machine speed,” Wysopal says. “If the organization needs days or weeks to inventory exposure, assess blast radius, test, get approvals, and deploy, then it is operating on a calendar while attackers are operating on a clock.” Another big issue is the industrialization of vulnerability exploitation. AI compresses exploit development and lowers the skill barrier, while the cybercrime market removes friction by creating a well-oiled production line that incorporates researchers, brokers, access sellers, botnet operators, and ransomware affiliates. “[This] assembly-line model means more vulnerabilities move from disclosure to usable attack paths almost immediately,” according to Wysopal. Secure-by-design imperative The real response to these challenges ought to be in reducing the amount of exploitable software reaching production in the first place rather than encouraging CISOs to “patch faster.” Secure-by-design engineering, aggressive pre-release testing by top-tier bug hunters, architectural mitigations that shrink whole bug classes, and the ability to rebuild or isolate exposed systems quickly are all necessary but perhaps insufficient. The old assumption that defenders get a grace period after disclosure is no longer credible, according to Wysopal. “We are watching the collapse of the traditional patch window in real-time,” Wysopal emphasizes. “Secure by design is the only sustainable response, because once disclosure happens, the attacker’s clock is already ticking.” View the full article

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

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

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

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

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

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