Configuration Policy Validation

Terry Slattery
Principal Architect

My previous post NANOG Posting on Configuration Analysis talked about the basics of verifying a configuration prior to deployment as a way to minimize the number of incorrect configurations that are fielded.  The second topic, which is closer to the original NANOG posting comments, is with respect to auditing existing configurations to make sure that they match your organization’s policies.

Organizational policies originate from multiple sources:

  • regulatory policies such as SOX, PCI, HIPAA, GLBP, etc;
  • industry best practices such as placement of root bridge, MPLS design parameters, security, and ARP and CAM timers;
  • organizational policies including address ranges for loopbacks, device naming, redundancy configuration, and additional security.

The figure below shows how policies are typically implemented.  It generally starts with a text document of some sort that describes the policy and its intent.  The next step is to turn the policies into device templates.  These templates are for each device type and its intended role in the network.  For example, a 6500 that’s a core device will have a different configuration than a similar hardware platform that is deployed in a distribution or access layer role, resulting in multiple templates for the same/similar hardware.  Once the templates are created, the per-device configurations are created, including specific IP addresses, VLAN definitions, routing neighbors (if needed), etc.  These final configurations are installed on the hardware.


Configuration audit, or validation, has two major functions.  The first is to verify that the fielded configurations match the templates that are derived from the policies.  Validation will detect unauthorized changes or deviations from defined policies, proactively allowing the networking team to correct the configuration before a problem occurs (like failing a SOX or PCI audit, or having a security breech occur).  Such validation processes also help organizations more easily pass SOX or PCI audits.  It makes the auditor’s job easier when you can point to your policies, templates, and process for verifying that the resulting configurations are correctly deployed across the network.  It also helps significantly if you can point to specific exceptions to the policies.  There are always exceptions and it it helpful to be able to easily identify them to the auditors and be able to explain how they do not impact the integrity of your network.

The second purpose of doing configuration validation has more to do with changes in policy.  Let’s take a simple case where you changed the location of your DNS server or your NTP server.  All your routers and switches will need to be updated to reflect the new server locations.  Many organizations take a snapshot of their device inventory (assuming that they have an accurate inventory) into a spreadsheet and assign someone to make the configuration changes.  If other changes are happening in the network (device move/add/change/delete – MACD), then the spreadsheet list is soon out of date.  The combination of a device list and MACD work means that there’s the possibility of a device being missed in the shuffle.  However, with a good template, it is easy to verify the configurations of all devices known to the system against that template.  A good auto discovery is essential to having an up-to-date inventory so that no devices are missed.  Any configurations that don’t match the policy for whatever reason, will be identified.  This now becomes the check-list of devices that need a configuration update.

Even better, is to have a system that when a simple policy is incorrect, it can automatically update the configuration.  A good example of this is updating NTP or DNS server addresses.

Some network staff members are reluctant to use automated tools because they think it threatens their job.  But I’ve never met anyone who likes the incredibly boring job of applying a simple configuration update across hundreds of devices.  Using automated tools allows the network staff to tackle more interesting jobs.  And with the right tools, you can make the network more reliable, allowing you to spend more time on interesting network upgrades.



Re-posted with Permission 

NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under


Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.