Category: ICT

News In Brief – Source: US Computer Emergency Readiness Team

CISA has added one new vulnerability to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. See CISA’s Alert Microsoft Releases Guidance on Exploitation of SharePoint Vulnerability (CVE-2025-53770) for more information and to apply the recommended mitigations. 

• CVE-2025-53770: Microsoft SharePoint Server Remote Code Execution Vulnerability

These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise.

Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information.

Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the specified criteria.

News In Brief – Source: US Computer Emergency Readiness Team

Summary

Note: This joint Cybersecurity Advisory is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), Department of Health and Human Services (HHS), and Multi-State Information Sharing and Analysis Center (MS-ISAC)—hereafter referred to as “the authoring organizations”—are releasing this joint advisory to disseminate known Interlock ransomware IOCs and TTPs identified through FBI investigations (as recently as June 2025) and trusted third-party reporting.

The Interlock ransomware variant was first observed in late September 2024, targeting various business, critical infrastructure, and other organizations in North America and Europe. FBI maintains these actors target their victims based on opportunity, and their activity is financially motivated. FBI is aware of Interlock ransomware encryptors designed for both Windows and Linux operating systems; these encryptors have been observed encrypting virtual machines (VMs) across both operating systems. FBI observed actors obtaining initial access via drive-by download from compromised legitimate websites, which is an uncommon method among ransomware groups. Actors were also observed using the ClickFix social engineering technique for initial access, in which victims are tricked into executing a malicious payload under the guise of fixing an issue on the victim’s system. Actors then use various methods for discovery, credential access, and lateral movement to spread to other systems on the network.

Interlock actors employ a double extortion model in which actors encrypt systems after exfiltrating data, which increases pressure on victims to pay the ransom to both get their data decrypted and prevent it from being leaked. 

FBI, CISA, HHS, and MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of Interlock ransomware incidents.

Download the PDF version of this report:

For a downloadable copy of IOCs, see:

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 17. See the MITRE ATT&CK Tactics and Techniques section of this advisory for tables mapped to the threat actors’ activity.

Overview

Since September 2024, Interlock ransomware actors have impacted a wide range of businesses and critical infrastructure sectors in North America and Europe. These actors are opportunistic and financially motivated in nature and employ tactics to infiltrate and disrupt the victim’s ability to provide their essential services. 

Interlock actors leverage a double extortion model, in which they both encrypt and exfiltrate victim data. Ransom notes do not include an initial ransom demand or payment instructions; instead, victims are provided with a unique code and are instructed to contact the ransomware group via a .onion URL through the Tor browser. To date, Interlock actors have been observed encrypting VMs, leaving hosts, workstations, and physical servers unaffected; however, this does not mean they will not expand to these systems in the future. To counter Interlock actors’ threat to VMs, enterprise defenders should implement robust endpoint detection and response (EDR) tooling and capabilities.

The authoring agencies are aware of emerging open-source reporting detailing similarities between the Rhysida and Interlock ransomware variants.¹ For additional information on Rhysida ransomware, see the joint advisory, #StopRansomware: Rhysida Ransomware.

Initial Access

FBI has observed Interlock actors obtaining initial access [TA0001] via drive-by download [T1189] from compromised legitimate websites, an atypical method for ransomware actors. Interlock ransomware methods for initial access have previously disguised malicious payloads as fake Google Chrome or Microsoft Edge browser updates, though a cybersecurity company recently reported a shift to payload filenames masquerading as updates for common security software (see Table 5 for a list of filenames).²

In some instances, FBI has observed Interlock actors using the ClickFix social engineering technique, in which unsuspecting users are prompted to execute a malicious payload by clicking a fake Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) [T1189]. The CAPTCHA contains instructions for users to open the Windows Run window, paste the clipboard contents, and then execute a malicious Base64-encoded PowerShell process [T1204.004].³

Note: This ClickFix technique has been used in several other malware campaigns, including Lumma Stealer and DarkGate.⁴

Execution and Persistence

Based on FBI investigations, the fake Google Chrome browser executable functions as a remote access trojan (RAT) [T1105] designed to execute a PowerShell script [T1059.001] that drops a file into the Windows Startup folder. From there, the file is designed to run the RAT every time the victim logs in [T1547.001], establishing persistence [TA0003]. 

FBI also observed instances in which Interlock actors executed a PowerShell command designed to establish persistence via a Windows Registry key modification [T1547.001]. To do so, Interlock actors used a PowerShell command [T1059.001] designed to add a run key value named “Chrome Updater” [T1036.005] that uses a specific log file as an argument upon user login.

Reconnaissance

To facilitate reconnaissance, a PowerShell script executes a series of commands [T1059.001] designed to gather information on victim machines (see Table 1).

Table 1. PowerShell Commands for Reconnaissance

PowerShell Command	Description
WindowsIdentity.GetCurrent()	Returns a WindowsIdentity object that represents the current Windows user [T1033].
systeminfo	Displays detailed configuration information [T1082] about a computer and its operating system, including operating system configuration, security information, product ID, and hardware properties.
tasklist/svc	Lists unabridged service information [T1007] for each process currently running on the local computer.
Get-Service	Gets objects that represent the services [T1007] on a computer, including running and stopped services.
Get-PSDrive	Gets the drives [T1082] in the current session, such as: Windows logical drives on the computer, including drives mapped to network shares. Drives exposed by PowerShell providers. Session-specified temporary drives and persistent mapped network drives.
arp -a	Displays and modifies entries in the Address Resolution Protocol (ARP) cache table [T1016], which contains entries on the IPv4 and IPv6 addresses on host endpoints.

Command and Control

FBI observed Interlock actors using command and control (C2) [TA0011] applications like Cobalt Strike and SystemBC. Interlock actors also used Interlock RAT⁵ and NodeSnake RAT (as of March 2025)⁶ for C2 and executing commands.

Credential Access, Lateral Movement, and Privilege Escalation

FBI observed that once Interlock actors establish remote control of a compromised system, they use a series of PowerShell commands to download a credential stealer (cht.exe) [TA0006] and keylogger binary (klg.dll) [T1056.001],[T1105]. According to open source reporting, the credential stealer collects login information and associated URLs for victims’ online accounts [T1555.003], while the keylogger dynamic link library (DLL) logs users’ keystrokes in a file named conhost.txt [T1036.005].⁷ As of February 2025, private cybersecurity analysts also observed Interlock ransomware infections executing different versions of information stealers [TA0006], including Lumma Stealer⁸ and Berserk Stealer, to harvest credentials for lateral movement and privilege escalation [T1078].⁹

Interlock actors leverage compromised credentials and Remote Desktop Protocol (RDP)¹⁰ [T1021.001] to move between systems. They also use tools like AnyDesk to enable remote connectivity and PuTTY to assist with lateral movement [T1219].¹¹ In addition to stealing users’ online credentials, Interlock actors have compromised domain administrator accounts (possibly by using a Kerberoasting attack [T1558.003])¹² to gain additional privileges [T1078.002]. 

Collection and Exfiltration

Interlock actors leverage Azure Storage Explorer (StorageExplorer.exe) to navigate victims’ Microsoft Azure Storage accounts [T1530] prior to exfiltrating data. According to open source reporting, Interlock actors execute AzCopy to exfiltrate data by uploading it to the Azure storage blob [T1567.002].¹³ Interlock actors also exfiltrate data over file transfer tools, including WinSCP [T1048].

Impact

Following data exfiltration, Interlock actors deploy the encryption binary as a 64-bit executable named conhost.exe [T1486],[T1036.005]. FBI has observed Interlock ransomware encryptors for both Windows and Linux operating systems. Encryptors are designed to encrypt files using a combined Advanced Encryption Standard (AES) and Rivest-Shamir-Adleman (RSA) algorithm. In addition, cybersecurity researchers have identified Interlock ransomware samples using a FreeBSD ELF encryptor [T1486], a departure from usual Linux encryptors designed for VMware ESXi servers and VMs.¹⁴

A cybersecurity company identified a DLL binary named tmp41.wasd—executed after encryption using rundll32.exe [T1218.011]—which uses the remove() function to delete the encryption binary [T1070.004];¹⁵ on Linux machines, the encryptor uses a similar technique to execute the removeme function. 

Encrypted files are appended with either a .interlock or .1nt3rlock file extension, alongside a ransom note titled !__README__!.txt delivered via group policy object (GPO). Interlock actors use a double-extortion model [T1657], encrypting systems after exfiltrating data. The ransom note provides each victim with a unique code and instructions to contact the ransomware actors via a .onion URL. 

Interlock actors do not leave an initial ransom demand or payment instructions on compromised networks, and do not relay this information until contacted by the victim. The actors instruct victims to make ransom payments in Bitcoin to cryptocurrency wallet addresses provided by the actors. The actors threaten to publish the victim’s exfiltrated data to their leak site on the Tor network unless the victim pays the ransom demand; the actors have previously followed through on this threat.¹⁶

See Table 2 for publicly available tools and applications used by Interlock ransomware actors. This includes legitimate tools repurposed for their operations.

Disclaimer: Use of these tools and applications should not be attributed as malicious without analytical evidence to support threat actor use and/or control.

Table 2. Tools Used by Interlock Ransomware Actors

Tool Name	Description
AnyDesk	A common legitimate remote monitoring and management (RMM) tool maliciously used by Interlock actors to obtain remote access and maintain persistence. AnyDesk also supports remote file transfer.
Cobalt Strike	A penetration testing tool used by security professionals to test the security of networks and systems.
PowerShell	A cross-platform task automation solution made up of a command-line shell, a scripting language, and a configuration management framework, which runs on Windows, Linux, and macOS.
PSExec	A tool designed to run programs and execute commands on remote systems.
PuTTY.exe	An open source file transfer application commonly used to remotely connect to systems via Secure Shell (SSH). PuTTY also supports file transfer protocols like Secure File Transfer Protocol (SFTP) and Secure Copy Protocol (SCP).
ScreenConnect	A remote support, access, and meeting software that allows users to control devices remotely over the internet. CISA observed Interlock actors using a cracked version of this software in at least one incident. These versions may be standalone versions not connecting to ScreenConnect’s official cloud domains (domains available upon request from ConnectWise).
SystemBC	Enables Interlock actors to compromise systems, run commands, download malicious payloads, and act as a proxy tool to the actors’ C2 servers.
Windows Console Host	Windows Console Host (conhost.exe) manages the user interface for command-line applications in Windows, including Command Prompt and PowerShell.
WinSCP	A free and open source SSH File Transfer Protocol (FTP), WebDAV, Amazon S3, and secure copy protocol client.

See Table 3 and Table 4 for files used by Interlock ransomware actors. These were obtained from FBI investigations as recently as June 2025.

Disclaimer: Some of the hashes are for legitimate tools and applications and should not be attributed as malicious without analytical evidence to support threat actor use and/or control. The authoring agencies recommend organizations investigate or vet these hashes prior to taking action, such as blocking.

Table 3. Files Used by Interlock Ransomware Actors (SHA-256)

File Name	Hash
1.ps1	fba4883bf4f73aa48a957d894051d78e0085ecc3170b1ff50e61ccec6aeee2cd
advanced_port_scanner.exe	4b036cc9930bb42454172f888b8fde1087797fc0c9d31ab546748bd2496bd3e5
Aisa.exe	18a507bf1c533aad8e6f2a2b023fbbcac02a477e8f05b095ee29b52b90d47421
AnyDesk.exe	1a70f4eef11fbecb721b9bab1c9ff43a8c4cd7b2cafef08c033c77070c6fe069
autoservice.dll	a4069aa29628e64ea63b4fb3e29d16dcc368c5add304358a47097eedafbbb565
Autostart.exe	d535bdc9970a3c6f7ebf0b229c695082a73eaeaf35a63cd8a0e7e6e3ceb22795
cht	FAFCD5404A992850FFCFFEE46221F9B2FF716006AECB637B80E5CD5AA112D79C
cht.exe	C20BABA26EBB596DE14B403B9F78DDC3C13CE9870EEA332476AC2C1DD582AA07
cleanup.dll (SystemBC)	1845a910dcde8c6e45ad2e0c48439e5ab8bbbeb731f2af11a1b7bbab3bfe0127
conhost	44887125aa2df864226421ee694d51e5535d8c6f70e327e9bcb366e43fd892c1
conhost.dll	a70af759e38219ca3a7f7645f3e103b13c9fb1db6d13b68f3d468b7987540ddf
conhost.dll	96babe53d6569ee3b4d8fc09c2a6557e49ebc2ed1b965abda0f7f51378557eb1
difxepi.dll (SystemBC)	1845a910dcde8c6e45ad2e0c48439e5ab8bbbeb731f2af11a1b7bbab3bfe0127
iexplore.exe	d0c1662ce239e4d288048c0e3324ec52962f6ddda77da0cb7af9c1d9c2f1e2eb
klg.dll	A4F0B68052E8DA9A80B70407A92400C6A5DEF19717E0240AC608612476E1137E
!!!OPEN_ME!!!.txt	68A49D5A097E3850F3BB572BAF2B75A8E158DADB70BADDC205C2628A9B660E7A
processhacker-2.39-bin.zip	88f26f3721076f74996f8518469d98bf9be0eaee5b9eccc72867ebfc25ea4e83
PsExec.exe	078163d5c16f64caa5a14784323fd51451b8c831c73396b967b4e35e6879937b
putty.exe	7a43789216ce242524e321d2222fa50820a532e29175e0a2e685459a19e09069
puttyportable.exe	97931d2e2e449ac3691eb526f6f60e2f828de89074bdac07bd7dbdfd51af9fa0
PuTTYPortable.zip	ff7ad2376ae01e4b3f1e1d7ae630f87b8262b5c11bc5d953e1ac34ffe81401b5
qrpce91.exe.asd	64a0ab00d90682b1807c5d7da1a4ae67cde4c5757fc7d995d8f126f0ec8ae983
ScreenConnect.ClientService.exe	2814b33ce81d2d2e528bb1ed4290d665569f112c9be54e65abca50c41314d462
SophosendpointAgent.exe	f51b3d054995803d04a754ea3ff7d31823fab654393e8054b227092580be43db
SophosScaner.exe	dfb5ba578b81f05593c047f2c822eeb03785aecffb1504dcb7f8357e898b5024
Starship.exe	94bf0aba5f9f32b9c35e8dfc70afd8a35621ed6ef084453dc1b10719ae72f8e2
start	28c3c50d115d2b8ffc7ba0a8de9572fbe307907aaae3a486aabd8c0266e9426f
start.exe	70bb799557da5ac4f18093decc60c96c13359e30f246683815a512d7f9824c8f
StorageExplorer.exe	73a9a1e38ff40908bcc15df2954246883dadfb991f3c74f6c514b4cffdabde66
Sysmon.sys	1d04e33009bcd017898b9e1387e40b5c04279c02ebc110f12e4a724ccdb9e4fb
upd_2327991.exe	7b9e12e3561285181634ab32015eb653ab5e5cfa157dd16cdd327104b258c332
webujgd.lnk	70EE22D394E107FBB807D86D187C216AD66B8537EDC67931559A8AEF18F6B5B3
WinSCP-6.3.5-Setup.exe	8eb7e3e8f3ee31d382359a8a232c984bdaa130584cad11683749026e5df1fdc3
Proxy Tool	e4d6fe517cdf3790dfa51c62457f5acd8cb961ab1f083de37b15fd2fddeb9b8f
Encryptor	e86bb8361c436be94b0901e5b39db9b6666134f23cce1e5581421c2981405cb1
Encryptor	c733d85f445004c9d6918f7c09a1e0d38a8f3b37ad825cd544b865dba36a1ba6
Encryptor	28c3c50d115d2b8ffc7ba0a8de9572fbe307907aaae3a486aabd8c0266e9426f

Table 4. Files Used by Interlock Ransomware Actors (SHA-1)

File Name	Hash
autorun.log	514946a8fc248de1ccf0dbeee2108a3b4d75b5f6
jar.jar	b625cc9e4024d09084e80a4a42ab7ccaa6afb61d
pack.jar	3703374c9622f74edc9c8e3a47a5d53007f7721e

See Table 5 through Table 16 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Table 5. Initial Access

Technique Title	ID	Use
Drive-By Compromise	T1189	Interlock actors obtain initial access by compromising a legitimate website that network users visit, or by disguising malicious payloads as fake browser updates or common security software, including the following:17 FortiClient.exe Ivanti-Secure-Access-Client.exe GlobalProtect.exe Webex.exe AnyConnectVPN.exe Cisco-Secure-Client.exe zyzoom_antimalware.exe Interlock actors also gain access via the ClickFix social engineering technique, in which users are tricked into executing a malicious payload by clicking on a fake CAPTCHA that prompts users to execute a malicious PowerShell script.

Table 6. Execution

Technique Title	ID	Use
Command and Scripting Interpreter: PowerShell	T1059.001	Interlock actors implement PowerShell scripts to drop a malicious file into the Windows Startup folder. Interlock actors execute a PowerShell command for registry key modification. Interlock actors use a PowerShell script to execute a series of commands to facilitate reconnaissance.
User Execution: Malicious Copy and Paste	T1204.004	Via the ClickFix social engineering technique, users are tricked into clicking a fake CAPTCHA and prompted into executing a malicious Base64-encoded PowerShell process by following instructions to open a Windows Run window (Windows Button + R), pasting clipboard contents (“CTRL + V”), and then executing the malicious script (“Enter”).

Table 7. Persistence

Technique Title	ID	Use
Boot or Logon Autostart Execution: Registry Run Keys/Startup Folder	T1547.001	Interlock actors establish persistence by adding a file into a Windows StartUp folder that executes a RAT every time a user logs in. Interlock actors also implement registry key modification by using a PowerShell command to add a run key value (named “Chrome Updater”) that uses a log file as an argument every time a user logs in.

Table 8. Privilege Escalation

Technique Title	ID	Use
Valid Accounts: Domain Accounts	T1078.002	Interlock actors compromise domain administrator accounts to gain additional privileges.

Table 9. Defense Escalation

Technique Title	ID	Use
Defense Evasion	TA0005	Interlock actors execute the removeme function on Linux systems to delete the encryption binary for defense evasion.
Masquerading: Match Legitimate Resource Name or Location	T1036.005	Interlock actors disguise a malicious run key value by naming it “Chrome Updater”; the run key value uses a specific log file as an argument upon user login. Interlock actors disguise files of keystrokes logged by one of their credential stealers with a legitimate Windows filename: conhost.txt. Interlock actors disguise an encryption binary, a 64-bit executable, by giving it the same name as the legitimate Console Windows Host executable: conhost.exe
System Binary Proxy Execution: Rundll32	T1218.011	Interlock actors use rundll32.exe to proxy execution of a malicious DLL binary tmp41.wasd.
Indicator Removal: File Deletion	T1070.004	Interlock actors execute a DLL binary tmp41.wasd that uses the remove() function to delete their encryption binary for defense evasion.

Table 10. Credential Access

Technique Title	ID	Use
Credential Access	TA0006	Interlock actors download credential stealer cht.exe and execute other versions information stealers (including Lumma Stealer and Berserk Stealer) to harvest credentials.
Credentials from Password Stores: Credentials from Web Browsers	T1555.003	Interlock actors download a credential stealer that collects login information and associated URLs for victims’ online accounts.
Input Capture	T1056	Interlock actors execute Lumma Stealer and Berserk Stealer information stealers on victim systems.
Input Capture: Keylogging	T1056.001	Interlock actors download klg.dll, a keylogger binary, onto compromised systems, where it logs users’ keystrokes in a file named conhost.txt.
Steal or Forge Kerberos Tickets: Kerberoasting	T1558.003	Interlock actors possibly use a Kerberoasting attack to compromise domain administrator accounts.

Table 11. Discovery

Technique Title	ID	Use
System Owner/User Discovery	T1033	Interlock actors execute a PowerShell command WindowsIdentity.GetCurrent() on victim systems to retrieve a WindowsIdentity object that represents the current Windows user.
System Information Discovery	T1082	Interlock actors execute a PowerShell command systeminfo on victim systems to access detailed configuration information about the system, including OS configuration, security information, product ID, and hardware properties. Interlock actors execute a PowerShell command Get-PSDrive on victim systems to discover the drives in the current session, such as:  Windows logical drives on the computer, including drives mapped to network shares. Drives exposed by PowerShell providers. Session-specified temporary drives and persistent mapped network drives.
System Service Discovery	T1007	Interlock actors execute a PowerShell command tasklist /svc on victim systems that lists service information for each process currently running on the system.  Actors also execute a PowerShell command Get-Service on victim systems that retrieves objects that represent the services (including running and stopped services) on the system.
System Network Configuration Discovery	T1016	Interlock actors execute a PowerShell command arp -a on victim systems that displays and modifies entries in the Address Resolution Protocol (ARP) cache table (which contains entries on the IPv4 and IPv6 addresses on host endpoints).

Table 12. Lateral Movement

Technique Title	ID	Use
Valid Accounts	T1078	Interlock actors harvest and abuse valid credentials for lateral movement and privilege escalation.
Remote Services: Remote Desktop Protocol	T1021.001	Interlock actors use RDP and valid credentials to move laterally between systems.

Table 13. Collection

Technique Title	ID	Use
Data from Cloud Storage	T1530	Interlock actors use StorageExplorer.exe, the cloud storage solution Azure Storage Explorer, to explore Microsoft Azure Storage accounts.

Table 14. Command and Control

Technique Title	ID	Use
Command and Control	TA0011	Interlock actors use applications Cobalt Strike and SystemBC for C2.
Ingress Tool Transfer	T1105	Interlock actors use a fake Google Chrome or Microsoft Edge browser update to cause users to execute a RAT on the victimized system. Interlock actors download credential stealers (cht.exe) and keylogger binaries (klg.dll) once actors establish remote control of a compromised system.
Remote Access Tools	T1219	Interlock actors use legitimate remote access tools such as AnyDesk to enable remote connectivity and PuTTY to assist with lateral movement.

Table 15. Exfiltration

Technique Title	ID	Use
Exfiltration Over Web Service: Exfiltration to Cloud Storage	T1567.002	Interlock actors exfiltrate data to cloud storage by executing AzCopy to upload data to the Azure storage blob.
Exfiltration Over Alternative Protocol	T1048	Interlock actors use file transfer tools like WinSCP to exfiltrate data.

Table 16. Impact

Technique Title	ID	Use
Data Encrypted for Impact	T1486	Interlock actors encrypt victim data using a combined AES and RSA algorithm on compromised systems to interrupt availability to system and network resources. Actors code encryptors using C/C++. Interlock actors use encryptors for both Windows and Linux operating systems.  Interlock actors also use a FreeBSD ELF encryptor to encrypt victim data.
Financial Theft	T1657	Interlock actors deliver a ransom note titled !__README__!.txt via a GPO which provides victims with instructions to use a .onion URL to contact the actors over the Tor network. Actors use a double-extortion model, both encrypting victim data and threatening release of victim data on their Tor network leak site if the ransom is not paid.

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the Interlock ransomware actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

In addition to the below mitigations, Healthcare and Public Health (HPH) organizations should use HPH Sector CPGs to implement cybersecurity protections to address the most common threats and TTPs used against this sector.

At-risk organizations should implement the following mitigations:

• Prevent Interlock ransomware actors from obtaining initial access:
  • Implement domain name system (DNS) filtering to block users from accessing malicious sites and applications.
  • Implement web access firewalls to mitigate and prevent unknown commands or process injection from malicious domains or websites.
  • Train users [CPG 2.I] to identify, avoid, and report social engineering attempts.
• Implement a recovery plan [CPG 5.A] to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, the cloud) [CPG 2.R].
• Require all accounts with password logins (e.g., service accounts, admin accounts, and domain admin accounts) to comply with NIST password standards.
  • Require employees to use long passwords [CPG 2.B] and consider not requiring recurring password changes, as these can weaken security.
• Require MFA [CPG 2.H] for all services to the extent possible, particularly for webmail, virtual private networks (VPNs), and accounts that access critical systems.
  • Implement ICAM policies across the organization as a precursor to MFA.
• Keep all operating systems, software, and firmware up to date; prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
  • Timely patching is efficient and cost effective for minimizing an organization’s exposure to cybersecurity threats.
• Implement robust EDR capabilities on VMs, systems, and networks.
• Segment networks [CPG 2.F] to prevent the spread of ransomware.
  • Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware [CPG 3.A] with a networking monitoring tool [CPG 2.T].
  • To aid in detecting ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network.
  • Implement EDR tools; these are useful for detecting lateral connections as they provide insight into common and uncommon network connections for each host.
• Filter network traffic by preventing unknown or untrusted origins from accessing remote services on internal systems.
  • This prevents threat actors from directly connecting to remote access services that they have established for persistence.
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 2.E].
• Disable unused ports.
• Consider adding an email banner to emails received from outside of your organization [CPG 2.M].
• Disable hyperlinks in received emails.
• Implement time-based access for accounts set at the admin level and higher; for example, the just-in-time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model):
  • This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need.
  • Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
• Disable command line and scripting activities and permissions [CPG 2.N].
  • Disabling software utilities that run from the command line makes it more difficult for threat actors to escalate privileges and move laterally.
• Maintain offline backups of data and regularly maintain backups and restorations [CPG 2.R]; this avoids severe service interruption and irretrievable data in the event of a compromise.
• Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.R].

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 5 through Table 16).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Your organization has no obligation to respond or provide information back to FBI in response to this joint advisory. If, after reviewing the information provided, your organization decides to provide information to FBI, reporting must be consistent with applicable state and federal laws.

FBI is interested in any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with threat actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

Additional details of interest include a targeted company point of contact, status and scope of infection, estimated loss, operational impact, transaction IDs, date of infection, date detected, initial attack vector, and host- and network-based indicators.

The authoring agencies do not encourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, FBI and CISA urge you to promptly report ransomware incidents to FBI’s Internet Crime Complain Center (IC3), a local FBI Field Office, or CISA via the agency’s Incident Reporting System or its 24/7 Operations Center (contact@mail.cisa.dhs.gov) or by calling 1-844-Say-CISA (1-844-729-2472).

State, local, tribal, and territorial governments should report incidents to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

HPH Sector organizations should report incidents to FBI or CISA but also can reach out to HHS at HHScyber@hhs.gov for cyber incident support focused on mitigating adverse patient impacts.

The information in this report is being provided “as is” for informational purposes only. The authoring agencies do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favor by the authoring agencies. 

Cisco Talos contributed to this advisory.

July 22, 2025: Initial version.

¹ Elio Biasiotto, et. al., “Unwrapping the Emerging Interlock Ransomware Attack,” Talos Intelligence (blog), Cisco Talos, last modified November 7, 2024, https://blog.talosintelligence.com/emerging-interlock-ransomware/.

² Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar,” Sekoia (blog), Sekoia, last modified April 16, 2025, https://blog.sekoia.io/interlock-ransomware-evolving-under-the-radar/.

³ Yashvi Shah and Vignesh Dhatchanamoorthy, “ClickFix Deception: A Social Engineering Tactic to Deploy Malware,” McAfee Labs (blog), McAfee,last modified June 11, 2024, https://www.mcafee.com/blogs/other-blogs/mcafee-labs/clickfix-deception-a-social-engineering-tactic-to-deploy-malware/ and “HC3 Sector Alert: ClickFix Attacks,” Health Sector Cybersecurity Coordination Center, Department of Health and Human Services, last modified October 29, 2024, https://www.hhs.gov/sites/default/files/clickfix-attacks-sector-alert-tlpclear.pdf.

⁴ Shah, “ClickFix Deception: A Social Engineering Tactic to Deploy Malware.”

⁵ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

⁶ Bill Toulas, “Interlock Ransomware Gang Deploys New NodeSnake RAT on Universities,“ Bleeping Computer, May 28, 2025, https://www.bleepingcomputer.com/news/security/interlock-ransomware-gang-deploys-new-nodesnake-rat-on-universities/.

⁷ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

⁸ International law-enforcement and Microsoft took down the Lumma Stealer malware in May 2025 by seizing internet domains the actors used to distribute the malware to actors and taking down domains that hosted the malware’s infrastructure. For more information, see Tara Seals, “Lumma Stealer Takedown Reveals Sprawling Operation,” Dark Reading, May 21, 2025, https://www.darkreading.com/cybersecurity-operations/lumma-stealer-takedown-sprawling-operation, and Steven Masada, “Disrupting Lumma Stealer: Microsoft Leads Global Action Against Favored Cybercrime Tool,” Microsoft On the Issues (blog), Microsoft, last modified May 21, 2025, https://blogs.microsoft.com/on-the-issues/2025/05/21/microsoft-leads-global-action-against-favored-cybercrime-tool/.

⁹ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

¹⁰ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹¹ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹² Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹³ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹⁴ Lawrence Abrams, “Meet Interlock — The New Ransomware Targeting FreeBSD Servers,” Bleeping Computer, November 3, 2024, https://www.bleepingcomputer.com/news/security/meet-interlock-the-new-ransomware-targeting-freebsd-servers/.

¹⁵ Biasiotto, “Unwrapping the Emerging Interlock Ransomware Attack.”

¹⁶ Graham Cluley, “Interlock Ransomware: What You Need to Know,” Fortra (blog), Fortra, last modified May 30, 2025, https://www.tripwire.com/state-of-security/interlock-ransomware-what-you-need-know.

¹⁷ Sekoia Threat Detection and Research team, “Interlock Ransomware Evolving Under the Radar.”

News In Brief – Source: US Computer Emergency Readiness Team

CISA released nine Industrial Control Systems (ICS) advisories on July 22, 2025. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.

CISA encourages users and administrators to review newly released ICS advisories for technical details and mitigations.

News In Brief – Source: US Computer Emergency Readiness Team

CISA is aware of active exploitation of a new remote code execution (RCE) vulnerability enabling unauthorized access to on-premise SharePoint servers. While the scope and impact continue to be assessed, the new Common Vulnerabilities and Exposures (CVE), CVE-2025-53770, is a variant of the existing vulnerability CVE-2025-49706 and poses a risk to organizations. This exploitation activity, publicly reported as “ToolShell,” provides unauthenticated access to systems and enables malicious actors to fully access SharePoint content, including file systems and internal configurations, and execute code over the network. 

CISA recommends the following actions to reduce the risks associated with the RCE compromise: 

• For information on detection, prevention, and advanced threat hunting measures, see Microsoft’s Customer Guidance for SharePoint Vulnerability and advisory for CVE-2025-49706. Organizations are encouraged to review all articles and security updates published by Microsoft on July 8, 2025, relevant to the SharePoint platform deployed in their environment.
• Monitor for POSTs to /_layouts/15/ToolPane.aspx?DisplayMode=Edit
• Conduct scanning for IPs 107.191.58[.]76, 104.238.159[.]149, and 96.9.125[.]147, particularly between July 18-19, 2025.
• Update intrusion prevention system and web-application firewall rules to block exploit patterns and anomalous behavior. For more information, see CISA’s Guidance on SIEM and SOAR Implementation.
• Implement comprehensive logging to identify exploitation activity. For more information, see CISA’s Best Practices for Event Logging and Threat Detection.
• Audit and minimize layout and admin privileges.

For more information on this vulnerability, please see Eye Security’s reporting and Palo Alto Unit42’s post.

Note: This Alert may be updated to reflect new guidance issued by CISA or other parties.

Organizations should report incidents and anomalous activity to CISA’s 24/7 Operations Center at Report@cisa.gov or (888) 282-0870.  

Disclaimer:  

The information in this report is being provided “as is” for informational purposes only. CISA does not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA. 

News In Brief – Source: US Computer Emergency Readiness Team

CISA released thirteen Industrial Control Systems (ICS) advisories on July 10, 2025. These advisories provide timely information about current security issues, vulnerabilities, and exploits surrounding ICS.

CISA encourages users and administrators to review newly released ICS advisories for technical details and mitigations.

News In Brief – Source: US Computer Emergency Readiness Team

Iranian state-sponsored or affiliated threat actors are known to conduct a range of targeted cyber activity to include exploit known vulnerabilities in unpatched or outdated software, compromise internet-connected accounts and devices that use default or weak passwords and work with ransomware affiliates to encrypt, steal and leak sensitive information.

At this time, we have not seen indications of a coordinated campaign of malicious cyber activity in the U.S. that can be attributed to Iran. However, we are urging critical infrastructure organizations to stay vigilant to Iranian-affiliated cyber actors that may target U.S. devices and networks. We strongly urge organizations to review our joint fact sheet and implement recommended actions to strengthen our collective defense against this potential cyber activity.

 The Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), Department of Defense Cyber Crime Center (DC3) and the National Security Agency (NSA) are actively monitoring and coordinating with government, industry, and international partners to identify and share actionable intelligence and provide resources and assistance. We also strongly urge organizations report suspicious or criminal activity related to potential Iranian cyber activity.

News In Brief – Source: US Computer Emergency Readiness Team

Today, CISA, in collaboration with the Federal Bureau of Investigation (FBI), the Department of Defense Cyber Crime Center (DC3), and the National Security Agency (NSA), released a Fact Sheet urging organizations to remain vigilant against potential targeted cyber operations by Iranian state-sponsored or affiliated threat actors. 

Over the past several months, there has been increasing activity from hacktivists and Iranian government-affiliated actors, which is expected to escalate due to recent events. These cyber actors often exploit targets of opportunity based on the use of unpatched or outdated software with known Common Vulnerabilities and Exposures or the use of default or common passwords on internet-connected accounts and devices.

At this time, we have not seen indications of a coordinated campaign of malicious cyber activity in the U.S. that can be attributed to Iran. However, CISA, FBI, DC3, and NSA strongly urge critical infrastructure asset owners and operators to implement the mitigations recommended in the joint Fact Sheet, which include: 

• Identifying and disconnecting operational technology and industrial control systems devices from the public internet,
• Protecting devices and accounts with strong, unique passwords,
• Applying the latest software patches, and
• Implementing phishing-resistant multifactor authentication for access to OT networks.

Review the joint Fact Sheet: Iranian Cyber Actors May Target Vulnerable US Networks and Entities of Interest and act now to understand the Iranian state-backed cyber threat, assess and mitigate cybersecurity weaknesses, and review and update incident response plans to strengthen your network against malicious cyber actors. 

News In Brief – Source: US Computer Emergency Readiness Team

CISA, the Federal Bureau of Investigation (FBI), and the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) have issued an updated advisory on Play ransomware, also known as Playcrypt. This advisory highlights new tactics, techniques, and procedures used by the Play ransomware group and provides updated indicators of compromise (IOCs) to enhance threat detection.

Since June 2022, Playcrypt has targeted diverse businesses and critical infrastructure across North America, South America, and Europe, becoming one of the most active ransomware groups in 2024. The FBI has identified approximately 900 entities allegedly exploited by these ransomware actors as of May 2025.

Recommended mitigations include:

• Implementing multifactor authentication;
• Maintaining offline data backups;
• Developing and testing a recovery plan; and
• Keeping all operating systems, software, and firmware updated.

Stay vigilant and take proactive measures to protect your organization. 

News In Brief – Source: US Computer Emergency Readiness Team

Today, CISA, in collaboration with the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) and other international and U.S. partners, released new guidance for organizations seeking to procure Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platforms.

This guidance includes the following three resources:

• Implementing SIEM and SOAR Platforms – Executive Guidance outlines how executives can enhance their organization’s cybersecurity framework by implementing these technologies to improve visibility into network activities, enabling swift detection and response to cyber threats.
• Implementing SIEM and SOAR Platforms – Practitioner Guidance focuses on how practitioners can quickly identify and respond to potential cybersecurity threats and leverage these technologies to streamline incident response processes by automating predefined actions based on detected anomalies.
• Priority Logs for SIEM Ingestion – Practitioner Guidance offers insights for prioritizing log ingestion into a SIEM, ensuring that critical data sources are effectively collected and analyzed to enhance threat detection and incident response capabilities tailored for organizations.

CISA encourages organizations to review this guidance and implement the recommended best practices to strengthen their cybersecurity. For access to the guidance documents, please visit CISA’s SIEM and SOAR Resource page.

News In Brief – Source: US Computer Emergency Readiness Team

Executive summary

This Cybersecurity Information Sheet (CSI) provides essential guidance on securing data used in artificial intelligence (AI) and machine learning (ML) systems. It also highlights the importance of data security in ensuring the accuracy and integrity of AI outcomes and outlines potential risks arising from data integrity issues in various stages of AI development and deployment.

This CSI provides a brief overview of the AI system lifecycle and general best practices to secure data used during the development, testing, and operation of AI-based systems. These best practices include the incorporation of techniques such as data encryption, digital signatures, data provenance tracking, secure storage, and trust infrastructure. This CSI also provides an in-depth examination of three significant areas of data security risks in AI systems: data supply chain, maliciously modified (“poisoned”) data, and data drift. Each section provides a detailed description of the risks and the corresponding best practices to mitigate those risks. 

This guidance is intended primarily for organizations using AI systems in their operations, with a focus on protecting sensitive, proprietary, or mission critical data. The principles outlined in this information sheet provide a robust foundation for securing AI data and ensuring the reliability and accuracy of AI-driven outcomes.

This document was authored by the National Security Agency’s Artificial Intelligence Security Center (AISC), the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the New Zealand’s Government Communications Security Bureau’s National Cyber Security Centre (NCSC-NZ), and the United Kingdom’s National Cyber Security Centre (NCSC-UK). 

The goals of this guidance are to: 

1. Raise awareness of the potential risks related to data security in the development, testing, and deployment of AI systems;
2. Provide guidance and best practices for securing AI data across various stages of the AI lifecycle, with an in-depth description of the three aforementioned significant areas of data security risks; and
3. Establish a strong foundation for data security in AI systems by promoting the adoption of robust data security measures and encouraging proactive risk mitigation strategies.

The data resources used during the development, testing, and operation of an AI¹ system are a critical component of the AI supply chain; therefore, the data resources must be protected and secured. In its Data Management Lexicon, [1] the Intelligence Community (IC) defines Data Security as “The ability to protect data resources from unauthorized discovery, access, use, modification, and/or destruction…. Data Security is a component of Data Protection.” 

Data security is paramount in the development and deployment of AI systems. Therefore, it is a key component of strategies developed to safeguard and manage the overall security of AI-based systems. Successful data management strategies must ensure that the data has not been tampered with at any point throughout the entire AI system lifecycle; is free from malicious, unwanted, and unauthorized content; and does not have unintentional duplicative or anomalous information. Note that AI data security depends on robust, fundamental cybersecurity protection for all datasets used in designing, developing, deploying, operating, and maintaining AI systems and the ML models that enable them.

Audience and scope

This CSI outlines potential risks in AI systems stemming from data security issues that arise during different phases of an AI deployment, and it introduces recommended protocols to mitigate these risks. This guidance builds upon the NSA’s joint guidance on Deploying AI Systems Securely [2] and delves deeper into securing the data used to train and operate AI-based systems. This guidance is primarily developed for organizations that use AI systems in their day-to-day operations, including the Defense Industrial Base (DIB), National Security System (NSS) owners, Federal Civilian Executive Branch (FCEB) agencies, and critical infrastructure owners and operators. Implementing these mitigations can help secure AI-enabled systems and protect proprietary, sensitive, and/or mission critical data.

Securing data throughout the AI system lifecycle

Data security is a critical enabler that spans all phases of the AI system lifecycle. ML models learn their decision logic from data, so an attacker who can manipulate the data can also manipulate the logic of an AI-based system. In the AI Risk Management Framework (RMF) [3], the National Institute of Standards and Technology (NIST) defines six major stages in the lifecycle of AI systems, starting from Plan & Design and progressing all the way to Operate & Monitor. The following table highlights relevant data security factors for each stage of the AI lifecycle: 

Table 1: The AI System Lifecycle with key dimensions, necessary ongoing assessments, focus areas for data security, and particular data security risks covered in this CSI. [3] 

AI Lifecycle Stage	Key Dimensions	Test, Evaluation, Verification, & Validation (TEVV)	Potential Focus Areas for Data Security	Particular Data Security Risks Covered in this CSI
1) Plan & Design	Application Context	Audit & Impact Assessment	Incorporating data security measures from inception, designing robust security protocols, threat modeling, and including privacy by design	Data supply chain
2) Collect & Process Data	Data & Input	Internal & External Validation	Ensuring data integrity, authenticity, encryption, access controls, data minimization, anonymization, and secure data transfer	Data supply chain, maliciously modified data
3) Build & Use Model	AI Model	Model Testing	Protecting data from tampering, ensuring data quality and privacy (including differential privacy and secure multi-party computation when appropriate and possible), securing model training, and operating environments	Data supply chain, maliciously modified data
4) Verify & Validate	AI Model	Model Testing	Performing comprehensive security testing, identifying and mitigating risks, validating data integrity, adversarial testing, and formal verification when appropriate and possible	Data supply chain, maliciously modified data
5) Deploy & Use	Task & Output	Integration, Compliance Testing, Validation	Implementing strict access controls, zero-trust infrastructure, secure data transmission and storage, secure API endpoints, and monitoring for anomalous behavior	Data supply chain, maliciously modified data, data drift
6) Operate & Monitor	Application Context	Audit & Impact Assessment	Conducting continuous risk assessments, monitoring for data breaches, deleting data securely, complying with regulations, incident response planning, and regular security auditing	Data supply chain, maliciously modified data, data drift

Throughout the AI system lifecycle, securing data is paramount to maintaining information integrity and system reliability. Starting with the initial Plan & Design phase, carefully plan data protection measures to provide proactive mitigations of potential risks. In the Collect & Process Data phase, data must be carefully analyzed, labeled, sanitized, and protected from breaches and tampering. Securing data in the Build & Use Model phase helps ensure models are trained on reliably sourced, accurate, and representative information. In the Verify & Validate phase, comprehensive and thorough testing of AI models, derived from training data, can identify security flaws and enable their mitigation. 

Note that Verification & Validation is necessary each time new data or user feedback is introduced into the model; therefore, that data also needs to be handled with the same security standards as AI training data. Implementing strict access controls protects data from unauthorized access, especially in the Deploy & Use phase. Lastly, continuous data risk assessments in the Operate & Monitor phase are necessary to adapt to evolving threats. Neglecting these practices can lead to data corruption, compromised models, data leaks, and non-compliance, emphasizing the critical importance of robust data security at every phase.

Best practices to secure data for AI-based systems

The following list contains recommended practical steps that system owners can take to better protect the data used to build and operate their AI-based systems, whether running on premises or in the cloud. For more details on general cybersecurity best practices, see also NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations.” [33]

1. Source reliable data and track data provenance
Verify data sources use trusted, reliable, and accurate data for training and operating AI systems. To the extent possible, only use data from authoritative sources. Implement provenance tracking to enable the tracing of data origins, and log the path that data follows through an AI system. [7],[8],[9] Incorporate a secure provenance database that is cryptographically signed and maintains an immutable, append-only ledger of data changes. This facilitates data provenance tracking, helps identify sources of maliciously modified data, and helps ensure that no single entity can undetectably manipulate the data.
2. Verify and maintain data integrity during storage and transport
Maintaining data integrity² is an essential component to preserve the accuracy, reliability, and trustworthiness of AI data. [4] Use checksums and cryptographic hashes to verify that data has not been altered or tampered with during storage or transmission. Generating such unique codes for AI datasets enables the detection of unauthorized changes or corruption, safeguarding the information’s authenticity.

3. Employ digital signatures to authenticate trusted data revisions
Digital signatures help ensure data integrity and prevent tampering by third parties. Adopt quantum-resistant digital signature standards [5][6] to authenticate and verify datasets used during AI model training, fine tuning, alignment, reinforcement learning from human feedback (RLHF), and/or other post-training processes that affect model parameters. Original versions of the data should be cryptographically signed, and any subsequent data revisions should be signed by the person who made the change. Organizations are encouraged to use trusted certificate authorities to verify this process.
4. Leverage trusted infrastructure
Use a trusted computing environment that leverages Zero Trust architecture. [10] Provide secure enclaves for data processing and keep sensitive information protected and unaltered during computations. This approach fosters a secure foundation for data privacy and security in AI data workflows by isolating sensitive operations and mitigating risks of tampering. Trusted computing infrastructure supports the integrity of data processes, reduces risks associated with unverified or altered data, and ultimately creates a more robust and transparent AI ecosystem. Trusted environments are essential for AI applications where data accuracy directly impacts their decision-making processes.
5. Classify data and use access controls
Categorize data using a classification system based on sensitivity and required protection measures. [11] This process enables organizations to apply appropriate security controls to different data types. Classifying data enables the enforcement of robust protection measures like stringent encryption and access controls. [33] In general, the output of AI systems should be classified at the same level as the input data (rather than creating a separate set of guardrails).
6. Encrypt data
Adopt advanced encryption protocols proportional to the organizational data protection level. This includes securing data at rest, in transit, and during processing. AES-256 encryption is the de facto industry standard and is considered resistant to quantum computing threats. [12],[13] Use protocols, such as TLS with AES-256 or post-quantum encryption, for data in transit. Refer to NIST SP 800-52r2, “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations” [14] for more details.
7. Store data securely
Store data in certified storage devices that enforce NIST FIPS 140-3 [15] compliance, ensuring that the cryptographic modules used to encrypt the data provide high-level security against advanced intrusion attempts. Note that Security Level 3 (defined in NIST FIPS 140-2 [16]) provides robust data protection; however, evaluate and determine the appropriate level of security based on organizational needs and risk assessments.
8. Leverage privacy-preserving techniques 
There are several privacy-preserving techniques [17] that can be leveraged for increased data security. Note that there may be practical limitations to their implementation due to computational cost.

• Data depersonalization techniques (e.g., data masking [18]) involve replacing sensitive data with inauthentic but realistic information that maintains the distributions of values throughout the dataset. This enables AI systems to utilize datasets without exposing sensitive information, reducing the impact of data breaches and supporting secure data sharing and collaboration. When possible, use data masking to facilitate AI model training and development without compromising sensitive information (e.g., personally identifiable information [PII]).
• Differential privacy is a framework that provides a mathematical guarantee quantifying the level of privacy of a dataset or query. It requires a pre-specified privacy budget for the level of noise added to the data, but there are tradeoffs between protecting the training data from membership inference techniques and target task accuracy. Refer to [17] for further details.
• Decentralized learning techniques (e.g., federated learning [19]) permit AI system training over multiple local datasets with limited sharing of data among local instances. An aggregator model incorporates the results of the distributed models, limiting access on the local instance to the larger training dataset. Secure multi-party computation is recommended for training and inferencing processes.

9. Delete data securely
Prior to repurposing or decommissioning any functional drives used for AI data storage and processing, erase them using a secure deletion method such as cryptographic erase, block erase, or data overwrite. Refer to NIST SP 800-88, “Guidelines for Media Sanitization,” [20] for guidance on appropriate deletion methods.
10. Conduct ongoing data security risk assessments
Conduct ongoing risk assessments using industry-standard frameworks, such as the NIST SP 800-3r2, Risk Management Framework (RMF) [4][21], and the NIST AI 100-1, Artificial Intelligence RMF [3]. These assessments should evaluate the AI data security landscape, identify risks, and prioritize actions to minimize security incidents. Continuously improve data security measures to keep pace with evolving threats and vulnerabilities, learn from security incidents, stay up to date with emerging technologies, and maintain a robust security posture. 

Data supply chain – risks and mitigations

Relevant AI Lifecycle stages: 1) Plan & Design; 2) Collect & Process Data; 3) Build & Use Model; 4) Verify & Validate; 5) Deploy & Use; 6) Operate & Monitor

Developing and deploying secure and reliable AI systems requires understanding potential risks and methods of introducing inaccurate or maliciously modified (a.k.a. “poisoned”) data into the system. In short, the security of AI systems depends on thorough verification of training data and proactive measures to detect and prevent the introduction of inaccurate material.

Threats can stem from large-scale data collected and curated by third parties, as well as from data that is not sufficiently protected after ingestion. Data collected and/or curated by a third party may contain inaccurate information, either unintentionally or through malicious intent. Inaccurate material can compromise not only models trained using that data, but also any additional models that rely on compromised models as a foundation.  

It is crucial, therefore, to verify the integrity of the training data used when building an AI system. Organizations that utilize third-party data must take appropriate measures to ensure that: 1) the data is not compromised upon ingestion; and 2) the data cannot be compromised after it has been incorporated into the AI system. As such, both data curators and data consumers should follow the best practices for digital signatures, data integrity, and data provenance that are described in detail above.

General risks for data consumers³  

The use of web-scale databases includes all of the risks outlined earlier, and one cannot simply assume that these datasets are clean, accurate, and free of malicious content. Third-party models trained on web-scraped data used to train a model for downstream tasks could also affect the model’s learning process and result in behavior that was unintended by the AI system designer.

From the moment data is ingested for use with AI systems, the data acquirer must secure it against insider threats and malicious network activity to prevent unauthorized modification. 

Mitigation strategies: 

• Dataset verification: Before ingest, the consumer or curator should verify, as much as possible, that the dataset to be ingested is free of malicious or inaccurate material. Any detected abnormalities should be addressed, and suspicious data should not be stored. The dataset verification process should include a digital signature of the dataset at time of ingestion.
• Content credentials: Use content credentials to track the provenance of media and other data. Content credentials are “metadata that are secured cryptographically and allow creators the ability to add information about themselves or their creative process, or both, directly to media content…. Content Credentials securely bind essential metadata to a media file that can track its origin(s), any edits made, and/or what was used to create or modify the content…. This metadata alone does not allow a consumer to determine whether a piece of content is ‘true,’ but rather provides contextual information that assists in determining the authenticity of the content.” [24]
• Foundation model assurances: In the case where a consumer is not ingesting a dataset but a foundation model trained by another party, the developers of the foundation model need to be able to provide assurances regarding the data and sources used and certify that their training data did not contain any known compromised data. Take care to track the training data used in various model lineages. Exercise caution before using a model without such assurances.
• Require certification: Data consumers should strongly consider requiring a formal certification from dataset and model providers, attesting that their systems are free from known compromised data before using third-party data and/or foundation models.
• Secure storage: After ingest, data needs to be stored in a database that adheres to the best practices for digital signatures, data integrity, and data provenance that are described in detail above. Note that an append-only cryptographically signed database should be used where feasible, but there may be a need to delete older material that is no longer relevant. Each time a data element is updated (e.g., resized, cropped, flipped, etc.) for augmentation purposes in a non-temporary fashion, then the updated data should be stored as a new entry with documented changes. The database’s certificate should be verified at the time the database is accessed for a training run. If the database does not pass the certificate check, abort the training and conduct a comprehensive database audit to discover any data modifications. 

2023 investigations by various industry professionals explored low-resource methods for introducing malicious or inaccurate material into web-scale datasets, and potential strategies to mitigate this risk.  [29] These vulnerabilities depend on the fact that curators or collectors do not have control over the data, as seen in cases of datasets curated by third parties (e.g., LAION) or datasets that are continually updated and released (e.g., Wikipedia). 

Risk: Curated web-scale datasets

Curated AI datasets (e.g., LAION-2B or COYO-700M) are vulnerable to a type of technique known as split-view poisoning. This risk arises because these datasets often contain data hosted on domains that may have expired or are no longer actively maintained by their original owners. In such cases, anyone who purchases these expired domains gains control over the content hosted on them. This situation creates an opportunity for malicious actors to modify or replace the data that the curated list points to, potentially introducing inaccurate or misleading information into the dataset. In many instances, it is possible to purchase enough control of a dataset to conduct effective poisoning for roughly $1,000 USD. In some cases, effective techniques can cost as little as $60 USD (e.g., COYO-700M), making this a viable threat from low-resource threat actors. 

Mitigation strategies:

• Raw data hashes: Data curators should attach a cryptographic hash to all raw data referenced in the dataset. This will enable follow-on data consumers to verify that the data has not changed since it was added to the list.
• Hash verification: Data consumers should incorporate a hash check at time of download in order to detect any changes made to it, and the downloader should discard any data that does not pass the hash check.
• Periodic checks: Curators should periodically scrape the data themselves to verify that the data has not been modified. If any changes are detected, the curator should take appropriate steps to ensure the data’s integrity.
• Verifying data: Curators should verify that any changed data is clean and free from inaccurate or malicious material. If the content of the data has been altered in any way, the curator should either remove it from their list or flag it for further review.
• Certification by curators: Since the data supply chain begins with the curators, the certification process must start there as well. To the best of their ability, curators should be able to certify that, at the time of publication, the dataset contains no malicious or inaccurate material. 

Risk: Collected web-scale datasets

Collected web-scale datasets (e.g., Wikipedia) are vulnerable to frontrunning poisoning techniques. Frontrunning poisoning occurs when an actor injects malicious examples in a short time window before websites with crowd-sourced content collect a snapshot of their data. Wikipedia in particular conducts twice-monthly snapshots of their data and publishes these snapshots for people to download. Since the snapshots happen at known times, it is possible for malicious actors to edit pages close enough to the snapshot time so that malicious edits will be captured and published before they can be discovered and corrected. Industry analysis demonstrated potential malicious actors would be able to successfully poison as much as 6.5% of Wikipedia. [29]

Mitigation strategies:

• Test & verify web-scale datasets: Be cautious when using web-scale datasets that are vulnerable to frontrunning poisoning. Check that the data hasn’t been manipulated, and only use snapshots verified by a trusted party.
• (For web-scale data collectors) Randomize or lengthen snapshots: Collectors such as Wikipedia should defend against actors making malicious edits ahead of a planned snapshot by:

1. Randomizing the snapshot order.

2. Freezing edits to content long enough for edits to go through review before releasing the snapshot.

   These mitigations focus on increasing the amount of time a malicious actor must maintain control of the data for it to be included in the published snapshot. Any reasonable methods that increase the time a malicious actor must control the data are also recommended. 

   Note that these mitigations are limited since they rely on trusted curators who can detect malicious edits. It is more difficult to defend against subtle edits (e.g., attempts to insert hidden watermarks) that appear valid to human reviewers but impact machine understanding.

Risk: Web-crawled datasets 

Web-crawled datasets present a unique intersection of the risks discussed above. Since web-crawled datasets are substantially less curated than other web-scale datasets, they bring increased risk. There are no trusted curators to detect malicious edits. There are no original curated views to which cryptographic hashes can be attached. The unfortunate reality is that “updates to a web page have no realistic bound on the delta between versions which might act as a signal for attaching trust.” [29]

Mitigation strategies:

• Consensus approaches: Data consumers using web-crawled datasets should rely on consensus-based approaches, since notional determinations of which domains to trust are ad-hoc and insufficient. For example, an AI developer could choose to only trust an image-caption pair when it appears on many different websites to reduce susceptibility to poisoning techniques, since a malicious actor would have to poison a sufficiently large number of websites to be successful.
• Data curation: Ultimately, it is incumbent on organizations to ensure malicious or inaccurate material is not present in the data they use. If an organization does not have resources to conduct the necessary due diligence, then the use of web-crawled datasets is not recommended until some sort of trust infrastructure can be implemented.

Final note on web-scale datasets and data poisoning

Both split-view and frontrunning poisoning are reasonably straightforward for a malicious actor to execute, since they do not require particularly sophisticated methodology. These poisoning techniques should be considered viable threats by anyone looking to incorporate web-scale data into their AI systems. The danger here comes not only from directly using compromised data, but also from using models which may themselves have been trained on compromised data. 

Ultimately, data poisoning must be addressed from a supply chain perspective by those who train and fine-tune AI models. Proper supply chain integrity and security management (i.e., selecting reliable model providers and verifying the legitimacy of the models used) can reduce the risk of data poisoning and system compromise. The most reliable providers are those who assure that they do everything possible to prevent the influence and distribution of poisoned data and models. [34] 

Every effort must be made by those building foundation models to filter out malicious and inaccurate data. Foundation models are evolving rapidly, and filtering out inaccurate, unauthorized, and malicious training data is an active area of research, particularly at web-scale. As such, is currently impractical to prescribe precise methods for doing so; it is a best-effort endeavor. Ideally, data curators and foundation model providers should be able to attest to their filtering methods and provide evidence (e.g. test results) of their effectiveness. Likewise, if possible, downstream model consumers should include a review of the security claims as part of their security processes before accepting a foundation model for use. 

Maliciously modified data – risks and mitigations

Relevant AI Lifecycle stages: 2) Collect & Process Data; 3) Build & Use Model; 4) Verify & Validate; 5) Deploy & Use; 6) Operate & Monitor

Maliciously modified data presents a significant threat to the accuracy and integrity of AI systems. Deliberate manipulation of data can result in inaccurate outcomes, poor decisions, and compromised security. Note that there are also risks associated with unintentional data errors and duplications that can affect the security and performance of AI systems. Challenges like adversarial machine learning threats, statistical bias, and inaccurate information can impact the overall security of AI-driven outcomes.

Risk: Adversarial Machine Learning threats

Adversarial Machine Learning (AML) threats involve intentional, malicious attempts to deceive, manipulate, or disrupt AI systems. [7],[17],[22] Malicious actors employ data poisoning to corrupt the learning process, compromising the integrity of training datasets and leading to unreliable or malicious model behavior. Additionally, malicious actors may introduce adversarial examples into datasets that, while subtle, can evade correct classification, thereby undermining the model’s performance. Furthermore, sensitive information in training datasets can be indirectly extracted through techniques like model inversion⁴, posing significant data security risks.

Mitigation Strategies:

• Anomaly detection: Incorporate anomaly detection algorithms during data pre-processing to identify and remove malicious or suspicious data points before training. These algorithms can recognize statistically deviant patterns in the data, making it possible to isolate and eliminate poisoned inputs.
• Data sanitization: Sanitize the training data by applying techniques like data filtering, sampling, and normalization. This helps reduce the impact of outliers, noisy data, and other potentially poisoned inputs, ensuring that models learn from high-quality, representative datasets. Perform sanitization on a regular basis, especially prior to each and every training, fine-tuning, or any other process that adjusts model parameters.
• Secure training pipelines: Secure data collection, pre-processing, and training pipelines to prevent malicious actors from tampering with datasets or model parameters.
• Ensemble methods / collaborative learning: Implement collaborative learning frameworks that combine an ensemble of multiple, distinct AI models to reach a consensus on output predictions. This approach can help counteract the impact of data poisoning, since malicious inputs may only affect a subset of the collaborative models, allowing the majority to maintain accuracy and reliability.
• Data anonymization: Implement anonymization techniques to protect sensitive data attributes, keeping them confidential while allowing AI models to learn patterns and generate accurate predictions.

Risk: Bad data statements

Bad data statements⁵ [7][23], such as missing metadata, can significantly influence AI data security by introducing data integrity issues that can lead to faulty model performance. Error-free metadata provides valuable contextual information about the data, including its structure, purpose, and collection methods. When metadata is missing, it becomes difficult to interpret data accurately and draw meaningful conclusions. This situation can result in incomplete or inaccurate data representation, compromising AI system performance and reliability. If metadata is modified by a malicious actor, then the security of the AI system is also at risk.

Mitigation strategies:

• Metadata management: Implement strong data governance practices to help ensure metadata is well-documented, complete, accurate, and secured.
• Metadata validation: Establish data validation processes to check the completeness and consistency of metadata before data is used for AI training.
• Data enrichment: Use available resources, such as reference data and trusted third-party data, to supplement missing metadata and improve the overall quality of the training data.

Risk: Statistical bias⁶ 

Robust data security and collection practices are key to mitigating statistical bias. Executive Order (EO) 14179 mandates that U.S. government entities “develop AI systems that are free from ideological bias or engineered social agendas.” [25] Note that “an AI system is said to be biased when it exhibits systematically inaccurate behavior.” [26] Statistical bias in AI systems can arise from artifacts present in training data that can lead to artificially slanted or inaccurate outcomes. Sampling biases or biases in data collection can affect the overall outcomes and performance of AI. Left unaddressed, statistical bias can degrade the accuracy and effectiveness of AI systems. 

Mitigation strategies:

• Regular training data audits: Regularly audit training data to detect, assess, and address potential issues that can result in systematically inaccurate AI systems.
• Representative training data: Ensure that training data is representative of the totality of the information relevant to any given topic to reduce the risk of statistical bias. Also ensure that AI data is properly divided into training, development, and evaluation sets without overlap to properly measure statistical bias and other measures of performance.
• Edge cases: Identify and mitigate edge cases that can cause models to malfunction.
• Test and correct for statistical bias: Create a repository with instances of observed model output bias. Leverage that information to improve training data audits and with reinforcement learning to “undo” some of the measured bias.

Risk: Data poisoning via inaccurate information

One form of data poisoning (sometimes referred to as “disinformation” [27]) involves the intentional insertion of inaccurate or misleading information in AI training datasets, which can negatively impact AI system performance, outcomes, and decision-making processes. 

Mitigation strategies:

• Remove inaccurate information from training data: Identify and remove inaccurate or misleading information from AI datasets to the extent feasible.
• Data provenance and verification: Implement provenance verification mechanisms during data collection to help ensure that only accurate and reliable data is used. This process can include methods such as cross-verification, fact-checking, source analysis, data provenance tracking, and content credentials.
• Add more training data: Increasing the amount of non-malicious data makes training more robust against poisoned examples—provided that these poisoned examples are small in number. One way to do this is through data augmentation—the creation of artificial training set samples that are small variations of existing samples. The goal is to “outnumber” the poisoned samples so the model “forgets” them. Note that this mitigation can only be applied during training, and therefore does not apply to an already trained model. [28]
• Data quality control: Perform quality control on data including detecting poisoned samples through integrity checks, statistical deviation, or pattern recognition. Proactively implement data quality controls during the training phase to prevent issues before they arise in production.

Risk: Data duplications

Unintended duplicate data elements [7] in training datasets can skew model performance and cause overfitting, reducing the AI model’s ability to generalize across a variety of real-world applications. Duplicates are not always exact; near-duplicates may contain minor differences like formatting, abbreviations, or errors, which makes detecting them more complex. Duplicate data often leads to inaccurate predictions, making the AI system less effective in real-world applications.

Mitigation strategies:

• Data deduplication: Implement deduplication techniques (such as fuzzy matching, hashing, clustering, etc.) to carefully identify and handle duplicates and near-duplicates in the data.

Data drift – risks and mitigations

Relevant AI Lifecycle stages: 5) Deploy & Use; 6) Operate & Monitor

Data drift, or distribution shift, refers to changes in the underlying statistical properties of the input data to an operational AI system. Over time, the input data can become significantly different from the data originally used to train the model. [7],[8] Degradation caused by data drift is a natural and expected occurrence, and AI system developers and operators need to regularly update models to maintain accuracy and performance. Data drift ordinarily begins as small, seemingly insignificant degradations in model performance. Left unchecked, the degradation caused by data drift can snowball into substantial reductions in AI system accuracy and integrity that become increasingly difficult to correct. 

It is crucial to distinguish between data drift and data poisoning attacks designed to affect an AI model. Continuous monitoring of system accuracy and performance provides important indicators based on the nature of the changes observed. If the changes are slow and gradual over time, it is more likely that the model is experiencing data drift. If the changes are abrupt and dramatic in one or more dimensions, it is more likely that an actor is trying to compromise the model. Cyber compromises often aim to manipulate the model’s performance quickly and significantly, leading to abrupt changes in the input data or model outputs.

AI system operators and developers should employ a wide range of techniques for detecting and mitigating data drift, including data preprocessing, increasing dataset coverage of real-world scenarios, and adopting robust training and adaptation strategies. [30] Packages that automate dataset loading assist AI system developers in creating application-specific detection and mitigation techniques for data drift.

There are many potential causes of data drift, including: 

1. A change in the upstream data pipeline not represented in the model training data (e.g., the units of a particular data element change from miles to kilometers)
2. The introduction of completely new data elements that the model had not previously seen (e.g., a new type of malware not recognized in the ML layer of an anti-virus product)
3. A change in the context of how inputs and outputs are related (e.g., a change in organizational structure due to a merger or acquisition could lead to new data access patterns that might be misinterpreted as security threats by an AI system)

The data associated with a given AI model should be regularly checked for any updates to help ensure the model still predicts as expected. [7],[8],[9] The interval for this update and check will depend on the particular AI system and application. For example, in high-stakes applications such as healthcare, early detection and mitigation of data drift are critical prior to patient impact. Thus, continuous monitoring of model performance with additional direct analysis of the input data is important in such applications. [30] 

Mitigation strategies:

• Data management: Employ a data management strategy in keeping with the best practices in this CSI to help ensure that it is easy to add and track new data elements for model training and adaptation. This management strategy enables identification of data elements causing drift for appropriate mitigation or action.
• Data-quality testing: AI system developers should use data-quality assessment tools to assist in selecting and filtering data used for model training or adaptation. Understanding the current dataset and its impact on model behavior is critical to detecting data drift.
• Input and output monitoring: Monitor the AI system inputs and outputs to verify the model is performing as expected. [9] Regularly update your model using current data. Utilize meaningful statistical methods that measure expected dataset metrics and compare the distribution of the training data to the test data to help determine if data drift is occurring. [7] 

Data management tools and methods are currently an active area of research. However, data drift can be mitigated by incorporating application-specific data management protocols that include: continuous monitoring, retraining (regularly incorporating the latest data into the models), data cleansing (correcting errors or inconsistencies in the data), and using ensemble models (combining predictions of multiple models). Incorporation of a data management framework into the design of AI systems from the beginning is essential for improving the overall integrity and security posture. [31]

Conclusion

Data security is of paramount importance when developing and operating AI systems. As organizations in various sectors rely more and more on AI-driven outcomes, data security becomes crucial for maintaining accuracy, reliability, and integrity. The guidance provided in this CSI outlines a robust approach to securing AI data and addressing the risks associated with the data supply chain, malicious data, and data drift.

Data security is an ever-evolving field, and continuous vigilance and adaptation are key to staying ahead of emerging threats and vulnerabilities. The best practices presented here encourage the highest standards of data security in AI while helping ensure the accuracy and integrity of AI-driven outcomes. By adopting these best practices and risk mitigation strategies, organizations can fortify their AI systems against potential threats and safeguard sensitive, proprietary, and mission critical data used in the development and operation of their AI systems. 

References

1 In this document, Artificial Intelligence (AI) has the meaning set forth in 15 U.S.C. 9401(3): 
“… a machine-based system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments. AI systems use machine- and human-based inputs to:
  (A) Perceive real and virtual environments;
  (B) Take these perceptions and turn them into models through analysis in an automated manner; and
  (C) Use model inference to formulate options for information or action.”

2 Data integrity is defined by the IC Data Management Lexicon [1] as “The degree to which data can be trusted due to its provenance, pedigree, lineage and conformance with all business rules regarding its relationship with other data. In the context of data movement, this is the degree to which data has verifiably not been changed unexpectedly by a person or NPE.”

3 The term data consumers is defined as technical personnel (e.g. data scientists, engineers) who make use of data that they themselves did not produce or annotate to build and/or operate AI systems. 

4 Model inversion refers to the process by which an attacker analyzes the output patterns of an AI system to reverse-engineer and uncover details about the training dataset, such as individual data points or patterns. This process can potentially expose confidential or proprietary information from the data that was used to train the AI models.

5 “A data statement is a characterization of a dataset that provides context to allow developers and users to better understand how experimental results might generalize, how software might be appropriately deployed, and what biases might be reflected in systems built on the software.” [23] 

6 “In technical systems, bias is most commonly understood and treated as a statistical phenomenon. Bias is an effect that deprives a statistical result of representativeness by systematically distorting it, as distinct from random error, which may distort on any one occasion but balances out on the average.” [26],[32] 

Works cited

[1] Office of the Director of National Intelligence. The Intelligence Community Data Management Lexicon. 2024. https://dni.gov/files/ODNI/documents/IC_Data_Management_Lexicon.pdf   
[2] National Security Agency et al. Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems. 2024. https://media.defense.gov/2024/Apr/15/2003439257/-1/-1/0/CSI-DEPLOYING-AI-SYSTEMS-SECURELY.PDF  
[3] National Institute of Standards and Technology (NIST). NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://doi.org/10.6028/NIST.AI.100-1  
[4] NIST. NIST Special Publication 800-37 Rev. 2: Guide for Applying the Risk Management Framework to Federal Information Systems. 2018. https://doi.org/10.6028/NIST.SP.800-37r2  
[5] NIST. Federal Information Processing Standards Publication (FIPS) 204: Module-Lattice-Based Digital Signature Standard. 2024. https://doi.org/10.6028/NIST.FIPS.204  
[6] NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard. 2024. https://doi.org/10.6028/NIST.FIPS.205  
[7] Bommasani, R. et al. On the Opportunities and Risks of Foundation Models. arXiv:2108.07258v3. 2022. https://arxiv.org/abs/2108.07258v3  
[8] Securing Artificial Intelligence (SAI); Data Supply Chain Security. ESTI GR SAI 002 V1.1.1. 2021. https://etsi.org/deliver/etsi_gr/SAI/001_099/002/01.01.01_60/gr_SAI002v010101p.pdf  
[9] National Cyber Security Centre et al. Guidelines for Secure AI System Development. 2023. https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf  
[10] NIST. NIST Special Publication 800-207: Zero Trust Architecture. 2020. https://doi.org/10.6028/NIST.SP.800-207  
[11] NIST. NIST IR 8496 ipd: Data Classification Concepts and Considerations for Improving Data Protection. 2023. https://doi.org/10.6028/NIST.IR.8496.ipd  
[12] Cybersecurity and Infrastructure Security Agency (CISA), NSA, and NIST. Quantum-Readiness: Migration to Post-Quantum Cryptography. 2023. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography 
[13] NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024. https://doi.org/10.6028/NIST.FIPS.203  
[14] NIST. NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. 2019. https://doi.org/10.6028/NIST.SP.800-52r2  
[15] NIST. FIPS 140-3, Security Requirements for Cryptographic Modules. 2019. https://doi.org/10.6028/NIST.FIPS.140-3    
[16] NIST. FIPS 140-2, Security Requirements for Cryptographic Modules. 2001. https://doi.org/10.6028/NIST.FIPS.140-2  
[17] NIST. NIST AI 100-2e2023: Trustworthy and Responsible AI, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. 2024. https://doi.org/10.6028/NIST.AI.100-2e2023  
[18] Adak, M. F., Kose, Z. N., & Akpinar, M. Dynamic Data Masking by Two-Step Encryption. In 2023 Innovations in Intelligent Systems and Applications Conference (ASYU) (pp. 1-5). IEEE. 2023 https://doi.org/10.1109/ASYU58738.2023.10296545    
[19] Kairouz, P. et al. Advances and Open Problems in Federated Learning. Foundations and Trends in Machine Learning 14 (1-2): 1-210. arXiv:1912.04977. 2021. https://arxiv.org/abs/1912.04977  
[20] NIST. NIST SP 800-88 Rev. 1: Guidelines for Media Sanitization. 2014. https://doi.org/10.6028/NIST.SP.800-88r1  
[21] NIST. NIST Special Publication 800-3 Rev. 2: Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. 2018. https://doi.org/10.6028/NIST.SP.800-37r2  
[22] U.S. Department of Homeland Security. Preparedness Series June 2023: Risks and Mitigation Strategies for Adversarial Artificial Intelligence Threats: A DHS S&T Study. 2023. https://www.dhs.gov/sites/default/files/2023-12/23_1222_st_risks_mitigation_strategies.pdf  
[23] Bender, E. M., & Friedman, B. Data Statements for Natural Language Processing: Toward Mitigating System Bias and Enabling Better Science. Transactions of the Association for Computational Linguistics (TACL) 6, 587–604. 2018. https://doi.org/10.1162/tacl_a_00041  
[24] NSA et al. Content Credentials: Strengthening Multimedia Integrity in the Generative AI Era. 2025. https://media.defense.gov/2025/Jan/29/2003634788/-1/-1/0/CSI-CONTENT-CREDENTIALS.PDF  
[25] Executive Order (EO) 14179: “Removing Barriers to American Leadership in Artificial Intelligence” https://www.federalregister.gov/executive-order/14179   
[26] NIST. NIST Special Publication 1270: Framework for Identifying and Managing Bias in Artificial Intelligence. 2023. https://doi.org/10.6028/NIST.SP.1270  
[27] NIST. NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. 2023. https://doi.org/10.6028/NIST.AI.600-1  
[28] Open Web Application Security Project (OWASP). AI Exchange. #Moretraindata. https://owaspai.org/goto/moretraindata/  
[29] Carlini, N. et al. Poisoning Web-Scale Training Datasets is Practical. arXiv:2302.10149. 2023. https://arxiv.org/abs/2302.10149  
[30] Kore, A., Abbasi Bavil, E., Subasri, V., Abdalla, M., Fine, B., Dolatabadi, E., & Abdalla, M. Empirical Data Drift Detection Experiments on Real-World Medical Image Data. Nature Communications 15, 1887. 2024. https://doi.org/10.1038/s41467-024-46142-w  
[31] NIST. NIST Special Publication 800-208: Recommendation for Stateful Hash-Based Signature Schemes. 2020. https://doi.org/10.6028/NIST.SP.800-208  
[32] The Organisation for Economic Cooperation and Development (OECD). Glossary of statistical terms. 2008. https://doi.org/10.1787/9789264055087-en  
[33] NIST. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. 2020. https://doi.org/10.6028/NIST.SP.800-53r5 
[34] OWASP. AI Exchange. How to select relevant threats and controls? risk analysis. https://owaspai.org/goto/riskanalysis/  

Disclaimer of Endorsement

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose

This document was developed in furtherance of the authoring organizations’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders. 

Notice of Generative AI Use

Generative AI technology was carefully and responsibly used in the development of this document. The authors maintain ultimate responsibility for the accuracy of the information provided herein.

Contact 

U.S. Organizations

National Security Agency

Australian organizations

• Visit cyber.gov.au/report or call 1300 292 371 (1300 CYBER1) to report cybersecurity incidents and vulnerabilities.

New Zealand organizations