Recently during a research interview with a small but fast-growing business, for the first time I encountered an organization with a “no-network-vendor” network. That is, instead of using Cisco or Dell or even a white-box solution for switching and routing, the company deployed only Fortinet equipment for its entire network. That is, every network component is part of the security infrastructure for them.
They built the network this way not just to bake security into its core (a great idea in itself) but also for:
- ease of management: they have one tool, it manages every component
- ease of deployment: they have only two or three versions of each appliance, all the same except for capacity and port count
- ease of expansion to new locations: every site is the same as any other site of similar size
They have a small stock of replacement appliances on the shelf, with which they provide rapid recovery for all locations. They could easily also consume security-operations center as-a-service, and use professional services for nearly all the rest of their network operations. In essence, their security solution could become their complete network solution as well.
They use Fortinet but could have chosen Versa Networks or Watchguard or others.
As security vendors push further into the networking space, should enterprises buy into their vision?
Yes and no.
On the plus side there are some clear benefits centering on operational simplicity and ease of management to having a single vendor and a minimal number of appliance types that comprise the converged network/security stack. More importantly, having security be the core of the network should make it far less likely, if not impossible, for there to be a disconnect between security policy and network practice, something that is all too common in environments where security is separate from connectivity.
On the minus side, any kind of monoculture in IT makes the infrastructure more susceptible to the chosen platform’s weaknesses, and to problems with the vendor. If there is a security flaw in the operating system of the core appliances, the whole network and all locations are likely vulnerable at the same time and in the same way—one attack compromises all. Where security has a separate tier of infrastructure, there is the chance that a problem in the security tier can be mitigated with changed configurations on the network tier, just as the security tier mitigates risks in the network. If the vendor is acquired by another vendor or acquires someone else, support for the whole connectivity infrastructure is at risk during the transition.
And the flipside of having one throat to choke when there is a problem is having less leverage in price negotiations and the likelihood of higher costs. Upping stakes and moving to a new vendor is harder the more stuff you rely on one vendor for.
The appeal and real benefits of having the security systems be the whole network are clearest for smaller and midsized companies. They are more likely to have uniform and relatively simple needs, and also to have thinner staffing. They are more likely to have difficulty affording, attracting, and retaining the talent they need in both security and networking. So, having just one platform to become expert in, one platform to train new staff on or to outsource the management of lets them make the most of the staff they have.
The benefits are less clear for larger company. These tend to have more complex environments and requirements, and are less likely to tolerate the risks of monoculture given they are better able to staff for and support a blended ecosystem.
So, should security systems be the network? For smaller organizations, it looks viable with the caveats outlined above. For most larger organizations, I think the answer is currently no. Instead, they should focus on making their network systems a bigger part of the security infrastructure.
In implementing a zero-trust architecture (and everyone should be) or an SD-LAN, or in deploying a software-defined perimeter (SDP), network switches can and should play a central role. Switches should be policy-enforcement points, enacting policies defined and managed in a security policy engine of some sort. They should be able to do this even if they are not all from the same vendor, let alone the same security vendor.
Copyright © 2022 IDG Communications, Inc.