Using Compliance Management as a task sheet

It is extremely crucial for a network to be configured in a compliant manner, this can be due to relevant legislation but also to ensure the highest quality of service is delivered. Checks are needed on IT infrastructure assessing whether they are in compliance with rulesets that are implemented. This was becoming increasingly difficult with the scope of IT infrastructure that is now required to maintain strict SLAs, but now those checks can be transitioned from manual to automated.

opConfig has an incredibly powerful compliance engine built into it, that can be used to audit a network and ensure that all devices are compliant to a set of policies. The product ships with the CISCO-NSA best practices as the default compliance policy set, but adding your own custom policies is extremely easy to do. The Community page has all the resources you will need to create your own policies or editing some existing policies (located here).

However, the focus of this brief is what to do with the information that is provided once these policies are in place. There are two key ways to process this information and get your network back to being compliant depending on how many devices are required to fix.

The first is usually used if you have inherited a compliance problem, through mergers and acquisitions, for example, where a large number of devices are not compliant. The best process for this instance may be to push out new config to all devices. This can take longer than single item fixes but there is the knowledge that each device will be configured to the same baseline. Configuration pushes has been explained through our Community page and outlines a terrific example also (located here).

This leads to the most common occurrence where small changes to a device have been noted by the auditing system. The compliance report can be automated to be run each morning before a team’s scheduled start time and generate a report of devices that are not compliant. A lot of network engineers will use this as a task sheet for the day/morning, the report on one monitor and the required CLI on the other. As they have completed tasks their environment will become more compliant and the service levels will be increased.

The outcome of the report can be seen above. This exemplifies what the opConfig compliance engine will look for. The hit/miss category refers to the policies that are tested. If there is a configuration point that is testable for the policy this will result in a hit. If there is nothing available there will be a miss (note that a hit or a miss doesn’t imply there is a fault, it’s detailing a successful testing protocol). The second column refers to Exceptions and OKs, an exception will require changing configuration on a device, OK denotes that the device is acting in accordance to how the policy requires.

If you would like more information on these topics, navigate to the community forums in the links above or contact us using the links below.