While conducting research interviews for a small but rapidly growing business recently, I encountered for the first time an organization with a “no network provider” network. That is, instead of using Cisco or Dell or even a white-box solution for switching and routing, the company simply deployed Fortinet equipment across its entire network. That is, every network component is part of their security infrastructure.
They build their networks this way not only to embed security into its core (which is a good idea in itself), but also to:
Easy to manage: they have a tool that manages every component
Easy to deploy: There are only two or three versions of each device, all identical except for capacity and port count
Easily expandable to new locations: every site looks like any other similarly sized site
They have a small number of replacement units on the shelves and can provide quick recovery for all locations. They can also easily use Security Operations Center as a Service and use professional services for nearly all the rest of their network operations. Essentially, their security solution can also become their complete network solution.
They used Fortinet, but could have chosen Versa Networks or Watchguard or something.
As security vendors push further into cyber, should enterprises embrace their vision?
Yes and no.
On the plus side, there are some clear benefits centered around operational simplicity and ease of management since there is only one vendor and a minimal number of device types making up a converged network/security stack. What’s more, putting security at the core of the network should greatly reduce the likelihood, if not the impossibility, of a disconnect between security policy and network practices, which is all too common in environments where security is separated from connectivity.
The downside is that any monoculture in IT makes the infrastructure more susceptible to weaknesses in the chosen platform and vendor issues. If there is a security vulnerability in the operating system of a core device, the entire network and all locations could be vulnerable in the same way at the same time—a single attack endangering everyone. If security has a separate infrastructure layer, issues in the security layer can be mitigated by changing configurations on the network layer, just as the security layer reduces risks in the network. If a vendor is acquired by or acquires another vendor, support for the entire connectivity infrastructure will be at risk during the transition period.
The flip side of having nothing but a chokehold when things go wrong is having less leverage in price negotiations and potentially higher costs. The more you rely on one supplier for something, the harder it is to increase your stake and switch to a new supplier.
For small and medium-sized companies, the appeal and real benefits of making security systems part of the entire network are most obvious. They are more likely to have uniform and relatively simple needs and have smaller staffing levels. They are more likely to struggle to afford, attract and retain the talent they need in security and networking. Therefore, there is only one platform that can become an expert, one that can train new employees or outsource management and allow them to make the most of existing employees.
For large companies, the benefits are less obvious. These tend to have more complex environments and requirements and are less likely to tolerate the risks of monocultures because they are better able to staff and support mixed ecosystems.
So, should a security system be a network? For smaller organizations it looks doable, with the caveats listed above. For most large organizations, I think the answer right now is no. Instead, they should focus on making their network systems a larger part of their security infrastructure.
Network switches can and should play a central role when implementing a zero-trust architecture (everyone should be doing this) or SD-LAN or deploying a software-defined perimeter (SDP). The switch should be the policy enforcement point, enforcing policies defined and managed in some kind of security policy engine. They should be able to do this even if they aren’t all from the same vendor, let alone the same security vendor.