Why have I not yet implemented File Integrity Management (FIM)?

FIM is a critical element to a data loss prevention (DLP) program

If you have not yet deployed FIM perhaps now is a good time to ask “why not”.

If your organization is now addressing data loss prevention (DLP) by minimizing the risk of damage by malicious code and by enforcing strict access controls to mitigate unauthorized access, then FIM is something you might also want to consider.

FIM is essentially monitoring all aspects of changes to key files to quickly detect any attempted or successful unauthorized changes, in order to take quick mitigation steps.

In the terms of reference of this blog, the main concern addressed by deploying FIM is to ensure that malicious code has not been embedded within critical applications and operating system files. Current concerns are for botnet or other large scale intrusion attempts to install Trojans including rootkits.

Just to be thorough, file integrity breaches can be caused by all manner of problems within file management lifecycle, such as transmission errors, software bugs, storage errors, write errors, and by incorrect change management procedures.

The important changes integrity monitoring should discover relate to:

• File size

• Version

• When it was created

 • When it was modified

• The login name of any user who modifies the file

• Its attributes (e.g., Read-Only, Hidden, System, etc.)

• When group ownership of files is changed.

• Improper user access or attempted access of confidential files

• Changes to security access permissions for files, including new permissions, deleted permissions, and changes to permissions.

• Changes to directories

• Files and folders that re moved and added The types of files of concern include:

• Key data files (Typically stored as alphanumeric and special symbols as ASCII files.)

• Database files.

• Web files.

• Video and audio files.

• System binaries (These are typically executable versions of programs stored in machine readable format consisting of “0”s and “1”s.

• Configuration files (When a program executes, it refers to the configuration file what settings are in effect. These files are sometimes stored in the systems registry, which is part of the guts of an operating system. The registry is essentially a database used by the operating system to store configuration details)

Delving into more technical detail on the registry subject, the following other types of changes could / should be monitored with regard to registry values, keys, and subkeys are: • new registry keys and subkeys,

 • removed registry keys and subkeys

• changed registry values.

• This detection ability includes changes to normally hidden registry keys such as the SAM and SECURITY keys.

FIM Compliance with IT Security Standards

Several security standards also require a file integrity monitoring and management program in order to achieve compliance. Some of these standards are:


Table R15 15. 1 Limit propagation of malicious code

Table R15 15.2 Detect and respond to the introduction of malicious code

Table R15 15.3 Implement processes to test and update malicious code protections.


SI-4 Information System Monitoring

SI-7Software and Information Integrity

PCI –Data Security Standard

10.5.5 Use file-integrity monitoring

11.5 Deploy file-integrity monitoring software

SANS Consensus Audit Guidelines (CAG)

3.5 integrity checking tools and change management

3.7 integrity checking tools

So the bottom line of FIM is to ensure that during the course of regular business which includes changes to files, the files always remain in a known and trusted state. I’ve run out of space for today. Next blog I’ll cover how FIM works and where to search for vendors that provide related tools.

Have a secure week.    Ron Lepofsky CISSP, CISM, B.A.SC (Mech Eng) www.ere-security.ca

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2011 IDG Communications, Inc.