File Integrity Monitor

The problem

3.14.5 requires periodic scans of organizational systems. 3.14.6 requires monitoring to detect attacks and indicators of attack. Both controls are written to be solved with file integrity monitoring, since FIM is the technical evidence that a system has not been tampered with between assessments rather than a procedural claim that nobody touched it.

Persistence mechanisms are visible to FIM that nothing else catches. A modified SSH host key is the setup for a man-in-the-middle. A new SUID binary is privilege escalation infrastructure waiting to be used. A kernel module added to /lib/modules/ is a near-certain rootkit indicator. None of these get detected by AV in the general case; all of them get detected by file hashing in the specific case.

Performance is the operational constraint. A naive scanner hashes hundreds of thousands of files on every run and burns the host's IO budget. The agent uses mtime as a pre-filter, so if mtime has not changed since the last scan it skips the re-hash and trusts the recorded hash. Subsequent scans complete in seconds rather than minutes, with no measurable load on production systems.

What CMMC requires

NIST SP 800-171 Rev 2 controls this agent verifies. Primary mappings drive the gap assessment; secondary mappings provide supporting evidence in the SSP.

How it works

Per-platform detection logic. The agent runs unprivileged where possible and falls back gracefully when raw access is unavailable.

What it finds

Concrete findings written to the assessor's mental model,not abstract categories. Severity drives POA&M priority and SPRS deduction.

• CRITICAL
  Critical binary modified in /bin or /sbin

  Hash mismatch on a system binary. High rootkit likelihood,investigate immediately. Trojaned ls, ps, netstat, or sshd are well-documented attack patterns.
• CRITICAL
  Kernel module added or modified

  New or changed file under /lib/modules/. Strong rootkit indicator. Kernel-mode persistence is the highest-risk change a system can experience.
• CRITICAL
  Windows System32 binary modified

  Hash mismatch on a System32 file outside an authorized Windows Update window. Service hijacking or rootkit pattern.
• HIGH
  /etc/sudoers modified

  Privilege escalation policy changed since last scan. Verify against approved configuration management,this should never happen outside a tracked change.
• HIGH
  SSH host key modified

  Host key replaced. Either an admin operation that needs documentation or a man-in-the-middle setup. Both demand explanation.
• HIGH
  New SUID binary detected

  Binary with SUID bit added since baseline. Privilege escalation infrastructure,investigate origin and authorize or remove.
• HIGH
  New cron job in /etc/cron.d/

  Cron file created since baseline. Persistence mechanism,verify the source of the change.

How it hooks into the platform

The platform initializes the SHA-256 hash database on first discovery of each host and re-hashes on a cadence calibrated to the host's CUI tier. You choose whether the database, diffs, and finding metadata stay on-prem or sync up; the database itself can remain local even when findings sync. The signed FIM database is the SSP's cryptographic file-state baseline under 3.4.1, and the recurring re-scan satisfies 3.14.5 and 3.14.6 directly. Findings link to path, hash before, hash after, and time of change. POA&M items capture investigations of unauthorized modification.

How we know it's working

Acceptance criteria from the engineering spec,what the agent must do to ship.

• ✓Detects modifications anywhere under /etc/ within the next scan cycle
• ✓Surfaces kernel module changes against any added or replaced .ko file
• ✓Flags newly added SUID binaries on the next scan automatically
• ✓Skips re-hashing of files whose mtime is unchanged for fast subsequent scans
• ✓Detects tampering of the FIM database via HMAC-SHA256 on every read
• ✓Hashes /bin, /sbin, and /usr/bin in under 30 seconds on first run
• ✓Excludes /proc, /sys, and /dev unconditionally to avoid pseudo-fs noise