Blog
/

Inside the SOC

Ransomware

/
October 26, 2022

Strategies to Prolong Quantum Ransomware Attacks

Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
26
Oct 2022
Learn more about how Darktrace combats Quantum Ransomware changing strategy for cyberattacks. Explore the power of AI-driven network cyber security!

Within science and engineering, the word ‘quantum’ may spark associations with speed and capability, referencing a superior computer that can perform tasks a classical computer cannot. In cyber security, some may recognize ‘quantum’ in relation to cryptography or, more recently, as the name of a new ransomware group, which achieved network-wide encryption a mere four hours after an initial infection.   

Although this group now has a reputation for carrying out fast and efficient attacks, speed is not their only tactic. In August 2022, Darktrace detected a Quantum Ransomware incident where attackers remained in the victim’s network for almost a month after the initial signs of infection, before detonating ransomware. This was a stark difference to previously reported attacks, demonstrating that as motives change, so do threat actors’ strategies. 

The Quantum Group

Quantum was first identified in August 2021 as the latest of several rebrands of MountLocker ransomware [1]. As part of this rebrand, the extension ‘.quantum’ is appended to filenames that are encrypted and the associated ransom notes are named ‘README_TO_DECRYPT.html’ [2].  

From April 2022, media coverage of this group has increased following a DFIR report detailing an attack that progressed from initial access to domain-wide ransomware within four hours [3]. To put this into perspective, the global median dwell time for ransomware in 2020 and 2021 is 5 days [4]. In the case of Quantum, threat actors gained direct keyboard access to devices merely 2 hours after initial infection. The ransomware was staged on the domain controller around an hour and a half later, and executed 12 minutes after that.   

Quantum’s behaviour bears similarities to other groups, possibly due to their history and recruitment. Several members of the disbanded Conti ransomware group are reported to have joined the Quantum and BumbleBee operations. Security researchers have also identified similarities in the payloads and C2 infrastructure used by these groups [5 & 6].  Notably, these are the IcedID initial payload and Cobalt Strike C2 beacon used in this attack. Darktrace has also observed and prevented IcedID and Cobalt Strike activity from BumbleBee across several customer environments.

The Attack

From 11th July 2022, a device suspected to be patient zero made repeated DNS queries for external hosts that appear to be associated with IcedID C2 traffic [7 & 8]. In several reported cases [9 & 10], this banking trojan is delivered through a phishing email containing a malicious attachment that loads an IcedID DLL. As Darktrace was not deployed in the prospect’s email environment, there was no visibility of the initial access vector, however an example of a phishing campaign containing this payload is presented below. It is also possible that the device was already infected prior to joining the network. 

Figure 1- An example phishing email used to distribute IcedID. If configured, Darktrace/Email would be able to detect that the email was sent from an anomalous sender, was part of a fake reply chain, and had a suspicious attachment containing compressed content of unusual mime type [11].    

 

Figure 2- The DNS queries to endpoints associated with IcedID C2 servers, taken from the infected device’s event log.  Additional DNS queries made to other IcedID C2 servers are in the list of IOCs in the appendices.  The repeated DNS queries are indicative of beaconing.


It was not until 22nd July that activity was seen which indicated the attack had progressed to the next stage of the kill chain. This contrasts the previously seen attacks where the progression to Cobalt Strike C2 beaconing and reconnaissance and lateral movement occurred within 2 hours of the initial infection [12 & 13]. In this case, patient zero initiated numerous unusual connections to other internal devices using a compromised account, connections that were indicative of reconnaissance using built-in Windows utilities:

·      DNS queries for hostnames in the network

·      SMB writes to IPC$ shares of those hostnames queried, binding to the srvsvc named pipe to enumerate things such as SMB shares and services on a device, client access permissions on network shares and users logged in to a remote session

·      DCE-RPC connections to the endpoint mapper service, which enables identification of the ports assigned to a particular RPC service

These connections were initiated using an existing credential on the device and just like the dwelling time, differed from previously reported Quantum group attacks where discovery actions were spawned and performed automatically by the IcedID process [14]. Figure 3 depicts how Darktrace detected that this activity deviated from the device’s normal behaviour.  

Figure 3- This figure displays the spike in active internal connections initiated by patient zero. The coloured dots represent the Darktrace models that were breached, detecting this unusual reconnaissance and lateral movement activity.

Four days later, on the 26th of July, patient zero performed SMB writes of DLL and MSI executables to the C$ shares of internal devices including domain controllers, using a privileged credential not previously seen on the patient zero device. The deviation from normal behaviour that this represents is also displayed in Figure 3. Throughout this activity, patient zero made DNS queries for the external Cobalt Strike C2 server shown in Figure 4. Cobalt Strike has often been seen as a secondary payload delivered via IcedID, due to IcedID’s ability to evade detection and deploy large scale campaigns [15]. It is likely that reconnaissance and lateral movement was performed under instructions received by the Cobalt Strike C2 server.   

Figure 4- This figure is taken from Darktrace’s Advanced Search interface, showing a DNS query for a Cobalt Strike C2 server occurring during SMB writes of .dll files and DCE-RPC requests to the epmapper service, demonstrating reconnaissance and lateral movement.


The SMB writes to domain controllers and usage of a new account suggests that by this stage, the attacker had achieved domain dominance. The attacker also appeared to have had hands-on access to the network via a console; the repetition of the paths ‘programdata\v1.dll’ and ‘ProgramData\v1.dll’, in lower and title case respectively, suggests they were entered manually.  

These DLL files likely contained a copy of the malware that injects into legitimate processes such as winlogon, to perform commands that call out to C2 servers [16]. Shortly after the file transfers, the affected domain controllers were also seen beaconing to external endpoints (‘sezijiru[.]com’ and ‘gedabuyisi[.]com’) that OSINT tools have associated with these DLL files [17 & 18]. Moreover, these SSL connections were made using a default client fingerprint for Cobalt Strike [19], which is consistent with the initial delivery method. To illustrate the beaconing nature of these connections, Figure 5 displays the 4.3 million daily SSL connections to one of the C2 servers during the attack. The 100,000 most recent connections were initiated by 11 unique source IP addresses alone.

Figure 5- The Advanced Search interface, querying for external SSL connections from devices in the network to an external host that appears to be a Cobalt Strike C2 server. 4.3 million connections were made over 8 days, even after the ransomware was eventually detonated on 2022-08-03.


Shortly after the writes, the attack progressed to the penultimate stage. The next day, on the 27th of July, the attackers moved to achieve their first objective: data exfiltration. Data exfiltration is not always performed by the Quantum ransomware gang. Researchers have noted discrepancies between claims of data theft made in their ransom notes versus the lack of data seen leaving the network, although this may have been missed due to covert exfiltration via a Cobalt Strike beacon [20]. 

In contrast, this attack displayed several gigabytes of data leaving internal devices including servers that had previously beaconed to Cobalt Strike C2 servers. This data was transferred overtly via FTP, however the attacker still attempted to conceal the activity using ephemeral ports (FTP in EPSV mode). FTP is an effective method for attackers to exfiltrate large files as it is easy to use, organizations often neglect to monitor outbound usage, and it can be shipped through ports that will not be blocked by traditional firewalls [21].   

Figure 6 displays an example of the FTP data transfer to attacker-controlled infrastructure, in which the destination share appears structured to identify the organization that the data was stolen from, suggesting there may be other victim organizations’ data stored. This suggests that data exfiltration was an intended outcome of this attack. 

Figure 6- This figure is from Darktrace’s Advanced Search interface, displaying some of the data transferred from an internal device to the attacker’s FTP server.

 
Data was continuously exfiltrated until a week later when the final stage of the attack was achieved and Quantum ransomware was detonated. Darktrace detected the following unusual SMB activity initiated from the attacker-created account that is a hallmark for ransomware (see Figure 7 for example log):

·      Symmetric SMB Read to Write ratio, indicative of active encryption

·      Sustained MIME type conversion of files, with the extension ‘.quantum’ appended to filenames

·      SMB writes of a ransom note ‘README_TO_DECRYPT.html’ (see Figure 8 for an example note)

Figure 7- The Model Breach Event Log for a device that had files encrypted by Quantum ransomware, showing the reads and writes of files with ‘.quantum’ appended to encrypted files, and an HTML ransom note left where the files were encrypted.

 

Figure 8- An example of the ransom note left by the Quantum gang, this one is taken from open-sources [22].


The example in Figure 8 mentions that the attacker also possessed large volumes of victim data.  It is likely that the gigabytes of data exfiltrated over FTP were leveraged as blackmail to further extort the victim organization for payment.  

Darktrace Coverage

 

Figure 9- Timeline of Quantum ransomware incident


If Darktrace/Email was deployed in the prospect’s environment, the initial payload (if delivered through a phishing email) could have been detected and held from the recipient’s inbox. Although DETECT identified anomalous network behaviour at each stage of the attack, since the incident occurred during a trial phase where Darktrace could only detect but not respond, the attack was able to progress through the kill chain. If RESPOND/Network had been configured in the targeted environment, the unusual connections observed during the initial access, C2, reconnaissance and lateral movement stages of the attack could have been blocked. This would have prevented the attackers from delivering the later stage payloads and eventual ransomware into the target network.

It is often thought that a properly implemented backup strategy is sufficient defense against ransomware [23], however as discussed in a previous Darktrace blog, the increasing frequency of double extortion attacks in a world where ‘data is the new oil’ demonstrates that backups alone are not a mitigation for the risk of a ransomware attack [24]. Equally, the lack of preventive defenses in the target’s environment enabled the attacker’s riskier decision to dwell in the network for longer and allowed them to optimize their potential reward. 

Recent crackdowns from law enforcement on ransomware groups have shifted these groups’ approaches to aim for a balance between low risk and significant financial rewards [25]. However, given the Quantum gang only have a 5% market share in Q2 2022, compared to the 13.2% held by LockBit and 16.9% held by BlackCat [26], a riskier strategy may be favourable, as a longer dwell time and double extortion outcome offers a ‘belt and braces’ approach to maximizing the rewards from carrying out this attack. Alternatively, the gaps in-between the attack stages may imply that more than one player was involved in this attack, although this group has not been reported to operate a franchise model before [27]. Whether assisted by others or driving for a risk approach, it is clear that Quantum (like other actors) are continuing to adapt to ensure their financial success. They will continue to be successful until organizations dedicate themselves to ensuring that the proper data protection and network security measures are in place. 

Conclusion 

Ransomware has evolved over time and groups have merged and rebranded. However, this incident of Quantum ransomware demonstrates that regardless of the capability to execute a full attack within hours, prolonging an attack to optimize potential reward by leveraging double extortion tactics is sometimes still the preferred action. The pattern of network activity mirrors the techniques used in other Quantum attacks, however this incident lacked the continuous progression of the group’s attacks reported recently and may represent a change of motives during the process. Knowing that attacker motives can change reinforces the need for organizations to invest in preventative controls- an organization may already be too far down the line if it is executing its backup contingency plans. Darktrace DETECT/Network had visibility over both the early network-based indicators of compromise and the escalation to the later stages of this attack. Had Darktrace also been allowed to respond, this case of Quantum ransomware would also have had a very short dwell time, but a far better outcome for the victim.

Thanks to Steve Robinson for his contributions to this blog.

Appendices

References

[1] https://community.ibm.com/community/user/security/blogs/tristan-reed/2022/07/13/ibm-security-reaqta-vs-quantum-locker-ransomware

 

[2] https://www.bleepingcomputer.com/news/security/quantum-ransomware-seen-deployed-in-rapid-network-attacks/

 

[3], [12], [14], [16], [20] https://thedfirreport.com/2022/04/25/quantum-ransomware/

 

[4] https://www.mandiant.com/sites/default/files/2022-04/M-Trends%202022%20Executive%20Summary.pdf

 

[5] https://cyware.com/news/over-650-healthcare-organizations-affected-by-the-quantum-ransomware-attack-d0e776bb/

 

[6] https://www.kroll.com/en/insights/publications/cyber/bumblebee-loader-linked-conti-used-in-quantum-locker-attacks

 

[7] https://github.com/pan-unit42/tweets/blob/master/2022-06-28-IOCs-for-TA578-IcedID-Cobalt-Strike-and-DarkVNC.txt 

 

[8] https://github.com/stamparm/maltrail/blob/master/trails/static/malware/icedid.txt

 

[9], [15] https://www.cynet.com/blog/shelob-moonlight-spinning-a-larger-web-from-icedid-to-conti-a-trojan-and-ransomware-collaboration/

 

[10] https://www.microsoft.com/security/blog/2021/04/09/investigating-a-unique-form-of-email-delivery-for-icedid-malware/

 

[11] https://twitter.com/0xToxin/status/1564289244084011014

 

[13], [27] https://cybernews.com/security/quantum-ransomware-gang-fast-and-furious/

 

[17] https://www.virustotal.com/gui/domain/gedabuyisi.com/relations

 

[18] https://www.virustotal.com/gui/domain/sezijiru.com/relations.

 

[19] https://github.com/ByteSecLabs/ja3-ja3s-combo/blob/master/master-list.txt 

 

[21] https://www.darkreading.com/perimeter/ftp-hacking-on-the-rise

 

[22] https://www.pcrisk.com/removal-guides/23352-quantum-ransomware

 

[23] https://www.cohesity.com/resource-assets/tip-sheet/5-ways-ransomware-renders-backup-useless-tip-sheet-en.pdf

 

[24] https://www.forbes.com/sites/nishatalagala/2022/03/02/data-as-the-new-oil-is-not-enough-four-principles-for-avoiding-data-fires/ 

 

[25] https://www.bleepingcomputer.com/news/security/access-to-hacked-corporate-networks-still-strong-but-sales-fall/

 

[26] https://www.bleepingcomputer.com/news/security/ransom-payments-fall-as-fewer-victims-choose-to-pay-hackers/ 

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.
Author
Nicole Wong
Cyber Security Analyst
Book a 1-1 meeting with one of our experts
Share this article

More in this series

No items found.

Blog

/

November 5, 2024

/

Inside the SOC

Onomastics Gymnastics : How Darktrace Detects Spoofing and Business Email Compromise in Multi-Name Users

Default blog imageDefault blog image

Note: For privacy reasons, actual surnames and email addresses observed in these incidents below have been replaced with fictitious placeholder names, using the common Spanish names “Fulano” and “Mengano”.

Naming conventions

Modeling names and their variants of members of an organization is a critical component to properly detect if those same names and variants are being spoofed by malicious actors. For many predominantly English-speaking organizations, these variants can largely be captured by variants of a person’s given name (e.g. James-Jimmy-Jim) and a consistent, singular surname or family name (e.g. Smith). Naming conventions, however, are far from universal. This piece will review how Darktrace / EMAIL manages the common naming conventions of much of the Spanish-speaking world, and can use its modeling to create high-fidelity detections of multiple types of spoofing attempts.

A brief summary of the common convention across Spain and much of Spanish-speaking America: most people are given one or two given names (e.g. Roberto, Juan, María, Natalia), and their surnames are the first surname of their father, followed by the first surname of their mother. While there are various exceptions to this norm, the below graphic Wikipedia [1][2] highlights the general rule.

Example Spanish naming convention for father “José García Torres” and mother “María Acosta Gómez” for child “Pablo García Acosta”. If shortened to one surname, the convention holds the child would be referred to as “Pablo García”
Figure 1: Example Spanish naming convention for father “José García Torres” and mother “María Acosta Gómez” for child “Pablo García Acosta”. If shortened to one surname, the convention holds the child would be referred to as “Pablo García” [1].

Detection of improper name usage

Implicit in the above comment that shortening to one surname follows the convention of using the first surname, shortening to the second surname is often a tell-tale sign of someone unfamiliar with the person or their broader culture. This can be a useful corroborating feature in detecting a spoof attempt – analogous to a spelling error.

In the case of a Spanish customer, this misuse of name shortening contributed to the detection of a spoof attempt trying to solicit a response by impersonating an internal user forwarding information about ‘Data Protection’.

Figure 2: The Cyber AI Analyst summary of the Darktrace / EMAIL detections shows the use of the Gmail sender impersonating Isabel Maria Fulano Mengano, but incorrectly uses the second surname Mengano.

While the limited communication history from the sender and the nature of the text content already marks the mail as suspicious, Darktrace / EMAIL notes the personal name used in the email is similar to a high-value user (‘whale’ to use the terminology of spearphishing). The additional context provided by the detection of the attempted spoof prompted more severe actioning of this email, leading to a ‘Hold’ action instead of a less-severe ‘Unspoof’ action via a banner on the email.

The content summary of the sender showing the ‘Personal’ field of the email being ‘Isabel Mengano’, breaking from the standard name-shortening convention. The additional metrics identify features that might be anomalous about the sender.
Figure 3: The content summary of the sender showing the ‘Personal’ field of the email being ‘Isabel Mengano’, breaking from the standard name-shortening convention. The additional metrics identify features that might be anomalous about the sender.

Malicious email properly using both surnames

Misusing the name-shortening convention is not the only way that Darktrace / EMAIL can detect spoofing attempts. In the case of another Spanish customer,  Darktrace observed a whale impersonation being sent to 230 users with solicitation content, but no links or attachments. Although the name was modeled internally in the “Surname, Given-name” format, Darktrace identified the spoofing attempt targeting a high-value user and took action, blocking the series of emails from reaching end-user inboxes to prevent unsuspecting users from responding.

Cyber AI Analyst summary of a suspicious email
Figure 4: Cyber AI Analyst summary of a suspicious email. The personal field is visible as ‘juan fulano mengano’, which is consistent with the reverse-order modelled user ‘fulano mengano, juan’. The subject line ‘Urgent Request’ sent to 230 users gives an intuitive indicator of the emails potentially being part of a malicious solicitation campaign.

In Summary: A case of onomastics gymnastics

The variety in valid usage of human language can be a barrier to evaluating when a given text is benign or malicious. Despite this, Darktrace / EMAIL is designed to manage this variety, as exemplified by the detections of two spoofing attempts seen against organizations using the distinct Spanish-speaking world’s common naming convention. The scope of this design as seen in this onomastic context, extends to a wide range of detections surrounding emails and their behavioral anomalies.

Credit to Roberto Romeu (Principal Cyber Analyst), Justin Torres (Senior Cyber Analyst) and Natalia Sánchez Rocafort (Senior Analyst Consultant).

Darktrace / Email solution brief screenshot

Secure Your Inbox with Cutting-Edge AI Email Protection

Discover the most advanced cloud-native AI email security solution to protect your domain and brand while preventing phishing, novel social engineering, business email compromise, account takeover, and data loss.

  • Gain up to 13 days of earlier threat detection and maximize ROI on your current email security
  • Experience 20-25% more threat blocking power with Darktrace / EMAIL
  • Stop the 58% of threats bypassing traditional email security

References

[1] https://en.wikipedia.org/wiki/Naming_customs_of_Hispanic_America

[2] https://en.wikipedia.org/wiki/Spanish_naming_customs

Continue reading
About the author
Roberto Romeu
Senior SOC Analyst

Blog

/

October 31, 2024

/

OT

Understanding the NERC-CIP015 Internal Network Security Monitoring (INSM) Requirements

Default blog imageDefault blog image

Background: NERC CIP-015

In January of 2023 the Federal Energy Regulatory Commission (FERC) released FERC Order 887 which addresses a critical security gap in Critical Infrastructure Protection (CIP) standards, the lack of internal network security monitoring (INSM).

The current NERC CIP standards only require solutions that use traditional detection systems that identify malicious code based on known rules and signatures. The new legislation will now require electric cooperatives to implement INSMs to detect malicious activity in east-west network traffic. INSMs establish a baseline of network activity and detect anomalies that would bypass traditional detection systems, improving an organization’s ability to detect novel threats. Without INSM, organizations have limited visibility into malicious activities inside their networks, leaving them vulnerable if attackers breach initial defenses like firewalls and anti-virus software.

Implementation of NERC CIP-015

Once approved, Bulk Electronic Systems (BESs) will have 36 months to implement INSM, and medium-impact BESs with external routable connectivity (ERC) will have 60 months to do so.

While the approval of the NERC CIP-015 requirements have not been finalized, preparation on the part of electric cooperatives should start as soon as possible. Darktrace is committed to helping electric cooperatives meet the requirements for INSM and help reach compliance standards.

Why is internal network security monitoring important?

NERC CIP-015 aims to enhance the detection of anomalies or unauthorized network activity within CIP environments, underscoring the importance of monitoring East-West traffic within trust zones. This approach enables faster response and recovery times.

INSMs are essential to detecting threats that bypass traditional defenses. For example, insider threats, sophisticated new attack techniques, and threats that exploit compromised credentials—such as those obtained through phishing or other malicious activities—can easily bypass traditional firewalls and antivirus software. These threats either introduce novel methods or leverage legitimate access, making them difficult to detect.

INSMs don’t rely on rules and signatures to detect anomalous activity, they spot abnormalities in network traffic and create alerts based on this activity making them vital to detecting sophisticated threats. Additionally, INSM sits behind the firewall and provides detections utilizing the passive monitoring of east west and north south traffic within the enforcement boundary.

Buyers should be aware of the discrepancies between different INSMs. Some systems require constant tuning and updating, external connectivity forcing holes in segmentation or have intrusive deployments that put sensitive OT assets at risk.

What are the NERC CIP-015 requirements?

The goal of this directive is to ensure that cyber threats are identified early in the attack lifecycle by mandating implementation of security systems that detect and speed up mitigation of malicious activity.

The requirements are divided into three sections:

  • Network security monitoring
  • Data retention for anomalous activity
  • Data protection

NERC CIP-015 emphasizes the importance of having documented processes and evidence of implementation, with a focus on risk-based monitoring, anomaly detection, evaluation, retention of data, and protection against unauthorized access. Below is a breakdown of each requirement.

R1: Network Security Monitoring

The NERC CIP-015 requires the implementation of and a documented process for monitoring networks within Electronic Security Perimeters (ESPs) that contain high and medium impact BES Cyber Systems.

Key parts:

Part 1.1: Use a risk-based rationale to implement network data feeds that monitor connections, devices, and communications.

Part 1.2: Detect anomalous network activity using the data feeds.

Part 1.3: Evaluate the anomalous activity to determine necessary actions.

M1: Evidence for R1 Implementation: Documentation of processes, including risk-based rationale for data collection, detection events, configuration settings, and network baselines.

Incorporating automated solutions for network baselining is essential for effective internal monitoring, especially in diverse environments like substations and control centers. Each environment requires unique baselines—what’s typical for a substation may differ significantly from a control center, making manual monitoring impractical.

A continuous internal monitoring solution powered by artificial intelligence (AI) simplifies this challenge by instantly detecting all connected assets, dynamically learning the environment’s baseline behavior, and identifying anomalies in real-time. Unlike traditional methods, Darktrace’s AI-driven approach requires no external connectivity or repeated tuning, offering a seamless, adaptive solution for maintaining secure operations across all environments.

R2: Data Retention for Anomalous Activity

Documented processes must be in place to retain network security data related to detected anomalies until the required actions are completed.

Note: Data that does not relate to detected anomalies (Part 1.2) is not required to be retained.

M2: Evidence for Data Retention (R2): Documentation of data retention processes, system configurations, or reports showing compliance with R2.

R3: Data Protection: Implement documented processes to protect the collected security monitoring data from unauthorized deletion or modification.

M3: Evidence for Data Protection (R3): Documentation demonstrating how network security monitoring data is protected from unauthorized access or changes.

How to choose the right INSM for your organization?

Several vendors will offer INSM, but how do you choose the right solution for your organization?

Here are seven questions to help you get started evaluating potential INSM vendors:

  1. How does the solution help with ongoing compliance and reporting including CIP-015? Or any other regulations we comply with?
  2. Does the solution provide real-time monitoring of east-west traffic across critical systems? And what kind of threats has it proven capable of finding?
  3. How deep is the traffic visibility—does it offer Layer 7 (application) insights, or is it limited to Layers 3-4?
  4. Is the solution compatible with our existing infrastructure (firewalls, IDS/IPS, SIEM, OT networks)?
  5. Is this solution inline, passive, or hybrid? What impact will it have on network latency?
  6. Does the vendor have experience with electric utilities or critical infrastructure environments?
  7. Where and how are logs and monitoring data stored?

How Darktrace helps electric utilities with INSM requirements

Darktrace's ActiveAI Security Platform is uniquely designed to continuously monitor network activity and detect anomalous activity across both IT and OT environments successfully detecting insider threats and novel ransomware, while accelerating time to detection and incident reporting.

Most INSM solutions require repeated baselining, which creates more work and increases the likelihood of false positives, as even minor deviations trigger alerts. Since networks are constantly changing, baselines need to adjust in real time. Unlike these solutions, Darktrace does not depend on external connectivity or cloud access over the public internet. Our passive network analysis requires no agents or intrusive scanning, minimizing disruptions and reducing risks to OT systems.

Darktrace's AI-driven threat detection, asset management, and incident response capabilities can help organizations comply with the requirements of NERC CIP-015 for internal network security monitoring and data protection. Built specifically to deploy in OT environments, Darktrace / OT comprehensively manages, detects, evaluates, and protects network activity and anomalous events across IT and OT environments, facilitating adherence to regulatory requirements like data retention and anomaly management.

See how INSM with Darktrace can enhance your security operations, schedule a personalized demo today.

Disclaimer

The information provided in this blog is intended for informational purposes only and reflects Darktrace’s understanding of the NERC CIP-015 INSM requirements as of the publication date. While every effort has been made to ensure the accuracy and reliability of the content, Darktrace makes no warranties or representations regarding its accuracy, completeness, or applicability to specific situations. This blog does not constitute legal or compliance advice and readers are encouraged to consult with qualified professionals for guidance specific to their circumstances. Darktrace disclaims any liability for actions taken or not taken based on the information contained herein.

References

1.     https://www.nerc.com/pa/Stand/Reliability%20Standards/CIP-015-1.pdf

Continue reading
About the author
Daniel Simonds
Director of Operational Technology
Your data. Our AI.
Elevate your network security with Darktrace AI