CSOonline

Days after Microsoft patched a high-severity issue affecting its Windows Defender antivirus tool through April’s Patch Tuesday, researchers warn of another vulnerability that could enable SYSTEM privileges through local escalation. In a newly disclosed proof-of-concept (PoC) exploit, dubbed “RedSun,” GitHub user going by the name “Nightmare Eclipse” demonstrated how Microsoft Defender’s handling of certain cloud-tagged files can be abused to overwrite protected system files and escalate privileges. “When Windows Defender realizes that a malicious file has a cloud tag, for whatever stupid and hilarious reason, the antivirus that’s supposed to protect decides that it is a good idea to just rewrite the file it found again to its original location,” Eclipse wrote in the PoC repository description. The PoC exploit impacts Windows 10 and Windows 11 systems running Microsoft Defender, specifically builds with cloud files features enabled. Antivirus rewrites the threat The RedSun PoC highlights a counterintuitive behavior. Defender’s remediation process may restore a flagged file under certain conditions. Specifically, files tagged with cloud metadata (such as those used by OneDrive and similar services) trigger a different handling path inside the antivirus engine. Rather than permanently removing the malicious file, Defender attempts to restore it to its original source, rewriting the file back to disk. The PoC exploits this mechanism to, during the rewrite process, manipulate the file contents or destination. If an attacker can control the timing and location of the rewrite, they can replace legitimate system binaries or configuration files with malicious payloads. RedSun demonstrated this exploit to gain SYSTEM-level privileges. Will Dormann from Infosec Exchange verified the PoC using the Cloud Files API. “This works ~100% reliably to go from unprivileged user to SYSTEM against Windows 11 and Windows Server 2019+ with April 2026 updates, as well as Windows 10, as long as you have Windows Defender enabled,” he said. “Any system that has cldapi.dll should be affected.” Dormann used the Cloud Files API to introduce a specially crafted file, followed by “oplock“ to control file access timing. From there, the exploit leverages Volume Shadow Copy race conditions and directory junctions/reparse points to redirect where Defender writes the file. Second Defender-based LPE in days The Defender flaw addressed earlier this week as part of Patch Tuesday was one of the two zero-day bugs Microsoft fixed, and it also allowed local privilege escalation stemming from “insufficient granularity of access control.” While Microsoft attributed the discovery of the flaw, tracked as CVE-2026-33825, to security researcher Zen Dodd, the flaw already had a PoC exploit, “BlueHammer,” available before it was even fixed. It came from “Chaotic Eclipse,” an alias used by Nightmare Eclipse on other publishing platforms. The flaw received a high-severity rating of 7.8 out of 10. Eclipse has some disagreements with how Microsoft handled the disclosure of CVE-2026-33825. While it is unknown if “RedSun” was reported to Microsoft before disclosure, the PoC still sits unaddressed. Microsoft did not immediately respond to CSO’s requests for comments. Dormann confirmed that the exploit is being detected on VirusTotal, but relies heavily on a test file signature (EICAR), which can be handled to some extent with string encryption. “Defender (Microsoft) currently doesn’t detect the exploit in either case,” he noted. View the full article

Days after Microsoft patched a high-severity issue affecting its Windows Defender antivirus tool through April’s Patch Tuesday, researchers warn of another vulnerability that could enable SYSTEM privileges through local escalation. In a newly disclosed proof-of-concept (PoC) exploit, dubbed “RedSun,” GitHub user going by the name “Nightmare Eclipse” demonstrated how Microsoft Defender’s handling of certain cloud-tagged files can be abused to overwrite protected system files and escalate privileges. “When Windows Defender realizes that a malicious file has a cloud tag, for whatever stupid and hilarious reason, the antivirus that’s supposed to protect decides that it is a good idea to just rewrite the file it found again to its original location,” Eclipse wrote in the PoC repository description. The PoC exploit impacts Windows 10 and Windows 11 systems running Microsoft Defender, specifically builds with cloud files features enabled. Antivirus rewrites the threat The RedSun PoC highlights a counterintuitive behavior. Defender’s remediation process may restore a flagged file under certain conditions. Specifically, files tagged with cloud metadata (such as those used by OneDrive and similar services) trigger a different handling path inside the antivirus engine. Rather than permanently removing the malicious file, Defender attempts to restore it to its original source, rewriting the file back to disk. The PoC exploits this mechanism to, during the rewrite process, manipulate the file contents or destination. If an attacker can control the timing and location of the rewrite, they can replace legitimate system binaries or configuration files with malicious payloads. RedSun demonstrated this exploit to gain SYSTEM-level privileges. Will Dormann from Infosec Exchange verified the PoC using the Cloud Files API. “This works ~100% reliably to go from unprivileged user to SYSTEM against Windows 11 and Windows Server 2019+ with April 2026 updates, as well as Windows 10, as long as you have Windows Defender enabled,” he said. “Any system that has cldapi.dll should be affected.” Dormann used the Cloud Files API to introduce a specially crafted file, followed by “oplock“ to control file access timing. From there, the exploit leverages Volume Shadow Copy race conditions and directory junctions/reparse points to redirect where Defender writes the file. Second Defender-based LPE in days The Defender flaw addressed earlier this week as part of Patch Tuesday was one of the two zero-day bugs Microsoft fixed, and it also allowed local privilege escalation stemming from “insufficient granularity of access control.” While Microsoft attributed the discovery of the flaw, tracked as CVE-2026-33825, to security researcher Zen Dodd, the flaw already had a PoC exploit, “BlueHammer,” available before it was even fixed. It came from “Chaotic Eclipse,” an alias used by Nightmare Eclipse on other publishing platforms. The flaw received a high-severity rating of 7.8 out of 10. Eclipse has some disagreements with how Microsoft handled the disclosure of CVE-2026-33825. While it is unknown if “RedSun” was reported to Microsoft before disclosure, the PoC still sits unaddressed. Microsoft did not immediately respond to CSO’s requests for comments. Dormann confirmed that the exploit is being detected on VirusTotal, but relies heavily on a test file signature (EICAR), which can be handled to some extent with string encryption. “Defender (Microsoft) currently doesn’t detect the exploit in either case,” he noted. View the full article

In two decades, Palo Alto Networks has evolved from a next-generation niche player to one of the largest global cybersecurity giants today. Under its mantra of “platformization,” the company has catapulted its revenues over its closest competitors and boosted its stock valuation to over $130 billion. No stranger to AI use in cybersecurity, Palo Alto recently announced its participation in Project Glasswing, an AI-based vulnerability-discovery initiative led by Anthropic that many are viewing as a structural shift for the cyber industry. The initiative, which includes 10 other major technology companies as coalition partners, including AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, and Microsoft, aims to leverage Anthropic’s Claude Mythos to improve the security of the software that underpins much of the world’s technical infrastructure. It is in this context that Computerworld Spain spoke with Helmut Reisinger, CEO of Palo Alto Networks for EMEA, in Madrid at the company’s Ignite event on April 14. The interview was conducted in Spanish, a language that the multilingual Austrian executive and PhD holder speaks fluently. Following are excerpts from that interview, edited for length and clarity. Computerworld Spain: Let’s start with the recent announcement of Palo Alto’s participation in the exclusive Mythos project, which few companies have access to due to the power of this technology and the risk of it falling into the wrong hands. Or is this just a marketing strategy? Helmut Reisinger: Indeed, this is a restricted release that only a few companies can access for vulnerability testing. We’ve witnessed firsthand how this pioneering model represents a radical shift. With it, we’ve detected zero-day vulnerabilities in an unprecedented number of operating systems and browsers. And it’s capable of turning most of these vulnerabilities into working exploits, with all the risks that entails. For now, we can’t say much more. We’re currently working on providing more information through a blog. In any case, the important thing is the context in which this is happening. On the democratization of AI. Yes. At Palo Alto, we’ve been using AI to improve cybersecurity for a long time. Back in 2014, we integrated machine learning technology into our systems, initially just firewalls. But we also develop cybersecurity solutions specifically for AI. The major challenge today is that, according to a Stanford University report, only 6% of AI deployments are implemented with appropriate cybersecurity. And this is happening in the age of agents, where for every human identity there are approximately 80 machine identities, and even more if we include agents. That’s why, thanks to our acquisition of Protect AI, a company founded by Ian Swanson, formerly head of AI at Amazon, we’ve launched a security solution for AI deployments, language models, and agents. This is just one of several purchases Palo Alto has made recently, correct? Yes, we just closed the deal [in February] with CyberArk, a leader in identity security. At Palo Alto, we’re convinced that AI and identity are two worlds that must go hand in hand, especially now in the era of generative systems and agents. Another acquisition we recently completed, in January, and which falls within this context of addressing the current AI landscape, is that of Chronosphere, a leader in observability. Chronosphere is capable of managing and protecting massive volumes of AI-generated data at a lower cost — half the price — of other market players. This is an important acquisition because observability is essential in cybersecurity. And finally, we’ve acquired Koi, a deal I expect will close in a few days. Koi’s technology focuses on agentic endpoint security — protecting businesses from the risks of using AI agents and autonomous development tools operating on users’ devices. Koi’s technology will be integrated into our Cortex XDR platform to monitor what AI agents are doing on users’ computers and detect if they are being manipulated to execute malicious commands. I imagine effectively integrate all these companies presents significant challenges. That’s right, because many IT companies, when they make acquisitions, focus more on contractual than technological integrations, but that’s not our approach. Our strategy involves complete technological integrations, like Protect AI, which is now part of our network platform. This aligns with our commitment to platformization using a modular system. It’s clear that ‘platformization’ is the company’s mantra and a way to simplify life for customers, but doesn’t it also create greater dependencies, including vendor lock-in? Yes, we sometimes hear clients say they don’t want to put all their eggs in one basket. But that’s precisely why our strategy is modular, so the client can decide. It’s also true that all the clients who have experienced a massive data breach have opted for complete platformization. In fact, our founder [Nir Zuk] has always said that “everyone will switch to platforms as soon as they suffer a mega-breach.” The speed of platform adoption, therefore, will be determined by the client themselves, their business, their use cases, their existing contracts, and so on. We are also making efforts to reduce costs to encourage clients to migrate and simplify their platformization process. Furthermore, we mustn’t lose sight of the fact that the approach to cybersecurity must be comprehensive; it’s a global chain. Regarding cost, Palo Alto has a reputation for having powerful but expensive technology. What’s your opinion? Compared to the level of protection we provide our customers, our technology isn’t that expensive. On the other hand, the cost also reflects all the innovation included in our solutions. How do you see Palo Alto Networks’ major competitors, primarily Fortinet and CrowdStrike? The cybersecurity market is fragmented, but we lead it. That said, we have to win every single day. The current, highly turbulent geopolitical climate is having a significant impact on the cybersecurity field, as well as on customers’ IT purchasing decisions. Does being a US player in Europe affect Palo Alto? Are you seeing a shift among public sector clients toward more local options? CISOs with high levels of responsibility know very well that a wealth of telemetry data is essential for effective protection, and that’s why we aren’t seeing a decrease in demand. That’s the primary reason. Furthermore, each region and country has its own legal frameworks and regulations, which we fully respect. In fact, we were among the first companies in the world to sign the European AI Act and ensured we also obtained the corresponding national certifications. Our view on sovereignty is that we must find a balance between perfect sovereignty and zero sovereignty. When we talk about sovereignty, we can refer, for example, to hardware. Regarding this issue, we must accept the interdependence we have between different global markets; this happens, for example, in the field of chips. But if we talk about data sovereignty, this is something that can be easily achieved. We implement the Bring Your Own Key (BYOK) policy for many clients to ensure that the telemetry data sent by their devices is encrypted and protected. We are not interested in accessing the personal data our clients handle; we only use telemetry, application identity, user, and device data. It was precisely thanks to this type of analysis that we were able to discover the attempted intrusion using SolarWinds, although, as it occurred years ago [2020], it was carried out using machine learning tools. How is the current war in Iran affecting the threat landscape? This has many implications. Our Unit42 team recently published a report outlining how the joint military offensive launched by the United States and Israel activated the Iranian-aligned cyber ecosystem, creating a scenario of digital confrontation that transcends the region and combines hacktivism, political messaging campaigns, and pressure on critical infrastructure. In this regard, I want to bring up the issue of sovereignty again because what can a company do if its infrastructure is, for example, bombed? In other words, what does the concept of sovereignty mean in an emergency situation? We already have clients in the Middle East who are rethinking their sovereignty strategy because of this situation. Furthermore, as we saw earlier, we are talking about telemetry data, not other types of data. Ultimately, all of this shows that the concept of sovereignty is fluid. Returning to Europe, in less than two months Palo Alto will be opening new offices in Spain and, in addition, a ‘hub’, correct? Yes, we want to establish a center of excellence here. In Europe, in addition to Madrid, Palo Alto has large offices in London, Amsterdam, Paris, and Munich. From Madrid, Jordi Botifoll has been leading the business for 87 countries — not only in Southern Europe, but also in the Middle East, Africa, etc. — for the past three years. And what are your expectations for the new center of excellence? Why have you chosen Spain? Cybersecurity requires a lot of technological expertise, and Spain has very good engineers who can help our clients in case of emergency, both through our incident response unit, Unit 42, and through our partners, such as Telefónica Tech, Kyndryl, and Orange, because ours is a technology company, not a service company. How many employees do they have in Spain, and what will the number of employees be at the new center? I can’t break down local numbers, but overall, across the entire company, once the 4,000 CyberArk professionals are integrated, we’re already around 20,000 people worldwide. Our main development centers are in California and Israel, although we also have others in Poland and Lithuania. Looking ahead, significant challenges in information security are coming with the arrival of the post-quantum era. Yes, and we’re already preparing. We’ve launched Quantum Safe Security to help organizations get ready for the post-quantum era. Because the big question scientists and experts are asking now is when ‘Q Day’ will be, which might arrive sometime between 2029 and 2035. Furthermore, integrating CyberArk technology will help ensure that credentials used by machines cannot be compromised through quantum decryption. The cybersecurity of the future must be real-time, highly automated, and simple for customers, or what we call modular ‘platformization.’ Finally, what would you say is the biggest challenge for CISOs today? Shadow AI. We must prevent AI from suffering the same fate as other technologies in the past, creating what’s known as shadow IT. AI deployments must be accompanied by robust cybersecurity. And AI and identity management must go hand in hand. Another concern is the fragmentation of solutions. I was recently speaking with an executive at a large European bank who told me they have 60 different solutions; the gaps between these systems are a clear invitation to attack. View the full article

In einem falschen Security-Mindset gefangen? Foto: Paul Craft – shutterstock.com Dass Jobs im Bereich Cybersecurity ein hohes Burnout-Potenzial aufweisen, ist längst kein Geheimnis mehr: Das Umfeld von Sicherheitsprofis ist vor allem geprägt von dem (gefühlten) Druck, täglich steigenden Anforderungen gerecht werden zu müssen. Dafür sind diverse Gründe ursächlich – in erster Linie aber die Art und Weise, wie über Security gedacht wird. Die gute Nachricht: Wenn Sie ein schädliches Mindset identifizieren, können Sie es verändern und sowohl sich als auch Ihre Teams besser für den Erfolg positionieren. Cybersicherheit ist ein hochtechnisches Gebiet und in gewisser Hinsicht eine harte Wissenschaft. Auf der anderen Seite ist sie aber auch stark von Elementen der Psychologie und Moral geprägt. Wie effektiv die IT-Sicherheit letztlich ausfällt, hängt auch vom Mindset und den Überzeugungen der Fachkräfte und Entscheider auf diesem Gebiet ab. Sollten Sie eines der folgenden sechs Mindsets an den Tag legen, ist Arbeit angesagt, damit ein gesünderes Security-Umfeld gedeihen kann. 1. “Security ist ein Ziel” Ein besonders heimtückisches Security-Mindset ist die Überzeugung, dass es sich um eine Reise mit Start- und Zielpunkt handelt. Zu dieser Überzeugung kommt man (hoffentlich) nicht bewusst – Profis ist klar, dass es sich um eine kontinuierliche Aufgabe handelt. Unterbewusst kann es aber durchaus dazu kommen, dass es zu vorübergehender Untätigkeit kommt, wenn bestimmte Tasks gerade erledigt wurden. Das führt allerdings nur dazu, dass alle im Team mehr unnötigen Stress haben. Denn wer ein Ende in Aussicht stellt, erzeugt ein subtiles Gefühl der Enttäuschung oder gar des Scheiterns, sobald offenbar wird, dass es doch immer noch etwas mehr zu tun gibt. Zur Ruhe werden Sie (und Ihr Team) erst kommen, wenn sie akzeptieren, dass Security ein fortlaufender Prozess ist. 2. “IT-Sicherheit ist nur was für Profis” Die Auffassung, dass Security ausschließlich in den Händen der entsprechenden Spezialisten liegt, führt zu zweierlei unglücklichen Konsequenzen: Alle anderen Mitarbeiter werden – zumindest gefühlt – aus der Verantwortung entlassen. Sicherheitsprofis werden auf subtile Weise in eine Einzelkämpferrolle gedrängt. Softwareentwickler sollten Security in jeder Phase des Lebenszyklus im Hinterkopf behalten, statt sich erst zur Auslieferung damit zu befassen. Das gilt jedoch auch für alle anderen Mitarbeiter im Unternehmen: Nur wenn Awareness herrscht, kann die Gefahr von Cyberangriffen minimiert werden. Natürlich kommt den Sicherheitsexperten diesbezüglich eine führende, beziehungsweise leitende Rolle zu. Letztendlich sollte sich aber jeder Mitarbeiter dazu befähigt fühlen, zur allgemeinen Unternehmenssicherheit beitragen zu können. Eine gemeinschaftliche Aufgabe stärkt davon abgesehen auch das Wir-Gefühl. 3. “Security wird immer nur diffiziler” Kaum etwas ist entmutigender als eine klassische Sisyphos-Aufgabe. Dieser Eindruck kann allerdings leicht entstehen, wenn es um Security geht: Cyberkriminelle werden immer raffinierter und nutzen immer bessere Tools, während die digitale Infrastruktur, die geschützt werden muss, sich immer umfangreicher, komplexer und vernetzter gestaltet. In der Realität ist der Kampf zwischen White und Black Hats ein ständiges Geben und Nehmen. Das Phänomen Ransomware ist ein gutes Beispiel: Eine Zeit lang schienen sich Verschlüsselungstrojaner zu einer Plage zu entwickeln – inzwischen hat sich die Sicherheitsbranche entsprechend weiterentwickelt und messbar zurückgeschlagen. Indem Sie die zyklische Natur der IT-Sicherheit akzeptieren, befähigen Sie sich dazu, eine Haltung einzunehmen, die die richtige Balance zwischen Entspannung und Wachsamkeit findet. Mentales Gleichgewicht ist der Schlüssel zu langfristigem (Security-)Erfolg. Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. Jetzt CSO-Newsletter sichern 4. “Sicherheit ist ein Produkt” Die IT Security wird nicht selten als Standalone-Funktion oder Zusatzprodukt betrachtet, die über die zugrundeliegende Infrastruktur “gestülpt” wird oder als konkrete “Sache”, die finalisiert und ausgeliefert werden muss. Das ähnelt ein bisschen der einstigen Perspektive auf Qualität im Allgemeinen als eine eigenständige, separate Komponente der Dinge. Um es mit Aristoteles zu sagen: “Qualität ist keine Handlung, sondern eine Gewohnheit”. Security wiederum ist wie Qualität kein fertiges Produkt, sondern (wie bereits angemerkt) eine fortlaufende Disziplin. Sicherheit als eine Praxis zu betrachten, die ständig verfeinert werden muss, setzt die dafür nötige Energie frei. Sie sollten es als Segen betrachten, in einem Bereich zu arbeiten, der kontinuierlich Raum für Wachstum und die Möglichkeit bietet, Ihre Skills vollumfänglich zur Geltung zu bringen. Haben Sie dieses Mindset verinnerlicht, gilt es, das mit dem gesamten Unternehmen zu teilen. Security sollte in keinem Fall wie ein Produkt ausgeliefert werden, denn sie ist keine Begleiterscheinung oder ein Hilfsmittel. Vielmehr sollte sie der Treiber für Kultur und bewusstes Handeln sein. Kurzum: IT-Sicherheit sollte Teil des täglichen Doings sein – auf individueller und organisatorischer Ebene. 5. “Die Kriminellen treiben die Security” Security-Profis, die kontinuierlich damit beschäftigt sind, Brände zu löschen, können zur Überzeugung kommen, dass die Cyberkriminellen das Spiel beherrschen. Diese reaktive Perspektive auf die IT-Sicherheit sorgt für Frustration und ein Gefühl der Machtlosigkeit. In der Realität haben die Unternehmen das Ruder in der Hand: Sie sind es schließlich, deren Assets für Kriminelle verlockende Ziele darstellen. Die Angreifer sind in den meisten Fällen nicht zu unterschätzen – es ist jedoch das Business, dass die Sicherheit treibt. 6. “100 Prozent reicht gerade” Gute Sicherheit braucht messbare Faktoren. Metriken wie die “Mean Time to Detect” (MTTD) ermöglichen es, die Situation zu monitoren und die Effektivität von Programmen zu messen. Problematisch wird es in diesem Bereich, wenn Sie der Vorstellung erliegen, dass sich sämtliche Indikatoren stets in eine positive Richtung – oder noch schlimmer im “perfekten” Bereich – bewegen müssen. Diese unrealistische Erwartung ist ein Einfallstor für verzerrte Messwerte. Stattdessen sollten Sie Metriken eher als Wegweiser sehen, die Sie ans Ziel bringen können. Der Schlüssel liegt jedoch darin, die nötigen Schritte zu unternehmen und Maßnahmen einzuziehen, um die Dinge in die richtige Richtung lenken. Das macht es essenziell, sich ehrlich mit Messungen auseinanderzusetzen. (fm) View the full article

Admins who use Cisco Webex Services configured to use trust anchors within the SSO integration with Control Hub must install a new identity provider certificate to close a critical vulnerability, or risk losing access control. Cisco said in an advisory this week that admins must upload a new identity provider (IdP) SAML certificate to Webex Control Hub, the web-based management portal where IT administrators can control all Cisco Webex services, including certificate management, meetings, messaging and calling. Failure to close this hole will allow an unauthenticated, remote attacker to impersonate any user within the service. The vulnerability, CVE-2026-20184, carries a CVSS score of 9.8. Because Webex is a cloud service, Cisco can, and has, patched its side of the application. But admins using single-sign on (SSO) still need to install the new certificate. There are no workarounds. A Webex support article on managing SSO integration says that information about certificates is found in the Webex Control Hub Alerts center, where customers can view which ones are installed, and their status. The Control Hub also contains an SSO wizard to aid in updating certificates. The article contains step-by-step details on the process. Asked for comment, and for more details about the vulnerability, a Cisco spokesperson didn’t go beyond the advisory. “Cisco published a security advisory disclosing a vulnerability in the integration of single sign-on with Control Hub in Cisco Webex Services,” the spokesperson said. “At the time of publication (April 15) Cisco had addressed the vulnerability, and was not aware of any malicious use of this vulnerability. Affected customers must update their SAML certificate to ensure uninterrupted services.” Gartner analyst Peter Firstbrook noted in an email that, since Cisco has applied the patch to the cloud service, this is more of a configuration change. But that doesn’t minimize the possible damage. “While we are not aware of exploits using this vulnerability, users can lose SSO access to Webex without this change,” he said. “This does illustrate a bigger trend that identity and access management is the corporate perimeter,” he added, “and the majority of attacks include an identity and access management component. CISOs must increase their focus on IAM hygiene, particularly as agentic computing is accelerating.” Identity and access management is, of course, the keystone of cybersecurity. As Crowdstrike observed in its 2026 Global Threat Report, abuse of valid accounts accounted for 35% of cloud incidents it investigated last year, “reinforcing that identity has become central to intrusion.” Single sign-on allows a user to authenticate to multiple applications through one set of credentials. It’s efficient, and, of more importance to a CSO, strengthens security. Additional critical fixes The Webex flaw is one of three critical vulnerabilities Cisco identified and issued patches for this week. In addition, multiple vulnerabilities have to be patched in Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC). These holes (CVE-2026-20147 and CVE-2026-20148, which carry CVSS scores of 9.9), could allow an authenticated, remote attacker to perform remote code execution or conduct path traversal attacks on an affected device. To exploit these vulnerabilities, the attacker must have valid administrative credentials, and send a crafted HTTP request to an affected device. There are no workarounds. Separately, two more vulnerabilities were found in ISE that could lead to remote code execution on the underlying operating system of an affected device. To exploit these vulnerabilities (CVE-2026-20180 and CVE-2026-20186), the attacker would only need Read Only Admin credentials. View the full article

Admins who use Cisco Webex Services configured to use trust anchors within the SSO integration with Control Hub must install a new identity provider certificate to close a critical vulnerability, or risk losing access control. Cisco said in an advisory this week that admins must upload a new identity provider (IdP) SAML certificate to Webex Control Hub, the web-based management portal where IT administrators can control all Cisco Webex services, including certificate management, meetings, messaging and calling. Failure to close this hole will allow an unauthenticated, remote attacker to impersonate any user within the service. The vulnerability, CVE-2026-20184, carries a CVSS score of 9.8. Because Webex is a cloud service, Cisco can, and has, patched its side of the application. But admins using single-sign on (SSO) still need to install the new certificate. There are no workarounds. A Webex support article on managing SSO integration says that information about certificates is found in the Webex Control Hub Alerts center, where customers can view which ones are installed, and their status. The Control Hub also contains an SSO wizard to aid in updating certificates. The article contains step-by-step details on the process. Asked for comment, and for more details about the vulnerability, a Cisco spokesperson didn’t go beyond the advisory. “Cisco published a security advisory disclosing a vulnerability in the integration of single sign-on with Control Hub in Cisco Webex Services,” the spokesperson said. “At the time of publication (April 15) Cisco had addressed the vulnerability, and was not aware of any malicious use of this vulnerability. Affected customers must update their SAML certificate to ensure uninterrupted services.” Gartner analyst Peter Firstbrook noted in an email that, since Cisco has applied the patch to the cloud service, this is more of a configuration change. But that doesn’t minimize the possible damage. “While we are not aware of exploits using this vulnerability, users can lose SSO access to Webex without this change,” he said. “This does illustrate a bigger trend that identity and access management is the corporate perimeter,” he added, “and the majority of attacks include an identity and access management component. CISOs must increase their focus on IAM hygiene, particularly as agentic computing is accelerating.” Identity and access management is, of course, the keystone of cybersecurity. As Crowdstrike observed in its 2026 Global Threat Report, abuse of valid accounts accounted for 35% of cloud incidents it investigated last year, “reinforcing that identity has become central to intrusion.” Single sign-on allows a user to authenticate to multiple applications through one set of credentials. It’s efficient, and, of more importance to a CSO, strengthens security. Additional critical fixes The Webex flaw is one of three critical vulnerabilities Cisco identified and issued patches for this week. In addition, multiple vulnerabilities have to be patched in Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC). These holes (CVE-2026-20147 and CVE-2026-20148, which carry CVSS scores of 9.9), could allow an authenticated, remote attacker to perform remote code execution or conduct path traversal attacks on an affected device. To exploit these vulnerabilities, the attacker must have valid administrative credentials, and send a crafted HTTP request to an affected device. There are no workarounds. Separately, two more vulnerabilities were found in ISE that could lead to remote code execution on the underlying operating system of an affected device. To exploit these vulnerabilities (CVE-2026-20180 and CVE-2026-20186), the attacker would only need Read Only Admin credentials. View the full article

AI agent building tools enable users to configure Model Context Protocol (MCP) servers may be exposing systems to remote code execution due to an architectural decision in Anthropic’s reference implementation. At issue are unsafe defaults in how MCP configuration works over the STDIO interface, with broad implications for the agent ecosystem, according to a new report. “The blast radius is massive,” researchers from application security firm OX Security wrote in their report on the design issue. “This exploit allowed us to directly execute commands on six official services of real companies with real paying customers, and to take over thousands of public servers spanning over 200 popular open-source GitHub projects with hundreds of millions of downloads.” According to Anthropic and other MCP adapter developers, the STDIO command execution behavior is by design and the responsibility of sanitizing MCP configurations falls with developers of client applications. While this might be true, in practice OX Security found that few developers have attempted to filter commands in MCP configs and even those who did failed to catch all potential bypasses. The root of the issue MCP provides a standardized method for applications to expose data sources and tools to LLMs, improving their context and effectiveness in completing automated workflows. Originally developed by Anthropic, MCP has become a widely adopted technology in the agentic AI space. Anthropic provides reference MCP implementations in the form of SDKs for a variety of programming languages, including TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Furthermore, other frameworks and functionality providers — such as FastMCP, LangChain’s mcp-adapters, Microsoft’s agent-framework, mcp-agent, browser-use, Amazon’s run-model-context-protocol-servers-with-aws-lambda, and NVIDIA’s NeMo-Agent-Toolkit — have Anthropic’s modelcontextprotocol reference implementation as a dependency. MCP supports two transport interfaces between servers and clients: Streamable HTTP with Server-Sent Events (SSE), which is typically used for remote MCP servers and web services, and Standard Input/Output (STDIO), for MCP servers and applications that run locally on the same machine. With STDIO, client applications can start MCP servers on demand as a subprocess and pass parameters to them. These parameters can include custom commands that get executed on the system with the permissions of the parent process. While in theory these commands are meant to tell the SDK’s StdioServerParameters function how to start the MCP server, they can technically be anything if no filtering is in place. The OX Security researchers consider this a design flaw that should be mitigated, but Anthropic disagrees, as do the creators of other frameworks that enable MCP functionality, such as LangChain and FastMCP. The argument is that the responsibility for making sure malicious user input doesn’t reach the SDK’s command execution function resides with the developers of the client applications that integrate these MCP frameworks. “The pattern of allowing user-supplied strings to flow directly into a shell execution environment is an anti-pattern that should be deprecated,” the OX Security researchers said. Anthropic’s SDKs should implement a command allowlist by default that blocks sh, bash, powershell, curl, rm, and other high-risk binaries, they added. The core issue is that there’s currently no check in place to verify that a STDIO command is intended to initialize an MCP server rather than perform a malicious task. Furthermore, the researchers observed that even if the sent command fails to start the server, the SDK returns an error after the command has already been executed. All modern IDEs such as VS Code, Cursor, and Windsurf, as well as agentic coding CLIs like Claude Code, OpenAI Codex, and Gemini CLI, have built-in support for local MCP servers over STDIO. But so do countless other agentic AI frameworks and open-source tools and few of them implement STDIO command allow lists. RCE in real-world applications The OX Security researchers have spent the past few months testing MCP support in numerous tools, including live production services. They found and reported more than 30 RCE issues stemming from this STDIO design decision to multiple projects and 10 have received CVE IDs so far. Depending on how a tool implements MCP support and how it accepts user input, there are multiple attack vectors that exploit the lack of STDIO command filtering. For example, some services and tools have not disabled STDIO internally even though their user interfaces only allow configuring MCP servers with Streamable HTTP. This was the case for Letta AI and DocsGPT, two platforms that enable companies to create AI agents via both cloud services and local deployments. “An attacker crafting a network request for an MCP server configuration, and changing the transport type in the configured JSON to contain an STDIO type instead of SSE or HTTP, also adding an arbitrary command to the request’s payload, can achieve remote command execution,” the researchers said. Another attack vector is prompt injection leading to malicious MCP configurations. While all IDEs are technically vulnerable to this — websites may contain hidden instructions for LLM agents to modify local files — most IDEs prompt users before making modifications to MCP configuration files. The exception was Windsurf, which directly modified the MCP config by default, resulting in a zero-interaction command injection attack. Many other tools don’t apply filtering to MCP STDIO parameters, meaning any user with access to configure an MCP server gains code execution on the underlying server, including production servers in the case of SaaS deployments. Tools found vulnerable to this include LangFlow, GPT Researcher, LiteLLM, Agent Zero, LangBot, Fay Digital Human Framework, Bisheng, Jaaz, Langchain-Chatchat, and several others the researchers are not yet able to disclose. Some developers were aware of the issue and did attempt to harden their implementations with command whitelisting. However, the hardening was insufficient, and the OX Security researchers found simple bypasses. For example, Upsonic, an open-source framework for building AI agents, implements an allowlist that includes npx, which supports -c (—call), a flag that allows custom commands and shell scripts to be passed for npx to execute. The same bypass was observed in Flowise, another UI-based AI agent building framework that also restricts MCP configuration commands but allows npx. Anthropic (modelcontextprotocol), LangChain (langchain-mcp-adapters), FastMCP, the browser-use project, AWS (run-model-context-protocol-servers-with-aws-lambda), NVIDIA (NeMo-Agent-Toolkit), OpenHands, PromptFoo, Firebase Studio, Gemini CLI, Claude Code, GitHub Copilot, and Cursor technically include the MCP STDIO code that allows for arbitrary command execution. Their maitainers consider the command execution intended behavior or have declined to fix it because it is mitigated by other controls such as modifications requiring user interaction or the command execution happening inside sandboxed environments like Docker containers. See also: What CISOs need to know about new tools for securing MCP servers Top 10 MCP vulnerabilities: The hidden risks of AI integrations 6 ways attackers abuse AI services to hack your business View the full article

Overwhelmed by an escalating volume of security flaws, the National Institute of Standards and Technology (NIST) has announced significant changes to how it handles cybersecurity vulnerabilities and exposures (CVEs). Rather than commit to providing enrichment for all entries in its National Vulnerability Database (NVD), the agency will focus on just the most critical CVEs, which will “allow us to stabilize the program while we develop the automated systems and workflow enhancements required for long-term sustainability.” Starting immediately, NIST will focus on CVEs appearing in CISA’s Known Exploited Vulnerabilities (KEV) catalog. “Our goal is to enrich these within one business day of receipt,” the agency said. Other high-priority CVEs will also include those for software used in the federal government and for other critical software. All the other CVEs will still be added to the NVD, but will be categorized as “not scheduled,” meaning that NIST will no longer prioritize their enrichment. Broken by backlog According to NIST, a backlog of CVEs started to accumulate in early 2024, and the agency has been unable to clear it due to increasing submissions. Submissions grew by 263% between 2020 and 2025, according to the agency, with nearly one-third more vulnerabilities reported in Q1 2026 than the same time last year. The agency, which enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, now faces a total backlog of more than 30,000 CVEs, said Harold Booth, a technical and program lead at NIST, at this week’s VulnCon cybersecurity conference. SOURCE: https://www.cve.org/about/Metrics CSO As a result, NIST will now forego enrichment for all but the most critical of vulnerabilities. Backlogged CVEs received prior to March 1 will also be labeled “not scheduled.” None of those are critical vulnerabilities, NIST said, because those have always been handled first. “They’ve just come out and publicly stated, ‘We are never going to get through this backlog,’“ Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CSO. In addition, NIST will no longer calculate severity scores for CVEs submitted with scores provided by the reporting organization. Security leaders reliant on NIST enrichment will need to take stock of their technology inventories to see whether they fall under NIST’s priority list, Childs said. That’s not easy. “Discovery is one of the most difficult problems we’re dealing with,” he noted, adding that it’s also not clear what software actually falls into the priority category. “Software used by the federal government is a very vague statement.” Mounting CVE counts — with AI flaw discovery on the rise Childs is not surprised that CVEs numbers have been going up, citing AI as part of the reason why. “We’re already seeing more garbage CVEs — and more real CVEs — related to AIs,” he says. Dealing with these CVEs is going to be a massive problem for companies. “People still don’t patch,” he says. “And we’re going to quadruple the number of patches they’re going to have to deploy. How do we build our defenses across the entire enterprise? I don’t know if we’ll get there before the bad guys do.” According to the Forum of Incident Response and Security Teams (FIRST), 59,427 CVEs are expected to be submitted this year, up from a little over 48,000 in 2025. That makes 2026 the first year that CVEs will pass the 50,000 milestone. “The sheer velocity of vulnerability discovery and exploitation is unlike anything we’ve seen before,” FIRST CEO Chris Gibson told CSO. FIRST has also modeled “realistic scenarios” in which the total number of CVEs cracks 100,000 for 2026 — but that was in February, before Anthropic announced Mythos, its vulnerability-finding AI model many foresee as a structural shift for the cybersecurity industry. “And if it’s not Mythos, or whatever else is coming out now, something is going to come out next week,” said Empirical Security founder Jay Jacobs, who also leads the Exploit Prediction Scoring System special interest group at FIRST. Still, Jacobs is optimistic that turning to technology will help NIST deal with rising CVE volumes. “Harold Booth has a lot of experience and skill working with AI over the last few years,” Jacobs told CSO. “So I’m expecting him to bring some expertise and I hope we do see some AI news there.” Both large language models and AI agents are on the agency’s to-do list, as is old-fashioned robotic process automation (RPA), Booth said in his presentation at VulnCon, which Jacobs chairs. NIST also plans to delegate some of the work to CVE Numbering Authorities (CNAs), which includes security vendors and researchers. View the full article

Overwhelmed by an escalating volume of security flaws, the National Institute of Standards and Technology (NIST) has announced significant changes to how it handles cybersecurity vulnerabilities and exposures (CVEs). Rather than commit to providing enrichment for all entries in its National Vulnerability Database (NVD), the agency will focus on just the most critical CVEs, which will “allow us to stabilize the program while we develop the automated systems and workflow enhancements required for long-term sustainability.” Starting immediately, NIST will focus on CVEs appearing in CISA’s Known Exploited Vulnerabilities (KEV) catalog. “Our goal is to enrich these within one business day of receipt,” the agency said. Other high-priority CVEs will also include those for software used in the federal government and for other critical software. All the other CVEs will still be added to the NVD, but will be categorized as “not scheduled,” meaning that NIST will no longer prioritize their enrichment. Broken by backlog According to NIST, a backlog of CVEs started to accumulate in early 2024, and the agency has been unable to clear it due to increasing submissions. Submissions grew by 263% between 2020 and 2025, according to the agency, with nearly one-third more vulnerabilities reported in Q1 2026 than the same time last year. The agency, which enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, now faces a total backlog of more than 30,000 CVEs, said Harold Booth, a technical and program lead at NIST, at this week’s VulnCon cybersecurity conference. SOURCE: https://www.cve.org/about/Metrics CSO As a result, NIST will now forego enrichment for all but the most critical of vulnerabilities. Backlogged CVEs received prior to March 1 will also be labeled “not scheduled.” None of those are critical vulnerabilities, NIST said, because those have always been handled first. “They’ve just come out and publicly stated, ‘We are never going to get through this backlog,’“ Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CSO. In addition, NIST will no longer calculate severity scores for CVEs submitted with scores provided by the reporting organization. Security leaders reliant on NIST enrichment will need to take stock of their technology inventories to see whether they fall under NIST’s priority list, Childs said. That’s not easy. “Discovery is one of the most difficult problems we’re dealing with,” he noted, adding that it’s also not clear what software actually falls into the priority category. “Software used by the federal government is a very vague statement.” Mounting CVE counts — with AI flaw discovery on the rise Childs is not surprised that CVEs numbers have been going up, citing AI as part of the reason why. “We’re already seeing more garbage CVEs — and more real CVEs — related to AIs,” he says. Dealing with these CVEs is going to be a massive problem for companies. “People still don’t patch,” he says. “And we’re going to quadruple the number of patches they’re going to have to deploy. How do we build our defenses across the entire enterprise? I don’t know if we’ll get there before the bad guys do.” According to the Forum of Incident Response and Security Teams (FIRST), 59,427 CVEs are expected to be submitted this year, up from a little over 48,000 in 2025. That makes 2026 the first year that CVEs will pass the 50,000 milestone. “The sheer velocity of vulnerability discovery and exploitation is unlike anything we’ve seen before,” FIRST CEO Chris Gibson told CSO. FIRST has also modeled “realistic scenarios” in which the total number of CVEs cracks 100,000 for 2026 — but that was in February, before Anthropic announced Mythos, its vulnerability-finding AI model many foresee as a structural shift for the cybersecurity industry. “And if it’s not Mythos, or whatever else is coming out now, something is going to come out next week,” said Empirical Security founder Jay Jacobs, who also leads the Exploit Prediction Scoring System special interest group at FIRST. Still, Jacobs is optimistic that turning to technology will help NIST deal with rising CVE volumes. “Harold Booth has a lot of experience and skill working with AI over the last few years,” Jacobs told CSO. “So I’m expecting him to bring some expertise and I hope we do see some AI news there.” Both large language models and AI agents are on the agency’s to-do list, as is old-fashioned robotic process automation (RPA), Booth said in his presentation at VulnCon, which Jacobs chairs. NIST also plans to delegate some of the work to CVE Numbering Authorities (CNAs), which includes security vendors and researchers. “Among other things, we are pursuing efforts to determine how large language models and other machine learning tools can be leveraged to speed up analysis and enrichment tasks that are currently manual and labor-intensive,” Booth added in follow-up with CSO. This story has been updated to include added comment from Harold Booth on NIST’s AI plans. View the full article

Microsoft’s Windows Recall feature remains vulnerable to complete data extraction despite a major security overhaul, according to a cybersecurity researcher who says malware running in a user’s context can quietly siphon off everything Recall has captured, without administrator privileges, kernel exploits, or breaking encryption. Alexander Hagenah, executive director at Zürich-based financial infrastructure operator SIX Group, made the claim in a LinkedIn post, where he also published a proof-of-concept tool called TotalRecall Reloaded to demonstrate the issue. Hagenah first exposed Recall’s security flaws in 2024, forcing Microsoft to pull the feature from preview and rebuild it. Microsoft relaunched Recall in April 2025, saying the new architecture would restrict “attempts by latent malware trying to ‘ride along’ with a user authentication to steal data.” Hagenah said it does not. “When you use Recall normally, TotalRecall Reloaded silently holds the door open behind you and then extracts what Recall has ever captured. That is precisely the scenario Microsoft’s architecture is supposed to restrict,” he wrote in the post. Hagenah wrote in the post that he disclosed the research to Microsoft’s Security Response Center on March 6, submitting full source code and reproduction steps. Microsoft reviewed the case for a month and closed it on April 3, telling him the behavior “does not represent a bypass of a security boundary or unauthorized access to data.” “Microsoft says this is by design,” Hagenah wrote. “That worries me.” Hagenah’s research does not challenge Microsoft’s encryption, which he said is sound. The gap, he told CSO, is in how decrypted data is handled once it leaves the enclave. “Plaintext screenshots and extracted text end up in an unprotected process for display,” he told CSO. “As long as decrypted content crosses into a process that same-user code can access, someone will find a way in.” What a fix would require A fix is technically feasible, Hagenah said. “The short-term fix is fairly straightforward. Microsoft could add stronger code integrity and process protections to AIXHost.exe, the process that renders the Recall timeline. Right now, it has none, which makes the injection path possible. That would block the specific technique I demonstrated and materially raise the bar,” he said. The longer-term problem runs deeper, he said. “Microsoft should rethink how decrypted data is handled after it leaves the enclave. The cryptography and enclave design are genuinely well done, and I want to be clear about that. The problem is that plaintext screenshots and extracted text end up in an unprotected process for display. As long as decrypted content crosses into a process that same-user code can access, someone will find a way in,” he said. “A durable fix would mean either rendering inside a protected process or adopting a compositing model where raw data never leaves the trust boundary. That is a bigger effort, but it is the only way to close this class of issue properly,” he said. Exploitation risk The barrier to weaponizing this technique is lower than Microsoft’s security messaging would suggest, Hagenah said. “They only need code running in the user’s context and a way to reuse the authorized Recall session,” he said. “That is a much lower bar than many people would assume from Microsoft’s security messaging.” While Recall’s limitation to Copilot+ PCs and its opt-in status reduce the scale of exposure, targeted abuse is a realistic near-term risk, he said. “For targeted abuse, surveillance, or high-value user collection, this is absolutely realistic,” he said. Hagenah said he published the source code deliberately so defenders, EDR vendors, and security teams could build detections before threat actors operationalize the technique independently. “In my view, that gives the defensive side a valuable head start,” he said. Independent security researcher Kevin Beaumont reached a similar conclusion after separately testing the current Recall implementation. “Yep, you can just read the database as a user process,” Beaumont wrote on Mastodon on March 11. “The database also contains all manner of fields that aren’t publicly disclosed for tracking the user’s activity. No AV or EDR alerts triggered,” he wrote. Microsoft did not immediately respond to a request for comment. View the full article

Efforts to cut through the buzz surrounding Anthropic’s Mythos are emerging. As OpenAI moves to counter the hype around it with its own cybersecurity model, VulnCheck is reporting that the model’s publicly attributable output amounts to just one confirmed CVE. While Project Glasswing, the controlled access program for Mythos, promises a powerful offensive capability, gated behind vetted organizations, VulnCheck’s recent findings reveal what those capabilities actually represent in practice. “Anthropic’s Project Glasswing has generated significant attention—but very little concrete data,” said Patrick Garrity, researcher at VulnCheck, in a blog post. “While Anthropic researchers are actively contributing to vulnerability discovery and appear to be promising, the publicly attributable impact of Glasswing itself remains limited so far.” Anthropic did not immediately respond to CSO’s request for comments. Only one CVE is attributable to Glasswing VulnCheck’s analysis of Project Glasswing drills into the numbers behind the claims by looking into public CVE attribution. “I started by re-reading the Glasswing report and the advisories published at red.anthropic.com,” Garrity said. “Neither source provides a comprehensive CVE list of vulnerabilities discovered by Anthropic. So I decided to search the full CVE record database, and searched every CVE record containing the term “anthropic” and reviewed each one.” Garrity identified 75 CVE records that mention Anthropic. But only 40 of those were actually credited to Anthropic researchers, with the rest tied to affected products or unrelated references. Of those 40, 10 originated from external collaboration programs, such as Calif.io’s MADBugs initiatives. The 40 CVEs attributed to Anthropic researchers span multiple products, including 28 affecting Firefox, nine tied to wolfSSL, and one each impacting NGINX Plus, FreeBSD, and OpenSSL. When narrowed down further, the number that mattered the most showed up. Only one CVE is explicitly attributed to Project Glasswing itself, CVE-2026-4747. This is a FreeBSD NFS remote code execution (RCE) flaw described as autonomously identified and exploited. Garrity did not include the three vulnerabilities without CVE numbers mentioned on the Glasswing page. These include a 27-year-old OpenBSD flaw, a 16-year-old FFmpeg bug, and Linux kernel privilege escalation chains, all under embargo pending patches. Why is Glasswing still a big deal VulnCheck’s findings reframe Glasswing’s capabilities. The limited number of directly attributable CVEs is just one way of measuring its impact. Industry observers are interpreting Mythos much differently. Melissa Bischoping, a SANS Technology Institute board member and senior Director of security and product research at Tanium, thinks Mythos potential lies elsewhere. According to a breakdown of the Claude Mythos Preview System Card, which Bischoping and her colleagues at Tanium reviewed, the model achieved an unseen exploit success rate. “Jumping from near-zero success to ~72% on the same class of targets suggests exploit development is no longer a high-skill, high-effort bottleneck,“ she said, adding that it’s only a matter of time before every other model catches up. While Mythos is being regulated under Glasswing, it has already shown the world what is possible. “The gap between frontier models and open-weight models has compressed from more than a year to a matter of weeks, which means this level of capability is poised to spread rapidly, likely without the same safety guardrails,” Bischoping noted. Bischoping is also concerned about whether organizations can act on what Mythos finds before Mythos is out in the wild. “Agentic patch workflows are possible and can match pace with adversarial AI in a lot of cases, but org politics and change control don’t run at the speed of AI today.” The full picture about the model’s true capability won’t be known before July 2026, when Anthropic will make a full public accounting of what Glasswing found and fixed, Garrity said. View the full article

Several major insurance carriers have begun to back away from providing cybersecurity and other insurance to companies using AI to run internal processes, insiders say. While there’s no standard response to customer use of AI in the insurance market, many carriers are now quietly declining to write policies for claims related to AI-generated outputs in cybersecurity and errors and omissions (E&O) coverage, these observers say. Other insurance carriers are jacking up prices to cover AI-related claims, they say. Dozens of insurance carriers appear to be rethinking coverage for mistakes related to AI, says Connor Deeks, CEO of Codestrap, an AI development and consulting firm that works with insurance firms. Many insurance companies aren’t comfortable with covering AI outputs because they can’t track the reasoning path the AI took to come up with a result, he says. “That’s playing out downstream with insurance companies basically carving out coverage, whether that’s across cybersecurity or E&O,” he says. “All of these vibe-coded solutions and these AI systems that people have constructed have inherent risk baked into the cake now, and you can’t actually see the full process.” The insurance carrier concerns about AI workloads first surfaced in November 2025, when Financial Times reported that three major carriers, AIG, Great American, and W.R. Berkley, filed requests with US regulators to offer insurance policies that exclude liabilities tied to AI tools such as chatbots and agents. At the time, those requests appeared to be preemptive moves to be allowed to exclude AI mistakes sometime in the future. But now, many carriers seem to be moving forward with plans to exclude AI mistakes from policies, Deeks says. Several carriers he’s been in contact with are moving to limit or end coverage for AI-related business disruptions and liabilities, he adds. The irony is that many insurance carriers are embracing AI for their own internal purposes. Deeks’ company has a vested interest in AI insurance coverage — Codestrap markets its AI coding platform as traceable and therefore insurable — but other industry insiders have also seen similar carrier decisions. Carriers find exclusions It’s still unclear how many carriers will refuse to insure AI workloads, but several carriers are now writing insurance policies that exempt coverage for AI-related business chaos, says Jason Bishara, financial practice leader at global carrier NSI Insurance Group. “The risk appetite is changing among the carriers, and it’s always constantly evolving,” he says. “With regard to AI, there are carriers that are just removing it from their risk appetite and declining to quote altogether.” While some carriers have declined to cover AI outputs, others are building in rate hikes to cover the increased risk, Bishara says. While he doesn’t have numbers on the extent of the rate hikes, they are significant, he adds. “Every business has insurance, and every business now is using AI to some extent,” he adds. “Are you seeing those liabilities and exclusions within these policies and an aversion to it from the carriers? The answer is yes.” Carriers are also treating AI vendors differently than AI users, he says. In many cases, carriers are declining to cover AI vendors altogether, while they carve out exceptions in policies against covering AI at companies using the technology. “If you’re an AI-related company or specifically an AI company, there’s a good chance that you’ll get a declination at this point,” he adds. In recent months, many carriers have been asking detailed questions about how customers are using AI to better understand the risk of insuring potential mishaps, he says. Ultimately, this increased scrutiny will make it more difficult for companies to buy insurance for AI workloads. “For everybody leveraging AI right now, you’re seeing questions like, ‘What are your AI policies? What are your procedures? How are you leveraging AI within your business?’” Bishara adds. “We’re getting a lot of questions from the underwriters on, ‘How do you leverage AI within your business?’” Coverage in flux Phil Karecki, CTO for the insurance sector at managed services provider Ensono, also sees some carriers backing away from covering AI outputs, although he’s not sure whether it’s a major trend. Insurance carriers continuously experiment with how to provide coverage, he notes. Carriers have tried to separate tightly governed AI deployments from more experimental projects when determining whether to provide coverage, he says. “You’ve got this bifurcation of AI, the governed generative and the autonomous pieces,” he says. “It’s no longer, ‘Are you using AI?’ It’s asking, ‘Are you using governed AI? How are you governing it? How are you keeping it safe and secure?’” Carriers have been trying to determine whether covering AI workloads can be profitable for them, Karecki adds. Governed AI tools operating in a bounded decision-making process will be more insurable, while experimental AI systems with no monitoring and no easy rollback will be difficult to cover, he notes. “There’s a repositioning versus a pullback, and that’s very common to the industry, and they will at times open up coverage just to see if it’s this type of insurance that will sell,” he says. “They will assess the results and what needs to change so they can decide whether to re-enter this marketplace or abandon it completely.” In some cases, whether an AI system is insurable may come down to circumstances at individual insurance customers. Carriers in general don’t want to get out of the business of providing insurance, Karecki says. “What they’re working for right now is, ‘How do I make this profitable, and is this sector insurable?’” he says. “They make those decisions on every application regardless, but now, depending upon what they’re being asked to insure, the questions will follow. ‘What are you using AI for? How are you governing it? What risks does that introduce?’” It makes sense that some carriers have begun to question whether to cover AI outputs, given the current level of unreliability of most AI systems, says Dorian Smiley, CTO at Codestrap. “The math says these models should be deterministic, like given the same input, you should get the same output,” he says. “But you can get very different output from the same input, and they can’t know if the answer that they’re giving you is actually correct.” In most cases, AI models lack inductive reason and can’t review their own work, but many organizations are talking about deploying hundreds of autonomous agents and treating them like digital employees, he notes. “The idea that these agents are going to become employees, autonomous people working in your organization, is insane,” he says. “You would never hire a person that can’t learn new information, can’t reliably retrieve information, or check their own work.” NSI’s Bishara has advice for IT and business leaders looking for insurance coverage for their AI workloads: Be honest about how they’re using AI. If they try to hide their AI risks, they risk having their claims rejected when something goes wrong, he says. “If you don’t fully disclose these things appropriately in the way in which you’re functioning and operating, it could be utilized as an excuse to deny a claim at a later date,” he says. “You don’t want a carrier to come back and say, ‘We didn’t underwrite to that risk. We asked these questions, and you didn’t disclose it.’” View the full article

It is difficult to understand why, in 2026, we are still debating the reporting line of the chief information security officer (CISO). It is one of the first topics I wrote about in 2015, and after more than two decades of high-profile cyber incidents, sustained regulatory pressure, massive technology investments and the steady elevation of cybersecurity to boardroom agendas, one might reasonably expect that this issue would have been settled long ago. Yet the question persists. And articles like this It’s time to rethink CISO reporting lines show that the debate is still raw. The fact that the debate continues tells us something important. It reveals that many organizations still struggle with a more fundamental question: What exactly is the role of the CISO within the enterprise? The reporting line matters — but it was never the real question Let me be clear. The reporting line matters. It matters because it defines the authority, visibility and influence of the security function across the organization. It signals internally how seriously cybersecurity is taken and determines how effectively the CISO can engage with the executive leadership team. But the reporting line was never the real question. The real question is whether the CISO has the organizational standing necessary to influence decisions across multiple silos: IT, operations, legal, compliance, HR, procurement, third-party suppliers and increasingly a complex ecosystem of partners and digital platforms. Cybersecurity is one of the very few corporate functions that touch virtually every part of the enterprise. It is therefore inherently cross-functional. Without sufficient authority and visibility, the CISO cannot hope to influence behaviour across the organization, let alone drive meaningful change. If we are still debating the reporting line in 2026, it is largely because many organizations still treat cybersecurity as a technical issue rather than a leadership issue. The governance gap behind the debate The persistence of this debate reflects a broader governance gap. Historically, information security emerged as a technical discipline embedded within IT departments. Early security teams focused primarily on protecting infrastructure: Firewalls, access controls, network monitoring and vulnerability management. In that environment, it was natural for the security function to sit within the IT organization. But the nature of cyber risk has evolved dramatically. Cybersecurity today is not merely about protecting technology infrastructure. It is about protecting digital business models, customer trust, intellectual property, operational resilience and in some sectors even national security interests. In other words, cybersecurity has become a strategic business issue. And yet, in many organizations, the governance structures surrounding cybersecurity have not evolved at the same pace. The continuing debate about the CISO reporting line is therefore less about organizational design and more about whether companies have fully internalised the strategic nature of cyber risk. There is no universal reporting line Another recurring misconception is the search for a universal answer. Every year, surveys attempt to determine the “correct” reporting line for the CISO. Some conclude that the CISO should report to the CEO. Others recommend the CRO or the COO. Some insist that independence from IT is essential. In reality, there is no universal model. The reporting line remains a means to an end. Organizations differ widely in their structure, culture, maturity and regulatory environment. What works in one organization may not work in another. In many organizations, the CIO remains the most natural reporting line for the CISO, particularly where technology transformation and digital innovation are core strategic priorities. In others, the COO or the CEO may be better placed to support the operational changes required to embed security across business processes. What matters is not the job title of the executive above the CISO. What matters is whether that individual has the authority, credibility, organizational reach and personal willingness to support the security agenda. Authority matters — and quite a lot of that is forged in the first 100 days When a new CISO joins an organization, their immediate priority is rarely technical. Instead, it is organizational: Understanding the business, mapping stakeholders, assessing governance structures and identifying the cultural barriers that may hinder security improvements. During those first months, the CISO must build credibility quickly across multiple constituencies. They must engage with senior executives, operational leaders, technology teams and sometimes regulators or external partners. None of this can be done effectively if the CISO lacks organizational authority. A reporting line that leaves the CISO buried several layers below executive leadership severely limits their ability to build the relationships required to succeed. Conversely, a reporting line that provides direct access to senior decision-makers can dramatically accelerate the process. The reporting line, therefore, matters not because it determines technical decisions, but because it determines access, influence and credibility. The illusion of structural solutions At the same time, we should be careful not to overstate the importance of organizational charts. A common mistake is to assume that moving the CISO reporting line will automatically solve cybersecurity challenges. It will not. Cybersecurity failures rarely occur because the organizational chart was incorrect. They occur because of poor governance, weak leadership, unclear accountability or cultural resistance to change. The most effective CISOs succeed not because of perfect reporting structures but because they build trust, credibility and influence across the organization. Which brings us to perhaps the most important factor of all: The relationship between the CISO and their direct superior. Trust matters more than structure In practice, the success of the CISO depends heavily on the quality of the relationship with the executive to whom they report. That relationship must be built on trust, alignment and shared understanding of the organization’s risk appetite and strategic priorities. If the executive above the CISO understands the importance of cybersecurity and is willing to champion the security agenda at the board level and across the firm, the reporting structure can work extremely well. If that support is absent because the business at large does not see the strategic importance of cybersecurity, no reporting line will magically solve the problem. The myth of the CIO–CISO conflict One final argument frequently raised in these discussions is the supposed “conflict of interest” between the CIO and the CISO. According to this theory, the CISO should not report to the CIO because the CIO is responsible for delivering technology projects and operational performance, while the CISO is responsible for enforcing security controls that may slow things down. This argument may have had some relevance 20 years ago, when security functions were primarily responsible for auditing IT operations. But today, it increasingly reflects an outdated understanding of both roles. Modern cybersecurity is deeply intertwined with technology architecture, cloud platforms, DevOps pipelines, digital transformation programs and operational resilience initiatives. Security cannot be treated as an external oversight function policing IT from a distance. It must be embedded within technology strategy itself. Any modern CIO should see it that way. In that environment, close collaboration between the CIO and the CISO is not only desirable — it is essential. Framing the relationship as a structural budgetary conflict and a source of friction is counterproductive and outdated. The real objective should not be to avoid friction but to engineer alignment: Ensuring that technology leadership and security leadership work together to support the organization’s strategic goals. Moving beyond the debate Ultimately, the continuing debate about the CISO reporting line distracts the security industry from more important questions. What matters far more is whether cybersecurity is integrated into corporate governance, supported by executive leadership and aligned with business strategy. If organizations are still arguing about where the CISO should sit in 2026, it may simply indicate that they have not yet fully accepted the strategic nature of cyber risk. And until that changes, the debate will likely continue. Not because the answer is difficult — but because the underlying governance challenge remains unresolved. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

DC Studio | shutterstock.com Konfigurationsfehler in der Cloud, die Unternehmensdaten gefährden, sind nicht unbedingt etwas Neues – eher im Gegenteil. Umso schlimmer, dass Unternehmen ihre Cloud-Ressourcen immer noch nicht durchgängig absichern. Zumindest legt das ein aktueller Report nahe. Dafür hat der Cloud-Sicherheitsanbieter Qualys 101 Cybersecurity- und IT-Profis befragt, zu deren Aufgaben es gehört, Cloud-Umgebungen abzusichern. Demnach: haben 28 Prozent der Befragten im vergangenen Jahr einen Breach in Zusammenhang mit der Cloud oder SaaS-Applikationen verzeichnet. sehen 24 Prozent falsch konfigurierte Services als das größte Risiko für ihre Cloud-Umgebung an. Qualys nahm für seine Studie außerdem rund 44 Millionen virtuelle Maschinen (VMs) unter die Lupe, die in Public Clouds gehostet werden. Dabei stellten die Experten fest, dass 45 Prozent der AWS-VMs, 63 Prozent der GCP-VMs und 70 Prozent der Azure-VMs über falsch konfigurierte Ressourcen verfügten. Die häufigsten Cloud-Konfigurationsfehler Laut Ayan Roy, Leiter des Bereichs Cybersicherheit bei EY Americas, aktivieren Unternehmen zwar durchaus bestimmte Cloud-Security-Funktionen, allerdings nicht alle. So blieben Logging, Monitoring und Multi-Faktor-Authentifizierung (MFA) in vielen Fällen unbeachtet: “Unternehmen wollen schnell vorankommen, und die Time-to-Value ist absolut entscheidend. Wenn Cybersicherheitsteams jedoch nicht in diese Entscheidungen eingebunden werden, beginnen die Probleme. So können die Sicherheitsprofis oft nur nachträglich Maßnahmen ergreifen.” Einen weiteren blinden Fleck in Sachen Cloud Security sieht Roy während Fusionen und Übernahmen. Er mahnt Unternehmen dazu, in solchen Fällen proaktiv vorzugehen: “Führen Sie eine Due Diligence durch, berücksichtigen Sie diese auch und stellen Sie sicher, dass Sie den richtigen Cybersecurity-Investitionsplan haben.” Laut Scott Wheeler, Cloud Practice Lead bei Asperitas, treten mit steigender Unternehmensgröße auch weniger Cloud-Konfigurationsfehler auf. Das liegt laut dem Cloud-Experten vor allem an der Aufsicht durch Regulierungsbehörden. Kleine Firmen hätten hingegen enorme Probleme, da sie weder über das Personal noch die nötigen Tools verfügten, um Risiken im Zusammenhang mit der Cloud-Konfiguration zu managen – etwa exponierte Speicher-Buckets oder Web Services. “Das gesamte Konzept von Zero Trust basiert auf der Tatsache, dass man den Zugriff auf das benötigte Minimum beschränken kann. Aber das ist in der Praxis schwer zu bewerkstelligen”, erklärt Wheeler. Oftmals würden während der Entwicklung Berechtigungen erweitert und nach der Inbetriebnahme nicht wieder zurückgesetzt, wie er beispielhaft anführt. Der regelmäßig größte Fehler, den Wheeler beobachtet, sind jedoch Datenbanken oder andere Cloud-Assets, die über nicht sichere, private Netzwerke kommunizieren. “Viele dieser Services unterstützen das nicht ‘out of the box’. Es erfordert einiges an Arbeit, sie so zu konfigurieren, dass ausschließlich privater Netzwerkverkehr in private Cloud- oder lokale Umgebungen fließt. Das ist ein großes Problem, das oft von kriminellen Hackern ausgenutzt wird.” Und auch wenn viele Anbieter versprechen, dass KI auch Cloud Security einfacher, kostengünstiger und effektiver gestalten wird: Sie sollten nicht damit rechnen, dass Cloud-Konfigurationsprobleme schon morgen der Vergangenheit angehören. Bis KI-Agenten soweit sind, dass sie das zuverlässig übernehmen können, wird noch ein bisschen Zeit ins Land ziehen. 9 Tipps für sicherere Cloud-Konfigurationen Tun können Sie dennoch etwas gegen fehlerhafte Cloud-Konfigurationen. Zum Beispiel: 1. Multi-Faktor-Authentifizierung implementieren MFA sollte für jede Form von Cloud-Zugriff zur Anwendung kommen, nicht nur für bestimmte Benutzer. 2. Private Netzwerke für alle Services nutzen Konfigurieren Sie Datenbanken und Cloud-Dienste so, dass sie nur über private Netzwerke und nicht über das öffentliche Internet kommunizieren. 3. Daten verschlüsseln Datenverschlüsselung sollte für alle neuen und bestehenden Ressourcen standardmäßig aktiviert sein. Angesichts des nahenden Quanten-Zeitalters empfiehlt es sich für Unternehmen bereits jetzt auf quantensichere Verschlüsselungsalgorithmen zu setzen, um sich gegen sogenannte “Harvest now, decrypt later”-Angriffe zu schützen. 4. Least-Privilege-Zugriffskontrollen anwenden Benutzern und Systemen Zugriff auf möglichst wenige Ressourcen zu gewähren, ist ein Grundpfeiler moderner Zero-Trust-Sicherheitsprinzipien. Konten mit übermäßigen Berechtigungen können schnell zu Datenverlust führen, wenn sie missbraucht werden. 5. Infrastructure as Code verwenden Wenn Administratoren oder Benutzer Änderungen an Cloud-Konfigurationen in den Cloud-Management-Konsolen vornehmen, ist es oft schwierig, diese nachzuvollziehen – und rückgängig zu machen, wenn etwas schiefgeht. Das Prinzip von Infrastructure as Code hilft an dieser Stelle: Verwenden Sie entsprechende Konfigurationsmanagement-Tools, um sämtliche Änderungen anhand von Richtlinien zu überprüfen, nachzuverfolgen und auditieren zu können. 6. Kontinuierlich scannen Einmal bei der Ersteinrichtung der Cloud-Ressourcen zu überprüfen, ob die Konfigurationen aktuell sind, reicht nicht aus. Unternehmen müssen sicherstellen, dass sich nichts verändert. Zu diesem Zweck haben einige Cloud-Anbieter native Tools im Angebot. Lösungen aus dem Bereich Cloud Security Posture Management (CSPM) können außerdem dabei unterstützen, Lücken zu schließen oder Multi-Cloud-Umgebungen zu überwachen. 7. Speicher-Buckets sperren Unsichere Amazon-S3-Buckets waren vor einigen Jahren bei Cyberkriminellen sehr populär – und sind nach wie vor ein gängiges Problem für Unternehmen. Um sicherzustellen, dass der Storage standardmäßig privat ist, empfehlen sich Bucket Policies und -Zugriffskontrollen. 8. Logging und Monitoring einziehen Viele Unternehmen überwachen essenzielle Cloud Services, dabei bleibt Schatten-IT jedoch oft außen vor. Das ist weniger ein technologisches, als vielmehr ein Management-Problem und lässt sich durch bessere Kommunikation mit den Geschäftsbereichen und einen disziplinierteren Ansatz bei der Bereitstellung von Technologien lösen. 9. Security by Design verinnerlichen Integrieren Sie Sicherheit von Anfang an in Ihre Cloud-Architektur – es ist immer deutlich schwieriger, nachträglich aufzurüsten. (fm) View the full article

DC Studio | shutterstock.com Konfigurationsfehler in der Cloud, die Unternehmensdaten gefährden, sind nicht unbedingt etwas Neues – eher im Gegenteil. Umso schlimmer, dass Unternehmen ihre Cloud-Ressourcen immer noch nicht durchgängig absichern. Zumindest legt das ein aktueller Report nahe. Dafür hat der Cloud-Sicherheitsanbieter Qualys 101 Cybersecurity- und IT-Profis befragt, zu deren Aufgaben es gehört, Cloud-Umgebungen abzusichern. Demnach: haben 28 Prozent der Befragten im vergangenen Jahr einen Breach in Zusammenhang mit der Cloud oder SaaS-Applikationen verzeichnet. sehen 24 Prozent falsch konfigurierte Services als das größte Risiko für ihre Cloud-Umgebung an. Qualys nahm für seine Studie außerdem rund 44 Millionen virtuelle Maschinen (VMs) unter die Lupe, die in Public Clouds gehostet werden. Dabei stellten die Experten fest, dass 45 Prozent der AWS-VMs, 63 Prozent der GCP-VMs und 70 Prozent der Azure-VMs über falsch konfigurierte Ressourcen verfügten. Die häufigsten Cloud-Konfigurationsfehler Laut Ayan Roy, Leiter des Bereichs Cybersicherheit bei EY Americas, aktivieren Unternehmen zwar durchaus bestimmte Cloud-Security-Funktionen, allerdings nicht alle. So blieben Logging, Monitoring und Multi-Faktor-Authentifizierung (MFA) in vielen Fällen unbeachtet: “Unternehmen wollen schnell vorankommen, und die Time-to-Value ist absolut entscheidend. Wenn Cybersicherheitsteams jedoch nicht in diese Entscheidungen eingebunden werden, beginnen die Probleme. So können die Sicherheitsprofis oft nur nachträglich Maßnahmen ergreifen.” Einen weiteren blinden Fleck in Sachen Cloud Security sieht Roy während Fusionen und Übernahmen. Er mahnt Unternehmen dazu, in solchen Fällen proaktiv vorzugehen: “Führen Sie eine Due Diligence durch, berücksichtigen Sie diese auch und stellen Sie sicher, dass Sie den richtigen Cybersecurity-Investitionsplan haben.” Laut Scott Wheeler, Cloud Practice Lead bei Asperitas, treten mit steigender Unternehmensgröße auch weniger Cloud-Konfigurationsfehler auf. Das liegt laut dem Cloud-Experten vor allem an der Aufsicht durch Regulierungsbehörden. Kleine Firmen hätten hingegen enorme Probleme, da sie weder über das Personal noch die nötigen Tools verfügten, um Risiken im Zusammenhang mit der Cloud-Konfiguration zu managen – etwa exponierte Speicher-Buckets oder Web Services. “Das gesamte Konzept von Zero Trust basiert auf der Tatsache, dass man den Zugriff auf das benötigte Minimum beschränken kann. Aber das ist in der Praxis schwer zu bewerkstelligen”, erklärt Wheeler. Oftmals würden während der Entwicklung Berechtigungen erweitert und nach der Inbetriebnahme nicht wieder zurückgesetzt, wie er beispielhaft anführt. Der regelmäßig größte Fehler, den Wheeler beobachtet, sind jedoch Datenbanken oder andere Cloud-Assets, die über nicht sichere, private Netzwerke kommunizieren. “Viele dieser Services unterstützen das nicht ‘out of the box’. Es erfordert einiges an Arbeit, sie so zu konfigurieren, dass ausschließlich privater Netzwerkverkehr in private Cloud- oder lokale Umgebungen fließt. Das ist ein großes Problem, das oft von kriminellen Hackern ausgenutzt wird.” Und auch wenn viele Anbieter versprechen, dass KI auch Cloud Security einfacher, kostengünstiger und effektiver gestalten wird: Sie sollten nicht damit rechnen, dass Cloud-Konfigurationsprobleme schon morgen der Vergangenheit angehören. Bis KI-Agenten soweit sind, dass sie das zuverlässig übernehmen können, wird noch ein bisschen Zeit ins Land ziehen. 9 Tipps für sicherere Cloud-Konfigurationen Tun können Sie dennoch etwas gegen fehlerhafte Cloud-Konfigurationen. Zum Beispiel: 1. Multi-Faktor-Authentifizierung implementieren MFA sollte für jede Form von Cloud-Zugriff zur Anwendung kommen, nicht nur für bestimmte Benutzer. 2. Private Netzwerke für alle Services nutzen Konfigurieren Sie Datenbanken und Cloud-Dienste so, dass sie nur über private Netzwerke und nicht über das öffentliche Internet kommunizieren. 3. Daten verschlüsseln Datenverschlüsselung sollte für alle neuen und bestehenden Ressourcen standardmäßig aktiviert sein. Angesichts des nahenden Quanten-Zeitalters empfiehlt es sich für Unternehmen bereits jetzt auf quantensichere Verschlüsselungsalgorithmen zu setzen, um sich gegen sogenannte “Harvest now, decrypt later”-Angriffe zu schützen. 4. Least-Privilege-Zugriffskontrollen anwenden Benutzern und Systemen Zugriff auf möglichst wenige Ressourcen zu gewähren, ist ein Grundpfeiler moderner Zero-Trust-Sicherheitsprinzipien. Konten mit übermäßigen Berechtigungen können schnell zu Datenverlust führen, wenn sie missbraucht werden. 5. Infrastructure as Code verwenden Wenn Administratoren oder Benutzer Änderungen an Cloud-Konfigurationen in den Cloud-Management-Konsolen vornehmen, ist es oft schwierig, diese nachzuvollziehen – und rückgängig zu machen, wenn etwas schiefgeht. Das Prinzip von Infrastructure as Code hilft an dieser Stelle: Verwenden Sie entsprechende Konfigurationsmanagement-Tools, um sämtliche Änderungen anhand von Richtlinien zu überprüfen, nachzuverfolgen und auditieren zu können. 6. Kontinuierlich scannen Einmal bei der Ersteinrichtung der Cloud-Ressourcen zu überprüfen, ob die Konfigurationen aktuell sind, reicht nicht aus. Unternehmen müssen sicherstellen, dass sich nichts verändert. Zu diesem Zweck haben einige Cloud-Anbieter native Tools im Angebot. Lösungen aus dem Bereich Cloud Security Posture Management (CSPM) können außerdem dabei unterstützen, Lücken zu schließen oder Multi-Cloud-Umgebungen zu überwachen. 7. Speicher-Buckets sperren Unsichere Amazon-S3-Buckets waren vor einigen Jahren bei Cyberkriminellen sehr populär – und sind nach wie vor ein gängiges Problem für Unternehmen. Um sicherzustellen, dass der Storage standardmäßig privat ist, empfehlen sich Bucket Policies und -Zugriffskontrollen. 8. Logging und Monitoring einziehen Viele Unternehmen überwachen essenzielle Cloud Services, dabei bleibt Schatten-IT jedoch oft außen vor. Das ist weniger ein technologisches, als vielmehr ein Management-Problem und lässt sich durch bessere Kommunikation mit den Geschäftsbereichen und einen disziplinierteren Ansatz bei der Bereitstellung von Technologien lösen. 9. Security by Design verinnerlichen Integrieren Sie Sicherheit von Anfang an in Ihre Cloud-Architektur – es ist immer deutlich schwieriger, nachträglich aufzurüsten. (fm) View the full article

Security vendor Pluto Security has published details of a critical vulnerability in the open-source nginx UI web server configuration tool that has been under active exploitation by cybercriminals since March. News of the flaw, identified as CVE-2026-33032, first appeared on the National Vulnerability Database (NVD) on March 30, the same day that threat intelligence companies VulnCheck and Recorded Future’s Insikt Group noted it was under active exploitation. What users didn’t have at that point were any details on the flaw from Pluto Security, the company that discovered it earlier that month. This week, the company rectified this, publishing a full breakdown of the vulnerability. Nginx UI is a convenient real-time dashboard and control panel interface for managing nginx single-node and cluster nodes without having to resort to the command line interface (CLI). The vulnerability, with a CVSS score of 9.8, relates to the software’s support for Model Context Protocol (MCP) servers, which was added in late 2025 and enables communication between nginx web servers and AI models though two HTTP-accessible MCP URL endpoints. Unfortunately, in the case of nginx UI, one of these endpoints, /mcp_message, was implemented without authentication, a weakness Pluto Security dubbed ‘MCPwn’. “This exposes 12 MCP tools, including config writes with automatic nginx reload, to any host on the network. One unauthenticated API call is all it takes to inject a config and take over nginx,” said Pluto Security. Leveraging MCPwn, an attacker would be able to intercept all traffic, harvest admin credentials, maintain persistent access, conduct infrastructure reconnaissance via nginx configuration files, and kill the service, the company said. MCP attack surface Nginx UI’s user base of hundreds of thousands is relatively small compared to the vast global popularity of the nginx web server. Many of its installations will also be internal and therefore not directly exposed to remote attack. However, using Shodan, Pluto Security was still able to find 2,689 vulnerable nginx UI instances reachable from the internet, it said. “This is a clear example of how AI integrations can unintentionally expand the attack surface,” commented Pluto Security’s CEO, Shahar Bahat. “MCP servers aren’t just developer tools, they’re privileged access points into production systems.” MCP has been implemented at breakneck speed to enable AI agents, leading to the adoption of tools without the risks they create being understood, Bahat pointed out. “This vulnerability shows how a single exposed endpoint can enable full compromise. AI integration layers must be treated as part of the attack surface, not an afterthought,” she said. To security teams, this will be reminiscent of the problems experienced when APIs started to boom a decade ago. By enabling an integration layer such as MCP, and the tools used to manage it, developers risk inadvertently creating a new layer of vulnerability. As Bahat put it: “AI integration endpoints expose the same capabilities as the core application, but often skip its security controls.” When planning MCP integrations, Pluto Security recommends giving MCP endpoints the same security attention as APIs, auditing Server-Sent Events (SSE) endpoints and fully testing authentication parameters. A priority fix The fact that the nginx vulnerability has been under exploitation for at least a month should make applying the recommended fix, version 2.3.4, released March 15, a priority for anyone using this software, since nginx servers represent a big prize for threat actors. In February, attackers were discovered exploiting the ‘React2Shell’ vulnerability (CVE-2025-55182) inReact Server Components (RSC) to target nginx servers. For those who can’t patch immediately, the stopgap workaround is to disable MCP, or lock the IP whitelist to trusted hosts, as well as reviewing access logs for unusual configuration changes. View the full article

Enterprise AI agents are supposed to streamline workflows. Instead, two fresh findings show they can just as easily streamline data exfiltration. Security researchers have uncovered prompt-injection vulnerabilities in both Microsoft Copilot Studio and Salesforce Agentforce that allow attackers to execute malicious instructions via seemingly harmless prompts. According to Capsule Security findings, SharePoint forms and public-facing lead forms within Copilot are vulnerable to attackers issuing prompts that can override system intent and trigger data exfiltration to attacker-controlled servers. One of these flaws has already been assigned a high-severity CVE, with another “critical” one reportedly missing the bar for categorization. The flaws can allow theft of PIIs, customer/lead records, free-text business context, and operational/workflow data. In both cases, AI agents treat untrusted user input as trusted instructions, Capsule researchers noted in the disclosures shared with CSO ahead of their publication on Wednesday. ShareLeak: SharePoint forms data leaked through Copilot The Microsoft-side issue, dubbed “ShareLeak,” is about how Copilot Studio agents process SharePoint form submissions. The attack begins with a crafted payload inserted into a standard form field, like “comments”, which the agent later ingests as part of its operational context. Because the system concatenates user input with system prompts, the injected payload overrides the agent’s original instructions. The model is thus tricked into believing the attacker’s instructions are legitimate system directives. The malicious input moves from form submission to agent execution without any resistance. Once compromised, the agent can access connected SharePoint Lists and extract sensitive customer data, including names, addresses, phone numbers, and send it externally via email. The researchers found that even when Microsoft’s safety mechanisms flagged suspicious behavior, the data was exfiltrated. The root cause is that there is no reliable separation between trusted system instructions and untrusted user data. In the existing setup, the AI cannot distinguish between the two, the researchers said. Microsoft patched the issue following disclosure, assigning CVE-2026-21520 to it and assessing its severity at 7.5 out of 10 on the CVSS scale. The mitigation was carried out internally, and no further action is required from the users. PipeLeak: Salesforce Agentforce hijacked by a simple lead In the Salesforce Agentforce case, attackers embed malicious instructions inside a public-facing lead form. When an internal user later asks the agent to review or process that lead, the agent executes the embedded instructions as if they were part of its task. According to a Capsule demonstration, the agent retrieves CRM data via the “GetLeadsInformation” function and then sends it externally via email. The compromise isn’t limited to a single record. Researchers demonstrated that a hijacked agent could query and exfiltrate multiple lead records in bulk, effectively turning a single form submission into a database extraction pipeline. The researchers said Salesforce acknowledged the prompt injection issue but characterized the exfiltration vector as “configuration-specific,” pointing to optional human-in-the-loop (HITL) controls. Capsule’s pushback on that framing argues that requiring manual approvals undermines the very purpose of autonomous agents. The deeper issue, they noted, is insecure defaults. Systems designed for automation should not allow untrusted inputs to redefine agent goals. Both disclosures converge on a baseline that calls for treating all external inputs as untrusted and having filters in place that separate data from instructions. This would entail enforcing input validation, least-privilege access, and strict controls on actions like outbound email. View the full article

Deepfake technology has crossed a critical threshold. What was impossible 10 years ago and required specific expertise only a few years ago is now cheap and accessible. Worse, it’s now good enough to fool a wide range of employees and executives. In fact, a 2025 Gartner survey found that 43% of cybersecurity leaders experienced at least one audio deepfake, and 37% experienced video deepfakes in the past year. These findings reflect what we see in the wild. Deepfakes are no longer a hypothetical future risk; they are showing up in real workflows, decisions and incidents. Meeting this sophisticated and evolving challenge demands rapid verification, cross-functional coordination and clear communication to limit the impact of synthetic media. The collapse of heuristics Humans tend to rely on mental shortcuts, or heuristics, to judge what is real. Historically, trusting a familiar face or voice was enough to feel confident. Early deepfakes began to test these instincts, but they were often marred by telltale flaws, such as unusual blinking, mangled fingers, or blurred text. Unfortunately, that tried-and-true approach to distinguishing fact from fiction is no longer reliable. The obvious cues that made deepfakes easier to spot have been eliminated by the latest generation of generative AI models, such as Nano Banana Pro. As a result, the heuristics humans have historically relied on cannot be trusted in isolation. Deepfakes as tools for financial fraud Deepfakes have quickly become a powerful enabler of financial fraud. This is largely because most business communication channels, like video and voice calls, remain unauthenticated. A single convincing audio or video call, seemingly from a trusted executive, can bypass established controls in minutes. Employees in these scenarios often follow instructions or approve large fund transfers, believing they are acting on legitimate requests. A well-known example of this risk occurred at Arup, where the company’s CFO and other video call participants were convincingly simulated using AI-generated deepfakes, and an employee transferred roughly $25 million. Until robust dual authentication for phone calls is standard, organizations remain exposed to anyone who can convincingly mimic a CFO or CEO. Deepfakes as reputational weapons Financial fraud remains a serious concern with deepfakes, but they are increasingly being used as reputational weapons, engineered to erode confidence among investors, customers and business partners. Attackers need only a brief clip, often as little as 20 seconds, to impersonate an executive and unravel years’ worth of reputation and trust built with key stakeholders. Beyond the C-cuite, anyone with a digital footprint, from a podcast appearance to a short social media clip, could become a target. Recent cases show how rapidly these false narratives can escalate and cause real damage: Market destabilization: In January 2026, the Bombay Stock Exchange was forced to issue an urgent warning after deepfake videos of its CEO spread online, promoting fraudulent stock tips and promises of “supernormal profits.” Public disruption: After a December 2025 earthquake in the UK, a synthetic image of a collapsed bridge went viral, leading to train cancellations. Internal sabotage: In a private case, a former employee created deepfakes of company leaders making inflammatory remarks and distributed them directly to business partners, intending to inflict reputational damage. Each of these incidents forced the affected organizations into crisis mode. The rapid spread of deepfakes on digital platforms means false content often circulates faster than teams can investigate or respond to it. By the time the truth emerges, the damage to relationships and reputation may already be done. Building resilience against deepfakes Deepfake incidents differ from other cyber attacks. While they may not cause immediate financial loss, they often unfold publicly, spread faster than investigations can keep pace and exploit human trust at scale. For most organizations, handling the widespread uncertainty and reputational damage stemming from a deepfake incident exceeds the capabilities of internal teams, especially when public trust is at stake. Addressing this challenge requires more than technical controls. Business leaders are increasingly recognizing the importance of being able to respond to these threats quickly and decisively. Effective response now depends on capabilities that enable organizations to verify content, limit its spread and communicate with stakeholders in a timely and credible way. In practice, this includes: Technical analysis: Expert forensic review of audio and video content to determine whether the content has been manipulated and to generate forensic proof for stakeholders. Legal support: The ability to act once harmful content has been identified, including coordinating takedown requests by working with legal experts to support the removal of malicious or defamatory content from online platforms. Clear communication: Public relations and communications support to help organizations craft effective messages for employees, investors and customers during a rapidly evolving incident. The path forward: Authentication as the end state In the long term, addressing deepfakes will likely require broad adoption of authentication and watermarking standards, like how web browsers display a lock icon to signal a secure, authenticated connection. For example, organizations may soon embed watermarks in official communications, such as press statements, interviews and earnings calls. Yet, watermarks will not resolve every challenge. Some authentic content, like revelations from whistleblowers, will inevitably circulate without official marks. Attackers will still be able to fake this kind of content, leaving us in a continual cat-and-mouse game, in which journalists and forensic experts must draw on alternative sources and advanced tools to verify materials. Establishing trust in digital media will remain an ongoing process, as both attackers and defenders adapt. For business and risk professionals, the takeaway is clear: True resilience no longer depends on heuristics and trusting what we see or hear. It depends on how quickly organizations can verify reality, coordinate a response with expert support and resources and restore trust before misinformation becomes the dominant narrative. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Cyberattacks targeting the healthcare sector have surged since the COVID-19 pandemic and the resulting rush to enable remote delivery of healthcare services. Security vendors and researchers tracking the industry have reported a major increase in phishing attacks, ransomware, web application attacks, and other threats targeting healthcare providers. Recent rising of ransomware attacks on healthcare, in particular the Change Healthcare breach, has been a headline-grabbing wake-up call for healthcare execs. The trend has put enormous strain on healthcare security organizations. “The healthcare industry is under siege from a range of complex security risks,” says Terry Ray, vice president of product strategy at Varonis. “Cybercriminals are hunting for the sensitive and valuable data that healthcare has access to, both patient data and corporate data.” Many organizations are struggling to meet the challenge because they are under-resourced and rely on vulnerable systems, third-party applications, and APIs to deliver services. Moreover, IT systems are increasingly used to optimize clinical encounters and patient care. Implantable devices, such as loop recorders, are increasingly being used to aid diagnoses, for example, of cardiac arrhythmias. These devices support telemetry, as do wearable devices, by transmitting patient data. Important healthcare decisions are made based on this data, with patient data being far more available due to advances in IT. The increasing usage of IoT and IT in healthcare have improved clinical efficiency and decision-making certainty, but it does require greater attention to risk assessment, with the days of patient data stored in locked filing cabinets long gone, says WithSecure principal consultant Stuart Morgan. “The impact of patient data being manipulated or leaked is intuitive and well understood, but the risk of denial of service — whether malicious or unintended — can be huge,” Morgan tells CSO. “Although resilience is built in to these systems to a degree, resorting to backup systems are by their nature far less efficient.” Here, security experts identify the major cybersecurity threats healthcare organizations face today. The rising ransomware threat Ransomware has emerged as one of the biggest cyber threats for healthcare today. Attackers have discovered that healthcare organizations delivering life-saving treatments can be more easily extorted than victims in almost every other sector. Many healthcare organizations are also more susceptible to attacks because of new digital applications and services they have launched to address demand for telehealth services, among other digitalization efforts. From 2022 to 2023, healthcare ransomware victims jumped 81%, according to a study by US Office of the Director of National Intelligence. This past year, healthcare ransomware attacks increased another 30%, as vendors and service partners joined clinics and hospitals as key targets for attacks, according to a study by Comparitech. Pharmaceutical manufacturers, medical billing providers, and healthcare tech companies have also come under increasing fire from ransomware actors, Comparitech found. Change Healthcare’s devastating ransomware attack in February 2024 is among the most notable. The attack, which disrupted insurance claim processing, prescription dispensing, and financial settlements, had a huge impact on hospitals, clinics, and pharmacies across the US. In August 2024, Michigan-based McLaren Health Care suffered the second of two ransomware attacks over the course of just 12 months. A June 2024 ransomware attack on NHS-affiliated UK pathology services Synnovis caused massive disruption in parts of London, forcing hospitals to cancel planned procedures and resulting in a temporary shortage of blood supplies. The Qilin ransomware group exfiltrated data before deploying ransomware that hobbled Synnovis’ IT systems, affecting blood tests, diagnostics, and lab services. Medical equipment firm Stryker experienced global network disruptions to its IT systems following a cyberattack in March 2026. Initially ransomware was suspected but Iran-linked group Handala quickly became the prime suspect in an attack that wiped an estimated 200,000 devices as part of a broader campaign against US and Israeli targets. Electronic health records (EHRs) and systems present the biggest risk in healthcare today, says Caleb Barlow, president and CEO of CynergisTek. “Past attacks have shown when a hospital undergoes a ransomware-induced lockdown period, access to EHRs is shut down, and patients may have to be diverted for care,” he says. “Such attacks can prevent access to critical prescription information and dosing for patients with complex, chronic conditions like diabetes or cancer. Worse, hackers can potentially take it a step further and manipulate health record data to undermine patient care.” Historically, healthcare institutions transferred this risk to cyber insurance, but that is becoming more difficult because insurers are making it harder for organizations to purchase ransomware protection without specific controls such as multi-factor authentication and endpoint detection and response technologies, Barlow says. Cloud vulnerabilities and misconfigurations Many healthcare organizations have adopted cloud services as part of broader digital transformation initiatives. As a result, patient health information (PHI) and other sensitive data is increasingly being hosted in vendor cloud environments. The trend has broadened attack surface at healthcare organizations, says Anthony James, vice president of products at Infoblox, especially as healthcare organizations often use multiple cloud vendors and services with differing security standards and practices, making it hard to apply a consistent data protection policies. Sixty-one percent of healthcare companies said they experienced a cloud cyberattack in the past 12 months in a February 2024 report by healthcare software developer KMS Healthcare. In March 2026, US healthcare software vendor CareCloud’s EHR environment suffered a breach, disrupting access for 45,000 providers. Attacks aren’t the only cyber risks healthcare organizations face with rising cloud use. Misconfigurations play a role as well. In April 2025, US health insurer Blue Shield of California found that it had exposed member data — including protected health information — to Google’s advertising platform for three years up until January 2024 because of a flawed Google Analytics setup on some of its web pages. Web application attacks Web application attacks targeting healthcare entities have also spiked sharply in recent years, with cross-site scripting attacks among the most common, along with SQL injection, protocol manipulation attacks, and remote code execution/remote file inclusion attacks. “Technically speaking, web application attacks can be incredibly challenging for under-resourced healthcare organizations to manage,” Varonis’ Ray says. To address the issue, healthcare organizations must implement controls that enable better visibility into third-party applications and API connections. Only then will the security team be able to understand who is trying to access critical data and whether that activity should be permitted. Bad-bot traffic Traffic from bad bots — such as those attempting to scrape data, send spam, or download unwanted software — present another major challenge for healthcare organizations. The problem became especially pressing during the pandemic when governments around the world set up new websites and other digital infrastructure to support COVID vaccine registrations and appointments. “Increased levels of traffic result in downtime and disruption for legitimate human users who are trying to access critical services on their healthcare providers’ site,” Ray says. “It might also result in increased infrastructure costs for the organization as it tries to sustain uptime from the persistent, burdensome level of elevated traffic.” The latest 2025 edition of Imperva’s Bad Bot report estimates malign bots account for nearly a third (37%) of internet traffic, up from 32% in the year prior. Imperva warned that AI is “supercharging the bot threat” alongside a shift in advanced bot traffic targeted APIs rather than applications, reflecting how API endpoints often handle sensitive or high-value data. “Financial services, business, telecom, and healthcare are among the most targeted industries for bot attacks on APIs, accounting for over 75% of all API attacks,” Imperva reports. Bad bots can lead to healthcare data breaches, for example through credential stuffing attacks against patient accounts, and scraping of sensitive health information. Cybercriminals target confidential health information, such as patient records, medical history, and insurance details because this stolen data can be sold on the dark web for profit or used for fraudulent activities, Imperva warns. Increased phishing volumes Phishing attacks pose a major threat to the healthcare industry as they do in almost every sector. Again, the pandemic provided a unique backdrop for a rise in phishing volumes versus healthcare organizations. In a survey of 168 healthcare cybersecurity professionals conducted by Healthcare Information and Management Systems Society (HIMSS) at the time found that phishing was the typical initial point of compromise for most security incidents. “Phishing attacks are the top type of significant security incident reported by respondents,” HIMSS noted in its report. “Phishers were the top type of threat actor responsible for significant security incidents at healthcare organizations.” But phishing has long been an issue for healthcare. Stats compiled by the US Department of Health and Human Services (HHS) record that 18% of 4,419 reported breaches of PHI between 2009 and 2021 involved either phishing attacks or the hacking of email accounts, according to the HIPAA Journal. Phishing was the initial vector in high-profile attacks against healthcare organizations Anthem (2015) and Magellan Health (2020), among others. A study by UK medical journal BMJ found that around 3% of emails sent to hospital staff over a one-month period were suspected threats. While many staff appear to be aware of phishing and respond appropriately, ongoing education is required — particularly about the risk of leaking information of potential use to attackers through social media, the BMJ advised. Smart devices Wearable and implantable smart medical devices are a proven cybersecurity risk. These technologies certainly offer better analysis, assisting diagnosis of medical conditions while aiding independent living, but mistakes made in securing such medtech have exposed vulnerable users to potential attack. A seminal moment was the late Barnaby Jack’s hacking of an insulin pump in 2011. This attack over Bluetooth had a maximum range of approximately 300 meters. Since then, security researchers at Pen Test Partners have found “closed loop” insulin trial data on the public internet. “In one case, we could have modified the readings taken by the body-worn continuous glucose monitor and automatically, remotely administered a fatal dose of insulin to around 3,000 users in the trial,” Ken Munro, managing director of Pen Test Partners, tells CSO. “Fortunately, the vendor involved responded very quickly to our report and had the system secured the same day.” Munro adds: “Other connected medtech devices Pen Test Partners have found security issues with include cranial stimulators, dosing pumps, and medical robots, among many others. Fortunately, the smart devices threat has been recognized and regulators are starting to take action.” For example, the US Food & Drug Administration (FDA) introduced FD&C 524b in 2023 to drive cybersecurity in connected medical devices. Generative AI As healthcare staff adopt generative AI, the risk of leaking sensitive information through prompts and documents has grown. Regulated data, such as patient records and medical information, is especially at risk, accounting for 89% of all data policy violations occurring in the context of gen AI usage, significantly higher than the cross-industry average of 31%, according to a 2026 study by Netskope. Moreover, the Netskope report shows that healthcare organizations’ deployment and usage of internal AI tools, which require bespoke security guardrails, is accelerating. The proportion of healthcare workers using gen AI applications managed by their organization jumped from 18% to 67% in 2025, significantly ahead of cross-industry averages (26% to 62%), according to the study. The need for bespoke security controls for AI systems is illustrated by research from Mindgard showing that the clinical AI tool Doctronic could be compromised to spread conspiracy theories or even manipulate prescription guidance. View the full article

Cyber resilience has become a critical governance concern as organizations face increasingly complex and costly cyber threats. However, recent research reveals that the concept of cyber resilience remains inconsistently defined across regulatory frameworks and in some cases presents contradictory guidance to cross-sector and multinational organizations. This conceptual fragmentation poses a systemic risk for top management teams. Without a standardized definition, boards will struggle to determine what they should oversee, what should be measured, and how to evaluate overall organizational cyber resilience. This challenge is amplified by several external factors such as regulatory pressure, increasing public scrutiny, and the growing economic impact of cyber disruption. What does the current research literature tell us? In an effort to synthesize the views that currently exist on cyber resilience, I recently conducted a detailed literature review on 38 articles that examine how cyber resilience is defined and conceptualized in contexts that are relevant to boards of directors and executive teams. The review included academic research articles, industry white papers, and output from recognized cyber resilience working groups. The goal was to assess whether existing definitions and conceptualizations of cyber resilience demonstrate sufficient alignment to support a generalized definition of cyber resilience relevant to boards and, over time, support meaningful measurement models. The results are clear: The field of cyber resilience is still in its infancy, and the understanding of cyber resilience concepts is far from consistent. While many cyber resilience concepts are intuitively understood within the technical ranks, cyber resilience must be put into specific contexts of business outcomes when discussing with Boards and Executive teams. Following is a short synthesis of the literature review findings, focusing on areas of convergence and divergence across the body of literature. Where the literature converges Organizational outcomes vs. policy and controls It’s consistently agreed that cyber resilience should be tied to organizational outcomes rather than technical controls and policies. Rather than focusing on metrics such as mean time to detection or number of security controls, organizational cyber resilience needs to evaluate levels of business continuity, preservation of stakeholder confidence and financial stabilization in the wake of major disruptions. To do so demands that cyber resilience be treated as a strategic priority that is integrated into organizational governance and business strategies. Resilience is much broader than preparedness While some articles framed risk prevention and protection in the context of resilience, business continuity and recovery featured prominently as important resilience themes in virtually every article reviewed. This demonstrates a common belief that disruption is inevitable and that resilience is demonstrated through rapid response and recovery rather than preparedness alone. Some articles went as far as to advocate for treating cybersecurity and cyber resilience as separate concepts to help address ambiguities. Cyber resilience is a leadership responsibility Cyber resilience is increasingly framed as a leadership responsibility, with the associated governance identified as one of the top governance challenges currently faced by boards of directors. Many sources explicitly position boards as being accountable for resilience outcomes, with some articles stressing the need to assign responsibility to a single officer. This is clearly driven by governmental regulations where, in some countries, Board responsibility for cyber resilience outcomes is explicitly identified. Articles also highlight the importance of senior leadership in fostering a culture of cybersecurity awareness and resilience across the entire organization. Industry context The review also investigated differences in definitions and conceptualizations of cyber resilience across industries, and while differences do exist, they are exclusively a reflection of prioritization and operating environment, not fundamentally different views of resilience. For example, articles that focused on the financial services sector emphasized regulatory compliance and systemic stability of the ecosystem, while those that focused on the energy and industrial sectors make it clear that the priority is on operational continuity and safety. While these differences might influence how resilience is implemented and measured, the underlying concepts of cyber resilience remain consistent across industries. Diverging views Conceptual framing: What exactly is cyber resilience? One area where current cyber resilience literature diverges is in the overall framing or construct of cyber resilience. In many cases, cyber resilience is framed as a component of cybersecurity, while others consider cybersecurity a precursor to cyber resilience. In many of the reviewed articles, terms such as risk management, cybersecurity preparedness and cyber resilience were used interchangeably. Approximately 30% of articles framed cyber resilience as a very distinct construct, differentiating it from general cybersecurity concepts. These articles exclusively positioned cyber resilience as a broader strategic governance construct. Scope of cyber resilience: Where does it start and where does it end? The most glaring area of debate is where, in the lifecycle of a cyber crisis, responsibility for cyber resilience starts and ends. For example, as previously noted, it’s often unclear whether preparedness is part of resilience or a precursor to it. Nearly half of the research articles reviewed consider risk analysis and preparedness separate from resilience. In such cases resilience is limited to response, recovery and adaptation. Essentially, separating what happens before a crisis from what happens during and after a crisis. This separation makes sense as cyber risk preparedness is generally measured through policies and controls, while crisis response, recovery and adaptation require much different measures. Still, slightly more than 50% of the articles view cyber resilience as an overarching construct with responsibility for all aspects from anticipating risk through to recovery and adaptation. This view also makes sense and is one that is more relevant to boards and executive teams given their broad fiduciary responsibilities to protect the company and its shareholders. Cyber crime, the catalyst for cyber resilience: What about unintentional disruptions? Similar to the previous area of debate is how broadly causes of disruptive events are defined in the context of cyber resilience. While cybercrime features prominently in the literature and remains the dominant driver of cyber risk, many definitions intentionally avoid tying resilience to a single type of threat. In fact, of the 38 articles reviewed, only two specifically linked their definitions of cyber resilience to events resulting from cybercrime. This was a surprising realization, but it is encouraging when considering the number of recent highly visible unintentional disruptions that have caused massive outages. Surely, cyber resilience governance needs to focus on an organization’s capacity to absorb and recover from any type of cyber disruption — intentional or not. Governmental regulation: An enabler or a constraint? Regulatory frameworks for cyber resilience vary significantly across geographies and industries, creating challenges for standardization. Cyber regulations within the financial services sector are quite different to those in the energy sector, which are different again than those in the consumer technology sector. Several of the articles reviewed highlighted the complexity of navigating the sea of regulations and regulators. Relevant regulators include CISA, FTC and SEC in the United States, more than 10 sector specific regulators in the UK, individual member states within the EU, and many more. There is some disagreement on the benefits of regulation, but the majority opinion from this review is that for organizations, particularly multinationals, the complexity has become unmanageable. It is also noted that for small and medium enterprises, compliance with regulations can provide a false sense of security, as it can be tempting to assume compliance equates to resilience. Implications for boards and executive teams Boards and executive teams are increasingly expected, and in some cases required by law, to bear responsibility for overall cyber risk and resilience outcomes. This responsibility far exceeds historical expectations of simply approving security investments or compliance activities. To do this effectively, it’s imperative that a clear definition and scope of cyber resilience be clearly communicated in business terms to the board and executive team. For such audiences, cyber resilience must be framed in terms of operational impact, financial exposure, and organizational continuity rather than technical indicators alone. As economies become more integrated and interdependent, their exposure to and impact from cyber disruptions grow exponentially. As such, the ability of individual organizations to withstand and quickly recover from cyber disruption is not just a measure of organizational cyber resilience; it also contributes to our overall global economic resilience. In this sense, cyber resilience should be considered one component of a larger resilience agenda, alongside financial, operational, and supply-chain resilience. Clarifying the scope of cyber resilience at the board level is therefore not only a governance issue, but also a foundation for understanding overall resilience in increasingly digital economies. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Built by a veteran security team and led by a former Google and Mandiant executive, Mallory delivers intelligence that drives action for enterprise security teams. Mallory is launching a AI-native threat intelligence platform, purpose-built to answer the questions CISOs and their teams are asking every day: What are the real threat vectors for our organization? What’s actually exploitable in our environment right now? What should we proactively fix? The platform monitors thousands of threat sources, contextualizes them against a user’s actual attack surface, and puts that intelligence to work across hunt, detection, and exposure management use cases. One platform. Answers, not alerts. Modern teams receive more signals than ever and have structured their SOC around dealing with the deluge. But they’re still chasing alerts and struggling to get proactive, let alone work with business partners to close gaps before they’re exploited. Mallory connects into the user’s existing tools and controls. When a new vulnerability or exposure surfaces, it doesn’t just flag it — it tracks who is exploiting it, where, and how, then determines whether the organization is actually at risk and what to do about it. “Attackers are AI-enabled now, moving faster and with more capability. Defenders need to be too. Security teams don’t need more alerts. They need answers: what can attackers do, are our controls stopping them, and what’s exploitable right now,” says Mallory founder and CEO Jonathan Cran. The result isn’t another feed or dashboard. It’s a prioritized set of evidence-based cases grounded in real threat intel, mapped to the user’s environment and ready for action. “When a new alert makes the news, I need to know within minutes if we are impacted. Mallory delivers the context needed to investigate at AI speed,” says John Sapp, CISO of Texas Mutual Insurance. Flexibility to build is critical in today’s cybersecurity ecosystem. Mallory is built by veteran security practitioners for security teams, with native support for Claude Code, MCP, API, and its own modern UI. Teams can integrate, automate, and extend on their terms. Mallory also announced a seed investment led by Decibel Partners, with participation from Live Oak Venture Partners and a cadre of industry leaders from organizations including Google, Robinhood, Cisco, Fastly, and GreyNoise. “Threat intelligence was built for an era where we would be able to process information at human speed. With the introduction of agents on the adversarial side, we no longer have data intel problem but rather a context and reasoning problem. Jonathan and the Mallory team are changing that by connecting real-time threat activity to an organization’s environment and processing it for relevance at agentic speed. ” says Dan Nguyen-Huu, partner at Decibel. Mallory is available immediately as a SaaS platform with integrations across existing security tools. Users can start a 30-day free trial at mallory.ai/platform. About Mallory Mallory is the AI-native threat intelligence platform for cyber defenders. It monitors global adversary activity, contextualizes threats against assets and controls, and delivers prioritized, evidence-based answers. Teams focus on what’s real and act faster. Users can learn more at mallory.ai. Contact Marketing Chris Tilton Mallory [email protected] View the full article

Miljan Zivkovic | shutterstock.com Die zunehmende Abhängigkeit von IT-Dienstleistern und Software von Drittanbietern vergrößert die Angriffsfläche von Unternehmen erheblich. Das wird auch durch zahlreiche Cyberattacken immer wieder unterstrichen. Zwar lassen sich die Risiken in Zusammenhang mit Third-Party-Anbietern nicht gänzlich beseitigen, aber durchaus reduzieren. Dabei sollten Sicherheitsentscheider eine zentrale Rolle spielen, wie Randy Gross, CISO bei CompTIA, erklärt: “CISOs sind in der einzigartigen Lage, den gesamten Geschäftsprozess zu überblicken – Datenflüsse, Abhängigkeiten und nachgelagerte Auswirkungen. Dennoch nutzen viele Unternehmen diese Perspektive noch immer nicht, um Risiken durch Dritte neu zu bewerten.” Insbesondere, wenn Verträge auf Ebene von Geschäftseinheiten verhandelt werden oder unterhalb der finanziellen Genehmigungsschwellen liegen, bleiben Sicherheitschefs jedoch oftmals außen vor. Das beobachtet auch Melissa Ventrone, Leiterin der Abteilung für Cybersicherheit bei der Anwaltskanzlei Clark Hill: “In vielen Unternehmen werden Sicherheitsverantwortliche erst nach Vertragsabschluss hinzugezogen. Oder wenn ein Sicherheitsproblem bereits aufgetreten ist.” Tatsächlich sollten CISOs an dieser Stelle als pragmatische Technologieberater fungieren, die wichtige Informationen einholen, für deren Bewertung sie besonders qualifiziert sind. 13 Fragen, die Sie Drittanbietern stellen sollten Die folgenden Fragen unterstützen CISOs und Sicherheitsentscheider dabei, das in der Praxis umzusetzen. 1. Welche Nachweise für angemessene Sicherheitskontrollen können Sie erbringen? Laut Juan Pablo Perez-Etchegoyen, CTO beim Security-Anbieter Onapsis, zählen folgende Nachweise dabei zu den gängigsten: SOC 2 Typ II (gilt als Goldstandard für Auditierungen von IT- und Cloud-Dienstleistern), ISO/IEC 27001, Cloud Security Alliance STAR (speziell für Cloud-Anbieter, kombiniert ISO 27001 mit einer Kontrollmatrix für Cloud-bezogene Risiken), sowie branchenspezifische Zertifizierungen (zum Beispiel HIPAA/HITRUST für den Umgang mit Gesundheitsdaten oder PCI DSS für die Verarbeitung von Kreditkartendaten). 2. Wie werden diese Kontrollen aktualisiert und wie werden wesentliche Änderungen kommuniziert? Anwältin Ventrone empfiehlt zudem,potenzielle IT-Partner mit einem detaillierten Due-Diligence-Fragebogen zu konfrontieren. Darüber hinaus empfiehlt die Rechtsexpertin, spezifische Aspekte vertraglich zu verankern: “Drittanbietern sollte es mindestens untersagt sein, Sicherheitskontrollen zu verändern, die das Schutzniveau oder die Ausfallsicherheit Ihrer Systeme und Daten beeinträchtigen würden.” 3. Wer ist in Ihrem Team für die Identity Posture zuständig und wie erkennt derjenige Anfragen, die auf Social Engineering zurückzuführen sind? Welche Form von Zugriff das Team des Drittanbieters auf Kundensysteme und -daten hat und wie dieser segmentiert und abgesichert ist, sollten Sicherheitsentscheider nach Meinung von Casey Corcoran, Field CISO beim Managed-Service-Anbieter Stratascale, unbedingt erfragen. “Achten Sie darauf, dass dieser Zugriff protokolliert sowie überwacht wird – und bei Bedarf sofort widerrufen werden kann.” Zudem sollten Sicherheitsverantwortliche dabei die richtigen Aspekte ins Auge fassen, wie John Alford, CSO bei der Unternehmensberatung TeraType, betont: “Viele Kunden konzentrieren sich auf Firewalls, Endpunkt-Agenten und MFA – übersehen dabei aber die Trust-Pfade, die Angreifer bevorzugt nutzen: Helpdesk-Workflows, OAuth-Integrationen, Lieferanten-Support-Portale und Automatisierungs-Konnektoren.” Alford empfiehlt seinen Berufskollegen außerdem, auf streng definierte Rollenbereiche, mehrstufige Verifizierungen sowie Approval Chains für den Reset von Anmeldedaten zu achten. “Ist nichts davon vorhanden, deutet das auf blinde Flecken hin, die sich nachträglich nicht beseitigen lassen.” 4. Wie lassen sich Ihre Workflows verifizieren? Können Sie Nachweise über deren Wirksamkeit erbringen? Viele Unternehmen unterschätzen, wie viel operatives Vertrauen sie wirklich an Anbieter abgeben. Deswegen sollten Drittanbieter nicht nur Richtlinien-Dokumente vorweisen können, sondern auch Workflow Maps, Execution-Protokolle und Testing-Belege. “Die größten Lücken treten regelmäßig an den Stellen zutage, die vermeintlich sicher sind. Ich habe schon erlebt, wie gestandene Unternehmen mit ausgeprägten Standards und Kontrollmaßnahmen an Problemen gescheitert sind, für die ausschließlich die Workflows ihres Third-Party-Anbieters verantwortlich waren”, plaudert Alford aus dem Nähkästchen. Risikobewertungen sollten sich seiner Meinung nach deshalb nicht bloß auf auf Server und Netzwerke konzentrieren, sondern auch auf Identitäts-Workflows und manuell gesteuerte Prozesse: “Wenn man den Blickwinkel erweitert, entdeckt man unter Umständen Kontrollmaßnahmen, die lediglich auf dem Papier gut aussehen.” 5. Welche Rolle spielt unabhängiges Testing bei Ihnen und wie oft wird das eingesetzt? Geht es um Security-Tests und -bewertungen bei IT-Partnern, sollten CISOs Wert darauflegen, dass diese von unabhängigen Dritten durchgeführt werden, meint Rechtsexpertin Ventrone. “Das sollte mindestens einmal pro Jahr stattfinden – und bei wesentlichen Änderungen an Netzwerk, Infrastruktur oder Sicherheitskontrollmaßnahmen. Die Zusammenfassungen von Schwachstellen-Scans, Penetrationstests und Audits sollten Sie sich ebenfalls zeigen lassen.” Danny Jenkins, CEO beim Security-Anbieter ThreatLocker, stellt insbesondere auf die Frequenz dieser Überprüfungen ab: “Bedrohungen entwickeln sich ständig weiter. Eine jährliche Prüfung reicht deshalb nicht aus. Sämtliche Systeme sollten regelmäßig Penetrationstests unterzogen und optimiert werden.” 6. Können Sie sämtliche OAuth-Integrationen und API-Beziehungen in Ihrem Service auflisten und erklären, wie diese definiert, überwacht und widerrufen werden? OAuth-Integrationen werden nach Einschätzung von Teratype-CSO Alford allzu oft als harmlose Annehmlichkeiten behandelt – statt als High-Privilege-Kanäle: “In Wirklichkeit funktionieren sie wie ein Netzwerk aus vergessenen Tunneln. Sie bieten eine Möglichkeit, das Eingangstor vollständig zu umgehen und verbinden Systeme tief im Inneren der Umgebung.” Unternehmen sollten ihre Drittanbieter deshalb auffordern, ein Token-Inventar inklusive Minimal Scopes, endlichen Laufzeiten sowie einer Möglichkeit zum Behavioral Monitoring bereitzustellen, so Alford. Permanent gültige Token sieht der Experte hingegen als Warnsignal, das auf ein erhöhtes Risiko hindeutet. 7. Wie sehen Ihre vertraglichen und operativen Pflichten aus, wenn ein Angreifer Ihre Prozesse missbraucht, ohne dabei in Systeme einzudringen? Wenn Drittanbieter Passwörter zurücksetzen oder OAuth-Integrationen managen können, wird der Vertrag zu einem Kontrolldokument. Dieses definiert, wie das Risiko geteilt wird und welche Nachweise der Kunde verlangen kann. An dieser Stelle ist es besonders wichtig, Sicherheitsentscheider in die Verhandlungen mit Third-Party-Anbietern einzubeziehen, wie Alford betont: “Ohne die Beteiligung des CISO bleiben Vertragsklauseln in der Regel eher nachteilig ausgestaltet. Das liegt daran, dass der Fokus ohne Security-Perspektive vor allem auf der Verfügbarkeit liegt – und nicht so sehr auf der Sicherheit. Als Kunde sollten Sie darauf bestehen, dass sich die Pflichten des Anbieters nicht nur auf kompromittierte Systeme, sondern auch kompromittierte Prozesse erstrecken.” 8. Welche Kontrollmaßnahmen kommen zum Einsatz, um die Aktivitäten Ihrer Mitarbeiter in unserer Umgebung zu kontrollieren? Und wie erkennen wir Verhalten, das von der Norm abweicht? “Moderne Angriffskampagnen machen sich Vertrauensbeziehungen und weiche Betriebsprozesse zunutze. Die Gefahr lauert dabei oft dort, wo sie niemand erwartet – beispielsweise Helpdesks”, warnt Alford. Die Aktivitäten der Belegschaft von Drittanbietern zu überwachen sei daher erfolgsentscheidend. Der Sicherheitsprofi empfiehlt deshalb, darauf zu bestehen, dass der Partner Sessions aufzeichnet, Echzeit-Alarmmeldungen zur Verfügung stellt und Aufgaben strikt getrennt werden. 9. Wie isolieren Sie unsere Assets und Daten von denen anderer Kunden? Mit Blick auf potenzielle Third-Party-Anbieter sollten CISOs zudem auf eine klare Architektur und konkrete Maßnahmen achten, die Schaden begrenzen können. Dabei spielt auch eine Rolle, wie der Drittanbieter Risiken in seinen eigenen Lieferketten managt. “IT-Partner sollten über ein robustes Vendor-Management-Programm verfügen und ihre eigenen Dienstleister einer angemessenen Due-Diligence-Prüfung unterziehen”, rät Ventrone. 10. Wie schnell werden wir über Sicherheitsvorfälle informiert, die sich auf unsere Daten oder Systeme auswirken? Von IT-Partnern über potenzielle Sicherheitsvorfälle informiert zu werden, sollte selbstverständlich sein. Dabei sollte jedoch auch eine Rolle spielen, wie zeitnah das erfolgt. Stratascale-Field-CISO Corcoran empfiehlt diesbezüglich: “Der Vertrag sollte eine Meldung des Drittanbieters innerhalb von 24 bis 72 Stunden garantieren. Darüber hinaus sollten Security-Verantwortliche auch auf einen getesteten Incident-Response-Plan sowie weitere vertraglich verankerte Verantwortlichkeiten achten.” Auch Alford sieht bei diesem Punkt kein Potenzial für Kompromisse – Drittanbieter müssten ihren Kunden ausreichend Informationen zur Verfügung stellen, damit diese ihre eigenen Threat-Analysen fahren können: “Geschieht das nicht, können sich Kundenunternehmen lediglich noch auf die Detection- und Reporting-Funktion des Hosting-Anbieters stützen.” 11. Wie identifizieren, priorisieren und beheben Sie Schwachstellen? Da nicht wenige Cyberattacken auf bereits bekannte Schwachstellen abzielen, gilt es bei der Evaluierung von Drittanbietern auch auf Patch-Richtlinien und Remediation-Fristen zu achten. Onapsis-CTO Perez-Etchegoyen klärt über die Risiken in diesem Zusammenhang auf: “Langsame Patch-Zyklen können zu Lieferkettenunterbrechungen, betrieblichen Problemen und manchmal auch zur Insolvenz führen.” Ventrone führt an dieser Stelle das Beispiel eines Unternehmens an, das sein Firewall-Management an einen Drittanbieter ausgelagert hat: “Nachdem eine Schwachstelle in der Firewall ausgenutzt worden war, stellte der Partner schließlich die anfällige Version wieder her – was zu einer zweiten Kompromittierung führte. Um es salopp zu sagen: So etwas kann man sich nicht ausdenken”, konstatiert die Anwältin. 12. Verfügen Sie über eine Cyberversicherung, die mögliche Auswirkungen auf sämtliche Ihrer Kunden abdeckt? Laut Joshua Wright, Faculty Fellow beim SANS Institute, werden die Attacken auf SaaS-Anbieter in Zukunft weiter steigen – und damit auch die nachgelagerten Risiken: “Wird ein solcher Drittanbieter kompromittiert, entstehen diverse Möglichkeiten für Folgeangriffe – etwa mit Ransomware.” Ventrone empfiehlt CISOs deshalb, in Verhandlungen mit Drittanbietern auch sicherzustellen, dass deren Cyberversicherungspolice nicht nur das eigene Unternehmen abdeckt, sondern auch den gesamten Impact eines Vorfalls, bei dem mehrere Kunden betroffen sind. 13. Können wir Ihre Prozesse testen? SANS-Experte Wright hält darüber hinaus auch Nachweise für Testing und Monitoring für unerlässlich – etwa bezogen auf Penetrationstests, Security Monitoring oder Threat Hunting. Alford empfiehlt allerdings, noch einen Schritt weiter zu gehen: “Prozesstests unter Einbeziehung realistischer Szenarien können aufdecken, wo tatsächlich Risiken bestehen. Das gibt Ihnen zudem die Möglichkeit, Kontrollen zu entwickeln, die der Denkweise von Angreifern entsprechen und nicht dem, was in der Dokumentation steht.” (fm) View the full article

In 2026, enterprise developers are building and deploying the first generation of powerful, increasingly autonomous AI agents at incredible speed. Now comes the hard part: working out how to secure them. Vendors in the space are facing multiple challenges. To begin with, traditional identity and access management (IAM) tools were never designed to secure anything as complex as agentic AI. In addition, the number of agents, both those sanctioned by the enterprise and the undocumented ‘shadow’ agents created by a new generation of powerful tools that barely existed a year ago, is increasing at unprecedented speed. And now it has started to dawn on organizations that this risks leaving yawning governance and security gaps whose weaknesses could one day return to haunt their creators. While a growing list of companies, including large cloud platforms such as Okta, Ping Identity, and Microsoft’s Entra ID, is vying to fill the vacuum, a smaller competitor, Sweden’s Curity, argues that agents can’t be secured using traditional IAM. Instead, it is offering a different approach to the problem: This week, it announced Access Intelligence, an extension to its existing API identity and access management (IAM) platform, Identity Server. The problem it addresses is that traditional IAM tools assume that applications are being accessed by human users or machine identities, governed by a one-time authentication process. But agents, which assume long chains of actions conducted at incredible speed, don’t work like this. Instead, access becomes ephemeral, complex, and non-deterministic, which is to say, hugely unpredictable. Lock them down too much and they stop working; let them run free, and weak security follows in their wake. Runtime enforcement Curity’s approach is to treat agents as a special type of application. Like applications, agents call APIs, MCP servers, and each other, and are credentialed using OAuth tokens. Through a feature called Token Intelligence, Curity extends the role of OAuth tokens to not simply permit access, but to carry information on the agent’s purpose and intent. In Curity’s scheme, an agent can only access resources based on that purpose. Instead of using static, pre-granted permissions, agent access is granted at runtime, on-the-fly. Each requested action generates a separate token that describes the access it needs. When an agent starts a new task, it needs a new token specifying a new set of permissions. If necessary, human authorization can be required when an agent is trying to perform a high-risk action such as transferring funds. “Curity has always been application-centric,” said Cofounder and CTO Jacob Ideskog. “Our focus has always been on how we broker access.” Multiple approaches to agent security Today, agent security falls into one of several camps, which include increasingly inadequate inline approaches such as API gateways and web application firewalls (WAFs), and out-of-band analysis systems that infer intent by analyzing agent behavior against a baseline. Curity’s Access Intelligence, by contrast, is a self-hosted microservice that acts as a glorified IAM layer through which every agent request must pass. “Because we let an agent do something now doesn’t mean we should be allowing it to do this a minute later,” Ideskog explained. Access Intelligence also uses Identity Server’s centralized token validation to ensure that developers can fire up agents or APIs without registering them. If they lack this validation, agents are isolated from real-world actions. Nothing does the whole job The appearance of systems such as Access Intelligence is good news for enterprises. It indicates that vendors are starting to address the problem of agent security, often by extending existing API security platforms. But that still leaves open the question of which approach to take. Ideskog believes it would be a mistake to see the different approaches as mutually exclusive. Curity’s Access Intelligence can be used in combination with other layers of agent security, he emphasized. In short, no one solution can do the whole job. “Up to this point, the IAM industry has focused on the identity part. But the real question is the access. Enterprises are asking their privilege access management (PAM) vendors how they’re going to deal with this [agent security] and I don’t think the PAM vendors have good answers yet,” he said. View the full article

Security teams are stretched thin. Alerts never stop, attackers move faster, and expectations for uptime and resilience keep rising. For many IT and security leaders, Managed Detection and Response (MDR) has become less of a “nice to have” and more of a practical way to stay ahead. But outsourcing MDR is not just about handing alerts to someone else. The real question is whether MDR helps you build cyber resilience, the ability to detect threats quickly, contain impact, and keep the business running. Here are four questions to ask when deciding whether MDR belongs in your security strategy. 1. Do you have the coverage to detect threats 24/7? Most attacks do not happen conveniently during business hours. They start late at night, on weekends, or during holidays when teams are understaffed or offline. If alerts sit unreviewed for hours, attackers gain time to escalate privileges, move laterally, and cause damage. MDR closes this gap by providing continuous monitoring across endpoints, identities, and cloud environments. Instead of relying on best‑effort internal coverage, MDR ensures threats are reviewed and acted on around the clock. This is a foundational part of cyber resilience. Faster detection means less dwell time, fewer affected systems, and easier recovery. Without 24/7 coverage, resilience becomes reactive rather than intentional. 2. Can your team separate real threats from noise? Alert fatigue is one of the biggest barriers to effective security. Tools generate volumes of signals, but not all alerts represent real risk. When everything looks critical, teams either burn out or miss the alerts that matter most. MDR helps by applying human expertise and threat intelligence to validate alerts, investigate behavior, and confirm whether activity is truly malicious. Instead of chasing every signal, your team receives clear guidance on what needs action and why. Adlumin MDR™ supports this by correlating identity, endpoint, and network activity, then prioritizing threats based on real attacker behavior. The result is fewer distractions and faster, more confident response. From a resilience perspective, this matters because a delayed or incorrect response often causes more disruption than the attack itself. 3. When an attack happens, can you contain it quickly? Detection alone does not equal resilience. The difference between a security incident and a business‑level disruption often comes down to how quickly you can contain the threat. Effective MDR does more than raise alerts. It helps security teams take action, isolating compromised systems, stopping malicious processes, and preventing spread before attackers reach critical assets. For organizations without a full in-house SOC, MDR provides response capabilities that would otherwise require significant staffing investment. For MSPs, it enables consistent containment across many client environments without scaling headcount linearly. When MDR is integrated with endpoint and identity controls, response becomes faster and more coordinated. This is a key step in minimizing attack impact and maintaining business continuity. 4. Does MDR fit into a broader cyber resilience strategy? MDR is most effective when it is part of a before‑during‑after approach to cyber resilience. Before an attack, reduce exposure with patching, configuration management, and least‑privilege access. Tools like N-central RMM™ help automate these fundamentals. During an attack, MDR detects and contains malicious activity in real time, reducing blast radius. After an attack, fast recovery determines whether operations resume quickly or stall. Cove Data Protection™ supports resilience with cloud‑first, immutable backups and rapid restore options. MDR plays a critical role in the “during” phase, but its value increases when it is connected to prevention and recovery. Resilience is not about any single control. It is about how well your controls work together under pressure. Outsourcing MDR is about resilience, not just resources The decision to outsource MDR is rarely about replacing your security team. It is about extending capabilities, improving response speed, and reducing the operational risk that comes from limited coverage and alert overload. If your team struggles with 24/7 monitoring, alert validation, or rapid containment, MDR can be a practical way to strengthen resilience without adding complexity or headcount. Cyber resilience depends on how quickly you can detect, respond, and recover. MDR helps close those gaps so attacks stay contained and the business keeps moving. Check out the new 2026 State of the SOC Report and get insights based on real-world alerts from the Adlumin MDR SOC. View the full article

The new N-able and Futurum Report reveals how AI is reshaping cyber resilience as it accelerates both business innovation and adversarial tradecraft. Attackers are scaling their operations with unprecedented speed, leveraging automation to bypass traditional defenses. For IT security leaders and MSP owners, the days of relying on static, perimeter-based security are over. To stay ahead, we must look beyond simply keeping attackers out. The future belongs to those who prioritize continuous cyber resilience—the ability to withstand, adapt to, and recover from threats in real-time. Here is where the industry is heading and how AI-powered platforms are redefining defense strategies for the next 3–5 years. 1. AI is both the weapon and the shield We are entering an era of AI-versus-AI warfare. Threat actors are already using generative AI to craft sophisticated phishing campaigns, automate vulnerability scanning, and execute attacks at machine speed. However, AI is also our most powerful ally. Modern defense isn’t about human analysts staring at screens; it’s about leveraging AI for rapid detection, automated triage, and predictive insights. By processing vast amounts of telemetry data, AI can identify subtle anomalies that human teams might miss, allowing for preemptive neutralization of threats before they cause damage. See how AI is altering the landscape in the new N-able and Futurum report, Cybersecurity in the Age of AI: Moving from Fragile to Resilient. Get key insights on building a modern framework for business resilience. 2. From perimeter security to continuous cyber resilience The “castle and moat” approach is obsolete. In a world of hybrid work and distributed cloud environments, the perimeter has dissolved. The new standard is continuous cyber resilience. This shift moves the goalposts from “prevention” to “continuity.” It focuses on always-on monitoring, continuous validation of security postures, and real-time response capabilities. The objective is to ensure that even when a breach attempts to occur, the business keeps running. This requires a mindset shift: resilience is not a product you buy, but a state of operation you maintain. 3. Platform-based security is the new norm Managing dozens of disparate point solutions is a logistical nightmare that introduces security gaps. The industry is rapidly consolidating toward integrated platforms that offer a unified view of the threat landscape. For MSPs and enterprise IT leaders, platform-based security offers streamlined operations and better data correlation. By unifying endpoint management, threat detection, and backup solutions, organizations can reduce complexity and improve their mean time to response (MTTR). 4. Human-centric security operations Despite the rise of AI, the human element remains critical—but the role is changing. We are moving toward human-centric security operations where AI handles the low-value, repetitive work, freeing up analysts to focus on high-impact strategic decisions. Automation is the key to alleviating burnout. By automating alert triage and routine remediation tasks, we can improve the analyst experience and ensure that human expertise is applied where it matters most: complex threat hunting and strategic resilience planning. Explore the benefits of integrating AI into your cybersecurity strategy and learn how it revolutionizes your security operations across crucial threat detection and response stages. 5. Regulation, reporting, and resilience mandates Regulatory pressure is mounting. Governments, insurers, and customers are no longer satisfied with improved security promises; they demand demonstrable resilience. Expect to see stricter mandates around incident reporting timelines and resilience metrics. Organizations will need to prove not just that they are secure, but that they can recover quickly and effectively from disruptions. This transparency will become a competitive differentiator in the market. Compliance is not just about checking boxes. Our solutions, like Adlumin MDR, offer enhanced compliance support with one-touch reporting. Preparing your organization for the future The next few years will separate the reactive from the resilient. To future-proof your defense, consider these actionable steps: Assess platform readiness: Evaluate whether your current toolset supports integration and automation or if it creates silos. Invest in automation: Look for opportunities to automate routine tasks and free up your team for strategic work. Build resilience metrics: Move beyond simple uptime stats. Measure your ability to recover and adapt to new threats. Align teams: Ensure that IT and security teams are working in lockstep, supported by a unified platform vision. The N-able vision for AI-powered resilience At N-able, we are committed to fueling your IT success by staying ahead of the curve. We see a future where our platform evolves continuously, leveraging AI not just to detect threats, but to anticipate them. Our vision is to provide partners and customers with an ecosystem that supports continuous threat hunting, intelligent automation, and seamless recovery. As the threat landscape evolves, so do we—ensuring you have the foundation needed to secure your clients effectively. The right partner makes all the difference. To learn more, visit us here. View the full article