Tripwire Enterprise can gather any number of different kinds of information from a monitored system, such as file and folder changes, registry changes, policy changes, etc. However, cast the net too wide and you can potentially end up with more information coming in than you can react to.
This will lead to important changes (the signal) being lost in a sea of innocuous daily information (the noise). We would like to improve this ratio, so the important information is easy to see and react to.
As we often do, we’re going to start with the dashboard reporting capabilities of Tripwire Enterprise. In here, we can have different dashboards associated with different types of information, such as approved vs. unapproved changes across groups of systems, certain types of changes that are of particular importance to me or that may indicate a breach, and reports showing my compliance level with particular policies like
HIPAA or
PCI.
These dashboards allow me to quickly tell where I have changes that I need to take a look at and help me prioritize my time spent in the Tripwire Enterprise console. Being able to see that we have unapproved changes from the night before or that a new executable has appeared on a system will help guide where my attention should be focused.
However, these dashboards merely reflect the data that we’re gathering in Tripwire Enterprise. To use them to their fullest, we may need to do a bit of tuning to our rules and policies. This can be especially true when running custom rules or policy tests that look at home-grown applications or important file shares.
This applies mostly to file system rules that look at files or folders, as that’s where the majority of noisy changes come from in my experience but there are ways of tuning other rule types, as well.
For a file system rule, there are a few things that we can do to cut down on the number of things that we need to manually look at every day. Some easy wins can be a ticketing system or CMDB integration, or using Tripwire Dynamic Software Reconciliation. Let’s talk about the ticketing system integration first.
If your organization has a
change management process that involves some sort of ticketing, then that’s a prime source of approval context for Tripwire Enterprise. When Tripwire Enterprise finds a change, it can query the ticketing system to see if there’s something that covers it, such as a ticket that has been approved, is in a work state, applies to the endpoint in question, and is within the stated timeframe.
If we find such a ticket, then the change can be approved using that ticket number as the approval identifier. Obviously this works best when the change management process is rigorous and followed consistently.
The other thing I mentioned, Tripwire Dynamic Software Reconciliation, is an add-on to Tripwire Enterprise that automatically promotes changes made by system patches being applied. It reaches out to the authoritative source of the patches, grabs the file manifest of all available packages, and creates a small database.
We then compare changes found in Tripwire Enterprise to those manifests, and if a match is found, we know that the change is because a particular patch was applied and we can approve it with that patch information.
However, those solutions won’t cover all changes, and many organizations may not have a change management ticketing system to reference. In these situations, there are still many things we can do. The first thing to decide is “Do we need to monitor these files in the first place?” It could be that we’ve cast the net slightly too wide and we’re gathering things we just don’t need to see.
This could be log files, temp directories, etc. If that’s the case, then we can adjust the Tripwire Enterprise rule to skip those. We can do that by changing our Start Points in the rule, maybe adding one or more Stop Points to stay out of certain directories, or using a filter on a Start Point to exclude certain filename patterns like *.log.
If it’s decided that those files and folders still should be monitored, we have a couple of options. The first is to adjust what attributes of those objects we’re monitoring. Perhaps the file is constantly being written to, so monitoring the file size or hash is always going to show a change.
Well, what if we can ignore those attributes and only monitor the permissions and ownership info of the file? This can still give us useful information about the secure configuration of the system without drowning us in change data.
The other option in this scenario is to auto-promote the changes based on certain criteria. We call this a Business-as-Usual workflow. I have certain files and folders that I must monitor for security or compliance reasons, but I don’t want the changes to show up on my reports unless they deviate from what I’d normally see.
This can include things like which user account made the change, what time the change occurred, what attributes changed, etc. I can use actions to look for those criteria and evaluate if they are what I expect before promoting the change or perhaps sending an email if they don’t. Business-as-Usual workflows can be implemented in a number of different ways and are a topic I could spend way too much time talking about by themselves.
Now that we’ve talked about how to filter or auto-promote changes that we don’t need to see, let’s talk about how to prioritize those that I do need to see. This is where severity levels can come in handy. Each rule in Tripwire Enterprise has one or more severity levels associated with it.
For a file system rule, each start point can have its own severity level. This is a number from 0 to 10,000 that gets associated with a change found by that start point. These severity levels are user-definable in the console and in the rules.
What this means for us is that we can use these levels to color-code and prioritize different changes found by different rules, letting us see at a glance what changes we need to look at first. This also gives us one final way to cut down on how many changes we’re presented in reports, and that’s to change the associated severity level to zero.
Unless configured otherwise, Tripwire Enterprise reports will ignore changes with a severity of zero, effectively filtering those out.
The final thing that I want to talk about today is the ability to react automatically to certain changes. This can mean many things, from sending an email or a syslog message to running a script if certain criteria are met.
I touched on this a bit earlier when talking about Business-as-Usual, as this uses Conditional Actions to look for known attributes of an acceptable change before using a Promote Specific Versions action to promote those changes that match. We can also trigger a reaction based upon a change causing us to fail a policy test.
In summary, we’ve covered some potential methods for cutting down on the amount of noise in your environment, and we hope that you have some ideas of your own for things to implement in your organizations. Things such as filtering out unnecessary changes, auto-promoting of known changes, and targeted responses and reactions with information going to those that need it only when they need it.
You can watch the webcast, "Avoiding IT Crisis Fatigue" below:
https://www.youtube.com/watch?v=_z3BzahCWAA&feature=youtu.be
