Network Source of Truth

What if you went to the store to buy a saucer for every cup you owned, only to realize that you don’t actually know how many cups you have?

I can’t tell you how many times that’s happened with BackBox customers… but with network equipment not cups. They implement BackBox only to find that they didn’t have a correct inventory of their network devices.

Sounds crazy, because how can you secure your network devices if you don’t even know they’re there? Crazy, maybe. Surprising, not at all.

A network source of truth

A network source of truth, a system that helps you KNOW exactly what devices comprise your network, is critical to securing and operating any network at scale.

BackBox can operate as a network source of truth, and in fact, that’s language we’ve used for some time. So it got me thinking what are the critical components that make it such?

3 keys capabilities required by a network source of truth

1. Discovery. The first step is device discovery. Makes sense, you want to know what devices are on the network. With BackBox you can discover devices by entering a range of IP addresses to search, and the discovery job can run regularly to pickup any newly added devices. However, discovering devices is not enough.
2. Device Modeling. Modeling devices is the critical piece that many overlook. It’s not only knowing what devices are on your network but also having a deeper inventory into devices specifics and how they’re configured. Together with discovery, modeling enables network administrators to know what devices are on the network and learn a lot about those devices. But, if that information stays within BackBox it’s only a partial win.
3. API for Connecting to External Systems. Once you’ve got an accurate inventory, other systems within the organization can be tapped to accelerate automation. A simple example is automating ticket creation and enrichment in an ITSM like ServiceNow. This is especially important for Service Providers who are managing multiple customers and for whom automatically opening tickets and getting device data into those tickets can save tons of time both when opening a ticket, and when working on a resolution.

An example – Network Vulnerability Manager

We’ve recently launched Network Vulnerability Manager (NVM) to help network administrators work on the vulnerabilities that most put their network at risk.

This product is only possible as an extension to our core product because of the three points above. NVM uses the inventory and device modeling to map against a database of network vulnerabilities and risk intelligence to come up with a set of actions that administrators should take based on their own network device makeup.

A dynamic, accurate inventory also makes a product like Network Vulnerability Manager more powerful. This is important because taking advantage of such an inventory in your organization improves the way network teams integrate with the rest of the IT stack and processes.

Final note

This article was inspired by a recent Gartner piece titled “4 Steps to Scale Network Automation” published on June 12, 2023 by Ted Corbett (Doc ID G00788696). If you’re a Gartner client, go check it out.