File Integrity Monitoring (FIM)

File Integrity Monitoring (FIM)

Overview

File Integrity Monitoring (FIM) is a feature within opConfig that allows you to monitor critical files and directories on remote servers for changes. It is designed to support regulatory compliance requirements by providing visibility into:

  • Existence - Whether a monitored file or directory is present on the target system.

  • Creation - When a file was first created or added to the server.

  • Last Modification - When a file was last changed, and by whom.

  • Size - The current size of the file, updated on each collection.

  • Ownership and Permissions - Who owns the file and what its current access permissions are.

  • Change Detection - Automatic detection and alerting when monitored files are created, modified, or deleted between collection runs.

  • Audit Trail - On supported systems, identification of the user or process responsible for changes.

FIM operates as an extension of the opConfig Command Set system. You create a FIM-enabled Command Set, define the files or directories you wish to monitor, and opConfig periodically collects metadata from the target nodes and raises alerts when changes are detected.

Supported Platforms

FIM supports two operating system families, each using a different backend collection method:

Platform

Collection Method

Audit Source

Linux (CentOS, Ubuntu, RHEL, etc.)

SSH + stat commands

auditd via ausearch

Windows (Windows Server, etc.)

WMI

Windows Security Event Log via WinRM/PowerShell

The platform is selected when creating the Command Set via the OS Mode setting, which determines the backend plugins used, the available configuration options, and path format validation.

Configuring a FIM Command Set

FIM is configured through the opConfig Command Set editor. When creating or editing a Command Set, enabling File Integrity Monitoring transforms the editor into the FIM-specific interface.

Step 1: Create a File Integrity Monitoring Command Set

image-20260302-012711.png
Create a new Command Set from the Command Set listing
image-20260302-012802.png
Specify the File Integrity Monitoring Command Set type

Step 2: Select OS Mode

Choose whether this Command Set will monitor Linux or Windows systems.

image-20260302-012949.png
Select the Operating System Mode

This affects:

  • Allowed file path formats (e.g., /path/to/file vs C:\path\to\file).

  • Available configuration fields (auditd settings for Linux, ACL settings for Windows).

  • The underlying collection and processing plugins used.

Note: A single Command Set can only target one OS family. Create separate Command Sets for Linux and Windows nodes.

Step 3: Configure General Settings

Field

Description

Name

A unique identifier for this Command Set. Must contain only alphanumeric characters and underscores, and cannot be the name “new”

Active

Enables or disables this Command Set. Use this to temporarily stop monitoring without deleting the configuration.

OS

A string or regex filter to match against the node’s os_info.os field. Defaults to /(Linux\|CentOS\|Ubuntu)/ for Linux mode or /Windows/ for Windows mode. Supports regex syntax, e.g., /(RHEL\|CentOS)/.

Version

Optional. A string or regex filter to match against the node’s os_info.version field.

Tags

These operate as normal Command Set tags, used for categorising and grouping Command Sets.

Keep Last

The number of revisions (changed result sets) to retain in the system. Set to 0 to keep all revisions.

Purge Older Than

Controls the maximum age for retained revisions. Revisions older than this are automatically purged.

Plugin Interaction Timeout

The maximum time (in seconds) the plugin is allowed to interact with the remote system before timing out. Default is 120 seconds.

Step 4: Configure Platform-Specific Settings

Linux: Auditd Configuration

These settings control how opConfig interacts with the Linux audit daemon on target machines.

Field

Description

Default

Configure Auditd

When enabled, opConfig will write audit rules to the target system’s auditd configuration to enable file-level monitoring.

true

Log File

The path to the audit log file on the target system.

/var/log/audit/audit.log

Reporting Level

The verbosity of auditd reporting: minimal, standard, or verbose.

standard

Max Log Size (MB)

The maximum size of the auditd log file before rotation. Must be greater than 0.

8

Note: When “Configure Auditd” is enabled, opConfig will automatically deploy audit rules to /etc/audit/rules.d/file-integrity.rules on the target system and reload the audit daemon. The Credential Set used to access the target server should be configured to allow sudo via it’s privileged password setting.

Windows: ACL Settings

These settings control how opConfig manages Windows audit ACLs (Access Control Lists) on target directories.

Field

Description

Default

Set ACLs

When enabled, opConfig will configure Windows audit ACL settings on the first run, or after path modifications. This should generally be left enabled.

Enabled

Force Set ACLs

Forces a reset of all Windows audit ACL settings. Only use this if you have encountered issues with audit/ACL settings on Windows servers. Once the Command Set has re-run on the affected system, you should manually set this back to false.

Disabled

Note: “Force Set ACLs” will rewrite all audit ACLs for monitored directories. Only enable this to recover from a known configuration issue, then disable it again after the next successful run.

Managing Monitored Paths

The core of FIM configuration is the list of files and directories you wish to monitor. The FIM editor provides several ways to manage this list.

Adding a Single Path

image-20260302-021800.png
The Add Path dialog in Linux mode
  1. Click “+ Add Path” in the Monitored Files and Directories toolbar.

  2. Enter the full file path:

    • Linux: Must begin with / (e.g., /etc/passwd, /usr/local/omk/conf/opCommon.json).

    • Windows: Must begin with a drive letter (e.g., C:\Windows\System32\config\SAM) or a UNC path (e.g., \\server\share\file.txt).

  3. Set the “Alert Level” for this path (see Alert Levels).

  4. Linux only: Configure the Audit Monitoring Options (Read, Write, Execute, Attributes).

  5. Click “Save”.

Bulk Add

image-20260302-021929.png
Bulk adding file paths in Linux Mode

To add many paths at once:

  1. Click “Bulk Add” in the toolbar.

  2. Paste file paths into the text area, one path per line.

  3. Alternatively, paste CSV data. The system auto-detects CSV format. CSV columns:

    • Linux: path, alert, read, write, execute, attributes

    • Windows: path, alert

    • Headers are optional and auto-detected.

  4. Set default audit rules and alert level for all imported paths (these apply in simple text mode; CSV mode uses the values from each row).

  5. Optionally check “Overwrite existing paths” to update paths that already exist in the list.

  6. Click “Add”.

Editing Paths

  • Click the edit icon on any row in the table to modify its path, alert level, or audit settings.

Bulk Editing

image-20260302-023425.png
Disabling the Attributes flag on multiple paths using Bulk Edit in Linux mode

To change settings on multiple paths at once:

  • Select the paths you wish to modify using the checkboxes in the table.

  • Click “Bulk Edit” in the toolbar.

    image-20260302-023642.png
  • Modify the desired fields. Fields left as “Don’t Change” will not be altered.

    • Alert Level: Select a new level or leave as “Don’t Change”.

    • Audit Rules (Linux only): Use the tri-state checkboxes - empty means “don’t change”, checkmark means “enable”, X means “disable”.

  • Click Edit.

Note: You will receive warnings post-import if duplicate paths exist, or paths are invalid

Deleting Paths

  • Click the delete icon on a single row, or select multiple rows and click “Delete Selected”.

  • Confirm the deletion prompt.

Exporting Paths

Click Export in the toolbar to download the current path list as a CSV file. This is useful for backup, auditing, or transferring configurations between Command Sets.

Searching Paths

Use the search box in the toolbar to filter the displayed paths. This filters the table view and does not affect the saved configuration.

Alert Levels

Each monitored path is assigned an alert level that determines the severity of alerts raised when changes are detected.

The alert level maps to the priority of events created in opEvents.

Audit Monitoring Options (Linux Only)

On Linux systems, FIM integrates with the auditd (Linux Audit Daemon) to provide granular monitoring of file access operations. When “Configure Auditd” is enabled, opConfig deploys audit rules to the target system that track the following types of operations:

Option

auditd flag

What it monitors

Read

r

Read access operations - when a file is opened for reading.

Write

w

Write/modification operations - when file contents are changed.

Execute

x

Execution of files.

Attributes

a

Attribute changes - modifications to permissions, ownership, or timestamps.

These options are combined into an audit rule for each monitored path. For example, a path with Read and Write enabled produces the auditd rule:

-w /path/to/file -p rw -k fwopconfig_Warning

The audit key (fwopconfig_Normal, fwopconfig_Warning, or fwopconfig_Fatal) is derived from the alert level and is used by opEvents parsers to assign the correct event priority.

Note: These per-path audit options are not available in Windows mode. Windows audit monitoring is handled through ACLs and the Windows Security Event Log, which monitors a broad set of access types automatically.

Preparing Target Machines

Linux Prerequisites

For FIM to function correctly on Linux target systems, the following must be in place:

SSH Access

  • The opConfig server must be able to reach the target node via SSH.

  • A valid credential set must be configured in opConfig for the target node, with either:

    • SSH key-based authentication (recommended), or

    • Password-based authentication.

Sudo Privileges

If auditd configuration is enabled the SSH user must have sudo access on the target machine. This can be configured as:

  • Always privileged: The user has passwordless sudo via sudoers configuration.

  • Password privileged: The user can elevate using their password via sudo.

Auditd Installation and Configuration

If you wish to configure FIM to use auditd, it must be installed and running on the target system, and:

  • The audit rules directory must exist at /etc/audit/rules.d/. This is the standard location on modern Linux distributions.

  • augenrules must be available - opConfig uses augenrules --check and augenrules --load to detect changes and reload rules.

Note: The file /etc/audit/rules.d/file-integrity.rules is managed by opConfig. Manual edits to this file may be overwritten on the next collection run.

Stat Command

The stat utility must be available at the standard path. opConfig uses stat -c to retrieve file metadata. This should be included by default on your Linux system.

Windows Prerequisites

For FIM to function correctly on Windows target systems:

WMI Access

  • The opConfig server must be able to query WMI on the target system.

  • A valid credential set must be configured with a Windows domain account that has WMI read access.

WinRM Access

  • For audit event retrieval, WinRM must be enabled on the target Windows system.

  • The opConfig server uses WinRM to execute PowerShell commands that query the Windows Security Event Log.

Windows Audit Policy

  • For change detection to identify which users modified files, Object Access auditing must be enabled on the Windows target.

ACL Configuration

When “Set ACLs” is enabled in the Command Set (recommended), opConfig will automatically configure audit ACLs on the parent directories of monitored files during the first collection run. This sets up the necessary Windows audit entries so that file access events are recorded in the Security Event Log.

  • ACLs are only applied to directories that haven’t been configured in a previous run (unless “Force Set ACLs” is enabled).

  • The credential used must have permission to modify audit ACLs on the target directories.

Viewing Results in opConfig

FIM results are viewed through the standard opConfig interface, as the data is stored as Command Set revisions.

Command Set Output

After the FIM Command Set runs, you can view the collected data in the Command Set revision output. The output is structured JSON containing:

  • Summary: Total count of monitored files, how many exist, and how many were not found.

  • Per-file details:

    • File path

    • Status (EXISTS / DOES NOT EXIST)

    • Creation date and time

    • Last modification date and time

    • File size (human-readable)

    • Ownership (user:group on Linux, owner on Windows)

    • File permissions

    • Modification status (UNCHANGED, MODIFIED, CREATED, DELETED, MISSING, FIRST_SEEN)

    • Audit information (who made changes, what operation, when)

Derived Data Table

The processing plugin produces a “File Integrity Status” derived data table with the following columns:

Column

Description

File Path

The full path of the monitored file.

Status

Whether the file exists (EXISTS) or not (DOES NOT EXIST).

Created

The date and time the file was created (if available).

Last Modified

The date and time the file was last modified.

Size

The current file size in human-readable format.

Ownership

The file owner (user:group on Linux, account name on Windows).

Additionally, a “File Count” summary table shows the number of files found, not found, and total.

Limitations

  • FIM detects changes on each collection cycle. Changes that occur between polls are detected at the next collection run, not in real-time. The audit trail helps identify what happened between runs.

  • FIM monitors file metadata (size, timestamps, permissions) rather than file content. Two files with different content but the same metadata would not be detected as changed.

  • When a directory path is monitored, only operations on the directory itself are tracked (not its contents). To monitor all files within a directory, each file must be added individually.

  • While there is no hard limit on the number of monitored paths, monitoring a very large number of files (hundreds+) will increase collection time. Consider the Plugin Interaction Timeout setting.

  • On the first collection run, there is no previous baseline for comparison. Files will show as FIRST_SEEN. Change detection begins from the second run onward.

  • You cannot mix Linux and Windows nodes in a single Command Set. Create separate Command Sets for each OS family.

  • Command sets can be edited manually for additional (command set specific) options. The UI will not overwrite settings in the json file which it doesn't itself use.