The best explanation of file integrity monitoring I have ever seen was not written by a security vendor. It aired on UPN in January 1999, and it stars a hologram.
I spend my days building integrity software, so I am used to explaining what it does with diagrams, compliance frameworks, and the occasional breach post-mortem. Then I rewatched "Latent Image," the eleventh episode of Star Trek: Voyager's fifth season, and realized the writers had done my job for me in 45 minutes. Fair warning: spoilers ahead for an episode that is old enough to rent a car.
A Surgery Nobody Remembers
The episode opens with a routine task. Voyager's Emergency Medical Hologram, known to the crew simply as the Doctor, is running annual physicals with a new holographic imaging device. When he scans Ensign Harry Kim, he finds something that should not be there: the faint trace of a delicate neurosurgical procedure, roughly eighteen months old.
The technique is unmistakably his own. He is the only one aboard who could have performed it. And he has no memory of doing so. Neither does Kim.
Think about that from a systems perspective. The Doctor is software. His memories are files. His present state does not match his own record of how he got there. Something in his history has been changed, and nothing told him.
He did not catch it with an alarm. He caught it by accident, a year and a half after the fact, because a new diagnostic tool happened to look in the right place. If that sounds familiar, it should. It is how a great many organizations find out about their own incidents: late, sideways, and from evidence nobody was looking for.
The Doctor enlists Seven of Nine to dig deeper. They recover fragments of deleted images from that same period, including a crew member he does not recognize. Then things get worse. A short time later, he has no memory of asking Seven for help at all. Someone is not only hiding old changes. Someone is making new ones, right now, while he investigates.
The Doctor Builds a FIM Tool in About Ninety Seconds
This is the scene that made me sit up. The Doctor now knows three things: his files are being altered, the alterations happen while he is deactivated, and whoever is doing it can cover their tracks. He cannot stop the next attempt, so he sets a trap for it instead. He does three things.
- He takes a baseline. He has the computer make a protected copy of his memory files from the last 48 hours. That copy is his known-good state, stored somewhere the intruder does not know to look.
- He creates a detection and restore method. He instructs the computer that if his program is tampered with, it should reactivate him and restore his memories from that copy.
- He captures evidence. He rigs his holo-imager to record whoever comes into sickbay and touches his program.
Then he shuts himself off and waits.
It works exactly as designed. The intruder arrives and deletes his recent memories. The computer detects the change and brings him back online. For a moment he is confused, a system running on altered files with no idea anything is wrong. Then the restore completes, and he remembers everything. He checks the imager, and there is the answer, in the frame.
Baseline. Detect. Restore. Identify. In the security industry we call this file integrity monitoring, and those four steps are the heart of it. The Doctor never asks whether the tampering looks malicious. He does not run a behavioral model or score a risk. He asks one precise, answerable question: are my files what they are supposed to be? When the answer is no, everything else follows.
That question is the reason integrity monitoring is so effective. It is deterministic. A file either matches its trusted state or it does not.
Plot Twist: The Intruder Had Command Codes
The face in the image is Captain Kathryn Janeway.
Not an alien saboteur. Not a virus. The person altering the Doctor's files is the most trusted, most privileged user on the ship, the one whose authorization overrides everyone else's.
This is where the episode stops being a fun analogy and becomes an uncomfortable one. Consider what every other security control on Voyager would have reported that night:
- Access control: a valid user with valid credentials. Approved.
- Perimeter defense: nobody crossed it. The call came from inside the ship.
- Anti-malware: no malicious code involved. Just an administrator using standard tools.
- Logs: the same person who made the change had the authority to clean up after it.
Every control built around the question "is this user allowed to be here?" returns the same answer: yes. And that is the pattern behind a large share of real-world breaches. Attackers rarely break in anymore. They log in, with stolen or misused credentials, and from that moment they look like an administrator doing administrator things.
The only control that caught Janeway was the one that ignored who she was and looked at what changed. Integrity monitoring does not care how impressive your credentials are. It cares that the file is different now.
Your Network Is Voyager (Minus the Warp Core)
Strip away the holograms and the situation is ordinary. Every server, workstation, network device, database, and cloud workload you run is defined by its files and configurations. When those are in a known, trusted state, the system does what you expect. When they change without your knowledge, it does something else.
Nearly every security incident, and a surprising number of outages, comes down to a change somebody did not expect:
- Malware has to write itself somewhere.
- Ransomware has to modify files to encrypt them.
- An attacker who wants to stay has to add an account, alter a configuration, or plant a tool.
- A well-meaning engineer pushes an untested fix at 2 a.m. and takes down production.
Different motives, same signature: something that was one way is now another way.
Most organizations today are the Doctor at the start of the episode. They are functional and confident, and they are missing part of their own history. They find out the way he did, long after the fact, when an auditor, a customer, or an unrelated investigation turns up something that does not add up. By then the question is no longer "how do we stop this?" It is "how long has this been going on, and what else don't we know?"
The Doctor went eighteen months without knowing. He needed about ninety seconds of integrity monitoring to get his answer.
What the Doctor Improvised, CimTrak Does by Design
The Doctor's trap was brilliant, but it was a one-off. It covered one system, for one night, against one suspected event, and it only existed because he already knew something was wrong. He also had to switch himself off to make it work, which is not a deployment model I would recommend.
CimTrak is what you get when you take the same four ideas and engineer them to run continuously across an entire enterprise.
|
What the Doctor did |
What CimTrak does |
|
Copied 48 hours of memory files to a safe location |
Captures a trusted baseline of your critical files and configurations, with cryptographic hashes and metadata, held in a secured repository |
|
Told the computer to act if his program was tampered with |
Detects changes in real time, as they happen, rather than waiting for a scheduled scan |
|
Pointed a camera at the sickbay door |
Records the forensic detail of every change: who made it, what changed, when, from where, and with which process |
|
Had the computer restore his memories from the copy |
Rolls a changed file or configuration back to its trusted state, manually or automatically |
|
Could not prevent the deletion, only recover from it |
Can lock down files that should never change, blocking modification regardless of the user's privileges |
|
Protected one hologram |
Covers servers, workstations, network devices, databases, hypervisors, cloud, and containers from one console |
Two of those rows deserve a closer look.
The restore. Detection alone would have left the Doctor knowing he had been tampered with and nothing more. What made the trap work was that his known-good state came back. Most monitoring tools stop at the alert and hand the problem to a human. CimTrak keeps the trusted version, so recovery can be a single action, or no action at all if you have told it to self-heal.
The lockdown. Imagine the episode if the Doctor's memory files had simply refused the delete command, command codes or not. For the files and settings in your environment that should never change, CimTrak can do exactly that. Even an administrator cannot alter them without going through the proper process.
In Defense of Captain Janeway (Sort Of)
Here is the part that makes "Latent Image" a great episode rather than a simple whodunit. Janeway is not a villain.
Eighteen months earlier, two crew members were critically injured in an attack: Harry Kim and a young ensign named Ahni Jetal. The Doctor had time to save one. He chose Kim, and Jetal died. Afterward he could not reconcile the choice, and the conflict sent his program into a spiral that threatened to destroy it. With the ship's only physician failing, Janeway made a command decision. She deleted his memories of the event and had every trace of it hidden.
You can argue she was right. The episode spends its entire second half arguing about it. But set the ethics aside and look at it as a change management problem:
- The change was made by someone with the authority to make it.
- It was made for a defensible reason.
- It was undocumented, invisible to the system it affected, and never reviewed.
- Eighteen months later it resurfaced as a full-blown crisis.
That is the anatomy of most operational incidents I have seen. The damaging change is rarely an attack. It is the emergency fix that never got a ticket, or the configuration tweak that one person understood and nobody wrote down.
This is why modern integrity monitoring cannot just shout "something changed." In a real environment, things change constantly: patches, deployments, routine maintenance. A tool that alerts on all of it is noise, and people learn to ignore noise.
CimTrak's job is to sort changes into the ones you expected and the ones you did not. It reconciles changes against approved work in your ticketing system. Its Trusted File Registry automatically recognizes legitimate vendor patches and updates. What remains is a short, high-confidence list of changes that are unknown, unauthorized, or unexpected, which is the list worth a human's attention.
Had Voyager worked that way, Janeway's decision would have been a recorded, authorized, reviewable change, not a secret waiting to be rediscovered.
The Doctor Was an AI. So Is Your Next Coworker.
One more detail has aged remarkably well. The system at the center of this story is an artificial intelligence, one the crew depends on for life-and-death decisions, whose behavior was changed by editing the data underneath it.
In 1999 that was science fiction. Today organizations are handing real work to AI agents that read files, change configurations, and act with real privileges. Those agents can be manipulated, and they can also simply get things wrong while trying to help. Either way, the question the Doctor asked becomes the one that matters: what changed, who or what changed it, and can we put it back?
You cannot answer that with a tool that guesses. You need a record of the trusted state and a definitive account of every departure from it. An AI agent should be held to the same standard as any other privileged user, starship captains included.
Here Begins a New Baseline
"Latent Image" ends quietly. Janeway decides the Doctor deserves the truth and the chance to work through it, and the crew stays with him while he does. It is one of the most human moments in the series, and it is why Robert Picardo, who played the Doctor, has called it his favorite episode.
It lands because the Doctor's integrity mattered, in both senses of the word. He could not be whole while part of his own record was missing.
Your systems will never have an existential crisis. They are in the same position, though. They are only as trustworthy as your ability to prove they are in the state you think they are in. The Doctor had to discover that the hard way, improvise a solution under pressure, and hope it held.
You do not have to improvise. CimTrak establishes the trusted baseline, watches it in real time, tells you exactly who changed what, and puts it back when it matters.
If you would like to see what is changing in your environment right now, request a CimTrak demo. It takes a little longer than ninety seconds, and nobody has to be deactivated.
November 12, 2026
Try CimTrak for Free
Get your Free 14-day trial of CimTrak
Just let us know what capabilities you want to test out, and we'll set up a trial in your environment.