NNT Change Tracker has the ability to capture malicious or breach activity by utilizing a “Change Manifest” with its Planned Change feature. A Change Manifest is a ruleset within Change Tracker that has captured the exact change details of a patch/update that has occurred on a patch testing system.
The power with this utility is that we are able to create a Planned Change Schedule based on a Production Patching Window using the change manifest with this planned change window to mark our patching activity as approved, leaving any malicious or breach activity marked as unplanned with alerts provided in real-time.
- Patch Testing on our Development Server
Here I have a server in my development environment named “NNT-DEV-01” that I’m running a “patch” on. This isn’t necessarily a real patch, but to show a simple example, I’ve taken a screenshot below of some files being moved to a directory that is being tracked. Keep note of the Five update files moved:
- Patch Testing Change Tracker Alerts
After moving these files, we can see five changes immediately appear in Change Tracker. Notice the Device name matches my Development server above as well as the same files going into the directory shown above:
- Creating our Change Manifest for our Planned Change Window
Our next step here is to create a Change Manifest ruleset since we know these are the exact approved changes that we need to see when patching in our production environment. We will first select the changes that occurred during the patch on the Development server by clicking on the small checkbox next and then click on “Actions”. In our dropdown, we will select “Create a new intelligent Planned Change to capture these events”:
A new window will appear for us to configure the Planned Change Name, Devices, Groups, Start/End time. In my example, I've used “November Dev Patching” as a Planned Change name. At the bottom of the screen, we will also select “Perform No Rule Reductions (Advanced)". This is to ensure that we match for the exact changes that we highlight for the Change Manifest:
Once we’ve applied these changes, we can see that the patching changes are now approved and part of our “November Dev Patching” Planned Change:
- Scheduling our Planned Change Window for Production Patching
Typically this next step does not happen immediately as approvals and scheduling is involved. But the next step is to begin scheduling the Change Window in Change Tracker using the Change Manifest we initially created with our Development Server changes. We will navigate to “Settings” > “Planned Change Schedules”. On this page, we will click on the “Actions” button and select “Schedule a Planned Change”.
A new window will appear describing the use of Planned Changes, but on the next page, we will be able to select from an existing Planned Change Ruleset. Here we will select the “November Dev Patching” ruleset, as this will be our previous Change Manifest from when we successfully patched on our development server. Once this has been selected, click “Next” to proceed to further configuration:
The following page will involve scheduling the Production Patching Planned Change window. On this page, we can select the Device Groups, Devices, and Start/End Time. For selecting groups, quite obviously, you will want to select a group that will have all of the production devices you plan to patch. For date and time, you will choose the window that has been approved for the patching to take place in production. In my case, I’ve selected 10 AM EST to 1 PM EST on November 14th:
The next page will ask for a Name/Description of the Scheduled Planned Change. In my example, I simply used “November Production Patching”. You can be more specific by providing Date, Time, Change Ticket Number, Patch Number, etc for future reference.
The final page will show all the configurations made to the Scheduled Planned Change and ask to confirm:
- Patching our Production Environment
Once the Planned Change Patching Window has been configured and confirmed, we will perform the same patch in our production environment during the specified time. The patching will need to match EXACTLY what we have done in the development environment, any changes outside of what we had recorded will be alerted and notified in Change Tracker. Below I have a server in my Production environment named “NNT-PROD-01” that I’m running a similar “patch” on. Note that there is an extra file moved that was not previously specified called “Unknown-File.dll”. This was done to replicate any malicious activity that can occur during a patching window. Not to worry, since we had previously recorded a successful patch to our Change Manifest, using the same Change Manifest in our Production Planned Change Window will capture this malicious change:
- Verify Approved and Unapproved Changes in the Patching Window
Now that the patching is completed, we can go into Change Tracker and view the changes that have been made during our Planned Change Patching Window. By navigating to the “Planned Changes” tab and selecting the “November Production Patching” planned change, we can see the changes that have matched under our Change Manifest ruleset:
Great! The Change Manifest ruleset was able to match the patching files successfully. Now we should confirm if any malicious changes occurred during our patching window. As I only had one device in my example production environment, I should only see 5 changes that were approved. However, navigating to the “Events” tab and setting the filter to the patching window, I can see I have 5 Planned Changes along with 1 Unplanned Change which I’ve highlighted.
In my next screenshot, I’ve changed my Event filter to only show Unplanned Changes to isolate the source of malicious activity. We can see that the file is the same “Unknown-File.dll” we previously moved to show an example of malicious activity. We can see that using our Change Manifest helped us hide the expected changes and let us drill down to any malicious or unverified changes that can occur during a patching window: