What I’ve found throughout the years is that the only constant in life is the fact that everything changes and changes frequently. I can’t even get a consistent scenery on my way to work longer than a couple of weeks before something is different!
At the same time, the world of technology is in constant flux whether it’s new technology or updates to automated tools that interact with all sorts of servers or services running throughout an environment. In this sea of changes, how do you know what the important changes are?
I think everyone will agree that tracking changes is nothing but a good thing. But getting inundated with all the noise is a very real possibility. I’m going to therefore define what I view as the three levels of change to help filter through all the white noise to really get down into the action.
Level #1: Is It Approved?
The first level of change will be around if the change is approved. Is the change coming from an expected business process? There are various ways you can determine whether a change is approved.
One of the best ways is to reconcile the changes against an existing change management process by leveraging work already to approve changes, while at the same time validating only approved changes are occurring.
There are other indicators that can be used to know whether a change is part of normal business operations, as well. For instance, you can compare the changes to a manifest from Microsoft for Patch Tuesday. In this instance, if the change matches what is to be expected from a patch, then you know it will be expected and better yet will allow you to capture unexpected changes that happen at the same time as the patching.
Each environment is different, and the knowledge of the system owners can be used to tune change alerting to collect but not notify on things which they know will be benign like a file that changes every day through a windows process.
Testing work in a staging or QA environment can also be re-used for production by referencing the test changes that are approved when the production deployment happens or if software such as Puppet is being used to deploy then changes from the Puppet service account would be expected. As a result, only changes that aren’t expected would be flagged.
Level #2: Is It Good?
The second level of change is analyzing the change to know whether it’s good.
There is a distinct difference between an approved change and a good change. For example, someone could have a ticket in hand giving approval to install telnet onto a production webserver for troubleshooting. However, would you call installing telnet good even through there is a change ticket for it?
The definition of “good” could be from something like a hardening framework such as NIST or ISO, or it could be a unique internal business requirement such as making sure all NTP servers are consistent across all servers. We need to be extra vigilant and careful when applying these definitions for the cloud. Just as an example, would you be able to quickly tell if a configuration change put your confidential information stored in an S3 bucket to become public?
Level #3: Is It Malicious?
Being able to check the executables being added against a known malicious database is crucial for catching files that are known to be a threat. However, known threats don’t help against zero-day attacks, so choosing a malware analytics tool that can detonate executables in a sandbox to analyze never before seen executables is an important consideration.
Using Tripwire to continuously monitor for these three levels of change will help protect your critical infrastructure from misconfigurations and zero-day attacks, and it will allow you to focus on the actionable changes rather than trying to swim through an upstream current of noise.