In the previous article, I introduced the integrity concept in FILIP:OS.

The central question was simple:

Is the system still in the state we originally trusted?

That question sounds straightforward, but answering it correctly requires more than calculating a checksum.

A production system changes continuously. Administrators modify configuration files, packages are updated, services generate state, permissions change and new tools are installed.

Some changes are expected. Others are mistakes. A smaller number may indicate an intrusion.

The role of the FILIP:OS integrity module is not to declare every change an attack.

Its role is to establish a trusted reference state, detect differences, preserve evidence and give the operator enough information to investigate what happened.

What is an integrity baseline?

An integrity baseline is a recorded representation of an accepted system state.

In FILIP:OS, an operational baseline can be created with:

filipctl run integrity baseline operational

The module scans the configured paths and creates a JSON baseline containing information about monitored files.

For regular files, FILIP:OS records:

  • path,
  • file type,
  • SHA-256 hash,
  • file size,
  • modification time,
  • Unix permissions,
  • user ID,
  • group ID,
  • executable status.

For symbolic links, it also records the link target.

The baseline additionally contains operational context such as:

  • baseline identifier,
  • baseline type,
  • creation time,
  • operator identity,
  • host,
  • node identity,
  • FILIP:OS version,
  • monitored include and exclude paths.

This matters because file integrity is not only about content.

A file can remain byte-for-byte identical while its permissions or ownership change. A symbolic link can begin pointing somewhere else. A trusted executable can become writable by an inappropriate user.

All of these changes may affect the security of the system.

What does FILIP:OS monitor?

The default integrity configuration focuses on the FILIP:OS control plane and important operating-system paths.

These include areas such as:

/usr/local/bin
/etc/filipos
/etc/init.d
/etc/runlevels
/etc/periodic
/etc/profile.d
/etc/webmin
/etc/glpi-agent
/etc/nxagentd.conf
/etc/nftables.d
/etc/apk/repositories
/lib/apk/db/installed

Dynamic or unsuitable locations are excluded by default:

/proc
/sys
/dev
/run
/tmp
/var/log
/var/cache
/var/lib/glpi-agent

The goal is not to hash every changing byte on the system.

The goal is to monitor binaries, configuration and control-plane objects that define how the appliance behaves.

Running an integrity check

A manual integrity check is started with:

filipctl run integrity

For a more detailed per-file view:

filipctl run integrity --verbose

The module loads the selected baseline, scans the monitored paths and compares the current filesystem state with the accepted state.

A normal result can look like this:

Result: OK
ok: 118
changed: 0
metadata_changed: 0
missing: 0
new: 0
errors: 0

A system with detected drift may return:

Result: WARN
ok: 116
changed: 1
metadata_changed: 1
missing: 0
new: 1
errors: 0

FILIP:OS currently distinguishes several change categories.

Changed

A file is classified as changed when its content hash or size differs from the baseline.

For example:

CHANGED /usr/local/bin/filipctl

This could mean:

  • a legitimate software update,
  • a manual binary replacement,
  • file corruption,
  • an unauthorized modification.

The integrity result alone does not determine which explanation is correct.

Metadata changed

A metadata change means that the content may be unchanged, but one of the recorded attributes differs.

This can include:

  • file permissions,
  • owner,
  • group,
  • symbolic-link target.

A configuration file may contain exactly the same text but become writable by an unauthorized account.

That is still a meaningful integrity change.

Missing

A monitored file existed in the baseline but no longer exists.

Possible explanations include:

  • intentional removal,
  • incomplete upgrade,
  • failed deployment,
  • accidental deletion,
  • attacker activity.

New

A new file exists in a monitored path but was not present in the baseline.

For example:

NEW /usr/local/bin/new-tool

A new administrative tool may be legitimate.

An unknown executable appearing in a trusted binary directory may require immediate investigation.

An integrity violation is not automatically an attack

This distinction is essential.

An integrity warning means:

The current system state differs from the accepted baseline.

It does not automatically mean:

The system has been compromised.

The difference may be caused by a legitimate administrator, a scheduled update, an incorrect command, a failed package operation or a security incident.

The integrity module detects the fact of change.

The operator must determine its meaning.

That investigation should include:

  • recent FILIP:OS lifecycle commands,
  • package-management history,
  • system logs,
  • syslog events,
  • administrator activity,
  • change-management records,
  • monitoring and SIEM events,
  • exact old and new file properties.

This is why integrity monitoring is most valuable when connected to operational context.

Reporting and evidence

FILIP:OS provides several report modes.

A basic operator report:

filipctl report integrity basic

A more detailed administrative report:

filipctl report integrity extended

A machine-readable external report:

filipctl report integrity external

The integrity check also writes local evidence to:

/var/lib/filipos/integrity/last-check.json
/var/lib/filipos/integrity/history.jsonl
/var/log/filipos/integrity.log

When drift is detected on a live system, FILIP:OS also attempts to emit a syslog event using the filipos-integrity tag.

This makes the result suitable for ingestion by monitoring or SIEM systems.

The current external JSON report is intentionally minimal. It contains the baseline ID, node identity, result and summary counts.

Richer export and correlation are areas for further development.

Periodic integrity checking

The integrity module is built into FILIP:OS.

It cannot be uninstalled or unloaded like an optional application module.

Running:

filipctl load integrity

ensures that the default configuration exists and creates a periodic daily integrity-check script.

This reflects the role of integrity monitoring in the platform.

It is not merely an optional convenience feature. It is part of the security control plane.

Legitimate changes and baseline refresh

A practical integrity system must handle legitimate changes.

If FILIP:OS modifies a monitored configuration through a lifecycle or settings command, the next integrity check would normally detect that modification.

Some current module workflows therefore refresh the operational baseline after a legitimate configuration change and then run an integrity check.

This prevents known administrative actions from continuously appearing as unexplained drift.

However, this also exposes an important security boundary.

The current baseline is local and can be replaced by a sufficiently privileged process.

It is not yet protected by:

  • a cryptographic signature,
  • an immutable ledger,
  • a central approval workflow,
  • a signed external receipt,
  • a command correlation identifier,
  • a formal change identifier.

The current integrity implementation should therefore be described accurately as:

Local baseline-based drift detection with operational evidence.

It should not yet be described as a tamper-proof integrity ledger.

Why blindly replacing a baseline is dangerous

Imagine this sequence:

  1. An attacker modifies a trusted executable.
  2. The attacker or another privileged process creates a new baseline.
  3. The compromised file becomes part of the accepted state.
  4. The next integrity check returns OK.

The hashes would be technically correct, but the security conclusion would be wrong.

A new baseline should therefore not be treated as a routine technical operation.

It represents a security decision:

We accept the current state as trusted.

A stronger future workflow should require context such as:

reason
operator identity
change identifier
approval
timestamp
previous baseline identifier
new baseline identifier
digital signature
external receipt

The process should look more like this:

system change
    ↓
integrity detects drift
    ↓
change is investigated
    ↓
change is approved
    ↓
new baseline is signed
    ↓
evidence is anchored externally

Current security properties

The current FILIP:OS integrity implementation already provides useful operational security properties:

  • SHA-256 hashing of regular files,
  • file metadata monitoring,
  • recursive scanning of configured paths,
  • detection of changed, missing and new files,
  • local JSON evidence,
  • append-style JSONL history,
  • local log output,
  • syslog drift notification,
  • daily periodic execution,
  • operator and external reports.

There are also known limitations:

  • the baseline is not signed,
  • the evidence history is not hash-chained,
  • baseline replacement does not require approval,
  • trusted timestamps are not yet implemented,
  • permission-read errors are not fully represented in the result,
  • directory metadata is not monitored,
  • no strong lifecycle correlation ID exists,
  • no direct , Wazuh or SIEM connector is implemented.

These limitations are not reasons to avoid integrity monitoring.

They define the next engineering steps.

How an operator should react to WARN

When FILIP:OS reports an integrity warning, the safest response is not to immediately recreate the baseline.

The operator should first run the extended report:

filipctl report integrity extended

Then:

  1. Identify every changed, missing or new object.
  2. Compare the changes with recent administrative actions.
  3. Review system and FILIP:OS logs.
  4. Check syslog, monitoring and SIEM events.
  5. Verify package updates and configuration changes.
  6. Determine whether the state is legitimate.
  7. Only after the change has been explained and accepted should a new baseline be created.

The unsafe workflow is:

WARN
    ↓
recreate baseline
    ↓
ignore the cause

The correct workflow is:

WARN
    ↓
investigate
    ↓
classify
    ↓
approve or respond
    ↓
accept a new trusted state

Integrity as evidence, not just monitoring

Traditional integrity tools often stop after reporting that a file changed.

FILIP:OS is moving toward a broader model.

The long-term objective is to connect:

  • integrity results,
  • system logs,
  • lifecycle commands,
  • node identity,
  • trusted time,
  • certificates,
  • digital signatures,
  • monitoring systems,
  • SIEM,
  • ,
  • an immutable Evidence Ledger.

The integrity module answers the first question:

What changed?

The audit and correlation layers must answer:

Who changed it, through which command, under which authorization and at what trusted time?

The evidence layer must answer:

Can we prove that the baseline and resulting records were not modified afterwards?

Conclusion

Integrity monitoring is not about treating every difference as an attack.

It is about replacing assumptions with evidence.

FILIP:OS records an accepted state, detects filesystem drift, classifies the differences and preserves local evidence for further investigation.

Today, this is a practical local integrity and drift-detection mechanism.

The next challenge is protecting the evidence itself.

Detecting a change is only the first step.

The stronger security question is:

How do we prove that the baseline, timestamp and evidence were not altered by the same privileged actor who changed the system?