Blog
/
Network
/
March 13, 2024

Simulated vs. Real Malware: What You Need To Know

Learn how Darktrace distinguishes between simulated and real malware. Discover the advanced detection techniques used to protect your network.
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
Priya Thapa
Cyber Analyst
Default blog image
13
Mar 2024

Distinguishing attack simulations from the real thing

In an era marked by the omnipresence of digital technologies and the relentless advancement of cyber threats, organizations face an ongoing battle to safeguard their digital environment. Although red and blue team exercises have long served as cornerstones in evaluating organizational defenses, their reliance on manual processes poses significant constraints [1]. Led by seasoned security professionals, these tests offer invaluable insights into security readiness but can be marred by their resource-intensive and infrequent testing cycles. The gaps between assessments leave organizations open to undetected vulnerabilities, compromising the true state of their security environment. In response to the ever-changing threat landscape, organizations are adopting a proactive stance towards cyber security to fortify their defenses.

At the forefront, these efforts tend to revolve around simulated attacks, a process designed to test an organization's security posture against both known and emerging threats in a safe and controlled environment [2]. These meticulously orchestrated simulations imitate the tactics, techniques, and procedures (TTPs) employed by actual adversaries and provide organizations with invaluable insights into their security resilience and vulnerabilities. By immersing themselves in simulated attack scenarios, security teams can proactively probe for vulnerabilities, adopt a more aggressive defense posture, and stay ahead of evolving cyber threats.

Distinguishing between simulated malware observations and authentic malware activities stands as a critical imperative for organizations bolstering their cyber defenses. While simulated platforms offer controlled scenarios for testing known attack patterns, Darktrace’s Self-Learning AI can detect known and unknown threats, identify zero-day threats, and previously unseen malware variants, including attack simulations. Whereas simulated platforms focus on specific known attack vectors, Darktrace DETECT™ and Darktrace RESPOND™ can identify and contain both known and unknown threats across the entire attack surface, providing unparalleled protection of the cyber estate.

Darktrace’s Coverage of Simulated Attacks

In January 2024, the Darktrace Security Operations Center (SOC) received a high volume of alerts relating to an unspecified malware strain that was affecting multiple customers across the fleet, raising concerns, and prompting the Darktrace Analyst team to swiftly investigate the multitude of incident. Initially, these activities were identified as malicious, exhibiting striking resemblance to the characteristics of Remcos, a sophisticated remote access trojan (RAT) that can be used to fully control and monitor any Windows computer from XP and onwards [3]. However, further investigation revealed that these activities were intricately linked to a simulated malware provider.

This discovery underscores a pivotal insight into Darktrace’s capabilities. To this point, leveraging advanced AI, Darktrace operates with a sophisticated framework that extends beyond conventional threat detection. By analyzing network behavior and anomalies, Darktrace not only discerns between simulated threats, such as those orchestrated by breach and attack simulation platforms and genuine malicious activities but can also autonomously respond to these threats with RESPOND. This showcases Darktrace’s advanced capabilities in effectively mitigating cyber threats.

Attack Simulation Process: Initial Access and Intrusion

Darktrace initially observed devices breaching several DETECT models relating to the hostname “new-tech-savvy[.]com”, an endpoint that was flagged as malicious by multiple open-source intelligence (OSINT) vendors [4].

In addition, multiple HTML Application (HTA) file downloads were observed from the malicious endpoint, “new-tech-savvy[.]com/5[.]hta”. HTA files are often seen as part of the UAC-0050 campaign, known for its cyber-attacks against Ukrainian targets, which tends to leverage the Remcos RAT with advanced evasion techniques [5] [6]. Such files are often critical components of a malware operation, serving as conduits for the deployment of malicious payloads onto a compromised system. Often, within the HTA file resides a VBScript which, upon execution, triggers a PowerShell script. This PowerShell script is designed to facilitate the download of a malicious payload, namely “word_update.exe”, from a remote server. Upon successful execution, “word_update.exe” is launched, invoking cmd.exe and initiating the sharing of malicious data. This process results in the execution of explorer.exe, with the malicious RemcosRAT concealed within the memory of explorer.exe. [7].

As the customers were subscribed to Darktrace’s Proactive Threat Notification (PTN) service, an Enhanced Monitoring model was breached upon detection of the malicious HTA file. Enhanced Monitoring models are high-fidelity DETECT models designed to identify activity likely to be indicative of compromise. These PTN alerts were swiftly investigated by Darktrace’s round the clock SOC team.

Following this successful detection, Darktrace RESPOND took immediate action by autonomously blocking connections to the malicious endpoint, effectively preventing additional download attempts. Similar activity may be seen in the case of a legitimate malware attack; however, in this instance, the hostname associated with the download confirmed the detected malicious activity was the result of an attack simulation.

Figure 1: The Breach Log displays the model breach, “Anomalous File/Incoming HTA File”, where a device was detected downloading the HTA file, “5.hta” from the endpoint, “new-tech-savvy[.]com”.
'
Figure 2: The Model Breach Event Log shows a device making connections to the endpoint, “new-tech-savvy[.]com”. As a result, theRESPOND model, “Antigena/Network/External Threat/Antigena File then New Outbound Block", breached and connections to this malicious endpoint were blocked.
Figure 3: The Breach Log further showcases another RESPOND model, “Antigena/Network/External Threat/Antigena Suspicious File Block", which was triggered when the device downloaded a  HTA file from the malicious endpoint, “new-tech-savvy[.]com".

In other cases, Darktrace observed SSL and HTTP connections also attributed to the same simulated malware provider, highlighting Darktrace’s capability to distinguish between legitimate and simulated malware attack activity.

Figure 4: The Model Breach “Anomalous Connection/Low and Slow Exfiltration" displays the hostname of a simulated malware provider, confirming the detected malicious activity as the result of an attack simulation.
Figure 5: The Model Breach Event Log shows the SSL connections made to an endpoint associated with the simulated malware provider.
Figure 6: Darktrace’s Advanced Search displays SSL connection logs to the endpoint of the simulated malware provider around the time the simulation activity was observed.

Upon detection of the malicious activity occurring within affected customer networks, Darktrace’s Cyber AI Analyst™ investigated and correlated the events at machine speed. Figure 8 illustrates the synopsis and additional technical information that AI Analyst generated on one customer’s environment, detailing that over 220 HTTP queries to 18 different endpoints for a single device were seen. The investigation process can also be seen in the screenshot, showcasing Darktrace’s ability to provide ‘explainable AI’ detail. AI Analyst was able to autonomously search for all HTTP connections made by the breach device and identified a single suspicious software agent making one HTTP request to the endpoint, 45.95.147[.]236.

Furthermore, the malicious endpoints, 45.95.147[.]236, previously observed in SSH attacks using brute-force or stolen credentials, and “tangible-drink.surge[.]sh”, associated with the Androxgh0st malware [8] [9] [10], were detected to have been requested by another device.

This highlights Darktrace’s ability to link and correlate seemingly separate events occurring on different devices, which could indicate a malicious attack spreading across the network.  AI Analyst was also able to identify a username associated with the simulated malware prior to the activity through Kerberos Authentication Service (AS) requests. The device in question was also tagged as a ‘Security Device’ – such tags provide human analysts with valuable context about expected device activity, and in this case, the tag corroborates with the testing activity seen. This exemplifies how Darktrace’s Cyber AI Analyst takes on the labor-intensive task of analyzing thousands of connections to hundreds of endpoints at a rapid pace, then compiling results into a single pane that provides customer security teams with the information needed to evaluate activities observed on a device.

All in all, this demonstrates how Darktrace’s Self-Learning AI is capable of offering an unparalleled level of awareness and visibility over any anomalous and potentially malicious behavior on the network, saving security teams and administrators a great deal of time.

Figure 7: Cyber AI Analyst Incident Log containing a summary of the attack simulation activity,, including relevant technical details, and the AI investigation process.

Conclusion

Simulated cyber-attacks represent the ever-present challenge of testing and validating security defenses, while the threat of legitimate compromise exemplifies the constant risk of cyber threats in today’s digital landscape. Darktrace emerges as the solution to this conflict, offering real-time detection and response capabilities that identify and mitigate simulated and authentic threats alike.

While simulations are crafted to mimic legitimate threats within predefined parameters and controlled environments, the capabilities of Darktrace DETECT transcend these limitations. Even in scenarios where intent is not malicious, Darktrace’s ability to identify anomalies and raise alerts remains unparalleled. Moreover, Darktrace’s AI Analyst and autonomous response technology, RESPOND, underscore Darktrace’s indispensable role in safeguarding organizations against emerging threats.

Credit to Priya Thapa, Cyber Analyst, Tiana Kelly, Cyber Analyst & Analyst Team Lead

Appendices

Model Breaches

Darktrace DETECT Model Breach Coverage

Anomalous File / Incoming HTA File

Anomalous Connection / Low and Slow Exfiltration

Darktrace RESPOND Model Breach Coverage

§  Antigena / Network/ External Threat/ Antigena File then New Outbound Block

Cyber AI Analyst Incidents

• Possible HTTP Command and Control

• Suspicious File Download

List of IoCs

IP Address

38.52.220[.]2 - Malicious Endpoint

46.249.58[.]40 - Malicious Endpoint

45.95.147[.]236 - Malicious Endpoint

Hostname

tangible-drink.surge[.]sh - Malicious Endpoint

new-tech-savvy[.]com - Malicious Endpoint

References

1.     https://xmcyber.com/glossary/what-are-breach-and-attack-simulations/

2.     https://www.picussecurity.com/resource/glossary/what-is-an-attack-simulation

3.     https://success.trendmicro.com/dcx/s/solution/1123281-remcos-malware-information?language=en_US&sfdcIFrameOrigin=null

4.     https://www.virustotal.com/gui/url/c145cf7010545791602e9585f447347c75e5f19a0850a24e12a89325ded88735

5.     https://www.virustotal.com/gui/url/7afd19e5696570851e6413d08b6f0c8bd42f4b5a19d1e1094e0d1eb4d2e62ce5

6.     https://thehackernews.com/2024/01/uac-0050-group-using-new-phishing.html

7.     https://www.uptycs.com/blog/remcos-rat-uac-0500-pipe-method

8.     https://www.virustotal.com/gui/ip-address/45.95.147.236/community

9.     https://www.virustotal.com/gui/domain/tangible-drink.surge.sh/community

10.  https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-016a

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
Priya Thapa
Cyber Analyst

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