I drink bourbon, but I don’t watch television. I own a television, but I don’t watch broadcast television. The latest show everybody is raving about? Right over my head. Sports? Sent to /dev/null. I buy physical media for movies off Amazon, rip them to disk, store the disks in a storage shed, and watch whatever I want in some anchorage with a margarita in hand. I find that arrangement lets me write more, be more productive, and also get to thinking about things others don’t even consider.
The CMMC is a confidentiality protection strategy. That is what it was designed to be. Most CIOs are mostly worried about availability, which makes sense from a business continuity perspective. But as a CISO, I keep coming back to integrity attacks. Changing the right data at the right time can produce consequences far beyond what a breach or an outage would. Whether it is making a check worth more money, or making a bank refuse all checks from a retailer. The history of hacking has so many elements of salami slicing, penny changes, and other integrity attacks that it is remarkable how little attention gets paid to them relative to the flashier categories of compromise.
And that is the problem this chapter takes on. The adversary who does not steal your data or lock it up with ransomware, but changes it, quietly, and waits for you to act on the lie.
Threat Model
The attack is subtle alteration rather than theft or destruction. An adversary with access changes values in databases, documents, maintenance records, parts tracking systems, or compliance evidence by small, plausible amounts. The goal is not to trigger an alert. The goal is to corrupt a decision.
MITRE ATT&CK categorizes this under T1565, Data Manipulation, with three sub-techniques: stored data manipulation (T1565.001), transmitted data manipulation (T1565.002), and runtime data manipulation (T1565.003). The framework describes the intent well. Adversaries insert, delete, or manipulate data to influence external outcomes or hide activity, threatening data integrity. But ATT&CK also notes something important: for complex systems, an adversary would likely need special expertise and possibly access to specialized software related to the system, typically gained through a prolonged information-gathering campaign. That constraint still holds. An adversary cannot manipulate data they do not understand. They need to know what a value means in context before they can change it to something plausible but wrong.
The attacker profile here is not a smash-and-grab operator. This is a patient actor, likely state-sponsored or a sophisticated criminal group, who has already achieved persistent access and is now studying how the target organization uses its data. The model for this is Elephant Beetle, tracked by Sygnia as TG2003 and overlapping with the group Mandiant tracks as FIN13. That group spent months inside financial institutions in Latin America, studying transaction systems, before injecting fraudulent transactions that mimicked legitimate activity. They used classic salami tactics, moving incremental amounts that blended into normal operations. Sygnia’s researchers described the transactions as mimicking legitimate behavior to siphon off incremental amounts from the victim. The group stole millions of dollars before discovery.
Elephant Beetle targeted financial transactions, but the technique generalizes. Consider the data an Aerospace company in the defense industrial base works with every day. Maintenance records that determine whether an aircraft is cleared for flight. Parts tracking that governs which components go on which airframe. Compliance evidence that determines whether a contract is fulfilled. Calibration records that determine whether a measurement can be trusted. Change any of those values by a small, plausible amount, and the downstream consequences are not financial. They are operational and potentially lethal.
A maintenance record that shows 200 flight hours when the actual count is 280 could keep a component in service past its inspection interval. A parts record that swaps one NSN for another, visually similar part number could put the wrong fastener on a structural joint. A calibration record that shifts a date forward by two weeks could mean a torque wrench is being used outside its certified accuracy window.
The attacker who does this does not need to bring down a network. They do not need to exfiltrate a terabyte of CUI. They need write access to a database and enough time to understand what the values mean. AI reduces the time required for that second part. An LLM can read application documentation, study schema relationships, and identify which fields carry operational significance far faster than a human analyst studying the same system from the outside. The constraint that ATT&CK identifies, the prolonged information gathering campaign, just got compressed.
For organizations in the defense industrial base, this is where the threat model connects to national security. A RealClearDefense analysis published in August 2026 stated the argument plainly: adversaries need not destroy a missile system if they can quietly corrupt the information upon which it depends. A manipulated maintenance record can ground aircraft at the wrong moment. The article argued that design files, bills of material, maintenance records, and operational telemetry form the nervous system of the industrial organism, and that periodic inspections cannot detect evolving threats to data integrity.
The attacker needs four things. First, persistent access to the target environment, which they may already have from a separate compromise. Second, knowledge of the target application’s data model, which AI now helps them acquire faster. Third, write access to the data store, either through compromised credentials or through an application vulnerability. Fourth, enough operational understanding to make changes that are plausible but wrong. The first three are standard post-compromise requirements. The fourth is where AI drops the cost.
Traditional Tools
A competent security program built five years ago would have deployed several categories of controls that bear on this threat.
Access controls form the first layer. Role-based access control in the application, database permissions, and privileged access management restrict who can read and write specific data. A mature program would separate duties so that the person who enters a maintenance record is not the same person who approves it. Multi-factor authentication protects the credentials that govern access. All of this works as designed against an outsider who has not yet achieved access. Once an adversary has compromised a legitimate account with write permissions, access controls have done their job and failed at the same time. The door was locked, but the attacker had the key.
Change management provides procedural controls. A change advisory board reviews proposed changes. Ticketing systems track who requested what and when it was approved. Change windows limit when modifications can occur. In theory, this catches unauthorized changes. In practice, change management governs infrastructure changes, not data value changes within applications. Nobody submits a change ticket to update a flight hour count in a maintenance database. That is transactional data, and it flows through the application’s own workflow, not through the IT change management process.
File integrity monitoring represents the primary technical control for detecting unauthorized changes. Products like Tripwire, OSSEC, and the FIM capabilities built into endpoint detection platforms (CrowdStrike, SentinelOne, Carbon Black) continuously compare critical files against a known baseline using cryptographic hashes. When a monitored file changes unexpectedly, FIM generates an alert. PCI DSS Requirement 11.5.2 mandates a change-detection mechanism such as FIM. NIST SP 800-53 covers integrity verification under SI-7, which has no direct counterpart among the NIST 800-171 requirements. The tools do exactly what they were built to do.
The scope of what they monitor is the issue. FIM was designed to watch operating system files, application binaries, configuration files, registry keys, and security agent configurations. The NCCoE data integrity practice guide, NIST SP 1800-26, treats integrity monitoring as a core capability, and common practice extends monitoring to system files, configuration files, application executables, libraries, audit logs, databases, and backup files. That last category, databases, sounds like it covers the threat. But FIM monitors database files at the file system level, watching for changes to the binary files that constitute the database. It does not understand the data model inside those files. It does not know that a value in a specific column of a specific table just changed from 200 to 180. It knows the database file’s hash changed, which it does constantly during normal operations, which is why most FIM deployments exclude active database files from monitoring entirely. A database that is being used looks different every few seconds. Alerting on every hash change would generate thousands of false positives per hour.
Database audit logging picks up where FIM leaves off. Native auditing in SQL Server, Oracle, PostgreSQL, and MySQL can record every DML statement (INSERT, UPDATE, DELETE) executed against monitored tables. Third-party database activity monitoring (DAM) tools from Imperva, IBM Guardium, or similar vendors can capture the same data with additional analysis capabilities. A well-configured audit log will tell you that user jsmith executed an UPDATE statement against the maintenance_records table at 14:32 on Tuesday, changing the value in the flight_hours column from 200 to 180 for record ID 4471.
That is a complete audit record. It tells you who, when, what table, what column, what the old value was, and what the new value is. What it does not tell you is whether 180 is a reasonable number. It does not know that aircraft N4471 flew 22 hours last month according to the flight log system, which would make 180 impossible given the previous recorded value. The audit log captures the mechanics of the change. It is silent on the semantics.
SIEM platforms collect these audit logs along with authentication events, network flows, and endpoint telemetry. A SIEM correlation rule can detect unusual patterns: a user making changes outside business hours, a single account modifying an unusual number of records, or changes occurring from an unexpected source IP. These rules work against attackers who are sloppy about when, where, and how much they change. They do not work against an attacker who has studied the target environment enough to make changes during business hours, from the expected workstation, at a rate consistent with normal activity.
Data loss prevention (DLP) rounds out the toolkit, but it is designed for a different problem entirely. DLP watches for sensitive data leaving the organization. It does not watch for data being changed within the organization. The threat model here is the opposite of exfiltration. The data stays right where it is. It just says something different now.
The Gap
Every tool described above relies on one assumption: that unauthorized changes are distinguishable from authorized ones by their mechanical properties. Who made the change, when they made it, how they made it, and whether they were supposed to be able to make it at all.
That assumption was valid when the primary threat was an unauthorized outsider or a careless insider. If someone without write permissions modifies a file, FIM catches it. If someone modifies a record outside of business hours from an unrecognized IP, the SIEM catches it. If someone uses a SQL injection to bypass the application layer entirely, the DAM tool catches it.
But the threat model for a data integrity attack is an adversary operating through a compromised legitimate account, during business hours, from an expected network location, using the application’s own interface, making changes that fall within the mechanical parameters the monitoring tools consider normal. Every check passes because the credentials are valid, the source is expected, and the time is ordinary. The application logged the change through its normal workflow. The only thing wrong is the value itself, and no tool in the stack is evaluating whether the value makes sense.
This is the constraint that traditional tools relied on: that attackers would be mechanically distinguishable from legitimate users. The attacker who comes through the front door with a stolen badge, sits at a workstation during business hours, and changes a single value in a single record using the same application interface that authorized users employ all day, produces log entries that look identical to normal operations. The traditional detection model has no basis for distinguishing this change from the hundreds of legitimate changes that happen every shift.
None of the tools described above can close this gap on their own, and the reason is the same in each case: they were built to evaluate the mechanics of a change, not its meaning. FIM does not see inside application data. Database audit logging captures what changed but not whether the change makes sense. SIEM correlation rules evaluate the who and when and where, all of which look normal in this scenario. Change management never sees transactional data in the first place, and DLP is watching for data leaving the building, not data being rewritten inside it.
The gap is a missing layer of analysis: semantic validation. Not “did this change happen through an authorized mechanism?” but “does this new value make sense given everything else we know about this record, this entity, and this business process?”
AI compressed the attacker’s ability to understand a target’s data model. A language model can read database documentation, infer schema relationships from table and column names, study sample queries, and identify which fields carry operational weight, all in hours rather than weeks. The information-gathering campaign that ATT&CK described as a gate on this attack class just got cheaper and faster. The defender’s detection tools still rely on mechanical indicators that an AI-assisted attacker can trivially satisfy.
AI Augmentation
The defensive response is semantic integrity monitoring: using AI to baseline what normal data values look like in context and flag changes that are technically valid but operationally suspicious.
You build this capability on top of the data infrastructure you already have.
What you feed it. The system ingests two categories of data. First, the database audit logs you are already collecting, which provide the record of what changed, when, and by whom. Second, cross-reference data from related systems that establish what the values should be. For a maintenance tracking database, cross-reference sources include flight log systems (actual hours flown), parts inventory systems (what was actually issued), calibration management systems (when instruments were actually serviced), and work order systems (what work was actually performed). The key insight is that most organizations already have these data sources. They are just not connected to each other for validation purposes.
What the AI does with it. The AI component performs three functions. First, it builds a statistical baseline for each monitored field by entity. For aircraft N4471, the flight hours field has historically increased by 15 to 25 hours per month. A change that decreases the value, or that increases it by 60 hours in a week, falls outside the baseline. Second, it performs cross-system consistency checks. If the flight log system shows N4471 flew 22 hours last month but the maintenance record shows a net decrease of 20 hours, those two data sources contradict each other. Third, it evaluates change patterns at the population level. If one user’s edits consistently move values in a single direction, slightly downward, across multiple records, that pattern has a different profile than routine corrections, which tend to move in both directions.
The statistical baseline can be built with conventional time-series anomaly detection. An LSTM network or a simpler autoregressive model trained on the historical progression of values for each entity and field will learn what normal change patterns look like. The cross-system consistency checks can be implemented as a set of validation rules (flight hours should only increase, and the delta should approximate what the flight log system reports) applied after every change, with an LLM available to evaluate edge cases that the rules flag but cannot resolve. The population-level pattern analysis can be built with clustering algorithms that group users by their editing behavior and flag outliers whose change distributions differ significantly from their peers.
What the analyst receives. The output is a prioritized feed of suspicious changes, each annotated with the reason for suspicion. A typical alert might read: “Record 4471 in maintenance_records: flight_hours changed from 200 to 180 by jsmith at 14:32. Flagged because (1) flight_hours for this aircraft has never decreased in 36 months of history, (2) flight_log_system shows 22 hours flown since last update, expected value approximately 222, (3) jsmith has decreased flight_hours values on 14 records in the past 30 days with no corresponding increases.”
That alert gives the analyst something the raw audit log never could: a reason to investigate this specific change. The analyst does not need to review every database modification. They need to review the ones where the new value does not fit the context.
How it connects to existing workflows. The suspicious change feed integrates with the SIEM. Each flagged change becomes an enriched event that the SOC can triage alongside other alert types. For organizations with a formal data stewardship function, the feed can also route to the data owner for the affected system, who is better positioned than the SOC analyst to evaluate whether the change is a legitimate correction or an anomaly.
What breaks if this fails. The dependency risk is model accuracy. A poorly trained baseline will produce excessive false positives, which leads to alert fatigue and eventually to the SOC ignoring the feed entirely. The cross-system consistency checks are only as good as the data quality in the reference systems. If the flight log system is itself poorly maintained, validating maintenance records against it produces noise rather than signal. An adversary who understands the monitoring system could also manipulate the reference data to match the altered primary data, defeating the consistency check. This is why the cross-reference should draw from multiple independent sources rather than a single validation point.
What an adversary could do to cause failure. An attacker who discovers the semantic monitoring system could take several approaches. They could corrupt the training data by making small, gradual changes over a long period so that the baseline absorbs the drift and treats the manipulated range as normal. They could target the reference systems to bring them into alignment with the altered primary data. They could also generate a high volume of minor, legitimate-looking changes across many records to create noise that buries the signal. Defenses against these counter-tactics include periodic revalidation of baselines against physical records (did someone actually count the flight hours by hand?), integrity monitoring of the reference systems themselves, and rate-of-change analysis that flags gradual baseline drift.
The manual fallback. If the AI monitoring system goes offline or loses credibility, the fallback is periodic manual reconciliation between primary data stores and physical reality. Someone walks the hangar floor, checks the actual configuration of the aircraft against what the database says, and verifies a sample of records against source documents. This is slow and expensive, which is exactly why organizations stopped doing it frequently enough. The AI augmentation does not replace the need for physical verification. It reduces how often you need to do it by telling you where to look first.
For any organization in the defense industrial base, this is a national security argument, not just an information security argument. CMMC focuses on protecting CUI from unauthorized disclosure, and that matters, but the integrity of the data inside those same systems matters at least as much. A manipulated maintenance record on a military aircraft does not need to leave the building to cause harm. It just needs to be believed.
The defenders who build this capability do not need a new platform. They need to connect the data sources they already have, apply statistical and language-model-based analysis to the change stream, and give their analysts the one thing the traditional tools never provided: context about whether a change makes sense. The tools that were built to answer “who changed this?” were the right tools for the threats they were designed to detect. The question that matters now is “should this value be what it is?” And that question requires a different kind of monitoring entirely.
Works Cited
Cawthra, J., Ekstrom, M., Lusty, L., Sexton, J., & Sweetnam, J. (2020). Data integrity: Detecting and responding to ransomware and other destructive events (NIST SP 1800-26). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.1800-26
MITRE. (n.d.). Data manipulation (T1565). MITRE ATT&CK. https://attack.mitre.org/techniques/T1565/
National Institute of Standards and Technology. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5). https://doi.org/10.6028/NIST.SP.800-53r5
National Institute of Standards and Technology. (2020). Protecting controlled unclassified information in nonfederal systems and organizations (NIST SP 800-171 Rev. 2). https://doi.org/10.6028/NIST.SP.800-171r2
PCI Security Standards Council. (2022). Payment Card Industry Data Security Standard v4.0.
Sharpe, G. (2026, May 14). Quiet warfare: Bending data and perceptions in the defense industrial base. Global Security Review. https://globalsecurityreview.com/quiet-warfare-bending-data-and-perceptions-in-the-defense-industrial-base/
Sygnia. (2022, January 5). Elephant Beetle: Uncovering an organized financial-theft operation. https://www.businesswire.com/news/home/20220105005203/en/Sygnia-Uncovers-%E2%80%9CElephant-Beetle%E2%80%9D-an-Organized-Significant-Financial-Theft-Operation-Threatening-Global-Enterprises
About the Author
