File integrity monitoring is implemented as a detection mechanism to monitor
changes to important files and folders. File integrity monitoring is largely
used as a security measure for detection and for meeting obligations such as
compliance. By using file integrity monitoring, better control measures can be
taken due to being able to track and provide data for alerts of activities on
assets that are being monitored, such as potential unauthorized changes. It
also allows for better incident response like the detection of malware
outbreaks or malicious changes made by malware to critical assets. It can also
serve as an intruder detection tactic to monitor changes to vital configuration
Within compliance, file integrity monitoring represents a crucial role in
meeting obligations and requirements. Below are some examples of compliance
mandates and obligations related to FIM:
Electronically protected health information will require FIM / electronic
mechanisms to corroborate that a particular data has not not been compromised
in an unauthorized manner.
A POS system would require FIM for PCI DSS compliance.
SOX (Sarbanes Oxley)/COBIT Framework
For the SOX/COBIT Framework, FIM is required for reporting on internal control
structures (SOX 404), Internal controls (SOX 302), Supporting applications
(COBIT enablers), and Evaluation and monitoring (COBIT lifecycle).
FIM can help the configuration change management and vulnerability assessments
required by CIP-010-2.
FISMA (part of NIST SP 800-53)
FIM can assist with ensuring that organizations remain compliant under the NIST
SP 800-53 federal guidelines.
The Gramm-Leach-Bliley Act (GLB Act or GLBA) or the Financial Modernization Act of 1999
FIM meets the following requirements of the GLB Act; Security Process,
Information Security Risk Assessment, Information Security Strategy, Security
Control Implementation - Access Control and Security Controls Implementation –
Critical Security Controls
Implementing FIM can help checking that critical system files have not been
altered, as is required by CIS.
What is real time integrity monitoring?
There are two modes for file integrity monitoring - real time integrity monitoring and periodic auditing and integrity monitoring.
Real time integrity monitoring is when files, folders, applications or
hierarchical databases like the Windows Registry are monitored in real-time
through the use of kernel-level auditing. Kernel-level auditing usually
provides improved performance (especially for large file sets) as well as a
more detailed data output.
The most obvious advantage of real time monitoring is that all events are
logged as they occur; and the granularity of reporting is not limited by the
scan intervals. Because the reported events are more detailed, they can provide
information that is not available in periodic integrity monitoring. Real time
integrity monitoring is useful if there is a need to track compliance and
change control violations, as well as when crucial datapoints like whom made
the change needs to be known. It can also provide further insights on other
potential indicators of attacks.
What is periodic auditing and integrity monitoring? How do periodic checks apply in log collection?
Administrators run periodic auditing and integrity monitoring by configuring
set intervals to scan the file system. 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, then the checksums are
compared. When a change is detected, an event is generated and logged to a set
file. When logs are generated due to irregular results from subsequent checksum
scans, these are forwarded for further monitoring and alerting.
This method has some downsides. It does not protect a system from file
signature bypass and does not do static anomaly detection. There can also be
gaps in places to run integrity checking within the operating system
environment. In addition, if weak or obsolete hashing algorithms are used, it
opens up the possibility for a hash collision attack (where two inputs strings
of a hash function produces the same hash result). This can be avoided by
enforcing the use of stronger hashing algorithms.
Since the checks only involves checksum monitoring, there is a lack of change
details involved. It is not possible to determine which user account made a
change as the filesystem or registry does not provide such information, as a
result, there may be multiple changes present by different users between scans.
If this is an obstacle, real time file integrity monitoring should be