Tripwire file change monitoring

Software programs change. Configuration states change. Organizations commonly respond to this dynamism by investing in asset discovery and secure configuration management SCM.

Even so, companies are left with an important challenge: reconciling change in important files. For that challenge, many enterprises are turning to file integrity monitoring FIM. FIM is a technology that monitors and detects file changes that could be indicative of a cyberattack.

Otherwise known as change monitoring, FIM specifically 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.

File integrity monitoring was invented in part by Tripwire founder Gene Kim. From there, it went on to become the security control around which many organizations now build their cybersecurity programs.

Unfortunately, for many organizations, FIM mostly means noise that complicates the work of security personnel.

Too many changes, no context around these changes, and very little insight into whether the changes actually pose force security teams into a position where they need to investigate which changes relate to one another. In the process, these professionals could waste their time looking into false positives, thus contributing to a sentiment of alert fatigue that leaves organizations exposed to data breaches and other digital threats. This highlights the reality of FIM. It is a critical security control, but it must provide sufficient insight and actionable intelligence for organizations to augment their security postures.

To complement the phases described above, organizations should look for additional features in their file integrity monitoring solution. The solution should also come with total control over a FIM policy. The usual trade-offs apply. If you pay for it, Tripwire does most of the hard work for you, and all you have to do is pay attention to the reports. If you implement Tripwire yourself, then you get to set it up and configure it on your own.

On RHEL 8, you must enable the codeready-builder option in subscription-manager :. Before configuring Tripwire, you should set a hostname for your server if it doesn't already have one. Hostnames are a frequent point of confusion, so read my article about setting hostnames to make sure you're clear on what you're setting. Next, you must generate encryption keys for Tripwire.

After all, the point of Tripwire is to prevent attackers from covering their tracks, so Tripwire data must be strongly encrypted. In both cases, you must provide a passphrase for each key. Keep these passphrases private and safe! Tripwire uses two different keys for encryption: the local key, which is unique to each server, and a site key, which you can use across all systems within your organization.

The site key is an important feature because it enables an IT manager to dictate a single security policy for the organization, and it can be updated centrally, signed with the site key, and then distributed with Ansible or scp for use on every server.

Each server admin still has a unique local key, though, so even though the security policy file can't be changed, they can still access Tripwire for updates and reports. Next, you need to create a basic configuration file for Tripwire. By default, Tripwire uses sendmail to email you alerts.

If you're using postfix , there's no need to change it, however, because postfix provides sendmail aliases. Also defined in the config file are the locations of your encryption keys and policy file, so verify that those are correct.

Signing the configuration file requires the passphrase to your site key. The policy file is where you put in most of the work for Tripwire. Your Tripwire policy dictates which files to monitor and which to ignore, and which lie somewhere in between. Both extremes are equally important. If your daily Tripwire reports send a false positive for every single user file that changes throughout a workday, then you'll quickly learn to ignore your Tripwire reports altogether.

You must customize it for your system unless you're running a full install of Fedora Workstation, but reading it helps give you an idea of what a standard policy file contains. To decode the Tripwire notation, review the twpolicy 4 man page. Policy files can be complex, and it might help to think of it more like a Sass or Makefile than a configuration file. Otherwise known as change monitoring, FIM specifically 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. File integrity monitoring was invented in part by Tripwire founder Gene Kim. From there, it went on to become the security control around which many organizations now build their cybersecurity programs.

Unfortunately, for many organizations, FIM mostly means noise that complicates the work of security personnel. Too many changes, no context around these changes, and very little insight into whether the changes actually pose force security teams into a position where they need to investigate which changes relate to one another.

In the process, these professionals could waste their time looking into false positives, thus contributing to a sentiment of alert fatigue that leaves organizations exposed to data breaches and other digital threats. This highlights the reality of FIM. It is a critical security control, but it must provide sufficient insight and actionable intelligence for organizations to augment their security postures.