CSOonline

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For more than two decades, cybersecurity has been built on a reactive model: detect intrusions, patch vulnerabilities, respond to incidents, and repeat. That model is now under sustained pressure from a threat environment that is faster, more coordinated, and increasingly automated. Two recent developments illustrate how quickly that model is breaking down. Earlier this month, the White House released its long-awaited cyber strategy that elevates proactive or offensive cybersecurity to the top of its priorities. At this year’s RSA Conference, Sandra Joyce, who leads Google’s Threat Intelligence Group, unveiled the company’s threat disruption unit, outlining plans to use legal authorities and technical capabilities to thwart cyber threat groups actively. Together, these developments reflect a shift already under way — from purely defensive models toward efforts to disrupt adversaries before attacks reach their targets. “What we’ve been doing for the past 20 years hasn’t been working,” Glenn Gerstell, former general counsel of the National Security Agency and now senior adviser at the Center for Strategic and International Studies, tells CSO. “We have been inherently playing catch-up on defense … and the gap is getting wider.” That assessment is now shaping both government strategy and private-sector operations. The United States is explicitly trying to shape adversary behavior rather than absorb attacks, while major technology providers are investing in capabilities designed to disrupt threat actors before they reach their targets. The shift is often described as “proactive cyber” or “active defense,” but the language obscures how constrained — and how operational — the change actually is. The collapse of response time The urgency behind that shift is grounded in how quickly modern attacks now unfold. The traditional sequence — initial access, lateral movement, data exfiltration — has collapsed into tightly coordinated, near-simultaneous activity across multiple actors. “The median time between initial access and the handoff to the secondary threat group has dropped from eight hours in 2022 to just 22 seconds in 2025,” Joyce emphasized during an RSA keynote. That compression reflects a broader structural change. Cyber operations are no longer linear campaigns but ecosystems, where access brokers, operators, and monetization specialists operate in parallel. Artificial intelligence is accelerating that model by automating key phases of exploitation and movement. “Agentic approaches for exploit development will allow adversaries to outpace human-driven controls,” Joyce said. John Hultquist, chief analyst at Google Threat Intelligence Group, says that once an intrusion is under way, defenders are already behind. “Active defense is looking for opportunities outside of the castle walls, before the actor shows up inside or starts hitting the castle walls.” Gerstell describes the same imbalance more bluntly. “The bad guys … have the advantage,” he says. What ‘proactive cyber’ means Despite the more aggressive language, this shift toward private-sector involvement doesn’t envision vigilante-style payback by aggrieved organizations. It instead embraces a more systematic effort to interfere with adversaries earlier in the attack chain using authorities and capabilities that already exist. “To be clear, this is not hacking back,” Joyce said. “This is the legal and ethical use of intelligence to protect our own platforms.” In practice, that approach combines civil litigation, coordinated takedowns, public exposure of tools, and product hardening. The goal is to impose cost and friction across the ecosystem rather than to stop individual intrusions. “Our goal is to shift the economics of the entire ecosystem, to make cyber threat operations so costly, so difficult, so risky, that it is no longer a viable path for any adversary,” Joyce said. Hultquist underscores that this kind of disruption has real but limited effects. “We’re looking for operations that will have a longer-lasting effect on adversaries, or we can repeat at such a tempo that we can actually maintain the effect,” he says. That dynamic is central to how proactive cyber is now being framed. Disruption is not a permanent solution; it is a way to degrade adversary capability and buy time. Gerstell offers a practical boundary for where that activity becomes more controversial. “If you’re doing something only on your own network, it sounds defensive,” he says. “If you’re doing something on somebody else’s network, it sounds offensive.” Why the private sector is central The shift toward proactive cyber is rooted in who controls the terrain. “The private sector operates the very infrastructure that adversaries abuse,” Joyce said. At the same time, the scale of cyber threats exceeds what the government can handle alone. “There’s no world in which the government can do all the things,” Cynthia Kaiser, former FBI cyber deputy director and now SVP at Halcyon, tells CSO. “When I was at the FBI, there was no world in which you could do all the things.” That has led to a push for deeper operational integration between government and industry, combining private-sector visibility and speed with public-sector authority. Adam Maruyama, former CTO and DoD and NSA analyst and counterterrorism expert, says the shift toward more proactive action is necessary but lacks clear rules. Acting earlier in the attack chain, he notes, raises questions about how those operations should be conducted across jurisdictions and how they should be coordinated with allies. “Once you start acting outside your own network, you’re immediately dealing with questions of jurisdiction and coordination,” Maruyama tells CSO. “Those aren’t fully worked out.” Without that clarity, more assertive disruption efforts risk creating friction even among partners, particularly when infrastructure sits outside US control. National Cyber Director Sean Cairncross framed the goal as correcting an imbalance. “The risk calculus on our adversary side in this space doesn’t seem to be calibrated correctly,” he said at the McCrary Institute Cyber Summit in March. But Cairncross drew a clear boundary around private-sector action. “I am not talking about private sector industry or companies engaging in a cyber offensive campaign,” he said. “That’s not what we’re talking about.” The fault lines: How far is too far Agreement on the need to act earlier does not extend to agreement on how far those actions should go. Kaiser sees a practical path in focusing on criminal actors, where legal authorities are clearer, and escalation risks are lower. “I think the least risky way in which industry can help on this front is with criminal actors,” she says, pointing to infrastructure takedowns and recovery of stolen funds. She also argues that legal frameworks may need to evolve. “The primary thing I’d like to see is re-looking at the laws as they exist now and seeing if there are ways in which industry can help more with taking down infrastructure and clawing back stolen funds,” she says. Others are more cautious. Maruyama points to the complexity of globally distributed infrastructure. “What if their infrastructure is hosted not in North Korea, but in France … or a semi-allied country like Malaysia?” he asks. Hultquist reinforces caution from an operational standpoint, but stresses the importance of effectiveness in targeting. That is one reason why Joyce said in her keynote that whatever tactic Google uses against adversaries, it intends for them to “stay burned.” He says, “We are committed to operations that have lasting effects.” Who can do this Even if those tensions are resolved, the ability to carry out proactive disruption is concentrated among a small number of actors. “This is something that Google can do [and that] Microsoft has done and can do,” Gerstell says. “A medium-sized company probably can’t.” The requirements include not just technical capability but legal authority, operational scale, and control over infrastructure. Large platform providers can act within environments they own and can absorb the risks associated with disruption. Most enterprises cannot. Even among organizations that could act, willingness varies. “Some of them could do it, but don’t want to,” Gerstell says. What should CISOs do? For enterprise security leaders, the shift toward proactive cyber does not expand their mandate to take on offensive or disruption roles. Instead, reinforcing core cybersecurity fundamentals remains the priority. “The basic blocking and tackling is still critical,” Gerstell says. Kaiser frames the enterprise role as participation rather than initiative. “What more can we all do?” she asks, particularly in supporting takedowns and recovery efforts where industry can act “more quickly and nimbly than the government can.” That participation requires operational readiness: the ability to share telemetry quickly, preserve evidence, and respond in real-time when providers or law enforcement act against adversary infrastructure. For CISOs, that means upstream disruption does not reduce the need for internal resilience. Even as governments and large cybersecurity providers increase pressure on attackers, enterprises should expect continued activity — often from the same actors operating in slightly different ways. At the same time, the legal limits remain clear. Acting outside an organization’s own environment introduces risks that most enterprises are not equipped to manage. The practical role for CISOs is not to become more aggressive, but to operate effectively in a system where others increasingly handle disruption. View the full article

I recently had the opportunity to review five popular SIEM solutions as part of a judging panel for a Security award. While each platform had its own unique flair, their core promises were remarkably consistent: 24/7/365 SOC monitoring: Round-the-clock coverage backed by global experts to validate and prioritize alerts. Proactive threat hunting: Active searches for hidden threats rather than just waiting for automated triggers. AI and machine learning integration: Leveraging everything from basic anomaly detection to “Agentic AI” to reduce noise and accelerate investigations. Active incident response and containment: Capabilities to isolate endpoints or disable compromised users to stop lateral movement. Third-party tool integrations: Ingesting telemetry from the “native stack” and third-party tools like CrowdStrike or Microsoft Defender. Continuous intelligence updates: Constant streams of new detection rules and playbooks based on global research. Service level guarantees: Financial credits or pricing adjustments for broken SLOs. These offerings are impressive, yet a glaring omission stood out: none of them discussed how they handle multi-tenancy. In a cloud-native world, it is very likely that most if not all of these providers operate on shared infrastructure. This means they are not immune to the “noisy neighbor” effect, a phenomenon where a single misbehaving tenant can degrade the security posture of everyone else on the platform. The noisy neighbor effect As security operations move toward cloud-native frameworks to handle the exponential growth of telemetry data (often reaching petabytes of logs), they rely on the elasticity of software-as-a-service (SaaS). However, the sharing of physical resources (including CPU, memory and I/O) among independent customers introduces a significant engineering risk. When one tenant’s workload consumes a disproportionate share of these resources, it creates a bottleneck. For other tenants, this translates to increased ingestion latency, delayed threat detection and violated SLAs. In security, a “delayed” alert is often as useless as no alert at all. The multi-tenant paradox The core appeal of multi-tenant SIEM solutions is efficiency: shared infrastructure leads to lower costs and unified management. Yet, without deliberate engineering, this becomes a zero-sum game. In a naive system, a high-volume tenant can saturate the ingestion pipeline, causing “starvation” for smaller tenants. This breaks the real-time detection and response (RTDR) promise that these companies market so heavily. The key distinction is that multi-tenancy does not have to be zero-sum. The fairness strategies explored in this article exist precisely to prevent that outcome, but only if vendors have invested in them. The silence in marketing materials suggests many have not. Why fairness is an engineering problem Engineering “fairness” is not merely about setting hard limits; it is about sophisticated resource orchestration. I highly recommend reading AWS’s paper on fairness in multitenant systems. A rigid cap might protect the system, but punish a client during a genuine security emergency when they need ingestion capacity most. Conversely, a completely open system is vulnerable to cascading failures. To solve this, engineers must move beyond simple rate-limiting and embrace “fair share” scheduling, intelligent queuing and dynamic resource allocation. This article explores the architectural strategies required to ensure that every tenant receives the performance they were promised, even when their neighbor’s house is on fire. The anatomy of a modern SIEM To understand where fairness fails in a multi-tenant environment, we must first dissect the anatomy of a modern SIEM. It is no longer a monolithic database, but a distributed data pipeline designed to ingest, transform and analyze petabytes of telemetry. This pipeline relies on decoupling producers from consumers using message queues, ensuring that a spike in one layer does not necessarily lead to a total system failure. The ingestion layer The Ingestion Layer is the system’s front door. It is responsible for collecting raw telemetry from diverse sources such as EDR agents, cloud APIs and firewalls. To handle the “firehose” of incoming data, which can spike unpredictably during a security incident, this layer does not process data immediately. Instead, it acts as a high-throughput buffer, writing raw events directly into a raw event queue (typically Apache Kafka). This decoupling is critical because it ensures that even if downstream processing layers are slow, the system can still accept incoming logs without data loss. The normalization layer The normalization layer consumes raw events from the initial queue. Its primary role is to bring order to chaos by parsing heterogeneous log formats (JSON, XML or Syslog) into a structured schema like the common information model (CIM). This involves CPU-intensive tasks such as regex matching, field extraction and enrichment. Once processed, these structured events are published to a second normalized event queue. This central bus becomes the single source of truth for all downstream consumers. The rule-based detection layer (real-time) The first consumer of the normalized queue is the rule-based detection layer, often powered by engines like Apache Flink in the last 2-3 years. This layer is optimized for speed, executing low-latency, rule-based logic on events as they flow through the pipe. It handles high-volume, simple detections, such as “five failed logins in one minute,” in milliseconds. By alerting on these patterns immediately, it reduces the time-to-detect for critical threats without waiting for data to be indexed. The ad-hoc search layer Parallel to the streaming engine, the ad-hoc search layer also consumes from the normalized queue. This system (often utilizing Elasticsearch or Splunk indexers) is optimized for human interaction. It indexes the data to support sub-second search and retrieval, enabling security analysts to perform investigations and threat hunting. While the streaming layer finds known threats, this layer helps analysts find the unknown ones through interactive querying. The storage layer (long-term retention) Simultaneously, a third consumer reads from the normalized queue to persist data into the storage layer. This layer is architected for durability and cost-efficiency, typically writing data to object storage (like Amazon S3) in a columnar format (such as Parquet). This “cold storage” ensures compliance with data retention policies at a fraction of the cost of the high-performance search tier, effectively decoupling retention from compute. The analytics and correlation layer (batch) Finally, the analytics and correlation layer operates by consuming data from the storage layer. Unlike the streaming engine, which looks at individual events in motion, this layer executes complex queries over vast historical datasets. It runs scheduled jobs to detect sophisticated patterns, such as “beaconing to a rare domain over thirty days,” that require analyzing long time windows. By reading from storage rather than the real-time stream, it isolates these resource-intensive jobs from the ingestion and search pipelines. Summary of SIEM layers LayerPrimary FunctionKey ChallengeIngestionCollects raw logs and buffers them into a Raw Queue.Handling massive throughput spikes without data loss.NormalizationParses raw logs into a common schema and publishes to a Normalized Queue.High CPU overhead from regex parsing and enrichment.Rule-based detectionConsumes normalized stream for fast, rule-based alerting.Managing state and windowing for millions of concurrent entities.Ad-hoc searchIndexes normalized data for fast, interactive investigation.Unpredictable resource consumption from complex analyst queries.StoragePersists normalized data for long-term retention.Optimizing file formats (Parquet or Avro) for efficient read and write.AnalyticsExecutes complex batch queries against storage.Scheduling long-running jobs without impacting other workloads. Strategies to encode fairness Without deliberate intervention, shared infrastructure will always favor the loudest voice. To build a resilient SIEM, engineers must implement strategies that enforce isolation and ensure equitable resource distribution. These strategies generally fall into three categories: admission control, tenant-aware scheduling and resource partitioning. Admission control and rate limiting The first line of defense is at the very front of the ingestion pipeline. Admission control ensures that a single tenant cannot flood the raw event queue beyond a certain threshold. However, modern SIEMs move beyond “hard” rate limits (where data is simply dropped) and instead use “soft” limits or shaping. A common approach is the token bucket algorithm. Each tenant is allocated a certain number of tokens per second, representing their licensed ingestion rate. During a spike, they can consume accumulated tokens to “burst” above their limit for a short duration. Once the bucket is empty, the system might begin “shaping” the traffic, introducing slight delays to the ingestion of that specific tenant’s logs to protect the system’s global stability without immediately discarding critical security data. In practice: A tenant contracted at 10,000 events per second might be permitted to burst to 15,000 EPS for up to 60 seconds by drawing on their accumulated token reserve. A real incident generating 20,000 EPS would exhaust the bucket and trigger shaping: their logs slow down, but nothing is dropped. Meanwhile, every other tenant on the platform continues processing at full speed. Tenant-aware fair share scheduling Inside the processing layers (such as normalization or analytics), the system must decide which tenant’s tasks to execute next. In a naive “first-in, first-out” (FIFO) model, a massive batch of logs from one tenant will block everyone else. Engineers solve this by implementing weighted fair queuing (WFQ). Instead of one giant queue for all events, the system maintains virtual queues for each tenant. The scheduler cycles through these queues, picking a small batch of events from each. This ensures that a small tenant with only ten events per second never has to wait behind a large tenant processing ten million. This “interleaving” of processing tasks guarantees that every customer makes progress, regardless of their neighbor’s activity. In practice: In a Kafka-backed SIEM, this is implemented by assigning each tenant their own partition (or partition group) within a topic. Normalization consumers are then configured to process a bounded number of records per tenant per poll cycle, cycling through partitions in round-robin order. A tenant generating a 50x spike in log volume gets their own partition filling up, but the consumer never spends more than its fair share of processing time on that partition before moving to the next tenant. Virtual resource isolation (quotas and reservations) For components like the ad-hoc search layer, where resource usage is highly unpredictable, engineers use resource partitioning. This involves setting up logical boundaries within the shared compute pool. Through resource quotas, the SIEM provider can cap the maximum CPU and memory a single tenant’s queries can consume at any given time. Some advanced architectures take this a step further with guaranteed reservations. A high-tier customer might be guaranteed a specific percentage of the cluster’s resources, ensuring that even during a global system spike, their SOC analysts can still run search queries with the same sub-second latency they expect. In practice: In Elasticsearch, this is implemented via a combination of search thread pool sizing per node and query-level circuit breakers. A tenant’s queries can be routed to a dedicated set of nodes (using shard allocation filtering), and the circuit breaker limits can be configured per tenant at the coordinating node layer. The result is that a runaway analyst query generating an expensive aggregation across 90 days of data will hit its memory ceiling and fail gracefully, rather than cascading across the entire cluster. Per-tenant buffering and decoupled processing In a highly resilient SIEM, I favor that backpressure (where a downstream failure forces the front-end to stop accepting data) should be avoided. Instead of pressuring the ingestion layer to stop, the system utilizes the queues positioned between each layer as shock absorbers. By implementing per-tenant virtual partitions within these queues, the system can ensure that a bottleneck in the storage or search layers only affects the processing speed of the responsible tenant. If one tenant’s data is being written too slowly, their specific virtual queue grows, while others continue to process at full speed. This results in delayed detection for the “noisy” tenant, but it guarantees data completeness. The system eventually catches up without ever dropping a log or impacting the real-time performance of the rest of the platform. The ultimate isolation: Physical vs. logical The strategies above address fairness within shared infrastructure. But for certain organizations, the right answer is no sharing at all. In a modern cloud environment, it is entirely feasible to provision and allocate an entire, independent SIEM stack per tenant. This “cluster-per-tenant” model eliminates the noisy neighbor problem entirely because there are no neighbors. Each customer’s ingestion pipeline, normalization workers, search nodes and storage buckets are fully dedicated to their own workload. The compliance implications alone make this worth serious consideration. Frameworks like FedRAMP, ITAR and CJIS often have explicit or implicit requirements around compute and data isolation that a shared multi-tenant cluster cannot satisfy without significant architectural gymnastics. A dedicated cluster satisfies these requirements cleanly, reduces audit surface area and simplifies the evidence chain during compliance reviews. The trade-off is cost. Dedicated clusters carry substantially higher per-tenant overhead: idle compute must be provisioned to handle peak loads, management complexity scales with cluster count and the economies of scale that make shared SaaS attractive are partially surrendered. In practice, providers who offer this model typically charge a meaningful premium (often 2-3x the multi-tenant equivalent) and reserve it for enterprise or public sector customers with specific regulatory requirements. The practical framework for security leaders evaluating this decision is straightforward. If your organization operates under a compliance framework that names compute or data isolation as a requirement, start with the dedicated cluster conversation. If your primary concern is detection performance and cost, invest time instead in understanding how deeply a vendor has engineered fairness into their shared environment, because that engineering is what determines whether the multi-tenant promise holds when it matters most. Conclusion The silence regarding multi-tenancy in major SIEM marketing is a risk that security leaders should not ignore. As telemetry volumes continue to explode, the engineering behind “fairness” becomes just as important as the AI detecting the threats. An ideal SIEM solution should offer the best of both worlds: the flexibility of a multi-tenant cluster where fairness is deeply engineered into every layer, combined with the option to deploy dedicated, physically isolated clusters for organizations with extreme performance or compliance needs. Until SIEM providers are transparent about how they manage the noisy tenants next door, the promise of 24/7/365 protection remains vulnerable to the activity of a neighbor you didn’t even know you had. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

DPRK-linked threat actors are preferring stealth over sophistication in targeting South Korean organizations, as researchers report the use of weaponized Windows shortcut (.LNK) files and GitHub-based command-and-control (C2) channels in a new campaign. According to new Fortinet findings, a series of attacks that began in 2024 were found using a multi-stage scripting process and GitHub C2 to evade detection, with obfuscation improving with each iteration of the campaign. “In recent months, the threat actor has altered their tactics,” Fortinet researchers said in a blog post. “They now embed decoding functions within LNK arguments and include encoded payloads directly inside the files.” The ongoing campaign seems to be targeted at expanding DPRK’s surveillance within South Korea. The researchers noted that lesser obfuscation and heavier metadata in the previous iterations of the campaign allowed them to link it to attacks spreading the XenoRAT malware. Jason Soroko, senior fellow at Sectigo, believes the strategy aligns with the recent trend of attackers relying on built-in Windows utilities and legitimate services to carry out their objectives. “Modern cyber espionage has fundamentally shifted toward a highly evasive strategy known as living off the land,” he said, noting that attackers are increasingly abusing native tools like PowerShell and scheduled tasks to blend into normal system activity. LNK files are long known for their history of exploitation, with Microsoft issuing multiple patches and advisories over the years to curb their misuse. LNK files used as stealth loaders The campaign begins its infection with a Windows shortcut file, which is typically used to launch applications or open documents, but can also embed commands to execute scripts or binaries. “A .lnk file is how Windows handles shortcuts: Whenever you click on that Outlook icon on your desktop, you’re actually clicking on a separate file that uses the Outlook image and directs the operating system to open up Microsoft Outlook,” explained Jamie Boote, senior manager, strategic security consulting at Black Duck. “You can also create shortcut links (.lnk files) to websites, programs with additional commands, executable scripts, and just about anything else you could type into Windows’s Run command window.” The LNK files in the campaign use various scripts, including earlier versions with simple character concatenation to mask GitHub C2 address and the access token, the researchers said, adding that it was easy to determine that the script was meant to run a PowerShell command fetched from GitHub. Later versions shifted to basic character decoding functions, making detection a little trickier, but still had telling metadata like name, sizes, and modification dates that allowed researchers to connect it to the specific campaign. The name column repeatedly uses “Hangul document,” a pattern consistent with state-affiliated groups like Kimsuky, APT37, and Lazarus. In its latest iteration, the campaign operators have removed the identifying metadata, now using only a decoding function within the arguments. GitHub as C2 Researchers also highlighted the campaign’s use of GitHub as a C2 layer. Rather than communicating with suspicious-looking or newly registered domains, the malware interacts with GitHub repositories and APIs to receive instructions and exfiltrate data. “The fact that this shortcut file creates a chain that ultimately reaches out to a GitHub repository, and pulls scripts over the internet, should put network defenders on alert that even productivity platforms can be attack vectors,” Boote added. After infecting a system, the PowerShell scripts perform system checks to confirm the environment isn’t under analysis, ensure the malware persists after system reboot through the Scheduled Task, and collect detailed system information. Only then is a stable connection attempted with subsequent scripts, where additional modules and instructions are fetched from the attacker’s GitHub repository. The researchers flagged a GitHub account, “motoralis”, with consistent activity dating back to 2025, and other less frequent accounts, including “God0808RAMA,” “Pigresy80,” “entire73,” “pandora0009,” and “brandonleeodd93-blip.” Additionally, the blog post shared a set of URLs and hash functions to support detection efforts. View the full article

Authentication keeps breaking where it matters most: On regulated front lines such as healthcare, government, aerospace and travel. The core issue is not a lack of innovation. Instead, it is a brittle and fragmented ecosystem of cards, readers, middleware and software that rarely work together under real-world pressure. Even today’s “passwordless” solutions can be undermined by poor implementation, downgrades and fallback paths that attackers are quick to exploit. This article examines where these failures occur, why they persist and offers a practical blueprint for CISOs to guide their organizations and vendors toward resilient, phishing-resistant and field-ready authentication. The problem: Brittle by design Authentication is supposed to be the most reliable control in your security stack. Yet in many enterprises, it is often the most fragile because there are too many moving parts: Credential types, readers (contact, contactless, dual frequency), protocols, middleware, identity platforms and device operating system nuances. Any minor mismatch — such as an unexpected identifier format, a driver quirk, a browser nuance or a rushed patch — can quickly turn a mission-critical login into a service desk crisis. This is not just a theoretical risk; it is a daily reality for operations teams who must keep care units, field agents and front of house operations running smoothly. Sector snapshots: Where it breaks (and why that matters) Healthcare. Clinicians need tap and go speed with zero tolerance for downtime. One large hospital attempted to pair advanced HID SEOS credentials, which use privacy-preserving randomized IDs, with a clinical SSO platform that expects static IDs for user recognition. This architectural mismatch forced a choice between stronger privacy and reliable workflows. The project stalled until the team reverted to technology compatible with static IDs. In healthcare, even a minor glitch can quickly escalate into a patient safety incident. State & local government. Agencies rolled out unified FIDO2 credentials to cover both door access and laptop logons. However, they soon discovered that many rugged laptops did not include the low-frequency antenna needed for physical access. Teams either split credentials, which defeated the purpose or added external readers, which increased cost and complexity. Field users ended up carrying multiple badges and dongles, which is the opposite of resilience. Aerospace and Travel. Aerospace organizations that adopted proprietary card ecosystems, such as LEGIC encountered licensing constraints that limited which readers they could purchase and how quickly they could scale globally. In the travel sector, a cruise line’s shift to wristband credentials faced challenges with FIPS 201 requirements, which were designed for cards rather than wearables. This forced the company into custom engineering solutions. In these cases, innovation moved faster than standards and operational teams had to manage the consequences. Root causes: Why the ecosystem is stuck Fragmentation across layers. Cards like SEOS, LEGIC, DESFire and FIDO2, mixed with contact, contactless and dual‑frequency readers and identity stacks such as Imprivata, Windows Hello, Okta and Ping rarely interoperate cleanly. A change in any layer can trigger unexpected failures across the system. Downgrades and fallback weaknesses. Authentication remains only as strong as its weakest backup path. Adversary‑in‑the‑middle and downgrade attacks routinely bypass phish‑resistant flows, as shown in CSO reporting on FIDO passkey downgrade exploits and ongoing MFA‑fatigue attacks. These gaps quietly reintroduce risk despite modern authentication advances. Patch fragility. Platform updates often break authentication flows, with CSO documenting cases where Windows updates disrupted smart card logons and Windows Hello for Business. These incidents, including the ones covered in Microsoft updates, knock out key enterprise functions. And Windows Hello for Business authentication issues, show how sensitive authentication stacks are to version drift. Vendor lock‑in and standards gaps. Proprietary licensing and uneven SDKs limit flexibility and slow upgrades. Progress toward interoperability profiles is emerging, but only when customers demand it. Okta’s IPSIE standard is one example, though broad adoption still depends on pressure from buyers. The path forward: 3 architectural shifts that can help Three architectural shifts can significantly improve reliability and reduce unexpected failures. These approaches are not mutually exclusive and can be combined for maximum effectiveness on a single platform. 1) Modular secure elements (SEs) embedded or in SIM form Device-bound cryptography, tamper resistance, ultra-low-power states and tighter OEM control over firmware and BIOS all raise the baseline for security and reliability. This is especially valuable in rugged or clinical environments, where device identity and offline resilience matter. Embedded secure elements help here by removing dependence on external readers and unstable drivers, though they introduce their own tradeoffs such as vendor lock‑in, added board and firmware complexity and reliance on specialized parts that can create yet another integration challenge if no common profile exists. The most effective way to adopt them is to start with a narrow, high‑value fleet like emergency carts, field supervisors or flight line tablets, pairing the secure element with a hardened, signed image and an offline‑ready authentication posture so it can serve as the root of trust for both login and data at rest. 2) Middleware standardization (make the reader/credential layer pluggable) Middleware becomes the universal bridge that smooths out card and reader quirks, giving you a stable way to integrate with identity platforms like Entra, Okta, Ping or Imprivata while normalizing identifiers, enforcing anti‑downgrade logic and capturing every strange edge case for rapid incident response. It comes with its own hurdles, including unclear ownership, upfront integration work and competing SDKs, yet once it’s in place you separate authentication behavior from device idiosyncrasies and vendor swaps, which is a major win for operations. The cleanest path is to stand up a credential abstraction layer with clear policies that block legacy fallbacks on high‑risk apps, enforce phishing‑resistant flows and log any downgrade decisions as security events sent to the SOC, while also applying session‑protection controls that blunt adversary‑in‑the‑middle attacks. 3) Unified credential ecosystem (the “USB‑C moment” for authentication) Standard behavior across readers, middleware and identity providers creates a calmer edge environment, cutting down on surprise failures and the weekend firefighting that follows patch cycles. The model isn’t free—you need industry coordination, legacy bridges and steady change management—but the direction is already set toward credential abstraction with multiprotocol support and reference integrations that vendors certify together. The cleanest way to land this is through RFP requirements that demand multiprotocol credential handling, verified reader and IdP compatibility, documented anti‑downgrade behavior and clear runbooks for regression handling after OS or IdP updates, with payments and renewals tied directly to meeting those standards. CISO action plan: 5 moves that change outcomes this quarter Kill the weakest link: Remove silent fallbacks. Identify where passwordless flows still revert to legacy prompts such as SMS, voice, OTP or simple approval pushes. On systems handling money, PHI or privileged access, disable or tightly control these paths. If a fallback is unavoidable, require identity verification and alert the SOC for review. Downgrade paths and MFA fatigue attacks often succeed because weak backups are left in place, as detailed here. Demand downgrade transparency in your tooling. Require your IdP or middleware to log every downgrade event and block scripted browser or agent spoofing that drives users into fake “unsupported browser” flows. Downgrade bypasses in passkey and FIDO flows have been demonstrated in the wild, so your stack should make these attempts easy to detect and simple to shut down. A clear example is outlined here. Harden for patch turbulence (assume authentication regressions). Create a pre‑prod integration gauntlet that exercises smart cards, passkeys, Windows Hello key trust and your clinical or field SSO flows. Hold broad deployment until the gauntlet passes and keep a one‑click rollback and a ready‑to‑send communications script. Recent Windows updates have shown how quickly authentication can break at scale, so build muscle‑memory playbooks before Patch Tuesday. Examples include Write interoperability into contracts. RFPs should call out multi‑protocol credential abstraction, certified reader and IdP pairings, FIDO2 and passkey support without insecure fallbacks and alignment with emerging interoperability profiles. Vendors are already moving in this direction and Okta’s IPSIE standard is one example worth citing. Pick the right pilot: Constrained, high‑value and visible. Start where downtime is costly and users are already trained, such as ICU stations, air‑side operations or revenue desks. Pair embedded secure‑element devices with reader‑agnostic middleware and strict anti‑downgrade policies. Track MTTR for authentication incidents, downgrade frequency and help‑desk volume, then publish the results to justify a broader rollout. The long view: Resilience over fashion Passkeys and FIDO2 move authentication in the right direction when they are deployed without porous fallbacks and with integrations that behave consistently under pressure. Their security and usability advantages are clear, yet real‑world usage has also shown how adversary‑in‑the‑middle techniques and weak backup paths can undermine those gains. These issues are not reasons to slow adoption but reminders to approach implementation with discipline. To build authentication that remains stable even as systems evolve, we need interoperability, anti‑downgrade behavior as the default and graceful failure modes. That means using modular hardware where it fits, relying on reader‑agnostic middleware with enforceable policy and pushing for a unified credential experience that vendors certify and customers insist on. Components exist today; what’s missing is the resolve to wire them together. Do not invest in another point solution until your contracts, runbooks and pilots reflect these principles. Authentication should be the calmest, most predictable part of your stack, not the source of your next incident. The building blocks for resilient, interoperable authentication already exist. What’s missing is resolve. Now is the time for security leaders to set the standard and demand better. Make authentication work for you, not against you. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Attackers are starting to exploit AI systems to mount attacks in the same way they once relied on built-in enterprise tools such as PowerShell. Instead of relying on malware, cybercriminals are increasingly abusing AI tools enterprises depend on — a trend some experts describe as living off the AI land. “We’re seeing it in things like poisoned MCP servers in the supply chain, attackers using legitimate models like Claude to extract sensitive data, and even viral agents like OpenClaw accidentally causing destructive actions,” says Kaushik Shanadi, CTO at Helmet Security, a startup focused on securing agentic AI communications. “The problem is most of these systems were deployed before anyone stopped to think about governance or security.” The shift from simple prompt injection to “agent hijacking” represents a fundamental change in the AI threat landscape, other security experts told CSO. “Attackers are no longer just trying to trick a chatbot; they are living off the AI land, abusing the same legitimate automation and memory features that make AI assistants useful,” says Pascal Geenens, VP of cyber threat intelligence at cybersecurity vendor Radware. Below are some examples of how attackers are subverting AI-based services to stage attacks. MCP server impersonation In September 2025, attackers promoted a counterfeit model context protocol (MCP) server mimicking technology to integrate Postmark, a transactional email service owned by ActiveCampaign, into AI assistants. The fake MCP server package looked legitimate and functioned as a legitimate tool across 15 versions before a single-line code change was introduced that meant sensitive communications — password resets, invoices, internal memos — were silently siphoned off for days before the hack was detected. The malicious package, which attracted 1,500 downloads per week on the popular node.js package registry, exposed enterprises that relied on the tool to a form of supply chain attack. “This is the AI equivalent of name-squatting a package registry, except there’s no central MCP authority verifying server identity and no cryptographic link between an MCP server and the organization it claims to represent,” says Brad Micklea, CEO at Jozu, an AI security and MLOps platform. “This breaks the trust model before the MCP is deployed.” MCP servers — which allow AI agents and chatbots to connect to data sources, tools, and other services — have recently become the target of varied (for example against Cursor’s built-in browser) and sustained malicious attacks. Locking down these systems to minimize risks has become a priority for enterprise CISOs. “These servers expose tools, memory, and APIs to AI agents so they can perform tasks,” says Zahra Timsah, PhD, CEO of i-GENTIC AI, an agentic AI governance platform. “If an attacker inserts a poisoned tool, modified connector, or malicious retrieval source into that chain, the AI agent can unknowingly execute it.” Abusing AI platforms as covert C2 channels Cybercriminals are also abusing AI platforms as covert command-and-control (C2) channels by turning AI services into proxies that hide malicious traffic inside the flow of legitimate content. Instead of running a dedicated C2 server, malware is programmed to fetch commands and exfiltrate data through AI services, circumventing traditional security controls in the process. For example, the SesameOp backdoor hid command traffic inside the OpenAI Assistants API, camouflaging instructions to malware as normal AI development activity. This is far from an isolated example and the potential for misuse is rife. For example, Check Point Research demonstrated how Microsoft Copilot and Grok might be manipulated through their public web interfaces to fetch attacker-controlled URLs and return responses. This behavior opens the door to abuse of AI systems without requiring an API key or authenticated account. Dependency poisoning in AI workflows Rather than attacking an AI system directly some assaults have relied on poisoning downstream dependencies that an agent relies on for data processing. In one case, a compromised NPM package was injected into an agentic workflow’s dependency chain. “This mirrors classical supply chain attacks (e.g. SolarWinds), but a poisoned dependency in an agentic pipeline doesn’t just leak data — it can alter the agent’s decision-making, tool selection, or output without any visible anomaly,” says Jozu’s Micklea. Double agents Some attackers are weaponizing vulnerabilities in agents rather than abusing components of an enterprise’s legacy IT infrastructure. For example, the “EchoLeak” command injection vulnerability in Microsoft 365 Copilot (CVE-2025-32711) shows that a single email with concealed prompt-injection instructions is sufficient to force the AI assistant to exfiltrate internal files and emails to an external server without user interaction. A series of vulnerabilities (such as CVE-2026-25253) in OpenClaw, the popular open-source personal AI assistant, created a route for a malicious website to take complete control of the developer’s AI agent. “More than 21,000 such instances were detected, and the researchers further observed that 12% of the skills marketplace for the OpenClaw platform was distributing malware,” says Dr. Suleyman Ozarslan, VP of Picus Labs at Picus Security, a specialist in breach and attack simulation. Security researchers at Varonis discovered an attack against Microsoft Copilot Personal that sidestepped built-in AI safeguards simply by asking for sensitive data twice. The Reprompt vulnerability — which effectively turned Microsoft Copilot into a data exfiltration tool — was reported to Microsoft, which has responded by issuing a patch. AI-orchestrated espionage campaigns Anthropic caught threat actors abusing Claude Code to manage operational tasks in a cyber-espionage campaign in September 2025. A suspected Chinese state-sponsored group designated GTG-1002 used Claude Code to execute 80-90% of tactical operations independently, at physically impossible request rates for human operators. Attackers abused the AI agentic capabilities of Claude Code to automate the process of scripting, target research, building attack tooling, and other functions. “The attackers decomposed their operation into thousands of small, individually innocuous tasks, combined with role-play framing that convinced the model it was operating as part of a legitimate security assessment,” explains Yagub Rahimov, CEO at cybersecurity startup Polygraf AI. Creating modular black-hat AI platforms The threat landscape has shifted from abusing chatbots to building dedicated, weaponized AI stacks like Xanthorox AI. Unlike general-purpose LLMs, Xanthorox is a purpose-built offensive platform designed specifically for cybercrime. The platform features modules for functions such as malware generation and vulnerability exploits. “Hexstrike AI Model Context Protocol (MCP) integration allows Xanthorox to move beyond mere ‘assisted’ hacking into the realm of fully autonomous agent systems, moving it into the realm of ‘vibe hacking,’” says Radware’s Geenens. Hexstrike is an open-source, AI-powered offensive security framework originally designed for ethical penetration testing. Check against delivery Zbyněk Sopuch, CTO of cybersecurity vendor Safetica, says that many attackers are no longer just exploiting software vulnerabilities, preferring instead to exploit the trust organizations place in AI. “This means security teams need to treat AI assistants the same exact way they treat human privileged users: with tight control, specific monitoring, and most importantly, never assume anyone or anything to be safe,” Sopuch concludes. View the full article

Over the years, enterprise cybersecurity environments have accumulated staggering numbers of commercial tools. Industry research converges on a consistent picture of tool proliferation that drives complexity, cost, and risk. The global cybersecurity market is valued at approximately $243 billion in 2024 and projected to surpass $520 billion annually by 2026. Commercial off-the-shelf (COTS) software promises speed and maturity, while avoiding years of custom development. At first, everything works out perfectly, and the decision feels justified. However, over time, the organization might shift its goals, integrate with other systems, or even decide to move away from the software entirely. This is when real problems start to appear, and teams suddenly realize just how difficult it is to move on. Making basic changes might take ages, replacing the systems feels risky, and the organization is stuck in a conundrum. What we call the “COTS trap”. The cost of COTS dependency becomes most visible when organizations attempt to switch platforms. Migration failure statistics underscore the depth of architectural entanglement that COTS platforms create. It’s because the system around it was designed in such a way that it makes the software hard to abandon. COTS dependency in cybersecurity is structural, expensive, and accelerating. Organizations that fail to implement architectural countermeasures face compounding costs, diminished strategic flexibility, and increasing vulnerability to both cyber threats and vendor disruption. What is COTS, and why do people like it? COTS (short for commercial off-the-shelf software) refers to ready-made software usually sold online or in retail stores. They come with preconfigured functionalities right out of the box, hence they need little to no modifications. Examples include: IAM GRC IGA Threat detection platform Most enterprises like them because: They already ”work.” They deploy easily and quickly. Reduced long-term expenditure as promised by vendors. At a glance, these benefits are compelling. The challenges arise when the software becomes more than a tool and starts shaping the architecture itself. Emerging dynamics: AI and the next wave of lock-in Artificial intelligence represents both the next frontier of cybersecurity capability and the next vector of vendor dependency. McKinsey’s 2024/2025 study identifies AI as expanding the total addressable cybersecurity market to $2 trillion. AI-driven security platforms, from behavioral analytics to automated threat detection to AI-powered SIEM, create new forms of COTS dependency. AI models are trained on proprietary datasets, use vendor-specific threat intelligence feeds (62% of enterprise deployments integrate threat intelligence consuming 2.4 billion daily indicators of compromise), and require specialized compute infrastructure. The investment in AI-based detection models creates a new category of switching cost: retraining models, re-establishing behavioral baselines, and losing institutional threat intelligence. Organizations adopting AI-native security platforms face the risk that their threat detection effectiveness becomes linked to a single vendor’s model training data and algorithmic approach. How vendor lock-in forms in enterprise security architectures Vendor lock-in rarely happens overnight. Instead, it emerges gradually as technical and business decisions accumulate. How? Embedded business logic After using the software for a while, the enterprise gets comfortable, and important rules such as pricing logic and validations end up being buried within the software. With time, the enterprise gradually loses direct control over its own logic. Vendor-shaped workflows “That’s how the system works” has quickly become an excuse for most businesses to change workflows to match the software’s limits. This means a lot of processes will either be simplified, bent, or even deemed “good enough”, just because changing them feels too hard. Platform-native customization When changes are needed, teams usually add custom scripts, configurations, and extensions to ensure the software fits even better. And even though this might be practical, even necessary at that time, they are usually tailored to that particular vendor’s platform. Data entanglement Put simply, your data becomes trapped in formats and structures that only the vendor understands. Reading it becomes hard, slow, and expensive. This makes moving on difficult as the data holds the enterprise hostage. Architectural patterns that break the COTS trap Escaping the COTS trap doesn’t mean avoiding commercial software. It means designing systems so the software never becomes the point of control. Solution 1: The anti-corruption layer This simply means having a buffer between your systems and the software. Its core purpose is to ensure the two don’t communicate directly. It acts as the translator so that your systems continue speaking your business language. The vendor system remains a tool, not the architectural foundation for your business model. Solution 2: Process abstraction pattern Don’t allow the software to dictate how you’ll run your enterprise. Instead, you should define your system independent of the vendor’s software. The software should only be used to perform specific tasks. That way, it will be way easier for you to change your business model without replacing the entire software. Not just that, you can also replace the software without affecting your business model. Solution 3: Event-driven integration Point-to-point integrations usually tighten systems together. Event-driven integration prevents this by sharing simple facts about what has happened, rather than issuing direct requests. This allows systems to act independently, evolve at their own pace, and be replaced without affecting others. Solution 4: Strangler fig pattern Changing systems should always be done slowly and not all at once. Replace small pieces step by step. Allow the old and new systems to run together. Gradually move your users and data. In case something goes wrong, it will be easier to stop and retrace your steps without crashing the system. Solution 5: Data sovereignty strategy Your most crucial data should always reside within your system under your control. Vendor platforms receive copies, not ownership. This will allow you to easily move, integrate, or even replace systems without losing access to your data. Designing for replaceability: Architectural principles This is where most enterprises get it all wrong. Treating COTS software as the final solution from the get-go. Once selected, purchased, and installed, everything else around it has to adapt to it. Most processes are bent, data models stretched, and architecture redefined to fit what the software requires. The outcome? Replacing it becomes unthinkable. This kind of thinking is the real problem, not the software itself. COTS was designed to improve productivity and efficiency. It wasn’t meant to define your long-term structure. In today’s ever-changing landscape, nothing is guaranteed to remain the same. Software that fits today will not always fit tomorrow. Hence, systems should be designed with the assumption that the vendor platform can be replaced anytime the business changes its goals, market shifts, regulations evolve, or strategies get rewritten. When you approach it in this way, you become flexible by default. You remain in charge of your own systems, and you don’t surrender control to vendors. Most importantly, you do away with last-minute rewrites that occur when change is forced. The goal here isn’t to switch platforms constantly, but to ensure that you can do it when you need to. That’s what it means to design enterprise systems you can walk away from. Conclusion: Flexibility matters in architectural design The cybersecurity industry’s COTS dependency is not a failure of procurement. It is a structural characteristic of a market growing at 10–15% annually, with 3,000+ vendors competing for enterprise budgets. The $212 billion spent on cybersecurity in 2025 flows overwhelmingly through COTS channels, creating dependencies that are expensive to establish, costly to maintain, and extraordinarily difficult to exit. Purchasing the most powerful commercial off-the-shelf software doesn’t always guarantee success. Successful enterprises are those whose systems are built to adapt to any platform change. That also doesn’t mean that COTS software is bad, and that you shouldn’t use it. Rather, you should know how to use it. Most enterprises miss the mark by treating these vendor platforms as the foundation for their entire architecture, rather than what they actually are: a tool and nothing more. Given the confusion around this, most enterprises usually end up stuck in a no-win situation simply because their systems are forced to mimic what the vendor platform wants, not the other way around. To get the best out of any COTS software, clear boundaries should be set, and strong domain ownership established. Because, at the end of it all, good architecture isn’t just picking the best platform. It’s more about ensuring that the choice you make today doesn’t limit your options later. Flexibility matters a lot in the architectural design of any enterprise system. It ensures that the organization remains functional and survives any unforeseen changes. Such freedom is what allows enterprises to get the best out of these platforms. Organizations that architect for strategic independence from day one transform the COTS dependency from a trap into a tool, leveraging commercial platforms for their strengths while retaining the flexibility to adapt, migrate, and evolve at the pace of business need rather than vendor roadmap. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article