Over the last few years there has been an increasing trend towards managing configuration as code (CaC) as NOC teams look for ways to reduce the risks associated with their networking practices. This methodology is now fundamentally changing the way that organizations manage and deploy their IT infrastructure.

Using CaC means that rather than updating and changing the configuration on a live device, a copy is taken instead. For example, rather than editing the configuration of a router, switch or firewall, directly on the device, a copy of that configuration can be taken and edited instead.

This copy of the configuration can be treated in the same way that a piece of code might be. This way configuration changes can be tested out in an offline environment before they are carried out on the live device.

By treating configuration files as code, teams can leverage version control, automated testing, and continuous integration practices to ensure consistency, reliability, and scalability across their environments. This approach not only reduces the risk of human error but also enhances collaboration among development, operations, and security teams. As a result, CaC has become a cornerstone of modern DevOps practices, enabling faster, more efficient, and more secure deployments.

It is a mindset shift which has several benefits including:

• Consistency and reliability
• Version control
• Traceability
• Disaster recovery

By taking this approach, you can create a ‘digital twin’ of the live configurations. In this case, the digital twin is an exact replica of the running configurations, stored in a repository. In essence it is a replica of the network devices' configurations.

Benefits to NOCs with CMDBs that enable a digital twin

For NOC teams, there are many benefits from having a digital twin of their configurations within a git-based repository. It's good networking practice to take the running configuration at periods of time and take it away from the device and store it somewhere secure. But using a git repository (or a CMDB with similar capabilities) can have other benefits for the NOC team.

Incident recovery with a digital twin of network configurations

Firstly, it can help speed up disaster recovery from operational incidents. Having an up-to-date copy of the configurations for routers, switches and firewalls on the network, gives a quickly accessible backup.

Say, for example, you have a firewall which protects many applications, accessed by many users. If this goes pop –and it’s not malicious activity, it’s just broken.

The hardware can be replaced, and cables plugged back in. But that configuration has disappeared. Having a backup means that the configuration can be restored as easily as the hardware.

But it might not just be a firewall going pop – there could be an incident where 2,000 users are saying they can’t access their application. This could have been caused by someone making a mistake - reconfiguring the access control list on the firewall or redoing the firewall rules in such a way that means the users no longer have access to the application they need.

Treating configurations as code and choosing something like a git repository to keep them in means that if this happens, you can look at the change log within git. This may show that someone recently updated the firewall configuration.

You can quickly see that this might be the cause of the incident and easily roll back to an earlier, working version of the configuration. Or you might see that this change was correct, and these users had been doing something that they shouldn’t have been able to.

Incident prevention with network configuration testing

In the latter example above, having a digital twin of configurations would allow NOC teams to roll back changes that had a detrimental effect. With the configuration as code approach, changes can also be tested before they go live.

With a digital twin of the configurations, you can make the changes and then test in an offline environment to make sure that the changes work as intended. You could create as many branches off the live repository as you need to try out different variations of configurations, and then when you are happy sync one of those branches back to the live configurations and make the changes.

This gives the ability to test in a sandbox-type environment where any errors don’t affect users or create vulnerabilities or misconfigurations in the live environment.

How digital twins are supported in Nipper Enterprise

Nipper Enterprise does not require the live device to assess the configurations and instead can be synched to a git repository or to a branch of that repository. The configuration collection layer within Nipper Enterprise can also be used to auto-populate and maintain that configuration repository.

When a populated configuration management database (CMDB) that contains the live configurations has been created, Nipper Enterprise can then run assessments of those configurations and provide reports on where there are any vulnerabilities or misconfigurations.

But it is not just the live configs that can be tested. With git-based repository, a digital twin environment can be created, with copies of the configurations. The configurations within these digital twins can be edited and updated without affecting the live configurations. And you can create as many branches, and variations of that configuration repository as you want. Nipper Enterprise can then sync to any of those branches and test the changed configurations. This can show if these proposed changes introduce any vulnerabilities or misconfigurations – ahead of rolling them out to the live environment.

How Nipper Enterprise supports config as code practices

By using Nipper Enterprise to test changes to configurations using a digital twin, any vulnerabilities or misconfigurations can be identified before that configuration is applied to a device in a live environment. For the NOC team, they will know that these changes will be secure.

However, humans can make mistakes, and these mistakes can result in misconfigurations, even with changes that have been tested prior to deployment. Nipper Enterprise, using the configuration collector to populate the CMDB of the live environment, will detect when a change has been made to a live device. It will then proactively trigger an assessment to assure the device maintains a secure state, giving confidence that the proposed change has been made correctly on the live device and the live device remains secure and compliant.

To learn more about how Nipper Enterprise can support configuration as code practices, request a demo.