IP Fabric at Cisco Live!
5 minute read
Ensuring your network is secure as you intended (3/3)
Updated: March 13, 2023

Ensuring your network is secure as you intended (3/3)

In my past two blog posts in this series (Part 1, Part 2), I called out very specific security use cases for IP Fabric. Today I’m going to take a different approach and talk about two very common - or dare I say it -pervasive problems.

  1. Configuration Compliance
  2. OS Version control and standardization

My first exposure to OS version control was leading up to the year 2000 with the so-called y2k bug. I spent days connecting to routers doing show vers to see OS version and installed memory. After checking this, I usually had to install memory before upgrading to IOS version 11. x.

That was the good old days - at least I usually knew exactly what I was going to break when I took the router out of commission.  I was also new to my career back then and was often excited about the new ways of doing things and did not always consider the consequences of my actions. At about the same time, I was fiddling around on a large bank's network (as a consultant) and I saw Netbios traffic. I was fully aware that it shouldn’t be there, so I helpfully updated the config on several routers and firewalls (yes, for those of you not old enough to know, Microsoft used to need that little protocol for communicating). I inadvertently broke the bank because I didn’t follow a standard and didn’t know what I didn’t know.

Today I am less adventurous and definitely more cautious - not to mention less technical - than I was back then.  However, I'm also wise enough to recognize the problems I didn’t when I was younger. Inconsistent configuration and failure to follow standards/compliance rules in our networking environments is a recipe for disaster. Maybe not today, maybe not tomorrow, but eventually, we will have a problem.

So how do we solve this age-old challenge?

This is a 3 stage problem, with all three stages being interrelated - it's easy to overthink and get paralyzed. In part that’s because we may lack tools and doing things manually, especially in a large environment, even with the correct resources can be intimidating if not impossible.

The challenge isn’t in building a single framework or standard. Most folk will already have this or be able to create it fairly easily.  The problem is in translating that framework into reality across our entire environment made up of multiple manufacturers and multiple device types in organizations that often have different technology areas tied to different organizational control groups (think of security, networking, DevOps, Scada/PCD as examples).

Many of the manufacturers we have in our environments have tried to solve this problem, but in totally myopic ways because they don’t see the pervasive problem - they only see their own brand's problem. They see it as a Cisco problem, a PaloAlto problem, a Juniper problem, etc., but our problem is not vendor-specific. We need a solution that can span entire networks all our network and security infrastructure, regardless of location device type, or sphere of control.

 Some companies tried to solve the problem by making tools to enforce device-level configuration management and standards. This device-level compliance and configuration management can help, as it solves a compliance problem, but it does not solve a reality problem. For example, I can push out perfect firewall configurations that are CIS/PCI/GDPR compliant, etc., but if another device in the data path is inadvertently configured to bypass that firewall or is compromised because it doesn’t meet the same standard, then the perfect configuration is useless.

What we need is a network-wide state-level view; a tool that will discover the entire network (quickly, simply, and efficiently), capture configurations, standardize said configurations, and visualize the data. Then allow us to write network-wide intent checks. The output from this check then needs to be consumable so that we can get alerts. Some examples: if our standard is to have only SNMPv3 running to avoid the inherent security risks with SNMPv2 community strings, logging needs to be enabled, and Telnet needs to be disabled. Check this each time we do a network snapshot (at least once a day) not on one device or location - but everywhere, the whole network.

This same Network Assurance platform can solve the other problem I mentioned - OS version standardization. If we have a sprawling network deployed over years, how do we enforce network OS standards? Perhaps we are very disciplined and have a schedule, or automation tools in place already, etc. for planned changes that can work (I haven’t seen it often but it can work).

Now what happens when there is a CVE - management says get it fixed. Easy. But then you think about operational risk. You need an outage window. How long should that be? How much risk is there really?

Wouldn’t it be great if a tool could quickly show you where the affected devices were in the network? (They would show you things like how many disparate code versions you have on the same device as a standard report already). Not only does it show you where they are by site, but because of the visualization, you can see the layer 1, 2, and 3 network level dependencies. Through all this, you can better understand the real risk associated with a potential outage. This doesn’t solve the problem but it does do several things

  1. decrease the time required to figure out where you are at risk
  2. give you a better idea of what the real risk of updating code is and
  3. give you a simple way to see OS level compliance across your entire environment.

 Lastly, in both cases above, a simple post-change path or network-wide snapshot will give you peace of mind.

In this blog series, I only touched on some simple use cases but the application of the data these tools collect is almost infinite. The trick when evaluating network assurance solutions, in my opinion, comes down to four things. Is it easy to install and set up, is it easy to operate and functionally modify for additional use cases,  does it have a simple open API and webhook capability to allow for integration with other 3rd party tools, and finally, if you speak to their customers, will they say they are nimble? No solution in this space will support every product on the market, but how quickly do they add support and functionality.

Until next time, may your networks be ever secure and stable.

To find out more, check out our Youtube channel youtube.com/c/ipfabric for demos of our monitoring platform integrations. Look at our other blog posts on the website to learn how our partners and customers are integrating IP Fabric with their wider operational ecosystem. And if you’re interested in an obligation-free demo of our platform, take a look here.


Try out the platform

Test out IP Fabric’s automated network assurance platform yourself and be inspired by the endless possibilities.

What would this change for your network teams?
Start live demo
We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
IP Fabric, Inc.
115 BROADWAY, 5th Floor
NEW YORK NY, 10006
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 (914) 752-2991
Email : [email protected]
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]
IP Fabric, Inc. © 2023 All Rights Reserved