Blog
/
OT
/
December 16, 2024

Breaking Down Nation State Attacks on Supply Chains

Explore how nation-state supply chain attacks like 3CX, NotPetya, and SolarWinds exploited trusted providers to cause global disruption, highlighting the urgent need for robust security measures.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Benjamin Druttman
Cyber Security AI Technical Instructor
Default blog image
16
Dec 2024

Introduction: Nation state attacks on supply chains

In recent years, supply chain attacks have surged in both frequency and sophistication, evolving into one of the most severe threats to organizations across almost every industry. By exploiting third-party vendors and service providers, these attacks can inflict widespread disruption with a single breach. They have become a go-to choice for nation state actors and show no signs of slowing down. According to Gartner, the costs from these attacks will skyrocket “from $46 billion in 2023 to $138 billion by 2031” [1].  

But why are supply chains specifically such an irresistible target for threat actors? Dwight D. Eisenhower, the General of the US Army in World War II and former US President, once said, “you won’t find it difficult to prove that battles, campaigns, and even wars have been won or lost primarily because of logistics.”

The same is true in cyberspace and cyberwarfare. We live in an increasingly interconnected world. The provision of almost every service integral to our daily lives relies on a complex web of interdependent third parties.  

Naturally, threat actors gravitate towards these service providers. By compromising just one of them, they can spread through supply chains downstream to other organizations and raise the odds of winning their battle, campaign, or war.  

software supply chain sequence
Figure 1: Software supply chain attack cycle

A house built on open-source sand

Software developers face immense pressure to produce functional code quickly, often under tight deadlines. Adding to this challenge is the need to comply with stringent security requirements set by their DevSecOps counterparts, who aim to ensure that code is safe from vulnerabilities.  

Open-source repositories alleviate some of this pressure by providing pre-built packages of code and fully functioning tools that developers can freely access and integrate. These highly accessible resources enhance productivity and boost innovation. As a result, they have a huge, diverse user base spanning industries and geographies. However, given their extensive adoption, any security lapse can result in widespread compromise across businesses.

Cautionary tales for open-source dependencies

This is exactly what happened in December 2021 when a remote code execution vulnerability was discovered in Log4J’s software. In simple terms, it exposed an alarmingly straightforward way for attackers to take control of any system using Log4J.  

The scope for potential attack was unprecedented. Some estimates say up to 3 billion devices were affected worldwide, in what was quickly labelled the “single biggest, most critical vulnerability of the last decade” [2].

What ensued was a race between opportunistic nefarious actors and panicked security professionals. The astronomical number of vulnerable devices laid expansive groundwork for attackers, who quickly began probing potentially exploitable systems. 48% of corporate networks globally were scanned for the vulnerability, while security teams scrambled to apply the remediating patch [3].

The vulnerability attracted nation states like a moth to a flame, who, unsurprisingly, beat many security teams to it. According to the FBI and the US Cybersecurity and Infrastructure Agency (CISA), Iranian government-sponsored threat groups were found using the Log4J vulnerability to install cryptomining software, credential stealers and Ngrok reverse proxies onto no less than US Federal networks [4].  

Research from Microsoft and Mandiant revealed nation state groups from China, North Korea and Turkey also taking advantage of the Log4J vulnerability to deploy malware on target systems [5].  

If Log4j taught us anything, it’s that vulnerabilities in open-source technologies can be highly attractive target for nation states. When these technologies are universally adopted, geopolitical adversaries have a much wider net of opportunity to successfully weaponize them.  

It therefore comes as no surprise that nation states have ramped up their operations targeting the open-source link of the supply chain in recent years.  

Since 2020, there has been a 1300% increase in malicious threats circulating on open-source repositories. PyPI is the official open-source code repository for programming done in the Python language and used by over 800,000 developers worldwide. In the first 9 months of 2023 alone, 7,000 malicious packages were found on PyPI, some of which were linked to the North Korea state-sponsored threat group, Lazarus [6].  

Most of them were found using a technique called typosquatting, in which the malicious payloads are disguised with names that very closely resemble those of legitimate packages, ready for download by an unwitting software developer. This trickery of the eye is an example of social engineering in the supply chain.  

A hop, skip, and a jump into the most sensitive networks on earth

One of the most high-profile supply chain attacks in recent history occurred in 2023, targeting 3CX’s Desktop App – a widely used video communications by over 600,000 customers in various sectors such as aerospace, healthcare and hospitality.

The incident gained notoriety as a double supply chain attack. The initial breach originated from financial trading software called X_Trader, which had been infected with a backdoor.  A 3CX employee unknowingly downloaded the compromised X_Trader software onto a corporate device. This allowed attackers to steal the employee’s credentials and use them to gain access to 3CX’s network, spread laterally and compromising Windows and Mac systems.  

The attack moved along another link of the supply chain to several of 3CX’s customers, impacting critical national infrastructure like energy sector in US and Europe.  

For the average software provider, this attack shed more light on how a compromise of their technology could cause chaos for their customers.  

But nation states already knew this. The 3CX attack was attributed, yet again, to Lazarus, the same North Korean nation state blamed for implanting malicious packages in the Python repository.  

It’s also worth mentioning the astounding piece of evidence in a separate social engineering campaign which linked the 3CX hack to North Korea. It was an attack worthy of a Hollywood cyber block buster. The threat group, Lazarus, lured hopeful job candidates on LinkedIn into clicking on malicious ZIP file disguised as an attractive PDF offer for a position as a Developer at HSBC. The malware’s command and control infrastructure, journalide[.]org, was the same one discovered in the 3CX campaign.  

Though not strictly a supply chain attack, the LinkedIn campaign illustrates how nation states employ a diverse array of methods that span beyond the supply chain to achieve their goals. These sophisticated and well-resourced adversaries are adaptable and capable of repurposing their command-and-control infrastructure to orchestrate a range of attacks. This attack, along with the typosquatting attacks found in PyPI, serve as a critical reminder for security teams: supply chain attacks are often coupled with another powerful tactic – social engineering of human teams.

When the cure is worse than the disease

Updates to the software are a core pillar of cybersecurity, designed to patch vulnerabilities like Log4J and ensure it is safe. However, they have also proven to serve as alarmingly efficient delivery vessels for nation states to propagate their cyberattacks.  

Two of the most prolific supply chain breaches in recent history have been deployed through malicious updates, illustrating how they can be a double-edged sword when it comes to cyber defense.  

NotPetya (2017) and Solarwinds (2020)

The 2017 NotPetya ransomware attack exemplified the mass spread of ransomware via a single software update. A Russian military group injected malware on accounting software used by Ukrainian businesses for tax reporting. Via an automatic update, the ransomware was pushed out to thousands of customers within hours, crippled Ukrainian infrastructure including airports, financial institutions and government agencies.  

Some of the hardest hit victims were suppliers themselves. Maersk, the global shipping giant responsible for shipping one fifth of the world’s goods, had their entire global operations brought to a halt and their 76 ports temporarily shut down. The interruptions to global trade were then compounded when a FedEx subsidiary was hit by the same ransomware. Meanwhile, Merck, a pharmaceutical company, was unable to supply vaccines to the Center for Disease Control and Prevention due to the attack.  

In 2020, another devastating supply chain attack unfolded in a similar way. Threat actors tied to Russian intelligence embedded malicious code into Solarwinds’ Orion IT software, which was then distributed as an update to 18,000 organizations. Victims included at least eight U.S. government agencies, as well as several major tech companies.  

These two attacks highlighted two key lessons. First, in a hyperconnected digital world, nation states will exploit the trust organizations place in software updates to cause a ripple effect of devastation downstream. Secondly, the economies of scale for the threat actor themselves are staggering: a single malicious update provided the heavy lifting work of dissemination to the attacker. A colossal number of originations were infected, and they obtained the keys to the world’s most sensitive networks.

The conclusion is obvious, albeit challenging to implement; organizations must rigorously scrutinize the authenticity and security of updates to prevent far-reaching consequences.  

Some of the biggest supply chain attacks in recent history and the nation state actor they are attributed to
Figure 2: Some of the biggest supply chain attacks in recent history and the nation state actor they are attributed to

Geopolitics and nation States in 2024: Beyond the software supply chain

The threat to our increasingly complex web of global supply is real. But organizations must look beyond their software to successfully mitigate supply chain disruption. Securing hardware and logistics is crucial, as these supply chain links are also in the crosshairs of nation states.  

In July 2024, suspicious packages caused a warehouse fire at a depot belonging to courier giant DHL in Birmingham, UK. British counter-terrorism authorities investigated Russian involvement in this fire, which was linked to a very similar incident that same month at a DHL facility in Germany.  

In September 2024, camouflaged explosives were hidden in walkie talkies and pagers in Lebanon and Syria – a supply chain attack widely believed to be carried out by Israel.

While these attacks targeted hardware and logistics rather than software, the underlying rule of thumb remained the same: the compromise of a single distributor can provide the attackers with considerable economies of scale.

These attacks sparked growing concerns of coordinated efforts to sabotage the supply chain. This sentiment was reflected in a global survey carried out by HP in August 2024, in which many organisations reported “nation-state threat actors targeting physical supply chains and tampering with device hardware and firmware integrity” [7].

More recently, in November 2024, the Russian military unit 29155 vowed to “turn the lights out for millions” by threatening to launch cyberattacks on the blood supply of NATO countries, critical national infrastructure (CNI). Today, CNI encompasses more than the electric grid and water supply; it includes ICT services and IT infrastructure – the digital systems that underpin the foundations of modern society.    

This is nothing new. The supply and logistics-focused tactic has been central to warfare throughout history. What’s changed is that cyberspace has merely expanded the scale and efficiency of these tactics, turning single software compromises into attack multipliers. The supply chain threat is now more multi-faceted than ever before.  

Learnings from the supply chain threat landscape

Consider some of the most disastrous nation-state supply chain attacks in recent history – 3CX, NotPetya and Solarwinds. They share a remarkable commonality: the attackers only needed to compromise a single piece of software to cause rampant disruption. By targeting a technology provider whose products were deeply embedded across industries, threat actors leveraged the trust inherent in the supply chain to infiltrate networks at scale.

From a nation-state’s perspective, targeting a specific technology, device or service used by vast swathes of society amplifies operational efficiency. For software, hardware and critical service suppliers, these examples serve as an urgent wake-up call. Without rigorous security measures, they risk becoming conduits for global disruption. Sanity-checking code, implementing robust validation processes, and fostering a culture of security throughout the supply chain are no longer optional—they are essential.  

The stakes are clear: in the interconnected digital age, the safety of countless systems, industries and society at large depends on their vigilance.  

Screenshot of supply chain security whitepaper

Gain a deeper understanding of the evolving risks in supply chain security and explore actionable strategies to protect your organization against emerging threats. Download the white paper to empower your decision-making with expert insights tailored for CISOs

Download: Securing the Supply Chain White Paper

References

  1. https://www.gartner.com/en/documents/5524495
  1. CISA Insights “Remediate Vulnerabilities for Internet-Accessible Systems.”
  1. https://blog.checkpoint.com/security/the-numbers-behind-a-cyber-pandemic-detailed-dive/
  1. https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-320a  
  1. https://www.microsoft.com/en-us/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/  
  1. https://content.reversinglabs.com/state-of-sscs-report/the-state-of-sscs-report-24  
  1. https://www.hp.com/us-en/newsroom/press-releases/2024/hp-wolf-security-study-supply-chains.html
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Benjamin Druttman
Cyber Security AI Technical Instructor

More in this series

No items found.

Blog

/

/

May 27, 2026

How to Evaluate AI Vendors: 5 Key categories for AI Adoption

Default blog imageDefault blog image

Understanding the AI buyers’ market

AI adoption has become a central topic of discussion in boardrooms, drawing growing interest from business leaders. Ultimately, organizations hope that an investment in AI technology will have tremendous returns. However, the process of buying an AI solution is not as straight forward as it appears on the surface.  

While business leaders may be eager to improve productivity across their operations, practitioners responsible for evaluating and selecting AI solutions may not always have the visibility or technical understanding needed to make the right decisions for their business. What is typically marketed as a holistic solution to their most critical problems is usually followed by uncertainty when AI tools are finally operationalized in real environments.

This guide is intended to support security leaders who are under growing pressure to adopt AI tools while navigating complex terminology, vendor claims, and increasingly crowded buying cycles. Ultimately, the goal is to help organizations evaluate and adopt AI in a safe, effective, and well-governed way. To support this, we’ve structured the evaluation framework across five key categories:

  1. Governance, safety, and data controls
  1. Data gathering and training
  1. Model and technique choice
  1. Performance and accuracy validation    
  1. Interpretability, adjustability, and transparency    

What buying AI looks like in cybersecurity

While investing in AI can bring immense benefits to your security team, first-time buyers of AI cybersecurity solutions may not know where to start. They will have to determine the type of tool they want, know the options available, and evaluate vendors. Research and understanding are critical to ensure purchases are worth the investment.  

With acceleration in AI adoption, accompanied by the recent boom in agentic AI and autonomous agents, CISOs must look “beneath the hood" of these tools to understand how they work, how they are governed, and to ensure the system is secure and compliant with internal policies.

Challenges in the AI buyers’ marketplace  

The AI security software market is buzzing with hype and flashy promises, which, understandably, needs to be addressed with due diligence. Potential buyers, especially in the cybersecurity space, are hesitant when it comes to allowing AI autonomous capabilities across their workflows, and a lack of vendor transparency can exacerbate those feelings.  

Reinforcing this sentiment, research from this year's Darktrace’s State of AI Cybersecurity report shows where confidence and hesitancy emerge amongst potential buyers. On the one hand, security professionals agree that they have good visibility into the logic and reasoning processes their AI solutions use. However, they lack the explainability and trust to allow AI to take independent remedial action.

  • 89% say they have good visibility into the reasoning behind the outputs generated by AI solutions
  • 92% say they need to understand how a defensive AI tool makes decisions before they can trust it
  • Only 14% say they allow AI to act independently, performing autonomous actions without human approval
  • 74% say they are limiting the autonomy of AI taking action in their SOC until explainability improves

Given the desire for trust and explainability we are seeing from buyers, it's important for them to be equipped with the right questions to ask vendors during an assessment or POV of AI tools in order to demystify marketing hype from real operational outcomes.

Below is a list of categories in which buyers can assess AI vendors or AI Service Providers (AISPs) to help reach safe adoption and maximize their ROI.  

5 categories of AI vendor assessment

Darktrace groups these AI-related questions into 5 categories: governance, data and training, model and technique choice, performance validation, and interpretability and adjustability. By asking questions regarding each of these 5 categories, buyers can gain a deeper understanding of how an AISP’s systems work and whether they suit their business requirements.

Governance, safety, and data controls

Governance of AI systems is critical for all AISPs. Whether their platform is based around a single model, or is a more complex, composite AI solution, strong governance is essential to ensure the system is safe, robust, and reliable.

A simple question you could ask is:

What AI governance policies and frameworks do you follow, and/or certifications do you currently maintain?

For more questions you can ask vendors, download the full guide here.

Darktrace is certified to the ISO/IEC 42001 standard, the world’s first AI Management System (AIMS) standard. ISO/IEC 42001 addresses the unique ethical and technical challenges AI poses by setting out a structured way to manage risks such as transparency, accuracy, and misuse. This includes a commitment to ethical AI development, and effective management and monitoring of AI systems both prior to and continually after release.

Data gathering and training

Accurate, meaningful, and unbiased data gathering is the first important step in producing any AI system. An AI model trained using inaccurate, unbalanced, or poor-quality training data will fail to perform optimally.

To alleviate concerns regarding training data quality, a question you could ask is:

What steps do you take to prevent bias in your AI models and training data?

For more questions, download the full guide here.

AISPs should be able to provide information about the steps taken, workflows followed, and auditing performed to reduce AI bias where appropriate. While it’s sometimes impossible to fully remove bias from an AI model, appropriate actions should be taken to mitigate or reduce bias where relevant.

Model and technique choice

Different AI techniques are optimal for different tasks. For example, research from Gartner suggests that relying on a single “one-size-fits-all" model can lead to data gaps, especially in highly specialized domains.

To achieve more accurate and robust AI solutions, AI leaders should move beyond using just one model or technique, embrace composite AI practices, and adopt a holistic AI system perspective.

A straightforward question you could ask is simply:

What type(s) of AI model(s) do you utilize in your solution?

For more questions, download the full guide here.

While specific detailed information about custom systems used by AISPs is likely proprietary, buyers should expect vendors to be able to provide an overview of the broad techniques used. This will allow you as a buyer to determine if the type of model is appropriate for your use case.

Performance and accuracy validation  

Testing and evaluation of performance is essential for all AI systems. Performance analysis should be performed both before release and continually after release to identify potential data or model drift.  

A question you could ask to understand an AISPs testing workflow is:

How do you audit, test, evaluate, verify, and validate your AI model outputs?

For more questions, download the full guide here.

Testing workflows will likely vary depending on the type of model – measurements relevant to one system may not always be relevant to others. Assessment of systems should also extend beyond these standard accuracy and robustness tests, and should also feature physical performance, such as latency and resource consumption.  

Interpretability, adjustability, and transparency  

AI systems are typically a black box, simply providing an output without an explanation of how that output was attained. Interpretability and transparency are critical to ensure that both SOC teams and end-users trust the outputs of a system to be accurate and meaningful.

A question you could ask is:

How do you promote a trust relationship between human analysts and AI outputs?

For more questions, download the full guide here.

In the context of cybersecurity, trust and interpretability are even more essential. This is particularly relevant for generative AI-based systems (including most AI Agents), where the risk of hallucination can reduce trust in responses.

Cybersecurity systems often need to perform autonomous actions to block incoming threats – an email filtering system may hold potentially dangerous emails; a firewall may block malicious inbound connections. If SOC teams can’t trust these systems to perform accurately, these systems may be limited or disabled, critically reducing their defensive power.

Darktrace as an AI-native cybersecurity vendor

Darktrace has been building and applying AI in cybersecurity for over a decade, developing its capabilities alongside an increasingly complex and fast‑moving threat landscape. This experience has resulted in a mature, multi-layered approach to AI, which continuously learns the normal patterns of each organization to understand behavior, interpret context, and identify meaningful deviations — without relying on predefined rules or known attack signatures. Over time, this has enabled a proven behavioral understanding that helps uncover subtle signals of risk that may otherwise be missed.

With the backing of our ISO/IEC 42001 certification, stakeholders, customers, and partners can be confident that Darktrace is responsibly, ethically, and safely developing its AI systems, and managing the use of AI in day-to-day operations in a compliant and secure manner.  

Explore the principles behind Darktrace’s responsible AI approach, informed by collaboration with global experts in academia and governments, detailing how accountability, explainability, and continuous validation are built into its cybersecurity technology.

How Darktrace secures AI systems

Darktrace now brings these capabilities to monitor and respond to risk generated from AI systems across organizations with Darktrace / SECURE AI. This solution analyzes how prompts, agents, and systems are used within the context of each organization, bringing every AI interaction into a single view. This unique approach helps teams understand intent, assess risk, protect sensitive data, and enforce policy across both human and AI agent activity.

Stay up to date

Sign up for the Secure AI Readiness Program here: This gives you exclusive access to the latest news on the latest AI threats, updates on emerging approaches shaping AI security, and insights into the latest innovations, including Darktrace’s ongoing work in this area.

Ready to talk with a Darktrace expert on securing AI? Register here to receive practical guidance on the AI risks that matter most to your business, paired with clarity on where to focus first across governance, visibility, risk reduction, and long-term readiness.  

Further Reading on AI in cybersecurity

When deciding to invest in an AI solution, it’s important to understand what this means for you and your organization. The questions presented here are only a starting point in understanding an AI solution and whether it is appropriate for your use case.  

Gain deeper knowledge on applications of AI in cybersecurity and Darktrace’s multi-layered AI in the AI Arsenal White Paper.

[related-resource]

Continue reading
About the author
Jamie Bali
Technical Author (AI) Developer

Blog

/

Compliance

/

May 26, 2026

The CIP-015 Countdown: What Utilities Should Be Doing Before October 2028

cip-015, utilities, cybersecurityDefault blog imageDefault blog image

CIP-015 what you need to know

The electric sector already knows CIP-015 is coming. The better question is whether utilities are using the time before October 1, 2028 to build an Internal Network Security Monitoring program that is defensible, auditable, and operationally useful.

I have spent most of my OT cybersecurity career around the power sector, from early NERC CIP program work as an asset owner, to consulting with utilities ranging from small municipalities and rural cooperatives to some of the largest power companies in the country, to now working with technology that helps organizations improve visibility and detection across IT and OT. One lesson has been consistent across all of those roles: compliance is not just about having a control in place. It is about being able to prove the control works.

That is where CIP-015 becomes important.

The standard is not simply asking utilities to deploy a tool inside the Electronic Security Perimeter and call the job done. CIP-015 is about improving the probability of detecting anomalous or unauthorized network activity so that organizations can improve response and recovery from an attack. That purpose is directly stated in the standard itself. (NERC)

The real work between now and October 2028 is not just buying technology. It is building an INSM capability that can collect the right data, detect meaningful activity, support evaluation, retain the right evidence, and protect that evidence from unauthorized deletion or modification.

Why CIP-015 exists

CIP-015 exists because perimeter security alone does not solve the internal visibility problem.

For years, many CIP controls have focused heavily on access management, segmentation, patching, logging, training, and other security practices that help reduce the likelihood of unauthorized access. Those controls still matter. But they do not fully answer what happens after an attacker, insider, compromised vendor account, misused credential, or malicious activity is already operating inside a trusted environment.

NERC’s technical rationale explains that Internal Network Security Monitoring focuses on the collection and analysis of network communications inside a “trust zone,” such as an ESP. In other words, CIP-015 is not only about defending the edge. It is about understanding what is happening inside the environment once traffic is already within the trusted zone. (NERC)

That is the internal visibility gap utilities need to close.

Why traditional security monitoring does not fully satisfy CIP-015

One mistake utilities should avoid is assuming that existing security event monitoring automatically solves CIP-015.

Many organizations already have logging programs tied to CIP-007, SIEM use cases, host-level security events, authentication logs, malware alerts, and incident response workflows. Those capabilities remain valuable, but they are not the same as Internal Network Security Monitoring.

Security event monitoring often tells you what happened on or to a system. INSM is intended to help show what is happening between systems, across network communications, devices, connections, and internal traffic patterns. That distinction is especially important in OT environments where adversaries may use legitimate pathways, valid credentials, native protocols, remote access, engineering workstations, or trusted systems to move inside the environment.

CIP-015 pushes utilities toward a different level of visibility: not just “did a system log something,” but “can we see and evaluate anomalous or unauthorized activity occurring inside the ESP?”

What CIP-015 requires

At a high level, CIP-015-1 requires three core capabilities.

Requirement R1: Monitoring internal network activity  

First, under Requirement R1, Responsible Entities must implement, using a risk-based rationale, network data feeds to monitor network activity, including connections, devices, and network communications. They must also implement one or more methods to detect anomalous network activity using those feeds, and one or more methods to evaluate detected anomalous activity to determine further actions.

Requirement R2: Retaining INSM data for investigations

Second, under Requirement R2, entities must retain INSM data associated with anomalous network activity at least until the related evaluation and action are complete. The standard also notes that entities are not required to retain INSM data that is not relevant to detected anomalous activity.

Requirement R3: Protecting monitoring data from tampering

Third, under Requirement R3, entities must protect INSM data collected for R1 and retained for R2 from unauthorized deletion or modification.

Those requirements may sound straightforward, but implementation is where the challenge begins.

What should utilities be asking themselves for CIP-015?

  • Where are we collecting network data inside the ESP, and why are those feeds defensible?
  • What methods are we using to detect anomalous network activity?
  • How do we distinguish meaningful anomalous behavior from normal operational change?
  • Who evaluates detections, and how are decisions documented?
  • What data is retained, and how is it protected from unauthorized deletion or modification?
  • Can we produce evidence that proves this process has worked over time?

Those answers matter because auditors will not be looking for marketing claims. They will be looking for evidence.

Why anomaly detection is central to CIP-015 compliance

One of the most important parts of CIP-015 is also one of the easiest to oversimplify: the word anomalous.

NERC’s technical rationale provides useful context. It explains that, as used in CIP-015, “anomalous” refers to unexpected, undesired, unusual, or undetermined network traffic. It also makes clear that the term does not refer to any single proprietary technology commonly marketed as “anomaly detection.”

Understanding static baselines vs true anomaly detection

A static baseline is not the same thing as meaningful anomaly detection. If a platform observes traffic for a limited period of time, assumes that observed behavior is “normal,” and then flags future deviations without deeper context, the result can be noisy, brittle, and operationally frustrating.

In real OT environments, “normal” is not fixed. Maintenance windows, vendor access, failovers, engineering changes, testing activity, backup jobs, and operational shifts can all change behavior. Detection has to keep learning and understand context. Otherwise, the organization may end up with alerts that are technically anomalous but not practically useful.

CIP-015 is not just about producing anomalies. It is about producing meaningful detections that can be evaluated, documented, and acted upon.

What should utilities consider when looking for anomaly detection tools

Some technologies were built around behavioral analysis and anomaly detection long before CIP-015 existed. What practitioners should look for is if the technology behind the phrase can identify meaningful deviations, provide context, reduce noise, and support the evaluation and evidence expectations of the standard.

Utilities should be cautious of vendor positioning that treats “anomaly” as a simple compliance keyword. This is especially important when evaluating tools historically built around signature-based, threat-based, or rule-based detection methods that are now being positioned as anomaly detection because CIP-015 uses the term.

A platform does not solve CIP-015 simply because it can baseline traffic or generate alerts when something changes.

The question is not: Can this tool create alerts?

The question is: Can this tool identify meaningful anomalous activity with enough context, prioritization, and evidence to support evaluation and response?

Why evidence and audit readiness matter for CIP-015

In NERC CIP, the control is only part of the story. Evidence is the part that proves the control existed, worked, and was followed.

That is why CIP-015 readiness should not be treated as a simple deployment project. It should be treated as a compliance operations and evidence program.

What auditors will expect utilities to prove

For R1, examples of evidence include documentation of network data feeds and the risk-based rationale for selecting them, anomalous network detection events, INSM configuration settings, communication baselines or other detection methods, methods used to evaluate anomalous activity, and actions taken in response to detected anomalies.

For R2, evidence may include documentation of the retention process, system configurations, or system-generated reports showing retention timelines sufficient to support evaluation. For R3, evidence may include documentation showing how INSM data is protected from unauthorized deletion or modification.

Common evidence gaps that can create compliance risk

If an entity implements a platform that generates noisy detections, lacks context, does not retain the right data, cannot demonstrate how data is protected, or cannot produce useful audit evidence, the issue may not become obvious until much later. By then, an organization may discover during an audit that it cannot prove what it thought it had implemented.

That is a bad place to be.

CIP evidence gaps can create exposure that goes back over time, not just to the day the audit finding is discovered. This is why utilities need to validate the process early. Do not wait until an audit cycle to find out whether your INSM approach can stand up to scrutiny.

How utilities should prepare for CIP-015 before 2028

October 2028 may sound far away, but in utility planning terms, it is not.

Utilities should already be moving through a structured readiness process.

Assessing internal network visibility across trusted environments

Start with scope. Identify the applicable High and Medium Impact BES Cyber Systems, the relevant ESPs, and the environments where INSM requirements will apply. Then map current visibility. Where do you already have useful network monitoring? Where are you relying mostly on logs, perimeter controls, or assumptions? Where do you have limited east-west visibility inside trusted environments?

Building a defensible network data feed strategy

Next, define the network data feed strategy. CIP-015 requires a risk-based rationale, so the organization should be able to explain why specific feeds were selected and how they support detection of anomalous activity across relevant connections, devices, and communications.

Validating anomaly detection workflows

Then validate the detection method. This is where utilities need to go deeper than vendor claims. Ask how the platform identifies anomalous activity. Ask how it reduces noise. Ask what context is provided for evaluation. Ask how it handles changes in normal operations. Ask what evidence is retained and how that evidence can be produced.

Testing evidence retention and protection processes

After that, build the evaluation workflow. Who reviews detections? How are anomalies classified as benign, abnormal but not suspicious, suspicious, or potentially malicious? When does an event move into CIP-008 incident response? What documentation is created during that process?

Finally, test evidence production. Utilities should be able to show detection records, configuration settings, evaluation notes, response actions, retention records, and data protection controls before an auditor asks for them.

Where Darktrace Fits into CIP-015

This is where technology matters, but only as part of the broader program.

Darktrace was built on self-learning anomaly detection long before CIP-015 created a new compliance driver around anomalous network activity. Its value is rooted in continuous behavioral understanding, multiple analytical techniques, and the ability to identify meaningful deviations across complex IT and OT environments. That matters because CIP-015 requires more than basic alerting. It requires detection that supports evaluation, evidence, and action.

This IT and OT visibility is especially important in power utility environments. High and Medium Impact environments are not made up only of industrial protocols and field devices. Control centers, operational workstations, engineering workstations, servers, remote access systems, domain services, printers, and other enterprise-class assets often sit inside or adjacent to critical operational environments. A useful INSM capability should understand a wide range of communications across both IT and OT, not only traditional industrial protocols like Modbus, DNP3, or IEC 61850.

That distinction matters because “protocol support” can mean very different things. Identifying that a protocol is present is not the same as performing deeper packet analysis that can provide behavioral context, richer protocol understanding, and meaningful detection across the communications actually used inside the environment. For CIP-015, utilities should be asking whether a platform can help evaluate activity across both enterprise and industrial communications, because real power utility environments are rarely “OT-only.”

This is also why utilities should look carefully at how vendors use the word “anomaly.” Some platforms were designed around behavioral understanding and anomaly detection long before CIP-015 created a new compliance driver. Others may now be adopting the language because the standard uses the term. The difference matters. Utilities should ask whether the platform’s detection approach is foundational to the technology, or simply a new label applied to existing signature-based, threat-based, or rule-based methods.

In OT environments, detection quality matters. Utilities do not need more noise. They need visibility into internal communications, confidence in what is normal, context when something changes, and prioritization that helps security and operations teams focus on what matters.

A strong INSM program should help utilities move from raw monitoring to operational confidence. It should support east-west visibility, better anomaly evaluation, defensible evidence retention, protection of monitoring data, and alignment between compliance and security outcomes.

That is the right way to think about CIP-015.

Not as “deploy a tool and move on.”But as “build a capability that can be trusted, operated, and proven.”

CIP-015 is about proving your INSM capability works

The CIP-015 countdown is real, but the countdown itself is not the whole story.

The real story is what utilities do with the time that remains.

Organizations that treat CIP-015 as a checkbox may be able to say they deployed something. But organizations that treat it as an opportunity to close the internal visibility gap will gain something much more valuable: better detection, better response, better evidence, and stronger operational resilience.

The question utilities should be asking now is not whether they can produce more alerts before October 2028.

The question is whether they can prove their INSM capability actually works.

Continue reading
About the author
Jeffrey Macre
Principal Industrial Security Solutions Architect
Your data. Our AI.
Elevate your network security with Darktrace AI