Change is prolific in organizations’ IT environments. Hardware assets change. Software programs change. Configuration states change. Some of these modifications are authorized insofar as they occur during a patch cycle; some cause concern by their unexpected nature.
Organizations commonly respond to such dynamism by investing in asset discovery and secure configuration management (SCM). These foundational controls allow companies to track their devices and monitor those products’ configurations. Even so, companies are left with an important challenge: reconciling change in important files.
For that challenge, enterprises turn to file integrity monitoring.
Otherwise known as change monitoring, file integrity monitoring (FIM) is a foundational control that involves examining files to see if and when they change, how they change, who changed them, and what can be done to restore those files if those modifications are unauthorized. Companies can leverage the control to supervise static files for suspicious modifications such as adjustments to their IP stack and email client configuration. As such, FIM is useful for detecting malware as well as achieving compliance with regulations like the Payment Card Industry Data Security Standard (PCI DSS).
There are five steps to file integrity monitoring. These are as follows:
- Setting a policy: FIM begins when an organization defines a relevant policy. This step involves identifying which files on which computers the company needs to monitor.
- Establishing a baseline for files: Before they can actively monitor files for changes, organizations need a reference point against which they can detect alterations. Companies should, therefore, document a baseline, or a known good state for files that will fall under their FIM policy. This standard should take into account version, creation date, modification date, and other data that can help IT professionals provide assurance that the file is legitimate.
- Monitoring changes: With a detailed baseline, enterprises can proceed to (Read more...)
This is a Security Bloggers Network syndicated blog post authored by David Bisson. Read the original post at: The State of Security