File Integrity Monitoring
File integrity monitoring (FIM) can be used to detect changes to files and directories. A file may be altered due to an update to a newer version, a security breach, or data corruption. File integrity monitoring helps an organization respond quickly and effectively to unexpected changes to files and is therefore a standard requirement for many regulatory compliance objectives.
-
PCI-DSS compliance - Payment Card Industry Data Security Standard (Requirement 11.5)
-
SOX compliance - Sarbanes-Oxley Act (Section 404)
-
NERC CIP compliance - NERC CIP Standard (CIP-010-2)
-
FISMA compliance - Federal Information Security Management Act (NIST SP800-53 Rev3)
-
HIPAA compliance - Health Insurance Portability and Accountability Act of 1996 (NIST Publication 800-66)
-
SANS compliance - SANS Critical Security Controls (Control 3)
NXLog can be configured to provide file (or Windows Registry) integrity monitoring. An event is generated for each detected modification. These events can then be used to generate alerts or be forwarded for storage and auditing.
There are various ways that monitoring can be implemented; these fall into two categories.
- Checksum monitoring
-
The im_fim and im_regmon modules (available with NXLog Enterprise Edition only) provide monitoring based on a cryptographic checksums. On the first run (when a file set or the registry is in a known secure state), a database of checksums is created. Subsequent scans are performed at regular intervals, and the checksums are compared. When a change is detected, an event is generated.
-
The im_fim module is platform independent, available on all platforms supported by NXLog, and has no external dependencies. Similarly, the im_regmon module requires no configuration outside of NXLog to monitor the Windows Registry.
-
If there are multiple changes between two scans, only the cumulative effect is logged. For example, if a file is deleted and a new file is created in its place before the next scan occurs, a single modification event will be generated.
-
It is not possible to detect which user made a change because the filesystem/registry does not provide that information, and there may be multiple changes by different users between scans.
-
- Real-Time monitoring
-
Files (and the Windows Registry) can also be monitored in real-time with the help of kernel-level auditing, which does not require periodic scanning. This type of monitoring is platform specific.
-
Kernel-level monitoring usually provides improved performance, especially for large file sets.
-
All events are logged; the granularity of reporting is not limited by the scan interval (because there is no scanning involved).
-
Reported events may be very detailed, and usually include information about which user made the change.
-
See the following sections for details about setting up file integrity monitoring on various platforms.
File integrity monitoring on Linux
Checksum monitoring on Linux can be configured with the im_fim module of NXLog.
NXLog must have permission to read the files that are to be monitored. Run NXLog as root, make sure the nxlog user or group has permission to read the files, or change the user/group under which NXLog runs.
See the User and Group directives.
This configuration uses im_fim to monitor a common set of system directories containing configuration, executables, and libraries. The RIPEMD-160 hash function is selected and the scan interval is set to 3,600 seconds (1 hour).
<Input fim>
Module im_fim
File "/bin/*"
File "/etc/*"
File "/lib/*"
File "/opt/nxlog/bin/*"
File "/opt/nxlog/lib/*"
File "/sbin/*"
File "/usr/bin/*"
File "/usr/sbin/*"
Exclude "/etc/hosts.deny"
Exclude "/etc/mtab"
Digest rmd160
Recursive TRUE
ScanInterval 3600
</Input>NXLog will report scan activity in its internal log.
2022-11-02 13:56:14 INFO [im_fim|fim] Module 'fim': FIM scan started
2022-11-02 13:57:17 INFO [im_fim|fim] Module 'fim': FIM scan finished in 24.37 seconds. Scanned folders: 6427 Scanned files: 48299 Read file bytes: 5412661872{
"EventTime": "2022-11-02T13:56:15.013687+03:00",
"EventType": "CHANGE",
"Object": "FILE",
"PrevFileName": "/etc/group-",
"PrevModificationTime": "2022-08-29T11:34:52.000000+03:00",
"FileName": "/etc/group-",
"ModificationTime": "2022-11-02T13:55:49.000000+03:00",
"PrevFileSize": 1078,
"FileSize": 1133,
"DigestName": "rmd160",
"Digest": "5f2ae5bfcf8140f7279448323606f23c0d040f7d",
"PrevDigest": "d36ad51d8b626241d30a897a65abf338cacc487f",
"Severity": "WARNING",
"SeverityValue": 3,
"EventReceivedTime": "2022-11-02T13:56:15.013714+03:00",
"SourceModuleName": "fim",
"SourceModuleType": "im_fim"
}See the Linux Audit System chapter for details about setting up kernel-level auditing. It is even possible to combine the im_fim and im_linuxaudit modules for redundant monitoring.
File integrity monitoring on Windows
The im_fim module of NXLog can be used on Windows for monitoring a file set.
This configuration monitors the program directories for changes. The scan interval is set to 1,800 seconds (30 minutes). The events generated by NXLog are similar to those shown in File integrity monitoring on Linux.
<Input fim>
Module im_fim
File 'C:\Program Files\*'
File 'C:\Program Files (x86)\*'
Exclude 'C:\Program Files\nxlog\data\*'
Recursive TRUE
ScanInterval 1800
</Input>The Windows Registry can be monitored with the im_regmon module. This configuration monitors all registry keys in the specified path. The keys are scanned every 60 seconds.
<Input registry>
Module im_regmon
RegValue 'HKLM\Software\Policies\*'
Recursive TRUE
ScanInterval 60
</Input>NXLog will report scan activity in its internal log.
2022-11-02 17:05:05 INFO [im_regmon|registry] Module 'registry': Registry scan started
2022-11-02 17:05:05 INFO [im_regmon|registry] Module 'registry': Registry scan finished in 0.01 seconds. Scanned registry keys: 68 Scanned registry values: 18 Read value bytes: 146{
"EventTime":"2022-11-02T17:37:18.149487+03:00",
"EventType":"CHANGE",
"RegistryValueName":"HKLM\\Software\\Policies\\Microsoft\\TPM\\OSManagedAuthLevel",
"PrevValueSize":4,
"ValueSize":4,
"DigestName":"SHA1",
"PrevDigest":"ddaf0ed54dfc227ce677b5c2b44e3edee7c7db77",
"Digest":"d6459ab29c7b9a9fbf0c7c15fa35faa30fbf8cc6",
"Severity":"WARNING",
"SeverityValue":3,
"EventReceivedTime":"2022-11-02T17:37:18.149487+03:00",
"SourceModuleName":"registry",
"SourceModuleType":"im_regmon"
}The following example uses the im_regmon module to monitor a list of hive key paths listed in documents such as the MITRE ATT&CK framework and the JP/CERT Lateral Movements. This list can be modified as and when needed.
When running a custom list, make sure to double-check the internal log for the appropriate number of keys and values that are being scanned.
<Input extend_regmon_rules>
Module im_regmon
Recursive TRUE
ScanInterval 30
RegValue "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\*"
RegValue "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*"
RegValue "HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security\*"
RegValue "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\*"
RegValue "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute"
RegValue "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Control Panel\NameSpace\*"
RegValue "HKLM\SYSTEM\ControlSet001\Enum\STORAGE\VolumeSnapshot"
RegValue "HKLM\SYSTEM\ControlSet001\Services\VSS\*"
RegValue "HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce"
RegValue "HKLM\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\*"
RegValue "HKLM\Software\Microsoft\Windows\CurrentVersion\Run\*"
RegValue "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\*"
RegValue "HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce"
RegValue "HKLM\Software\Policies\*"
</Input>Real-time monitoring on Windows
Real-time monitoring can be implemented with Windows security auditing (see Security auditing on Microsoft Docs). Sysmon also implements file and registry monitoring with a system service and device driver; see the Sysmon chapter. In both cases, the generated events can be collected from the Windows Event Log with the im_msvistalog module (see the Windows Event Log chapter).
