RSMUS.comClients often ask if it would be wise to diversify their network components for fear a single code vulnerability could compromise their entire single-vendor architecture. That is a good question and it would seem logical that we would want to provide multiple layers of diverse components to prevent such events.
Perhaps the first thing to examine is the possibility that a single bug could compromise multiple components (switches, routers, firewalls, IPS, etc.) from the same vendor. While the likelihood certainly isn’t outside the realm of possibility, a multi-vendor architecture doesn’t guarantee against the threat either. The same vulnerability in one vendor’s components could also be exploited in another. We know this from this from the cross-vendor vulnerabilities discovered within SNMP, H.323 and BGP over the last few years.
We can agree that multi-vendor networks do not necessarily guarantee against compromises from a single-vendor vulnerability. When it comes to security there are no guarantees but why not implement the best-of-breed products from the best-of-breed vendors in the areas they perform best? To answer this, let’s look at the reasons behind security breaches in the past. A recent NetworkWorld article referencing the 2013 Verizon Data Breach Investigations Report finds that “misconfigurations are much more likely to be the reason for a data breach than obsolete technology.” The Verizon report states a staggering 99% of all breaches were not highly difficult and that 97% could have been stopped with simple or intermediate controls. Gartner stated in a research note that “through 2018, more than 95% of firewall breaches will be caused by firewall misconfigurations, not firewall flaws.”
These findings indicate that improper device configurations and lack of proper maintenance and review are more likely to put environments at risk. This should really be of no surprise given the number of technologies network administrators can be responsible for. Unless you get to work with the same technology every day, it is very hard to become an expert at any one thing. There could be hundreds if not thousands of options that can be configured between different device types. Once something is up and working, there is rarely time to review the rest of the options for proper hardening, not to mention log review, vulnerability research and system updates.
For most organizations with limited IT resources, the single-vendor architecture can offer simplicity which in turn can reduce the risk to the environment. Generally speaking, different device types from the same vendor have common configuration syntax and methodologies. For example, configuring a firewall from vendor X will have similar base configurations as a switch from vendor X. In other words, network administrators aren’t completely starting from scratch for each device type they deploy. A configuration template can be created to apply important logging and monitoring commands to each of the different device types without much effort.
Monitoring and management tools sold by vendors for their own devices typically offer more features and capabilities than tools designed to support multi-vendor platforms. Network administrators can also focus on security and vulnerability notifications from a single vendor rather than having to research across several vendor sites or subscriptions. The upgrade process can also be similar between different device types which may provide enough of a comfort level for network administrators to actually do the upgrades.
When choosing the next technology to integrate into your network, evaluate what similarities it has to your current environment. If you have limited IT resources, there may be less risk to your environment sticking with what you know over a feature set that will require you to start from scratch. If your current environment is a mix and match of different vendors, you may want to take a closer look at how well you are truly managing the risks associated with the different devices types.
For more information on McGladrey’s IT offerings check out our website, contact McGladrey’s technology consulting professionals at 800.274.3978 or email us.
Scott Hermanson
Scott leads the national network and unified communication solutions team, which encompasses network cyber-defense technologies, transport systems and unified communication platforms. Prior to joining RSM in 2003, Scott worked for a software company as a senior network engineer where he was responsible for the design and implementation of data and voice networks to support financial transactions in excess of over $1 million every minute and up to 800,000 online traders. Scott also has an extensive background in network design and architecture. He has designed infrastructures to support both front and back-office financial transactions with a variety of firms. Scott has great discipline in the field of network documentation and operational procedures. He has created web-based systems to capture network-based move, add and change requests, and a live documentation management system. He also has detailed experience for the implementation of network monitoring and management tools from a variety of vendors. In order to accommodate government regulation of financial-based networks, Scott has designed networks for five nines of availability. During his employment with a software company, the core network designed by Scott was able to switch all 800,000 users and over a dozen back-end connections to a remote recovery facility in less than three minutes. Switching services to the remote facility was performed once per month to ensure clients of the business continuance plan.