automated

Sovereignty vs. security: Microsoft’s Roger Halbheer says you’re asking the wrong question

Sovereignty vs. security: Microsoft’s Roger Halbheer says you’re asking the wrong question In this interview with Help Net Security, Roger Halbheer, Customer Security Officer at Microsoft, argues that digital sovereignty is a security question first. He explains why organizations underestimate speed, the time it takes to detect and stop an attacker, and why the cost curve turns steep once workloads move on premises. Halbheer says boards ask for independence but end up buying a location and an assurance statement. Instead, he urges risk decisions per workload. He also points out that governments can compel providers almost everywhere, including in Europe, and that a compromised environment is never sovereign. Sovereignty costs money, people and speed. Which of the three do organizations consistently underestimate, and why? Speed, and I mean security speed: how fast you detect an intrusion, decide and act. Money shows up in a procurement decision. Speed shows up only on the day an attacker is inside, and then it is the only number that matters. That window keeps shrinking. The Microsoft Digital Defense Report 2026 shows that the time from a vulnerability’s discovery in the wild to active weaponization can be well below 24 hours, in a year heading for a record 72,000 published CVEs. And in 52.2 percent of intrusions using valid accounts, the attacker went on to steal further credentials. One foothold becomes many, fast. What most organizations miss is that the cost of sovereignty is not a straight line. That is my model, but I see it in every engagement. Inside the cloud, a lot of sovereignty comes cheap: customer-managed keys, residency where your counsel says you need it, access transparency. It is a configuration change, not a re-platforming, and you keep the platform’s detection, threat intelligence and automated response. The same report names shared, correlated threat intelligence as one of the highest-leverage variables a defender controls. You lose very little speed and need very few additional people. The cloud is also where the innovation is, and customers are asking for it: AI assistants, agents and analytics that need the service to work with their data. The same is true for defense. Agentic AI is changing what defenders can do. MDASH, our multi-model agentic code scanner, coordinates more than a hundred specialized AI agents to find and validate vulnerabilities before attackers do, and it is offered in EU and Swiss regions. Project Perception puts red, blue and green agents to work probing, investigating and hardening at machine speed, with humans signing off every high-impact action. Both are in preview today, and both are delivered from the cloud. The curve turns steep the moment you move on premises and build it yourself, often on open source. Every detection is one you write, every patch one you roll out, every lesson one you learn on your own incident at three in the morning, and none of that innovation arrives on its own. Open source does not end the dependency question either: the license is free, the supply chain is not. That is where people come in, because speed is made of people: platform, identity and security skills at once, twenty-four hour coverage, runbooks that hold under stress. In the ISC2 2025 Workforce Study, 33 percent said their organization lacks the budget to staff its security teams adequately. Germany shows the result at scale. In October 2025 the BSI found 92 percent of roughly 33,000 internet-reachable on-premises Exchange servers running versions at or past end of support. In August 2026 CERT-Bund could see extended security patches on nine. Sovereignty is not the server you own. It is the work you keep doing, fast enough, after you own it. When a European board says it wants sovereignty, what is it usually asking for, and what does it usually end up buying? It is asking for independence: nobody outside can reach its data or switch it off. It usually ends up buying a location and an assurance statement, applied to the whole company at once. Both halves are the problem. Independence is not for sale, and a company-wide posture has no unit of decision, no price and no test. You cannot defend it to an auditor, so you cannot manage it. What a board should ask for is a risk decision per workload. Which exposure are we reducing, what does it cost in money, people and speed, and how would we prove it works? If you cannot answer the third question, you have not bought anything. And that decision belongs in the risk register, not in a procurement negotiation or a news cycle. If independence is not for sale, what is a European organization buying when it pays for sovereignty? Precision. The European Commission says the Union relies on non-EU countries for over 80 percent of key digital products, services, infrastructure and intellectual property. Read that as hopeless and you get paralysis. Buy one sovereign layer and declare victory and you get a press release. What you are actually paying for is control over the dependencies that matter for a specific workload: who holds the keys, a contract that says what the provider will contest and tell you, a second supplier where one exists, an exit plan you have actually run. And not only on your core platform. Payroll, CRM, backup and security monitoring each hold copies of the same data, in their own jurisdictions. A legal order and an attacker both take the cheapest route in. Above all, you are buying security, because a compromised environment is not sovereign. Whatever assurance you hold about lawful access is void the moment someone is accessing your data unlawfully. In our Digital Defense Report, 63 percent of intrusions involved data theft, and cloud identity abuse accounted for 78 percent of the attack techniques observed against critical infrastructure. Those are identity failures, not jurisdiction failures, and no sovereignty control on anybody’s slide stops them. Security is not a parallel program to sovereignty. It is the precondition. How many European customers understand that “move it to Europe” does not mean “no government can compel the provider”? Fewer than should. I do not have a number and would not trust anyone who claims one, but in my conversations it is rarely understood. Compelled access is not an American peculiarity. The UK can compel a provider to build a capability. France can require certain providers to hand over decryption keys within seventy-two hours. And since 18 August 2026, e-Evidence lets an authority in one member state order a provider in another to produce data within ten days, or eight hours in an emergency. To be fair, e-Evidence operates inside a mutual-recognition area with common fundamental-rights standards. But the point stands. Can a government compel my provider? Yes, almost everywhere. What separates jurisdictions is under what conditions, with what oversight, and whether I can see it happening. This is where we as a society have to strike a balance. We all want law enforcement to fight child sexual abuse, human trafficking, terrorism and fraud, and those crimes are global. Their evidence sits on somebody’s server, often in another country. At the same time, we need privacy and managed risk. So the question is not whether these powers should exist, but whether they are properly bounded: a legal basis, independent authorization, a limit on scope, a route to challenge, and some way for the rest of us to see that the system works. If a large share of government requests come with secrecy orders, how can anyone tell the difference between a risk that is rare and a risk that is well hidden? I would start with the premise, because it assumes something I cannot confirm. Secrecy orders exist, in the US and in Europe. How often they attach to requests touching European enterprise data is not something the public record lets anyone state with confidence, in either direction. What their existence does mean is that the absence of documented cases has two readings. Either the risk is genuinely rare, or the secrecy rules are working as designed. Assert only the first and you overstate. Assert only the second and you can never be proved wrong. And secrecy is not unchallengeable: Microsoft sued the US Department of Justice over indefinite secrecy orders in 2016, and the Department changed its policy in 2017. Treat it as a risk you cannot quantify. Ask providers whether their transparency reporting is externally assured. Put the commitment to contest orders and notify you in the contract, not a blog post. For the narrow class of data that needs it, use a design where the provider cannot read the content, and accept the cost in functionality. Then look at the other risk in the same room, the one measured in minutes. One risk you cannot count. The other gives you a number every day. Only one of them tells you where to start. Download: The IT and security field guide to AI adoption

helpnetsecurity.comOct 22, 2026extracted

China-Linked Hackers Use ARTEX AI Agents in ConnectWise Supply Chain Attack

Microsoft on Wednesday disclosed that a China state-aligned actor dubbed Storm-0940 was behind the recent supply chain compromise of the ConnectWise Cloud Backup application. During the incident, Storm-0940 used ARTEX, a Go-based agentic AI penetration testing framework that was made closed-source in the wake of its abuse in cyber attacks targeting South Korean financial institutions, to speed up scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims. The tech giant said the threat actor used the AI tool at "machine speed" to automate attacks targeting hundreds of organizations across the world spanning a broad range of sectors since September 2026. Targets include aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks and non-profits. "Storm-0940's use of ARTEX accelerated the speed of compromised application abuse to authenticate to target environments through applications that had already been granted access, allowing the threat actor to operate without requiring an interactive user sign-in," Microsoft said. "AI-accelerated follow-on activity included reconnaissance, application credential changes, and attempts to modify privileges that could enable expanded or persistent access." Storm-0940 was first detailed by Microsoft in November 2024, revealing that the threat actor has been leveraging a botnet called Quad7 (aka CovertNetwork-1658) to conduct highly evasive password spray attacks. The threat actor is assessed to be active since at least 2021. The adversary is also said to exploit internet-facing applications to gain initial access, followed by using compromised accounts to move through targeted environments. It has also been observed establishing persistence by adding credentials to existing OAuth applications within cloud infrastructures to ensure access to Microsoft 365 resources. According to Microsoft, a chunk of these ARTEX-driven attacks have resulted in the adversary gaining privileged access to an organization's cloud infrastructure, including several instances where the time frame from initial targeting to privileged access was less than 3 hours. In the case of the ConnectWise incident, Storm-0940 has been observed using ARTEX to attempt to sign in to more than 2,250 tenants at 2,900 sign-in attempts per minute, a pace the company said gives defenders a short window to detect and respond. "Between October 10 and 14, 2026, Storm-0940 infrastructure at 144.172.64[.]99 conducted an automated cross-tenant password-spray campaign targeting 327 accounts across eight organizations to gain access to Microsoft 365 and Exchange Online," Microsoft said. During this window, Microsoft said it captured over 151,000 failed logon events. The activity peaked on October 11 at 2,900 failures per minute, resulting in more than 111,000 failures in a single day. Of these, 48 accounts received more than 1,000 failures. No successful authentication, token issuance, Graph call, or directory change was detected, it noted. That changed on October 15, 2026, when the AI agents gained access to the identities of multiple ConnectWise cloud applications and began to use them to authenticate to customer environments. "Additionally, after acquiring control of the identities of multiple ConnectWise cloud applications, the AI agents operating on behalf of the threat actor continued to use the same IP range to authenticate to customer environments using the illicit access acquired through these stolen app credentials, effectively taking advantage of the already established trust by these apps within a tenant," the tech giant added. In some of these cases, the AI agents are assessed to have progressed beyond authentication to Microsoft Graph and directory operations. This included reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups, and privileged roles. "The application credential modification made by Storm-0940’s associated agents in the targeted victims' environments can lead to persistence through other identities, credentials, and cloud services," Microsoft said. "These changes can remain active as a backdoor even after the original compromised application is mediated." Storm-0940 is far from the only hacking crew to rely on ARTEX. Microsoft said it has observed threat actors across multiple geographic regions weaponizing the framework in their operations. Recorded Future Insikt Group, which is tracking the threat cluster behind the attacks on South Korean financial institutions under the moniker TAG-217, said it identified activity linked to the threat actor dating back to August 17, 2026, when it "tested infrastructure designed to maintain remote access to computers and conducted internet scanning." Over the next few weeks, the Chinese-speaking threat actor is said to have put together tools to attack cryptocurrency mining operations using the YiiMP platform, as well as set up a workspace for testing weaknesses in iPhones and modifying Android system software. Zscaler ThreatLabz has since revealed that the attack's footprint extends beyond South Korea, and that it opportunistically targeted organizations around the globe and across multiple industry sectors. The findings come from a custom ARTEX deployment that included AI assistant configurations, synchronization scripts, network routing tools, and a Claude Code prompt history. "ARTEX was configured to use a DeepSeek model through an OpenAI-compatible gateway, but other configurations also specified DeepSeek, GLM, and Grok," security researcher Seongsu Park said. "Prompts directed AI models to divide investigation tasks and review one another's findings, including instructions for GLM to review work performed by DeepSeek and its subagents." An analysis of the prompt histories has revealed requests for bulk personal and transaction data, along with questions about selling stolen data, suggesting the attacks were likely financially motivated. Other prompts related to extracting payment gateway API keys, exploiting NFT minting workflows, and gaining unauthorized administrative privileges. The findings once again highlight how threat actors are increasingly integrating agentic AI tools into their offensive security workflows to quickly carry out attacks at scale. "Agents are not constrained by factors affecting humans – they can work around the clock, on weekends, and on holidays and attempt multiple breach paths simultaneously, enabling significantly reduced time from selecting a target to achieving objectives, increasing the speed and impact of complex attacks like supply chain compromises," Microsoft said. In response to the findings, ConnectWise said the activity "describes a campaign that reaches well beyond any one company," adding "nation-state actors are increasingly targeting the software supply chain, because one trusted connection can open the door to many organizations." "AI now lets them test those connections at [...] 'machine speed.' MSPs are in the middle of that chain. They are targets in their own right, and they are also a path into every client they serve. Every vendor and every MSP must defend itself with both of those risks in mind." ConnectWise, which temporarily shut down services following the attacks, has been restoring services in phases, a process that it said will take several days.

thehackernews.comOct 22, 2026extracted

Japan's Onamae Desktop Cloud hacked, up to 27,000 servers affected

Hackers compromised the infrastructure of Onamae Desktop Cloud, a popular provider of VPS services in Japan, and installed malware on up to 26,739 customers' servers. [...]

bleepingcomputer.comOct 21, 2026extracted

Best practices for integrating IAM Roles Anywhere with your PKI

aws.amazon.comOct 21, 2026extracted

USN-8949-1: Ghostscript vulnerabilities

Rick de Jager discovered that Ghostscript incorrectly handled memory under certain circumstances when processing PostScript documents. If a user or automated system were tricked into processing a specially crafted document, an attacker could possibly use this issue to bypass the sandbox and execute arbitrary code. (CVE-2026-101258) It was discovered that Ghostscript incorrectly handled memory when converting certain fonts. If a user or automated system were tricked into processing a specially crafted file, an attacker could possibly use this issue to cause Ghostscript to crash, or possibly execute arbitrary code. (CVE-2026-103226) Paulos Yibelo discovered that Ghostscript did not properly validate certain operands when loading fonts. If a user or automated system were tricked into processing a specially crafted file, an attacker could possibly use this issue to bypass the sandbox and execute arbitrary code. (No CVE number)

ubuntu.comOct 21, 2026extracted

High-Severity Flaws Exploited in Three Days as Ransomware Dominates Q3: Rapid7

Rapid7’s Q3 analysis finds high-severity flaws exploited within three days on average, while AI appeared in just 8% of tracked incidents. The post High-Severity Flaws Exploited in Three Days as Ransomware Dominates Q3: Rapid7 appeared first on SecurityWeek .

securityweek.comOct 21, 2026extracted

“Next Exploit Opportunities”: How a Threat Actor Used AI to Help Plan and Execute Multiple Types of Cybercrime Activities

An investigation into a threat actor bypassing AI safety controls to coordinate credential theft, VoIP fraud planning, and database exfiltration. The post “Next Exploit Opportunities”: How a Threat Actor Used AI to Help Plan and Execute Multiple Types of Cybercrime Activities appeared first on Unit 42 .

unit42.paloaltonetworks.comOct 21, 2026extracted

Generative AI Is Erasing Behavioral Tells, Weakening Behavior-Only Detection, Proofpoint Reports

Generative AI has changed what a malicious email looks like. Messages that once gave themselves away through clumsy wording, generic pretexts, and reused templates now arrive fluent, personalized, and unique to each recipient, and the behavioral signals email filters have relied on for years are fading as a result. Proofpoint shared several examples of the shift at its Protect 2026 conference.

thehackernews.comOct 21, 2026extracted

The Harness Is the Hard Part of Agentic Pentesting

An AppSec team can point an AI agent running on a general-purpose model at its own web apps with little setup. Sure, the model writes the attacks. But everything that makes those attacks safe to run against production and worth acting on afterward lives in the harness around the model. The harness is where the engineering in AI pentesting sits. The Hugging Face intrusion OpenAI disclosed in July

thehackernews.comOct 21, 2026extracted

CISA: SafePay ransomware hit over 600 critical infrastructure orgs

The Cybersecurity and Infrastructure Security Agency (CISA) says the SafePay ransomware gang has breached over 600 critical infrastructure organizations worldwide since 2024. [...]

bleepingcomputer.comOct 21, 2026extracted

Hackers Hid Vasilek Backdoor in VMware Tools During 2-Year Russian Healthcare Intrusion

A Belarus-aligned hacktivist group spent nearly two years within the network of a Russian healthcare organization. According to a report published by Russian cybersecurity firm Solar, the activity has been attributed to a threat cluster dubbed Partisan Zmiy, which is also known as the Cyber Partisans. Known to be active since at least 2020, the group has a track record of striking industrial enterprises and government agencies in Russia and Belarus with a backdoor called Vasilek that uses Telegram for command-and-control (C2) and data exfiltration. Some of the attacks have also leveraged phishing lures to deliver an installer that simultaneously deploys the legitimate FortiClient VPN program on the system as well as an open-source program known as DNSCat2 that allows attackers to gain control of the infected host. A notable aspect of the threat actor is their ability to stage destructive attacks with a wiper referred to as Pryanik, alongside taking steps to systematically clear Windows event logs using a utility dubbed Evlx. The Rostelecom subsidiary said it discovered the intrusion in December 2025, although evidence suggests that the earliest signs of compromise date back to early 2024. The name of the targeted organization was not identified. The exact initial access vector used to breach the entity is also not known. Unlike other attacks linked to Cyber Partisans, the threat actors remained on the network for an extended period of time without carrying out any destructive activity, marking something of a shift in modus operandi. "The attacked organization possessed an extensive infrastructure and two-way trusted relationships with numerous subsidiary medical institutions," Solar said. "We hypothesize that the lack of infrastructure disruption is due precisely to the value of this access for further espionage and trusted relationship attacks." Observed as part of the intrusion is a loader-scheduler service ("vmauad") that masquerades as a legitimate VMware component to maintain persistence and evade cursory inspection. To accomplish this, the attackers are said to have taken advantage of a trusted-but-unmonitored VMware Tools directory location to plant malicious executables or replace legitimate VMware DLLs with a malicious version ("vmtools.dll") containing the backdoor. The primary responsibility of the Windows service is to launch the rogue binary "C:\Program Files\VMware\VMware Tools\authd.exe" that, besides launching a GOST tunnel every Saturday from 10 p.m. to 11 p.m., runs an updated version of Vasilek (version 1.5.8) once, eight hours after the service begins. Once installed, Vasilek is equipped to collect information about an infected computer, execute Windows commands, launch and terminate processes, transfer files, capture screenshots, record keystrokes, and escalate privileges via runas. It can also prevent the machine from going into sleep mode, and update or remove itself. One new addition is the "move_cursor" command that, as the name implies, allows the backdoor to move the cursor and simulate user input on the victim's screen. "The group consistently invests in stealth and operational security, rather than new capabilities: hostname binding in two independent components, nightly scheduled payload launches, system proxy inheritance, disguise as legitimately installed but unused software, file rotation across the same paths, time-stomping, outgoing message suppression, and anonymous messages on behalf of the group in operator chats," Solar said. "The backdoor's feature set has remained largely unchanged over four revisions. Due to Telegram being blocked in Russia by ISPs, communication between the Vasilek backdoor and C2 has become unstable." The disclosure comes as Solar also disclosed details of a phishing campaign that employs JavaScript attachments mimicking business-themed documents, such as payments and purchase orders, to deliver a previously unreported malware family known as HypeAgent. The Windows malware is a full-featured trojan designed to take complete control over infected systems, packing the ability to steal files, open a console, change desktop wallpaper, turn on a webcam, log keystrokes, launch hidden VNC and RDP sessions, control the mouse, and even deploy a cryptocurrency miner. It's also capable of stealing cookies associated with Discord, Steam, GitHub, Instagram, Telegram, Binance, ChatGPT, Claude, and Cursor, and tampering with the installed Exodus wallet app to inject JavaScript that can collect the victim's password, PIN, mnemonic phrase, and private key. Earlier this June, Solar also observed legitimate infrastructure compromised by the ProxyCB proxyware botnet malware making automated requests to Russian websites and online platforms, while identifying possible overlaps between the botnet infrastructure and historical activity linked to TeamSpy, a threat cluster known for abusing TeamViewer to facilitate reconnaissance and data theft. Last month, the U.S. Department of Justice (DoJ) charged Searzhudin Tamirlanovich Aktulaev, a 40-year-old Russian national extradited from Cyprus in May 2025, for exploiting an online messaging service of a well-known freelance employment platform to send malware-laced Excel attachments to about 80,000 of its users in 2016 and 2017 using 255 fake accounts. The attacks led to the deployment of two types of malware, a variant of the TVRAT (aka Sheldor, SpyAgent, TeamBot, TeamSpy, and TVSPY) and DarkVNC, to harvest and send data from a victim computer to a remote server under the attacker's control. Thousands of computers are assessed to have been infected as a result of this scheme.

thehackernews.comOct 21, 2026extracted

How AI can fix cybersecurity compliance: From dashboards to continuous execution

How AI can fix cybersecurity compliance: From dashboards to continuous execution Most compliance work goes into proving security, not improving it. That isn’t because the rules are unreasonable. Regulators, customers, and cyber insurers are right to expect organizations to implement hundreds of technical and administrative controls, monitor their environments, respond to incidents, and prove that all of it works. The problem is the cost of delivering it. The Pentagon’s own estimate puts a small contractor’s CMMC level 2 compliance at roughly $105,000 over three years. That figure covers only assessing and attesting to compliance, not implementing a single control. In our experience working with small and midsize businesses, the full first-year cost of a compliance program runs from $50,000 to well over $300,000, depending on the framework, the organization’s starting maturity, and how much outside consulting it needs. The strain is showing. In July, the Department of War suspended Phase 2 of CMMC (Cybersecurity Maturity Model Certification), which would have required third-party assessments for contractors handling controlled unclassified information. It launched a 60-day review with an eye toward easing the burden on small and midsize businesses. Yet the underlying obligations didn’t go away. Contractors working with DoW must still meet compliance standards and submit self-assessment scores. The same burden applies across SOC 2, ISO 27001, HIPAA, HITRUST, FINRA, and NYDFS: implement the controls, keep them running, and prove it. An assembly line that never stops Compliance isn’t a checklist. It’s an assembly line. It starts with policies, asset inventories, and risk assessments. Next come control implementation and employee training. Then the daily grind: monitoring, patching, vulnerability management, incident response, and remediation. Every step must be documented and every control backed by evidence, while systems, users, and regulations keep changing. The day one audit closes, prep for the next one begins. To keep that line moving, a typical organization stitches together more than 20 tools. These span identity management and MFA, endpoint protection (EDR), device management (MDM), firewalls, SIEM, backup, encryption or CMMC enclaves, vulnerability scanning, and many more. On top of the tools come an MSP, a SOC provider, consultants, auditors, and someone to coordinate it all. Controls get applied unevenly, and documentation goes stale. Weeks before the audit, everyone scrambles to reconstruct evidence for controls that may have been working all year. The irony is that most of this effort doesn’t make anyone more secure. It goes into proving security that already exists. Traditional compliance software didn’t fix it The first generation of GRC platforms replaced spreadsheets with dashboards. They centralized policies, mapped controls to frameworks, assigned tasks, and sometimes pulled evidence automatically from cloud services. That was real progress. But it left the hardest part untouched. Somebody still has to deploy endpoint protection, configure MFA, patch systems, encrypt devices, triage alerts, and fix what’s broken. A dashboard can tell you a control exists. It can’t enforce it. Attackers already run at machine speed There’s a second reason manual compliance can’t keep up: the adversary has automated. A CISO I know recently walked me through a breach at his company. The attackers got in and left with the data in seven minutes. No ticket queue, on-call rotation, or morning triage meeting moves that fast. Seven minutes sounds extreme, but the numbers are heading the same way. CrowdStrike reports that the average time for a criminal intruder to move from initial access to other systems fell to 29 minutes in 2025, and the fastest took 27 seconds. Operations by AI-enabled adversaries rose 89 percent. AI is also putting these capabilities in the hands of amateurs. Earlier this year, Amazon’s threat intelligence team found that a single, modestly skilled criminal had used commercial AI tools to break into more than 600 firewalls across 55 countries in about five weeks. Now compare that with how most compliance programs operate: a quarterly access review, a monthly patch window, an alert that sits in a queue over the weekend. A control checked once a quarter won’t stop an attacker who needs seven minutes. When offense runs at machine speed, defense has to as well. That means catching drift the moment it appears, closing the gap automatically, and bringing in a human for the calls that need judgment. The Amazon case holds the most important lesson. The attacker didn’t use a single zero-day. They got in through exposed management ports and passwords without MFA, the same basics every compliance framework already requires. When they ran into hardened environments, they simply moved on to easier targets. Controls that are actually enforced, every day, are what make an organization the harder target. The automation that satisfies the auditor is the same automation that sends attackers looking elsewhere. From compliance dashboards to continuous execution AI-native compliance platforms flip that model. Instead of telling teams what to do, they do the work. Take a control like “ensure unauthorized applications are not used.” A dashboard displays it as a task. An operational platform scans endpoints, detects unapproved software, prioritizes the risk, and removes or quarantines the software according to policy. It logs each action as audit evidence along the way. The same approach applies across the whole lifecycle. The platform drafts policies tailored to the environment and maps one set of controls to CMMC, SOC 2, ISO 27001, and HIPAA at once. It watches endpoints, identities, cloud services, and networks for drift. It investigates alerts around the clock and opens remediation tickets. As a result, evidence becomes a byproduct of daily operations rather than a separate project. Audit prep shrinks dramatically. Instead of a snapshot once a year, organizations can see their real security posture every day. People still make the calls None of this removes the need for security professionals. It changes where they spend their time. AI handles the repetitive work: monitoring, evidence collection, documentation, and routine remediation. Humans own architecture, governance, serious incidents, and decisions about which risks to accept. And a human remains accountable to the auditor for everything the system does. For most SMBs, this is the only realistic path to a mature program. They could never afford to hire the IT, security, compliance, and SOC staff needed to do it all manually. Pairing AI-driven execution with expert oversight lets them raise the bar without growing headcount at the same pace. This is the future The next evolution of compliance platforms is an intelligent, operational layer that drafts policies, implements controls, monitors the environment, assists with remediation, and continuously collects evidence as work happens. The first generation of compliance software helped organizations document security. The next generation will help them operate it. Organizations that embrace this shift won’t simply spend less time preparing for audits. They’ll spend less time managing compliance and more time improving their security, serving their customers, and growing their business.

helpnetsecurity.comOct 8, 2026extracted

Evolution of Web3 in Cloud Supply Chain Attacks

Unit 42 details how threat actors leverage Web3 infrastructure and open-source supply chain attacks to breach enterprise cloud environments The post Evolution of Web3 in Cloud Supply Chain Attacks appeared first on Unit 42 .

unit42.paloaltonetworks.comOct 7, 2026extracted

Building your AI vulnerability harness, Part 1

Vulnerability scanners produce findings faster than manual triage can process them. Your developers ship more code with more dependencies, and the volume of candidate findings grows with it. Many findings a scanner produces are unlikely to be exploited. The ones that matter need to reach an engineer fast, with enough evidence that they can act immediately rather than repeat the analysis. The challenge is separating signal from noise at the speed your pipeline demands. This post shows you how to close the gap between detection and action. We built a three-layer pipeline that takes raw scanner findings and narrows them to a small, prioritized set with documented evidence of exploitability. The companion post, Configuring your AI vulnerability harness , will cover the steering file that drives the model’s behavior inside this pipeline. This post covers the layers around it. Because the pipeline’s value comes from its filtering logic and evidence standards—not from any specific tool—you can substitute your own scanners and models without changing the architecture. Your AI provider, your infrastructure stack, and your scanner ensemble will differ from ours. The architectural decisions—what to filter at each layer, what counts as evidence, where to stop trusting the model—transfer regardless. What a test harness is A test harness is an automated framework that subjects a system to controlled inputs and observes whether outputs match expected behavior. Applied to vulnerability detection, the harness takes each candidate finding, constructs a test to evaluate exploitability, executes that test in a controlled environment, and records the evidence. The harness is the testing infrastructure, not the results it produces. Traditional static application security testing (SAST) tools rely on pattern matching, with data-flow analysis varying by tool and language. They flag known-shape sinks well but struggle with multi-hop chains, business-logic flaws, context-dependent sanitization, and whether a sink is reachable from attacker-controlled input. AI-augmented analysis addresses that reasoning gap: tracing across files, inferring intent, and weighing deployment context. The key conceptual distinction is that we don’t run a model against the codebase. The codebase is context passed to a model with a specific prompt. The model receives code and applies reasoning about how data flows, where trust boundaries exist, and whether security-relevant patterns are present. Context scoping is one of the harder parts of this architecture because too much context can overwhelm the model’s reasoning window, while too little can produce analysis gaps that generate false negatives. For a basic AWS Lambda function, the relevant context might be a single file plus its AWS Identity and Access Management (IAM) role. For a complex microservice with shared libraries and layered infrastructure, deciding what to include requires understanding the application’s dependency graph. The model can reason about your deployment topology if you provide it; for example, by passing AWS Cloud Development Kit (AWS CDK) constructs or AWS CloudFormation templates as additional context. Starting narrow and expanding only when the model’s initial assessment is inconclusive generally produces better results than passing everything at once. Building the pipeline Security scanners can produce high volumes of findings each time they run. Many of these are false positives that look like vulnerabilities but aren’t real issues. To separate real problems from noise, the pipeline filters findings through three layers. Each layer applies a different type of evidence. By the end, a smaller number of prioritized issues backed by documented evidence remains. Layer 1: Multi-scanner agreement Plausibility comes first. Run multiple scanners independently against the same codebase: when two or more converge on the same finding, confidence increases. When only one scanner reports an issue and no other tool agrees, the pipeline flags that finding for extra scrutiny. This approach—called multi-scanner agreement—is a low-cost way to increase confidence. It works with your existing tools and requires no new infrastructure. Layer 2: Structural verification The second layer verifies structure. AI-powered scanners describe how they think a vulnerability works: data enters through one function, passes through another, and reaches a point where it could cause harm. However, these descriptions can be wrong. Before a finding moves forward, the pipeline verifies it against the actual code. It checks to see if the function that the scanner mentioned exists, that the file exists, and if data can flow along the path described by the scanner. If not, the pipeline rejects the finding. This verification step uses the code’s abstract syntax tree (AST): a structured map of how functions, files, and data flows connect in your codebase. This step helps protect the credibility of your pipeline’s output. If unverified findings reach human reviewers, teams quickly learn to distrust the results, which reduces the security value of the tool. Layer 3: Deployment context The final layer adds deployment context. Vulnerabilities exist within the context of an architecture, which might include protective controls. These controls can include AWS WAF rules, network isolation, authentication requirements, and input validation. This layer reads your infrastructure-as-code (IaC) templates—such as CloudFormation or Terraform files that define your cloud architecture—alongside your application source code. It then checks to see if an attacker can exploit a vulnerability by avoiding the controls that are in place. Not all controls provide the same level of protection. A web application firewall rule that directly blocks the relevant attack technique provides stronger mitigation than one that addresses a different type of vulnerability. The pipeline treats control effectiveness as a spectrum, not a yes-or-no checkbox. The result The result is a short list of findings. Each one has cleared all three layers: it passed the plausibility check, its structure checks out against the code, and its deployment context indicates it can be taken advantage of. The number of findings decreases at each layer, and confidence in the remaining findings increases. Principles Four principles emerged from building this pipeline: Progressive filtering with escalating evidence – Each layer demands a different kind of proof. The first layer checks that the finding is plausible. The second determines if it’s structurally real. The third analyzes if it’s exploitable in context. Using three focused layers works better than using one comprehensive layer, because each layer catches a different type of error. Infrastructure context transforms prioritization – Without deployment context, you might assume that a critical-severity finding is more urgent than a medium-severity finding. However, a critical finding behind strong protective controls might be less urgent than a medium finding that’s directly exposed to the internet. To make this assessment, the pipeline needs access to your IaC templates, not only your application source code. Independent agreement outperforms single-tool confidence – No single scanner reliably detects the full range of vulnerabilities. No single model produces correct results across all situations. When multiple independent tools agree on a finding, that agreement provides a stronger signal than one tool’s self-reported confidence score. This principle generally holds across tool choices. AI-generated claims require verification before human review – Language models can produce outputs that sound plausible but might not be correct. Verifying AI-generated findings against the actual code structure—before a human reviews them—is what separates a useful system from one that erodes trust through confident-sounding errors. How to apply this to your stack You don’t need to build everything at once. Adopt them in order of immediate return: Start with indexing – Build (or use) an AST-based index of your codebase that surfaces entry points, sinks, and authentication configuration. This costs nothing to run and gives you a map of your attack surface before any AI is involved. Add multi-scanner triage – Take the output you already get from Semgrep , CodeQL , or equivalent tooling, and run it through the AST gate plus a large language model (LLM) exploitability classification. This delivers substantial noise reduction for a modest investment: you’re filtering output from tools you already run. Add hypothesis generation – After triage is stable, add AI-driven discovery of vulnerabilities scanners miss: multi-hop chains, business-logic flaws, and cross-package data flows. This is the step where steering quality matters a great deal; see Configuring your AI vulnerability harness . Add infrastructure context – Parse your CDK or CloudFormation, map controls to vulnerability classes, and apply the multipliers. This is where your prioritization becomes more targeted. Add live verification – Run proofs of concept (PoCs) against a deployed pre-production target with structured success criteria. This step requires the most operational overhead, so run it last and only for findings that have already passed your confidence threshold. Treat the pipeline as something you tune over time. Validate it against known true and false positives, adjust the weights, and rerun. Your results will change. What this doesn’t solve The harness is detection infrastructure. It helps you see which findings are likely real and which deserve attention first. It doesn’t: Fix the code – Remediation is a separate problem. The harness produces findings with enough evidence that a human or agent can act on them; the act of remediation requires its own tooling and process. Replace human review for final action – Even after three layers of filtering, the output is a prioritized list of likely-exploitable findings, not proven exploits. Priority 0 (P0) findings still warrant review by an engineer before they drive code changes. Catch vulnerability classes outside the scanner ensemble’s detection profile – If none of your scanners look for a particular vulnerability category, the harness won’t surface it. AI-augmented hypothesis generation closes some of this gap, but novel or business-logic flaws still depend on what the model can reason about from code alone. Verify live infrastructure state by default – Parsing IaC tells you what was defined. It doesn’t tell you whether a WAF rule got disabled last week, or whether a security group was modified after deployment. Live verification is an additional integration, not a property of the layers themselves. Each of these limits points to where the architecture extends, not where it breaks. The harness is the first floor of a multi-story system, not the whole building. What comes next In this post, we showed how a three-layer pipeline—multi-scanner agreement, structural verification, and deployment context—narrows scanner output to a small, higher-confidence set of findings that your team can act on. The architecture is tool-agnostic; what transfers is where to filter, what counts as evidence, and when to stop trusting the model. The architecture produces consistent results when the model receives consistent instructions. Our companion post, Configuring your AI vulnerability harness , covers the steering file that encodes this methodology as machine-executable instructions, including the confidence formula, the infrastructure control multipliers, and the verification gates that help prevent hallucinated findings from reaching your engineers. The same model that produces rigorous, evidence-grounded assessments with well-crafted instructions can produce inflated severity ratings and fabricated attack chains without those instructions. Configuration is what turns capability into judgment. The window between disclosure and exploitation is narrowing. Embedding automated detection into your development workflows helps your team keep pace. We built this pipeline through trial and error and are sharing it so you can skip some of the mistakes we made. For more information about the services mentioned in this post, see the AWS Lambda , AWS WAF , and AWS CloudFormation documentation. If you have feedback about this post, leave a comment in the Comments section below. Nidhi Ramakant Nidhi is a Software Development Manager at AWS with two decades of experience in security and enterprise architecture. She’s obsessed with helping customers secure their environments and building creative solutions that make security decisions easier. She’s equally invested in developing the talent around her. Outside work, she’s either binging shows or vibe coding apps for secure local LLMs so her kids can explore and learn safely. Ievgeniia Ieromenko Ievgeniia is a Software Development Engineer at AWS, where she builds tooling and agentic AI systems designed to strengthen security posture without slowing delivery. Outside of work, she enjoys traveling, volunteering, and outdoor adventures with her very good dog, Pickle. Justin Kontny Justin is a Senior Software Engineer, Security, at AWS who blends a passion for software development with deep expertise in cloud security. He focuses on building agentic security solutions using AI-Driven Development Lifecycle (AIDLC) practices, transforming security from a barrier into a business enabler. Outside of work, Justin enjoys spending time with his children and staying active outdoors.

aws.amazon.comOct 7, 2026extracted

FBI: Ongoing FortiBleed attacks lock out FortiGate VPN admins

The FBI is warning that FortiBleed attacks are still ongoing, targeting exposed Fortinet FortiGate firewalls and SSL VPN gateways and locking out legitimate administrators. [...]

bleepingcomputer.comOct 7, 2026extracted

OT Coalition Urges CISA to Mandate Federal OT Security

OTCC urged CISA to mandate baseline security requirements for federal operational technology

infosecurity-magazine.comOct 7, 2026extracted

Gremlin Foresight AI finds system weaknesses and verifies the fixes

Gremlin has announced the general availability of Gremlin Foresight AI. Following a successful beta, Gremlin Foresight AI has proven it can identify and address reliability risks before they become incidents, helping engineering teams move at AI speed without compromising the resilience of mission-critical production systems. “AI-driven development means shipping code at 10X velocity; it also means 10x the opportunity for bugs, risks, and failures,” said Kolton Andrus, CEO of Gremlin. “While the rise of AI … More → The post Gremlin Foresight AI finds system weaknesses and verifies the fixes appeared first on Help Net Security .

helpnetsecurity.comOct 7, 2026extracted

Vijil DART tests AI agents for security flaws and policy violations

Vijil has released Diamond Adaptive Red Teaming for Agents (DART), an automated testing system that finds security vulnerabilities and policy violations in enterprise AI agents. DART employs multiple adversarial agents of its own to probe the target’s defenses with multi-turn attacks that learn and adapt tactics across turns, episodes, and engagements. Using DART, AI developers and application security engineers can find more issues across their agent fleet than with red-team tools and services that use … More → The post Vijil DART tests AI agents for security flaws and policy violations appeared first on Help Net Security .

helpnetsecurity.comOct 7, 2026extracted

Tanium adds endpoint behavior detection and AI-assisted threat hunting

Tanium has relaunched Tanium Security Operations to address AI-assisted attacks in which adversaries use legitimate administrative tools to blend into normal activity and spread across endpoints. The platform is designed to detect this behavior, support response across affected endpoints and help analysts investigate threats. With AI, attackers no longer need malware that a scanner can catch. They sign in with stolen credentials and run the same administrative tools IT uses every day. To a security … More → The post Tanium adds endpoint behavior detection and AI-assisted threat hunting appeared first on Help Net Security .

helpnetsecurity.comOct 7, 2026extracted

FBI, Secret Service add to warnings of FortiBleed credential stealing campaign

FBI, Secret Service add to warnings of FortiBleed credential stealing campaign More than 86,000 internet-facing Fortinet FortiGate firewalls and virtual private network (VPN) gateways have been compromised as part of an ongoing campaign tracked as FortiBleed, according to the FBI and Secret Service. The agencies released an advisory on Tuesday warning organizations that the credential stealing attacks on Fortinet devices have continued for months across 194 countries. The campaign exploits reused or leaked credentials, allowing hackers to “harvest and crack authentication data at scale.” “Initial findings indicate attackers are continuing to scan internet-exposed Fortinet firewalls using previously obtained compromised credentials,” the federal agencies explained. “Affected organizations may find themselves locked out of their systems if threat actors disable accounts or change passwords, requiring remediation steps beyond standard patching and password resets. In addition, the FortiBleed attack chain has been observed as an initial entry point for ransomware affiliates.” The advisory says initial access brokers are also taking part in the campaign and offering their access to ransomware affiliates tied to the INC/Lynx ransomware and Payload ransomware. The FBI and Secret Service noted that the credential-harvesting operation became known to cybersecurity firms and law enforcement after hackers exposed their own backend server, making their internal workflow visible. “The recovered tooling and datasets provide a rare, end-to-end view of how the operators identified targets, validated stolen credentials, and expanded access inside victim networks,” the agencies said. The attackers scanned the internet for exposed FortiGate SSL VPN portals, used automated scripts to identify reachable devices and collected large volumes of credentials and authentication artifacts using credential stuffing and password spraying attacks. Stolen credentials were sorted, validated and organized based on a victim organization’s revenue or network structure. New accounts were created on firewall devices, allowing them to maintain access. Hackers either sold their access to others or used it themselves. The FBI and Secret Service said organizations should review all of their Fortinet accounts and verify their legitimacy. Staying power Cybersecurity experts have warned for months about the FortiBleed campaign. SOCRadar published a lengthy study in July detailing how affiliates of the INC and Lynx groups were taking part in the campaign. An internal tracking file found more than 20 affiliates in defined roles scanning thousands of FortiGate portals across more than 150 countries. At least 12 organizations were breached and encrypted with ransomware. The group also spent heavily on artificial intelligence tools that helped them get past model safety controls and more. The Cybersecurity and Infrastructure Security Agency (CISA) released its own warning about the campaign three months ago alongside officials in the U.K. Russian hackers allegedly used the campaign to break into email accounts of U.K. government officials. The FBI and Secret Service urged organizations to restrict external management of devices or remove internet administration altogether. Credentials should be reset and all admin VPN sessions should be terminated. Jonathan Greig is a Breaking News Reporter at Recorded Future News. Jonathan has worked across the globe as a journalist since 2014. Before moving back to New York City, he worked for news outlets in South Africa, Jordan and Cambodia. He previously covered cybersecurity at ZDNet and TechRepublic.

therecord.mediaOct 7, 2026extracted

Hackers exploit critical Atlassian flaw after public PoC release

A critical vulnerability (CVE-2026-21589) affecting multiple Atlassian product families, including Jira, Confluence, and Bitbucket, is being exploited in attacks that do not require authentication. [...]

bleepingcomputer.comOct 7, 2026extracted

Atlassian Data Center Flaw Draws Exploitation Attempts Within Two Hours of Public Details

Threat actors have begun to exploit a newly disclosed critical security flaw impacting Atlassian Data Center products that could allow access to sensitive files under certain conditions. The arbitrary file access flaw, tracked as CVE-2026-21589 (CVSS score: 9.3) affects multiple products, including Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software

thehackernews.comOct 7, 2026extracted

What Is Agentic Pentesting? What It Proves, and Where It Stops.

If you’re evaluating an agentic pentesting solution right now, you’ve probably heard the same pitch more than once: point it at a target, and it discovers, validates, and exploits attack paths autonomously, the way a real attacker would. That promise is worth taking seriously. It’s also worth pressure testing, and three questions do the heavy lifting.  What can the assessment actually

thehackernews.comOct 7, 2026extracted

Chrome 155 Update Patches 247 Vulnerabilities

Four critical-severity use-after-free defects were fixed in Chromecast, Browser, Navigation, and Track. The post Chrome 155 Update Patches 247 Vulnerabilities appeared first on SecurityWeek .

securityweek.comOct 7, 2026extracted

Musician sent to prison for $10 million streaming fraud using AI bots

A North Carolina musician was sentenced to 18 months in prison for collecting more than $10 million in royalties from Spotify, Apple Music, Amazon Music, and YouTube Music in a massive streaming royalty fraud scheme. [...]

bleepingcomputer.comOct 7, 2026extracted

Advantest confirms personal information stolen in ransomware attack

Advantest Corporation is notifying affected individuals that a ransomware attack earlier this year exposed their personally identifiable data. [...]

bleepingcomputer.comOct 7, 2026extracted

Wikimedia Says Rogue OpenAI Agents Tried to Turn Its Tools Into Proxies

Wikimedia looked into whether its own websites had seen activity like that disclosed by other organizations The post Wikimedia Says Rogue OpenAI Agents Tried to Turn Its Tools Into Proxies appeared first on SecurityWeek .

securityweek.comOct 7, 2026extracted

Android’s October 2026 Updates Patch 25 Vulnerabilities

The patches resolve a critical vulnerability in Android’s System component that could lead to privilege escalation. The post Android’s October 2026 Updates Patch 25 Vulnerabilities appeared first on SecurityWeek .

securityweek.comOct 7, 2026extracted

AI endpoint management: Visibility, compliance, and remediation

AI endpoint management: Visibility, compliance, and remediation Endpoint estates are growing faster than the teams that look after them. Hybrid work, cloud adoption, contractor laptops, a steady stream of new CVEs, and rising compliance pressure mean security teams manage more devices, more software, and more exceptions than a spreadsheet or a monthly scan can hold. Manual tracking and manual remediation no longer keep up. AI endpoint management offers a way out. Used well, it helps teams see what is actually on the network, spot compliance gaps as they open, and fix the highest-risk problems first. The shift is from reactive clean-up to continuous, prioritized action. This article looks at where AI helps across endpoint visibility, compliance, and remediation, and where it doesn’t. Why endpoint visibility is still a security challenge Most organizations can tell you how many endpoints they think they have. Fewer can tell you how many they actually have, where those devices are, and what state they are in today. The gaps are familiar. Inventory goes stale between scans. Remote devices touch the corporate network rarely, or never. Unmanaged endpoints and shadow IT sit outside the tooling entirely. Software data differs between the CMDB, the vulnerability scanner, and the patching tool, so three teams argue about which number is right. This matters because everything else depends on it. A team can’t patch a device it doesn’t know about, and it can’t prove compliance for one it can’t see. Every blind spot works against attack surface reduction, and attackers only need one. Endpoint visibility is the foundation, and it is where endpoint risk quietly starts to accumulate. The role of AI in making endpoint data more actionable Visibility produces data, and data at enterprise scale creates its own problem. Tens of thousands of devices, each reporting software versions, configuration states, missing patches, and policy results, generate more findings than any team can read. This is where AI earns its place. Its most useful jobs are unglamorous: Surfacing abnormal endpoint states, such as a device drifting from its baseline or an agent that quietly stopped reporting. Grouping similar risks, so thousands of findings collapse into a handful of root causes. Prioritizing vulnerable assets by exposure and business importance rather than raw severity score. Summarizing exposure in plain terms for people who won’t open the console. Reducing alert fatigue by suppressing duplicates and noise. None of this replaces analyst judgment. It removes the manual analysis that sits between a finding and a decision, so people spend their time deciding what to do rather than working out what they are looking at. Improving compliance with continuous intelligence A point-in-time audit describes how an environment looked on the day of the audit. Endpoint posture changes daily: a patch fails, a setting is reverted, a new device joins with a default configuration. By the next audit, the evidence is already out of date. Endpoint compliance works better as a continuous process. AI-assisted monitoring can flag policy drift, missing patches, and configuration gaps against frameworks such as CIS, DISA STIG, PCI-DSS, and NIST as they appear, not weeks later. Teams can fix a gap before it becomes an audit finding, and produce proof of compliance from current data instead of a scramble of exports. That is audit readiness in practice: policy enforcement that runs continuously, not a clean-up before the auditors arrive. The practical test for any endpoint security compliance software is whether it can show, for a given device and a given control, what the state is now, when it last changed, and what was done about it. Accelerating remediation with AI-powered prioritization Not every vulnerability deserves the same urgency. CVE volume keeps climbing, patch backlogs rarely shrink, and remediation SLAs assume teams can act on everything at once. They can’t. AI-assisted prioritization helps by weighing what actually changes risk: whether a flaw is being exploited in the wild, how severe it is, how exposed the affected device is, and how important that asset is to the business. A critical vulnerability on an internet-facing server under active exploitation shouldn’t sit in the same queue as a medium-severity issue on a lab machine. It also makes emergency patching manageable. When a widely exploited vulnerability lands, the team needs to know within minutes which critical assets are affected and what to fix first, not after a week of reconciling spreadsheets. Sources such as CISA’s Known Exploited Vulnerabilities catalog give that prioritization a factual anchor. From detection to action: Closing the remediation loop Visibility and prioritization only matter if teams can act on them. Plenty of organizations have excellent dashboards and slow remediation, because the handoff from insight to action is still manual: a ticket, a change window, a script someone has to write. AI-powered endpoint management should close that loop. In practice, that means automated remediation for routine cases and controlled workflows for risky ones: Patch automation and policy-based remediation, so approved fixes deploy without a ticket for every device. Rollback planning, so a bad patch doesn’t become an outage. Deployment verification and failed-patch detection, so “deployed” means “fixed,” not “sent.” Reporting that shows before and after, for auditors and leadership. Teams skip the last two most often. A remediation program that can’t prove a fix landed is a hope, not a control. Where HCL BigFix fits HCL BigFix is an endpoint management platform built around this idea: one agent and one console for discovering, patching, securing, and reporting on endpoints at scale. It covers endpoint discovery, patch management, compliance, vulnerability remediation, and automation across more than 120 operating systems, including endpoints that are remote or disconnected from the corporate network. On the intelligence side, HCL BigFix correlates vulnerability data to available patches and prioritizes remediation using threat context such as CISA KEV, so teams can move from a finding to a fix in the same platform. Compliance content maps to common frameworks, and reporting supports endpoint risk reduction from the console through to the audit. The aim matches the rest of this article: connect the insight to the action. What security leaders should look for For readers evaluating tools, a short checklist: Continuous endpoint visibility, including remote and intermittently connected devices Risk-based prioritization that accounts for exploitability and asset importance Automated remediation with approval controls and rollback Compliance reporting mapped to the frameworks you are audited against Integration with vulnerability scanners, SIEM, and ITSM tools Explainable insights, so analysts can see why something ranked first Cross-platform support across Windows, macOS, Linux, and UNIX Proof of remediation: verified fixes, not just deployment logs Ask vendors to demonstrate the last three with your data. They are the easiest to promise and the hardest to deliver. Conclusion AI endpoint management can help security teams see more, prove compliance continuously, and fix what matters first. But the value comes from connecting each step: visibility feeds prioritization, prioritization drives automated remediation, and verification proves the result. Teams that close that loop improve cyber hygiene and shrink the attack surface they have to defend. Teams that stop at better dashboards will still be waiting on the next patch cycle. Frequently asked questions What is AI endpoint management? AI endpoint management uses machine learning and automation to discover, monitor, prioritize, and fix issues across an organization’s devices. It analyzes data such as software inventory, patch status, and configuration state to show where risk is highest. The goal is to move teams from manual tracking to faster, prioritized action. How does AI improve endpoint visibility? AI helps make sense of large volumes of endpoint data. It can flag devices that drift from their baseline, surface agents that have stopped reporting, and highlight gaps between inconsistent inventory sources. Teams get a clearer picture of what exists, where it is, and what state it is in. Can AI help with endpoint compliance? Yes. Continuous monitoring can flag policy drift, missing patches, and configuration gaps against frameworks such as CIS, DISA STIG, and PCI-DSS as they appear, rather than at the next audit. This gives teams current evidence for auditors and time to fix gaps before they become findings. How does AI help prioritize vulnerability remediation? It weighs factors such as active exploitation, severity, device exposure, and asset importance, instead of ranking by severity score alone. Threat sources like CISA’s Known Exploited Vulnerabilities catalog add a factual anchor. Teams can then fix the issues most likely to be used against them first. Is automated remediation safe? It can be, with the right controls. Approval workflows, rollback plans, and deployment verification keep a bad patch from becoming an outage and confirm that fixes actually landed. A common approach is to automate routine, low-risk fixes first and keep human review for critical systems. Will AI replace security and IT teams? No. AI reduces manual analysis and repetitive remediation work, but people still set policy, approve risky changes, and judge trade-offs. Its value is giving teams time back for decisions that need human judgment.

helpnetsecurity.comOct 7, 2026extracted

Even with OT network visibility, critical infrastructure operators struggle with legacy equipment

Even with OT network visibility, critical infrastructure operators struggle with legacy equipment Large critical infrastructure operators run seven separate security tools on average, and most still cannot see every asset on their operational technology (OT) networks. That is the picture from a Palo Alto Networks survey of more than 1,600 security and operations leaders. Old equipment stays on the network Legacy OT is the most common visibility problem, named by 52 percent of respondents. Another 42 percent call legacy equipment that cannot be patched their biggest cybersecurity risk. Even among respondents who say they see everything, 49 percent still list legacy OT as a challenge. Knowing a machine is there does not update its software. “Cybersecurity in critical infrastructure today is at a dangerous point where we’ve connected decades-old OT to modern networks faster than we’ve updated the security models needed to protect them,” said a VP of IT at a US manufacturer. Buying more tools did not fix it Fifty-nine percent of respondents say the tools make operations more complicated, and 56 percent report higher operating costs. Just over half still sort alerts with a standard severity score or by hand. If your team has added a tool every time a new gap turned up, this is the pattern the survey describes. Breaches were common last year Fifty-nine percent had a significant security breach in the past twelve months, and one in five was hit more than once. Half of respondents list safety concerns among the impacts of incidents, and unplanned downtime costs a mean of $288,563 per hour. Containment is getting faster from a low start. Fifteen percent now contain incidents in minutes through automation, up from 10 percent a year ago. Fifty-one percent want to be there within the next twelve months. Fifteen percent are there today. AI is the next worry Ninety-five percent are concerned about attacks powered by what the survey calls Frontier AI, and 91 percent expect AI-driven security tools to help defend against them. Few have much AI in place yet. Only 19 percent use it across four or more operational areas, and those areas include process optimization and predictive maintenance, so the figure is not limited to security. IT and OT teams still work apart Seventy-four percent have not integrated their IT and OT security operations. Among them, 44 percent point to incompatible technology and 44 percent to differing priorities between the two teams. Automated alert correlation tops the wish list for closing the divide. Fifty-two percent of respondents picked it as the thing that would most speed IT and OT convergence over the next two years. Webinar: Closing the accountability gap in AI-assisted delivery

helpnetsecurity.comOct 7, 2026extracted

Improving SPIRE security and resiliency with AWS managed services

In cloud-centered environments, establishing trust between workloads is fundamental to securing machine-to-machine communication. Traditional approaches such as API keys, shared secrets, and static service account credentials weren’t designed for the scale and ephemeral nature of cloud workloads. This drives an organizational need to shift from long-term, static credentials to short-lived cryptographic workload identities. Organizations are turning to SPIFFE (Secure Production Identity Framework for Everyone) as a core component of their workload identity strategy. SPIFFE is a set of open source standards for securely identifying software systems in dynamic and heterogeneous environments. Using SPIFFE can help address what’s known as the bottom turtle problem: the circular dependency where protecting one credential requires yet another credential. SPIRE (the SPIFFE Runtime Environment) is an open source implementation of SPIFFE. Customers can use it to quickly experiment with the framework. However, there are operational and security considerations when deploying SPIRE in production, such as: Where cryptographic signing keys for workload identities are managed How to ensure availability and resiliency of the workload identity registry How the SPIRE Certificate Authority integrates into the existing enterprise PKI How workloads without direct connectivity to the SPIRE server validate identities How workload identities are delivered to serverless environments How fine-grained authorization based on SPIFFE IDs is enforced In this post, we show you how to address each of these considerations by offloading SPIRE core functionality to AWS managed services. This post is accompanied by a Github Repository that guides you through the deployment of the reference architecture. To learn the core concepts the SPIFFE framework, take a moment to familiarize yourself with the SPIFFE documentation . SPIRE background A SPIRE deployment is comprised of at least one SPIRE Server, at least one SPIRE Agent, and at least one workload. Figure 1: SPIRE high-level architecture The SPIRE Server is deployed on a central control plane instance (or instances) and manages identity issuance and stores workload identity registrations. The SPIRE server handles five key functions: RegistrationAPI : Create, update, and delete registration entries that define which workloads are entitled to specific SPIFFE IDs based on selectors (for example, Kubernetes namespace, Unix UID). DataStore : The SPIRE server uses a data store to keep track of the workload identity registration entries and the status of the SVIDs it has issued. KeyManager : Controls how the server manages private keys used to sign X.509-SVIDs and JWT-SVIDs. BundlePublisher : Publishes the local trust bundle to a store. The trust bundle is an object containing a trust domain’s cryptographic keys UpstreamAuthority : Dictates which root certificate authority is used to sign the SPIRE certificate authority (CA) certificate The SPIRE Agent is distributed across your workloads, whether they run on Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Container Service (Amazon ECS) containers, or Amazon Elastic Kubernetes Service (Amazon EKS) Pods. The SPIRE Agent handles: WorkloadAPI : Exposes the workload API to workloads, which enable workloads to retrieve their SVIDs and trust bundles from the SPIRE server. NodeAttestation : SPIRE requires that each agent attest and verify itself. WorkloadAttestation : The SPIRE agent collects workload metadata to determine its identity. SVIDStore : The SPIRE Agent also stores SVIDs in other destinations, such as AWS Secrets Manager or HashiCorp Vault making them available for workloads running in serverless environments. After the server and agent are deployed, applications retrieve short-lived SPIFFE Verifiable Identity Documents ( X.509 Certificates or JSON Web Tokens (JWTs) ) using the workload API. How to use AWS managed services for core SPIRE functions In the following sections, we dive deeper into what each of these SPIRE functions does and the advantages of using each AWS service for the function. Figure 2: SPIFFE architecture using AWS managed services To deploy the infrastructure required to follow along with this post, follow the deployment process in the Github Repository . Note : For each managed service, there’s a parameter in the source AWS CloudFormation templates that you can use to specify whether to provision the resource. For example, if you already have an AWS Private Certificate Authority (AWS Private CA) certificate authority deployed in your environment, you can use that for your SPIRE implementation and avoid provisioning a new certificate authority. SPIRE Key Manager using AWS KMS The SPIRE Key Manager controls the cryptographic keys that are used to sign SPIFFE Verifiable Identity Documents (SVIDs), which are either X.509 certificates or JWTs. By using SPIRE, you can configure the cryptographic keys to be either stored in memory or on disk, or to use a plugin where external keys are used for signing SVIDs. By using the AWS KMS plugin for SPIRE , you bring the security benefits of AWS KMS to your SPIRE implementation. HSMs : AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-3 Level 2 Key protection : Your plaintext AWS KMS keys don’t leave the HSMs, aren’t written to disk, and are only used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation Comprehensive auditing : Each request to use the keys for signing must be authenticated using Signature Version 4 (SigV4) and is audited and logged in AWS CloudTrail Fine-grained access control: Use AWS KMS Key Policies to restrict access to your signing keys This configuration block indicates to SPIRE that AWS KMS keys are used to sign our SVIDs: KeyManager "aws_kms" { plugin_data { region = "<your-region>" key_identifier_file = "./key_metadata" } } This code block exists in the SPIRE server configuration deployed in the Github repository. SPIRE datastore using Amazon Aurora The SPIRE server uses a data store to keep track of the workload identity registration entries as well as the status of the SVIDs it has issued. By default, the datastore lives as an SQLite database in memory. However, you can configure the SPIRE server to use Amazon Aurora . By doing this, you can decouple the database from the server and offload the operational overhead of managing the datastore to AWS. Benefits: High availability : Automatic failover and multi-Availability Zone deployments Automated backups : Point-in-time recovery and automated backup retention Scalability : Scale compute and storage independently Security : Encryption at rest and in transit, with AWS Identity and Access Management (IAM) Monitoring : Built-in performance insights and enhanced monitoring Reduced operational burden : Automated patching, maintenance, and updates To do this, the CloudFormation stack provisions: An Aurora PostgreSQL Cluster A database user with the capability to authenticate through AWS IAM Network connectivity between your SPIRE Server and the database After the sample finishes deployment, the configuration in the SPIRE server is changed from the default: DataStore "sql" { plugin_data { database_type = "sqlite3" connection_string = "/opt/spire/data/server/datastore.sqlite3" } } To: DataStore "sql" { plugin_data { database_type "aws_postgres" { region = "<region>" } connection_string = "dbname=<dbname> user=spiffe host=<your_db_endpoint> port=<your_port>" } } For more information, see Datastore SQL Plugin . SPIRE certificate authority using AWS Private Certificate Authority The SPIRE Server issues SVIDs to SPIRE agents and workloads. Given that these SVIDs are X.509 certificates, the SPIRE server needs to act as a certificate authority. In the default configuration of SPIRE, the server generates a self-signed certificate that it will use as the root CA certificate. In production scenarios, organizations often use their existing AWS Private CA certificate authority hierarchy. Using the AWS Private CA plugin for SPIRE, you configure the SPIRE CA to act as an issuing certificate authority that chains to your existing root CA. This delivers three benefits for your SPIRE implementation: HSM-backed root of trust : The root of trust of your CA hierarchy is backed by fully managed, FIPS 140-2 Level 3 validated hardware security modules Non-exportable private keys : The private keys for the root CA can’t be exported Fully Managed Certificate Revocation Lists and OCSP endpoint : In case the issuing CA certificate needs to be revoked Note : If the SPIRE CA certificate will be signed by an issuing CA, you need to ensure that the path length of that CA is at least 1. The sample code provisions a root CA, so this isn’t an issue if you’re following the sample code. After the sample deployment is complete, the configuration of the SPIRE server configuration includes the UpstreamAuthority plugin to use your AWS Private CA certificate authority as the root of trust. UpstreamAuthority "aws_pca" { plugin_data { region = "<aws_region>" certificate_authority_arn = "<your_pca_arn>" ca_signing_template_arn = "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1" } } For more information, see the AWS Private CA upstream authority plugin documentation . SPIRE bundle publisher using Amazon S3 In SPIFFE, trust bundles are sets of public keys that are used by destination workloads to verify the identity of source workloads. These bundles contain the root certificates and public keys used to sign JWT SVIDs. The SPIRE Server supports exposing an endpoint containing this trust bundle or publishing the bundle to Amazon Simple Storage Service (Amazon S3) . By publishing the bundle to Amazon S3, you can: Decouple : Decouple bundle access from the SPIRE server availability Continuous validation : Allow destination workloads to continually validate source workload identities without requiring network access to the SPIRE server Global distribution : Distribute the trust bundle using Amazon CloudFront , improving performance through the CloudFront global edge network with over 750 Points of Presence Reduced load : Offload trust bundle retrieval traffic from the SPIRE server Version control : Maintain historical versions of trust bundles with S3 versioning The following is a sample configuration for this plugin: BundlePublisher "aws_s3" { plugin_data { region = "<your_bucket_region>" bucket = "<your_bucket_name>" object_key = "<your_bundle_name" format = "spiffe" } } For more information, see S3 Bundle Publisher Plugin Reference . SPIRE Agent SVID store using Secrets Manager In a typical SPIRE implementation, SVIDs are retrieved from the workload API using the SPIRE agent by workloads. In serverless or container cases, it isn’t feasible or possible to run the SPIRE agent, especially in workloads running on AWS Lambda or an AI agent running in Amazon Bedrock AgentCore Runtime . In these scenarios, use the SVID store plugin to push the SVID to Secrets Manager . In this scenario, you still need a SPIRE agent running on a node that performs node attestation with the SPIRE server and delivers the SVID to a secrets store. One of the available secrets store plugins is the AWS Secrets Manager SVIDStore Plugin . Benefits: Encryption at rest : Secrets are encrypted by default using AWS managed or customer-managed AWS KMS keys Broad integration : Integrations with multiple compute types, including AWS Secrets Manager Lambda Extension , Amazon ECS , Amazon EMR , and 52 other AWS services Client-side caching : Secrets Manager provides client-side caching libraries to improve performance and reduce API calls Multi-region replication : Built-in multi-Region replication functionality for workloads with multi-region requirements Fine-grained access control : Use resource policies to control which workloads access which SVIDs Audit trail : All secret access is logged in CloudTrail This plugin is configured in the agent , as opposed to the SPIRE server. A reference for the specific permissions required are in the plugin Github repository . In the sample code, see the configuration in the following agent.conf file: SVIDStore "aws_secretsmanager" { plugin_data { region = "<your_region>" } } When you need to specify a given workload’s SVID to be pushed to Secrets Manager, you add the storeSVID and selector parameters when you create the entry in the workload registry. If you’re managing your SPIRE server in Kubernetes, the appropriate command looks like: kubectl exec -n spire spire-server-<postfix>-- \ /opt/spire/bin/spire-server entry create \ -spiffeID spiffe://example.org/<workload_name> \ -parentID spiffe://example.org/ns/spire/sa/spire-agent \ -selector aws_secretsmanager:secretname:<workload_name> \ -storeSVID Fine-grained access control using Verified Permissions Up to this point, all the managed services we’ve talked about have been used for creating and distributing SVIDs and trust bundles to workloads. However, a key advantage of using a framework such as SPIFFE is that it allows resource owners to protect resources with fine-grained access control. One managed service that helps you do that in the context of SPIFFE and SPIRE implementations is Amazon Verified Permissions . Verified Permissions is a scalable, fine-grained permissions management and authorization service that helps you build secure applications. You can use it to: Define declarative policies : Use Cedar policy language , which provides human-readable, declarative access control rules Centralize policy management : Separate authorization logic from application code Take advantage of the straightforward policy authoring, formal verification capabilities, and performance benefits of Cedar Make real-time decisions : Evaluate authorization requests in real-time based on multiple factors including user identity, workload identity (SPIFFE ID), resource attributes, and contextual information Integrate with identity providers : Support for OpenID Connect (OIDC) providers, enabling validation of JWT tokens including JWT-SVIDs With Verified Permissions, you authenticate SPIRE issued SVIDs using the public keys associated with your trust domain, and deploy fine-grained authorization policies protecting your resources. To use Verified Permissions, you need a policy store, an identity source , and authorization policies . The github sample creates a policy store on your behalf and sets up the necessary infrastructure to have SPIRE serve as an identity source for your policy store. You will need policies to enforce fine grained authorization. The following sample policy forbids a specific workload from taking any action: forbid( principal, action, resource ) when { context has sub && context.sub like "spiffe://example.org/forbidden-workload/*" }; Or conversely allows a specific workload to take actions: permit( principal, action, resource ) when { context has sub && context.sub like "spiffe://example.org/allowed-workload/*" }; Experiment with these policies as you build on top of your SPIRE infrastructure. Conclusion This post demonstrates how organizations enhance their SPIRE deployments on AWS by replacing default implementations with AWS managed services. We showed you integrations with AWS KMS for SVID signing, Amazon RDS Aurora for managed datastore operations, AWS Private Certificate Authority for root of trust, Amazon S3 and CloudFront for global trust bundle distribution, AWS Secrets Manager for SVID storage, and Amazon Verified Permissions for fine-grained authorization. By adopting these integrations, organizations can improve security posture, reduce operational complexity, and enhance resiliency. If you’re interested in learning SPIFFE on AWS, check out our SPIRE on AWS github sample or the SPIFFE and SPIRE on AWS Workshop for hands-on learning. If you have feedback about this post, submit comments in the Comments section below. Brendan Paul Brendan is a Security Services SA Manager at AWS and has been at AWS for more than 7 years. He spends most of his time at work helping customers solve problems in the data protection and workload identity domains. Outside of work, he’s pursuing his master’s degree in data science from UC Berkeley. Meg Peddada Meg is a Principal FSI Security Solutions architect specializing in security, risk, and compliance. Her expertise spans governance, security automations, threat management, and architecture. In her spare time, she loves playing volleyball, arts and crafts, and finding new brunch experiences.

aws.amazon.comOct 6, 2026extracted

Rogue OpenAI agents made unauthorized Wikipedia edits and millions of requests to Wikimedia

Rogue OpenAI agents made unauthorized edits on Wikimedia wikis and sent millions of automated requests to Wikimedia’s public APIs, traffic that may have contributed to a partial outage of the Wikidata Query Service in May, the Wikimedia Foundation said on Monday. “The Wikimedia Foundation conducted its own investigation to see whether Wikimedia websites had been similarly affected by AI agents, focusing on those operated by OpenAI,” wrote Selena Deckelmann, Wikimedia Chief Product and Technology Officer. … More → The post Rogue OpenAI agents made unauthorized Wikipedia edits and millions of requests to Wikimedia appeared first on Help Net Security .

helpnetsecurity.comOct 6, 2026extracted

SailPoint adds AI agent discovery, temporary access and compliance automation

SailPoint has announced significant new capabilities across SailPoint Agentic Fabric (SAF) and SailPoint Human Fabric (SHF), the two purpose-built products of its Identity Security solution, built on SailPoint Atlas. These innovations give enterprises visibility into every hidden AI tool, continuous compliance across human and machine workflows, the replacement of permanent access keys with temporary permissions, and the transformation of identity security from a static compliance check into real-time, automated defense. According to the latest SailPoint … More → The post SailPoint adds AI agent discovery, temporary access and compliance automation appeared first on Help Net Security .

helpnetsecurity.comOct 6, 2026extracted

AXON Datum enforces data access policies before AI systems act

AXON Networks has announced AXON Datum, a data management and secure sovereign governance layer that helps service providers, enterprises, and institutions such as governments control how information is accessed, protected and moved in an AI world. Critical to the success of every telecom and government moving into agentic AI who want the data and AI operating on it to stay under their own control, AXON Datum closes the gap between current data lake architecture and … More → The post AXON Datum enforces data access policies before AI systems act appeared first on Help Net Security .

helpnetsecurity.comOct 6, 2026extracted

Apple to Tighten Full Disk Access Controls in macOS Amid AI Risks

Citing growing risks posed by more capable and autonomous AI agents, Apple will introduce additional controls. The post Apple to Tighten Full Disk Access Controls in macOS Amid AI Risks appeared first on SecurityWeek .

securityweek.comOct 6, 2026extracted

Wikimedia: Rogue OpenAI agents behind unauthorized Wikipedia edits

The Wikimedia Foundation says rogue OpenAI agents made unauthorized Wikipedia edits and may have been partially responsible for a May outage. [...]

bleepingcomputer.comOct 6, 2026extracted

Wikimedia Says OpenAI Agents Tried to Compromise Etherpad and Use Wiki Tools as Proxies

The Wikimedia Foundation, which hosts Wikipedia, has confirmed that it has discovered activity by rogue OpenAI agents on its platforms, including unsuccessful efforts to compromise Etherpad, a public note-taking tool, and edit Wikipedia pages. "The unauthorized bot activities included edits to our wikis, some unsuccessful attempts to exploit a public note-taking tool we host, and heavy traffic,

thehackernews.comOct 6, 2026extracted

Domino’s customers targeted in credential stuffing attacks

Domino’s Pizza customers tell us they have received emails saying they account has been accessed by a third party. Domino’s says its internal systems weren’t breached, but that individual accounts were logged into using a password and email combination stolen from another online account owned by the customer. This is known as credential stuffing. Here’s the email: “We’re getting in touch to let you know that we believe a very small number of Domino’s customer accounts were accessed by an unauthorised third party, and unfortunately your account is one of those affected. We want to reassure you that our security systems have not been breached. We also don’t store any payment details, so no financial information has been accessed. It appears that you have used a password for your Domino’s account which you have used on other sites, which was already out there because of a previous data breach unrelated to Domino’s. An unauthorised third party has used this to obtain access to your account. As a precaution, we’ve reset your account. You can still place orders as normal, but the next time you log in you’ll need to set a new password using the ‘Forgotten password’ link. We recommend choosing a strong, unique password that you haven’t used elsewhere. Please avoid reusing your previous password. Keeping your information safe is really important to us. We’ve reported this incident to the Information Commissioner’s Office and included some FAQs below if you’d like more detail. If you have any questions, our Customer Services team will be happy to help on 0800 640 9071. ” Credential stuffing is an attack where criminals take usernames and passwords stolen from one website and try them on many other websites. They don’t guess the passwords. They already have them, often millions at a time, from old data breaches, from malware that steals saved logins from people’s computers, or from phishing sites. These lists are bought and sold on criminal forums. Attackers then use automated tools that run through the list and try each email and password pair against a login page, such as a food delivery app, a web shop, or a streaming service. The attack works because so many people reuse the same password on different sites. If you used the same email and password for a small online forum that was breached years ago and for your pizza ordering account, the criminals don’t need to hack the pizza company at all. They just log in as you. To the company, it looks like a normal login with the correct password. That’s why these attacks often show up as “accounts were accessed” and not “the company was hacked.” Once they’re in, attackers can order food or goods using your saved payment card, use up loyalty points or gift card balances, or collect your name, address, and phone number. They can use those details for more convincing scams later, for example a text or email that seems to come from the company because it knows what you ordered. Accounts that are confirmed to work are also resold to other criminals, so one reused password can cause trouble long after the original breach. How to stay safe Use a different password for every account. That way, a breach at one site stays at that site. Use a password manager to remember those passwords. Nobody can remember dozens of unique passwords, but a password manager can store all these for you. Where it’s offered, turn on two-factor authentication (a code from an app or text message, or a passkey) so a stolen password alone isn’t enough to login to your account. If you’ve reused a password on an account that may have been affected, change it there and on every other site where you used it, starting with accounts that have payment details saved. Don’t follow links in emails or other unsolicited messaging. Log in directly on the official website or in the app. Please note: Unsolicited “update your account” emails claiming to be from Domino’s are frequently phishing attempts designed to steal personal or financial information. When in doubt, Malwarebytes Scam Guard can help you determine whether a message is a scam or not and suggest follow-up steps. What do cybercriminals know about you? Use Malwarebytes’ free Digital Footprint scan to see whether your personal information has been exposed online. SCAN NOW

malwarebytes.comOct 6, 2026extracted

Welcome to the Jungle: What We Found Inside 15,465 Public MCP Servers

In 2024, MCP (Model Context Protocol) set out to become the USB-C of AI: one standard for connecting models, agents, and IDEs to tools and data. The protocol delivered. Thousands of developers built servers, and enterprises plugged them into agent workflows. The ecosystem around it fell short. Earlier this year, our team at OX Security,  traced critical vulnerabilities in Anthropic's MCP

thehackernews.comOct 6, 2026extracted

Blinder Tunnel Campaign Targets Iraqi Infrastructure

Analysis of Blinder Tunnel, an Iran-nexus campaign using fake Dubai Airports recruitment lures and GitHub C2 malware to target critical infrastructure. The post Blinder Tunnel Campaign Targets Iraqi Infrastructure appeared first on Unit 42 .

unit42.paloaltonetworks.comOct 6, 2026extracted