See How Restorepoint Helps You Remediate After a Network Breach

You see a lab environment set up with Restorepoint managing the same set of Cisco devices synchronized between the two platforms, and Restorepoint is collecting configurations from those devices. On the Restorepoint side, we have set up a simple security policy. In a real production environment, you would use a policy like this to check for things like:

• Insecure plain text passwords;
• Default SNMP community strings; and
• Invalid entries in access control lists.

In this case, I’ve set up a simple rule that does a plain text search for indications that known troublemaker, Michael Bell, has been making changes to our network environment.

As we look at a device, we can see that right now it is fully compliant, as we have not triggered any policy violations. Looking at these configurations we have collected from this device, you can see the check mark in this first column, indicating that configuration is the established baseline configuration for this device. We can see that the router called “Angela” is currently running its baseline configuration and isn’t violating any of our policy rules.

Network Configuration in Restorepoint

We’re going to make a quick change that is going to violate that security rule. We can make this adjustment straight from within Restorepoint, which obviously is not how the change would be made in a real breach situation, but we can use Restorepoint’s terminal features to go directly to the device. We are going to make a harmless change here to prevent any damage to my demo environment. Let’s simply rename the looping interface to indicate that Michael Bell was here.

Now we know that this device is no longer in compliance with our security rules. Because this device has been configured to send notifications to Restorepoint when changes are made, we should momentarily see that Restorepoint automatically detects changes and starts collecting a fresh configuration from the device in real time. Now we can look at the configurations and see immediately that yes, we are in fact no longer running on the baseline configuration. We are running on a new version of the configuration that was triggered by a change that was made and reported by the device. First order of business, we want to know exactly what that change was so we can select the baseline and the new current configuration and then compare the two.

We only want to show the difference between the two and select the running configuration. We can see that this is the old description of the loopback interface. And over here, we have the new ones showing that nefarious hacker Michael Bell has been involved with this configuration in some way. We can also quickly go back to compliance and confirm that now, after the change, this device is no longer compliant with our security policy. We have shown how quickly Restorepoint can detect and identify the changes, and then determine if they have violated any security policies.

Network Configuration in SL1

Next, let’s have a look from within the SL1 platform. How can you see those changes on the ScienceLogic platform? There’s a couple of different things we can look at. Here we see a business service consisting of these same routers that are being managed by Restorepoint, broken into two different groups. And we can see that one of those is green and one is orange, indicating an elevated risk.

What is causing this risk? We can look down here and see our policy compliance violation for the router called “Angela.” But how can we tell that was an unsanctioned or unscheduled change? Well, if we are using the change management features in SL1, we can go to change events and we can see here that there was a scheduled maintenance window or change request for this router, but that was well over three weeks ago. Clearly that is not relevant in this case. That would be an indication that this change is something we need to address. We can also look at it from the context of a specific device.

We can look at the events for that router. And here we see the same thing here, a compliance violation. How do we quickly remedy that from SL1? We can use the tools menu up here in the upper right corner to bring up troubleshooting tools or customized tools for a device. And we will see here that Restorepoint is one of those options. If we select Restorepoint, we automatically will be taken back into Restorepoint to the view specific to that device where we can troubleshoot.

Reverting to the Baseline Configuration

Now what if we want to revert to our established baseline to make sure that our network is clean and secure again? To quickly revert, we simply select the device and the configuration that we need and hit the restore button. I’m not going to do this in my demo environment. If I wanted to revert this back to the baseline configuration, I would only have to:

1. Select the configuration;
2. Hit the reset after restore button; and
3. Select okay.

And if I were to do that, the process would immediately begin in the background to push the baseline config back to this device. Up until this point, we’ve seen how quickly Restorepoint can:

• Identify changes;
• Trigger alerts;
• Send those to SL1; and
• Switch back to Restorepoint for remediation.

But what about prevention? Suppose that our IT security team had indicated to us that they knew that this change was made because somebody, in this case the nefarious Michael Bell, was able to access this system using Telnet instead of a more secure protocol. We can look within the current configuration and quickly confirm that, yes, Telnet is enabled for this. And we could go back to the device and manually make that change to correct that like we did before from the terminal. Suppose we also wanted to check if there were a wider vulnerability in the network? We can go back to the list of devices and do a global search, and we can do that same keyword search input Telnet.

We could very quickly search through the most recent version of all our Cisco devices like this and identify all the devices in the network whose current configuration is vulnerable to this. We could now use the Restorepoint control feature to push a series of commands out to only these devices to automatically correct that on all of them.

In our next blog, we’ll demonstrate how you can minimize MTTR with Restorepoint and SL1.

Learn more about network configuration and change management>