CSOonline

As Amazon celebrates the 20th anniversary of its AWS cloud this year, the world’s biggest cloud computing provider now faces two giant cybersecurity threats — AI and quantum. How the company will navigate these emerging issues to ensure the security and resilience of systems used by its millions of corporate customers remains an evolving question. But senior executives at AWS believe key decisions and innovations the company has made throughout its 20-year run position it to handle these threats. Here is a look at three key AWS advances and how they factor into what the company and its customers are dealing with as emerging threats now and in the years ahead. Nitro and ‘zero humans’ infrastructure When Amazon released Virtual Private Cloud, its networking layer for AWS, in 2009, it was all software. “Now VPC is implemented in hardware,” says Eric Brandwine, who first came to AWS more than 18 years ago to work on that project and is now a VP and distinguished engineer for Amazon security. What changed was 2017’s introduction of Nitro, a hardware foundation for networking, security, and the hypervisor that enforces strong isolation between customer instances. Amazon paid more than $350 million for a fabless semiconductor company in 2015 to make the technology shift possible. “Commercial hypervisors are a mature and appropriate technology but not designed for cloud scale for the kind of multi-tenancy we have,” Brandwine tells CSO. Nitro also enables Amazon to operate AWS without employees ever touching customer infrastructure. “With Nitro, there’s no human access to it,” he says. “This is one of the reasons why we’re able to offer bare-metal instances.” If maintenance is required, all customer content is removed from the machine before employees can get into it. “And we’ve had third parties take a look at this process,” he adds, including NCC Group, which conducted an architecture review of Amazon’s security claims in 2023. Today, Nitro provides the trust foundation for protecting the company’s quantum-safe encryption keys, for securing the identities of AI agents, for protecting AWS infrastructure against rogue agents, and for providing the confidential compute foundation for AI workloads themselves. Symmetric cryptography and the quantum threat Back in the early 2010s, most hardware security modules used asymmetric cryptography to protect security keys. Asymmetric cryptography, the kind used to secure online communications, involves pairs of keys — one to lock, another to unlock. It’s a very useful and convenient approach when dealing with multiple parties. Amazon chose to use symmetric encryption instead, where the same key is used to both lock and unlock the data, because it’s faster and more efficient. “One of the things we did 15 years ago is that to authenticate customers who talk to us, we rely on symmetric cryptography,” says Ken Beer, director of AWS cryptography. “And the Key Management Service that I helped launch back in 2013, we also said we would rely on symmetric cryptography to protect all the keys.” Today, over 99.9% of all the encryption of data at rest involves no asymmetric cryptography anywhere in the chain of keys that secure it, he says. That turned out to be an extremely fortuitous decision. The reason? Quantum computers are expected to be able to break today’s asymmetric encryption standards — but symmetric encryption is safe. And quantum computing progress has been moving so quickly of late that both Google and Cloudflare have moved up their timelines. Companies of all sizes are now up against the clock to update their cryptography to quantum-safe algorithms — unless those algorithms are symmetric. “We don’t have to change it, and we’re glad we don’t have to change it,” Beer says. As for all the data stored on Amazon’s servers, the company doesn’t have to decrypt and re-encrypt it with quantum-safe methods. It’s already quantum-safe. That’s not to say that Amazon doesn’t have any asymmetric encryption anywhere. Communications with untrusted counterparties, or over the public Internet, require it. AWS is targeting 2028 and 2029 to complete its public-certificate post-quantum authentication — there’s a delay there because the world still needs to agree on a common set of standards. “It’s going to require cooperation between five or ten big vendors,” says Beer. “Once we agree on the method of validating digital signatures, then all the vendors that own different parts of the technology stack will go and implement it.” Amazon has been a member of the CA/Browser Forum for over a decade, he says, referring to the industry body that sets the rules for how public key infrastructure works on the Internet. “We have confidence that we’ll move the industry by 2029.” AWS customers who use AWS for their cryptographic heavy lifting get post-quantum protection for free without additional effort. Those who have their own asymmetric cryptography, however, will have to do some serious work. “There’s potentially a lot of crypto embedded in people’s applications,” Beer says. “Can I find it? Can I change it? Do I have to go talk to some vendor I haven’t talked to in ten years — or that doesn’t exist anymore?” Those are the kinds of questions enterprise customers should be asking. S3 security controls and the shared responsibility model There have been no public instances of AWS Nitro or encryption infrastructure being compromised. The NCC report, as well as other analyst research, shows that it’s working. But Amazon data breaches are constantly in the news. The reason? AWS customers are failing to secure their S3 buckets, leaking credentials, hard-coding keys, and making many other mistakes when managing their environments. According to cybersecurity firm UpGuard, AWS S3 security is “flawed by design,” with thousands of breaches over the past few years detected by the firm. “From the day that S3 launched, buckets have been secure by default,” counters Brandwine. That is accurate, UpGuard says — but AWS makes it too easy to accidentally misconfigure buckets, it concludes. Brandwine admits there’s an issue here. “If a customer has a bad day in the cloud, it’s something that they did,” he says. “But if a bunch of customers have a bad day in the cloud, we need to take a look.” Say, for example, a company uses an S3 bucket to hold some content and then takes down the bucket — but there are still web pages, or services, or tools that link to it. Attackers can hijack these abandoned buckets and use them for malicious purposes. This is user error — customers who take down buckets should also take down the links pointing to them. But it happens. And happens frequently. “So we built a thing called active defense,” says Brandwine. When Amazon detects someone trying to use a dictionary attack to guess bucket names, “we lie to them and say, ‘Bucket not found,’“ he says. “It makes scanning ineffective and has effectively ended dictionary attacks against S3.” But the AWS infrastructure is complex, and there are many instances in which enterprise customers can easily set up policies incorrectly. And it’s not just customers. Amazon employees also make mistakes. In CodeBreach, AWS engineers misconfigured AWS’s own systems, according to Wiz researchers. Attackers have always looked for opportunities to exploit misconfigurations, weak credentials, and similar customer-side problems. Now, with AI, the risks are greater than ever. “AI isn’t changing what threat actors do,” says Gee Rittenhouse, VP of security services at Amazon. “It changes the speed and scale at which they operate. We still see the primary threat vectors, such as phishing and credential compromise, but the exploits are much faster.” Amazon is also leveraging this technology, he says. At the end of March, AWS launched its AWS Security Agent for on-demand penetration testing and AWS DevOps agent, which autonomously resolves incidents. “We have attacker agents pitted against defender agents and what used to take a few weeks we’re now able to do in a few hours,” he says. But there’s another way in which AI is a big emerging threat for Amazon. The AI agents that enterprises are building and deploying on AWS could be the next big breach vector, the new equivalent of unsecured S3 buckets. Can Amazon take its successes at securing its infrastructure and combine it with the lessons learned from years of S3 bucket breaches to build a security foundation for AI agents? Rittenhouse says yes. And a lot of it comes down to the agent authentication layer and access privileges. “We just released a new authentication, the OAuth 2 token exchange,” he says. It’s part of Amazon Bedrock AgentCore Identity, and it involves keeping track of which user the AI agent is acting on behalf of, and what resources it’s trying to access. “It evaluates whether the agent can do this before it does it, at the infrastructure layer,” says Rittenhouse. “And if it’s no, it’s not allowed to do it then, regardless of the command, or whether it’s hallucinating, or whether it’s been taken over, our infrastructure does not allow that.” “That’s the advantage we have,” he adds. “We go all the way from the infrastructure layer.” View the full article

CSO and CISO roles are among the hardest to fill in IT. Which should be good news for cybersecurity professionals that aspire to leadership positions as the organization’s top security exec. For those that do, the authority, clout, pay, and benefits are increasing significantly. But so too are the responsibility and accountability placed on cybersecurity leaders today. Now typically part of the C-suite, many CSOs and CISOs report directly to the CEO, and all are expected to be a driving force for organizational security, compliance, and, in many cases, overall business success. So while either title may be very personally rewarding, the role is definitely not for the faint of heart. With that in mind, we asked current and recently elevated CSOs, as well as executive recruiters, about what it takes to land a top security executive appointment or promotion, and how those interested in earning the CSO or CISO role should go about getting it. Evolving responsibilities and expectations for CSOs One person who has seen the CSO role significantly evolve is Kanani Breckenridge, CEO and headhuntress at San Diego-based Kismet Search. “I’ve been recruiting for the CSO and CISO functions for over 25 years,” Breckenridge explains. “I started in 1999 during the dot-com bubble, when security was largely perimeter defense and antivirus software. Since then, I’ve watched the role evolve from technical gatekeeper to enterprise risk executive. Today’s CSO sits at the intersection of technology, regulatory exposure, revenue continuity, and brand trust. It is no longer a back-office function. It is a board-level accountability role.” With this new responsibility, Breckenridge says CSO candidates today are typically expected to: Govern the explosion of shadow AI and establish guardrails for generative AI before it creates material data leakage. Move beyond prevention and operate as a business enabler, proving the organization can maintain a minimum viable business during a sustained outage. Address compliance burdens, such as SEC disclosure rules or the EU AI Act, not as a checklist, but as a strategic shield that protects enterprise value. “Resilience, transparency, and measurable assurance are now baseline expectations,” Breckenridge explains. Find out what it takes to be an award-winning CISO at the CSO Cybersecurity Awards & Conference, May 11-13, 2026, in Nashville. href="https://event.foundryco.com/cso-conference-awards/?utm_medium=editorial&utm_source=cso2026_foundry_pre-event_editorial&utm_campaign=cso_2026_pre_event_articles&utm_term=4/25/2026-5/16//2026&utm_content=editorial">Register to attend Living the evolution of cybersecurity leadership One cybersecurity professional that has lived that transformation is Dale Hoak, who in July 2025 was promoted to the role of CISO at RegScale, a leading provider of continuous controls monitoring (CCM). Hoak originally joined RegScale as its first security hire and one of its first employees. Since then, he has helped the company build its security foundation. In announcing Hoak’s promotion at the time, RegScale CEO Travis Howerton noted, “The CISO role is often seen as a lifetime achievement award in this field, and Dale has earned it. With decades of experience in the Department of Defense and private sector, he has brought deep expertise, a relentless drive, and a clear vision to our security program.” In his years leading up to RegScale, Hoak “built security programs from scratch, fixed ones that were broken, operated in environments where downtime and data loss or failure had real consequences,” he says. “That experience gave me what I believe to be a strong operational background and mindset and healthy respect for practicality over theory. It’s how you do it, not how you think about it.” RegScale agreed when it offered Hoak its first cybersecurity role. For Hoak, the mission was clear: “Build trust and scale without slowing the business down,” he says. “RegScale lives in some of the most highly regulated environments out there. Security has to be an enabler; it can’t be a blocker. The CISO’s role in every company is to help the organizations get to ‘yes,’ because organizations often can’t get out of their own way.” As a CISO, you must understand how to make a positive impact on the business, he adds. You’re not just security. Part of your job in the C-suite is to help the organization make money, Hoak advises. The journey through the ranks to CSO Another cybersecurity professional who worked his way up the ranks, though through a multi-employer path, is Russ Kirby, now CISO at Ping Identity. “I’ve previously worked across technical, compliance, and business-facing roles, so I bring variety and breadth of experience,” Kirby explains. “The size and scale of those roles and companies has also been dramatically different — from startups to Fortune 50s. I can talk in context of the ‘now,’ but also look to the future and see where the company wants to go.” That experience led Kirby to the role of CISO at ForgeRock in 2019. When ForgeRock was acquired by Ping Identity and the companies officially merged in August 2023, he took over the role of global CISO at Ping Identity. “I view the CISO position as a business leadership role rather than just a technical one, focusing on people and strategy,” Kirby explains. “The ability to communicate and translate for a broad spectrum of audiences — technical, non-technical, business, non-business — is critical. As a CISO, you need to be able to help people understand the ‘why’ of what we do.” Once viewed primarily as a senior technologist focused on systems and controls, today’s CISO now sits at the heart of business strategy, Kirby says. The modern CISO is also, by necessity, a futurist: forecasting not just threats, but how digital trust, identity, and security will determine which businesses succeed and which fail. Minimal business and technology skills for CSO candidates The gold standard CSO candidate today has a T-shaped background: deep expertise in one or two domains with broad fluency across the rest of the security ecosystem, Breckenridge explains. Here, three areas stand out: Deep experience in identity and access management is often more valuable today than traditional network security. Leaders who have lived through large-scale hybrid or multicloud migrations across AWS, Azure, or Google Cloud Platform understand the modern attack surface in a way legacy operators often do not. You do not need to be a data scientist, but you must understand model risk, data poisoning, automated agents, and how AI reshapes both offensive and defensive security dynamics within your environment. “On the technology side, proficiency in security automation and continuous control monitoring is increasingly critical,” Breckenridge explains. “In 2026, if you cannot automate compliance and evidence collection, you cannot scale. Manual security programs do not survive growth.” On the business side, financial acumen is non-negotiable, Breckenridge says. You must be able to explain a $5 million security investment in terms of revenue protection, contractual leverage, or reduced insurance premiums. “Boards think in terms of exposure, enterprise value, and downside risk. If you cannot translate your strategy into that framework, you will struggle to gain sustained support,” Breckenridge says. Challenges and surprises that often await a new CSO Once appointed or promoted to a CSO role, certain challenges and surprises may come up that new appointees will have to navigate. “One I learned early on, and I wasn’t ready for this, is that everything is a negotiation,” RegScale’s Hoak explains. “Whether you’re dealing with vendors or your own teams, you have to identify problems, and then negotiate with other folks to get them to understand it or to do what they need to do.” “I’m used to the old days, where you tell somebody to do it, and they do it,” Hoak says. “Now, most everything is a negotiation, regardless of whether you’re going up or down, whether you’re talking to a superior or subordinate. The other thing is that rarely are the hardest problems technical in nature. Most of the time you’re dealing with either poor planning or poor communication. I find that I spend far more time doing research and root cause analysis now than actually fixing issues.” Ping Identity’s Kirby agrees, noting that most CSO burnout is caused by issues related to hero culture, micromanagement, and failure to delegate. “This is not a mental health crisis caused by hackers; it is a leadership design flaw,” Kirby explains. “The most important point is that it’s entirely fixable through modern delegation models, autonomous team structures, and trust-based leadership.” Steps to take toward landing a CSO role What are best steps a CSO candidate or aspirant can take to land a coveted role? It starts with transitioning your mindset from being the “No” person to being the “How” person, Breckenridge explains. The modern CSO must evolve from cost center to trust center as the role has shifted to being a more integrated part of the overall business and associated with revenue. Security should be a reason a customer feels confident signing a contract, not the reason a product launch is delayed. “Focus on continuous assurance,” Breckenridge says. “At any given moment, you should be able to demonstrate that your controls are functioning as intended. That level of transparency transforms board conversations from reactive to strategic.” From a recruiting perspective, Breckenridge advises candidates not to pursue the title without the competence and real operating depth to back it up. Technology is evolving quickly, the regulatory environment is tightening, and this role carries genuine personal exposure. When candidates move between companies, they are evaluated on measurable scope, authority, and outcomes, Breckenridge adds. Boards and hiring committees look closely at what happened under your watch. If there were material incidents, weak controls, or inflated scope relative to your actual mandate, that becomes visible very quickly. Title inflation does not hold up under due diligence. “The successful leaders who build durable careers in this role align accountability with authority, speak fluently in both risk and revenue, and position security as an embedded strategic function of the business,” Breckenridge says. “When you do that well, you are not simply protecting the company. You are strengthening its resilience and long-term enterprise value.” There’s no playbook for leading through today’s cyber risk—only experience. The CSO Cybersecurity Awards & Conference brings together CISOs and senior security executives for peer‑driven insight, unfiltered conversations, and practical strategies that drive real business impact. Register here View the full article

The threat actor seeding the Open VSX code marketplace with fraudulent extensions that download the GlassWorm malware has uploaded 73 more impersonated links, as its attempt to infect software supply chains continues. Philipp Burckhardt, head of threat intelligence at Socket, which revealed the latest activity, called it a “significant escalation” in the gang’s activity, after it added 72 malicious extensions last month. The extensions impersonate trusted developer tools. More recently, the listed extensions contain benign code so they will evade malware scanners. Later, after connecting automatically to newly-created GitHub or other public accounts, they download GlassWorm to developers’ computers as an update. This latest wave includes some extensions that rely on bundled native binaries. “The extension itself acts as a thin loader,” Socket explained in its report. “By shifting critical logic outside of what tools typically scan, and spreading it across multiple delivery mechanisms, the threat actor increases the likelihood of evading detection.” Of the 73 new extensions seen by Socket, last week, six were activated to connect to sources of malware. This week, eight more were activated, Burckhardt said in an interview. Socket has notified the Eclipse Foundation, which oversees the Open VSX marketplace, of the latest fraudulent additions, and Burckhardt expects that by now all 73 have been deleted. But the continuing attacks are another example of how threat actors are trying to use open code marketplaces used by developers, such as Open VSX and npm, to compromise applications as they are being created, to enable the later distribution of data stealing malware. [Related content: GlassWorm malware spreads via dependency abuse] Extensions are add-on modules that help developers speed application creation. Since Microsoft’s Visual Studio Code is one of the most common code editors around the world, VS Code extensions are a tempting target for threat actors. Popular extensions include utilities that do everything from analyzing JavaScript, TypeScript, and other supported languages for potential errors, to AI tools that suggest code completions. The Eclipse Foundation says the Open VSX registry hosts over 12,000 extensions from more than 8,000 publishers. A systemic gap in dev environment security GlassWorm, despite its name, isn’t a worm, but a loader. According to StepSecurity, GlassWorm’s stage 3 payload includes a dedicated credential theft module that harvests GitHub and npm tokens from multiple sources. The attacker then uses these credentials to force-push malware into all of the victim’s repositories. The loader includes host gating that detects and negates the dropping of malware on Russian language computers, leaving Burckhardt to suspect that the threat actors behind this campaign are Russian. Tanya Janca, who teaches secure coding through her firm, SheHacksPurple, observed, “what makes the GlassWorm campaign particularly dangerous and interesting is that it exposes a systemic gap in how we secure developer environments.” “With software packages, we have lockfiles, pinned hashes, and reproducible builds. With IDE [integrated development environment] extensions, we have almost nothing. There is no integrity verification, no equivalent of package-lock.json, and most organizations have no policy whatsoever governing what developers are allowed to install into their IDEs.” Malicious actors have noticed the gap. For them, targeting VS Code extensions is a lower-friction attack surface than targeting packages, she said, specifically because the controls that organizations have spent years building around their dependency pipelines simply do not exist for extensions. The reason only some of the 73 extensions had been activated before the warning spread is certainly deliberate, Janca added. “This looks like an intentionally staged deployment: publish them all broadly to establish credibility and accumulate downloads, then activate harmful subsets over time to avoid triggering mass detection and to preserve a reserve of ready assets if some are removed or noticed. Advice for developers Janca said developers who want to reduce their exposure to the GlassWorm campaign should start with the basics: install fewer extensions and treat each one as a dependency with real risk attached. Disable auto-update so you control when updates are applied, and carefully evaluate each one. Use a next-generation SCA tool that covers IDE extensions and other areas of the supply chain, not just third party packages and components. “One thing most people overlook,” she added: “Audit what you already have installed. Extensions accumulate over the years and the developer who built that extension in 2022 may not be the same person maintaining it today.” Teams that want stronger guarantees should use a behavioral monitoring tool that watches runtime activity, Janca said, not just install-time content. Establish a formal approval process for new extensions, with security sign-off. Maintain an allowlist of approved extensions, and do not install from alternative marketplaces like Open VSX without treating it as a higher-risk source. “The same discipline we apply to open source packages needs to be applied to the tools living inside our IDEs and the rest of our software supply chain,” she said. Train developers to recognize signs Burckhardt said CSOs need to ensure developers are trained to recognize phony extensions, carefully examining the names of files they are looking for to avoid being fooled by typosquatting, and verifying a publisher is legitimate. Some GlassWorm-related extensions have more downloads than a legitimate extension, he noted, a suspicious sign. Developers should also be restricted in what they can download, he added, particularly extensions newly added to a repository. It may also be necessary to disable the ability to automatically download extension updates, he said, and developers should be warned to only download extensions they need, not ones to experiment with. CSOs should also look for security tools that give visibility into what developers download, Burckhardt added. And to help detect Open VSX issues, earlier this month the Eclipse Foundation announced the Open VSX Security Researcher Recognition Program to encourage responsible vulnerability disclosure. View the full article

Security researchers have disclosed a high-severity vulnerability affecting the Cursor IDE, allowing arbitrary code execution on a developer’s machine through a seemingly routine repository interaction. According to findings by AI pentesting platform Novee Security, once a developer cloned and interacted with a malicious repository, the IDE’s AI agent could trigger embedded Git logic, resulting in attacker-controlled code execution. “The root cause is not a flaw in Cursor’s core product logic, but rather a consequence of a feature interaction in Git, one that becomes exploitable the moment an AI agent starts autonomously executing Git operations inside a repository it doesn’t control,” said Assaf Levkovich, a vulnerability researcher at Novee, in a blog post shared with CSO ahead of its publication on Tuesday. The flaw could be used to enable the AI agent (through prompt injection) to write to improperly protected Git configurations, which could allow out-of-sandbox RCE on the next trigger. It is now patched by Cursor, with no indication of any in-the-wild exploitation as yet. Using a legit Git feature for code execution The exploit depends on standard Git features, including Git hooks and Bare repositories. Hooks are scripts that run automatically during events like pre-commits or post-checkouts, while bare repositories are repositories that contain only version control metadata and can be nested within other repositories. According to Novee, an attacker could embed a malicious bare repository inside an otherwise legitimate project and plant a harmful pre-commit hook within it. When Cursor’s AI agent performs a routine operation, like a git checkout triggered by a high-level prompt, it could execute that hook. This would result in automatic execution of remote attacker code on the developer’s machine. Levkovich noted that the underlying Git behavior allowing the attack path is well documented, but what’s different here is Cursor autonomously deciding to execute Git operations (running hooks) that ultimately result in code execution. The flaw is tracked as CVE-2026-26268, with a critical severity rating of 9.9 out of 10 assigned by NVD, and affects Cursor versions prior to 2.5. “Sandbox escape via writing .git configuration was possible in versions prior to 2.5,” reads an NVD description of the flaw. “A malicious agent (i.e. prompt injection) could write to improperly protected .git settings, including git hooks, which may cause out-of-sandbox RCE next time they are triggered.” Expanded attack surface with agentic IDEs Novee warned that while traditional IDEs are passive, doing what developers explicitly tell them to do, Cursor’s AI agent interprets intent and autonomously decides which commands to run, which includes Git operations. And that’s where the problem lies. “In traditional pentesting, ‘client-side’ attacks targeting developer machines have always been a known vector,” Levkovich noted. “But they relied on user error or a lapse in vigilance, typically requiring a degree of deliberate action on the part of the victim: opening a malicious file, executing a script, clicking a link.” Security has long relied on trusted IDEs and human action as safeguards, but AI agents remove both constraints, he added. As the attack path does not need phishing or tricking the user into running scripts beyond cloning the bare repository, and malicious code executes as part of the normal development workflow, it is quite difficult to detect. Still, Cursor contested NVD’s critical rating of the flaw and instead issued its own high-severity CVSS score of 8.0 out of 10. The flaw is patched in Cursor version 2.5. View the full article

In the enterprise SaaS space, AI agents are becoming an integral part of the SaaS product. To make these intelligent agents truly useful, they need contextual, customer-specific knowledge, something standard Large Language Models (LLMs), open source or otherwise, inherently lack since they are not trained on customer proprietary data. Retrieval-Augmented Generation (RAG) is the bridge that grants AI agents real-time access to a company’s most sensitive data: Internal wikis, CRM records, code repositories, task tracking system and intellectual property. However, this bridge introduces significant security liabilities. The cost of getting RAG security wrong in a SaaS environment is catastrophic, ranging from cross-tenant data leaks and unauthorized PII exposure to malicious prompt injections. Recent RAG-related security failures Over the past year, several high-profile incidents have underscored the vulnerabilities of enterprise AI integrations: Zero-Click data exfiltration (Late 2025): The “EchoLeak” vulnerability demonstrated how attackers could use a specially crafted, unclicked email to manipulate Microsoft 365 Copilot’s massive enterprise RAG pipeline. The AI was tricked into retrieving and exfiltrating sensitive corporate data without any employee interaction. Vector database exposures (2024 – 2025): Several incidents involved exposed API keys for vector databases. In one notable fintech breach, attackers used “reconstruction attacks” to reverse-engineer embeddings back into millions of original client investment portfolios. A similar access-control bypass in Pinecone exposed over 200,000 healthcare records. Indirect prompt injection in development environments (August 2025): Attackers implanted hidden, malicious text inside public GitHub README files. When developers used the Cursor IDE’s AI assistant to summarize these repositories, the AI unwittingly executed the hidden commands, granting attackers unauthorized access to developer machines. Knowledge base poisoning (March 2026): A massive operation flooded external knowledge bases with manipulated data. Because AI answering systems rely on RAG for up-to-date functionality, this “data irrigation” successfully poisoned the retrieval pipelines, forcing AIs to push false information and disguised ads to millions of users. To secure RAG pipelines effectively against these evolving threats, organizations must thoroughly understand their architecture, map the threat models and implement defense-in-depth strategies. Deconstructing the enterprise RAG architecture To secure a RAG system, you must first understand how data flows through it. A typical enterprise RAG pipeline operates in three distinct phases: Ingestion & embedding (data layer): Raw enterprise data is pulled from sources like ERPs, CRMs and document repositories. This data is cleaned, chunked into smaller segments and passed through an embedding model that converts the text into high-dimensional numerical vectors. Storage & retrieval (vector layer): These vectors, along with metadata (e.g., source tags, access permissions), are stored in a specialized Vector Database (like Pinecone, Milvus or ElasticSearch). When a user asks a question, the system runs a similarity search to retrieve the most semantically relevant document chunks. Generation & orchestration (LLM layer): The retrieved enterprise data is combined with the user’s original query to create an augmented prompt. The LLM then uses this context to generate a highly accurate, grounded response. Here is a visual representation of the RAG architecture, overlaid with the primary threat vectors targeting each phase: IMAGE GOES HERE The threat model: How RAG pipelines are attacked The integration of dynamic data retrieval fundamentally shifts the AI threat landscape. Frameworks like the OWASP Top 10 for LLM Applications highlight several critical vulnerabilities specific to RAG: Prompt injection (Direct and indirect) Prompt injection remains the most critical vulnerability in AI systems. While direct injection involves a user trying to jailbreak the chatbot, RAG introduces indirect prompt injection. Here, an attacker hides malicious instructions within an external document (e.g., a customer support ticket or an uploaded PDF). When the RAG system retrieves this poisoned document as context, the LLM unwittingly executes the hidden commands. This can lead to data exfiltration or the hijacking of the AI agent’s actions. Knowledge base poisoning Unlike prompt injection, which targets execution logic, data poisoning targets the integrity of the knowledge base. Attackers inject manipulated, biased or false information into the data sources feeding the ingestion pipeline. Because the LLM inherently trusts the retrieved context, it will confidently generate harmful or factually incorrect responses, destroying trust in the SaaS application. Sensitive information disclosure and vector weaknesses RAG pipelines frequently process Personally Identifiable Information (PII) and confidential business logic. If the pipeline lacks robust filtering, sensitive documents are vectorized without proper access boundaries. Furthermore, vectors are not inherently secure; sophisticated “embedding inversion” attacks can reverse-engineer vectors to reconstruct the original sensitive text. Cross-tenant contamination In multi-tenant SaaS environments, poor isolation can lead to cross-tenant contamination. A poorly architected retrieval system might inadvertently allow one customer to retrieve another customer’s proprietary data via a perfectly normal semantic search. Prevention and detection Securing a RAG pipeline requires a zero-trust posture across the entire data lifecycle. You cannot rely solely on the LLM to behave safely; security must be layered across ingestion, retrieval and generation. Prevention strategies Sanitize the ingestion pipeline (DLP): Prevention begins before data reaches the vector database. Implement Data Loss Prevention (DLP) controls to scan documents before they are chunked and embedded. Anonymize, redact or pseudonymize sensitive fields (like SSNs or API keys) so that a leak, if it occurs, yields useless data. Compliance & data privacy (The right to be forgotten): Enterprise SaaS is heavily bound by regulations like GDPR, CCPA and HIPAA. A massive, often-overlooked challenge in RAG pipelines is data deletion. In a traditional database, deleting a user record is a simple SQL query. In a Vector Database, if a user requests their data be deleted, you must ensure every fragmented, embedded vector chunk related to that user is also destroyed. Implement rigorous metadata tagging during ingestion so that specific customer data can be easily located and purged from the vector database to maintain full compliance. Vector database encryption: Treat your vector database as a highly sensitive asset. Ensure data is encrypted at rest and in transit. Retrieval-time access control (RBAC & ABAC): The most effective defense against data leakage is enforcing document-level permissions during the retrieval phase. When a similarity search is executed, the vector database must strictly honor the querying user’s access rights. If a user doesn’t have permission to view a document in the underlying CRM, the RAG system should not be able to retrieve it for them. Prompt isolation and input guardrails: Implement architectural guardrails that separate the system prompt from the retrieved context and the user input. Pre-process incoming queries to detect jailbreak attempts or known injection signatures before passing them to the LLM. Detection strategies Output filtering: Do not implicitly trust the LLM’s output. Deploy output filters to evaluate the generated response for regurgitated PII, toxic content or anomalous behavior before delivering it to the user. Telemetry and semantic monitoring: Standard logging isn’t enough. Monitor for token usage spikes (which can indicate Denial of Wallet attacks) and track the hit/miss ratio of the retrieval component. Look for semantic anomalies, such as an AI agent consistently pulling documents that seem unrelated to the user’s role. Evaluate against data drift: Continuously evaluate the pipeline using frameworks like RAGAS to detect if the knowledge base has been poisoned or if the model’s accuracy is decaying over time. Operationalizing security with Google cloud tools Implementing these defense-in-depth strategies requires robust tooling. For organizations building on Google Cloud, several native enterprise-grade services map directly to the RAG security lifecycle: Data ingestion & sanitization: Google cloud sensitive data protection (formerly Cloud DLP) inspects, classifies and redacts sensitive PII and financial data from raw documents before they are ever chunked and sent to the embedding model. Vector storage & access control: Vertex AI vector search integrates directly with Google Cloud IAM, allowing developers to enforce strict, retrieval-time access controls and ensure strong tenant isolation within multi-tenant SaaS environments. Input/output guardrails: Vertex AI model armor serves as a dedicated security layer between the user and the LLM. It evaluates incoming prompts to block jailbreaks and indirect prompt injections and it filters outgoing responses to prevent sensitive data leaks and toxic content. Pipeline evaluation: Vertex AI evaluation continuously assesses the quality and safety of your RAG pipeline, tracking critical metrics like “groundedness” to ensure the AI’s responses are strictly based on the retrieved context and not hallucinated or poisoned data. Overall AI security posture: Security command center (SCC) enterprise integrates AI security posture management (AI-SPM) to automatically discover AI workloads across your environment, identify misconfigurations (such as exposed vector databases), and detect potential data exfiltration paths. Conclusion As AI agents take on increasingly autonomous roles within Enterprise SaaS platforms, RAG pipelines serve as their vital connection to reality. However, the operational benefits of augmented intelligence come with profound security risks. Securing these pipelines demands a departure from legacy application security models. By enforcing strict access controls at the point of retrieval, aggressively sanitizing inputs and outputs and maintaining continuous observability over AI operations, enterprise SaaS providers can confidently harness the power of AI while safeguarding their customers’ most valuable assets. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

In the enterprise SaaS space, AI agents are becoming an integral part of the SaaS product. To make these intelligent agents truly useful, they need contextual, customer-specific knowledge, something standard Large Language Models (LLMs), open source or otherwise, inherently lack since they are not trained on customer proprietary data. Retrieval-Augmented Generation (RAG) is the bridge that grants AI agents real-time access to a company’s most sensitive data: Internal wikis, CRM records, code repositories, task tracking system and intellectual property. However, this bridge introduces significant security liabilities. The cost of getting RAG security wrong in a SaaS environment is catastrophic, ranging from cross-tenant data leaks and unauthorized PII exposure to malicious prompt injections. Recent RAG-related security failures Over the past year, several high-profile incidents have underscored the vulnerabilities of enterprise AI integrations: Zero-Click data exfiltration (Late 2025): The “EchoLeak” vulnerability demonstrated how attackers could use a specially crafted, unclicked email to manipulate Microsoft 365 Copilot’s massive enterprise RAG pipeline. The AI was tricked into retrieving and exfiltrating sensitive corporate data without any employee interaction. Vector database exposures (2024 – 2025): Several incidents involved exposed API keys for vector databases. In one notable fintech breach, attackers used “reconstruction attacks” to reverse-engineer embeddings back into millions of original client investment portfolios. A similar access-control bypass in Pinecone exposed over 200,000 healthcare records. Indirect prompt injection in development environments (August 2025): Attackers implanted hidden, malicious text inside public GitHub README files. When developers used the Cursor IDE’s AI assistant to summarize these repositories, the AI unwittingly executed the hidden commands, granting attackers unauthorized access to developer machines. Knowledge base poisoning (March 2026): A massive operation flooded external knowledge bases with manipulated data. Because AI answering systems rely on RAG for up-to-date functionality, this “data irrigation” successfully poisoned the retrieval pipelines, forcing AIs to push false information and disguised ads to millions of users. To secure RAG pipelines effectively against these evolving threats, organizations must thoroughly understand their architecture, map the threat models and implement defense-in-depth strategies. Deconstructing the enterprise RAG architecture To secure a RAG system, you must first understand how data flows through it. A typical enterprise RAG pipeline operates in three distinct phases: Ingestion & embedding (data layer): Raw enterprise data is pulled from sources like ERPs, CRMs and document repositories. This data is cleaned, chunked into smaller segments and passed through an embedding model that converts the text into high-dimensional numerical vectors. Storage & retrieval (vector layer): These vectors, along with metadata (e.g., source tags, access permissions), are stored in a specialized Vector Database (like Pinecone, Milvus or ElasticSearch). When a user asks a question, the system runs a similarity search to retrieve the most semantically relevant document chunks. Generation & orchestration (LLM layer): The retrieved enterprise data is combined with the user’s original query to create an augmented prompt. The LLM then uses this context to generate a highly accurate, grounded response. Here is a visual representation of the RAG architecture, overlaid with the primary threat vectors targeting each phase: Mayank Singhi The threat model: How RAG pipelines are attacked The integration of dynamic data retrieval fundamentally shifts the AI threat landscape. Frameworks like the OWASP Top 10 for LLM Applications highlight several critical vulnerabilities specific to RAG: Prompt injection (Direct and indirect) Prompt injection remains the most critical vulnerability in AI systems. While direct injection involves a user trying to jailbreak the chatbot, RAG introduces indirect prompt injection. Here, an attacker hides malicious instructions within an external document (e.g., a customer support ticket or an uploaded PDF). When the RAG system retrieves this poisoned document as context, the LLM unwittingly executes the hidden commands. This can lead to data exfiltration or the hijacking of the AI agent’s actions. Knowledge base poisoning Unlike prompt injection, which targets execution logic, data poisoning targets the integrity of the knowledge base. Attackers inject manipulated, biased or false information into the data sources feeding the ingestion pipeline. Because the LLM inherently trusts the retrieved context, it will confidently generate harmful or factually incorrect responses, destroying trust in the SaaS application. Sensitive information disclosure and vector weaknesses RAG pipelines frequently process Personally Identifiable Information (PII) and confidential business logic. If the pipeline lacks robust filtering, sensitive documents are vectorized without proper access boundaries. Furthermore, vectors are not inherently secure; sophisticated “embedding inversion” attacks can reverse-engineer vectors to reconstruct the original sensitive text. Cross-tenant contamination In multi-tenant SaaS environments, poor isolation can lead to cross-tenant contamination. A poorly architected retrieval system might inadvertently allow one customer to retrieve another customer’s proprietary data via a perfectly normal semantic search. Prevention and detection Securing a RAG pipeline requires a zero-trust posture across the entire data lifecycle. You cannot rely solely on the LLM to behave safely; security must be layered across ingestion, retrieval and generation. Prevention strategies Sanitize the ingestion pipeline (DLP): Prevention begins before data reaches the vector database. Implement Data Loss Prevention (DLP) controls to scan documents before they are chunked and embedded. Anonymize, redact or pseudonymize sensitive fields (like SSNs or API keys) so that a leak, if it occurs, yields useless data. Compliance & data privacy (The right to be forgotten): Enterprise SaaS is heavily bound by regulations like GDPR, CCPA and HIPAA. A massive, often-overlooked challenge in RAG pipelines is data deletion. In a traditional database, deleting a user record is a simple SQL query. In a Vector Database, if a user requests their data be deleted, you must ensure every fragmented, embedded vector chunk related to that user is also destroyed. Implement rigorous metadata tagging during ingestion so that specific customer data can be easily located and purged from the vector database to maintain full compliance. Vector database encryption: Treat your vector database as a highly sensitive asset. Ensure data is encrypted at rest and in transit. Retrieval-time access control (RBAC & ABAC): The most effective defense against data leakage is enforcing document-level permissions during the retrieval phase. When a similarity search is executed, the vector database must strictly honor the querying user’s access rights. If a user doesn’t have permission to view a document in the underlying CRM, the RAG system should not be able to retrieve it for them. Prompt isolation and input guardrails: Implement architectural guardrails that separate the system prompt from the retrieved context and the user input. Pre-process incoming queries to detect jailbreak attempts or known injection signatures before passing them to the LLM. Detection strategies Output filtering: Do not implicitly trust the LLM’s output. Deploy output filters to evaluate the generated response for regurgitated PII, toxic content or anomalous behavior before delivering it to the user. Telemetry and semantic monitoring: Standard logging isn’t enough. Monitor for token usage spikes (which can indicate Denial of Wallet attacks) and track the hit/miss ratio of the retrieval component. Look for semantic anomalies, such as an AI agent consistently pulling documents that seem unrelated to the user’s role. Evaluate against data drift: Continuously evaluate the pipeline using frameworks like RAGAS to detect if the knowledge base has been poisoned or if the model’s accuracy is decaying over time. Operationalizing security with Google cloud tools Implementing these defense-in-depth strategies requires robust tooling. For organizations building on Google Cloud, several native enterprise-grade services map directly to the RAG security lifecycle: Data ingestion & sanitization: Google cloud sensitive data protection (formerly Cloud DLP) inspects, classifies and redacts sensitive PII and financial data from raw documents before they are ever chunked and sent to the embedding model. Vector storage & access control: Vertex AI vector search integrates directly with Google Cloud IAM, allowing developers to enforce strict, retrieval-time access controls and ensure strong tenant isolation within multi-tenant SaaS environments. Input/output guardrails: Vertex AI model armor serves as a dedicated security layer between the user and the LLM. It evaluates incoming prompts to block jailbreaks and indirect prompt injections and it filters outgoing responses to prevent sensitive data leaks and toxic content. Pipeline evaluation: Vertex AI evaluation continuously assesses the quality and safety of your RAG pipeline, tracking critical metrics like “groundedness” to ensure the AI’s responses are strictly based on the retrieved context and not hallucinated or poisoned data. Overall AI security posture: Security command center (SCC) enterprise integrates AI security posture management (AI-SPM) to automatically discover AI workloads across your environment, identify misconfigurations (such as exposed vector databases), and detect potential data exfiltration paths. Conclusion As AI agents take on increasingly autonomous roles within Enterprise SaaS platforms, RAG pipelines serve as their vital connection to reality. However, the operational benefits of augmented intelligence come with profound security risks. Securing these pipelines demands a departure from legacy application security models. By enforcing strict access controls at the point of retrieval, aggressively sanitizing inputs and outputs and maintaining continuous observability over AI operations, enterprise SaaS providers can confidently harness the power of AI while safeguarding their customers’ most valuable assets. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Identity has always been central to security, but the proliferation of AI agents is rapidly changing the challenge of managing and securing identity, spurring CISOs to rethink their identity strategies — even how it is defined. “Identity is now both a control surface and an attack surface. We’ve had non-human identities as API keys, tokens, service accounts, but now we have agents, and that’s a new class,” says Dustin Wilcox, senior VP and CISO at S&P Global. The challenge is attributing actions to non-human identities because the typical signals don’t apply. “The techniques to identify a person, like the telemetry of how they use the keyboard, we won’t be able to do that when it’s an agent that’s working entirely digitally,” Wilcox tells CSO. And as agents proliferate, it becomes difficult for CISOs to maintain a complete picture of how many exist, what they’re used for, and what they’re authorized to do. “With a human identity, you can validate access needs directly. With service accounts, and now with agents, that clarity is harder to achieve,” says Docusign CISO Michael Adams. “Treating them as if they fit existing models can create gaps in visibility and control. At the same time, AI systems are contributing to rapid growth in non-human identities, including the creation of new credentials and tokens, which many inventory processes weren’t designed to track,” he adds. “And on the human side, generative AI is making social engineering more convincing, eroding some of the behavioral signals defenders have historically relied on. The result is an expanding attack surface at the same moment traditional indicators are becoming less reliable,” Adams tells CSO. The advice for CISOs is to adopt an identity-first security model that treats identity as the foundational layer of the security architecture. “Every access decision flows through identity and is continuously verified, not just checked at the door,” says Adams. Identity becomes the primary control plane CISOs are now managing a new class of identities that includes copilots, autonomous agents, and AI-powered workflows that don’t fit neatly into existing frameworks. And they can access systems, take actions, and make decisions at machine speed. Wilcox and Adams are speaking at the CSO Cybersecurity Awards & Conference, May 11–13. Reserve your place. As a result, Adams says CISOs will increasingly need to adopt an identity-centric security architecture and there are several key tenets to consider. Build a strong foundation before layering on complexity. The instinct when modernizing an identity program, says Adams, is to reach for sophisticated tooling. Instead, his advice is to get the fundamentals in place — clean directories, enforced least privilege, and reliable offboarding processes. “Organizations that jump to continuous verification without establishing basic identity hygiene may find themselves building on an unstable foundation,” he says. Design for the new class of identities. When designing role models and access policies, the temptation is to mirror existing structures. “That often carries years of permission creep into a new architecture. Starting from least privilege rather than from legacy helps ensure users receive only the access required for their job functions,” he says. “It’s important to challenge ‘it’s always been done this way’ where appropriate.” Get your non-human identity inventory in order. Build a full inventory of non-human identities and include who is responsible for each identity, and what each one is authorized to do. Do this before any more agents are operating. “This is as much a governance challenge as a technology one,” he notes. Treat MFA as a starting point, not a destination. The identity roadmap needs to include phishing-resistant alternatives to SMS or push-based MFA. Least privilege, micro-segmentation, and continuous monitoring are part of the playbook. “Assume credentials may be compromised and architect accordingly,” Adams advises. AI and the shifting security balance Identity systems have long been targets for attack. But as identity becomes the primary control plane, the risk becomes more concentrated and requires a different approach. “I’d encourage every CISO to think deeply about the intersection of identity and AI,” says Adams, adding that systems need to be redesigned around the principle of intent instead of actual behavior to ensure agents operate within appropriate boundaries. “That requires behavioral monitoring and real-time access evaluation — capabilities many organizations are still building toward,” he notes. “That’s the work ahead.” Wilcox is ultimately optimistic that AI offers security practitioners more tools to combat malicious actors. If CISOs can get this right, it’s a way to level the playing field with the attackers in a way not previously available. “We’ve had this asymmetric playing field where they’ve had the advantage for as long as I can remember. Now we can use AI both strategically and tactically to improve our defenses,” he says. Agentic AI is rewriting the identity security playbook in real-time, and your peers are already adapting. Hear Dustin Wilcox, Michael Adams, Renee Guttmann, and other leading CISOs share what’s actually working at the CSO Cybersecurity Awards & Conference, May 11–13. Secure your seat before it fills up. View the full article

The security industry has spent years building better authentication. Longer passwords, second factors, hardware tokens. And attackers responded by moving past authentication entirely. Adversary-in-the-middle (AiTM) phishing does not steal credentials and replay them. It sits between the user and the legitimate service, watches a real authentication succeed in real time, and walks away with the session token that proves it happened. The login was genuine. The MFA prompt was real. The attacker just observed — and copied the result. If you have read the analysis of how these attacks work, you understand the mechanism. This piece is about what comes after that understanding. Specifically: What controls reduce risk when the attack does not touch credentials at all? Why most current defenses miss the point The instinct after learning about AiTM phishing is to strengthen authentication. Buy hardware keys. Deploy passkeys. Force phishing-resistant MFA for privileged accounts. That instinct is correct but incomplete. Phishing-resistant authentication stops the credential theft phase. FIDO2 and passkeys bind the authentication challenge cryptographically to the legitimate domain, so a proxy domain cannot complete the handshake. This works. Organizations that have deployed passkeys broadly have significantly reduced their AiTM exposure at the authentication layer. But authentication is not the only layer that matters. Session tokens issued after successful authentication are the real target, and most organizations treat them as inherently trustworthy once issued. They are not. A session cookie is a bearer token. Whoever holds it is authenticated. There is no cryptographic binding between the token and the device that generated it, no ongoing proof that the holder is who they claim to be, and no automatic expiry triggered by location change or device mismatch. An attacker who steals a session token in one country can replay it from another, and the identity provider will accept it as legitimate. This is where most defenses currently have a gap. The 3 controls that close the gap Control #1: Bind sessions to managed devices The most impactful single control for session security is requiring managed, compliant devices as a condition of accessing sensitive resources. When access policies —such as Microsoft Entra Conditional Access — require that the device presenting a session token is enrolled, managed and meets compliance requirements, stolen tokens become significantly harder to replay. An attacker who intercepts a session token cannot easily replay it from an unmanaged machine if the policy requires device compliance. The session gets terminated. The attacker needs not just the token but also a compliant device — a much higher bar. This control is not foolproof. Sophisticated attackers can attempt to compromise managed devices directly. But it eliminates the easiest replay vector: Taking a stolen token and opening it in a browser on a completely different machine. The practical challenge is rollout. Requiring managed devices for all users immediately creates friction for contractors, part-time workers and anyone using personal devices for work. The pragmatic approach is to start with the highest-risk access: Administrative roles, finance systems and any application handling sensitive data. Expand from there as device management coverage improves. Control #2: Monitor for post-authentication anomalies AiTM attacks do not generate failed login attempts. They generate successful ones. Traditional monitoring focused on authentication failures will miss these attacks entirely. The signals that matter are in what happens after authentication succeeds. Specifically: Impossible travel. If a session authenticates from one location and then accesses resources from a geographically distant location minutes later, that warrants investigation. The time between events matters — a session that authenticates in New York and then accesses resources from a different continent thirty minutes later is not a normal user scenario. New device registration. Attackers who gain session access often immediately register a new MFA device or add a new authentication method to ensure persistent access. A new device registration occurring within minutes of a successful login is a high-fidelity signal worth alerting on. Inbox rule creation. A consistent post-compromise behavior across many attack campaigns is the creation of email forwarding rules or inbox filters designed to hide security alerts and forward communications to attacker-controlled addresses.Microsoft’s own incident response teams have documented this pattern repeatedly. Monitoring for inbox rule creation, particularly rules that forward externally or hide emails containing specific keywords, catches this behavior reliably. Privilege escalation attempts. Attackers who gain access to a standard user account typically attempt to escalate to higher-privilege roles or access administrative interfaces. Anomalous access attempts against admin portals or privilege management systems shortly after a new session authentication are worth flagging. None of these signals is conclusive on its own. But building detection rules around the combination — successful authentication followed by impossible travel followed by new device registration, for example — creates a detection capability that catches AiTM post-compromise activity that authentication monitoring misses entirely. Control #3: Shorten session lifetimes for high-value access Long-lived session tokens give attackers more time to operate after a successful interception. A token that remains valid for seven days provides a much larger window than one that expires after an hour and requires reauthentication. The friction of more frequent reauthentication is real. Users notice. For productivity applications used continuously throughout the day, aggressive session timeouts create a poor experience. The answer is risk-based session management rather than uniform policies. Sessions accessing low-sensitivity productivity tools can have longer lifetimes. Sessions accessing financial systems, administrative interfaces, HR data or anything handling regulated information should have short lifetimes and require reauthentication before performing sensitive operations.NIST’s Digital Identity Guidelines provide a useful framework for thinking about session timeout thresholds by assurance level. This approach concentrates the friction where the risk is highest, which makes it more defensible to users and leadership alike. The training problem has not gone away Technical controls reduce risk. They do not eliminate it. Users remain part of the attack surface, and the awareness training most organizations provide does not prepare them for what AiTM phishing looks like. Traditional phishing training teaches people to look for indicators of fake pages: Misspellings, suspicious URLs, unusual sender addresses. AiTM phishing pages show none of these indicators because they are not fake. They proxy the real service in real time. The URL may be suspicious, but users who click links in emails rarely check URLs carefully, even after training. The one behavioral change that reduces AiTM exposure is simple and teachable: Do not start authentication flows from links in emails. Navigate directly to the service. Bookmark login pages. If you receive an email telling you to log in somewhere, open a browser tab and type the address yourself rather than clicking through. This sounds obvious. It is not instinctive. Most users have spent years clicking login links in emails because it is faster and those links usually are legitimate. Changing that behavior requires explicit, repeated training that explains why the old approach is no longer safe — not just instruction to be more suspicious of phishing generally. Pair this with a low-friction reporting mechanism. Users who notice something feels wrong should be able to flag it in seconds. The value of early reporting in limiting the damage from a successful session compromise is significant, and that value disappears if reporting requires effort or feels like it will generate blame rather than action. The honest assessment AiTM phishing is a real and growing threat.Phishing-as-a-Service platforms like Tycoon 2FA and FlowerStorm have lowered the barrier to entry to the point where this is no longer an advanced technique requiring sophisticated threat actors. It is a commodity attack available to anyone willing to pay a subscription. The organizations that reduce their exposure are those that treat session security as seriously as credential security, build detection capability around post-authentication behavior rather than just failed logins, and give users a realistic model of how modern phishing works. Phishing-resistant authentication is the right long-term direction. Getting there takes time, budget and change management. In the meantime, the controls above provide meaningful risk reduction without waiting for full passkey deployment. The goal is not to make AiTM attacks impossible. It is to make them expensive enough that attackers move on to easier targets. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

SvetaZi | shutterstock.com Software im Bereich Endpoint Detection and Response (EDR) erfreut sich weiterhin steigender Beliebtheit – und wird mit zunehmender Reife immer effektiver. EDR-Lösungen bieten Realtime-Einblicke in die Endpunkt-Aktivitäten und ermöglichen es, Mobiltelefone, Workstations, Laptops, Server und andere Devices vor Cyberangriffen zu schützen. In diesem Kaufratgeber erfahren Sie: wie sich Endpoint Detection and Response definiert, welche Fähigkeiten EDR-Tools an Bord haben sollten, welche Anbieter und Lösung in Sachen Endpunkt-Sicherheit tonangebend sind, und welche konkreten Fragen vor einer Investition relevant sind. Endpoint Detection and Response erklärt EDR-Tools erfassen Verhaltensdaten aus diversen Endpunkt-Quellen. Dazu gehören herkömmliche Computing Devices wie Windows- oder Mac-Rechner genauso wie Peripherie- und IoT-Geräte, beispielsweise Drucker oder Controller. Um IT-Profis auf verdächtige Aktivitäten oder laufende Cyberangriffe aufmerksam zu machen, analysieren Endpoint-Security-Lösungen zudem auch Signale aus: Netzwerk-Traffic-Mustern, Cloud-Computing-Anwendungen und Systemprotokollen. Das deckt die “Detection-Seite” ab. Mit Blick auf die “Response-Seite” sind EDR-Lösungen auch in der Lage, Schaden zu begrenzen und zu beheben. Zum Beispiel, indem sie auffällige Devices isolieren oder problematische Netzwerksegmente mit einer Firewall absichern. Je nachdem, wie das jeweilige Tool funktioniert, können diese Prozesse mehr oder weniger manuellen Aufwand erfordern. Schwierig ist hingegen mittlerweile, EDR von anderen Detection-Produktkategorien zu unterscheiden. Das beste Beispiel ist Extended Detection and Response (XDR): Inzwischen haben viele EDR-Lösungen deutlich an Umfang und Funktionen zugelegt, was dazu geführt hat, dass sie teilweise zu XDR “umetikettiert” wurden. Das lässt die Grenzen zwischen den Kategorien immer weiter verschwimmen. Die zunehmende Verschmelzung von EDR und XDR ist mit Blick auf den Detection-Gesamtmarkt jedoch nur ein Aspekt. Die Produkte in diesem Bereich laufen unter anderem auch unter folgenden Bezeichnungen: Network Detection and Response (NDR), Managed Detection and Response (MDR), oder Application Detection and Response (ADR). Was EDR-Tools leisten sollten Folgende Funktionen sollte eine hochwertige Endpoint-Security-Lösung mitbringen: Fortschrittliche Threat-Detection-Funktionen: Effektive Endpoint-Detection-and-Response-Lösungen sind in der Lage, Events zu beobachten und in Echtzeit darauf zu reagieren. Sie sollten außerdem automatisch mit einer wachsenden Zahl von Netzwerken und Anwendungen skalieren können. Support für tiefgehende Untersuchungen: So können Security-Teams potenzielle Bedrohungen verstehen und möglichst zeitnah entsprechende Gegenmaßnahmen einleiten. Integrationsfähigkeit: EDR-Tools sollten sich mit diversen anderen Sicherheitslösungen integrieren lassen – etwa Firewalls, SIEM, SOAR und Incident-Response-Tools. Das ermöglicht Anwenderunternehmen, Bedrohungsinformationen über APIs und Konnektoren systemübergreifend zu teilen. Zentralisierte Management-Funktionen und Analytics-Dashboards: Um ausufernde Schulungen zu vermeiden und jederzeit den Überblick über den aktuellen Status aller Endpunkte im Unternehmen zu wahren, sollte EDR-Software eine zentrale Konsole und Datenanalysen bereitstellen. Lückenloser Support für die fünf wesentlichen Endpoint-Betriebssysteme: Windows-, macOS-, Android-, iOS- und Linux-Devices sollten im Idealfall abgedeckt sein. Die 6 wichtigsten Endpoint-Security-Lösungen Der Endpoint-Detection-and-Response-Markt hält unzählige Lösungen diverser Anbieter bereit. Um Sie nicht zu erschlagen, stellen wir Ihnen an dieser Stelle sechs bewährte und empfehlenswerte Lösungen namhafter Anbieter vor. CrowdStrike Falcon Insight EDR Die Crowdstrike-Lösung kombiniert XDR- und EDR-Funktionen und soll (Advanced) Threats auf Android-, Chrome-OS-, iOS-, Linux-, macOS- und Windows-Geräten automatisch identifizieren und priorisieren. Zudem stellt Falcon Insight EDR Echtzeit-Response-Funktionalitäten zur Verfügung, um auf Endpunkte zuzugreifen, während sie untersucht werden. Um schadhafte Aktivitäten automatisch zu identifizieren und zu klassifizieren, nutzt die Crowdstrike-Software KI-gestützte Angriffsindikatoren. Die automatisierte Alert-Priorisierung verspricht, manuelle Suchen und zeitaufwändige Recherche-Arbeiten überflüssig zu machen. Dank der integrierten Threat-Intelligence-Funktion kommt auch der übergeordnete Kontext von Cyberangriffen nicht zu kurz – inklusive Attribution. Microsoft Defender for Endpoint Ransomware, Fileless Malware und weitere raffinierte Angriffsmethoden verspricht Microsoft mit Defender for Endpoint den Wind aus den Segeln zu nehmen. Das Tool funktioniert auf Android, iOS, Linux, macOS und Windows. Die integrierten Threat-Analytics-Reportings sollen Unternehmen in die Lage versetzen: sich schnell einen Überblick über neu aufkommende Bedrohungen verschaffen zu können; ihre Gefährdungslage evaluieren zu können; sowie geeignete Gegenmaßnahmen zu definieren. Darüber hinaus überwacht Defender for Endpoint die Sicherheitskonfigurationen von Microsoft- und Drittanbieter-Produkten. Sollte die Software fündig werden, ergreift sie automatisiert Maßnahmen, um Risiken zu minimieren. Palo Alto Networks Cortex XDR Cortex wurde von Palo Alto ursprünglich als EDR-Tool vermarktet. Inzwischen wurde die Lösung allerdings zu einem XDR-Produkt erweitert. Die Palo-Alto-Endpunktlösung deckt alle relevanten Betriebssysteme ab und integriert mit zahlreichen anderen Palo-Alto-Tools – etwa XSOAR. Auch diese Endpoint-Detection-and-Response-Lösung deckt automatisch Angriffsursachen und -sequenzen auf. Sie verspricht Anwendern außerdem, Fehlalarme zu reduzieren und damit der gefürchteten „Alert Fatigue“ ein Schnippchen zu schlagen. SentinelOne Singularity Diese cloudbasierte Plattform von SentinelOne kombiniert EDR-Funktionen mit Workload Protection und Identity Threat Detection. Sie funktioniert mit Android-, iOS-, Linux-, macOS- und Windows-Geräten, sowie Kubernetes-Instanzen. Die Singularity-Plattform verspricht darüber hinaus: optimierte Bedrohungserkennung, verkürzte Reaktionszeit bei Cybervorfällen sowie eine effektive Risikominimierung. Darauf zahlen unter anderem auch die transparente Ausgestaltung der Plattform, ihre performanten Analytics-Funktionen sowie automatisierte Reaktionsfähigkeiten ein. Zu guter Letzt ist die Endpoint-Lösung von SentinelOne auch noch einfach zu implementieren, skalierbar und mit einem benutzerfreundlichen Interface ausgestattet. Sophos XDR Diese Endpoint-Security-Lösung nutzt Telemetriedaten verschiedener Sophos- und Secureworks-Produkte und kombiniert diese mit weiteren Daten anderer, externer Tools. Im Ergebnis steht eine Software, die EDR- und XDR-Funktionalitäten zusammenbringt. Auch mit Blick auf die Integrationsfähigkeit überzeugt Sophos XDR. Das Tool integriert mit: Firewall-Produkten, Identity-Lösungen, Netzwerksicherheits-Tools, Productivity-Apps, E-Mail-Security-Lösungen, Backup- und Recovery-Software sowie Cloud-Instanzen. Mit seinen Generative-AI-Funktionen will Sophos XDR Security-Profis ermöglichen, Angreifer schneller zu neutralisieren. In Kombination mit dem Echtzeit-Schutz, der laufende Angriffe erkennt und automatisiert Abwehrmaßnahmen ergreift, steigt die Wahrscheinlichkeit, Cyberattacken abwehren zu können. Trend Micro Apex One Die Trend-Micro-Lösung Apex One ist in die Vision-One-Plattform des Sicherheitsanbieters integriert. Auch dieses Produkt bietet sowohl EDR- als auch XDR-Features und unterstützt Android, iOS, macOS und Windows. Linux-Systeme bleiben leider außen vor. Apex One verspricht, vor Zero-Day-Bedrohungen schützen zu können – und zwar mit Hilfe einer Kombination aus Antimalware-Techniken und virtuellem Patching. Ransomware, Malware und bösartige Skripte sollen so keine Chance mehr haben, Endpunkte heimzusuchen. Um Security-Tools von Drittanbietern zu integrieren, bietet die Trend-Micro-Lösung eine Vielzahl von APIs. 4 Fragen vor dem EDR-Investment Bevor Sie eine Kaufentscheidung in Sachen EDR treffen, sollten Sie sich, beziehungsweise dem Anbieter Ihrer Wahl einige Fragen stellen: Mit welchen anderen Sicherheits-Tools ist die Lösung integriert und wie wird das erreicht? Wie unterscheidet die betreffende Lösung zwischen verdächtigen und böswilligen Verhaltensmustern? Deckt die Software sämtliche relevanten Endpunkte ab und lässt sie sich auch auf größere Netzwerke skalieren? Wie gut identifiziert das Tool Fehlalarme? (fm) View the full article

SvetaZi | shutterstock.com Software im Bereich Endpoint Detection and Response (EDR) erfreut sich weiterhin steigender Beliebtheit – und wird mit zunehmender Reife immer effektiver. EDR-Lösungen bieten Realtime-Einblicke in die Endpunkt-Aktivitäten und ermöglichen es, Mobiltelefone, Workstations, Laptops, Server und andere Devices vor Cyberangriffen zu schützen. In diesem Kaufratgeber erfahren Sie: wie sich Endpoint Detection and Response definiert, welche Fähigkeiten EDR-Tools an Bord haben sollten, welche Anbieter und Lösung in Sachen Endpunkt-Sicherheit tonangebend sind, und welche konkreten Fragen vor einer Investition relevant sind. Endpoint Detection and Response erklärt EDR-Tools erfassen Verhaltensdaten aus diversen Endpunkt-Quellen. Dazu gehören herkömmliche Computing Devices wie Windows- oder Mac-Rechner genauso wie Peripherie- und IoT-Geräte, beispielsweise Drucker oder Controller. Um IT-Profis auf verdächtige Aktivitäten oder laufende Cyberangriffe aufmerksam zu machen, analysieren Endpoint-Security-Lösungen zudem auch Signale aus: Netzwerk-Traffic-Mustern, Cloud-Computing-Anwendungen und Systemprotokollen. Das deckt die “Detection-Seite” ab. Mit Blick auf die “Response-Seite” sind EDR-Lösungen auch in der Lage, Schaden zu begrenzen und zu beheben. Zum Beispiel, indem sie auffällige Devices isolieren oder problematische Netzwerksegmente mit einer Firewall absichern. Je nachdem, wie das jeweilige Tool funktioniert, können diese Prozesse mehr oder weniger manuellen Aufwand erfordern. Schwierig ist hingegen mittlerweile, EDR von anderen Detection-Produktkategorien zu unterscheiden. Das beste Beispiel ist Extended Detection and Response (XDR): Inzwischen haben viele EDR-Lösungen deutlich an Umfang und Funktionen zugelegt, was dazu geführt hat, dass sie teilweise zu XDR “umetikettiert” wurden. Das lässt die Grenzen zwischen den Kategorien immer weiter verschwimmen. Die zunehmende Verschmelzung von EDR und XDR ist mit Blick auf den Detection-Gesamtmarkt jedoch nur ein Aspekt. Die Produkte in diesem Bereich laufen unter anderem auch unter folgenden Bezeichnungen: Network Detection and Response (NDR), Managed Detection and Response (MDR), oder Application Detection and Response (ADR). Was EDR-Tools leisten sollten Folgende Funktionen sollte eine hochwertige Endpoint-Security-Lösung mitbringen: Fortschrittliche Threat-Detection-Funktionen: Effektive Endpoint-Detection-and-Response-Lösungen sind in der Lage, Events zu beobachten und in Echtzeit darauf zu reagieren. Sie sollten außerdem automatisch mit einer wachsenden Zahl von Netzwerken und Anwendungen skalieren können. Support für tiefgehende Untersuchungen: So können Security-Teams potenzielle Bedrohungen verstehen und möglichst zeitnah entsprechende Gegenmaßnahmen einleiten. Integrationsfähigkeit: EDR-Tools sollten sich mit diversen anderen Sicherheitslösungen integrieren lassen – etwa Firewalls, SIEM, SOAR und Incident-Response-Tools. Das ermöglicht Anwenderunternehmen, Bedrohungsinformationen über APIs und Konnektoren systemübergreifend zu teilen. Zentralisierte Management-Funktionen und Analytics-Dashboards: Um ausufernde Schulungen zu vermeiden und jederzeit den Überblick über den aktuellen Status aller Endpunkte im Unternehmen zu wahren, sollte EDR-Software eine zentrale Konsole und Datenanalysen bereitstellen. Lückenloser Support für die fünf wesentlichen Endpoint-Betriebssysteme: Windows-, macOS-, Android-, iOS- und Linux-Devices sollten im Idealfall abgedeckt sein. Die 6 wichtigsten Endpoint-Security-Lösungen Der Endpoint-Detection-and-Response-Markt hält unzählige Lösungen diverser Anbieter bereit. Um Sie nicht zu erschlagen, stellen wir Ihnen an dieser Stelle sechs bewährte und empfehlenswerte Lösungen namhafter Anbieter vor. CrowdStrike Falcon Insight EDR Die Crowdstrike-Lösung kombiniert XDR- und EDR-Funktionen und soll (Advanced) Threats auf Android-, Chrome-OS-, iOS-, Linux-, macOS- und Windows-Geräten automatisch identifizieren und priorisieren. Zudem stellt Falcon Insight EDR Echtzeit-Response-Funktionalitäten zur Verfügung, um auf Endpunkte zuzugreifen, während sie untersucht werden. Um schadhafte Aktivitäten automatisch zu identifizieren und zu klassifizieren, nutzt die Crowdstrike-Software KI-gestützte Angriffsindikatoren. Die automatisierte Alert-Priorisierung verspricht, manuelle Suchen und zeitaufwändige Recherche-Arbeiten überflüssig zu machen. Dank der integrierten Threat-Intelligence-Funktion kommt auch der übergeordnete Kontext von Cyberangriffen nicht zu kurz – inklusive Attribution. Microsoft Defender for Endpoint Ransomware, Fileless Malware und weitere raffinierte Angriffsmethoden verspricht Microsoft mit Defender for Endpoint den Wind aus den Segeln zu nehmen. Das Tool funktioniert auf Android, iOS, Linux, macOS und Windows. Die integrierten Threat-Analytics-Reportings sollen Unternehmen in die Lage versetzen: sich schnell einen Überblick über neu aufkommende Bedrohungen verschaffen zu können; ihre Gefährdungslage evaluieren zu können; sowie geeignete Gegenmaßnahmen zu definieren. Darüber hinaus überwacht Defender for Endpoint die Sicherheitskonfigurationen von Microsoft- und Drittanbieter-Produkten. Sollte die Software fündig werden, ergreift sie automatisiert Maßnahmen, um Risiken zu minimieren. Palo Alto Networks Cortex XDR Cortex wurde von Palo Alto ursprünglich als EDR-Tool vermarktet. Inzwischen wurde die Lösung allerdings zu einem XDR-Produkt erweitert. Die Palo-Alto-Endpunktlösung deckt alle relevanten Betriebssysteme ab und integriert mit zahlreichen anderen Palo-Alto-Tools – etwa XSOAR. Auch diese Endpoint-Detection-and-Response-Lösung deckt automatisch Angriffsursachen und -sequenzen auf. Sie verspricht Anwendern außerdem, Fehlalarme zu reduzieren und damit der gefürchteten „Alert Fatigue“ ein Schnippchen zu schlagen. SentinelOne Singularity Diese cloudbasierte Plattform von SentinelOne kombiniert EDR-Funktionen mit Workload Protection und Identity Threat Detection. Sie funktioniert mit Android-, iOS-, Linux-, macOS- und Windows-Geräten, sowie Kubernetes-Instanzen. Die Singularity-Plattform verspricht darüber hinaus: optimierte Bedrohungserkennung, verkürzte Reaktionszeit bei Cybervorfällen sowie eine effektive Risikominimierung. Darauf zahlen unter anderem auch die transparente Ausgestaltung der Plattform, ihre performanten Analytics-Funktionen sowie automatisierte Reaktionsfähigkeiten ein. Zu guter Letzt ist die Endpoint-Lösung von SentinelOne auch noch einfach zu implementieren, skalierbar und mit einem benutzerfreundlichen Interface ausgestattet. Sophos XDR Diese Endpoint-Security-Lösung nutzt Telemetriedaten verschiedener Sophos- und Secureworks-Produkte und kombiniert diese mit weiteren Daten anderer, externer Tools. Im Ergebnis steht eine Software, die EDR- und XDR-Funktionalitäten zusammenbringt. Auch mit Blick auf die Integrationsfähigkeit überzeugt Sophos XDR. Das Tool integriert mit: Firewall-Produkten, Identity-Lösungen, Netzwerksicherheits-Tools, Productivity-Apps, E-Mail-Security-Lösungen, Backup- und Recovery-Software sowie Cloud-Instanzen. Mit seinen Generative-AI-Funktionen will Sophos XDR Security-Profis ermöglichen, Angreifer schneller zu neutralisieren. In Kombination mit dem Echtzeit-Schutz, der laufende Angriffe erkennt und automatisiert Abwehrmaßnahmen ergreift, steigt die Wahrscheinlichkeit, Cyberattacken abwehren zu können. Trend Micro Apex One Die Trend-Micro-Lösung Apex One ist in die Vision-One-Plattform des Sicherheitsanbieters integriert. Auch dieses Produkt bietet sowohl EDR- als auch XDR-Features und unterstützt Android, iOS, macOS und Windows. Linux-Systeme bleiben leider außen vor. Apex One verspricht, vor Zero-Day-Bedrohungen schützen zu können – und zwar mit Hilfe einer Kombination aus Antimalware-Techniken und virtuellem Patching. Ransomware, Malware und bösartige Skripte sollen so keine Chance mehr haben, Endpunkte heimzusuchen. Um Security-Tools von Drittanbietern zu integrieren, bietet die Trend-Micro-Lösung eine Vielzahl von APIs. 4 Fragen vor dem EDR-Investment Bevor Sie eine Kaufentscheidung in Sachen EDR treffen, sollten Sie sich, beziehungsweise dem Anbieter Ihrer Wahl einige Fragen stellen: Mit welchen anderen Sicherheits-Tools ist die Lösung integriert und wie wird das erreicht? Wie unterscheidet die betreffende Lösung zwischen verdächtigen und böswilligen Verhaltensmustern? Deckt die Software sämtliche relevanten Endpunkte ab und lässt sie sich auch auf größere Netzwerke skalieren? Wie gut identifiziert das Tool Fehlalarme? (fm) View the full article

An administrative role meant for AI agents within Microsoft’s Entra ID ecosystem could allow privilege escalation and tenant takeover attacks, as it had privileges over more than agent-related objects. Researchers at Silverfort found that users assigned to Microsoft’s “Agent ID Administrator” role, scoped to agent-related objects like blueprints and agent identities, could take ownership of unrelated service principals across the tenant. These users could then attach credentials and authenticate as those applications (unrelated services) to potentially manipulate app-to-app communication inside enterprise environments. “Prior to the fix, the Agent ID Administrator role allowed assigning ownership over service principals beyond agent-related identities, effectively enabling similar capabilities to roles such as Application Administrator, but without being scoped specifically to agent use cases,” Silverfort researchers said in a blog post. Microsoft has reportedly patched the issue across all cloud environments, blocking the role from modifying non-agent service principals. The cloud giant did not immediately respond to CSO’s request for comments. Agent-only briefly meant everything The problem was a failure in scope enforcement within a new agent identity security offering. Introduced as part of Microsoft’s push to operationalize AI agents through its Agent Identity Platform, the Agent ID Administrator role is an effort to give autonomous agents their own governed identities inside Entra ID. The role was designed to operate within a newly introduced set of objects tied to AI agents. However, because agent identities are ultimately built on the same primitives as applications, namely service principals, the boundary between “agent” and “non-agent” objects was not properly defined. This architectural confusion could allow role holders to add themselves as owners of a wide range of service principals across the tenant. But the same action was blocked for application objects, suggesting the flaw was specific to the service principal layer rather than the broader identity model. Application object and service principal are two related objects created every time an application is registered in Microsoft Entra ID. “The application object serves as the global definition of the app and describes its configuration,” the researchers explained. “The service principal represents the app as an identity within a tenant and is the object that authenticates, is assigned roles and permissions, and accesses resources.” The lack of definition allowed privilege expansion, allowing the role to mimic capabilities of a higher-privileged role like an Application Administrator. This was happening by default and did not trigger any alarm, the researchers noted. From principal ownership to full takeover Once ownership of a service principal was obtained, the attacker could generate new credentials like client secrets or certificates, and use them to authenticate as the compromised application. If the application held elevated directory roles or sensitive API permissions, the attackers could inherit those privileges. “The impact depends on the privileges assigned to the targeted service principal,” the researchers said. “In environments where service principals are widely used or hold elevated permissions, this can lead to significant escalation. Tenant posture can further influence the impact, for example in cases of broadly consented applications or permissive configurations.” The researchers noted that Agent ID Administrator is fairly new and isn’t in wide use yet, but the service principal-based escalation path is. “About 99% of tenants have at least one privileged service principal (not necessarily agent-related),” they said. Of them, more than half use agent identities averaging around 100 per tenant, creating a “real risk.” Microsoft Security Response Center (MSRC) told Silverfort that an internal fix was fully rolled out by April 9, 2026, requiring no further user action. Researchers still published a few recommendations along with detection steps to help users identify and respond to similar patterns. View the full article

Artificial intelligence tools are revamping DevSecOps processes, enabling security and development teams to more effectively build safeguards into software products from the get-go. But AI’s impact on DevSecOps goes well beyond tooling and processes, altering the scope, skills, and strategies foundational to the discipline as well. “AI is fundamentally shifting DevSecOps from reactive validation to continuous, intelligent enforcement,” says Siddardha Vangala, senior AI engineer and AI systems architect at engineering and construction company MasTec. “In enterprise environments, the biggest gains are coming from automation that operates alongside development workflows rather than after deployment.” Revamping DevSecOps processes AI is reshaping DevSecOps first and foremost by embedding security earlier in development and improving how issues are detected and remediated, says Katie Norton, a research manager for IDC’s DevSecOps and software supply chain security research practice. Its impact on DevSecOps processes breaks down into three main areas, Norton says. The first is AI-assisted secure coding. “One of the clearest changes is the integration of third-party security tooling into coding assistants and agents,” she says. “Rather than assuming AI-generated code is secure by default, organizations are increasingly embedding security controls into the generation workflow itself.” These controls provide policy guidance, secure coding patterns, validation checks, secrets detection, and approved dependency or configuration recommendations while code is produced, Norton says. As a result, security’s position within the development lifecycle is changing. “Security is no longer interacting only with the developer after or alongside code creation,” Norton says. “It is increasingly interacting with the agent that is generating the code. That changes DevSecOps in a practical way. Security controls are moving closer to the point of generation, and [application security] teams are beginning to govern the behavior of AI systems, not just the behavior of human developers.” The second area is large language model (LLM) vulnerability scanning. “LLMs are increasingly used to analyze code, configurations, and APIs for vulnerabilities, using contextual reasoning rather than fixed rules,” Norton says. “This allows them to identify logic flaws and insecure usage patterns that traditional scanners often miss. This expands detection coverage, particularly in complex or modern application architectures.” At the same time, scanning itself is evolving, Norton says, becoming more autonomous and in some cases capable of initiating analysis, confirming findings, and integrating more directly into development workflows without requiring explicit human activities. A third area is automated remediation suggestions and execution. “AI is increasingly used to generate fixes for vulnerabilities, including code changes, dependency updates, and configuration adjustments,” Norton notes. “These suggestions are often integrated directly into developer workflows, such as pull requests or IDEs [integrated development environments]. This reduces mean time to remediation and lowers the expertise required to resolve issues.” The overall impact of AI on DevSecOps processes is that it’s collapsing the distance between writing code, finding vulnerabilities, and fixing them. “That makes DevSecOps more continuous, but also more machine-mediated,” Norton says. “The key challenge now becomes validating machine-generated code, machine-identified findings, and machine-suggested remediation across a development lifecycle.” Explicit security requirements elevate AI benefits While deploying AI with DevSecOps is helping to shift the emphasis on security to earlier in the development lifecycle, this requires “explicit instruction to do it right,” says Noe Ramos, vice president of AI operations at business software provider Agiloft. “AI coding assistants accelerate development meaningfully, but they optimize for functional code by default, not secure enterprise code,” Ramos says. “Those aren’t the same target. We’ve had to build explicit security requirements into our AI coding prompts and project-level instructions — input validation, secrets management, least privilege, vulnerability patterns — because if you don’t specify it, it won’t reliably appear.” Once that instruction layer is in place, “it applies consistently at scale in a way human developers working under deadline pressure don’t,” Ramos says. AI tools are increasingly useful for flagging dependency vulnerabilities, identifying common vulnerability patterns, and suggesting remediation, tasks that previously required dedicated security review cycles, Ramos says. “This is compressing the feedback loop between writing code and catching security issues,” she says. AI has improved the ability of teams to prioritize vulnerabilities. “Too much noise has been a long-standing problem in the DevSecOps space,” says Monika Malik, lead data/AI software engineer at communications provider AT&T. “Too many findings are generated with little context provided to make informed decisions.” AI tools provide value by correlating multiple types of findings across code, dependencies, configurations, and runtime behaviors, Malik says. “This allows teams to then focus on those items that represent actual exploits or operationally impactful issues,” she says. “Teams are no longer treating all scanner results as equal.” For example, AI-assisted analysis identifies actual exposures related to public-facing services, privileged workloads, or sensitive data, Malik says. “This enables teams focused on security engineering [to] spend time addressing relevant issues,” she says. Transforming DevSecOps as a discipline Given the impact AI is having in transforming DevSecOps on a larger scale, IT, security, and development leaders need to be on top of what changes when AI is introduced into development strategies. “Historically, DevSecOps has been centered on application code security, infrastructure security, and software supply chain security,” Malik says. “With the introduction of AI, the scope of concern has expanded significantly. DevSecOps can no longer simply address source code security, container security, pipeline security, and cloud infrastructure security.” Additional concerns now include model access exposure, prompt abuse/injection risks, sensitive data leakage, data lineage, third-party models and API dependencies, deployment of AI-generated code, and others, Malik says. Strategic impact and challenges “From a strategic standpoint, AI is leading DevSecOps towards a more risk-based operating model,” Malik says. “The mature strategy will be to apply different levels of scrutiny to different use cases. Teams will increasingly separate low-risk internal productivity use cases from high-risk use cases based upon customer-facing decisions, regulated data usage, authentication flows, privileged operations, etc.” Agiloft is treating AI coding governance not as a DevSecOps-specific problem, “but as an enterprise governance problem with a DevSecOps component,” Agiloft’s Ramos says. That means cross-functional alignment among security, IT, AI operations, engineering, legal, and others, rather than expecting DevSecOps to absorb the entire new surface area alone, she says. “The organizations that will get this right are the ones building governance infrastructure now, before the incidents force it,” Ramos says. Traditional DevSecOps processes assumed human authorship of code, Ramos says. “AI authorship creates new questions: Who is accountable for AI-generated code that passes review and later causes a breach?” she says. “How do you track provenance? How do you handle the reality that developers are copy-pasting AI-generated code from consumer tools into enterprise codebases, potentially carrying licensing, security, or compliance baggage with it?” New threat vectors arise New threats are emerging, many of which stem from the growing use of AI. “DevSecOps now has to cover a new attack surface it didn’t exist to address,” Ramos says. “AI models themselves, the prompts sent to them, the data used to fine-tune them, the outputs fed into production systems, are all threat vectors. That’s a material scope expansion on top of an already stretched discipline.” DevSecOps is expanding beyond application and cloud security to include AI systems as “first-class” assets, IDC’s Norton says. “This includes securing models, training data, prompts, and inference pipelines, as well as addressing new attack vectors such as prompt injection, data leakage, and model manipulation,” she adds. At a strategic level, “organizations are shifting from controlling developer behavior alone to governing AI-assisted development as a system,” Norton says. “This includes standardizing approved tools, defining usage policies, and embedding security controls into developer environments and AI systems.” Application security teams are increasingly responsible for shaping how code is generated, by influencing the behavior of AI systems rather than relying solely on downstream detection and remediation, Norton says. Skill sets evolve AI’s infusion into DevSecOps will have a big impact on skills. “Security and engineering teams need a broader skill set that includes understanding how AI systems behave, how data flows through them, and where they introduce risk,” Norton says. There is a shift away from developers needing to be deeply knowledgeable about how to write secure code themselves, as more of that responsibility is mediated through AI systems and embedded controls, Norton says. “Developers need to understand how to use AI coding tools responsibly, while [application security] teams need to define and implement guardrails that shape what AI systems produce,” she says. The DevSecOps practitioner “now needs enough AI literacy to evaluate risk in AI-assisted code, not just, ‘Does this code have a SQL injection risk?’ But, ‘Did an AI generate this in a way that introduced subtle logic errors or trained-in vulnerabilities?’” Ramos says. “That’s a different kind of code review skill, and most teams haven’t fully developed it yet.” Among the necessary skill sets for DevSecOps teams, Malik says, are AI threat modeling; the ability to investigate model and prompt abuse scenarios and ensure secure use of coding copilots; data governance and provenance; and knowing how to evaluate supply chain AI models and services. There is growing demand for engineers who understand both traditional security practices and AI-specific risks such as prompt injection, data leakage, and model misuse, Vangala says. “Teams increasingly need hybrid skills combining DevOps, application security, and AI system architecture,” he says. Automation in overdrive One of the biggest impacts of AI in any area is the rise in automation, and applying AI to DevSecOps will make automation increasingly common in the coming months. DevSecOps practices are becoming more machine-to-machine and more tightly looped, while also reinforcing separation of concerns, IDC’s Norton says. “Security teams are shaping how AI systems generate code through embedded guardrails, while independently scaling detection and remediation through automated workflows,” she says. The result is less reliance on manual, developer-mediated handoffs and more reliance on coordinated systems where code generation, analysis, and remediation occur through automated interactions, with humans focused on validation and oversight. “When developers generate code using AI assistants, automated validation checks flag insecure patterns such as unsafe API calls, improper authentication logic, or exposed secrets,” Vangala says. “This reduces the number of security issues reaching downstream testing environments.” Security logs are increasingly analyzed using AI models to identify anomalies and prioritize alerts, Vangala says. “Instead of manually reviewing large volumes of telemetry, automated systems highlight suspicious activity patterns and reduce alert fatigue by grouping related signals into actionable insights,” he says. View the full article

Every SOC analyst has heard it by now: “AI is coming for your job”. I hear it in conversations with SOC teams. I see it in the hesitation during evaluations. And increasingly, I feel it as a source of resistance — especially from the very people AI is supposed to help. But the reality is the opposite. Instead of eliminating the Tier 1 analyst role, AI is elevating it — from a job defined by repetitive tasks to one defined by judgment, oversight and decision-making. In short, it makes them more powerful as SOC commanders. The work was never the point To understand what’s changing, we need to be honest about the historical role of Tier 1 analysts. In a typical SOC, a Tier 1 analyst might spend 20–30 minutes investigating a single phishing alert — pivoting across email logs, endpoint data and threat intelligence tools, validating signals and documenting findings. It’s necessary work, but it’s also highly repetitive and time-consuming. Modern security operations generate more data than humans can reasonably process. Investigating a single alert often requires pivoting across identity systems, endpoint telemetry, cloud logs and threat intelligence sources. Multiply that by hundreds or thousands of alerts per day, and you have a workload that is fundamentally misaligned with human capacity. More importantly, SOC analysts are too talented for this kind of non-human work. For years, we’ve accepted this as the cost of doing business. AI changes that equation. From doing the work to directing it What agentic AI introduces into the SOC is the ability to delegate. Instead of analysts manually gathering evidence and stitching together context, AI agents can now autonomously execute investigative steps: Querying systems, correlating signals and building evidence chains in real time. It doesn’t remove the human from the process. It elevates them within it. The emerging model is one where analysts manage a system of agents — each responsible for a piece of the investigation — rather than performing each step themselves. The human role shifts from operator to orchestrator. What I consistently hear from security leaders isn’t, “I need my analysts to move faster.” It’s, “I need my analysts to stop collecting data and start making decisions based on it.” Those are fundamentally different problems. And the gap between them is where AI creates the most value. The rise of the ‘manager of agents’ This is where the Tier 1 role evolves — not disappears. In this new model, entry-level analysts are effectively managing a swarm of AI agents. They are responsible for reviewing investigations, validating conclusions and ensuring actions align with business context and risk tolerance. They are not “in the loop” for every step. They are “on the loop” — overseeing outcomes rather than executing tasks. When analysts are forced to stay in the loop — checking every enrichment, every query, every intermediate step — they become a bottleneck. When they move on the loop, they can operate at scale, reviewing dozens or hundreds of investigations with the right level of oversight. This is how trust in AI is built: Not by asking humans to verify everything, but by giving them the visibility to verify anything. Transparency becomes the control plane. Analysts can see exactly what the AI did, how it reached a conclusion and where uncertainty exists. Over time, as accuracy proves out, they naturally increase their level of trust — just as they would with a new colleague joining the team. Why cybersecurity is different The fear of job displacement is understandable. In many industries, AI is reducing the need for entry-level roles. Cybersecurity is one of the few domains where AI won’t reduce work. It will expose how much work we’ve been unable to do. The volume and complexity of threats are increasing faster than teams can scale. Attackers are already using AI to automate reconnaissance, generate code and accelerate exploitation. Defenders don’t have the option to sit this out. Threat hunting, detection engineering and control optimization have historically been under-resourced because teams were consumed by alert triage. When AI removes that burden, it creates much-needed capacity for analysts to do what they were trained to do. The work doesn’t shrink. The right work finally gets done. A new baseline for entry-level talent This shift also changes what we expect from entry-level analysts. Historically, Tier 1 roles were designed as places where analysts learned by doing repetitive tasks. That model no longer makes sense when those tasks can be automated. The baseline is moving toward understanding how AI systems operate: Interpreting their outputs, questioning their reasoning and guiding their behavior. Human-centric skills become more important, not less. Curiosity, critical thinking and the ability to connect disparate signals into a coherent narrative — these are the differentiators in an AI-driven SOC. We’re already seeing organizations rethink how they hire for these roles. There is less emphasis on credentials and more on how someone thinks and solves problems. When AI handles the mechanics, judgment is the job. Building trust that holds If the future is so clear, why is there resistance? In most cases, it comes down to trust — and trust must be earned, not assumed. The deployments I’ve seen fail share a common pattern: Organizations treat AI as a binary shift from no automation to full autonomy. That’s not how security teams work, and it’s not how they should be asked to work. What works is a progression. Start with limited, high-confidence use cases. Provide full transparency into how the system reaches its conclusions. Let analysts validate outcomes before expanding the scope. And critically, put practitioners in the room. Not implementation consultants or project managers, but people who have run SOC shifts, triaged thousands of alerts and earned credibility the hard way. This is why, when we deploy, we bring former SOC leads, threat hunters and detection engineers to work directly alongside analyst teams. They’re not there to configure software. They’re there to build trust in the system — because they’ve already earned trust from the people using it. When analysts see that the people helping them deploy this technology have lived the same grind, the conversation changes. It stops being “will this replace me” and starts being “how do I use this well.” That shift in orientation — from threat to tool — is what separates a successful deployment from one that stalls. The trust gap isn’t a technology problem. It’s a human one. And it closes the same way trust always closes: Through demonstrated competence, shared context and time. The future SOC is human-led The end state here is not an autonomous SOC with no humans involved. It’s a human-led SOC, powered by AI. AI agents handle the labor-intensive, evidence-gathering aspects of security operations. Humans provide direction, oversight and accountability. Together, they operate at a speed and scale neither could achieve alone. That’s not a theory — it’s what’s happening in production environments today. Elevation, not elimination The narrative that AI will eliminate Tier 1 analysts misses the point. The role isn’t going away. It’s being redefined. The analysts who succeed in this new environment will be those who can manage intelligence systems, interpret complex outputs and make high-quality decisions under uncertainty. They won’t be replaced. They’ll be promoted. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

mikeledray | shutterstock.com Vor seinen MAGA- und DOGE-Eskapaden wurde Elon Musk in erster Linie als visionärer Entrepreneur wahrgenommen. Damals, im Jahr 2010, ließ er den Mitarbeitern seines Raumfahrtunternehmens SpaceX ein Memo zukommen. Darin kritisierte er den übermäßigen, internen Gebrauch von Abkürzungen in gewohnt ausdrucksstarkem Stil: “Bei SpaceX gibt es eine schleichende Tendenz, erfundene Akronyme zu nutzen. Geschieht das exzessiv, wird die Kommunikation erheblich beeinträchtigt […] Niemand kann sich diese Abkürzungen merken und manche Leute wollen in Meetings nicht dumm erscheinen und nehmen es einfach hin […] Das muss sofort aufhören, sonst werde ich drastische Maßnahmen ergreifen”, drohte Trumps ehemaliger Sidekick damals. Tatsächlich lässt sich nicht leugnen, dass der übermäßige Gebrauch von Akronymen ein erhebliches Hindernis für präzise Kommunikation darstellen kann – insbesondere in der Cybersicherheitsbranche, denn hier steht besonders viel auf dem Spiel. Wie Akronym-überladen die Security ist, veranschaulicht diese kuratierte Liste aller derzeit in Gebrauch befindlichen Security-Abkürzungen. Ein (kleiner) Auszug: BAS, CTI, DDoS, DLP, EDR, IAM, MDR, MSSP, SASE, SIEM, SOC, DevSecOps, SAST/DAST, MFA. Mag sein, dass Cybersicherheitsprofis und -entscheider mit jedem dieser Akronyme direkt etwas anfangen können. In vielen anderen Teilen der Belegschaft werden sie vermutlich vor allem für fragende Blicke sorgen – insbesondere bei den Menschen, die gerade neu ins Unternehmen kommen. In diesem Artikel werfen wir einen Blick darauf, wie Organisationen internen Buchstabenschlachten ein Ende bereiten können. Abkürzungsschäden Ian P. McCarthy, Professor für Innovations- und Betriebsmanagement an der kanadischen Simon Fraser University, erklärt, was es mit der Tendenz auf sich hat, komplexe Begrifflichkeiten zu kryptischen Kurzformen zu transformieren: “Einerseits werden Akronyme verwendet, um die Kommunikation kurz, standardisiert und effizient zu gestalten. Andererseits trägt Kommunikation auch dazu bei, die Identität und Exklusivität eines Berufs zu definieren.” Insofern sei es auch eine Form von Elitismus, Akronyme zu nutzen, so der Akademiker: “Das schränkt ein, wer zu dieser Berufsgemeinschaft zählen kann.” Tatsächlich erweckt es den Anschein, als ob die Tech-Branche Akronyme zur ultimativen Geheimwaffe erklärt hat. Die kommt aber nicht nur zum Einsatz, um Zeit zu sparen, sondern auch um einen exklusiven “Club” zu etablieren. Das ist für die “Nicht-Mitglieder” nicht nur frustrierend, sondern kann auch Einarbeitungszeiten verlängern und potenzielle, neue Mitarbeiter abschrecken. Stichwort: Diversity. Die Nachteile exzessiver Akronym-Angewohnheiten im Überblick: Zugangsbarrieren: Stellen Sie sich einen neuen Mitarbeiter vor, der versucht, Cybersecurity-Protokolle zu verstehen, dabei aber von Tausenden unbekannter Abkürzungen erschlagen wird. Was ursprünglich dazu gedacht war, Brancheninsidern eine schnelle Kommunikation zu ermöglichen, wird so schnell zum Abschreckungs- und Erlahmungsfaktor. Doppel- und Mehrdeutigkeiten: Je nach Kontext können Abkürzungen manchmal mehrere Bedeutungen haben – wie im Fall von APT (Advanced Persistent Threat vs. Advanced Packaging Tool). Das kann unter Umständen zu Missverständnissen in wichtigen Mitteilungen führen und begünstigt damit potenziell Sicherheitslücken. Akronym-Müdigkeit: Nicht nur neue Mitarbeiter können von übermäßig verwendeten Abkürzungen überfordert werden. Auch versierte Cybersicherheitsexperten können einer „Acronym Fatigue“ erliegen – einfach, weil es viel zu viele Abkürzungen gibt und es unmöglich ist, auch noch mit allen neuen Entwicklungen Schritt zu halten. Die sind aber besonders im Bereich IT-Sicherheit wichtig. Transparenzverlust: Da Cybersecurity eine immer wichtigere Rolle im täglichen Leben einnimmt, ist es essenziell, grundlegende Sicherheitskonzepte allgemeinverständlich zu kommunizieren. Dabei können Akronyme unkundige Benutzer oft mehr verwirren, als für Klarheit zu sorgen. Akronymabhilfe Natürlich gibt es je nach Organisation Unterschiede mit Blick darauf, wie mit Akronymen umgegangen wird. Eine allgemeine Faustregel könnte beispielsweise darstellen, ausschließlich diejenigen zu verwenden, die innerhalb der Organisation bekannt sind. Abkürzungen, die nicht in einem Gespräch verwendet werden, sollten bei schriftlicher Kommunikation auf jeden Fall vermieden, beziehungsweise ausgeschrieben werden – zumindest bei der ersten Erwähnung. Keine Lösung ist es hingegen, auf Abkürzungen ganz generell zu verzichten. Stattdessen empfiehlt es sich, sie maßvoll einzusetzen und mit dem zugehörigen Kontext auszustatten. Die folgenden vier Ansätze können Unternehmen und Organisationen dabei unterstützen, das umzusetzen. Glossare: Standardisierte Glossare mit häufig verwendeten Akronymen erleichtern nicht nur Neueinsteigern, sich mit den wichtigsten, relevanten Begrifflichkeiten vertraut zu machen. Einfache Erklärungen: Kurze Erklärungen oder Definitionen, die bei weniger gebräuchlichen Akronymen eingeblendet werden, sind in Dokumentationen und journalistischen Fachartikeln bereits üblich. Dieser Ansatz ließe sich auch auf Präsentationen, Meetings und E-Mails ausweiten. Unnötiges vermeiden: Nicht jeder Begriff braucht ein Akronym, In manchen Fällen kann einfache Sprache, die kryptische Begriffe umschreibt, die bessere Wahl sein. Schulungen: Regelmäßige Trainingseinheiten zu neuen und bestehenden Terminologien können dazu beitragen, die gesamte Belegschaft einer Organisation auf dem aktuellen Stand zu halten, ohne dabei Einzelne zu überfordern. Laut dem Dramatiker George Bernard Shaw ist das größte Hindernis der Kommunikation die Illusion, dass sie stattgefunden hat. Exzessiv mit Akronymen um sich zu werfen, trägt dazu bei, dieses Trugbild zu erzeugen. Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

mikeledray | shutterstock.com Vor seinen MAGA- und DOGE-Eskapaden wurde Elon Musk in erster Linie als visionärer Entrepreneur wahrgenommen. Damals, im Jahr 2010, ließ er den Mitarbeitern seines Raumfahrtunternehmens SpaceX ein Memo zukommen. Darin kritisierte er den übermäßigen, internen Gebrauch von Abkürzungen in gewohnt ausdrucksstarkem Stil: “Bei SpaceX gibt es eine schleichende Tendenz, erfundene Akronyme zu nutzen. Geschieht das exzessiv, wird die Kommunikation erheblich beeinträchtigt […] Niemand kann sich diese Abkürzungen merken und manche Leute wollen in Meetings nicht dumm erscheinen und nehmen es einfach hin […] Das muss sofort aufhören, sonst werde ich drastische Maßnahmen ergreifen”, drohte Trumps ehemaliger Sidekick damals. Tatsächlich lässt sich nicht leugnen, dass der übermäßige Gebrauch von Akronymen ein erhebliches Hindernis für präzise Kommunikation darstellen kann – insbesondere in der Cybersicherheitsbranche, denn hier steht besonders viel auf dem Spiel. Wie Akronym-überladen die Security ist, veranschaulicht diese kuratierte Liste aller derzeit in Gebrauch befindlichen Security-Abkürzungen. Ein (kleiner) Auszug: BAS, CTI, DDoS, DLP, EDR, IAM, MDR, MSSP, SASE, SIEM, SOC, DevSecOps, SAST/DAST, MFA. Mag sein, dass Cybersicherheitsprofis und -entscheider mit jedem dieser Akronyme direkt etwas anfangen können. In vielen anderen Teilen der Belegschaft werden sie vermutlich vor allem für fragende Blicke sorgen – insbesondere bei den Menschen, die gerade neu ins Unternehmen kommen. In diesem Artikel werfen wir einen Blick darauf, wie Organisationen internen Buchstabenschlachten ein Ende bereiten können. Abkürzungsschäden Ian P. McCarthy, Professor für Innovations- und Betriebsmanagement an der kanadischen Simon Fraser University, erklärt, was es mit der Tendenz auf sich hat, komplexe Begrifflichkeiten zu kryptischen Kurzformen zu transformieren: “Einerseits werden Akronyme verwendet, um die Kommunikation kurz, standardisiert und effizient zu gestalten. Andererseits trägt Kommunikation auch dazu bei, die Identität und Exklusivität eines Berufs zu definieren.” Insofern sei es auch eine Form von Elitismus, Akronyme zu nutzen, so der Akademiker: “Das schränkt ein, wer zu dieser Berufsgemeinschaft zählen kann.” Tatsächlich erweckt es den Anschein, als ob die Tech-Branche Akronyme zur ultimativen Geheimwaffe erklärt hat. Die kommt aber nicht nur zum Einsatz, um Zeit zu sparen, sondern auch um einen exklusiven “Club” zu etablieren. Das ist für die “Nicht-Mitglieder” nicht nur frustrierend, sondern kann auch Einarbeitungszeiten verlängern und potenzielle, neue Mitarbeiter abschrecken. Stichwort: Diversity. Die Nachteile exzessiver Akronym-Angewohnheiten im Überblick: Zugangsbarrieren: Stellen Sie sich einen neuen Mitarbeiter vor, der versucht, Cybersecurity-Protokolle zu verstehen, dabei aber von Tausenden unbekannter Abkürzungen erschlagen wird. Was ursprünglich dazu gedacht war, Brancheninsidern eine schnelle Kommunikation zu ermöglichen, wird so schnell zum Abschreckungs- und Erlahmungsfaktor. Doppel- und Mehrdeutigkeiten: Je nach Kontext können Abkürzungen manchmal mehrere Bedeutungen haben – wie im Fall von APT (Advanced Persistent Threat vs. Advanced Packaging Tool). Das kann unter Umständen zu Missverständnissen in wichtigen Mitteilungen führen und begünstigt damit potenziell Sicherheitslücken. Akronym-Müdigkeit: Nicht nur neue Mitarbeiter können von übermäßig verwendeten Abkürzungen überfordert werden. Auch versierte Cybersicherheitsexperten können einer „Acronym Fatigue“ erliegen – einfach, weil es viel zu viele Abkürzungen gibt und es unmöglich ist, auch noch mit allen neuen Entwicklungen Schritt zu halten. Die sind aber besonders im Bereich IT-Sicherheit wichtig. Transparenzverlust: Da Cybersecurity eine immer wichtigere Rolle im täglichen Leben einnimmt, ist es essenziell, grundlegende Sicherheitskonzepte allgemeinverständlich zu kommunizieren. Dabei können Akronyme unkundige Benutzer oft mehr verwirren, als für Klarheit zu sorgen. Akronymabhilfe Natürlich gibt es je nach Organisation Unterschiede mit Blick darauf, wie mit Akronymen umgegangen wird. Eine allgemeine Faustregel könnte beispielsweise darstellen, ausschließlich diejenigen zu verwenden, die innerhalb der Organisation bekannt sind. Abkürzungen, die nicht in einem Gespräch verwendet werden, sollten bei schriftlicher Kommunikation auf jeden Fall vermieden, beziehungsweise ausgeschrieben werden – zumindest bei der ersten Erwähnung. Keine Lösung ist es hingegen, auf Abkürzungen ganz generell zu verzichten. Stattdessen empfiehlt es sich, sie maßvoll einzusetzen und mit dem zugehörigen Kontext auszustatten. Die folgenden vier Ansätze können Unternehmen und Organisationen dabei unterstützen, das umzusetzen. Glossare: Standardisierte Glossare mit häufig verwendeten Akronymen erleichtern nicht nur Neueinsteigern, sich mit den wichtigsten, relevanten Begrifflichkeiten vertraut zu machen. Einfache Erklärungen: Kurze Erklärungen oder Definitionen, die bei weniger gebräuchlichen Akronymen eingeblendet werden, sind in Dokumentationen und journalistischen Fachartikeln bereits üblich. Dieser Ansatz ließe sich auch auf Präsentationen, Meetings und E-Mails ausweiten. Unnötiges vermeiden: Nicht jeder Begriff braucht ein Akronym, In manchen Fällen kann einfache Sprache, die kryptische Begriffe umschreibt, die bessere Wahl sein. Schulungen: Regelmäßige Trainingseinheiten zu neuen und bestehenden Terminologien können dazu beitragen, die gesamte Belegschaft einer Organisation auf dem aktuellen Stand zu halten, ohne dabei Einzelne zu überfordern. Laut dem Dramatiker George Bernard Shaw ist das größte Hindernis der Kommunikation die Illusion, dass sie stattgefunden hat. Exzessiv mit Akronymen um sich zu werfen, trägt dazu bei, dieses Trugbild zu erzeugen. Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. View the full article

US House Republicans have introduced two major privacy proposals that would reshape how US companies collect, process, and retain consumer data: the SECURE Data Act for general consumer privacy and the GUARD Financial Data Act for financial institutions. The bills would create national standards for privacy and security practices while broadly preempting many state privacy laws, including the stronger protections already in place in states like California and Maryland. They also would eliminate the possibility of private lawsuits under the federal framework, leaving enforcement primarily to the Federal Trade Commission and state attorneys general. That combination of federal preemption, weaker enforcement, and broad compliance changes has made the bills politically toxic for Democrats and privacy advocates alike. The Electronic Privacy Information Center (EPIC) called the SECURE Data Act “a huge gift to Big Tech” and warned that “a weak federal standard is worse than no standard at all.” Congress has spent more than a decade failing to produce a comprehensive federal privacy law, often under less polarized conditions than today. “Support from one party in a single house of Congress is not going to do it,” said Alan Butler, executive director and president of EPIC. “It takes a bipartisan process, actually, to pass substantive legislation like this.” The bills matter because they expose the privacy issues enterprises are already being forced to confront under existing state laws and federal guidance, including data minimization, automated profiling, data broker accountability, and increasingly complex rules around sensitive data. Why data minimization is becoming a business issue The SECURE Data Act includes familiar privacy rights: access, correction, deletion, portability, opt-outs for targeted advertising and data sales, and restrictions on certain forms of automated profiling. It also creates a federal data broker registry and formal controller-processor obligations for companies and vendors. The most consequential operational issue for enterprises, however, is data minimization, the increasingly accepted principle that companies should collect only what they need, retain it only as long as necessary, and be able to justify both decisions. The National Institute of Standards and Technology (NIST) already treats minimization as a core privacy and security principle. In its “Collection and Data Minimization” guidance, the agency says organizations should collect only the personal information necessary for a stated purpose, because excess retention creates avoidable privacy and security risks That principle is increasingly central to state privacy laws as well. California and Maryland both impose stronger restrictions on unnecessary collection and retention than many earlier state frameworks. For CIOs, CISOs, and CFOs, this is not simply a privacy-notice issue. Dormant customer records, excessive telemetry, forgotten SaaS archives, oversized AI training datasets, and legacy marketing databases all increase breach exposure. The more unnecessary data a company stores, the larger its attack surface becomes. Butler argues the SECURE bill’s own minimization language is weaker than what leading states already require. “The answer is that the law doesn’t really do anything,” he said, because the provision largely ties collection limits to what companies disclose in their privacy policy rather than imposing a stronger necessity standard. That creates an unusual enterprise dynamic: the bill could weaken privacy protections overall while still reinforcing the long-term expectation that companies must be able to justify why they keep the data they have. Where privacy law overlaps with AI governance The SECURE Data Act does not contain broad, standalone AI governance rules, but it still touches AI in meaningful ways. The bill includes opt-outs for fully automated profiling used for decisions with legal or similarly significant effects. That language can clearly implicate some uses of AI, particularly in hiring, lending, insurance, and other high-impact decisions. Butler said that the profiling provision is worth watching, because several state laws already include similar requirements, and the concept is expanding. That means privacy law may become the first practical form of AI regulation for many enterprises. Training datasets, customer prompts, telemetry collection, and retention periods all become harder to defend when regulators ask whether the data is truly necessary. Legal teams, privacy officers, and CISOs may find themselves shaping AI strategy well before Congress passes a standalone AI law. The teen-data provision that could break everything One of the least-discussed but most disruptive provisions in the SECURE Data Act involves teens. It states that a controller, namely any entity that is processing personal data, may not process the sensitive data of a teen without obtaining verifiable parental consent. The problem is that the bill defines sensitive data to include personal data collected from a teen, meaning almost any interaction involving a known user between 13 and 15 years old could trigger the requirement. “If you operate a website, an app, a service, and there are users you know who are between 13 and 15, it’s going to break everything,” Butler said. “You’re going to have to get verifiable parental consent every time you touch the data—collect it, transfer it, store it, process it, anything.” To comply, companies would need not only age awareness, which many already have through account creation or app stores, but also a system for verifying parent-child relationships. That would likely require collecting additional sensitive identity documents and personal records, the exact kind of information most organizations should try to avoid storing. “It doesn’t work. It doesn’t make sense,” Butler said. “If I were a CIO or CISO, I would be very concerned, because it is completely unworkable.” Why vendors and data brokers matter more The SECURE bill requires formal controller-processor contracts covering confidentiality, deletion, retention limits, subcontractor obligations, and other safeguards. That pushes privacy compliance directly into procurement and third-party risk management. For companies with inherited vendors from acquisitions and unclear data ownership, privacy compliance becomes an exercise in figuring out who has what data, where it sits, and whether anyone can actually force its deletion. Butler points to the federal data broker registry as one of the few provisions in the bill that clearly reflects where privacy law is already moving. More states are adopting registry requirements, and businesses increasingly have to evaluate what data they buy, where it came from, and whether they qualify as brokers themselves. Why financial firms should watch GUARD more closely While the SECURE Data Act affects far more enterprises, the companion GUARD Financial Data Act may matter more for banks, insurers, and fintechs. Rather than creating an entirely new framework, GUARD would significantly modernize Title V of the Gramm-Leach-Bliley Act (GLBA). It would preserve consumer opt-out rights while expanding access rights, adding former-customer deletion rights, requiring affirmative opt-in consent before disclosure of sensitive personal information, and imposing stronger obligations around financial data aggregators and access credentials. It also includes provisions around data processing involving “covered nations,” tying financial privacy more directly to national security and supply chain concerns. For institutions that still treat GLBA privacy notices as an annual compliance exercise, GUARD would turn privacy into a daily operational issue, touching open banking, credential handling, vendor relationships, and retention practices for former customers. A federal law may not be the best for business Business groups have long wanted a single national standard to replace the state-by-state patchwork of privacy laws. One federal framework is easier to govern than 20 competing ones, and many companies would welcome the predictability. Brendan Thomas, executive director of the Internet for Growth coalition, praises the SECURE Data Act for providing a federal framework against the patchwork of state laws, which the coalition says is driving up prices for small businesses. “The introduction of the SECURE Data Act (H.R. 8413) in the House is an important step in the ongoing effort to establish a national privacy framework,” Thomas said in a statement. But EPIC’s Butler argues that wiping away stronger state laws may not actually be good for business. He says that companies have already invested heavily in compliance programs around those frameworks, and replacing them with weaker, vaguer federal rules could create new uncertainty rather than less. “It breeds distrust among your customers,” Butler said. “It’s not good for business for people to mistrust what’s happening with these apps. All of a sudden, [consumers] don’t feel like their privacy is protected anymore.” View the full article

Another member of the notorious Scattered Spider gang of cyber criminals has pleaded guilty in a US court, and will be sentenced later this year. Tyler Buchanan pleaded guilty in a Florida court to conspiring with others to hack into companies’ computer systems with the intent of stealing at least $8 million in virtual currency. He faces up to Other members of the gang have already been arrested: In 2024, a British national was picked up in Spain while, in the same year, another was charged in Florida. However, there are members of the Scattered Spider group still active: last year it branched out and attacked a number of other businesses, including Marks and Spencer, Co-op and Harrods – although there were other arrests following these attacks. The group works by sending SMS phishing attacks to the mobile phones of employees of its targets. The messages purport to come from suppliers to those companies but contain links to websites set up by group members, allowing them to steal information from the employees. However, last year the cyber criminals revealed a new line of attack — pretending to be fellow employees of the victims, tricking help desks to reveal more personal information. Despite the arrests, CISOs are being advised to be on alert against such attacks and take appropriate measures to guard against them. View the full article

The US Cybersecurity and Infrastructure Security Agency (CISA) does not yet have access to Anthropic’s bug-hunting AI model, Claude Mythos, even though other government agencies do, Axios reported earlier this week. As if that weren’t a big enough slap in the face for the national cyber-defense agency, the list of those who do have access to Mythos includes several unauthorized users, according to Bloomberg News. Members of a private Discord channel specializing in seeking information about unreleased AI models, have gained access to Mythos, according to one unnamed member of the group, Bloomberg reported. “The group has been using Mythos regularly since then, though not for cybersecurity purposes,” the person told Bloomberg, supplying screenshots to back up their claim. As a result of its fear that the powerful model could be used to identify and exploit flaws in software and online services, Anthropic has limited access to a preview of Mythos to an exclusive group of government agencies, industry groups, and software providers through an initiative it calls Project Glasswing. Even if CISA is shut out, some government agencies do have access to Mythos, including the US Department of Commerce’s Center for AI Standards and Innovation and the US National Security Agency, which Axios said are already assessing Mythos. This article first appeared on Computerworld. View the full article

Cybersicherheit zu messen, ist kein Kinderspiel. Foto: Ultraskrip – shutterstock.com Eine wichtige Säule jedes ausgereiften Cyberrisk-Programms ist die Fähigkeit, die Performance der IT-Security und registrierte Bedrohungen zu messen, zu analysieren und zu melden. Die Cybersecurity zu messen, ist allerdings kein leichtes Unterfangen: Einerseits, weil sich viele Führungskräfte ohne entsprechenden Background schwer tun, IT-Risiken zu verstehen. Andererseits verstricken sich Sicherheitsprofis auch zu oft in technische Details, die die Stakeholder verwirren und auf den falschen Weg führen. Das ideale Szenario: Security-Experten messen und reporten die Cybersicherheit auf eine Art und Weise, die für Führungskräfte leicht verständlich und nützlich ist – was zu umsetzbaren Ergebnissen führt. Klingt gut? Dieser Artikel vermittelt Ihnen, wie Sie das anstellen. Messkategorien der IT-Sicherheit Die meisten Stakeholder beschäftigen Fragen zu Risiken, Compliance oder Sicherheit. Diese lassen sich jedoch in der Regel nicht mit einem einzigen Datenpunkt beantworten. Doch es gibt eine Reihe von Dingen, die Security-Profis messen können, um auf die Fragen und Bedenken der Stakeholder einzugehen. Diese lassen sich (grob) in folgende Kategorien einordnen: Kontrollen: Maßnahmen, die ergriffen werden, um Bedrohungen abzuwehren und Risiken zu reduzieren. Assets: Jeder Gegenstand, der für die Organisation einen Wert besitzt, beziehungsweise sich in ihrem Besitz befindet. Vulnerabilities: Schwachstellen in einem System, die ausgenutzt werden können. Threat Events: Von einer Bedrohung ausgelöste Ereignisse, die Assets potenziell Schaden zufügen können. Sicherheitsvorfälle: Ereignisse, die “erfolgreich” Wirkung auf das Unternehmen entfaltet haben, etwa in Form von (System-)Ausfällen, Datenschutzverletzungen oder Cyberangriffen. Diese Kategorien lassen sich weiter nach verschiedenen Faktoren aufschlüsseln: Zahlen, Zeit oder Kosten. Zahlen könnten beispielsweise in Form des Prozentsatzes der ungepatchten Server gemessen werden. Eine weitere Möglichkeit: Sie messen die Zeit, die benötigt wurde, um einen Sicherheitsvorfall zu identifizieren. Schließlich könnten Kosten – zum Beispiel in Form von Wiederherstellungs- oder Ausfallkosten – Aufschluss über die finanziellen Auswirkungen von Security-Ereignissen geben. Cybersicherheits-Metriken, -KPIs und -KRIs Wenn Security-Profis oder -Entscheider an Business Teams berichten, sollten sie dazu möglichst relevante Messerwerte wählen. Dabei konzentrieren sich die meisten Sicherheitsteams auf Metriken, die Low-Level-Messungen bezüglich Assets, Schwachstellen und Threat Events abbilden. Auf Führungs- und Vorstandsebene sind hingegen vor allem KPIs (Key Performance Indicators) und KRIs (Key Risk Indicators) entscheidend, weil diese dazu beitragen können, spezifische Fragen in Bezug auf IT-Risiko, -Status und -Vorbereitung zu beantworten. Beispielsweise: Sind wir sicher? Liefern die Sicherheitsinvestitionen dem Unternehmen Mehrwert? Erfüllen wir aus Sicherheitsperspektive alle regulatorischen Anforderungen? Wie gut sind wir auf Ransomware- oder Supply-Chain-Angriffe vorbereitet? Deshalb sollten sich Security-Praktiker auch auf KPIs und KRIs konzentrieren. Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox. Jetzt CSO-Newsletter sichern Cybersecurity messen in 5 Schritten Der Aufbau des richtigen Messrahmens ist ein schrittweiser, iterativer Prozess. Im Folgenden die fünf wichtigsten Schritte, um einen Security Measurement Cycle aufzubauen. 1. Anforderungen definieren Sprechen Sie mit relevanten Stakeholdern, um deren Bedürfnisse zu definieren und zu verstehen. Diese haben zu diesem Zeitpunkt möglicherweise noch kein umfassendes Verständnis über IT-Risiken – oder ihre eigenen Anforderungen. Deshalb ist für Security-Praktiker ein Bottom-Up-Ansatz empfehlenswert, bei dem sie selbst die Initiative ergreifen und Fragen zu stellen, um die Anforderungen definieren zu können. 2. Key Indicators auswählen Sobald die Anforderungen der Stakeholder definiert sind, sollten Sicherheitsexperten diejenigen Key Indicators auswählen, die auf diese einzahlen. Dabei sollten die Stakeholder konsultiert und über die beabsichtigten, späteren Messungen informiert werden. Wenn die Stakeholder die Key Indicators kennen, können sie Maßnahmen ergreifen oder Entscheidungen treffen. Die Schlüsselindikatoren sollten auf hoher Ebene angesiedelt sein – und ihre Anzahl überschaubar bleiben. Das Ziel besteht schließlich darin, die Entscheidungsfindung zu erleichtern. 3. Metriken identifizieren Nachdem Ziele und Key Indicators festgelegt sind, gilt es für die Sicherheitsteams, die Low-Level-Messgrößen zu fokussieren, die dabei unterstützen, die Indikatoren zu reporten. Das kann – je nach Art des Indikators – bedeuten, dass Dutzende von Metriken aus den verschiedenen oben beschriebenen Messkategorien erforderlich sind. 4. Metriken sammeln und analysieren Da die Anforderungen nun feststehen, die Schlüsselindikatoren ausgewählt und die Messgrößen festgelegt sind, können die Praktiker nun damit beginnen, Daten auf dieser Grundlage zu sammeln und zu analysieren. Metriken dürfen dabei nur aus Daten abgeleitet werden, die akkurat, aktuell, relevant und vertrauenswürdig sind. Anderenfalls kann es zu Entscheidungen kommen, die schwerwiegende Folgen für die Sicherheitslage des Unternehmens nach sich ziehen. Es ist die Aufgabe der Security-Teams, Wege zu finden, Daten kontinuierlich zu sammeln (die meisten Messungen erfordern einen Überblick über Trends im Zeitverlauf) und den Prozess vorzugsweise so weit wie möglich zu automatisieren (ein manueller Prozess kann ermüdend und zeitaufwändig sein). 5. Key Indicators reporten Key Indicators müssen zeitnah an die Entscheidungsträger reported werden. Dabei sollten sich Security-Profis und Stakeholder auf einen zeitlichen Rhythmus einigen – ebenso wie über die Art der Berichterstattung: Sind Dashboards erforderlich oder reichen Powerpoint-Präsentationen aus? Die Schlüsselindikatoren sollten deutlich sichtbar und leicht verständlich sein, um zu Entscheidungen oder Maßnahmen zu führen. Darüber hinaus ist es wichtig, nach jedem Berichtszyklus die Key Indicators zu überprüfen und sie (unter Einbeziehung der Stakeholder) neu zu bewerten. Haben sich die geschäftlichen Anforderungen tatsächlich geändert, müssen die Anforderungen erneut definiert und ein anderer Satz von Indikatoren und Messgrößen erarbeitet werden. Unternehmen, Stakeholder und Sicherheitsexperten sollten keine Angst vor Rückwärts- oder Vorwärtsschritten haben: Die Fähigkeit, nach einem schnellen Fail direkt weiterzumachen, zu improvisieren oder sich neu auszurichten sind entscheidende Fähigkeiten, wenn es darum geht, Cybersicherheit erfolgreich zu messen. (fm) Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online. View the full article

Researchers warn of a new software supply chain attack that resulted in a malicious version of Bitwarden CLI, the terminal version of the extremely popular open-source password manager. The attack is believed to be related to the string of recent supply chain compromises attributed to a group called TeamPCP. “The attack appears to have leveraged a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign,” researchers from security firm Socket.dev said in a report. The attackers managed to publish a malicious Bitwarden CLI version 2026.4.0 on the npm registry. The version did not have a corresponding official release on the project’s GitHub repository and was detected and deleted in around 1.5 hours, between 5:57 PM and 7:30 PM ET on April 22. “The investigation found no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised,” Bitwarden said in a statement on its community forums. “Once the issue was detected, compromised access was revoked, the malicious npm release was deprecated, and remediation steps were initiated immediately.” The attack appears to be related to the recent supply chain compromise that impacted the Docker images and VS Code extensions of the KICS infrastructure-as-code vulnerability scanner from security firm Checkmarx. The group alleged to be involved, TeamPCP, has been responsible for a wave of supply chain attacks that have impacted open-source projects in recent months, including the Trivy security scanner. Luckily the new attack only impacted the CLI version of Bitwarden and not the much more widely used web browser extension and other client applications. Bitwarden is estimated to have over 10 million users, including 50,000 business customers. Attackers target cloud and development credentials The trojanized Bitwarden CLI version 2026.4.0 contained a custom loader called bw_setup.js that checks if the bun package manager is installed and then uses it to execute bw1.js. If bun doesn’t exist, it is downloaded and installed from GitHub. According to an analysis by security firm JFrog, the malicious payload is designed to detect and collect a board range of credentials and access tokens from the filesystem, shell environment variables, and GitHub actions configurations. Targeted credentials include GitHub and npm tokens, AWS and GCP credentials, API keys from MCP and AI agent configurations, Git credentials, SSH keys, and more. If GitHub tokens are found, the malicious code automatically weaponizes them by contacting https://api.github.com/user and trying several escalation paths, including executing GitHub Actions and listing secrets from their workflows. “This is not passive credential theft,” the JFrog researchers said. “It is a secondary access mechanism built to extract more secret material from GitHub-hosted automation environments.” Remediation Users who determined that their Bitwarden CLI installation was updated to the malicious 2026.4.0 version should assume developer and cloud credentials present on their machine have been compromised and should be rotated immediately. The goal of this attacker group is to gather credentials that would enable additional software supply chain attacks. After uninstalling the malicious version, clearing the npm cache, deleting bw1.js and bw_setup.js from the system, the JFrog researchers recommend: Revoking all GitHub PATs present on affected systems Rotating npm tokens and invalidating CI publishing tokens Rotating AWS access keys and reviewing access to SSM and Secrets Manager Reviewing Azure Key Vault audit logs and rotating affected secrets Reviewing GCP Secret Manager access logs and rotating affected secrets Inspecting GitHub Actions workflows and repository artifacts for unauthorized runs or branches Reviewing shell history and AI tooling configuration files for sensitive data leakage Blocking audit[.]checkmarx[.]cx and 94[.]154[.]172[.]43 at network egress points Enforcing npm script controls where possible, including ignore-scripts for untrusted installs View the full article

Why “more alerts” isn’t the same as better security If you run security in an enterprise environment, you already know the problem. Generic detection tools generate thousands of alerts, most of them low value. Analysts spend hours chasing noise while attackers quietly move laterally using valid credentials and trusted tools. AI‑driven threat detection promises to fix this, but not every “AI‑powered” platform actually delivers at enterprise scale. Real cyber resilience depends on something much simpler and harder to get right: detecting threats faster, containing them sooner, and reducing the operational impact when something slips through. Here are three practical ways AI threat detection helps make that happen. 1. AI detection reduces noise so teams can focus on real threats Traditional, rule‑based detection only catches what it already knows. That works for known malware and predictable attacks, but it breaks down when attackers use stolen credentials, PowerShell, or built‑in admin tools. Nothing looks obviously malicious, so alerts either never fire or fire constantly without context. AI‑driven detection flips the model. Instead of matching signatures, it builds behavioral baselines for users, endpoints, identities, and cloud workloads, then flags deviations that don’t fit normal patterns. At enterprise scale, this matters because: Legitimate admin activity and malicious behavior often look similar without context Hybrid environments generate fragmented telemetry that rule sets can’t correlate Lean teams don’t have time to manually connect the dots across systems Platforms like Adlumin MDR™ apply behavioral models and automated triage to suppress low‑value alerts and elevate incidents that actually matter. Fewer alerts, better context, and clearer prioritization reduce analyst fatigue and improve detection speed. From a resilience standpoint, this is the first win: faster detection means attackers have less time to move, escalate privileges, or reach critical systems. 2. Correlation and automated triage limit blast radius during an attack Most serious incidents aren’t a single event. They’re a chain of small actions that only look dangerous when viewed together. A failed login by itself is noise. Pair that login with unusual file access, an unexpected VPN session, and a new process on a server, and suddenly you have an incident worth acting on. AI‑driven detection at enterprise scale depends on cross‑telemetry correlation, pulling signals together from endpoints, identity providers, networks, and cloud services before analysts ever see an alert. This turns weak signals into actionable incidents. Automated triage takes it a step further by: Enriching alerts with investigative context Suppressing routine activity automatically Triggering response playbooks when risk crosses a defined threshold That automation is critical when attacks start moving quickly. Containing threats early reduces lateral movement and keeps incidents from turning into business‑level disruptions. This is where MDR really enables cyber resilience. It is not just about detection. It is about shrinking the window between intrusion and containment. 3. AI detection works best as part of a before‑during‑after resilience model Detection alone does not equal resilience. Enterprise environments need coverage before, during, and after an attack. A practical framework looks like this: Before an attack: Reduce exposure with patching, vulnerability management, endpoint hardening, and DNS filtering. Tools like N-central UEM™ help close common entry points before attackers exploit them. During an attack: Detect and contain threats with AI‑driven MDR. Behavioral detection, correlation, and automated response limit blast radius when prevention fails. After an attack: Recover quickly and confidently. Cove Data Protection™ supports resilience with isolated cloud backups, flexible recovery options, and ransomware rollback when downtime matters most. AI threat detection sits squarely in the “during” phase, but its real value shows up when it is integrated with prevention and recovery. That handoff is where point solutions usually fail and where platform approaches hold up under pressure. AI detection has to fit the enterprise you actually run AI threat detection fails when it is bolted onto architectures designed for simpler environments. It works when behavioral detection, correlation, automation, and human expertise operate together as a system built for scale, segmentation, and lean teams. For IT security leaders, the takeaway is practical: cyber resilience improves when detection reduces noise, response happens faster, and recovery is ready when needed. MDR enables that by changing how quickly teams can see and stop what matters. Discover what 500+ midmarket leaders are experiencing as AI reshapes the threat landscape in the Futurum research report: Cybersecurity in the Age of AI: Moving from Fragile to Resilient. View the full article

Donald Trump’s nominee to lead the Cybersecurity and Infrastructure Security Agency (CISA), Sean Plankey, informed Homeland Security Secretary Markwayne Mullin and the White House that he is withdrawing his nomination after a 13-month stall, during which the well-regarded cybersecurity veteran faced mounting resistance. “After thirteen months since my initial nomination, it has become clear the Senate will not confirm me,” he wrote in a letter sent to the White House, according to Politico. Plankey was nominated by Trump last March but failed to be confirmed by the end of 2025. He was renominated in January, only to face resistance to his confirmation. While he waited for his CISA confirmation, he worked for then-DHS Secretary Kristi Noem on Coast Guard issues, retiring from the Coast Guard last month. The administration’s failure to confirm Plankey comes amid great turmoil at the nation’s cybersecurity agency, which has suffered severe staff reductions and budget cuts since the start of Trump’s current administration, capped by the sudden departure of CISA’s acting director, Madhu Gottumukkala, in February, who was moved into a position at DHS following revelations of embarrassing security missteps he made during his short tenure. Policy experts say this turmoil is not simply bureaucratic drift — it weakens US cybersecurity at a dangerous moment, inviting foreign adversaries to exploit the aimlessness of an agency that is crucial to national security. “It’s hard for an agency to go this long without confirmed leadership,” Michael Daniel, president and CEO of the Cyber Threat Alliance (CTA), told CSO. “That’s not a good place for the country to be.” Problems on the Senate side Although neither Plankey nor the White House has clearly stated why his nomination stalled, a series of poorly sourced allegations and reported behind-the-scenes maneuvering over the past few months indicate that adversaries to Plankey’s confirmation were working to derail his leadership of the agency. On the surface, two Senators vowed to stop Plankey’s CISA confirmation. Sen. Rick Scott (R-FL) blocked Plankey’s nomination due to a Coast Guard issue. At the same time, Sen. Ron Wyden (D-OR) held up Plankey’s nomination to force CISA to release an unclassified report on telephone network security. A knowledgeable source told CSO they heard on the “backchannel” that someone on the Senate side called on US Representative Hillary Scholten (D-MI) to send a March 24 letter to DHS Inspector General Joseph Cuffari to investigate Plankey’s connection to a government contracting firm, alleging that he failed to cut his financial ties with the firm before his CISA nomination. However, the CEO of that firm told CSO he was blindsided by Scholten’s letter and that Plankey had forfeited all financial interest in the company prior to the announcement of his CISA nomination. The CEO told CSO he sent a letter to the Coast Guard detailing the facts after Scholten — who he said never contacted his company — sent her letter to DHS. CSO contacted Scholten’s office multiple times seeking comment, but received no response. CSO also received no response to the questions surrounding this letter from either DHS or CISA. CSO made efforts to reach Plankey for comment, but yielded no response. Questions over who wanted Plankey blocked On March 3, Ana Visneski, a former head of global disaster response at Amazon Web Services and former chief of digital media for the US Coast Guard, posted on Bluesky that she was “hearing from multiple sources” that Plankey “has been fired and escorted out of Coast Guard HQ by security,” a post that was picked up by at least one influential military analyst. Visneski did not respond to CSO’s request for comment. Following Visneski’s social media post, CBS News published a report repeating the allegation, saying that Plankey was abruptly escorted out of the US Coast Guard headquarters and had his access badge removed. CBS News also reported that sources said Plankey’s renomination was made in error, which the White House denied. The CBS report also highlights longstanding tensions between Plankey and Madhu Gottumukkala over cybersecurity contracts. Gottumukkala had been former DHS Secretary Kristi Noem’s CIO in North Dakota, and Plankey, by all accounts, had an excellent relationship with Noem while at DHS. Two sources told CSO that it was highly unlikely that Plankey was fired because he received a Coast Guard award days after he was supposedly escorted out of the building, and, moreover, he was still the CISA nominee at that point, an unlikely status if he had indeed been fired. A weak agency in the middle of a hot war Whatever harm may have been done to Plankey, it is certain that the lack of leadership at CISA risks damage to the nation’s security, particularly in the middle of the Iran war. “Cybersecurity is not just a law enforcement or an economic issue,” CTA’s Daniel said. “It’s both of those things, but it is also a national security issue. And we are in a position now where we have started a hot war, a kinetic war.” He added, “One of the tools that Iran has at its disposal is its cyber capabilities, and it would be foolish of anyone to think that Iran would not at least consider targeting US critical infrastructure because of that ongoing conflict. You have left your nation’s cyber defense agency, which is responsible for working with critical infrastructure across the whole country, leaderless when you’re in an active hot conflict. So that seems like a problem to me.” Just how long CISA will be leaderless is unclear. One thing that is clear is that Plankey will support whoever does become the next CISA leader. “While I humbly request the removal of my nomination, I wholeheartedly support President Trump’s upcoming nomination for CISA and look forward to the continued success of the United States of America,” Plankey told the White House. In the end, the story may be less about Sean Plankey than about what happens when Washington treats cybersecurity leadership as expendable. Leaving the nation’s primary cyber defense agency weakened, underfunded, and without confirmed leadership is not simply a personnel problem — it is a national security risk. View the full article

Donald Trump’s nominee to lead the Cybersecurity and Infrastructure Security Agency (CISA), Sean Plankey, informed Homeland Security Secretary Markwayne Mullin and the White House that he is withdrawing his nomination after a 13-month stall, during which the well-regarded cybersecurity veteran faced mounting resistance. “After thirteen months since my initial nomination, it has become clear the Senate will not confirm me,” he wrote in a letter sent to the White House, according to Politico. Plankey was nominated by Trump last March but failed to be confirmed by the end of 2025. He was renominated in January, only to face resistance to his confirmation. While he waited for his CISA confirmation, he worked for then-DHS Secretary Kristi Noem on Coast Guard issues, retiring from the Coast Guard last month. The administration’s failure to confirm Plankey comes amid great turmoil at the nation’s cybersecurity agency, which has suffered severe staff reductions and budget cuts since the start of Trump’s current administration, capped by the sudden departure of CISA’s acting director, Madhu Gottumukkala, in February, who was moved into a position at DHS following revelations of embarrassing security missteps he made during his short tenure. Policy experts say this turmoil is not simply bureaucratic drift — it weakens US cybersecurity at a dangerous moment, inviting foreign adversaries to exploit the aimlessness of an agency that is crucial to national security. “It’s hard for an agency to go this long without confirmed leadership,” Michael Daniel, president and CEO of the Cyber Threat Alliance (CTA), told CSO. “That’s not a good place for the country to be.” Problems on the Senate side Although neither Plankey nor the White House has clearly stated why his nomination stalled, a series of poorly sourced allegations and reported behind-the-scenes maneuvering over the past few months indicate that adversaries to Plankey’s confirmation were working to derail his leadership of the agency. On the surface, two Senators vowed to stop Plankey’s CISA confirmation. Sen. Rick Scott (R-FL) blocked Plankey’s nomination due to a Coast Guard issue. At the same time, Sen. Ron Wyden (D-OR) held up Plankey’s nomination to force CISA to release an unclassified report on telephone network security. A knowledgeable source told CSO they heard on the “backchannel” that someone on the Senate side called on US Representative Hillary Scholten (D-MI) to send a March 24 letter to DHS Inspector General Joseph Cuffari to investigate Plankey’s connection to a government contracting firm, alleging that he failed to cut his financial ties with the firm before his CISA nomination. However, the CEO of that firm told CSO he was blindsided by Scholten’s letter and that Plankey had forfeited all financial interest in the company prior to the announcement of his CISA nomination. The CEO told CSO he sent a letter to the Coast Guard detailing the facts after Scholten — who he said never contacted his company — sent her letter to DHS. CSO contacted Scholten’s office multiple times seeking comment, but received no response. CSO also received no response to the questions surrounding this letter from either DHS or CISA. CSO made efforts to reach Plankey for comment, but yielded no response. Questions over who wanted Plankey blocked On March 3, Ana Visneski, a former head of global disaster response at Amazon Web Services and former chief of digital media for the US Coast Guard, posted on Bluesky that she was “hearing from multiple sources” that Plankey “has been fired and escorted out of Coast Guard HQ by security,” a post that was picked up by at least one influential military analyst. Visneski did not respond to CSO’s request for comment. Following Visneski’s social media post, CBS News published a report repeating the allegation, saying that Plankey was abruptly escorted out of the US Coast Guard headquarters and had his access badge removed. CBS News also reported that sources said Plankey’s renomination was made in error, which the White House denied. The CBS report also highlights longstanding tensions between Plankey and Madhu Gottumukkala over cybersecurity contracts. Gottumukkala had been former DHS Secretary Kristi Noem’s CIO in South Dakota, and Plankey, by all accounts, had an excellent relationship with Noem while at DHS. Two sources told CSO that it was highly unlikely that Plankey was fired because he received a Coast Guard award days after he was supposedly escorted out of the building, and, moreover, he was still the CISA nominee at that point, an unlikely status if he had indeed been fired. A weak agency in the middle of a hot war Whatever harm may have been done to Plankey, it is certain that the lack of leadership at CISA risks damage to the nation’s security, particularly in the middle of the Iran war. “Cybersecurity is not just a law enforcement or an economic issue,” CTA’s Daniel said. “It’s both of those things, but it is also a national security issue. And we are in a position now where we have started a hot war, a kinetic war.” He added, “One of the tools that Iran has at its disposal is its cyber capabilities, and it would be foolish of anyone to think that Iran would not at least consider targeting US critical infrastructure because of that ongoing conflict. You have left your nation’s cyber defense agency, which is responsible for working with critical infrastructure across the whole country, leaderless when you’re in an active hot conflict. So that seems like a problem to me.” Just how long CISA will be leaderless is unclear. One thing that is clear is that Plankey will support whoever does become the next CISA leader. “While I humbly request the removal of my nomination, I wholeheartedly support President Trump’s upcoming nomination for CISA and look forward to the continued success of the United States of America,” Plankey told the White House. In the end, the story may be less about Sean Plankey than about what happens when Washington treats cybersecurity leadership as expendable. Leaving the nation’s primary cyber defense agency weakened, underfunded, and without confirmed leadership is not simply a personnel problem — it is a national security risk. View the full article

The UK’s National Cyber Security Centre (NCSC) is recommending passkeys as the default authentication method for businesses to offer consumers, citing industry progress that now makes them a more secure and user-friendly alternative to passwords. In a blog post published this week, the agency said passkeys can now be recommended to both the public and businesses as a primary authentication method. “Passkeys should now be consumers’ first choice of login,” the UK cybersecurity authority said in a blog post, adding that passwords are “no longer resilient enough for the contemporary world.” “Passkeys are a newer method for logging into online accounts which do much of the heavy lifting for users, only requiring user approval rather than needing to input a password. This makes passkeys quicker and easier to use and harder for cyber attackers to compromise,” the NCSC added in the blog. The agency said passkeys should be used wherever supported, describing them as resistant to phishing and eliminating risks associated with password reuse. Focus on phishing-resistant authentication The guidance is based on the agency’s assessment of how authentication methods perform against real-world attacks. The NCSC said its analysis examines common techniques, including phishing, credential reuse, and session hijacking, and evaluates how credentials are exposed across their lifecycle, from creation and storage to use. “Passkeys are resistant to phishing attacks and remove the risks associated with password reuse,” the agency said. In its accompanying technical paper, the NCSC said traditional authentication methods, including passwords combined with one-time codes, remain “inherently phishable.” By contrast, FIDO2-based credentials such as passkeys are “as secure or more secure than traditional MFA against all common credential attacks observed in the wild,” the agency said. However, NCSC cautioned in the technical paper that “while much of the analysis in this paper also applies to enterprise authentication scenarios (for example staff authenticating to a Single Sign On), the different threat model and usage scenarios mean this paper is not intended for enterprise risk assessment.” How passkeys change the attack model The NCSC added that passkeys reduce risk by removing reliance on shared secrets and binding authentication to the legitimate service. According to the agency, this prevents credential reuse and relay attacks, as authentication cannot be intercepted and reused by an attacker. Passkeys use cryptographic key pairs stored on a user’s device, with authentication tied to device-based verification such as biometrics or PINs, the agency said. Shift in user-level authentication For organizations that provide online services to customers, the guidance signals a shift in how authentication is implemented at the user interface level. “This is a fundamental architectural change, not an incremental authentication upgrade,” said Madelein van der Hout, senior analyst at Forrester. “It moves organizations beyond the passwords-plus-MFA paradigm toward a phishing-resistant foundation.” Van der Hout said passkeys eliminate risks associated with credential theft by using device-bound cryptographic authentication rather than shared secrets. “Organizations that treat this as a credential swap will underinvest,” she said. “Those who treat it as a broader identity modernization opportunity will get ahead.” The NCSC said organizations should also consider how authentication is implemented across the full user journey, including account recovery and fallback mechanisms. While passkeys reduce reliance on passwords, the agency noted that weaker processes, such as password resets or account recovery flows, can still introduce risk if not properly secured. Adoption challenges remain The NCSC said passkeys are not yet universally supported and recommended password managers and multi-factor authentication where passkeys cannot be used. “Where a particular service does not support passkeys, the NCSC’s advice to consumers is to use a password manager to create stronger passwords and keep using two-step verification,” NCSC noted in the blog post. Van der Hout said implementation challenges are likely, particularly for organizations operating across multiple platforms and user environments. “Legacy systems and fragmented identity environments present significant obstacles,” she said. She added that organizations must also consider non-human identities. “Any passkey strategy that ignores the machine identity layer will create new security gaps,” she said. Device requirements and account recovery processes may also affect how passkeys are deployed, she said. Hybrid model is expected during the transition A full transition away from passwords is unlikely in the near term, analysts believe. “Expect a hybrid model lasting several years,” van der Hout said, as organizations continue to support both passkeys and traditional authentication methods. During this period, organizations will need to manage authentication across multiple login options while ensuring that fallback methods do not weaken overall security, she added The NCSC similarly advised maintaining strong authentication practices where passkeys are not yet available. Policy signal strengthens shift toward passwordless login The guidance adds to broader efforts to move away from passwords in consumer authentication. “The guidance matters because it gives security leaders leverage,” van der Hout said, including in discussions with vendors and internal stakeholders. The NCSC said that moving toward phishing-resistant authentication could reduce a major cause of cyber compromise, particularly in services that rely on user login credentials. View the full article

In response to Anthropic Mythos, instead of launching another LLM, Google unveiled a broad push toward agentic, AI-driven defense at Google Cloud Next ‘26 to help SOC analysts as they scramble to keep up with the influx of CVEs Mythos threatens. As Mythos promises more vulnerabilities, and reports of unauthorized access despite its limited preview emerge, Google is betting that only agents, not analysts, can keep pace with what is coming. Google unveiled new capabilities focused on automating detection, accelerating response, and securing the increasingly messy intersection of AI, cloud, and third-party ecosystems. Under this, the search giant announced three new agents in Google Security Operations, expanded security across clouds and AI studios with expanded Wiz integration, and the Gemini Enterprise Agent Platform that promises a defense layer against shadow AI. Additionally, Google said it is working on simplifying permissions with modern IAM, along with a handful of improvements in Google Cloud Security. New emphasis on agentic defense Google’s most direct help to SOC teams comes in the form of three new AI agents embedded in Google Security Operations. These include a threat hunting agent, a detection engineering agent, and a third-party context agent. While the threat hunting and detection engineering agents, both now in preview, aim to identify novel attack patterns and close detection gaps, respectively, the third-party context agent, set to enter preview, is designed to enrich investigations with external intelligence. Google claimed its existing triage and investigation agent has already processed over five million alerts, shrinking analysis time from 30 minutes to roughly a minute using Gemini. There’s also a push toward what Google calls “agentic automation,” where response actions can be triggered automatically, paired with new dark web intelligence (infused into Google Threat Intelligence) capabilities to prioritize real threats with high accuracy. Wiz, AI-BOMs, and securing the AI development sprawl Google has expanded its Wiz portfolio to tackle the chaos of AI development and multi-cloud risk. Wiz is being positioned as the connective tissue across environments, supporting everything from AWS and Azure to SaaS platforms and AI agent studios.“Wiz now supports Databricks as well as new agent studios like AWS Agentcore, Gemini Enterprise Agent Platform, Microsoft Azure Copilot Studio, and Salesforce Agentforce, so customers gain visibility however their teams choose to build,” said Francis deSouza, COO, Google Cloud and President, Security Products. Other new capabilities from the integration come in the form of inline scanning of AI-generated code, integrations directly into developer workflows, and an AI-bill of materials (AI-BOM) that inventories all AI components, including models, frameworks, and IDE plugins across an organization. AI-BOM is targeted as a practical response to shadow AI, offering visibility into tools developers use versus what’s approved. Securing the agentic web Google is also aiming to have visibility into the plane where AI agents interact autonomously across systems, something it calls the “agentic web.” To address that, it introduced Agent Identity and Agent Gateway for governance and policy enforcement, alongside deeper integrations for Model Armor to mitigate risks like prompt injection and data leakage. There’s also a reworked approach to bot and fraud detection through Google Cloud Fraud Defense, which aims to distinguish between humans, bots, and AI agents across the workflows. View the full article