Two Schools of Thought on Network Vulnerability Management

There’s a conversation that goes on all the time between Network Engineers and Security Analysts. The Information Security team will perform vulnerability analysis of network devices and tell the Networking team “Here’s a list of all the known security vulnerabilities that has released. Please go fix them.”

And the Network Engineers, seeing hours of unproductive patching ahead of them will reply with “But these aren’t all vulnerabilities. We don’t even use Feature “X” or Feature “Y” in our configurations, so we’re not at risk.”

There usually follows a period of negotiation between the two teams and some smaller number of vulnerabilities will be agreed to be the critical set.

Having watched this dialogue play out more than once, I’m struck by the thinking that underlies it, particularly in an age where we’ve seen massive breaches of customer information at banks, credit agencies, retailers and other companies.

What does it mean for a system to be “vulnerable” these days? Is it enough to say “we don’t use that feature so we’re safe?” Is it enough to claim, “we’re too busy to patch these systems?” Is it appropriate to treat security advice as unwelcome or unhelpful?

No. What we’ve been doing to address known vulnerabilities has not been good enough. Trying to pare the list down by virtue of what features are used or not is not smart management. And it’s time to change.

“Hold on!” you say. Why isn’t it good enough to look at the feature sets in use in the environment as a filter to required patching? Because even if you don’t use that feature today, the overall OS retains that vulnerability. If a vulnerable feature is enabled either by accident by an engineer, or deliberately by a bad actor, the vulnerability is available to be exploited. The only safe solution is to upgrade the device to a non-vulnerable OS build.

If we unpack the reasons for the classic approach, it becomes clear that the problem is really “How do we find all the holes?” And then “how do we fill all the holes in?” And the only answer that makes sense in today’s security climate is through automation. Network engineers need to take the lead in automating the discovery of known security vulnerabilities in our infrastructures. Then we need to take the lead in automating a rapid response to network device patching.

No one thought that multiple software releases to production was possible and the CI/CD/DevOps community have proven that dead wrong. We need to leverage tools and platforms and processes that have as a goal the rapid delivery of new device software releases across the infrastructure. An ideal goal to start with is to patch the entire infrastructure in 48 hours from the release of a vulnerability notification.

Infoblox NetMRI and NetMRI Advisor can help you implement a robust, automated compliance program. You’ll automatically obtain new and updated CVE bulletins about devices in your network, highlighting those devices affected on a bulleting by bulletin basis. With NetMRI’s automation engine, you can automate the upgrade of device OS images, as well as apply configuration updates to provide additional protections like SNMP exclusion lists or ACL’s to filter traffic. NetMRI Advisor will also provide you daily reports on devices in your infrastructure that have End of Sale or End of Support dates published against them so you can plan lifecycle activities based on real, actionable data.

As the Infoblox NetMRI experts, we can help you plan, implement and grow a successful network automation practice. Contact us today and get started with NetMRI. 

 

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.