Learn Effective Policy Compliance Management with Restorepoint
In the two previous blogs from this series, we showed you how Restorepoint enables you to minimize MTTR to mitigate the impact of change management and remediate after a network breach. The third and final blog of the series walks you through policy compliance management—demonstrating the value of creating a single pane of glass where you can see all relevant information from a single location.
Today we will be doing a deep dive into policy compliance rules to really show the power and flexibility of that system within Restorepoint. Here is that simple security rule, just checking that the plain text string, Michael Bell did not occur anywhere in the config. You can do quite a bit more than that.
First off, the things you match against can be plain text phrases or regular expressions. We are using ProStaR regular expressions for pattern matching, which can be quite sophisticated in themselves. And for even more advanced matching, we can use script written in the Lua language to do things like looping over interfaces or sections of the configuration doing advanced conditional logic and so forth.
Between those things, anything able to be scripted can be configured as a policy compliance check. We didn’t do anything with specifying remediation, but you have the option for any policy rule to specify what the remediation is for violating that rule. And that can range from just a manual text phrase where you are just telling the person looking at this what needs to be done. If the rule is a lower script, it can be filled out programmatically with exactly the commands that need to be executed to fix it. Or it can be a link to a pre-established and saved command script that can automatically run on the device.
Depending on the exact requirements, we can simply flag policy violations as alerts and send them to systems like SL1, or we can automatically run scripts or apply templates to correct the problem.
Policy Rules for Schedules Commands
In addition to that, you’re not limited to only applying policies to configurations. That’s what we’ve done so far in these demos, but you could also do policy rules against things like the output of scheduled commands. You could have a series of commands that you want on a schedule to do things like:
- Checking the file system;
- Looking at the routing table of devices; or
- Anything else that can be done as a scheduled command.
And you can apply policy rules to the output for that. Between those two, looking at configurations and scripted outputs, a tremendous number of things can be checked for in these policies. And again, sending that information to SL1 makes it possible for you to see exactly which devices are currently in compliance or out of compliance with your policy.
Assessing Device Compliance Policies
To see which devices are in or out of compliance, we can do that with both Restorepoint and within SL1. Looking at it from within Restorepoint, we can quickly group the list of devices by compliance status. We can see immediately which devices are currently failing, or don’t have any compliance or any policies applied, and which ones are passing. Hopefully, in a production environment, you would see something very close to the opposite of this.
In SL1, we can take that same information and bring it in to a dashboard, where we can see a summary of all the devices known to Restorepoint. And for each one we can see what their current policy compliance is and whether that device has currently been backed up. This makes it easy to bring your dashboards, reporting and ticketing systems in from SL1, which is all the relevant information about device and compliance status coming from Restorepoint. This makes it easy to have that single pane of glass where you can see all relevant information from a single location.