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 files.
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.
PCI DSS 11.5, 12.9
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 – Encryption.
Critical Security Controls
Implementing FIM can help checking that critical system files have not been altered, as is required by CIS.
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.
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 implemented instead.
Auditing on various operating systems is important as it provides data on file/ directory access and changes. The crucial element is determining what critical files should be monitored and what system auditing should be deployed on them. The list of systems to be monitored for FIM may and should include; Servers that deal with authentication and/or authorization such as Domain Controllers, PKI servers, Application Servers, Database Servers, Web and DNS Servers as well as key staff desktops engaged in critical business functions. Furthermore, all systems in scope for any PCI DSS network including POS should be subject for auditing.
The NXLog Enterprise Edition offers the File Integrity Monitoring (im_fim) module for all supported platforms. By utilizing this module, administrators can use file integrity monitoring as part of their overall log collection strategy. With this module, IT professionals can easily add a potential list of file locations to monitor for. Sources of files, may be included from both, outside sources and from the organization’s own internal needs.
As an addition to file integrity monitoring, the changes of critical Windows Registry hive keys must be monitored as well. The Windows Registry Monitoring (im_regmon) module from NXLog provides the solution to monitor the required list of critical Windows Registry hive keys for changes. In frameworks such as the MITRE ATT&CK Framework, hive keys are typically targeted for changes (depending on the malware). Additional rules are available for FIM and RegMon to test and use with NXLog.
While FIM is a key element of IT Security and compliance, it is important to be aware that FIM on its own does not provide crucial details, such as the user identity that initiated the change. By using NXLog, these details can be easily obtained from the OS/kernel since all operating systems have auditing capabilities that NXLog supports natively.
On Windows, administrators can enable the correct audit policy for specific events via Group Policy, then collect relevant Windows events using the EventLog for Windows 2008/Vista and Later (im_msvistalog) module. Collecting Sysmon logs can also be used, as it detects changes in file creation time to understand when a file was really created. Modification of file create timestamps is a technique commonly used by malware to cover its tracks. On Linux, the Linux Audit System (im_linuxaudit) module can be set up to collect audit logs, similarly, on AIX systems the AIX Auditing (im_aixaudit) can be used for the same purpose. In addition, the Basic Security Module Auditing (im_bsm) and (xm_bsm) modules can be utilized on other Unix platforms for auditing. NXLog recommends to take advantage of both file integrity monitoring and auditing for a more thorough log collection and monitoring approach in your enterprise. Feel free to download the trial or contact us if you have any questions on how NXLog can help your business.