CSOonline

New Report Highlights Surge in Exposed API Keys, Session Tokens, and Machine Identities, and more. SpyCloud, the leader in identity threat protection, today released its annual 2026 Identity Exposure Report, one of the most comprehensive analyses of stolen credentials and identity exposure data circulating in the criminal underground and highlighting a sharp expansion in non-human identity (NHI) exposure. Last year, SpyCloud saw a 23% increase in its recaptured identity datalake, which now totals 65.7B distinct identity records. The report shows attackers are increasingly targeting machine identities and authenticated session artifacts in addition to traditional username and password combinations and personally identifiable information (PII). “We’re witnessing a structural shift in how identity is exploited,” said Trevor Hilligoss, Chief Intelligence Officer at SpyCloud. “Attackers are no longer just targeting credentials. They’re stealing authenticated access, including API keys, session tokens and automation credentials, and using this access to move faster, stay persistent, and scale attacks across cloud and enterprise environments.” Key Findings from the 2026 Identity Exposure Report: Non-Human Identities Are Now a Core Attack Surface SpyCloud recaptured 18.1 million exposed API keys and tokens in 2025, spanning payment platforms, cloud infrastructure providers, developer ecosystems, collaboration tools, and AI services. The report also identified 6.2 million credentials or authentication cookies tied to AI tools, reflecting rapid enterprise adoption of AI platforms and the associated expansion of machine-based access paths. Unlike human credentials, these NHIs often lack MFA enforcement, rotate infrequently, and operate with broad permissions. When exposed, they can provide attackers with persistent access to production systems, software supply chains, and cloud infrastructure. Phishing is an Enterprise Threat SpyCloud recaptured 28.6 million phished identity records in 2025. Notably, nearly half of those identities were corporate users, reinforcing that phishing remains a persistent enterprise threat. This trend aligns with SpyCloud research showing that successful phishing attacks have surged 400% YoY. The result is a clear warning to enterprises: their workforce is now 3x more likely to be targeted with phishing attacks than infostealer malware. Modern phishing datasets increasingly contain more than credentials. Many include session cookies, authentication tokens, and MFA workflow data, allowing attackers to assume authenticated sessions without triggering traditional alerts. With an influx of bad actors leveraging AI to craft more realistic lures and automate campaigns, this problem is not going away anytime soon, and enterprise security teams must go beyond employee training for a more true preventative approach. Session Theft and MFA Bypass Continue at Scale SpyCloud recaptured 8.6 billion stolen cookies and session artifacts exposed through malware infections, demonstrating continued attacker focus on session hijacking techniques that bypass traditional authentication safeguards. In parallel, SpyCloud analysis of underground combolists found that 51% of records overlapped with previously observed infostealer logs, indicating that criminals are increasingly repackaging malware-exfiltrated data rather than relying solely on fresh breach disclosures. Public reporting throughout the past year has documented multiple MFA bypass campaigns leveraging adversary-in-the-middle (AitM) phishing kits and session replay techniques, including activity targeting Microsoft 365 environments through stolen authentication tokens. On March 4, 2026, Europol announced, in partnership with Microsoft and other private organizations, that it had executed a coordinated seizure of Tycoon 2FA – a major phishing-as-a-service infrastructure and service that enabled widespread MFA bypass through AitM techniques – and disrupted its operational capabilities significantly. SpyCloud supported the global disruption effort by contributing victim identity intelligence and operational analysis drawn from criminal underground sources. The recent operation highlights the industrialization of phishing and the growing value of session artifacts in attacker workflows. Malware Continues to Exfiltrate Identity Data Despite the rise of phishing, infostealer malware remains a significant contributor to identity exposure, enabling attackers to harvest credentials, cookies, and authentication tokens from infected devices. SpyCloud recaptured over 642.4 million exposed credentials from 13.2 million infostealer malware infections in 2025. That’s an average of 50 exposed user credentials per malware infection – further expanding the amount of entry points available to bad actors. A notable portion of infections occurred on endpoints with EDR or antivirus tools installed, reinforcing that endpoint controls alone are not sufficient to prevent identity theft. Credential Exposure Remains High, with Weak Password Hygiene SpyCloud recaptured 5.3 billion credential pairs – stolen credentials consisting of usernames or email addresses and passwords. Among exposed corporate credentials, 80% contained plaintext passwords, significantly lowering the barrier to immediate account takeover attacks. Once again, predictable patterns tied to pop culture, sports, and short numeric strings continue to be used broadly. Top trendy passwords include: 67 / sixseven: 140.4M sweet / cookie / candy / cake / pie: 5.7M chiefs / kansas city chiefs: 5M 2025: 4.1M apple / banana / orange / strawberry / fruit: 2.6M Password reuse remains widespread, and the report also identified 1.1 million password manager master passwords circulating in underground sources, raising concerns about vault-level compromise when master credentials are weak. The Expanding Identity Exposure Surface The 2026 report highlights a central shift in identity threats and underscores the need for continuous identity threat protection across both human and machine identities. Attackers are combining breach data, phishing captures, malware logs, session tokens, and machine credentials to construct composite identity profiles that fuel everything from session hijacking and ransomware to supply chain compromise. As organizations accelerate cloud adoption and embed AI tools across workflows, machine identities are becoming deeply integrated into critical systems. The theft of these credentials and authentication tokens can create downstream ripple effects far beyond a single compromised account. “The challenge isn’t just stopping phishing or malware,” Hilligoss added. “It’s understanding how exposed identities connect across systems, vendors, and automation workflows.” He continues, “SpyCloud has recaptured nearly one trillion stolen identity assets in our 10 years of disrupting cybercrime. It’s the basis of our insights on the evolution of identity sprawl and the ways in which bad actors aim to weaponize data against individuals and businesses. But there is good news for defenders. When organizations continuously monitor exposure and build in automated remediation workflows – we’ve seen how that can significantly shrink the attacker’s window of opportunity, and that’s a win worth fighting for.” Full report and in-depth analysis available here. About SpyCloud SpyCloud transforms recaptured darknet data to disrupt cybercrime. Its automated identity threat protection solutions leverage advanced analytics and AI to proactively prevent ransomware and account takeover, detect insider threats, safeguard employee and consumer identities, and accelerate cybercrime investigations. SpyCloud’s data from breaches, malware-infected devices, and successful phishes also powers many popular dark web monitoring and identity theft protection offerings. Customers include seven of the Fortune 10, along with hundreds of global enterprises, mid-sized companies, and government agencies worldwide. Headquartered in Austin, TX, SpyCloud is home to more than 200 cybersecurity experts whose mission is to protect businesses and consumers from the stolen identity data criminals are using to target them now. To learn more and see insights on your company’s exposed data, users can visit spycloud.com. Contact Katie Hanusik REQ on behalf of SpyCloud [email protected] View the full article

RSA Conference 2026 arrives at a significant inflection point for the cybersecurity industry — one that will see its more than 43,000 attendees and 600-plus exhibitors navigating an agenda that has fundamentally shifted in character. For the first time, “AI” is not a track at RSAC. It is the event. Of the 450-plus sessions across four days, approximately 40% of the entire agenda is AI-weighted. Only two of 29 tracks are explicitly labeled as being dedicated to “AI,” but that understates the penetration entirely. AI is now embedded as a core component across every other track: Identity, Cloud Security, CISO Insights, the Human Element, and Threat Intelligence alike. This is not a trend. It is a structural shift in what cybersecurity leadership means and speaks to the largest gap in knowledge that the CISO is trying to address personally. The CISO’s defining tension at RSAC 2026 The CISO arrives at RSAC this year in the wake of many FOMO conversations involving their board and management. The competitive pressure to adopt AI, in products and operations, is real and accelerating. Each CISO sits at the center of that pressure, navigating a dual mandate that has no easy resolution: Enable AI adoption fast enough to stay competitive. Secure the enterprise against a threat landscape that AI itself is creating. These are not sequential problems, unfortunately; they are parallel ones. I’d argue that RSAC 2026 is your best opportunity this year as a security leader to close the knowledge gap. AI prioritised Learning Framework RSAC can be overwhelming. And while CISOs are accustomed to working in environments where demand for their attention exceeds supply, prioritizing where to focus your learning investment at the conference in order of strategic return is essential. Following are my suggestions in priority order. If you are attending with a team, then I suggest you “divide and conquer” across these domains rather than clustering around the same keynotes and sessions. 1. Technical priority: Securing the AI stack RAG workflows, LLM data pipelines, vector databases, and model APIs have introduced an attack surface that most security teams are not yet equipped to defend. Prompt injection, training data poisoning, and model inversion attacks are no longer theoretical. The technical sessions at RSAC 2026 on AI infrastructure security are essential viewing for any CISO whose organizations are moving AI initiatives from pilot to production. 2. Compliance priority: AI governance and policy The EU AI Act is no longer theoretical. Boards are beginning to ask whether the organization has a defensible “licence to operate” framework for AI deployment. Most don’t. RSAC offers the most concentrated set of sessions on AI governance, regulatory compliance, and policy architecture available anywhere in 2026. Getting clarity on AI governance posture is vital for the CISO. 3. Operational priority: Non-human identity The explosion of AI agents, autonomous bots, and service accounts has created an identity management problem of a different order of magnitude. Non-human identities now routinely outnumber human ones in enterprise environments. NHI governance is rapidly becoming one of the most consequential operational gaps in enterprise security. RSAC 2026 treats it seriously for the first time at scale. 4. Risk priority: Shadow AI and vibe coding AI-assisted development by non-technical staff is on the rise. Product managers are building automations, marketers are writing code with AI assistance, and executives are prompting their way to data analysis at many organizations today, largely invisible to security teams. Unsanctioned AI tool usage and inadvertent data exfiltration through consumer AI platforms is a real risk. Then we have AI-generated code moving into production without security review. CISOs need to be on top of these surging risk categories. 5. Strategic priority: SOC autonomous remediation The AI-native SOC, where detection, triage, and remediation operate with meaningful autonomy is now moving from aspiration to early reality. What can be done to prepare the SOC for AI and agentic systems is a high strategic priority for many security leaders. The underlying message RSAC has always been the industry’s annual calibration point. In 2026 it is something more specific than that: It is the moment where the cybersecurity profession collectively confronts what it means to lead security in an AI-native world. Every CISO who leaves San Francisco with a clearer governance framework and a more honest assessment of their AI stack exposure will be measurably better positioned than those who attended the same event and just collected vendor swag. The AI knowledge gap for the CISO is real. RSAC 2026 is your window to start closing it. View the full article

Last year, most businesses faced a cloud security incident. Here’s what stands out — it wasn’t sophisticated cybercriminals behind these events. Instead, basic errors opened the door. According to the Cloud Security Alliance’s 2024 report on risks in cloud computing, misconfigured settings caused nearly every single breach. Just one wrong switch — that’s all it took. Imagine a closet left swinging open, keys hanging on the knob. Not every login needs extra checks — some skip them entirely. Barriers at entrances often allow free passage, like welcome mats rolled out. Code sometimes holds passwords in plain sight, exposed by oversight. None of this happens once in a blue moon. This is how fortunes slip away, reputations crumble, records spill into the wild and teams are stuck playing catch-up for weeks. Far from fancy digital theft, this mess lives in corners left unvisited. Each gap feeds the problem — no oversight, just open doors. The scale of the crisis What stands out first? The scale feels unreal. According to IBM’s 2025 report on data breach expenses, breaches globally now cost an average of 4.44 million dollars. Yet within the United States, each event costs 10.22 million. Still, beyond these shocking totals lies something deeper, harder to capture fully through stats alone. Take the 2024 Snowflake incident — dozens of companies caught in it, half a billion lives touched. AT&T saw 109 million client files slip away. Then there’s Ticketmaster, where nearly 560 million entries vanished into hacker hands. Even Santander exposed details of 190 million individuals. Yet how did they break through? Logging in was enough. Real credentials gave them access to profiles missing extra login safeguards. What stands out is how old issues still cause harm. A faulty web app firewall opened the door for Capital One’s 2019 incident. Over 100 million customers were affected by that slip, followed by an $80 million penalty, then another $190 million paid later. For close to two years, Football Australia had live API keys visible in their site’s code — no protection at all. As a result, 127 data stores became reachable. Toyota kept customer files in a public cloud setup for nine years, maybe ten. Around 260,000 accounts slipped out during that time A further deep dive paints the real picture: Most cloud setup errors — 8 out of 10 — happen because people slip up, not because code fails. One out of three cloud setups sits empty, ignored by any oversight. A third of online storage spaces get zero attention from monitors. Almost one out of every two hundred storage units on Amazon’s cloud sits open, per a 2024 report by monitoring firm Datadog. Their findings spotlight how common loose settings remain across web-based file systems. 50% of the time, fixing leaks runs about ninety-four days long. What comes after discovery drags on for nearly three months. Strange how often this happens. It shouldn’t take long for stolen logins to cause harm — yet here, hackers had over three months just waiting. The Snowflake incident relied on old data pulled years ago, sitting untouched since 2020. No new passwords were issued, no extra login steps added and zero checks on odd activity. A pattern returns, messy and ignored. Why this keeps happening Strange how something so clear stays unsolved — misconfigurations stick around despite being easy to spot. From chats with several CISOs and cloud experts, similar reasons pop up each time. One thing leads to another, then patterns emerge. Imagine trying to keep track of it all — modern cloud environments are packed with endless pieces working at once. Juggle this: resources spread through countless accounts, scattered across regions and platforms. Think about AWS — with its 200-plus tools, every one loaded with settings you can tweak. Then there’s Azure, where the count climbs past six hundred offerings. Finding a single person who could handle all of that manually — while staying accurate — is impossible. Numbers simply refuse to cooperate in that situation. Folks move fast these days. While developers ship updates constantly, old security steps — meant for monthly rollouts — get in the way. What once worked now drags things behind. Folks on teams walk past these issues, saying they’ll return down the line to sort it out. Truth? That future moment slips away every time. Out of sight, out of mind — that’s how it often goes. Hidden tech pops up in every department. Workers set up online tools without asking anyone first, slipping past checks. When coders build trial setups, they sometimes leave them running. Those unnoticed spots? Perfect nests for errors. Eventually, something gives — rarely does a friendly face catch it first. Owning things brings trouble, too. When cloud companies manage hardware, users still need to secure settings and information themselves. Sounds straightforward until you try it. Think back to the Snowflake incident. People assumed Snowflake would catch dangers before they spread. What happened at Snowflake? Customers were supposed to enable MFA. Yet somehow, every team assumed someone else had handled it. With no one verifying setup completion, hackers entered without resistance. Right then, complexity hits hard when speed piles on top. Blind spots grow where clarity should be. Unclear boundaries mix in with too few skilled hands around. Missteps return — no surprise there. The path forward Good news? This situation isn’t hopeless. While zero-day flaws leave you idle, waiting on updates, misconfigurations aren’t like that. They sit in your hands. The power to resolve lies with you. Quick wins: Flip the switch on multi-factor authentication wherever you can. Honestly. Following the Snowflake incident, investigators looked back — nearly all break-ins could’ve been stopped cold by MFA. Treat it like a rule with no exceptions. Go through each cloud service within the month ahead. Wherever that extra login step is gone, put it in place. Start poking around each S3 bucket, then slide into Azure Blobs, and later hop over to Google Cloud Storage spots. Check that none of them are sitting out in the open without meaning to be. Flip the switch on public access blockers right at the account root — keeps things locked down. Turn on notifications so a warning lands in your lap whenever something sneaks into public view, no matter how it got there. Start with logs. Without clear records, spotting problems becomes guesswork. When something goes wrong, answers come from entries made earlier. Turn on AWS CloudTrail across every login. Include Azure Activity Log too — no gaps allowed. GCP Cloud Audit Logs need activation just the same. Each system must record actions taken. Skip none. Miss nothing. Might want to glance at your network settings while you’re at it. Rules letting everything in through 0.0.0.0/0? Those are best removed. Admin entry should come only from IPs you know and expect. Strategic move: Cloud Security Posture Management tools help spot problems quickly. Always watching, they catch mistakes in how systems are set up. One study from 2025 found firms using these tools dropped exposure time from weeks to less than two days. Mistakes linger much shorter now. Fewer openings exist for those trying to break in. Start treating infrastructure as code like real code — with real risks. Before anything hits the cloud, check every Terraform file or CloudFormation setup you’ve got. Errors found early skip the chaos of live systems later. Build security checks right into how things get built, step by step. That way, flawed setups never slip through to where they run. When done right, trusting nothing by default works in your favor. A misconfigured setting might slip through, yet damage stays contained. Rely on minimal permissions instead of broad ones, slice systems apart like layers, and each check happens fresh, even if the request arrives familiar. Confirm every entry point without exception. Last thing — put energy into your team. Everyone handling cloud systems should have actual hands-on security learning. Push them toward official certifications. Help security folks understand development work, while developers learn what security needs — balance builds better talk. You’ve got a lot of control here. Take it. The culture question Most problems won’t vanish just because tools are added. Getting cloud safety right takes effort from every corner — security people can’t carry it solo. When coders pick shortcuts, risks grow — that truth needs to land early. Training for system managers must match the cloud world, not recycled advice from older systems. Support from top leaders shows up best when budgets shift, and decisions include risk checks. Not everything has to move fast. Slowing down can mean doing it right, especially when safety is involved. This isn’t failure — this is how solid systems grow. Clever groups figure out how to weave protection into tools, so progress keeps flowing. The stakes are real Out here, moving to the cloud doesn’t simply shift tech — it reshapes how fast companies grow and what they’re able to try. Getting security right opens doors most never reach. Slip up, though, and risk swallows everything. Speed without safety turns into danger. Few thought weak login steps could unravel so fast. Snowflake’s lapse exposed over 165 groups, touching half a billion lives. Bills pile high — likely hundreds of millions — fed by ransoms, penalties, court fights and shattered trust. Weak shields opened doors; missing extra checks on logins made it worse. This moment is real, not a distant threat. What unfolds today hits hard when cloud safety takes a back seat. Cyber intruders shift focus steadily toward online infrastructure. Rules tighten across regions; an example stands clear: CISA’s recent order pushes government bodies to secure digital environments firmly. A realistic optimism Most cloud security problems come from mistakes in setup. The good part is that these are simpler to solve than other issues. Instead of hoping it works, run checks using CSPM software. Policies stick better when written directly into the system code. People pay attention if they understand what’s at stake. When safety becomes normal talk, fewer errors slip through. Risk drops once habits shift toward caution. The tools are out there. Clear methods stand proven. Case after case shows what actually moves the needle. Right now, the hurdle sits inside — getting everyone on board together. Facing facts comes first. Funding follows. Then understanding settles: how you set up systems shapes everything in cloud safety. Here’s the truth: Misconfigured settings spark every cloud breach. Get set up right, and security follows. Errors costing millions? Entirely avoidable. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Multi-factor authentication was supposed to be the solution. For years, security teams have told employees that MFA would keep them safe. Password stolen? No problem — attackers still need that second factor. But adversary-in-the-middle (AiTM) phishing has changed everything. These attacks do not try to steal passwords and MFA codes separately. They capture the entire authentication flow in real time, including the session token that proves a user is logged in. The employee does everything right — checks for HTTPS, verifies the MFA prompt, avoids suspicious attachments — and still gets compromised. This should concern every security leader. If our training, our MFA and our security awareness programs cannot protect someone who is genuinely trying to be careful, then what exactly are we promising when we tell users MFA will keep them safe? Why this is not the phishing you trained for Traditional phishing meant sloppy fake login pages with typos and dodgy URLs. Those pages could not handle MFA because they had no connection to the real authentication service. Here is what changed, and I wish more security leaders understood this: modern phishing pages are not fake. They are proxies. Tools like Evilginx sit between the user and the legitimate service — Microsoft, Google, Okta, whatever — and relay everything in real time. The employee types their password. It goes to Microsoft. Microsoft sends the MFA challenge. It flows back through the proxy to the employee’s phone. The employee approves it. The session cookie — that golden token proving authentication — passes right back through the proxy into the attacker’s hands. The employee sees a successful login and gets on with their day. The attacker takes that same session cookie, opens a browser on a completely different machine, and they are in. No password needed. No MFA prompt. Just a clean, authenticated session that belongs to someone else. What bothers me most is how quiet it is. There are no failed login attempts. No MFA fatigue bombing. No brute force alerts. Everything looks normal because, technically, everything was normal. The authentication was real. The attacker just watched it happen. And this is not a nation-state technique anymore. Phishing-as-a-Service platforms — Tycoon 2FA, Sneaky2FA, FlowerStorm — have turned this into a commodity. According to Barracuda’s frontline security predictions, over 90 percent of credential compromise attacks are expected to involve sophisticated phishing kits by the end of 2026. A separate Barracuda threat report found that 90 percent of high-volume phishing campaigns in 2025 relied on PhaaS kits, with the number of known kits doubling over the year. You do not need to understand reverse proxies to run this attack. You need a credit card and a subscription. Three failures that keep showing up Through my research into adversary-in-the-middle attacks and reviewing industry incident reports, I have identified three consistent failures that make these attacks successful. 1. We trained our people for the wrong threat Most security awareness programs still teach the same things: Look for misspellings, check the sender address, hover over links. That advice was built for 2015 phishing. In an adversary-in-the-middle attack, there are no misspellings because the page is real — it is being proxied from the actual service. The SSL certificate is valid because the proxy obtains its own legitimate certificate. The login flow behaves exactly as expected because it is the real login flow, just observed by someone in the middle. Security researchers have tested this extensively. Setting up an Evilginx proxy against a test tenant and sending phishing links to security professionals — people who know what phishing looks like — consistently catches a significant number of them. If people whose literal job is spotting these attacks cannot tell the difference, expecting finance or HR staff to do so is unrealistic. Research from Push Security confirms phishing has gone omni-channel, with roughly one in three phishing attacks now delivered outside of email entirely, through channels like LinkedIn DMs and Google Search. 2. We trust session cookies too much Once MFA is completed, most organisations treat the resulting session as sacred. The user proved who they are, so we let them work. But session cookies are bearer tokens — whoever holds them is the authenticated user. There is no binding between the cookie and the device that generated it. There is no fingerprint. There is no anchor. An attacker who steals a session cookie from London can replay it from an entirely different location, and the identity provider will accept it as the legitimate user. Research from Silverfort demonstrated that even after successful FIDO2 authentication, many identity providers remain vulnerable to session hijacking because the session tokens created after authentication are not adequately protected. 3. We react to credential theft, not session theft Incident response playbooks are built around compromised passwords: Force a reset, revoke tokens, re-enroll MFA. But in an adversary-in-the-middle attack, the password is not the primary concern — the session is. Industry reports consistently show response teams resetting passwords and considering the case closed, while attackers continue operating on stolen sessions for days. If you are not revoking all active sessions and monitoring for session replay, you are not actually remediating the compromise. What actually works The uncomfortable truth is that traditional MFA — push notifications, SMS codes, authenticator apps — cannot defend against adversary-in-the-middle phishing. The authentication succeeds because it is real authentication. The attacker simply observes and copies the result. Here is what actually makes a difference. Deploy phishing-resistant authentication FIDO2 security keys and passkeys bind authentication cryptographically to the specific domain. If the login request comes from a proxy domain instead of the real service, the key refuses to sign the challenge. According to Microsoft’s documentation on passkeys, passkeys use origin-bound public key cryptography, ensuring credentials cannot be replayed or shared with malicious actors. Rolling out hardware keys can be challenging — budget approvals take time, users need training. But start somewhere. Finance teams, IT admins and executives should be first. The people with the most valuable access need the strongest authentication. It is worth noting that Proofpoint researchers have demonstrated a downgrade attack against FIDO in Microsoft Entra ID by spoofing an unsupported browser, so organisations should also disable fallback authentication methods where possible. Bind sessions to devices Conditional Access policies that require managed, compliant devices create a hardware anchor that cookie replay cannot bypass. If someone steals a session cookie and tries to replay it from an unmanaged machine, the session gets killed. This is one of the most impactful changes organisations can implement. It is not foolproof, but it eliminates the easiest replay vector overnight. Monitor for session anomalies, not just failed logins The adversary-in-the-middle attack does not generate failed logins. It generates perfect-looking successful ones. The signals are in what happens after authentication. Watch for impossible travel between the authentication IP and subsequent session activity. Watch for new MFA device registration within minutes of login. Watch for inbox rule creation. Barracuda’s threat analysis highlights that attackers are increasingly using MFA code theft via relay attacks and targeting MFA recovery flows, making post-authentication monitoring more critical than ever. These are the post-compromise actions that attackers perform consistently, and building detection rules around these patterns catches attempts that traditional monitoring misses entirely. Rebuild your security awareness training Stop teaching people to spot phishing pages — they cannot, not against modern attacks. Push Security’s analysis notes that the vast majority of phishing attacks today use reverse proxies capable of bypassing most forms of MFA in real time, and that old-school approaches to URL blocking leave defenders two steps behind attackers. Instead, teach employees one simple rule: If you did not initiate the login yourself by typing the URL directly, do not trust it. Do not click login links in emails, even if they look legitimate. Navigate to the service directly. Bookmark your login pages. And give people a simple, frictionless way to report anything that feels wrong, even if they cannot explain why. The uncomfortable conclusion The security industry spent years telling organisations that MFA was the answer. It was — for the threats we had then. But the threat has evolved, and our defenses have not kept pace. Adversary-in-the-middle phishing does not break MFA. It does not need to. It sits patiently in the middle, watches the authentication happen exactly as designed, and copies the result. Our strongest defence does not fail — it succeeds, and the attacker benefits anyway. The organisations that recognise this shift and move to phishing-resistant authentication will be protected. The rest are waiting for a breach that will look exactly like a normal Monday morning login — until it is too late. We told our employees MFA would keep them safe. We owe them a defence that actually does. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

The Trump administration’s decision to ban AI company Anthropic from Pentagon assets and other government systems as a “supply chain risk” could force CISOs into a position few have faced before: preparing to identify, isolate, and potentially remove a specific AI technology from across their organizations without a clear understanding of where it resides or how deeply it is embedded. While the administration is defending the designation in federal court as a legitimate national security and supply chain measure, the practical burden is already shifting to enterprises, particularly government contractors that may soon be expected to prove they are no longer using the company’s technology in any form. “It’s basically impossible … to say with a high degree of confidence they removed Anthropic from everything in their environment,” Tom Pace, CEO of NetRise, tells CSO, capturing the problem in operational terms. That difficulty stems from a longstanding gap that is now becoming unavoidable. Most enterprises do not maintain a complete or current inventory of how AI systems are used across their environments, nor do they fully understand how those systems are embedded across their networks. AI models may be accessed directly through APIs, embedded in internally developed applications, incorporated into developer workflows, or introduced indirectly through third-party software and services. In many cases, those dependencies are invisible to central security teams, particularly in organizations where experimentation with generative AI has outpaced governance. Even so, the Pentagon is moving aggressively to strip Anthropic technology from both its internal networks and those of contractors. A March 6 Pentagon memo directs military components to remove Anthropic products from systems and networks within 180 days, prioritizing mission-critical environments such as nuclear, missile defense, and cyber operations. The directive also requires contracting officers to notify vendors and obligates contractors to certify compliance within the same timeframe, effectively extending the requirement across the defense industrial base. The administration’s actions mark a shift in how AI technologies are treated in the national security context. Models are no longer just tools; they are being treated as regulated components of the supply chain. For CISOs, that shift introduces a new class of risk — one that combines policy uncertainty, technical opacity, and potentially aggressive compliance timelines. A mandate that assumes visibility CISOs don’t yet have On paper, the Pentagon’s directive follows a familiar pattern. It establishes a deadline, prioritizes critical systems, cascades requirements to contractors, and allows only limited exemptions under controlled conditions. Similar frameworks have been used in past efforts to remove specific vendors from federal systems, particularly in telecommunications. What distinguishes the Anthropic case is the nature of the technology involved. Unlike hardware or traditional software components, AI systems are not easily enumerated. A single model can be accessed through multiple interfaces, embedded in different applications, or wrapped in layers of tooling that obscure its origin. Dependencies can also be transitive, appearing through libraries, plugins, or services integrated into broader systems. That complexity makes the first step — identifying where Anthropic is used — far more difficult than the directive implies. Pace likened the challenge to the industry’s experience with Log4j, where organizations struggled to locate a widely used component buried across sprawling software ecosystems. In the case of AI, the problem is compounded by the fact that not all dependencies behave like traditional software artifacts — or are even visible as such. The lack of visibility is reflected in broader industry readiness. According to Cisco’s 2025 AI Readiness Index, only 31% of organizations say they are fully equipped to secure agentic AI systems, while just 27% report having granular access controls over AI systems and datasets. Those figures suggest that even basic governance over AI usage remains incomplete across much of the enterprise landscape, leaving organizations poorly positioned to respond to a directive that assumes a level of insight many do not yet have. Compliance pressure before policy clarity For organizations that do business with the federal government, the implications extend beyond technical challenges into legal and contractual risk. Alex Major, co-chair of government contracts and global trade practice at law firm McCarter and English, tells CSO that supply chain designations like the Anthropic ban tend to move quickly from policy statements into enforceable requirements, even when formal acquisition rules lag. “You can’t manage what you haven’t found,” Major says, emphasizing that the immediate task for CISOs is to determine where Anthropic dependencies exist across their systems and supplier networks. That process, he says, must be approached as both a technical and a compliance exercise. Organizations may need to document how they identified affected systems, what steps they took to remove or replace components, and how they validated that those steps were effective. In a certification environment, the ability to demonstrate due diligence can be as important as the technical outcome. At the same time, Major cautioned against acting too quickly in regulated environments without appropriate controls. “Slow down,” he advises. “Get your supply chain analysis in shape and don’t do anything until those things have happened.” He adds, “If you’re moving quickly, the compliance risk of a hasty removal in a sensitive environment can exceed the compliance risk of a deliberate, documented transition plan.” No agreement on when to act That tension is reflected in the lack of consensus among experts about how CISOs should respond in the near term. The Pentagon’s directive provides a clear signal for defense-related systems, but the broader policy landscape remains unsettled, leaving organizations to interpret how aggressively to act. Daniel Bardenstein, CEO and co-founder of Manifest, argues that the current policy framework does not yet provide the specificity needed to justify sweeping changes across enterprise environments. “It is not an executive order,” he tells CSO. “It’s not an OMB memo.” He described the guidance as incomplete and insufficiently detailed to translate into operational requirements, particularly given the complexity of AI systems and the existing gaps in software supply chain security. Pace takes a more pragmatic view for organizations already operating within federal environments. “If you are part of the federal government, you have to remove all evidence and use of Anthropic, period,” he says. At the same time, Pace acknowledged that many organizations are likely to delay action until requirements are formalized across procurement and regulatory frameworks. That hesitation reflects a broader uncertainty about how to respond to a policy that is still evolving, even as early enforcement signals emerge. The visibility problem predates AI The difficulty of identifying AI dependencies is not entirely new. It builds on longstanding challenges in software supply chain visibility, where organizations have struggled to maintain accurate inventories of the components in their systems. Chris Wysopal, founder and chief security evangelist of Veracode, tells CSO that the Anthropic situation highlights how those challenges are now extending into AI. “It’s a huge change for people selling software to the federal government,” he says, noting that companies are being asked to account for the models inside their products in ways they have not previously had to do. Wysopal said that some form of bill of materials can help organizations determine whether a specific technology appears in their software, particularly when responding to customer or regulatory requirements. At the same time, he cautioned that replacing models may not be trivial if applications have been built around specific capabilities, requiring adjustments to code, workflows, and testing processes. AI-BOM or SBOM? The question of how to achieve that visibility has sparked an active debate about whether existing software bill of materials (SBOM) frameworks are sufficient for AI, or whether organizations need a new approach. Amy Chang, leader of AI threat intelligence and security researcher at Cisco Systems, argues that traditional SBOMs do not capture the full scope of AI systems. “AI systems include models, agents, prompts, and data,” she says. “If you only track packages, you’re missing how the system actually functions.” Her view is that organizations need a more dynamic representation of how AI systems operate, including how models interact with data and other components, to understand risk and manage change effectively. Allan Friedman, the “father” of SBOM and now technologist in residence at TPO group, offers a more measured perspective. He agrees that transparency is essential but cautions against assuming that visibility alone will solve the problem. “Transparency will not solve all your problems,” he tells CSO, noting that organizations must integrate that information into broader risk management processes. “We still need a red team, and some of these basic security techniques to remind people that SBOM has never picked up my dry cleaning, not once,” he adds. “So thinking about how you take that transparency data and integrate it into your broader supply program is going to be important.” NetRise’s Pace rejects the premise that AI requires its own new bill of materials category, arguing that a properly implemented SBOM should already capture AI-related components. In his view, the problem is not the absence of a new framework, but the incomplete adoption of existing ones. “AI-BOMs are stupid,” he says. “There’s no such thing as an AI-BOM. You have an SBOM, which identifies AI components. AI is software, last time I checked.” The disagreement reflects a deeper uncertainty about how to model AI supply chain risk at a time when organizations are being asked to act on it. Removal is not the same as replacement Even if organizations can identify where Anthropic technology is used, removing it is only part of the challenge. Replacement introduces its own set of complexities, particularly when applications have been designed around specific model behaviors. Dependencies may be embedded deep within applications or introduced through third-party software, requiring coordination across vendors and development teams. In some cases, replacing a model may require reworking prompts, retraining systems, or revalidating outputs to ensure that functionality and performance are maintained. Anand Oswal, EVP at Palo Alto Networks, emphasizes that visibility is only one component of a broader security strategy. Organizations also need continuous discovery, testing, and runtime controls to manage AI risk as systems evolve. “You need a full AI security solution,” he tells CSO, arguing that AI systems are dynamic, with models, data, and behaviors that change over time, making static inventories insufficient without ongoing monitoring and governance. “You want complete visibility into your AI applications, your AI agents, your AI tools, your plugins, the data they’re accessing, everything around that whole infrastructure of AI that is being used to build your applications or agents. Once you do that, that’s discovery. It’s a good thing. It’s a start.” A new category of supply chain risk The Anthropic case represents a shift in how governments approach AI technologies, treating models and their associated ecosystems as supply chain components that can be restricted or removed. For CISOs, the challenge is not simply responding to a single directive, but preparing for a future in which similar actions could be applied to other AI providers not only by the US government, but also by regulators and customers. That requires visibility into AI dependencies, clarity about how those dependencies are used, and a strategy for replacing them without disrupting critical systems. As those expectations take shape, organizations are being asked to operate at a level of insight and control that many have not yet achieved. As Friedman cautions, “Everyone is moving quickly to build on these systems without really understanding what’s inside them.” Greater collaboration across the software and AI supply chain may eventually make that problem more manageable, he said, but for now the gap between what organizations are expected to know and what they can actually see remains wide. View the full article

The Trump administration’s decision to ban AI company Anthropic from Pentagon assets and other government systems as a “supply chain risk” could force CISOs into a position few have faced before: preparing to identify, isolate, and potentially remove a specific AI technology from across their organizations without a clear understanding of where it resides or how deeply it is embedded. While the administration is defending the designation in federal court as a legitimate national security and supply chain measure, the practical burden is already shifting to enterprises, particularly government contractors that may soon be expected to prove they are no longer using the company’s technology in any form. “It’s basically impossible … to say with a high degree of confidence they removed Anthropic from everything in their environment,” Tom Pace, CEO of NetRise, tells CSO, capturing the problem in operational terms. That difficulty stems from a longstanding gap that is now becoming unavoidable. Most enterprises do not maintain a complete or current inventory of how AI systems are used across their environments, nor do they fully understand how those systems are embedded across their networks. AI models may be accessed directly through APIs, embedded in internally developed applications, incorporated into developer workflows, or introduced indirectly through third-party software and services. In many cases, those dependencies are invisible to central security teams, particularly in organizations where experimentation with generative AI has outpaced governance. Even so, the Pentagon is moving aggressively to strip Anthropic technology from both its internal networks and those of contractors. A March 6 Pentagon memo directs military components to remove Anthropic products from systems and networks within 180 days, prioritizing mission-critical environments such as nuclear, missile defense, and cyber operations. The directive also requires contracting officers to notify vendors and obligates contractors to certify compliance within the same timeframe, effectively extending the requirement across the defense industrial base. The administration’s actions mark a shift in how AI technologies are treated in the national security context. Models are no longer just tools; they are being treated as regulated components of the supply chain. For CISOs, that shift introduces a new class of risk — one that combines policy uncertainty, technical opacity, and potentially aggressive compliance timelines. A mandate that assumes visibility CISOs don’t yet have On paper, the Pentagon’s directive follows a familiar pattern. It establishes a deadline, prioritizes critical systems, cascades requirements to contractors, and allows only limited exemptions under controlled conditions. Similar frameworks have been used in past efforts to remove specific vendors from federal systems, particularly in telecommunications. What distinguishes the Anthropic case is the nature of the technology involved. Unlike hardware or traditional software components, AI systems are not easily enumerated. A single model can be accessed through multiple interfaces, embedded in different applications, or wrapped in layers of tooling that obscure its origin. Dependencies can also be transitive, appearing through libraries, plugins, or services integrated into broader systems. That complexity makes the first step — identifying where Anthropic is used — far more difficult than the directive implies. Pace likened the challenge to the industry’s experience with Log4j, where organizations struggled to locate a widely used component buried across sprawling software ecosystems. In the case of AI, the problem is compounded by the fact that not all dependencies behave like traditional software artifacts — or are even visible as such. The lack of visibility is reflected in broader industry readiness. According to Cisco’s 2025 AI Readiness Index, only 31% of organizations say they are fully equipped to secure agentic AI systems, while just 27% report having granular access controls over AI systems and datasets. Those figures suggest that even basic governance over AI usage remains incomplete across much of the enterprise landscape, leaving organizations poorly positioned to respond to a directive that assumes a level of insight many do not yet have. Compliance pressure before policy clarity For organizations that do business with the federal government, the implications extend beyond technical challenges into legal and contractual risk. Alex Major, co-chair of government contracts and global trade practice at law firm McCarter and English, tells CSO that supply chain designations like the Anthropic ban tend to move quickly from policy statements into enforceable requirements, even when formal acquisition rules lag. “You can’t manage what you haven’t found,” Major says, emphasizing that the immediate task for CISOs is to determine where Anthropic dependencies exist across their systems and supplier networks. That process, he says, must be approached as both a technical and a compliance exercise. Organizations may need to document how they identified affected systems, what steps they took to remove or replace components, and how they validated that those steps were effective. In a certification environment, the ability to demonstrate due diligence can be as important as the technical outcome. At the same time, Major cautioned against acting too quickly in regulated environments without appropriate controls. “Slow down,” he advises. “Get your supply chain analysis in shape and don’t do anything until those things have happened.” He adds, “If you’re moving quickly, the compliance risk of a hasty removal in a sensitive environment can exceed the compliance risk of a deliberate, documented transition plan.” No agreement on when to act That tension is reflected in the lack of consensus among experts about how CISOs should respond in the near term. The Pentagon’s directive provides a clear signal for defense-related systems, but the broader policy landscape remains unsettled, leaving organizations to interpret how aggressively to act. Daniel Bardenstein, CEO and co-founder of Manifest, argues that the current policy framework does not yet provide the specificity needed to justify sweeping changes across enterprise environments. “It is not an executive order,” he tells CSO. “It’s not an OMB memo.” He described the guidance as incomplete and insufficiently detailed to translate into operational requirements, particularly given the complexity of AI systems and the existing gaps in software supply chain security. Bardenstein later clarified to CSO that the Department of War has no way to actually enforce the memo and understand whether there are Anthropic models in software systems without demanding transparency artifacts (like AI-inclusive SBOMs) from contractors and DOW developers. Pace takes a more pragmatic view for organizations already operating within federal environments. “If you are part of the federal government, you have to remove all evidence and use of Anthropic, period,” he says. At the same time, Pace acknowledged that many organizations are likely to delay action until requirements are formalized across procurement and regulatory frameworks. That hesitation reflects a broader uncertainty about how to respond to a policy that is still evolving, even as early enforcement signals emerge. The visibility problem predates AI The difficulty of identifying AI dependencies is not entirely new. It builds on longstanding challenges in software supply chain visibility, where organizations have struggled to maintain accurate inventories of the components in their systems. Chris Wysopal, founder and chief security evangelist of Veracode, tells CSO that the Anthropic situation highlights how those challenges are now extending into AI. “It’s a huge change for people selling software to the federal government,” he says, noting that companies are being asked to account for the models inside their products in ways they have not previously had to do. Wysopal said that some form of bill of materials can help organizations determine whether a specific technology appears in their software, particularly when responding to customer or regulatory requirements. At the same time, he cautioned that replacing models may not be trivial if applications have been built around specific capabilities, requiring adjustments to code, workflows, and testing processes. AI-BOM or SBOM? The question of how to achieve that visibility has sparked an active debate about whether existing software bill of materials (SBOM) frameworks are sufficient for AI, or whether organizations need a new approach. Amy Chang, leader of AI threat intelligence and security researcher at Cisco Systems, argues that traditional SBOMs do not capture the full scope of AI systems. “AI systems include models, agents, prompts, and data,” she says. “If you only track packages, you’re missing how the system actually functions.” Her view is that organizations need a more dynamic representation of how AI systems operate, including how models interact with data and other components, to understand risk and manage change effectively. Allan Friedman, the “father” of SBOM and now technologist in residence at TPO group, offers a more measured perspective. He agrees that transparency is essential but cautions against assuming that visibility alone will solve the problem. “Transparency will not solve all your problems,” he tells CSO, noting that organizations must integrate that information into broader risk management processes. “We still need a red team, and some of these basic security techniques to remind people that SBOM has never picked up my dry cleaning, not once,” he adds. “So thinking about how you take that transparency data and integrate it into your broader supply program is going to be important.” NetRise’s Pace rejects the premise that AI requires its own new bill of materials category, arguing that a properly implemented SBOM should already capture AI-related components. In his view, the problem is not the absence of a new framework, but the incomplete adoption of existing ones. “AI-BOMs are stupid,” he says. “There’s no such thing as an AI-BOM. You have an SBOM, which identifies AI components. AI is software, last time I checked.” The disagreement reflects a deeper uncertainty about how to model AI supply chain risk at a time when organizations are being asked to act on it. Removal is not the same as replacement Even if organizations can identify where Anthropic technology is used, removing it is only part of the challenge. Replacement introduces its own set of complexities, particularly when applications have been designed around specific model behaviors. Dependencies may be embedded deep within applications or introduced through third-party software, requiring coordination across vendors and development teams. In some cases, replacing a model may require reworking prompts, retraining systems, or revalidating outputs to ensure that functionality and performance are maintained. Anand Oswal, EVP at Palo Alto Networks, emphasizes that visibility is only one component of a broader security strategy. Organizations also need continuous discovery, testing, and runtime controls to manage AI risk as systems evolve. “You need a full AI security solution,” he tells CSO, arguing that AI systems are dynamic, with models, data, and behaviors that change over time, making static inventories insufficient without ongoing monitoring and governance. “You want complete visibility into your AI applications, your AI agents, your AI tools, your plugins, the data they’re accessing, everything around that whole infrastructure of AI that is being used to build your applications or agents. Once you do that, that’s discovery. It’s a good thing. It’s a start.” A new category of supply chain risk The Anthropic case represents a shift in how governments approach AI technologies, treating models and their associated ecosystems as supply chain components that can be restricted or removed. For CISOs, the challenge is not simply responding to a single directive, but preparing for a future in which similar actions could be applied to other AI providers not only by the US government, but also by regulators and customers. That requires visibility into AI dependencies, clarity about how those dependencies are used, and a strategy for replacing them without disrupting critical systems. As those expectations take shape, organizations are being asked to operate at a level of insight and control that many have not yet achieved. As Friedman cautions, “Everyone is moving quickly to build on these systems without really understanding what’s inside them.” Greater collaboration across the software and AI supply chain may eventually make that problem more manageable, he said, but for now the gap between what organizations are expected to know and what they can actually see remains wide. View the full article

Jack the sparow | shutterstock.com Ein Cloud Access Security Broker (CASB) sitzt zwischen Enterprise-Endpunkten und Cloud-Ressourcen und fungiert dabei als eine Art Monitoring-Gateway. Eine CASB-Lösung: gewährt Einblicke in Benutzeraktivitäten in der Cloud, setzt Access-Control-Richtlinien durch und hält Ausschau nach Security-Bedrohungen. Standalone-Lösungen im Bereich Cloud Access Security Broker erfreuen sich wachsender Beliebtheit. Laut den Analysten von Mordor Intelligence soll sich der CASB-Markt bis 2029 auf ein Volumen von 24,2 Milliarden Dollar aufblähen (2023: 11 Milliarden Dollar) – bei einer jährlichen Wachstumsrate von 17 Prozent. Den Research-Experten zufolge ist diese Entwicklung im Wesentlichen der zunehmenden Cloud-Akzeptanz, den wachsenden Sorgen in punkto Datensicherheit sowie der steigenden Nachfrage nach integrierten Security-Lösungen zuzuschreiben. Darüber hinaus ist wichtig zu wissen, dass Cloud Access Security Broker auch eine Schlüsselkomponente umfassenderer Sicherheitsstrategien sind. Diese sind im Wesentlichen unter zweierlei Bezeichnungen bekannt: Der Begriff Secure Service Edge (SSE) entstammt dem Analystenhaus Gartner und hat sich inzwischen als De-Facto-Nomenklatur etabliert. SSE bezeichnet die Integration von CASB, Secure Web Gateway (SWG) und Zero Trust Network Access (ZTNA). Network Edge Security as a Service (NESaaS) heißt dasselbe Konstrukt aus CASB, SWG und ZTNA bei den Marktforschern von IDC. Die 5 wichtigsten CASB-Anwendungsfälle Der ursprüngliche Use-Case für Cloud Access Security Broker war es, Schatten-IT-Instanzen zu bekämpfen: CASB-Tools können Security-Teams dabei unterstützen, nicht autorisierte – oder nicht gemanagte – Cloud Services zu identifizieren und zu überwachen. Inzwischen hat sich das Use-Case-Portfolio von CASB jedoch erheblich erweitert: Datenschutz durchsetzen. Die Pandemie ist vorbei, viele Mitarbeiter kehren zumindest teilweise ins Büro zurück – aber die Applikationen und Daten aus Remote-Work-Zeiten befinden sich weiterhin in der Cloud. Hybride Cloud-Umgebungen erfordern allerdings, sensible Daten angemessen zu schützen. Compliance umsetzen. In einem Umfeld sich stets verschärfender Datenschutzregularien sind CASB-Tools ein wichtiges Instrument, um entsprechende Richtlinien durchzusetzen. Remote-Arbeit absichern. Unabhängig vom Standort der Mitarbeiter können Unternehmen mit einem Cloud Access Security Broker Sicherheitsstandards implementieren sowie den Remote-Zugriff auf Cloud-Ressourcen absichern. Bedrohungen erkennen. CASB-Lösungen können bösartige Aktivitäten und Kompromittierungsversuche detektieren. Darüber hinaus sind die Tools in der Lage, Warnmeldungen in Echtzeit zu generieren. Das sollten Cloud Access Security Broker leisten Rein funktional betrachtet, zeichnen sich CASB-Lösungen hauptsächlich durch vier Features aus: Sichtbarkeit: Sie bieten umfassende Einblicke in Cloud-Nutzung, Benutzeraktivitäten und Datenflüsse. Kontrolle: Sie bieten granulare Kontrollmöglichkeiten mit Blick auf User-Berechtigungen und Datenzugriff. Datenschutz: Sie bieten Funktionen, um sensible Informationen über mehrere Cloud-Dienste hinweg zu schützen. Compliance: Sie unterstützen dabei, Datenschutzbestimmungen einzuhalten. Von diesen Kernfunktionen abgesehen, sollten Unternehmen zudem sicherstellen, dass sich das CASB-Tool ihrer Wahl möglichst gut in bestehende Cloud Services, Applikationen und Security-Infrastrukturen integrieren lässt. In Sachen Deployment stehen im Regelfall zwei Optionen zur Wahl – Proxy- oder API-basiert. Die Mehrheit der Branchenkenner vertritt dabei die Meinung, dass letztgenannter Ansatz bessere Funktionalitäten bietet. Allerdings sollten Anwenderunternehmen auch sichergehen, dass die API Connections des Anbieters mit dem eigenen Cloud-App-Inventar in Einklang stehen. Die wichtigsten CASB-Anbieter und -Lösungen Die CASB-Anbieterlandschaft wird sowohl von IT-, beziehungsweise Technologie-Riesen als auch von traditionellen Sicherheitsanbietern bevölkert. Wir haben im Folgenden die wichtigsten Anbieter und ihre Angebote im Bereich Cloud Access Security Broker für Sie zusammengestellt. Cisco Cloudlock Der Netzwerkriese Cisco hat bereits im Jahr 2016 das CASB-Startup Cloudlock übernommen und dessen Technologie und Branding in sein Portfolio integriert. Bei Cisco Cloudlock handelt es sich um einen Cloud-nativen Cloud Access Security Broker, der Nutzer, Daten und Apps mit einem automatisierten Ansatz schützen soll und APIs nutzt, um Risiken im Cloud-Ökosystem zu managen. Laut Cisco setzt die Lösung auch fortschrittliche Machine-Learning-Algorithmen ein, um Anomalien zu erkennen und bietet Data-Loss-Prevention (DLP)-Funktionalitäten. Richtlinienbasierte Kontrollen sollen dafür sorgen, dass gefährliche Aktivitäten je nach Berechtigung und Risikostufe blockiert werden können. Forcepoint One CASB Auch der Sicherheitsanbieter Forcepoint hat im Jahr 2021 mit Bitglass einen Standalone-CASB-Spezialisten übernommen, den Gartner bis dahin in seinem Magic Quadrant als “Leader” im Bereich CASB einstufte. In der Folge hat Forcepoint die Technologie von Bitglass mit seinen eigenen DLP-Funktionalitäten zu einer SSE-Lösung integriert. Forcepoint One CASB zeichnet sich vor allem durch sein Schatten-IT-Monitoring und -Reporting aus, bringt aber auch Funktionen im Bereich UEBA (User and Entity Behavior Analytics) mit. Die Software unterstützt darüber hinaus Zero-Trust-Architekturen und stellt hierfür Device und User-Authentifizierung zur Verfügung. Microsoft Defender for Cloud Apps Microsoft fokussiert sich mit seinem vollwertigen CASB-Angebot darauf, SaaS-Applikationen abzusichern. Defender for Cloud Apps kann laut den Redmondern Schatten-IT erkennen, gewährt Einblicke in die Cloud-App-Nutzung, schützt vor App-basierten Bedrohungen und liefert Compliance Assessments. Zu den erweiterten Funktionalitäten zählen SaaS Security Posture Management (SSPM), fortschrittlicher Bedrohungsschutz im Rahmen von Microsofts Extended Detection and Response (XDR)-Lösung sowie eine App-Governance-Funktion, die zusätzlichen Bedrohungsschutz für kritische Daten und Ressourcen bieten soll. Netskope One CASB Netskope ist ein Pure-Play-CASB-Original und gilt sowohl im Bereich CASB als auch im Bereich SSE als führend. Laut Forrester Research zeichnet sich der Anbieter durch Innovationskraft über seinen gesamten Technologiestack aus und hat zudem bedeutende Investitionen in den Bereichen Private Global Network, künstliche Intelligenz und Generative AI Security getätigt. Vor kurzem hat der Anbieter sein CASB-Tool außerdem um eine SWG-Funktion erweitert. Palo Alto Next-Generation CASB Basierend auf der Aussage, dass es sich weniger um ein eigenständiges Produkt als vielmehr um eine Reihe integrierter Lösungen wie Inline-Sicherheit, SSPM und Enterprise DLP handelt, bewirbt Palo Alto sein CASB-Offering offensiv als “Next Generation”. Die Lösung soll Anwendungen und Daten in Cloud- und hybriden Arbeitsumgebungen sichern, Daten im Transit zwischen Benutzern und SaaS-Anbietern sichern, Compliance gewährleisten und Schatten-IT-Risiken minimieren. Proofpoint Cloud App Security Broker Proofpoint konzentriert sich mit seinem CASB-Tool darauf, DLP-Funktionen zu erweitern sowie E-Mail- und Cloud-basierte Bedrohungen abzuwenden. Dabei verfolgt die Proofpoint-Lösung einen menschenzentrierten Ansatz: Sie liefert detaillierte Insights darüber, wer sensible Daten erstellt, diese besitzt, herunter- oder hochlädt, teilt und bearbeitet. Aber das Tool kann auch Benutzer identifizieren, bei denen Phishing-Angriffe erfolgreich verlaufen sind, oder die Personen, die am häufigsten angegriffen werden. Skyhigh CASB Durch seine Inline-Bereitstellungsmodi (Forward- und Reverse-Proxy) ermöglicht die CASB-Lösung von Skyhigh Security, den User Access zu genehmigten und nicht genehmigten Cloud-Diensten in Echtzeit zu kontrollieren. Dabei konzentriert sich der Sicherheitsanbieter Skyhigh (der zum indischen IT-Konzern Musarubra gehört) darauf, eine umfassende Abdeckung bereitzustellen. Dazu kombiniert die Software Security-Ereignisse und Machine-Learning-Systeme, um Sicherheitsteams dabei zu unterstützen, Fehlalarme von echten Alerts zu unterscheiden. Symantec CloudSOC CASB Symantec wurde 2019 bekanntermaßen von Broadcom übernommen. Die CloudSOC CASB-Lösung soll SaaS-Anwendungen über extensive API-Integrationen und Inline-Traffic-Analysen überwachen können. Dabei verspricht Symantec – respektive Broadcom – vollständige Transparenz und automatisierte Detektion von Hochrisiko-Benutzern, kompromittierten Konten und Insider-Aktivitäten. Individuelle, verhaltensbasierte Bedrohungs-Scores für Benutzer ermöglichen darüber hinaus, Risiken zeitnah zu identifizieren. Die Symantec-Lösung automatisiert darüber hinaus die Klassifizierung regulierter Daten, die in und aus Anwendungen fließen und setzt Richtlinien durch. DLP- und CSPM-Funktionen sind ebenfalls geboten. Zscaler CASB Das CASB-Tool von Zscaler bietet Inline-, Echtzeit- und Out-of-Band-Scanning-Funktionen, um Daten zu schützen, Bedrohungen zu blockieren, Compliance zu gewährleisten und Transparenz zu schaffen. Zu den wichtigsten Funktionen der Lösung zählen die “Agentless Cloud Browser Isolation” um BYOD- und Drittanbieter-Geräte abzusichern, Advanced Threat Protection um Malware von Cloud-Ressourcen fernzuhalten, Cloud Sandboxing, um Ransomware und Zero-Day-Exploits Einhalt zu gebieten sowie Risk Scores für ungenehmigte Apps. 16 Fragen vor dem Invest in Cloud Access Security Broker Einen Cloud Access Security Broker anzuschaffen, kann ein komplexes Unterfangen darstellen: Die Liste möglicher Funktionen ist – je nach Definition – lang. Und CASB-Tools selbst sind Teil eines breiter angelegten Trends hin zu SSE- und SASE-Plattformen, die wiederum Funktionen wie ZTNA oder SD-WAN umfassen. Soll heißen: Unternehmen müssen ihre jeweiligen, spezifischen Probleme identifizieren – und anschließend einen Anbieter auswählen, der ihre unmittelbaren Anforderungen erfüllt. Um Sie dabei zu unterstützen, haben wir einige wichtige Fragen zusammengestellt, die Sie sich selbst und dem Anbieter Ihrer Wahl vor dem Kauf einer CASB-Lösung stellen sollten. 8 Fragen, die Sie sich stellen sollten Habe ich einen guten Überblick darüber, auf welche Cloud-Dienste meine Benutzer zugreifen – einschließlich Auftragnehmer und andere Drittanbieter? Verfüge ich über ein solides Datenklassifizierungssystem, um zu wissen, welche Art von Daten sensibel oder unternehmenskritisch sind? Verfüge ich über Richtlinien für die Zugriffskontrolle in On-Premise- und Cloud-Umgebungen? Habe ich klare Ziele? Wie sieht meine Prioritätensetzung bei der Suche nach einer CASB-Lösung aus? Wie lässt sich eine CASB-Lösung in meine bestehende Sicherheitsinfrastruktur integrieren? Wie fügt sich der Kauf eines CASB-Tools in meine Security-Roadmap ein? Welche Rolle könnten mit Blick auf die Zukunft SSE oder SASE spielen? Verfüge ich über ausreichend Budget für ein neues Tool? Verfüge ich über das interne Personal, um das Tool vor Ort zu implementieren und zu managen? Ist ein Cloud-basierter Managed Service möglicherweise die bessere Option? 8 Fragen, die Sie Ihrem CASB-Anbieter stellen sollten Welche Funktionen sind in Ihrem CASB-Produkt enthalten? Sind DLP und SWG enthalten oder handelt es sich um zusätzliche Module? Wie sieht Ihre Roadmap für SSE und SASE aus? Viele Anbieter haben Standalone-CASB-Tools gekauft und sie in ihr Portfolio integriert. Welchen Grad der Integration haben Sie erreicht? Wie passt dieses Tool jetzt und in Zukunft in meine bestehende Sicherheitsinfrastruktur, wenn ich mehr Sicherheitsfunktionen in die Cloud migriere? Welche geografischen Gebiete decken Sie ab? Decken Ihre APIs alle Cloud-Dienste ab, die wir nutzen? Skaliert Ihr Produkt, wenn unser Unternehmen wächst? Wie hoch sind die initialen sowie die längerfristigen Kosten? Wie steht es um die Total Cost of Ownership? View the full article

Jack the sparow | shutterstock.com Ein Cloud Access Security Broker (CASB) sitzt zwischen Enterprise-Endpunkten und Cloud-Ressourcen und fungiert dabei als eine Art Monitoring-Gateway. Eine CASB-Lösung: gewährt Einblicke in Benutzeraktivitäten in der Cloud, setzt Access-Control-Richtlinien durch und hält Ausschau nach Security-Bedrohungen. Standalone-Lösungen im Bereich Cloud Access Security Broker erfreuen sich wachsender Beliebtheit. Laut den Analysten von Mordor Intelligence soll sich der CASB-Markt bis 2029 auf ein Volumen von 24,2 Milliarden Dollar aufblähen (2023: 11 Milliarden Dollar) – bei einer jährlichen Wachstumsrate von 17 Prozent. Den Research-Experten zufolge ist diese Entwicklung im Wesentlichen der zunehmenden Cloud-Akzeptanz, den wachsenden Sorgen in punkto Datensicherheit sowie der steigenden Nachfrage nach integrierten Security-Lösungen zuzuschreiben. Darüber hinaus ist wichtig zu wissen, dass Cloud Access Security Broker auch eine Schlüsselkomponente umfassenderer Sicherheitsstrategien sind. Diese sind im Wesentlichen unter zweierlei Bezeichnungen bekannt: Der Begriff Secure Service Edge (SSE) entstammt dem Analystenhaus Gartner und hat sich inzwischen als De-Facto-Nomenklatur etabliert. SSE bezeichnet die Integration von CASB, Secure Web Gateway (SWG) und Zero Trust Network Access (ZTNA). Network Edge Security as a Service (NESaaS) heißt dasselbe Konstrukt aus CASB, SWG und ZTNA bei den Marktforschern von IDC. Die 5 wichtigsten CASB-Anwendungsfälle Der ursprüngliche Use-Case für Cloud Access Security Broker war es, Schatten-IT-Instanzen zu bekämpfen: CASB-Tools können Security-Teams dabei unterstützen, nicht autorisierte – oder nicht gemanagte – Cloud Services zu identifizieren und zu überwachen. Inzwischen hat sich das Use-Case-Portfolio von CASB jedoch erheblich erweitert: Datenschutz durchsetzen. Die Pandemie ist vorbei, viele Mitarbeiter kehren zumindest teilweise ins Büro zurück – aber die Applikationen und Daten aus Remote-Work-Zeiten befinden sich weiterhin in der Cloud. Hybride Cloud-Umgebungen erfordern allerdings, sensible Daten angemessen zu schützen. Compliance umsetzen. In einem Umfeld sich stets verschärfender Datenschutzregularien sind CASB-Tools ein wichtiges Instrument, um entsprechende Richtlinien durchzusetzen. Remote-Arbeit absichern. Unabhängig vom Standort der Mitarbeiter können Unternehmen mit einem Cloud Access Security Broker Sicherheitsstandards implementieren sowie den Remote-Zugriff auf Cloud-Ressourcen absichern. Bedrohungen erkennen. CASB-Lösungen können bösartige Aktivitäten und Kompromittierungsversuche detektieren. Darüber hinaus sind die Tools in der Lage, Warnmeldungen in Echtzeit zu generieren. Das sollten Cloud Access Security Broker leisten Rein funktional betrachtet, zeichnen sich CASB-Lösungen hauptsächlich durch vier Features aus: Sichtbarkeit: Sie bieten umfassende Einblicke in Cloud-Nutzung, Benutzeraktivitäten und Datenflüsse. Kontrolle: Sie bieten granulare Kontrollmöglichkeiten mit Blick auf User-Berechtigungen und Datenzugriff. Datenschutz: Sie bieten Funktionen, um sensible Informationen über mehrere Cloud-Dienste hinweg zu schützen. Compliance: Sie unterstützen dabei, Datenschutzbestimmungen einzuhalten. Von diesen Kernfunktionen abgesehen, sollten Unternehmen zudem sicherstellen, dass sich das CASB-Tool ihrer Wahl möglichst gut in bestehende Cloud Services, Applikationen und Security-Infrastrukturen integrieren lässt. In Sachen Deployment stehen im Regelfall zwei Optionen zur Wahl – Proxy- oder API-basiert. Die Mehrheit der Branchenkenner vertritt dabei die Meinung, dass letztgenannter Ansatz bessere Funktionalitäten bietet. Allerdings sollten Anwenderunternehmen auch sichergehen, dass die API Connections des Anbieters mit dem eigenen Cloud-App-Inventar in Einklang stehen. Die wichtigsten CASB-Anbieter und -Lösungen Die CASB-Anbieterlandschaft wird sowohl von IT-, beziehungsweise Technologie-Riesen als auch von traditionellen Sicherheitsanbietern bevölkert. Wir haben im Folgenden die wichtigsten Anbieter und ihre Angebote im Bereich Cloud Access Security Broker für Sie zusammengestellt. Cisco Cloudlock Der Netzwerkriese Cisco hat bereits im Jahr 2016 das CASB-Startup Cloudlock übernommen und dessen Technologie und Branding in sein Portfolio integriert. Bei Cisco Cloudlock handelt es sich um einen Cloud-nativen Cloud Access Security Broker, der Nutzer, Daten und Apps mit einem automatisierten Ansatz schützen soll und APIs nutzt, um Risiken im Cloud-Ökosystem zu managen. Laut Cisco setzt die Lösung auch fortschrittliche Machine-Learning-Algorithmen ein, um Anomalien zu erkennen und bietet Data-Loss-Prevention (DLP)-Funktionalitäten. Richtlinienbasierte Kontrollen sollen dafür sorgen, dass gefährliche Aktivitäten je nach Berechtigung und Risikostufe blockiert werden können. Forcepoint One CASB Auch der Sicherheitsanbieter Forcepoint hat im Jahr 2021 mit Bitglass einen Standalone-CASB-Spezialisten übernommen, den Gartner bis dahin in seinem Magic Quadrant als “Leader” im Bereich CASB einstufte. In der Folge hat Forcepoint die Technologie von Bitglass mit seinen eigenen DLP-Funktionalitäten zu einer SSE-Lösung integriert. Forcepoint One CASB zeichnet sich vor allem durch sein Schatten-IT-Monitoring und -Reporting aus, bringt aber auch Funktionen im Bereich UEBA (User and Entity Behavior Analytics) mit. Die Software unterstützt darüber hinaus Zero-Trust-Architekturen und stellt hierfür Device und User-Authentifizierung zur Verfügung. Microsoft Defender for Cloud Apps Microsoft fokussiert sich mit seinem vollwertigen CASB-Angebot darauf, SaaS-Applikationen abzusichern. Defender for Cloud Apps kann laut den Redmondern Schatten-IT erkennen, gewährt Einblicke in die Cloud-App-Nutzung, schützt vor App-basierten Bedrohungen und liefert Compliance Assessments. Zu den erweiterten Funktionalitäten zählen SaaS Security Posture Management (SSPM), fortschrittlicher Bedrohungsschutz im Rahmen von Microsofts Extended Detection and Response (XDR)-Lösung sowie eine App-Governance-Funktion, die zusätzlichen Bedrohungsschutz für kritische Daten und Ressourcen bieten soll. Netskope One CASB Netskope ist ein Pure-Play-CASB-Original und gilt sowohl im Bereich CASB als auch im Bereich SSE als führend. Laut Forrester Research zeichnet sich der Anbieter durch Innovationskraft über seinen gesamten Technologiestack aus und hat zudem bedeutende Investitionen in den Bereichen Private Global Network, künstliche Intelligenz und Generative AI Security getätigt. Vor kurzem hat der Anbieter sein CASB-Tool außerdem um eine SWG-Funktion erweitert. Palo Alto Next-Generation CASB Basierend auf der Aussage, dass es sich weniger um ein eigenständiges Produkt als vielmehr um eine Reihe integrierter Lösungen wie Inline-Sicherheit, SSPM und Enterprise DLP handelt, bewirbt Palo Alto sein CASB-Offering offensiv als “Next Generation”. Die Lösung soll Anwendungen und Daten in Cloud- und hybriden Arbeitsumgebungen sichern, Daten im Transit zwischen Benutzern und SaaS-Anbietern sichern, Compliance gewährleisten und Schatten-IT-Risiken minimieren. Proofpoint Cloud App Security Broker Proofpoint konzentriert sich mit seinem CASB-Tool darauf, DLP-Funktionen zu erweitern sowie E-Mail- und Cloud-basierte Bedrohungen abzuwenden. Dabei verfolgt die Proofpoint-Lösung einen menschenzentrierten Ansatz: Sie liefert detaillierte Insights darüber, wer sensible Daten erstellt, diese besitzt, herunter- oder hochlädt, teilt und bearbeitet. Aber das Tool kann auch Benutzer identifizieren, bei denen Phishing-Angriffe erfolgreich verlaufen sind, oder die Personen, die am häufigsten angegriffen werden. Skyhigh CASB Durch seine Inline-Bereitstellungsmodi (Forward- und Reverse-Proxy) ermöglicht die CASB-Lösung von Skyhigh Security, den User Access zu genehmigten und nicht genehmigten Cloud-Diensten in Echtzeit zu kontrollieren. Dabei konzentriert sich der Sicherheitsanbieter Skyhigh (der zum indischen IT-Konzern Musarubra gehört) darauf, eine umfassende Abdeckung bereitzustellen. Dazu kombiniert die Software Security-Ereignisse und Machine-Learning-Systeme, um Sicherheitsteams dabei zu unterstützen, Fehlalarme von echten Alerts zu unterscheiden. Symantec CloudSOC CASB Symantec wurde 2019 bekanntermaßen von Broadcom übernommen. Die CloudSOC CASB-Lösung soll SaaS-Anwendungen über extensive API-Integrationen und Inline-Traffic-Analysen überwachen können. Dabei verspricht Symantec – respektive Broadcom – vollständige Transparenz und automatisierte Detektion von Hochrisiko-Benutzern, kompromittierten Konten und Insider-Aktivitäten. Individuelle, verhaltensbasierte Bedrohungs-Scores für Benutzer ermöglichen darüber hinaus, Risiken zeitnah zu identifizieren. Die Symantec-Lösung automatisiert darüber hinaus die Klassifizierung regulierter Daten, die in und aus Anwendungen fließen und setzt Richtlinien durch. DLP- und CSPM-Funktionen sind ebenfalls geboten. Zscaler CASB Das CASB-Tool von Zscaler bietet Inline-, Echtzeit- und Out-of-Band-Scanning-Funktionen, um Daten zu schützen, Bedrohungen zu blockieren, Compliance zu gewährleisten und Transparenz zu schaffen. Zu den wichtigsten Funktionen der Lösung zählen die “Agentless Cloud Browser Isolation” um BYOD- und Drittanbieter-Geräte abzusichern, Advanced Threat Protection um Malware von Cloud-Ressourcen fernzuhalten, Cloud Sandboxing, um Ransomware und Zero-Day-Exploits Einhalt zu gebieten sowie Risk Scores für ungenehmigte Apps. 16 Fragen vor dem Invest in Cloud Access Security Broker Einen Cloud Access Security Broker anzuschaffen, kann ein komplexes Unterfangen darstellen: Die Liste möglicher Funktionen ist – je nach Definition – lang. Und CASB-Tools selbst sind Teil eines breiter angelegten Trends hin zu SSE- und SASE-Plattformen, die wiederum Funktionen wie ZTNA oder SD-WAN umfassen. Soll heißen: Unternehmen müssen ihre jeweiligen, spezifischen Probleme identifizieren – und anschließend einen Anbieter auswählen, der ihre unmittelbaren Anforderungen erfüllt. Um Sie dabei zu unterstützen, haben wir einige wichtige Fragen zusammengestellt, die Sie sich selbst und dem Anbieter Ihrer Wahl vor dem Kauf einer CASB-Lösung stellen sollten. 8 Fragen, die Sie sich stellen sollten Habe ich einen guten Überblick darüber, auf welche Cloud-Dienste meine Benutzer zugreifen – einschließlich Auftragnehmer und andere Drittanbieter? Verfüge ich über ein solides Datenklassifizierungssystem, um zu wissen, welche Art von Daten sensibel oder unternehmenskritisch sind? Verfüge ich über Richtlinien für die Zugriffskontrolle in On-Premise- und Cloud-Umgebungen? Habe ich klare Ziele? Wie sieht meine Prioritätensetzung bei der Suche nach einer CASB-Lösung aus? Wie lässt sich eine CASB-Lösung in meine bestehende Sicherheitsinfrastruktur integrieren? Wie fügt sich der Kauf eines CASB-Tools in meine Security-Roadmap ein? Welche Rolle könnten mit Blick auf die Zukunft SSE oder SASE spielen? Verfüge ich über ausreichend Budget für ein neues Tool? Verfüge ich über das interne Personal, um das Tool vor Ort zu implementieren und zu managen? Ist ein Cloud-basierter Managed Service möglicherweise die bessere Option? 8 Fragen, die Sie Ihrem CASB-Anbieter stellen sollten Welche Funktionen sind in Ihrem CASB-Produkt enthalten? Sind DLP und SWG enthalten oder handelt es sich um zusätzliche Module? Wie sieht Ihre Roadmap für SSE und SASE aus? Viele Anbieter haben Standalone-CASB-Tools gekauft und sie in ihr Portfolio integriert. Welchen Grad der Integration haben Sie erreicht? Wie passt dieses Tool jetzt und in Zukunft in meine bestehende Sicherheitsinfrastruktur, wenn ich mehr Sicherheitsfunktionen in die Cloud migriere? Welche geografischen Gebiete decken Sie ab? Decken Ihre APIs alle Cloud-Dienste ab, die wir nutzen? Skaliert Ihr Produkt, wenn unser Unternehmen wächst? Wie hoch sind die initialen sowie die längerfristigen Kosten? Wie steht es um die Total Cost of Ownership? View the full article

SaaS security platform Reco has decided to address the “agent sprawl” challenge from the increased adoption of AI-driven tools by enterprises. It argues that enterprises are faced with a security situation as numerous autonomous agents now traverse multiple systems, accessing sensitive data, and executing actions without direct human oversight. To help contain this risk, the company has made a new capability, “Reco AI Agent Security,” available to its customers starting March 18. The tool is aimed at giving enterprise security teams complete visibility and control over “all AI agents” operating across their SaaS ecosystem. These include Copilot, ChatGPT, and Salesforce Agentforce integrations and automation tools like n8n and Zapier. “Security teams have spent years getting visibility into their SaaS applications, but AI agents operate differently,” said Ofer Klein, CEO and Co-Founder of Reco. “They act autonomously, make decisions without human intervention, and often have permissions across multiple systems. Traditional SaaS security posture management (SSPM) tools weren’t built to see or control this. We’re solving a new category of risk.” The offering is designed to solve the dual challenge of “AI sprawl” and “Agent sprawl,” folding AI agent discovery, risk analysis, and governance into Reco’s existing SaaS security platform. Discovery beyond OAuth The core of the launch focuses on a shift in how AI agents are identified. Reco told CSO that its approach moves past traditional OAuth-based discovery and into a multi-layered detection model that looks at how systems behave, not just how they’re connected. “We track third-party OAuth connections and analyze API call patterns that indicate autonomous behavior, like agents making decisions and executing actions without direct user intervention,” he added. “Many AI agents operate under service accounts or shared credentials. We correlate service account activity across applications to identify agent behavior patterns.” Klein explained that automation tools themselves leave distinct fingerprints. Platforms like n8n, Make, and Zapier exhibit recognizable workflow signatures, which Reco uses to detect and map how these automations interact across systems. “An AI agent accessing 500 Salesforce records per minute looks different from a human user,” he said. Additionally, for native agents like Microsoft Copilot or Salesforce Agentforce, Reco claims to monitor feature enablement, data access patterns, and cross-application activity that traditional SSPM tools categorize as “normal user behavior.” The offering is positioned around real-world patterns observed by Reco, which include shadow automation with excessive permissions, misconfigured enterprise agents, and even credential exposure in AI workflows. In observed incidents, this ranged from agents with full read/write access to customer PII in Salesforce, financial data in NetSuite, source code in GitHub, to an unnamed agent exfiltrating customer data to a personal Airtable account for 8 months before discovery. Aiming where traditional SSPM falls short Reco positions the launch as a break from traditional SSPM, arguing that those tools were never designed for autonomous systems. “SSPM sees connections. We see behavior,” Klein said. While a typical SSPM might flag a Zapier-Salesforce link as a third-party integration, “We identify that this specific Zapier workflow is an AI agent that runs every 15 minutes, accesses customer payment data, enriches it with external APIs, and writes results to a shared spreadsheet, all without human interventions,” he explained, emphasizing the difference in risk profiles. Cross-system visibility is another gap cited by Reco. SSPM tools analyze each application in isolation, whereas Reco recognizes that agents span multiple systems and treats them as one autonomous system with compound risk. These distinctions align with how SSPM tools are generally designed today. Industry definitions describe SSPM as focusing on continuously monitoring SaaS applications for misconfigurations, managing permissions, and identifying risky integrations or compliance gaps. In practice, that means SSPM is effective at answering what is connected and who has access by inventorying applications, tracking OAuth integrations, and flagging overly permissive settings. Reco draws a line in the behavioral context, arguing SSPM tools are less equipped to analyze how an integration behaves once it is approved, and that is where most of the agent-induced risks lie. Reco AI Agent Security is available immediately as part of the company’s existing SaaS security platform, with support for previously noted SaaS, automation, and AI tools at launch and additional integrations expected to roll out on a continuous delivery basis. View the full article

Khakimullin Aleksandr – shutterstock.com Das Bundesamt für Sicherheit in der Informationstechnik (BSI) mahnt einen besseren Schutz sensibler Gesundheitsdaten in Computer-Anwendungen von Arztpraxen, Kliniken und in der Pflege an. Die IT-Sicherheit von Softwareprodukten im Gesundheitswesen sei “ausbaufähig”, teilte das Amt nach Tests von Standardkonfigurationen verschiedener Anwendungen mit. In einem Projekt untersucht wurden demnach unter anderem vier exemplarische Praxisverwaltungssysteme. Dabei habe sich gezeigt, dass bei drei Produkten eine Verkettung einzelner Schwachstellen einen Angriff aus dem Internet ermögliche. Konkret sei es etwa um veraltete und daher unsichere Algorithmen zur Verschlüsselung von Daten gegangen. Über die Schwachstellen seien die Hersteller informiert worden, die sie auch unverzüglich adressiert hätten. (dpa/rs) View the full article

In my role, I spend a lot of time thinking about what “trust” means when money, grief and identity collide. By 2026, the real competition in our space won’t be who automates fastest or offers the most AI features. It will be who can still tell a legitimate executor, beneficiary or family representative from a manufactured persona. We’re building with AI because the benefits are undeniable. But we’re also watching that same technology change the economics of impersonation. Synthetic identities and deepfake-enabled scams have moved from edge cases into constant pressure that slowly wears down controls we used to trust. On paper, identity programs still look strong. Under real-world attack conditions, too many become a thin perimeter that collapses once an adversary applies realism at scale. In estate and identity-related work, that erosion of trust carries extra weight. A synthetic identity can easily misdirect distributions, delay rightful claims and drag families into disputes because the evidence trail looks “complete” even when the person isn’t real. The rise of the digital ghost Synthetic identity fraud means manufacturing whole “people” who never existed—the digital ghosts. Generative models can produce government-style documents, plausible histories and supporting media that clear routine checks, allowing a fake identity to look consistent across systems, channels and time. That’s why the cost can be far higher than a single loss event. A synthetic identity can enter an ecosystem, behave normally long enough to blend in and surface later at the exact moment a claim, profile change or payout is needed. When it succeeds, it pollutes the baselines we used to depend on—risk models, case triage and the patterns analysts learn to trust. Deepfakes raise the stakes further by collapsing the boundary between “digital” and “human.” Video calls, voice verification and live interactions used to feel like stronger proof. Now an adversary can show up with a face, a voice and a coherent story long enough to pass a rushed review. If identity is spoofable, every downstream control runs on contaminated truth, even when the process is compliant and well-documented. Exploiting the deceased and the dormant Attackers follow leverage. Dormant, legacy and deceased identities create leverage because they already come with history, which serves as scaffolding for a synthetic persona to climb. I have seen how quickly a subdued record can become an entry point. An adversary pairs an older account or identity footprint with newly generated documents and a polished support interaction. They request a profile change, a contact update or a payment redirection. They push for a new credential, a new device or a new channel. Each looks like a minute detail in isolation. In sequence, it’s a takeover that feels earned because the activity resembles real life. Traditional trust signals struggle here. Device fingerprinting, behavioral analytics and static biometrics can help, but AI now targets those signals directly. Typing rhythm can be imitated. Mouse movement can be simulated. Voices can be cloned well enough to fool humans who are tired or rushed. Even experienced reviewers lose their advantage because the obvious seams appear less often. That is why this threat feels different inside estate-facing workflows. There is usually a compelling story attached to the request. There is often urgency. There is often emotion. Attackers understand that human pressure and procedural pressure create openings that technical controls alone do not close. Establishing a new standard of proof There’s no plug-and-play fix for synthetic identity. Addressing it means moving past “Who is this?” to a more forensic question such as “How did this identity—and its digital footprint—come to exist?” That shift raises the standard of proof. It prioritizes provenance, issuer verification and cross-channel consistency over surface-level plausibility. It also changes how teams operate. We can’t keep identity signals scattered across separate tools, queues and owners. We need a shared risk view built from independent signals that either reinforce confidence or reveal contradictions. In practice, we examine where artifacts came from, how they were created and whether they were altered. We require stronger proof when risk changes and correlates across channels instead of trusting a single checkpoint. We also have to tighten internal access and auditability. If attackers can impersonate external claimants, they can also target internal workflows. Privileged actions need least privilege, just-in-time access and forensic-grade trails. Engineering accountability into internal workflows Continuous verification has to be a deliberate design choice. A mature program ties the level of proof to the risk of what’s happening right now. A new device shouldn’t be treated like a routine login. A request to change payout instructions should face a higher threshold than a simple record view or address update. That same discipline must apply internally. High-impact roles and machine identities need named owners, documented credential succession plans and access trails that can be reconstructed without guesswork. When something goes wrong, you don’t want an argument about who might have done it. You want evidence. Regulators and boards are moving this way because the old model assumes identity stays stable once “verified.” AI breaks that assumption. Organizations that treat identity assurance as measurable, with clear risk appetite and regular adversarial testing, will be best positioned to defend their decisions with confidence. The 2026 readiness test As we look toward 2026, I keep coming back to one question. Can you prove, at any moment, that the identities behind your highest-impact actions belong to real, accountable humans? If the answer is vague, then AI accelerates the wrong things. It accelerates decisions based on polluted data. It accelerates workflows that can be hijacked by believable fakes. It accelerates outcomes that look compliant until the moment you need to defend them. In our business, we are not just managing accounts and records. We are protecting legacies, resolving obligations and serving people who often have one chance to get it right. Synthetic identity turns that responsibility into a security problem, a governance problem and a human problem all at the same time. Let’s treat it like the new ground truth. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

ClickFix-Kampagnen werden immer raffinierter und zielen verstärkt auf WordPress-Webseiten. Gorodenkoff | shutterstock.com Cyberkriminelle kombinieren kompromittierte Websites mit immer raffinierteren Social-Engineering-Köder-Methoden, um neue Infostealer-Malware zu verbreiten. Bekannt ist das Ganze unter dem Namen ClickFix – und zudem effektiv: In einer einzigen Kampagne wurden über 250 WordPress-Websites in zwölf Ländern infiziert. Während diese Kampagne zu unauffälligen, im Arbeitsspeicher ausgeführten Schadprogrammen führt, beobachtete Microsoft parallel dazu einen weiteren Angriff, der Windows Terminal zum Ausführen der Schadsoftware – anstelle des herkömmlichen Ausführen-Dialogs – nutzt. Die WordPress-Kampagne ist seit Dezember 2025 aktiv und konfrontiert Besucher mit gefälschten Cloudflare-CAPTCHA-Abfragen, wie Forscher des Sicherheitsunternehmens Rapid7 berichten. Zu den kompromittierten WordPress-Websites gehören regionale Nachrichtenportale, Websites lokaler Unternehmen und sogar die offizielle Website eines US-Senatskandidaten. „Der großflächig durchgeführte Angriff auf völlig unabhängige WordPress-Instanzen weist auf einen hohen Automatisierungsgrad seitens der Angreifer hin und ist wahrscheinlich Teil einer organisierten, langfristigen kriminellen Handlung“, heißt es in dem Bericht. Drei gut getarnte Payloads Technisch gesehen, verschickt die WordPress-ClickFix-Kampagne drei separate Infostealer-Payloads – zwei davon bisher unbekannt – und nutzt eine Domain-Infrastruktur, die offenbar seit Juli 2025 existiert. Die Angreifer tarnen ihren eingeschleusten JavaScript-Code als Leistungsoptimierung, die nur dann aktiv wird, wenn der Browser des Besuchers keinen WordPress-Admin-Cookie besitzt. Auf diese Weise soll die Malware vor den Website-Administratoren verborgen werden. Das Skript ruft dann eine gefälschte Cloudflare-CAPTCHA-Abfrage von einer von 14 Angreifer-kontrollierten Domains ab, die alle auf dieselbe IP-Adresse verweisen. Die gefälschte CAPTCHA-Abfrage fordert Besucher dann auf, einen Befehl zu kopieren und in das Windows-Ausführen-Dialogfeld einzufügen. Digitaler Gift-Donut Der schädliche Befehl besteht aus verschleiertem JavaScript- und PowerShell-Code, der den sogenannten DoubleDonut Loader im Arbeitsspeicher startet. Dieser Loader schleust Schadcode direkt in legitime Windows-Prozesse ein. „Die Malware-Kette wird fast ausschließlich im Arbeitsspeicher und im Kontext unauffälliger Windows-Prozesse ausgeführt, was die herkömmliche dateibasierte Erkennung wirkungslos macht“, erläutern die Experten von Rapid7. Da die kompromittierten Websites unterschiedliche WordPress-Versionen oder -Plugins nutzen, gehen die Forscher davon aus, dass die Angreifer möglicherweise schwache Zugangsdaten ausnutzen oder Exploits für mehrere Sicherheitslücken kombinieren. Vidar-Stealer-Variante verwendet Der DoubleDonut Loader wurde dabei beobachtet, wie er eine neue Variante des bekannten Infostealers Vidar Stealer verbreitete. Dieser nutzt eine sogenannte Dead-Drop-Resolver-Technik, um seine Command-and-Control-Konfiguration und die dynamische API-Auflösung zu ermitteln. Zusätzlich entdeckten die Forscher zwei bisher undokumentierte Infostealer, von denen einer in .NET und einer in C++ geschrieben ist. Die von Rapid7 Impure Stealer und VodkaStealer genannten Programme verwenden beide spezielle Techniken, um nicht entdeckt zu werden. Dazu zählen eine ungewöhnliche Datenkodierung, symmetrische Verschlüsselung der Kommunikation oder Sandbox-Erkennung mithilfe system- und zeitbasierter Prüfungen. Köder-Evolution Auch die ClickFix-Taktiken entwickeln sich weiter. So identifizierte das Threat Intelligence Team von Microsoft eine Kampagne, bei der der klassische Ausführen-Dialog (Win+R) durch die Windows Terminal-App (Win+X) ersetzt wurde, um Befehle auszuführen. Dabei wurden unter anderem der bekannte Lumma Stealer und die Fernwartungssoftware NetSupport RAT verbreitet. Eine weitere Angriffskette nutzte VBScript über MSBuild sowie eine Technik namens Etherhiding, um Code zum Sammeln von Anmeldeinformationen herunterzuladen. Beliebt bei staatlichen und privaten Kriminellen Das Sicherheitsunternehmen ESET schätzt, dass die ClickFix-Angriffe im letzten Jahr um 517 Prozent zugenommen haben. Die dabei verwendeten Varianten CrashFix, ConsentFix und PhantomCaptcha sollen dabei mit unterschiedlichen Ködern und Zustellungsmechanismen arbeiten. Diese grundlegende Social-Engineering-Taktik hat sich als so effektiv erwiesen, dass sie sogar von staatlichen Gruppen wie der nordkoreanischen Lazarus-Gruppe, der iranischen MuddyWater-Gruppe und der russischen APT28 angewendet wird. Bereits im Januar berichteten Forscher von Sekoia, dass ein weiteres ClickFix-Framework namens IClickFix seit 2024 in über 3.800 WordPress-Websites eingeschleust wurde. Handlungsempfehlungen Betreiber von WordPress-Websites sollten sicherstellen, dass ihre Admin-Login-Bereiche nicht öffentlich zugänglich sind. Laut Rapid7 war dies bei fast allen Websites nicht der Fall. Zudem hat das Sicherheitsunternehmen Indikatoren für Kompromittierungen und YARA-Erkennungsregeln in seinem öffentlichen GitHub-Repository veröffentlicht. (tf) View the full article

ClickFix-Kampagnen werden immer raffinierter und zielen verstärkt auf WordPress-Webseiten. Gorodenkoff | shutterstock.com Cyberkriminelle kombinieren kompromittierte Websites mit immer raffinierteren Social-Engineering-Köder-Methoden, um neue Infostealer-Malware zu verbreiten. Bekannt ist das Ganze unter dem Namen ClickFix – und zudem effektiv: In einer einzigen Kampagne wurden über 250 WordPress-Websites in zwölf Ländern infiziert. Während diese Kampagne zu unauffälligen, im Arbeitsspeicher ausgeführten Schadprogrammen führt, beobachtete Microsoft parallel dazu einen weiteren Angriff, der Windows Terminal zum Ausführen der Schadsoftware – anstelle des herkömmlichen Ausführen-Dialogs – nutzt. Die WordPress-Kampagne ist seit Dezember 2025 aktiv und konfrontiert Besucher mit gefälschten Cloudflare-CAPTCHA-Abfragen, wie Forscher des Sicherheitsunternehmens Rapid7 berichten. Zu den kompromittierten WordPress-Websites gehören regionale Nachrichtenportale, Websites lokaler Unternehmen und sogar die offizielle Website eines US-Senatskandidaten. „Der großflächig durchgeführte Angriff auf völlig unabhängige WordPress-Instanzen weist auf einen hohen Automatisierungsgrad seitens der Angreifer hin und ist wahrscheinlich Teil einer organisierten, langfristigen kriminellen Handlung“, heißt es in dem Bericht. Drei gut getarnte Payloads Technisch gesehen, verschickt die WordPress-ClickFix-Kampagne drei separate Infostealer-Payloads – zwei davon bisher unbekannt – und nutzt eine Domain-Infrastruktur, die offenbar seit Juli 2025 existiert. Die Angreifer tarnen ihren eingeschleusten JavaScript-Code als Leistungsoptimierung, die nur dann aktiv wird, wenn der Browser des Besuchers keinen WordPress-Admin-Cookie besitzt. Auf diese Weise soll die Malware vor den Website-Administratoren verborgen werden. Das Skript ruft dann eine gefälschte Cloudflare-CAPTCHA-Abfrage von einer von 14 Angreifer-kontrollierten Domains ab, die alle auf dieselbe IP-Adresse verweisen. Die gefälschte CAPTCHA-Abfrage fordert Besucher dann auf, einen Befehl zu kopieren und in das Windows-Ausführen-Dialogfeld einzufügen. Digitaler Gift-Donut Der schädliche Befehl besteht aus verschleiertem JavaScript- und PowerShell-Code, der den sogenannten DoubleDonut Loader im Arbeitsspeicher startet. Dieser Loader schleust Schadcode direkt in legitime Windows-Prozesse ein. „Die Malware-Kette wird fast ausschließlich im Arbeitsspeicher und im Kontext unauffälliger Windows-Prozesse ausgeführt, was die herkömmliche dateibasierte Erkennung wirkungslos macht“, erläutern die Experten von Rapid7. Da die kompromittierten Websites unterschiedliche WordPress-Versionen oder -Plugins nutzen, gehen die Forscher davon aus, dass die Angreifer möglicherweise schwache Zugangsdaten ausnutzen oder Exploits für mehrere Sicherheitslücken kombinieren. Vidar-Stealer-Variante verwendet Der DoubleDonut Loader wurde dabei beobachtet, wie er eine neue Variante des bekannten Infostealers Vidar Stealer verbreitete. Dieser nutzt eine sogenannte Dead-Drop-Resolver-Technik, um seine Command-and-Control-Konfiguration und die dynamische API-Auflösung zu ermitteln. Zusätzlich entdeckten die Forscher zwei bisher undokumentierte Infostealer, von denen einer in .NET und einer in C++ geschrieben ist. Die von Rapid7 Impure Stealer und VodkaStealer genannten Programme verwenden beide spezielle Techniken, um nicht entdeckt zu werden. Dazu zählen eine ungewöhnliche Datenkodierung, symmetrische Verschlüsselung der Kommunikation oder Sandbox-Erkennung mithilfe system- und zeitbasierter Prüfungen. Köder-Evolution Auch die ClickFix-Taktiken entwickeln sich weiter. So identifizierte das Threat Intelligence Team von Microsoft eine Kampagne, bei der der klassische Ausführen-Dialog (Win+R) durch die Windows Terminal-App (Win+X) ersetzt wurde, um Befehle auszuführen. Dabei wurden unter anderem der bekannte Lumma Stealer und die Fernwartungssoftware NetSupport RAT verbreitet. Eine weitere Angriffskette nutzte VBScript über MSBuild sowie eine Technik namens Etherhiding, um Code zum Sammeln von Anmeldeinformationen herunterzuladen. Beliebt bei staatlichen und privaten Kriminellen Das Sicherheitsunternehmen ESET schätzt, dass die ClickFix-Angriffe im letzten Jahr um 517 Prozent zugenommen haben. Die dabei verwendeten Varianten CrashFix, ConsentFix und PhantomCaptcha sollen dabei mit unterschiedlichen Ködern und Zustellungsmechanismen arbeiten. Diese grundlegende Social-Engineering-Taktik hat sich als so effektiv erwiesen, dass sie sogar von staatlichen Gruppen wie der nordkoreanischen Lazarus-Gruppe, der iranischen MuddyWater-Gruppe und der russischen APT28 angewendet wird. Bereits im Januar berichteten Forscher von Sekoia, dass ein weiteres ClickFix-Framework namens IClickFix seit 2024 in über 3.800 WordPress-Websites eingeschleust wurde. Handlungsempfehlungen Betreiber von WordPress-Websites sollten sicherstellen, dass ihre Admin-Login-Bereiche nicht öffentlich zugänglich sind. Laut Rapid7 war dies bei fast allen Websites nicht der Fall. Zudem hat das Sicherheitsunternehmen Indikatoren für Kompromittierungen und YARA-Erkennungsregeln in seinem öffentlichen GitHub-Repository veröffentlicht. (tf) View the full article

Escalating cybersecurity threats and growing privacy concerns lurk around every corner these days. Evolving technology and mounting regulations continue to present both the perils and solutions. All players — public and private, organizations and individuals alike — are to conquer the next quest in this realm. In the most recent Annual Litigation Trends Survey by Norton Rose Fulbright, nearly four in 10 corporate counsel respondents stated that their business’s exposure to cybersecurity and privacy disputes deepened in 2025. The actual increase in exposure also surpassed the already high expectations from the year before. Cybersecurity and privacy even claimed the fastest-rising class action hotspot. Treading such treacherous waters requires constant education and setting appropriate priorities. Here are the key drivers of cybersecurity and privacy legal exposure that deserve the utmost attention: State-sponsored actors emboldened by sophisticated technology Heading into 2026, rising geopolitical tensions across the globe further intensify conflicts in the digital space. The latest developments in the Middle East have only added fuel to the long-standing cyber battlegrounds. The pressure to defend against state-sponsored threat actors had already reached its peak in recent years, especially for the critical infrastructure sector. Given the additional tensions and interconnected nature of today’s digital systems through supply chains and data-sharing relationships, it will be difficult to find a sanctuary anytime soon no matter the industry. The state-sponsored threat actors operate with high sophistication, leveraging the latest technology including AI, to launch attacks and maximize potential impact. Their malicious activities often result in disruption of essential services, data theft and/or illicit revenue generation. The quick adoption of the latest tools embolden the attacker moves whereas defenders pursue a more measured approach in adoption and thus take more time. Furthermore, preparing for and responding to these threats are demanding not only in and of themselves, but also for the additional legal obstacles thereafter as various types of cybersecurity and privacy disputes may ensue and those may expose additional compliance gaps. Continued federal interest in cybersecurity and privacy, especially in connection with national security concerns The evident connection between cybersecurity and privacy and national security have led to a number of federal initiatives in recent years. Most recently in March 2026, the White House announced the current administration’s Cyber Strategy for America, renewing a commitment to strengthening the country’s cybersecurity posture. In 2025, the U.S. Department of Justice Data Security Program went into effect to govern certain categories of data transactions with countries of concern and covered persons as defined. Although there have been delays in the rulemaking following the passage of the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA), [CISA originally planned to hold town hall meetings this spring regarding the CIRCIA proposed rules from 2024.] When it comes to enforcement, the Department of Justice has indicated that its focus on cybersecurity remains strong, especially with respect to the Civil Cyber-Fraud Initiative, which utilizes the False Claims Act to pursue fraud related to cybersecurity by government contractors and grant recipients. Although the U.S. Securities and Exchange Commission has been less active in this space lately, the Federal Trade Commission has shown some signs of interest. In February 2026 alone, it warned data brokers of noncompliance with the Protecting Americans’ Data from Foreign Adversaries Act of 2024 (PADFAA) and held a Workshop on Consumer Injuries and Benefits in the Data-Driven Economy, exploring potential implications of empirical evidence of injuries and benefits to enforcement decisions and judicial review outcomes. Despite the remaining uncertainties around specific guidance and direction, it is fair to conclude that the federal pressure is still on especially for organizations with dealings with the federal government as a service provider or partner receiving sensitive information belonging to the government and/or American individuals. Coordinated efforts from state government agencies As organizations hustle to keep up with the rapidly developing cybersecurity threat landscape and the federal government agencies prioritize a subset of issues, state government agencies are diversifying the options to fill in any regulatory and enforcement gaps. California leads the way with the newly in effect regulations under the California Consumer Privacy Act (CCPA), including the requirement on certain businesses to conduct comprehensive annual cybersecurity audits spanning across 18 components ranging from multi-factor authentication (MFA) to incident response management. The New York Department of Financial Services also bolstered its cybersecurity requirements for financial services companies under 23 NYCRR 500 earlier, with its most recent MFA guidance announced in February 2026. On the privacy front, state regulators are finding ways to collaborate despite the challenges stemming from the ever-expanding web of federal and state laws. In 2025, several state regulators formed a bipartisan “Consortium of Privacy Regulators to share expertise and resources, as well as coordinate efforts to investigate potential violations of applicable laws.” The Consortium members including the California Privacy Protection Agency is investing in resources to implement and enforce the laws and regulations, poised to continue addressing consumer privacy rights ranging from opt-outs to data broker oversight. Looking ahead, state regulators and enforcers are expected to solidify and expand the exchange across state and national borders and seek to address common privacy concerns such as children’s privacy and surrounding dynamic pricing, also referred to as algorithmic or “surveillance pricing”, as part of consumer protection initiatives. As threat actors become more sophisticated, so will the defenses, governing laws and their enforcers. Heightened risk associated with third-party service providers Notably, state regulators recognize the importance of third-party risk management as many incident occur in the third-party service provider or vendor environment. Management of third parties is also a key component of the CCPA regulations. Prior federal regulations and guidance, too, reflect this emphasis. For example, the Securities and Exchange Commission’s Cybersecurity Risk Management, Strategy, Governance and Incident Disclosure requirements include a managing risks posed by third-party service providers. The Federal Communications Commission named third-party risk evaluation as one of the eight core best practices for preventing and mitigating ransomware attacks in its January 2026 Public Notice. In the age of endless supply chain attacks, a strong cybersecurity program involves an established process for identifying and managing risks from third-party service providers. Demonstrating an effective third-party risk management in this context is not limited to preparing the paperwork alone. It also means understanding and monitoring the actual practices of the third-party service providers at hand and continuing to seek further improvements. Growing seeds of conflict — whistleblowers and creative litigants The days of only widely publicized data breaches leading to relatively simple class action lawsuits are far behind us. There has been a proliferation of cybersecurity and privacy claims due to the increasing number of laws and regulations alongside creative arguments manifested in government enforcement initiatives, strike forces and lawsuits making use of broad interpretation of old laws. The False Claims Act, originally of the Civil War era, illustrates this point. Federal government (and state governments with their corresponding laws), may rely on private whistleblowers who make qui tam filings on behalf of the government under this law. In fact, the Department of Justice is looking to rely on whistleblowers as key sources for detecting potential noncompliance related to cybersecurity. State regulators are evaluating how this approach may be replicated not only under the state False Claims Act, but in other state laws. Many state regulators rely heavily on consumer complaints in forming the agenda. As the world becomes more cybersecurity and privacy-conscious, inaccurate statements around cybersecurity and privacy are projected to have greater impact. It is no longer a surprise to see organizations simultaneously face cybersecurity attacks, immediately filed class action lawsuits and investigations based on whistleblower allegations. Without strategic development and refinement of processes to identify, escalate and investigate cybersecurity and privacy concerns as appropriateffganizations may easily get swept into a whirlwind of legal troubles. These trends call for organizations to take a moment and assess where they stand in their cybersecurity and privacy journey. Consider going back to the basics and asking some fundamental questions: What information does the organization handle? How is the information used? With whom is it shared? What measures are in place to safeguard that information? What cybersecurity and privacy obligations does the organization carry? Who is responsible for identifying and performing these obligations? How does the organization raise awareness and train appropriate personnel? What statements does the organization make regarding its cybersecurity and privacy practices? How are cybersecurity and privacy concerns raised and investigated? How does the organization identify and implement areas for improvement? Who oversees cybersecurity and risk management? How? If an answer to any of these questions is unclear, it is time to roll up the sleeves and prioritize the to-do list. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Escalating cybersecurity threats and growing privacy concerns lurk around every corner these days. Evolving technology and mounting regulations continue to present both the perils and solutions. All players — public and private, organizations and individuals alike — are to conquer the next quest in this realm. In the most recent Annual Litigation Trends Survey by Norton Rose Fulbright, nearly four in 10 corporate counsel respondents stated that their business’s exposure to cybersecurity and privacy disputes deepened in 2025. The actual increase in exposure also surpassed the already high expectations from the year before. Cybersecurity and privacy even claimed the fastest-rising class action hotspot. Treading such treacherous waters requires constant education and setting appropriate priorities. Here are the key drivers of cybersecurity and privacy legal exposure that deserve the utmost attention: State-sponsored actors emboldened by sophisticated technology Heading into 2026, rising geopolitical tensions across the globe further intensify conflicts in the digital space. The latest developments in the Middle East have only added fuel to the long-standing cyber battlegrounds. The pressure to defend against state-sponsored threat actors had already reached its peak in recent years, especially for the critical infrastructure sector. Given the additional tensions and interconnected nature of today’s digital systems through supply chains and data-sharing relationships, it will be difficult to find a sanctuary anytime soon no matter the industry. The state-sponsored threat actors operate with high sophistication, leveraging the latest technology including AI, to launch attacks and maximize potential impact. Their malicious activities often result in disruption of essential services, data theft and/or illicit revenue generation. The quick adoption of the latest tools embolden the attacker moves whereas defenders pursue a more measured approach in adoption and thus take more time. Furthermore, preparing for and responding to these threats are demanding not only in and of themselves, but also for the additional legal obstacles thereafter as various types of cybersecurity and privacy disputes may ensue and those may expose additional compliance gaps. Continued federal interest in cybersecurity and privacy, especially in connection with national security concerns The evident connection between cybersecurity and privacy and national security have led to a number of federal initiatives in recent years. Most recently in March 2026, the White House announced the current administration’s Cyber Strategy for America, renewing a commitment to strengthening the country’s cybersecurity posture. In 2025, the U.S. Department of Justice Data Security Program went into effect to govern certain categories of data transactions with countries of concern and covered persons as defined. Although there have been delays in the rulemaking following the passage of the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA), [CISA originally planned to hold town hall meetings this spring regarding the CIRCIA proposed rules from 2024.] When it comes to enforcement, the Department of Justice has indicated that its focus on cybersecurity remains strong, especially with respect to the Civil Cyber-Fraud Initiative, which utilizes the False Claims Act to pursue fraud related to cybersecurity by government contractors and grant recipients. Although the U.S. Securities and Exchange Commission has been less active in this space lately, the Federal Trade Commission has shown some signs of interest. In February 2026 alone, it warned data brokers of noncompliance with the Protecting Americans’ Data from Foreign Adversaries Act of 2024 (PADFAA) and held a Workshop on Consumer Injuries and Benefits in the Data-Driven Economy, exploring potential implications of empirical evidence of injuries and benefits to enforcement decisions and judicial review outcomes. Despite the remaining uncertainties around specific guidance and direction, it is fair to conclude that the federal pressure is still on especially for organizations with dealings with the federal government as a service provider or partner receiving sensitive information belonging to the government and/or American individuals. Coordinated efforts from state government agencies As organizations hustle to keep up with the rapidly developing cybersecurity threat landscape and the federal government agencies prioritize a subset of issues, state government agencies are diversifying the options to fill in any regulatory and enforcement gaps. California leads the way with the newly in effect regulations under the California Consumer Privacy Act (CCPA), including the requirement on certain businesses to conduct comprehensive annual cybersecurity audits spanning across 18 components ranging from multi-factor authentication (MFA) to incident response management. The New York Department of Financial Services also bolstered its cybersecurity requirements for financial services companies under 23 NYCRR 500 earlier, with its most recent MFA guidance announced in February 2026. On the privacy front, state regulators are finding ways to collaborate despite the challenges stemming from the ever-expanding web of federal and state laws. In 2025, several state regulators formed a bipartisan “Consortium of Privacy Regulators to share expertise and resources, as well as coordinate efforts to investigate potential violations of applicable laws.” The Consortium members including the California Privacy Protection Agency is investing in resources to implement and enforce the laws and regulations, poised to continue addressing consumer privacy rights ranging from opt-outs to data broker oversight. Looking ahead, state regulators and enforcers are expected to solidify and expand the exchange across state and national borders and seek to address common privacy concerns such as children’s privacy and surrounding dynamic pricing, also referred to as algorithmic or “surveillance pricing”, as part of consumer protection initiatives. As threat actors become more sophisticated, so will the defenses, governing laws and their enforcers. Heightened risk associated with third-party service providers Notably, state regulators recognize the importance of third-party risk management as many incident occur in the third-party service provider or vendor environment. Management of third parties is also a key component of the CCPA regulations. Prior federal regulations and guidance, too, reflect this emphasis. For example, the Securities and Exchange Commission’s Cybersecurity Risk Management, Strategy, Governance and Incident Disclosure requirements include a managing risks posed by third-party service providers. The Federal Communications Commission named third-party risk evaluation as one of the eight core best practices for preventing and mitigating ransomware attacks in its January 2026 Public Notice. In the age of endless supply chain attacks, a strong cybersecurity program involves an established process for identifying and managing risks from third-party service providers. Demonstrating an effective third-party risk management in this context is not limited to preparing the paperwork alone. It also means understanding and monitoring the actual practices of the third-party service providers at hand and continuing to seek further improvements. Growing seeds of conflict — whistleblowers and creative litigants The days of only widely publicized data breaches leading to relatively simple class action lawsuits are far behind us. There has been a proliferation of cybersecurity and privacy claims due to the increasing number of laws and regulations alongside creative arguments manifested in government enforcement initiatives, strike forces and lawsuits making use of broad interpretation of old laws. The False Claims Act, originally of the Civil War era, illustrates this point. Federal government (and state governments with their corresponding laws), may rely on private whistleblowers who make qui tam filings on behalf of the government under this law. In fact, the Department of Justice is looking to rely on whistleblowers as key sources for detecting potential noncompliance related to cybersecurity. State regulators are evaluating how this approach may be replicated not only under the state False Claims Act, but in other state laws. Many state regulators rely heavily on consumer complaints in forming the agenda. As the world becomes more cybersecurity and privacy-conscious, inaccurate statements around cybersecurity and privacy are projected to have greater impact. It is no longer a surprise to see organizations simultaneously face cybersecurity attacks, immediately filed class action lawsuits and investigations based on whistleblower allegations. Without strategic development and refinement of processes to identify, escalate and investigate cybersecurity and privacy concerns as appropriate, organizations may easily get swept into a whirlwind of legal troubles. These trends call for organizations to take a moment and assess where they stand in their cybersecurity and privacy journey. Consider going back to the basics and asking some fundamental questions: What information does the organization handle? How is the information used? With whom is it shared? What measures are in place to safeguard that information? What cybersecurity and privacy obligations does the organization carry? Who is responsible for identifying and performing these obligations? How does the organization raise awareness and train appropriate personnel? What statements does the organization make regarding its cybersecurity and privacy practices? How are cybersecurity and privacy concerns raised and investigated? How does the organization identify and implement areas for improvement? Who oversees cybersecurity and risk management? How? If an answer to any of these questions is unclear, it is time to roll up the sleeves and prioritize the to-do list. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Scott Kopcha witnessed what CISOs everywhere are seeing: employees eager to use artificial intelligence, whether through public models or custom AI tools, accessing company data at a breathtaking rate and volume. Kopcha already had a mature data protection strategy in place; as a law firm, his organization had a long history of safeguarding sensitive data. Still, Kopcha, CISO at law firm Goodwin Procter, knew his firm’s data protection strategy needed to evolve. “Whenever you start breaking down these different types of AI models, you see there are seven or eight different ways they can interact with your data, and our tools weren’t necessarily set up to provide the breadth of monitoring and protective capabilities required,” he says. He added another protection layer that classified and tagged data based on whether it could be used with AI and in what circumstances. He invested in new tools to support that layer, and he’s monitoring the vendor landscape for emerging capabilities that could further boost his data protection program. Kopcha’s data protection strategy also calls for an evaluation of new technologies being deployed by the firm to determine whether new controls are needed for them, a move he says ensures protection keeps pace with technological innovations. “The idea is to be able to show anyone who comes to ask that you’ve done your due diligence, and you’ve done your due care,” he says. Kopcha is not alone in that quest. Many CISOs are working to mature their data protection strategies, driven primarily by the explosion of AI use. That has them rethinking policies, procedures, and their tools as well as how they make decisions and how often they need to revise their data protection plans. “Data has always been the lifeblood of the enterprise. What’s changed is the convergence of pressures making data protection exponentially harder,” says Chris Cochran, field CISO and vice president of AI security at the SANS Institute. “AI has made the traditional perimeter largely irrelevant. Employees are using unsanctioned AI tools for work at a pretty alarming rate, pasting source code and customer data into consumer-grade models. One of the problems is that it doesn’t look or feel like exfiltration. Layer on expanding data sovereignty requirements, regulators now issuing guidance specifically on AI data security, and the looming reality of what encryption looks like post-quantum, and you understand why this has become a board-level conversation.” Factors driving strategy evaluations CISOs, security experts, and data practitioners cite the expanding use of AI in the enterprise as the main reason they’re rethinking their data protection strategies. “AI is exposing more sensitive information as [workers] are taking that information and typing it into LLMs,” says Errol Weiss, CSO at Health-ISAC. AI tools make it easy for employees to easily expose sensitive data, Weiss says. They can quickly input protected information into a public AI model to tackle everyday tasks, thinking they’re working efficiently without realizing the data privacy risks they’re taking. “We now have hundreds of thousands of people using the technology that way today,” he adds. But other factors are prompting CISOs to reassess their data protection policies and practices, too. They include the ever-increasing speed and volume of data generation, expanding attack surfaces, increasing regulatory pressure, a growing focus on operational resilience, and AI-enabled cyberattacks. Research shows that the vast majority of organizations are taking action. According to the Cisco 2026 Data and Privacy Benchmark Study, 90% of organizations have expanded their privacy programs because of AI, 43% have increased privacy spending over the past year, and 93% plan to allocate more resources in the next two years to privacy and data governance due to the growing complexity of AI systems and expectations of customers, clients, and regulators. Dan Mellen, global and US cyber CTO at professional services firm EY, says improvements are needed in most organizations. For example, many organizations do a poor job at data classification and data tagging, two vital steps for ensuring adequate security controls are applied to sensitive data, he says. “We’ve seen countless examples where the right guardrails aren’t in place,” he adds. Many IT leaders are also finding that some technologies they implement for data protection are not capable of addressing their needs as AI advances, particularly for agentic AI deployments, Mellen says. For instance, not all data loss prevention (DLP) tools monitor lateral data movement between servers or workloads and instead only deliver perimeter defense, he says. Mike Baker, vice president and global CISO at DXC Technology, uses the term “data sprawl” to describe the growing amount of data on the move, something that accelerated first with cloud computing and now with AI. Like other CISOs, Baker is re-examining his data protection program to ensure he and his team “really understand where our data is, understand the sensitivity of the data across our estate, how it’s being accessed, and what environment the data is in.” To that end, he’s deploying best-of-breed tools to identify, discover, and classify data as well as to manage access to it and continually monitor data flow. He has also implemented a zero-trust security framework. Furthermore, Baker is now holding more ad hoc meetings, in addition to quarterly sessions with business leaders, to ensure the data protection strategy remains aligned with the business strategy and that it can keep up with changes in the company’s technology and business environments. Not all organizations are taking such actions, however. For example, 20% of execs said their organizations don’t monitor their privacy programs, according to the 2026 State of Privacy Report from ISACA, a nonprofit association for governance, risk, security, and assurance professionals. Report authors called that “concerning, as these respondents do not have a way to evaluate their privacy program’s progress or identify areas for improvement.” Key areas of action Organizations with immature data protection strategies need to quickly catch up, experts say. Regardless of where they are on the maturity scale, everyone can do better, they add. “They have a lot of work to do,” says Pam Nigro, vice president of security at Medecision and an ISACA board member. Nigro says companies in heavily regulated industries such as healthcare, as her company is, tend to have mature data protection programs. They’re also more likely to regularly review their strategies and aim for continuous improvement she adds. Nigro reviews her data protection strategy nearly monthly to ensure its practices and policies keep up with the company’s evolving technology and business plans. As called for in her data protection strategy, Nigro’s team reviews how new technologies will use company data to determine whether new controls are needed; monitors traffic flow; and evaluates emerging data protection and security technologies for potential use. In addition, security leaders offer other actions CISOs can take to mature their data protection strategies and programs. Mike Aiello, a former CISO at Goldman Sachs and now a partner with AllegisCyber Capital, suggests working collaboratively with other executives to understand the likelihood and impact of data breaches, “so you know what money to spend on what controls and what data to prioritize protecting as opposed to focusing on ambiguous risks.” Make identity and access management a central part of your data protection strategy, Aiello advises. The ability to recognize and control who (whether human or machine) is authorized to access what data is essential for preventing breaches and complying with regulations. Aiello also advises security leaders to have a strategy that addresses data provenance, as it ensures security teams can enforce integrity, trust, and compliance throughout the dataset’s full lifecycle. And have a strategy for regularly evaluating emerging tools, especially those that use AI, to ensure the organization’s data protection program can benefit from evolutions within the vendor space. Jeremy Koppen, CISO at Equifax, says the “spotlight’s getting brighter” on data privacy, noting that the company had created its Security and Privacy Controls Framework years ago to manage both. (Equifax made the framework available to the public in 2023.) The company’s strategy has called for continuing evolution, which has included moving to a passwordless environment; continually tuning and refining tools to align them to the company’s internal rules and control framework; focusing on automation and prioritization; and co-innovating with vendors on product and service enhancements. “Staying ahead,” Koppen says, “requires a relentless focus on evolving our guardrails to protect every new way our data is being used and accessed.” View the full article

Vorsicht, dieses Film-Listicle kann zu Prokrastination verführen! Nomad Soul | shutterstock.com Security-Profis und -Entscheider mit Hang zur Filmkunst müssen auch nach Feierabend nicht auf ihr Leib-und-Magen-Thema verzichten – einer Fülle cineastischer Ergüsse sei Dank. Das Film-Pflichtprogramm für Security-Profis Wir haben die unserer Meinung nach besten (Achtung: Nerd-Brille erforderlich) Hacker-Filme nachfolgend für Sie zusammengestellt – in chronologischer Reihenfolge und inklusive Trailer der jeweiligen Originalfassung. Vielleicht entdecken Sie ja die ein oder andere Perle in unserer Zusammenstellung, die Sie noch nicht kennen – oder einfach viel zu lange nicht mehr gesehen haben. War Games (1983) Plot: Ein jugendlicher Hacker (Matthew Broderick) entdeckt durch Zufall eine Backdoor in einem Militärcomputer. Als er dort ein vermeintliches Spiel startet, droht eine nukleare Katastrophe. Genre: Action/Drama/Sci-Fi Bewertungen: IMDb 7,1/10 Rotten Tomatoes 94 % Metacritic 77/100 Sneakers (1992) Plot: Ein (physischer) Penetration Tester (Robert Redford) und sein Team (unter anderem Sidney Poitier, Ben Kingsley und Dan Aykroyd) erhalten von der NSA einen Spezialauftrag und geraten zwischen die Fronten. Genre: Comedy/Krimi/Drama Bewertungen: IMDb 7,1/10 Rotten Tomatoes 80 % Metacritic 65/100 Hackers (1995) Plot: Zwei berüchtigte Hacker (Angelina Jolie und Johnny Lee Miller) legen sich mit der Regierung an, entdecken dann jedoch die wahre Gefahr: bösartigere Hacker. Genre: Krimi/Drama/Romantik Bewertungen: IMDb 6,2/10 Rotten Tomatoes 33 % Metacritic 46/100 The Net (1995) Plot: Nachdem einer Softwareentwicklerin (Sandra Bullock) eine ominöse Diskette zugespielt wird, ist nichts wie es vorher war: Ihre Identität wird gestohlen, Menschen in ihrem Umfeld sterben unter mysteriösen Umständen. Genre: Action/Thriller/Krimi Bewertungen: IMDb 6,0/10 Rotten Tomatoes 43 % Metacritic 51/100 23 (1998) Plot: Der 19-jährige Hacker Karl Koch (August Diehl) ist davon überzeugt, im vom Kalten Krieg geprägten Deutschland der 1980er Jahre einer weltweiten Verschwörung auf der Spur zu sein. Als er vom russischen Geheimdienst rekrutiert wird, gerät sein Leben aus den Fugen. Genre: Biografie/Thriller/Drama Bewertungen: IMDb 7,2/10 Rotten Tomatoes — Metacritic — The Matrix (1999) Plot: Der junge Hacker Neo (Keanu Reeves) erhält über seinen Computer mysteriöse Botschaften. Wenig später kämpft er mit den verbündeten Hackern Trinity (Carrie-Anne Moss) und Morpheus (Larence Fishburne) um das Überleben der Menschheit. Genre: Action/Sci-Fi Bewertungen: IMDb 8,7/10 Rotten Tomatoes 83 % Metacritic 73/100 Takedown (2000) Plot: Der Hacker Kevin Mitnick (Skeet Ulrich) verschätzt sich bei einem Angriffsversuch und gerät ins Visier des FBI. Genre: Biografie/Drama Bewertungen: IMDb 6,2/10 Rotten Tomatoes — Metacritic — Pulse (2001) Plot: Eine Gruppe junger Leute entdeckt Hinweise darauf, dass Geistwesen versuchen, über das Internet in die reale Welt zu gelangen. Im Jahr 2006 entstand ein gleichnamiges US-amerikanisches Remake des japanischen Originals. Genre: Horror/Sci-Fi Bewertungen: IMDb 6,5/10 Rotten Tomatoes 76% Metacritic 68/100 Swordfish (2001) Plot: Ein Hacker (Hugh Jackman) wird von einem Gangster (John Travolta) engagiert, um einen Computerwurm für einen Bankraub zu erschaffen. Bald merkt er jedoch, dass die Dinge anders sind, als sie scheinen. Genre: Action/Thriller Bewertungen: IMDb 6,5/10 Rotten Tomatoes 26% Metacritic 32/100 Firewall (2006) Plot: Ein IT-Chef (Harrison Ford) gerät ins Visier von Erpressern, die seine Familie bedrohen. Ein Kampf auf Leben und Tod entbrennt – der mit viel technologischem Knowhow geführt wird. Genre: Action/Thriller Bewertungen: IMDb 5,8/10 Rotten Tomatoes 19% Metacritic 45/100 Live Free or Die Hard (2007) Plot: Cybercrime-Terroristen bringen die Ostküste der USA unter ihre Kontrolle. Zeit für Cop-Ikone John McClane (Bruce Willis) wieder einmal den Tag zu retten. Dazu braucht er die Unterstützung eines technisch talentierten aber ansonsten eher tollpatschigen Hackers (Justin Long). Genre: Action/Thriller Bewertungen: IMDb 7,1/10 Rotten Tomatoes 82% Metacritic 69/100 Untraceable (2008) Plot: Eine FBI-Agentin (Diane Lane) stößt durch Zufall auf eine verstörende Webseite. Die Jagd auf den Webmaster wird zu einer mörderischen Jagd. Genre: Krimi/Thriller Bewertungen: IMDb 6,2/10 Rotten Tomatoes 16% Metacritic 32/100 The Girl with the Dragon Tattoo (2009) Plot: In Deutschland besser bekannt unter dem Titel “Verblendung”, erzählt der erste Teil von Stig Larssons Millenium-Trilogie die Geschichte der jungen Hackerin Lisbeth Salander (Noomi Rapace), die einen Kriminalkommissar (Mikael Nyqvist) bei der Aufklärung einer Mordserie unterstützt. Im Jahr 2011 entstand ein Remake des schwedischen Originals mit Beteiligung von James-Bond-Darsteller Daniel Craig. Genre: Krimi/Drama Bewertungen: IMDb 7,8/10 Rotten Tomatoes 85% Metacritic 76/100 Skyfall (2012) Plot: Geheimagent James Bond (Daniel Craig) nimmt es mit einem Cyberterroristen (Javier Bardem) auf. Dabei wird seine Loyalität zu M (Judi Dench) auf eine harte Probe gestellt. Genre: Action/Thriller Bewertungen: IMDb 7,8/10 Rotten Tomatoes 92% Metacritic 81/100 The Fifth Estate (2013) Plot: Daniel Domscheit-Berg (Daniel Brühl) und Julian Assange (Benedict Cumberbatch) tun sich zusammen, um die Whistleblower-Onlineplattform WikiLeaks aus der Taufe zu heben. Das bleibt nicht ohne Folgen. Genre: Biografie/Drama Bewertungen: IMDb 6,2/10 Rotten Tomatoes 35% Metacritic 49/100 Blackhat (2015) Plot: Als ein Hacker (Chris Hemsworth) von einem Freund um Unterstützung bei der Untersuchung einer Malware gebeten wird, kommen sie einem weltumspannenden Cybercrime-Netzwerk auf die Spur. Genre: Action/Thriller Bewertungen: IMDb 5,5/10 Rotten Tomatoes 33% Metacritic 52/100 Snowden (2016) Plot: Der ehemalige CIA- und NSA-Mitarbeiter Edward Snowden (Joseph Gordon-Levitt) entschließt sich, über die Cyber-Methoden und -Praktiken der Geheimdienste auszupacken. Das macht ihn in den USA zum Staatsfeind Nummer Eins. Genre: Biografie/Drama Bewertungen: IMDb 7,3/10 Rotten Tomatoes 61% Metacritic 58/100 Ocean’s Eight (2018) Plot: Eine erfahrene Kriminelle (Sandra Bullock) plant ihren nächsten großen Coup. Dabei erhält sie unter anderem Unterstützung durch eine Hackerin (Rihanna). Genre: Action/Comedy Bewertungen: IMDb 6,3/10 Rotten Tomatoes 69% Metacritic 61/100 Silk Road (2021) Plot: Uni-Absolvent Ross Ulbricht (Nick Robinson) baut einen illegalen Marktplatz im Darknet auf, der es zu ungeahnter Popularität bringt. Das ruft jedoch auch die Behörden auf den Plan. Genre: Biografie/Drama/Thriller Bewertungen: IMDb 6,0/10 Rotten Tomatoes 51% Metacritic 41/100 Kimi (2022) Plot: Tech-Spezialistin Angela Childs (Zoë Kravitz) entdeckt Aufnahmen, die auf ein Verbrechen hindeuten. Als sie versucht die Behörden einzuschalten, muss sie selbst um ihr Leben fürchten. Genre: Drama/Thriller Bewertungen: IMDb 6,3/10 Rotten Tomatoes 92% Metacritic 79/100 The Creator (2023) Plot: In einer postapokalyptischen Welt tobt ein vernichtender Krieg zwischen Menschheit und künstlicher Intelligenz. Joshua (John David Washington) will den “Creator”, der die feindliche KI erschaffen hat, zur Strecke bringen. Genre: Science Fiction/Thriller Bewertungen: IMDb 6,7/10 Rotten Tomatoes 68% Metacritic 63/100 Unlocked (2023) Plot: Ein Stalker mit ausgeprägten Cybercrime-Fähigkeiten (Yim Si-wan) findet das Smartphone der Büroangestellten Na-mi (Chun Woo-hee), was deren gesamtes Leben auf den Kopf stellt. Genre: Thriller Bewertungen: IMDb 6,4/10 Rotten Tomatoes 50% Metacritic — View the full article

Vorsicht, dieses Film-Listicle kann zu Prokrastination verführen! Nomad Soul | shutterstock.com Security-Profis und -Entscheider mit Hang zur Filmkunst müssen auch nach Feierabend nicht auf ihr Leib-und-Magen-Thema verzichten – einer Fülle cineastischer Ergüsse sei Dank. Das Film-Pflichtprogramm für Security-Profis Wir haben die unserer Meinung nach besten (Achtung: Nerd-Brille erforderlich) Hacker-Filme nachfolgend für Sie zusammengestellt – in chronologischer Reihenfolge und inklusive Trailer der jeweiligen Originalfassung. Vielleicht entdecken Sie ja die ein oder andere Perle in unserer Zusammenstellung, die Sie noch nicht kennen – oder einfach viel zu lange nicht mehr gesehen haben. War Games (1983) Plot: Ein jugendlicher Hacker (Matthew Broderick) entdeckt durch Zufall eine Backdoor in einem Militärcomputer. Als er dort ein vermeintliches Spiel startet, droht eine nukleare Katastrophe. Genre: Action/Drama/Sci-Fi Bewertungen: IMDb 7,1/10 Rotten Tomatoes 94 % Metacritic 77/100 Sneakers (1992) Plot: Ein (physischer) Penetration Tester (Robert Redford) und sein Team (unter anderem Sidney Poitier, Ben Kingsley und Dan Aykroyd) erhalten von der NSA einen Spezialauftrag und geraten zwischen die Fronten. Genre: Comedy/Krimi/Drama Bewertungen: IMDb 7,1/10 Rotten Tomatoes 80 % Metacritic 65/100 Hackers (1995) Plot: Zwei berüchtigte Hacker (Angelina Jolie und Johnny Lee Miller) legen sich mit der Regierung an, entdecken dann jedoch die wahre Gefahr: bösartigere Hacker. Genre: Krimi/Drama/Romantik Bewertungen: IMDb 6,2/10 Rotten Tomatoes 33 % Metacritic 46/100 The Net (1995) Plot: Nachdem einer Softwareentwicklerin (Sandra Bullock) eine ominöse Diskette zugespielt wird, ist nichts wie es vorher war: Ihre Identität wird gestohlen, Menschen in ihrem Umfeld sterben unter mysteriösen Umständen. Genre: Action/Thriller/Krimi Bewertungen: IMDb 6,0/10 Rotten Tomatoes 43 % Metacritic 51/100 23 (1998) Plot: Der 19-jährige Hacker Karl Koch (August Diehl) ist davon überzeugt, im vom Kalten Krieg geprägten Deutschland der 1980er Jahre einer weltweiten Verschwörung auf der Spur zu sein. Als er vom russischen Geheimdienst rekrutiert wird, gerät sein Leben aus den Fugen. Genre: Biografie/Thriller/Drama Bewertungen: IMDb 7,2/10 Rotten Tomatoes — Metacritic — The Matrix (1999) Plot: Der junge Hacker Neo (Keanu Reeves) erhält über seinen Computer mysteriöse Botschaften. Wenig später kämpft er mit den verbündeten Hackern Trinity (Carrie-Anne Moss) und Morpheus (Larence Fishburne) um das Überleben der Menschheit. Genre: Action/Sci-Fi Bewertungen: IMDb 8,7/10 Rotten Tomatoes 83 % Metacritic 73/100 Takedown (2000) Plot: Der Hacker Kevin Mitnick (Skeet Ulrich) verschätzt sich bei einem Angriffsversuch und gerät ins Visier des FBI. Genre: Biografie/Drama Bewertungen: IMDb 6,2/10 Rotten Tomatoes — Metacritic — Pulse (2001) Plot: Eine Gruppe junger Leute entdeckt Hinweise darauf, dass Geistwesen versuchen, über das Internet in die reale Welt zu gelangen. Im Jahr 2006 entstand ein gleichnamiges US-amerikanisches Remake des japanischen Originals. Genre: Horror/Sci-Fi Bewertungen: IMDb 6,5/10 Rotten Tomatoes 76% Metacritic 68/100 Swordfish (2001) Plot: Ein Hacker (Hugh Jackman) wird von einem Gangster (John Travolta) engagiert, um einen Computerwurm für einen Bankraub zu erschaffen. Bald merkt er jedoch, dass die Dinge anders sind, als sie scheinen. Genre: Action/Thriller Bewertungen: IMDb 6,5/10 Rotten Tomatoes 26% Metacritic 32/100 Firewall (2006) Plot: Ein IT-Chef (Harrison Ford) gerät ins Visier von Erpressern, die seine Familie bedrohen. Ein Kampf auf Leben und Tod entbrennt – der mit viel technologischem Knowhow geführt wird. Genre: Action/Thriller Bewertungen: IMDb 5,8/10 Rotten Tomatoes 19% Metacritic 45/100 Live Free or Die Hard (2007) Plot: Cybercrime-Terroristen bringen die Ostküste der USA unter ihre Kontrolle. Zeit für Cop-Ikone John McClane (Bruce Willis) wieder einmal den Tag zu retten. Dazu braucht er die Unterstützung eines technisch talentierten aber ansonsten eher tollpatschigen Hackers (Justin Long). Genre: Action/Thriller Bewertungen: IMDb 7,1/10 Rotten Tomatoes 82% Metacritic 69/100 Untraceable (2008) Plot: Eine FBI-Agentin (Diane Lane) stößt durch Zufall auf eine verstörende Webseite. Die Jagd auf den Webmaster wird zu einer mörderischen Jagd. Genre: Krimi/Thriller Bewertungen: IMDb 6,2/10 Rotten Tomatoes 16% Metacritic 32/100 The Girl with the Dragon Tattoo (2009) Plot: In Deutschland besser bekannt unter dem Titel “Verblendung”, erzählt der erste Teil von Stig Larssons Millenium-Trilogie die Geschichte der jungen Hackerin Lisbeth Salander (Noomi Rapace), die einen Kriminalkommissar (Mikael Nyqvist) bei der Aufklärung einer Mordserie unterstützt. Im Jahr 2011 entstand ein Remake des schwedischen Originals mit Beteiligung von James-Bond-Darsteller Daniel Craig. Genre: Krimi/Drama Bewertungen: IMDb 7,8/10 Rotten Tomatoes 85% Metacritic 76/100 Skyfall (2012) Plot: Geheimagent James Bond (Daniel Craig) nimmt es mit einem Cyberterroristen (Javier Bardem) auf. Dabei wird seine Loyalität zu M (Judi Dench) auf eine harte Probe gestellt. Genre: Action/Thriller Bewertungen: IMDb 7,8/10 Rotten Tomatoes 92% Metacritic 81/100 The Fifth Estate (2013) Plot: Daniel Domscheit-Berg (Daniel Brühl) und Julian Assange (Benedict Cumberbatch) tun sich zusammen, um die Whistleblower-Onlineplattform WikiLeaks aus der Taufe zu heben. Das bleibt nicht ohne Folgen. Genre: Biografie/Drama Bewertungen: IMDb 6,2/10 Rotten Tomatoes 35% Metacritic 49/100 Blackhat (2015) Plot: Als ein Hacker (Chris Hemsworth) von einem Freund um Unterstützung bei der Untersuchung einer Malware gebeten wird, kommen sie einem weltumspannenden Cybercrime-Netzwerk auf die Spur. Genre: Action/Thriller Bewertungen: IMDb 5,5/10 Rotten Tomatoes 33% Metacritic 52/100 Snowden (2016) Plot: Der ehemalige CIA- und NSA-Mitarbeiter Edward Snowden (Joseph Gordon-Levitt) entschließt sich, über die Cyber-Methoden und -Praktiken der Geheimdienste auszupacken. Das macht ihn in den USA zum Staatsfeind Nummer Eins. Genre: Biografie/Drama Bewertungen: IMDb 7,3/10 Rotten Tomatoes 61% Metacritic 58/100 Ocean’s Eight (2018) Plot: Eine erfahrene Kriminelle (Sandra Bullock) plant ihren nächsten großen Coup. Dabei erhält sie unter anderem Unterstützung durch eine Hackerin (Rihanna). Genre: Action/Comedy Bewertungen: IMDb 6,3/10 Rotten Tomatoes 69% Metacritic 61/100 Silk Road (2021) Plot: Uni-Absolvent Ross Ulbricht (Nick Robinson) baut einen illegalen Marktplatz im Darknet auf, der es zu ungeahnter Popularität bringt. Das ruft jedoch auch die Behörden auf den Plan. Genre: Biografie/Drama/Thriller Bewertungen: IMDb 6,0/10 Rotten Tomatoes 51% Metacritic 41/100 Kimi (2022) Plot: Tech-Spezialistin Angela Childs (Zoë Kravitz) entdeckt Aufnahmen, die auf ein Verbrechen hindeuten. Als sie versucht die Behörden einzuschalten, muss sie selbst um ihr Leben fürchten. Genre: Drama/Thriller Bewertungen: IMDb 6,3/10 Rotten Tomatoes 92% Metacritic 79/100 The Creator (2023) Plot: In einer postapokalyptischen Welt tobt ein vernichtender Krieg zwischen Menschheit und künstlicher Intelligenz. Joshua (John David Washington) will den “Creator”, der die feindliche KI erschaffen hat, zur Strecke bringen. Genre: Science Fiction/Thriller Bewertungen: IMDb 6,7/10 Rotten Tomatoes 68% Metacritic 63/100 Unlocked (2023) Plot: Ein Stalker mit ausgeprägten Cybercrime-Fähigkeiten (Yim Si-wan) findet das Smartphone der Büroangestellten Na-mi (Chun Woo-hee), was deren gesamtes Leben auf den Kopf stellt. Genre: Thriller Bewertungen: IMDb 6,4/10 Rotten Tomatoes 50% Metacritic — View the full article

In the few short weeks since OpenClaw became the biggest story in agentic AI, it has been dogged by concerns that it is not secure enough to be safely let loose in enterprises. This week at the Nvidia GPU Technology Conference (GTC) conference, CEO Jensen Huang announced what he believes is the answer: NemoClaw. Built in consultation with OpenClaw’s creator, Peter Steinberger, NemoClaw is based on Nvidia Agent Toolkit, part of the broader NeMo ecosystem for building AI agents. The security innovation is Nvidia OpenShell, a new security and policy enforcement guardrail that integrates with the OpenClaw command line. The company decided to build NemoClaw after realizing that what Steinberger had created in OpenClaw was an agentic “operating system,” Huang said. “It is no different to how Windows made it possible to create personal computers. Now OpenClaw has made it possible for us to create personal agents,” he added. Huang compared OpenClaw’s significance to that of the arrival of Linux and HTML in the 1990s, noting that it has given the AI industry exactly what it needed to accelerate agentic AI. “Every company in the world today needs to have an OpenClaw strategy,” he said. “This is the new computer. Post-OpenClaw, post-agentic […] every SaaS company will become an agentic-as-a-service company.” Security sandbox Last year, the release of Chinese company DeepSeek’s super-efficient R1 model suggested that big AI might not be the only available future. This year, thanks to the work of a single developer, Steinberger, it’s the turn of agentic AI. Until recently, the assumption was that this year’s autonomous agents would be chatbot front ends connecting most of the time to cloud platforms such as Microsoft AutoGen, Google Vertex AI, or OpenAI’s Assistants API. The rapid ascent of OpenClaw (formerly Clawdbot and Moltbot) in early 2026 has shown that agentic, or ‘edge,’ AI represents an alternative model in which agentic processing happens on local devices such as PCs. OpenClaw’s ascent was so rapid that by mid-February, only weeks after it became widely known, Steinberger was hired by OpenAI, and OpenClaw became an internal open-source project. At the same time, OpenClaw’s security shortcomings were generating plenty of negative headlines, with researchers finding security flaws galore, including ways in which a device running it could be compromised remotely. NemoClaw’s answer is to isolate OpenClaw using the OpenShell runtime. This contains several security layers, including kernel-level sandboxing and a “privacy router” that monitors OpenClaw’s behavior and communication with other systems. For example, if it detects OpenClaw sending sensitive data somewhere it shouldn’t, it steps in to block the action. This is central to mitigating the security issues that might otherwise hold back the deployment of OpenClaw, or third-party “claws”, in enterprises. It’s also the layer researchers will doubtlessly soon be poring over for CVE-level weaknesses. Hardware agnostic For enterprises wary of lock-in, the first question they will ask is what Nvidia gains from NemoClaw. NemoClaw’s OpenShell is fully open source, an attempt to turn it into the gold standard for agentic claw security. The underlying hardware is not vendor specific either; NemoClaw is agnostic and will run on any hardware, not just Nvidia’s. However, it is still optimized for the Nvidia-specific technologies such as Nvidia Inference Microservices (NIM), even if it technically works with other microservices. “Nvidia is doing what Nvidia always does. They are pulling the center of gravity toward their stack,” commented Zahra Timsah, CEO of AI governance platform i-GENTIC AI. “Developers will be attracted to [NemoClaw], not because it is better, but because it is faster on Nvidia hardware and easier if you are already in that ecosystem,” she said. But it still lacks elements essential for developers: “The missing piece is not tooling. It is control. Real developers building agentic systems want observability, policy enforcement, rollback, and audit trails,” said Timsah. “For enterprises, this [announcement] makes OpenClaw more usable from an infrastructure standpoint. It helps run agents closer to data,” she observed. “But it does not solve governance, consistency, or cross system reasoning. So, the real question is not ‘Can agents run at the edge?’ It’s ‘Can you trust what they do when no one is watching?’” This article originally appeared on CIO.com. View the full article

nitpicker – shutterstock.com Der Energiekonzern Eon sieht eine zunehmende Zahl von Cyberangriffen auf seine Energienetze. Mittlerweile seien täglich mehrere hundert Angriffe auf die Netzinfrastuktur zu verzeichnen, berichtete Vorstandsmitglied Thomas König am Montag im Austausch mit Journalisten. Im Vergleich zu von vor fünf Jahren habe sich die Zahl damit verzehnfacht. Der Manager verwies in diesem Zusammenhang auf die Bedeutung eines digitalisierten Stromnetzes, sowie die eigenen Bemühungen, die Sicherheit zu gewährleisten. Dafür arbeite Eon, wie viele andere Unternehmen, etwa auch mit externen Dienstleistern zusammen, um Angriffe zu simulieren und sich dagegen zu wappnen. Eon ist Deutschlands größter Stromversorger und -netzbetreiber. Dem Unternehmen gehört rund ein Drittel dieses Netzes, das alle Spannungsebenen unterhalb des Übertragungsnetzes umfasst. (dpa/rs) View the full article

AWS’ promise of “complete isolation” for agentic AI workflows on Bedrock is facing scrutiny after researchers found its sandbox mode isn’t as sealed as advertised. In a recent disclosure, BeyondTrust detailed how the “Sandbox” mode in AWS Bedrock AgentCore’s Code Interpreter can be abused to break isolation boundaries using DNS queries. While the sandbox blocks most outbound traffic, it still allows DNS queries for A and AAAA records, potentially allowing attackers to establish a covert communication channel, leading to data exfiltration and remote command execution. “AWS Bedrock’s sandbox isolation failed at the most fundamental layer, DNS, and the lesson isn’t that AWS shipped a bug, it’s that perimeter controls are architecturally insufficient against agentic AI execution environments,” said Ram Varadarajan, CEO at Acalvio. “No malware required, just a compliant model with poisoned inputs.” BeyondTrust researchers said in a blog post that AWS acknowledged the report and reproduced the issue during the disclosure process, but ultimately chose not to patch the behavior, calling it an “intended functionality rather than a defect.” The “allowed” DNS path breaks isolation The issue is that the sandbox environment permits outbound DNS queries, which can be manipulated to create a bidirectional communication channel between the AI agent and an external attacker-controlled server. By encoding data into DNS queries and responses, BeyondTrust’s Phantom Labs team demonstrated exfiltrating data and even establishing an interactive reverse shell, without triggering any network restrictions. “The (vulnerable) environment permits outbound DNS queries for A and AAAA records, a structural allowance that threat actors can exploit to establish a bidirectional command-and-control channel,” said Jason Soroko, senior fellow at Sectigo. Once that channel is in place, the rest becomes a question of permissions. If the agent is operating with overly broad IAM roles, the blast radius expands quickly. “By leveraging this channel, attackers can secure an interactive reverse shell and execute arbitrary commands,” Soroko added. “If the AI execution environment is assigned overly permissive IAM roles, attackers can silently exfiltrate sensitive cloud data, such as S3 bucket contents, directly through these allowed DNS queries.” Technically, the sandbox isn’t breached; it’s bypassed using a functionality that was always meant to be there. At least, that’s what AWS says. AWS allegedly rolled back a fix BeyondTrust said it discovered and reported the vulnerability to AWS on September 1, 2025, via the bug bounty platform HackerOne. AWS reportedly acknowledged receipt of the report and deployed an initial fix to production in November. However, BeyondTrust was informed a few days later that the initial fix was rolled back due to “other factors” and that AWS is working on a more robust solution. Finally, in December, AWS told BeyondTrust that a fix would not be made as the behavior is an “intended functionality” and instead updated their documentation to clarify that Sandbox mode permits DNS resolution. The BeyondTrust researcher received a $100 AWS Gear Shop gift card for the finding. An AWS spokesperson told CSO that all AWS services and infrastructure are operating as expected. “The Sandbox mode provides network access exclusively to Amazon S3 for your data operations, making it ideal for production workloads that rely on S3 data,” the spokesperson said. “DNS resolution is enabled to support successful execution of S3 operations.” “Because AWS has determined this behavior is intended functionality and opted to update its documentation rather than issue a patch, security teams must proactively shift their defensive strategies,” Soroko said, recommending teams “inventory all active AgentCore Code Interpreter instances” and “migrate to VPC mode”. Varadarajan points to a more adaptive approach. “The correct architectural response is to instrument the execution environment itself with deception artifacts — canary IAM credentials, honey S3 paths, DNS sinkholes — that an effective agent will inevitably surface precisely because it’s doing its job well,” he said. AWS reportedly awarded the issue a CVSS Score of 7.5. The documentation now reflects the change in the Sandbox mode description, which says the mode “provides limited external network access” as opposed to “provides complete isolation with no external network access” earlier. View the full article

AI agents are already operating inside enterprise networks, quietly doing some of the work employees once handled themselves — writing code, drafting emails, retrieving files, and connecting to internal systems. Sometimes they also make costly mistakes. At Meta, an employee asked an AI assistant to help manage her inbox. It deleted it instead. At Amazon, an internal agent autonomously decided to tear down and rebuild a deployment environment, knocking an AWS service offline for 13 hours. These incidents offer glimpses of a larger shift security leaders are confronting: Autonomous software is now acting inside corporate environments with real permissions and real consequences. “Agents are like teenagers,” Joe Sullivan, former chief security officer of Uber, Cloudflare, and Facebook, and now head of Joe Sullivan Security, tells CSO. “They have all the access and none of the judgment.” For years, most efforts to secure AI have focused on prevention — scanning models, filtering prompts, and analyzing AI-generated code before it reaches production. But as enterprises deploy autonomous agents that interact directly with internal systems, some security leaders say the real risk begins only after those agents are live. “In security, we always assume prevention will fail,” Sullivan says. “That’s why detection and monitoring are equally important.” The speed and autonomy of AI agents mean mistakes or unexpected actions can cascade quickly across systems. That dynamic is why a growing number of security leaders are rallying around, at least conceptually, what Sullivan calls runtime security, or continuously monitoring agents as they operate inside enterprise environments. In simple terms, runtime security focuses on what software does while it is running, rather than only evaluating it before deployment. Why agents change the security model CISOs have spent years governing human behavior inside enterprise networks. They have identity management, role-based access controls, user behavior analytics, and endpoint detection tools. The question is whether those same frameworks — and those same tools for tracking employees — can be extended to AI agents. Security leaders studying the problem say the answer is: only partially. The traditional frameworks still apply conceptually, but the mechanisms required to observe agent behavior are fundamentally different. “The what isn’t new — the how is new,” says Hanah-Marie Darley, co-founder and chief AI officer of Geordie AI. “How do you actually get this data, where you actually get the agent’s behavioral information mostly through logs, and not every AI agent platform will mean that you are getting logs, that you have logs in the first place.” Traditional security tools were built to intercept human behavior at perimeter checkpoints where employees access the internet, log into systems, or move data across boundaries. Agents frequently bypass those checkpoints entirely. They operate through API calls and MCP connections that may never pass through the security tooling that would ordinarily flag anomalous behavior. They also generate dramatically more activity. Where a typical employee might produce 50 to 100 log events in a two-hour period, an agent can generate 10 to 20 times that volume in the same window. And — critically — they often don’t produce any logs. Some agent platforms generate robust audit trails by default. Others don’t. Coding agents can overwrite their own session logs when a previous session is replayed, meaning a security team investigating an incident may find the record of what happened has been erased. “Having the logs in the first place is often a bigger step than people realize because not every agent natively has logs,” Darley tells CSO. The inventory problem Before a CISO can monitor what agents are doing, they face a more elemental challenge: knowing which agents exist. This simple idea is harder than it sounds. In many large enterprises, agents are proliferating faster than any central inventory can capture. Marketing teams deploy AI assistants. HR departments use agents for resume screening. Engineers run coding agents with broad filesystem access. Non-technical employees connect AI productivity tools such as note-takers, email managers, and scheduling assistants to corporate accounts, often without formal IT approval. “CISOs right now are getting the hard question from their board and their CEO,” Sullivan says. “What AI is being run inside the company right now? You’ve got to answer that question. What AI is being run, and what’s it doing?” Darley recommends starting with a structured inventory effort, ideally using tools built specifically for agent discovery, since general-purpose application management systems often can’t see agents living in the cloud, in code repositories, or inside third-party SaaS platforms. “Start with at least one system,” she advises. “It will give you a sense of scale, help you understand who the owners are, and start to educate you on the kind of tooling you actually need.” Without inventory, behavioral monitoring has nothing to which it can anchor. Security teams can watch the logs of the agents they know about. But the agents they have missed are precisely the ones most likely to deliver unwelcome consequences. What runtime monitoring looks like Once an organization knows where its agents are, the question is what to watch for — and how. Elia Zaitsev, CTO of CrowdStrike, tells CSO that existing endpoint detection and response (EDR) tools already capture the kinds of behavior needed to track AI agents. They instrument operating systems like a flight data recorder, recording every application that runs, every file it touches, every network connection it makes, and every command it spawns. CrowdStrike’s EDR, for example, builds a threat graph: a connected map of behaviors and their upstream causes. If a suspicious network connection occurs, the threat graph can trace it back through many degrees of separation to the application or agent that initiated the chain. “EDR technology can associate this end behavior with the fact that it came from an application ultimately being driven by an agentic system,” Zaitsev explains. “A firewall just tells you something on this computer is trying to communicate with an AI model in the cloud. EDR allows you to say: This specific application is talking to this specific model.” For AI agents specifically, this creates a new set of controls. A system that recognizes a known agent application — Claude Code, OpenAI’s Codex, OpenHands — can apply a different policy to that application than it would to the same application running under human control. “There are activities that may be benign if a human is responsible,” Zaitsev says, “but if it’s an AI agent I don’t necessarily trust, I may want to apply different policies on the fly.” Build-time security still has a pivotal role to play Not all enterprises will be solely introducing AI agents off the shelf. Many will be building such systems themselves. Because of this, runtime monitoring does not mean that build-time security — scanning code, evaluating models before deployment, and checking prompts — is yesterday’s problem. Varun Badhwar, CEO of Endor Labs, pushes back on that kind of framing. “I’ll never say runtime isn’t important,” Badhwar tells CSO. “But you want to fix as much as you can early. The average cost of a runtime security finding is $4,000, versus $40 at build time. So, guess what? You want to fix as much as you can before it ever gets there.” A vulnerability caught while a developer is still writing code takes minutes to fix. That same vulnerability, once deployed into a container, run through QA, and pushed to a production environment, requires retracing every step of that journey before it can be addressed — at roughly a hundredfold the cost. Badhwar uses the analogy of a car manufacturing line: Quality controls on the assembly line are always cheaper than recalling 70,000 cars from the street. His framework is simple: Shift left, shield right. Shift as many security controls as possible into the development process — catch problems while agents are being built, not after they’re running. Then shield right with runtime monitoring as your last-mile safety net, because some things will always slip through, and zero-day vulnerabilities by definition can’t be anticipated at build time. What CISOs should do now For CISOs, the shift is less about a single new tool and more about a new way of thinking about AI risk. Instead of focusing solely on how agents are built, security teams increasingly need visibility into how they behave once they begin operating inside enterprise systems. The path forward for CISOs is therefore not a single new product or a rip-and-replace of existing infrastructure. It is a methodical extension of security discipline to a new category of actor inside the enterprise. Zaitsev frames it using the security-in-depth model: You don’t stop securing agents at build time just because runtime monitoring is available. You build both. “EDR and runtime security is that last-level safety net,” he says. “You still want all those other layers.” But the experts say the following starting points could be practical first steps toward implementing runtime security for most CISOs: Build an inventory first. Pick one system — a major SaaS platform, your code repositories, your endpoint fleet — and map the agents operating within it. Identify the owners, the permissions, and the protocols. Without visibility, nothing else is possible. Extend behavioral monitoring to agents. Whether through EDR, dedicated agent security tooling, or a combination, establish what normal looks like. What systems should each agent touch? What data should it process? Who should it communicate with? Deviations from that baseline are your signal. Apply agent-specific policies. Don’t govern agents with the same controls you use for employees. They have different access patterns, different risk profiles, and different failure modes. Agent-aware tools can differentiate policy based on whether an application is AI-driven. Design for incident response before you need it. Know how you’ll stop a misbehaving agent without destroying the evidence of what it did. Behavioral logs need to be captured in separate, write-protected stores — not just in the agent platform’s native logging, which may be overwritten. Plan for AI solutions to AI problems. You won’t hire your way out of the volume challenge. Security teams will need automation to monitor systems that operate at machine speed. See also: Agentic AI: A CISO’s security nightmare in the making? Think agentic AI is hard to secure today? Just wait a few months What CISOs need to know about new tools for securing MCP servers Misconfigured MCP servers expose AI agent systems to compromise How cybersecurity leaders can defend against the spur of AI-driven NHI MCP: Securing the backbone of agentic AI View the full article

AI agents are already operating inside enterprise networks, quietly doing some of the work employees once handled themselves — writing code, drafting emails, retrieving files, and connecting to internal systems. Sometimes they also make costly mistakes. At Meta, an employee asked an AI assistant to help manage her inbox. It deleted it instead. At Amazon, an internal agent autonomously decided to tear down and rebuild a deployment environment, knocking an AWS service offline for 13 hours. These incidents offer glimpses of a larger shift security leaders are confronting: Autonomous software is now acting inside corporate environments with real permissions and real consequences. “Agents are like teenagers,” Joe Sullivan, former chief security officer of Uber, Cloudflare, and Facebook, and now head of Joe Sullivan Security, tells CSO. “They have all the access and none of the judgment.” For years, most efforts to secure AI have focused on prevention — scanning models, filtering prompts, and analyzing AI-generated code before it reaches production. But as enterprises deploy autonomous agents that interact directly with internal systems, some security leaders say the real risk begins only after those agents are live. “In security, we always assume prevention will fail,” Sullivan says. “That’s why detection and monitoring are equally important.” The speed and autonomy of AI agents mean mistakes or unexpected actions can cascade quickly across systems. That dynamic is why a growing number of security leaders are rallying around, at least conceptually, what Sullivan calls runtime security, or continuously monitoring agents as they operate inside enterprise environments. In simple terms, runtime security focuses on what software does while it is running, rather than only evaluating it before deployment. Why agents change the security model CISOs have spent years governing human behavior inside enterprise networks. They have identity management, role-based access controls, user behavior analytics, and endpoint detection tools. The question is whether those same frameworks — and those same tools for tracking employees — can be extended to AI agents. Security leaders studying the problem say the answer is: only partially. The traditional frameworks still apply conceptually, but the mechanisms required to observe agent behavior are fundamentally different. “The what isn’t new — the how is new,” says Hanah-Marie Darley, co-founder and chief AI officer of Geordie AI. “How do you actually get this data, where you actually get the agent’s behavioral information mostly through logs, and not every AI agent platform will mean that you are getting logs, that you have logs in the first place.” Traditional security tools were built to intercept human behavior at perimeter checkpoints where employees access the internet, log into systems, or move data across boundaries. Agents frequently bypass those checkpoints entirely. They operate through API calls and MCP connections that may never pass through the security tooling that would ordinarily flag anomalous behavior. They also generate dramatically more activity. Where a typical employee might produce 50 to 100 log events in a two-hour period, an agent can generate 10 to 20 times that volume in the same window. And — critically — they often don’t produce any logs. Some agent platforms generate robust audit trails by default. Others don’t. Coding agents can overwrite their own session logs when a previous session is replayed, meaning a security team investigating an incident may find the record of what happened has been erased. “Having the logs in the first place is often a bigger step than people realize because not every agent natively has logs,” Darley tells CSO. The inventory problem Before a CISO can monitor what agents are doing, they face a more elemental challenge: knowing which agents exist. This simple idea is harder than it sounds. In many large enterprises, agents are proliferating faster than any central inventory can capture. Marketing teams deploy AI assistants. HR departments use agents for resume screening. Engineers run coding agents with broad filesystem access. Non-technical employees connect AI productivity tools such as note-takers, email managers, and scheduling assistants to corporate accounts, often without formal IT approval. “CISOs right now are getting the hard question from their board and their CEO,” Sullivan says. “What AI is being run inside the company right now? You’ve got to answer that question. What AI is being run, and what’s it doing?” Darley recommends starting with a structured inventory effort, ideally using tools built specifically for agent discovery, since general-purpose application management systems often can’t see agents living in the cloud, in code repositories, or inside third-party SaaS platforms. “Start with at least one system,” she advises. “It will give you a sense of scale, help you understand who the owners are, and start to educate you on the kind of tooling you actually need.” Without inventory, behavioral monitoring has nothing to which it can anchor. Security teams can watch the logs of the agents they know about. But the agents they have missed are precisely the ones most likely to deliver unwelcome consequences. What runtime monitoring looks like Once an organization knows where its agents are, the question is what to watch for — and how. Elia Zaitsev, CTO of CrowdStrike, tells CSO that existing endpoint detection and response (EDR) tools already capture the kinds of behavior needed to track AI agents. They instrument operating systems like a flight data recorder, recording every application that runs, every file it touches, every network connection it makes, and every command it spawns. CrowdStrike’s EDR, for example, builds a threat graph: a connected map of behaviors and their upstream causes. If a suspicious network connection occurs, the threat graph can trace it back through many degrees of separation to the application or agent that initiated the chain. “EDR technology can associate this end behavior with the fact that it came from an application ultimately being driven by an agentic system,” Zaitsev explains. “A firewall just tells you something on this computer is trying to communicate with an AI model in the cloud. EDR allows you to say: This specific application is talking to this specific model.” For AI agents specifically, this creates a new set of controls. A system that recognizes a known agent application — Claude Code, OpenAI’s Codex, OpenHands — can apply a different policy to that application than it would to the same application running under human control. “There are activities that may be benign if a human is responsible,” Zaitsev says, “but if it’s an AI agent I don’t necessarily trust, I may want to apply different policies on the fly.” Build-time security still has a pivotal role to play Not all enterprises will be solely introducing AI agents off the shelf. Many will be building such systems themselves. Because of this, runtime monitoring does not mean that build-time security — scanning code, evaluating models before deployment, and checking prompts — is yesterday’s problem. Varun Badhwar, CEO of Endor Labs, pushes back on that kind of framing. “I’ll never say runtime isn’t important,” Badhwar tells CSO. “But you want to fix as much as you can early. The average cost of a runtime security finding is $4,000, versus $40 at build time. So, guess what? You want to fix as much as you can before it ever gets there.” A vulnerability caught while a developer is still writing code takes minutes to fix. That same vulnerability, once deployed into a container, run through QA, and pushed to a production environment, requires retracing every step of that journey before it can be addressed — at roughly a hundredfold the cost. Badhwar uses the analogy of a car manufacturing line: Quality controls on the assembly line are always cheaper than recalling 70,000 cars from the street. His framework is simple: Shift left, shield right. Shift as many security controls as possible into the development process — catch problems while agents are being built, not after they’re running. Then shield right with runtime monitoring as your last-mile safety net, because some things will always slip through, and zero-day vulnerabilities by definition can’t be anticipated at build time. What CISOs should do now For CISOs, the shift is less about a single new tool and more about a new way of thinking about AI risk. Instead of focusing solely on how agents are built, security teams increasingly need visibility into how they behave once they begin operating inside enterprise systems. The path forward for CISOs is therefore not a single new product or a rip-and-replace of existing infrastructure. It is a methodical extension of security discipline to a new category of actor inside the enterprise. Zaitsev frames it using the security-in-depth model: You don’t stop securing agents at build time just because runtime monitoring is available. You build both. “EDR and runtime security is that last-level safety net,” he says. “You still want all those other layers.” But the experts say the following starting points could be practical first steps toward implementing runtime security for most CISOs: Build an inventory first. Pick one system — a major SaaS platform, your code repositories, your endpoint fleet — and map the agents operating within it. Identify the owners, the permissions, and the protocols. Without visibility, nothing else is possible. Extend behavioral monitoring to agents. Whether through EDR, dedicated agent security tooling, or a combination, establish what normal looks like. What systems should each agent touch? What data should it process? Who should it communicate with? Deviations from that baseline are your signal. Apply agent-specific policies. Don’t govern agents with the same controls you use for employees. They have different access patterns, different risk profiles, and different failure modes. Agent-aware tools can differentiate policy based on whether an application is AI-driven. Design for incident response before you need it. Know how you’ll stop a misbehaving agent without destroying the evidence of what it did. Behavioral logs need to be captured in separate, write-protected stores — not just in the agent platform’s native logging, which may be overwritten. Plan for AI solutions to AI problems. You won’t hire your way out of the volume challenge. Security teams will need automation to monitor systems that operate at machine speed. See also: Agentic AI: A CISO’s security nightmare in the making? Think agentic AI is hard to secure today? Just wait a few months What CISOs need to know about new tools for securing MCP servers Misconfigured MCP servers expose AI agent systems to compromise How cybersecurity leaders can defend against the spur of AI-driven NHI MCP: Securing the backbone of agentic AI View the full article

FOTOGRIN – shutterstock.com Für viele Geschäftsprozesse ist Technologie inzwischen unverzichtbar. Deshalb zählt diese auch zu den wertvollsten Assets eines Unternehmens. Leider stellt sie gleichzeitig jedoch auch eines der größten Risiken dar – was Risk-Assessment-Frameworks auf den Plan ruft. IT-Risiken formal zu bewerten, ermöglicht es Organisationen, besser einzuschätzen, zu welchem Grad ihre Systeme, Devices und Daten schädlichen Einflüssen ausgesetzt sind. Etwa in Form von Cyberbedrohungen, Compliance-Verfehlungen oder Ausfällen. Zudem können IT- und Sicherheitsentscheider deren Folgen mit Hilfe von entsprechenden Rahmenwerken auch besser abzuschätzen. Das Ziel besteht am Ende darin, sämtliche identifizierten Risiken – und ihren Impact – zu minimieren. In diesem Artikel stellen wir Ihnen (in aller Kürze) sechs populäre Risk-Assessment-Frameworks vor, die jeweils auf spezifische Risikobereiche abgestimmt sind. 1. COBIT Das ist es: Hinter COBIT (Control Objectives for Information and Related Technology) steht der internationale IT-Berufsverband ISACA, der sich auf IT Governance fokussiert hat. Dieses sehr umfassende und breit angelegte Framework wurde entwickelt, um dabei zu unterstützen, Enterprise IT: zu verstehen, zu designen, zu implementieren, zu managen und zu steuern. Das kann es: Laut ISACA definiert COBIT die Komponenten und Designfaktoren, ein optimales Governance-System aufzubauen und aufrechtzuerhalten. Die aktuelle Version, COBIT 2019, fußt auf einem Governance-Prinzipien-Sextett: Value für Stakeholder liefern ganzheitlichen Ansatz realisieren Governance-System dynamisch gestalten Management von Governance trennen auf individuelle Unternehmensanforderungen abstimmen Ende-zu-Ende-Governance-System realisieren So funktioniert es: Das COBIT-Framework ist auf Business-Fokus konzipiert und definiert eine Reihe generischer Prozesse, um IT-Komponenten zu managen. Dabei werden außerdem auch Inputs und Outputs, Schlüsselaktivitäten, Zielsetzungen, Performance-Metriken und ein grundlegendes Reifegradmodell festgelegt. Gut zu wissen: Laut ISACA ist COBIT flexibel zu implementieren und ermöglicht Unternehmen, ihre Governance-Strategie anzupassen. 2. FAIR Das ist es: Das Framework FAIR (Factor Analysis of Information Risk) bildet eine Methodik ab, um unternehmensbezogene Risiken zu quantifizieren und zu managen. Dahinter steht das Fair Institute, eine wissenschaftlich ausgerichtete Non-Profit-Organisation, die sich dem Management von betrieblichen und sicherheitstechnischen Risiken verschrieben hat. Laut den Machern ist FAIR das einzige, quantitative Standardmodell auf internationaler Ebene, um diese Art von Risiken zu erfassen. Das kann es: FAIR bietet ein Modell, um die genannten Risiken in finanzieller Hinsicht zu verstehen, zu analysieren und zu quantifizieren. Laut dem Fair Institute unterscheidet es sich dabei insofern von anderen Risk-Assessment-Frameworks, als dass es seinen Fokus nicht auf qualitative Farbdiagramme oder numerisch gewichtete Skalen legt. Stattdessen will FAIR eine Grundlage liefern, um einen robusten Risikomanagement-Ansatz auszubilden. So funktioniert es: FAIR ermittelt in erster Linie Wahrscheinlichkeiten mit Blick auf die Frequenz und das Ausmaß von Data-Loss-Ereignissen. Es handelt sich hierbei nicht um eine Methodik, um individuelle Risikobewertungen durchzuführen. Vielmehr will das Framework Unternehmen in die Lage versetzen, IT-Risiken zu verstehen, zu analysieren und zu messen. Zu den Komponenten des FAIR-Frameworks gehören: eine Taxonomie für IT-Risiken, eine standardisierte Nomenklatur für Risiken, eine Methode um Datenerfassungskriterien zu definieren, Messskalen für Risikofaktoren, eine Engine für Risikoberechnungen, sowie ein Modell, um komplexe Risikoszenarien zu analysieren. Gut zu wissen: Die quantitative Risk-Assessment-Ansatz von FAIR ist branchenübergreifend anwendbar. 3. ISO/IEC 27001 Das ist es: Bei ISO/IEC 27001 handelt es sich um einen internationalen Standard, der mit Leitlinien in Sachen IT-Security-Management unterstützt. Ursprünglich wurde er im Jahr 2005 gemeinschaftlich von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) veröffentlicht – und wird seither sukzessive überarbeitet. Das kann es: ISO/IEC 27001 ist laut den Verantwortlichen ein Guide für Unternehmen jeder Größe und aus sämtlichen Branchen, um ein Information-Security-Management-System (ISMS) aufzusetzen, zu implementieren, zu warten und fortlaufend zu verbessern. So funktioniert es: ISO/IEC 27001 fördert einen ganzheitlichen Cybersicherheitsansatz, der Menschen, Richtlinien und Technologie auf den Prüfstand stellt. Ein auf dieser Grundlage erstelltes ISMS ist laut ISO ein Tool für Risikomanagement, Cyberresilienz und Operational Excellence. Gut zu wissen: ISO/IEC-27001-konform zu sein bedeutet, einem weltweit eingesetzten Standard zu genügen und Datensicherheitsrisiken aktiv zu managen. 4. NIST Risk Management Framework Das ist es: Das Risk Management Framework (RMF) wurde von der US-Behörde NIST (National Institute of Standards and Technology) entwickelt. Dieses Framework stellt einen umfassenden, wiederverwend- und messbaren, siebenstufigen Prozess in den Mittelpunkt, um IT- und Datenschutzrisiken zu managen. Dabei kommt eine ganze Reihe von NIST-eigenen Standards und Guidelines zur Anwendung, um die Implementierung von Risikomanagement-Initiativen zu unterstützen. Das kann es: Laut NIST realisiert das RMF einen Prozess, der die Risikomanagementaktivitäten in den Bereichen Sicherheit, Datenschutz und Supply Chain in den Lebenszyklus der Systementwicklung integriert. Dabei berücksichtigt der Ansatz Effektivität, Effizienz und Einschränkungen durch geltende Gesetze, Direktiven, Anordnungen, Richtlinien, Standards oder Vorschriften. So funktioniert es: Der siebenstufige Prozess des NIST RMF gliedert sich in. wesentliche Aktivitäten, um die Organisation auf den Umgang mit Sicherheits- und Datenschutzrisiken vorzubereiten. Systeme und Daten, die verarbeitet, gespeichert und übertragen werden, auf der Grundlage einer Impact-Analyse kategorisieren. eine Reihe von Kontrollmaßnahmen auswählen, um Systeme auf der Grundlage einer Risikobewertung zu schützen. Kontrollmaßnahmen implementieren – und dokumentieren, wie das vonstattengeht. Kontrollmaßnahmen überprüfen und bewerten, ob diese wie gewünscht funktionieren. Systembetrieb auf Grundlage einer risikobasierten Entscheidung autorisieren. Implementierung und Systemrisiken kontinuierlich überwachen. Gut zu wissen: Das RMF bietet einen verfahrenstechnischen und geordneten Prozess, um Organisation dabei zu unterstützen, Security in ihre allgemeinen Risikomanagement-Prozesse einzubetten. 5. OCTAVE Das ist es: OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation (PDF)) ist ein Framework, um Risiken im Bereich der Cybersicherheit zu identifizieren und zu managen. Es wurde vom CERT-Team der Carnegie Mellon University in den USA entwickelt. Das kann es: Dieses Risk-Assessment-Framework definiert eine umfassende Evaluierungsmethode. Diese ermöglicht Unternehmen nicht nur, missionskritische IT-Assets zu identifizieren, sondern auch die Bedrohungen, die mit diesen in Zusammenhang stehen und die Schwachstellen, die das erst ermöglichen. So funktioniert es: Laut den Verantwortlichen ermöglicht die Zusammenstellung von IT-Assets, -Bedrohungen und –Schwachstellen Unternehmen, zu durchdringen, welche Daten wirklich bedroht sind. Mit diesem Verständnis ausgestattet, können die Anwender eine Schutzstrategie entwickeln und implementieren, um diese nachhaltig zu schützen. Gut zu wissen: Das OCTAVE-Framework ist in zwei Versionen erhältlich. OCTAVE-S bietet eine vereinfachte Methodik, die auf kleinere Unternehmen mit flachen hierarchischen Strukturen ausgerichtet ist. OCTAVE Allegro ist hingegen ein umfassenderes Framework, das sich in erster Linie für große Unternehmen oder solche mit komplexen Strukturen eignet. 6. TARA Das ist es: TARA (Threat Assessment and Remediation Analysis) stellt eine Engineering-Methodik dar, mit deren Hilfe, Sicherheitslücken identifiziert, bewertet und behoben werden können. Dieses Framework wurde von der Non-Profit-Organisation MITRE entwickelt. Das kann es: Das Framework ist Teil des MITRE-Systemportfolios, das darauf ausgerichtet ist, die Cybersicherheitshygiene sowie die Resilienz von IT-Systemen in einem möglichst frühen Stadium (innerhalb des Beschaffungsprozesses) zu adressieren. So funktioniert es: Das TARA-Framework nutzt einen Datenkatalog, um Angriffsvektoren zu identifizieren, die genutzt werden könnten, um Systemschwachstellen auszunutzen sowie potenzielle Gegenmaßnahmen einzuleiten. Gut zu wissen: TARA wurde ursprünglich im Jahr 2010 entwickelt und kam bereits in mehr als 30 Cyber-Risk-Assessments zum Einsatz. Dieses Framework eignet sich in besonderem Maße für Risikostudien, die sich auf Sicherheitsbedrohungen konzentrieren. (fm) View the full article

Keylogger sind Malware der alten Schule. Lesen Sie, wie die Tools zur Tastaturüberwachung funktionieren und warum sie nicht nur etwas für Cyberkriminelle sind. IM_photo | shutterstock.com Auch wenn Keylogger schon etliche Jahre auf dem Buckel haben: Sie sind immer noch beliebt und werden häufig im Rahmen großangelegter Cyberangriffe eingesetzt. Keylogger – Definition Der Begriff Keylogger bezeichnet eine Art von Überwachungssoftware, die die Tastatureingaben eines Benutzers aufzeichnet. Die Schadsoftware sendet die Daten, die beim Keylogging erfasst werden, an einen Dritten. Cyberkriminelle nutzen Keylogger, um an persönliche Daten oder sensible Finanzinformationen zu gelangen, die sie dann verkaufen oder anderweitig gewinnbringend nutzen können. Es gibt jedoch auch legitime Verwendungszwecke für Keylogger in Unternehmen – zum Beispiel beim Troubleshooting, dem Optimieren der Benutzerfreundlichkeit oder um Mitarbeiter legal zu überwachen (je nachdem, welchen Gesetzen sie dabei unterliegen). Darüber hinaus nutzen Strafverfolgungsbehörden und Geheimdienste Keylogging zu Überwachungszwecken. Mehr dazu lesen Sie im Absatz “Einsatzzwecke”. Keylogger – Funktionsweise “Keylogger sind Programme, die Algorithmen nutzen, um die Tastaturanschläge durch Mustererkennung und andere Techniken zu überwachen”, erklärt Tom Bain, Vice President Security Strategy bei Morphisec. Der Umfang der von der Keylogger-Software gesammelten Informationen kann dabei variieren: Einfache Formen erfassen nur die Informationen, die auf einer (einzigen) Website oder in einer Anwendung eingegeben werden. Hochentwickelte Keylogging-Programme zeichnen hingegen alles auf (einschließlich der Daten, die bei Copy-Paste-Aktionen anfallen), unabhängig von der Anwendung. Einige Keylogger-Varianten – insbesondere solche, die auf mobile Geräte abzielen – gehen noch weiter und erfassen auch Anrufe (sowohl Anrufverlauf als auch Audio), Informationen aus Messaging-Anwendungen, GPS-Standorte, Screenshots und sogar Mikrofon- und Kameraaufnahmen. Keylogger können hardware- oder softwarebasiert aufgebaut sein: Hardwarebasierte Keylogger werden einfach zwischen Tastatur und Computer geschaltet. Bei softwarebasierten Keyloggern kann es sich um Applikationen oder Tools handeln, die legal oder illegal installiert werden, in letzterem Fall also das Gerät unwissentlich mit Malware infizieren. Die beim Keylogging erfassten Daten werden von der Software per E-Mail oder durch den Upload von Protokolldaten in vordefinierte Websites, Datenbanken oder FTP-Server an den Angreifer zurückgesendet. Ist der Keylogger Instument in einem großen Cyberangriff, ist es sehr wahrscheinlich, dass die Kriminellen sich per Fernzugriff einloggen können, um die Tastaturanschlagsdaten herunterzuladen. Keylogger – Einsatzzwecke Die ersten Keylogger wurden bereits in den 1970er Jahren vom sowjetischen Geheimdienst eingesetzt (mehr dazu später). Auch diese frühen Keylogger zeichneten auf, was getippt wurde und schickten die Informationen über Funksignale an den KGB zurück. Wie Cyberkriminelle Keylogger einsetzen Heute gehören Keylogger zum gängigen Instrumentarium Cyberkrimineller, um finanzielle Informationen wie Bank- und Kreditkartendaten, persönliche Informationen wie E-Mail-Adressen, Passwörter oder sensible Geschäftsinformationen über Prozesse und geistiges Eigentum zu entwenden. Je nach Art der gesammelten Daten (und den Motiven der Angreifer) werden die Informationen auf Darknet-Marktplätzen feilgeboten oder im Rahmen eines größeren Angriffs wiederverwendet. “Wenn ein Keylogger in der Lage ist, die Tastenanschläge eines Datenbankadministrators in einem großen Unternehmen aufzuzeichnen, eröffnet das dem Angreifer Zugang zu Endpunkten und Servern, die wiederum viele sensible Informationen preisgeben können, die sich zu Geld machen lassen“, erklärt Security-Spezialist Bain. Keylogger am Arbeitsplatz Es gibt auch einen großen Markt für legale Keylogging-Apps, wenngleich diese meist ethisch fragwürdig sind. Sie können etwa genutzt werden, um Familienmitglieder, Partner oder Arbeitnehmer auszuspionieren. Wenn der Benutzer eines Geräts davon weiß, dass Spyware auf seinem Gerät läuft, ist das in vielen Ländern legal. Anwendungen, die Informationen über das Arbeitsverhalten sammeln, sind allerdings nicht nur aus moralischen, sondern auch aus Sicherheitsgründen mit Vorsicht zu genießen. Der Spyware-Anbieter mSpy wurde beispielsweise überführt, in mehreren Fällen unabsichtlich Millionen Datensätze von Opfern einer Ausspähung veröffentlicht zu haben. Überwachungssoftware dieser Art, die manchmal auch als “Corporate Keylogging” bezeichnet wird, kann indes für Testing, Debugging und die Verbesserung der User Experience nützlich sein. “In einer seriösen Umgebung werden Keylogger beispielsweise eingesetzt, um zu überprüfen, ob IT-Sicherheits- und Compliance-Vorschriften eingehalten werden”, weiß Simon Sharp, International Vice President beim Sicherheitsanbieter ObserveIT. “Ein Administrator kann dann sofort feststellen, wer ein bestimmtes Wort oder einen bestimmten Wert eingegeben hat, der mit einem Sicherheitsvorfall in Verbindung steht. So kann er verstehen, wer wann und warum gegen eine Richtlinie verstoßen hat.” Die IT-Abteilung kann die Tastaturanschlagsdaten nutzen, um Benutzerprobleme zu identifizieren und zu beheben. Darüber hinaus können die Keylogging-Daten möglicherweise zusätzliche forensische Informationen nach einem Sicherheitsvorfall bereitstellen. Keylogger können auch dazu genutzt werden, potenzielle Innentäter zu erkennen, die Produktivität der Mitarbeiter zu überwachen oder um sicherzustellen, dass die IT-Ressourcen des Unternehmens nur für berufliche Zwecke genutzt werden. Sämtliche erfassten Keylogging-Daten sollten verschlüsselt werden. Keylogger – Infektionswege Es gibt verschiedene Wege, wie Keylogger auf einem Zielsystem platziert werden können. Hardwarebasierte Keylogger erfordern eine physische Handlung des Angreifers vor Ort. Das ist meist schwierig zu bewerkstelligen – aber nicht unmöglich. Auch drahtlose Tastaturen können übrigens aus der Ferne ausspioniert werden. Software-basierte Keylogger sind weiter verbreitet und eröffnen mehrere Zugangswege: Infizierte Domains sind eine gängige Angriffsmethode – im Oktober 2018 wurden die .com- und .eu-Domains der Online-Bürosoftware Zoho gesperrt, nachdem sie Keylogging-Malware an Nutzer ausgeliefert hatten. Auch Tausende von WordPress-Webseiten wurden bereits über gefälschte Google-Analytics-Skripte mit Keyloggern infiziert. Mit Malware infizierte Apps sind ebenfalls ein Problem. Der Google Play Store hatte in der Vergangenheit bereits des öfteren mit Apps zu kämpfen, die Keylogger enthielten. Wie viele andere Arten von Malware sind auch Keylogger oft in Phishing-E-Mails eingebettet. Eine Version des HawkEye-Keyloggers wurde beispielsweise über eine E-Mail-Kampagne mit infizierten Word-Dokumenten verbreitet. Einige andere Keylogger-Varianten, wie etwa Fauxspersky, können sich über infizierte USB-Laufwerke verbreiten. “Die größte Innovation bei Keyloggern sind integrierte Ausweichtechniken, die es ermöglichen, die Malware an Erkennungsmechanismen wie Antivirus-Software vorbeizuschleusen”, sagt Bain. Viele Keylogger würden inzwischen in Kombination mit Ransomware, Cryptominer Malware oder Botnet-Code geliefert, so der Experte. 6 Wege, um Keylogger zu erkennen und entfernen Die folgenden Ratschläge stellen die nach allgemeiner Auffassung wirksamsten Schritte dar, um die Auswirkungen unerwünschter Keylogger zu minimieren: 1. Ressourcen, Prozesse und Daten überwachen Um einen Keylogger zu finden, kann es hilfreich sein, einen Blick auf die Ressourcenzuweisung, die Hintergrundprozesse und die Daten zu werfen, die vom betreffenden Gerät übertragen werden. Um zu funktionieren, benötigen Keylogger in der Regel Root-Zugriff auf den Zielrechner – ebenfalls ein verräterisches Anzeichen für eine Keylogger-Infektion. 2. Schutz aktualisieren Da Keylogger oft mit anderen Formen von Malware gebündelt werden, kann die Entdeckung von Keylogger-Malware ein Hinweis auf einen umfassenderen Angriff sein. Aktuelle Virenschutz- und Anti-Rootkit-Lösungen entfernen bekannte Keylogger-Malware. Dennoch empfehlen sich weitere Untersuchungen, um festzustellen, ob der Vorfall Teil eines größeren Angriffs war. 3. Anti-Keylogger-Software einsetzen Spezielle Anti-Keylogger-Software verschlüsselt Tastaturanschläge, sucht nach bekannten Keyloggern und entfernt sie. Bei ungewöhnlichem Keylogger-ähnlichem Verhalten schlägt sie Alarm. Hilfreich ist es auch, den Root-Zugriff für nicht autorisierte Anwendungen zu sperren und bekannte Spyware in die IT-Blacklist aufzunehmen. 4. Virtuelle Tastaturen nutzen Virtuelle Onscreen-Keyboards vermindern das Keylogger-Risiko, weil sie Informationen auf andere Weise weitergeben als physische Tastaturen. Das kann sich allerdings auf die Produktivität der Benutzer auswirken. Außerdem wirkt es nicht gegen alle Arten von Keylogger und beseitigt auch nicht die Ursache des Problems. 5. Selbstausführende Dateien deaktivieren Indem selbstausführende Dateien auf extern angeschlossenen Geräten wie etwa USB-Devices deaktiviert werden und Dateien lediglich eingeschränkt auf und von externen Rechnern kopiert werden können, lässt sich das Risiko einer Keylogger-Infektion ebenfalls verringern. 6. Strikte Richtlinien durchsetzen Der beste Weg für Unternehmen, sich vor Keylogger-Malware zu schützen, besteht in vielschichtigen Kennwortrichtlinien und einer Mehr-Faktor-Authentifizierung für alle Unternehmenskonten und -geräte. Auch im Fall von Keylogging reicht durchschnittliche Antivirus-Technologie nicht mehr aus. Keylogger-Historie – berühmte Beispiele Der älteste bekannte Keylogger entstammt dem Prä-Computerzeitalter: Der sowjetische Geheimdienst entwickelte in den 1970er Jahren ein Device, das in elektrischen IBM-Schreibmaschinen versteckt werden konnte und Informationen über Tastenanschläge per Funk übermittelte. Diese frühen Keylogger wurden in US-Botschaften in Moskau und Leningrad eingesetzt. Der erste Computer-Keylogger wurde 1983 vom damaligen Doktoranden Perry Kivolowitz als Proof of Concept entwickelt. Ein besonders bemerkenswertes Beispiel für einen Keylogger “in freier Wildbahn” wurde 2015 “im Bundle” mit einer Modifikation für das Videospiel Grand Theft Auto V verbreitet. Im Jahr 2017 wurde bekannt, dass Hunderte von Laptop-Modellen aus dem Hause Hewlett-Packard mit einem Keylogger ausgeliefert wurden. Das Unternehmen bestand allerdings darauf, dass es sich um ein Tool zur Diagnose der Tastaturleistung handelte, das vor der Auslieferung hätte gelöscht werden müssen. View the full article