Unexplained changes surface on their own
Changes are recorded as they happen, so the one that matches no ticket stands out.
Know which files changed, on which endpoint, and whether the change was expected.
A changed system file is either maintenance or an intrusion, and the difference is whether anyone can account for it. File Integrity records each change with its hash and its endpoint, and holds a baseline to compare against.
File Integrity & Baseline
MonitoringEvery change is recorded with its endpoint, time and file hash.
What is at stake
If you cannot say what changed on a system, you cannot say whether it is still the system you built.
Changes are recorded as they happen, so the one that matches no ticket stands out.
The change feed is the evidence that file integrity monitoring was in place and operating.
Knowing exactly which files changed on which endpoints, with hashes, shortens the question of what was touched.
Who carries this
Carried by whoever answers for system integrity, typically infrastructure and security together, and by compliance when a standard names the control.
The problem
Attackers change files to stay: a replaced binary, an edited configuration, a new key in an authorised list. So do administrators, package managers and deployment pipelines, hundreds of times a week.
Without a record, the two are impossible to tell apart after the fact. With a record of what changed, on which endpoint, when, and what the file hashed to, the question becomes answerable: match the change to a ticket, or treat it as a finding.
File Integrity keeps that record and a baseline to measure it against.
A change you can account for is maintenance. One you cannot is an investigation.
Capabilities
Every tracked change is listed with the file path, the type of event, the endpoint, when it was modified and the SHA-256 of the file, and the feed can be filtered by event type.
The baseline shows what is under monitoring, across files and registry entries, for every endpoint. That is what turns a list of changes into an answer about drift.
Changes to security-critical locations, such as accounts, remote access, scheduled jobs, services and system configuration, are separated from routine change so they are not lost in the volume.
The agent watches sensitive paths and reports changes as they happen, so file integrity is a detection source as well as a record.
The hash produced on change is what the platform checks for file reputation, which is why a file integrity event can become a malware finding.
How it fits the platform
File integrity monitoring is a control that PCI DSS and HIPAA assessors ask to see evidenced directly. Because the change feed lives beside compliance posture, the evidence and the control are the same data.
How it works
How a file change is handled.
Sensitive paths are monitored on the endpoint, and changes are detected as they happen.
The event carries the path, the kind of change, the endpoint and the SHA-256 of the file.
The same hash is used for file reputation, so a known-bad file arriving through a change becomes a malware finding.
Analysts read the change feed, filter it, and compare against the baseline.
Because the feed is retained, it is also the evidence that the control was operating for the period an assessor samples.
Questions
The file, the type of change, the endpoint, the time and a hash of the file.
Yes. File integrity monitoring is a control assessors ask to see for standards such as PCI DSS and HIPAA. The change feed is the record that the control was operating.
They are connected. The hash produced when a file changes is what the platform uses for file reputation, so a file integrity event can lead to a malware finding.
Works with
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
We will walk through the console, the deployment model and what it takes to stand it up in your environment.