Image
“FIM – that’s going to produce a lot of alerts and could be noisy.”My general response to this is, “not at all.” Like all enterprise applications, if configured correctly and integrated efficiently with other technologies, there shouldn’t be a lot of alerts. The first step in file integrity monitoring is controlling what needs to be monitored. There is no practical reason to monitor every file on every device or application all of the time. The solution should provide a robust rules-based way to control which files are monitored for change and to what level they are monitored. Therefore, focusing on the important files, registry keys and configuration files should not generate a high change rate. To help reduce the alerts, the solution should integrate with a service management solution, so that any changes can be reconciled against a change management system, promoting the changes that have been authorised. But as the title of this article suggests, there are more levels to integrity monitoring than just file systems. First of all, let’s define what the endpoint is. We know file systems, like your servers and desktops, are good examples of an endpoint, but how about services such as databases or directory services such as Active Directory? They contain information and data that is subject to change. For instance, in Active Directory, administrators can add and remove people from groups. Some of those groups could be restricted groups, or groups that protect sensitive information. Being able to monitor changes in Active Directory and other directory services would enable the detection of potentially any change in any attribute. For example, if we monitor for membership changes in AD, we could identify who gets added or removed from the group and, equally important, who made that change. Integrate this change detection with a service management solution and we could potentially start to identify those unauthorised changes by people who are circumventing controls. Databases are an interesting endpoint to monitor for changes. I get asked from time to time, why would I want to monitor a database for changes? It’s a good point. By design, databases are designed to store structured information and have the potential to dynamically change a lot, therefore monitoring content changes could lead to a high number of alerts and false positives, which is what we want to avoid. My response to database monitoring is to take a different view on how we monitor a database. There may be some databases whose content does not change much at all, and you would want to monitor for content change. But how about the database schematics? The structure and design of the database. Does that change often? One of my favourite use cases for database monitoring is to look at the permissions or the access control lists to a database or table. This attribute should not be changing much at all. For example, you may have a database set up, and the only account that has access to it would be a dedicated application ‘service account’ in Active Directory. Wouldn’t it be useful if we could use our Integrity Monitoring tool to inform of a change to the permissions, owner, or access control list of this database or table? It could be a legitimate change, or it could be part of an elaborate attempt to compromise information from the database itself. Virtual Infrastructures is another key area to integrity monitoring. We are not talking about the guest operating systems themselves; we cover that with FIM. I’m referring to the host system that manages the virtual systems. The host, whether it’s ESXi, vCenter etc., contains specific machine configuration of each virtual machine. So, if a new Virtual Machine was created or changes were made to an existing virtual machine, such as RAM relocation, our integrity monitoring tool would be able to detect those changes and report or alert on it. Last, and by no means least, there’s the network devices themselves, such as routers, switches, firewalls, etc. These devices contain critical information that help secure and maintain the corporate network environment. Unauthorised changes in these could lead to compromise, network outages and misconfiguration. With our integrity monitoring tool, via a CLI (Command Line Interface), we could pull baseline configurations, access control lists, firewall lists, and many other attributes from these devices and then compare any changes against the baseline. A good use case is to report on what firewall rules were changed the night before. Not only would this show you that there was a change, but it would also detail what the change was, giving you a side-by-side comparison that would help you get back to that ‘known good configuration’ state. Before we summarise, though, there is one more area that I tend to talk a lot about with our Tripwire Enterprise solution. This is where I ask customers to think differently when it comes to detecting changes on the endpoint. Tripwire Enterprise has a feature called COCR rules, which stands for ‘Command Output Capture Rules.' The possibilities for this are potentially endless. We could run a script or command on the endpoint and capture the output. For example. on a Linux server, if we run the command ‘rpm –qa | sort’, it will return a full list of installed RPM packages on that server. When we run the COCR rule again, we can see if new packages have been added or old ones have been removed. In conclusion, a good integrity monitoring or change detection solution can help detect unauthorised changes on the endpoint, whether it’s a malicious file dropped on a critical server or an admin adding an unauthorised user to a restricted Active Directory group outside of change control. If you are interested in learning more about purchasing a good integrity monitoring product, please read our Security Configuration Management Buyers Guide. Alternatively, you can learn more about how Tripwire Enterprise can improve your business here. If you are in London for March 7, you can catch my talk at the World Cyber Security Congress titled, “Fifty Shades of FIM – Uncovering the True Intent of File Integrity Monitoring.” To find out more about the event, click here.
