Shifts in Network-Based Security

PETER WELCHER | Solutions Architect 

Networking and Security staff have been reviewing their security requirements and debating how to meet those needs. More niche needs are being noticed and serviced with products, adding flexibility to the approach taken in security designs. 

While Zero Trust identity-based controls are rapidly becoming required, sometimes replacing firewall/network-based controls, there are cases where they need to be supplemented with network-based controls deeper into the network. 

That may be because identity-based controls just don’t fit some use cases. Some sites may want belt-and-suspenders (ID-based plus network-based controls). Some sites may require stateful inspection or enforcement deeper in the network. The latter is noteworthy since it is not met by Cisco SD-Access / DNAC or designs with non-stateful switch-based security rules. In short: ‘stateful or not’ is one requirement versus the ‘cost and performance’ decision point. 

The complexity of support is part of the “cost” there. 

To sum up, there are new security requirements and capabilities, trade-offs between cost and requirements, and different vendor solutions. 

So, what’s new? 

What brought attention to this matter was Elisity, which recognized the existence of a large and growing market for simple, centrally managed identity-based security (and discovery) that can handle IoT, IIoT, and OT devices, as commonly found in hospital and industrial networks. Yes, it’s niche, but it’s very real and growing in size. And it’s not limited to just IoT, either. 

The underlying premise holds that IoT/IIoT/OT devices may not be well-hardened (from a security perspective). The vendors may be small or dedicated to a niche market (albeit a large one, like healthcare) and may need more experience with rapidly changing security and identity tools that are seen in the network security space. Or they may be used to isolated networks and unaware of what their products need to incorporate to be safely used on non-isolated networks. 

Elisity’s approach is aligned with ZTNA: controlling flows albeit with identity as a factor: determining which end systems can communicate using what ports and protocols. The understanding is that Elisity leverages intrinsic Cisco Catalyst switch enforcement capabilities and is, therefore, not stateful. 

Cisco and Juniper have recently made announcements about their visions (or perhaps one of their approaches) for driving stateful enforcement deeper into the network.  

Stateful security enforcement has always been a challenge. Standard chipsets probably need to deal with single packets on the fly and cannot (currently) track state. 

That’s one reason firewalls were distinct from routers and switches. Routers and switches focused on high-performance forwarding, while firewalls needed to focus on CPU-based or other intensive state tracking, among other things. This made them costly, and that is why they tended to be used only in selected places in the network, such as the Internet edge. 

Cisco 

Cisco scaled up network-centric enforcement with SD-Access/DNAC, albeit using stateless enforcement in centrally managed switches for the lower-risk micro-segmentation flows. If one designs to isolate flows needing more robust security into different VRFs, then an edge or other firewall (pair) can be used to secure them, assuming the flows were not too large. Doing so would mean using VRFs to backhaul (forward-haul?) traffic from a site mesh to the firewall and possible back again, i.e., with a scosh of topology plumbing awkwardness. But within a site or campus, the added latency would most likely not be a problem. 

If there are IOT devices all over a campus (e.g., hospitals), doing that creates somewhat awkward not-quite-obvious packet flows, but might not be a huge problem. However, keeping the traffic local to the building or site level might be preferable in terms of minimizing outage impacts, localizing risk domains, or smaller enforcement rulesets. Keep the flows going upstream, no hairpinning or tunnels! 

Thus, one solution that Cisco now provides is a containerized version of the ASA firewall code, the ASAc. It can be deployed in appropriate campus switches and used to localize enforcement. 

The impression is that it plays to the IOT campus niche, in that its use can be designed so only IOT VLANs or VRFs are subject to the ASAc enforcement. Doing so would then make the most of the limited throughput capacity of the ASAc (not shabby, but not anywhere near the full switch throughput either). 

Centralized control is then available using existing products. 

For conciseness, let’s call what the ASAc provides “modest volume distributed stateful enforcement.” 

On a not-very-related note: Cisco SEA (Secure Equipment Access) and SEA Plus deal with a related but different problem: secure remote access for staff and possibly vendor techs to OT devices in the field. Running such traffic through a proxy (yours or Cisco’s) and enforcing security standards can reduce risk. 

See also the links below. 

Juniper 

Juniper’s answer consists of enabling a more widespread placement of firewalls under centralized control: the Security Distributed Services Architecture built into Junos 23.4. 

Juniper states that this enables a variety of security features from Zero Trust policy enforcement to intrusion detection and prevention across distributed datacenter networks. It includes AI-based predictive threat support and new high-performance firewalls. This includes the AI-based ability to detect threats within encrypted traffic without decryption. The firewalls also include EVPN-VXLAN Type 5 support to secure data center fabrics. New 1 RU firewalls are part of the announcements. 

Juniper notes that the announcement provides scalability by creating a distributed firewall fabric, decoupling forwarding and services layers. 

One significant aspect is that centralized control should simplify managing distributed firewalls while standardizing security across them. 

There doesn’t appear to be anything about Juniper that matches “light distributed stateful enforcement.” It does appear to enable distributed deployment of smaller physical firewalls should one wish to do so. 

Aruba Networks  

Aruba announced enhancements to NetConductor, its cloud-based service for central management of distributed network security. NetConductor is based on creating an EVPN-VXLAN based network overlay for wired and wireless networks. It provides application visibility and policy enforcement to specified network access and distribution switches and data center core switches. Policy can now include identity, role, and business outcome-based rules. 

One key aspect is said to be distributed enforcement within campus and WAN (presumably sites). It includes IoT device discovery and enforcement. 

Aruba is said to be working towards a unified policy manager that centers on the ClearPass policy management platform. This is approximately the equivalent of Cisco SD-Access SGT’s. 

Skimming through the documentation, it seems Aruba may now use a VXLAN approach similar to Cisco’s DNAC, with switch-based micro-segmentation (presumably stateless) and “gateway” based enforcement, presumably between VRFs or macro segments. 

Regarding “light distributed stateful enforcement”, the comment for Aruba is the same as for Juniper, above. 

Aruba’s design docs for data center security reveal several choices: 

• Tunnel and hairpin at external gateways. 
• Use DSPs in some switch models for clustered filtering at ingress or egress (claimed wire speed, apparently enforced at the edges in/out). 
• Do enforcement at the VM/VMware/hypervisor level (but managing it is a concern?). 

Arista 

A quick take on Arista: Arista appears to have centralized firewall control with its CloudVision VRF support. The strategy appears (after a quick look) to focus on controlling traffic between VRFs. Arista also offers virtual firewalling for VMs, mentioned in conjunction with “micro-segmentation.” This provides data center security focus, which is perhaps no surprise given Arista’s primary market. 

Conclusion 

Everything in network-based security comes down to determining requirements, trade-offs between them, costs, and design complexity. 

Cisco’s innovation is containerized firewalls. They are performance-limited, but they are one way to distribute enforcement load and localize it to IoT connection points, which is campus-side security. Note that distributed firewalls with central management are also a Cisco option. 

Juniper’s innovation lets users deploy more firewalling for data center or campus security, arguably deeper in the network. Using distributed small firewalls appears to be their answer to Cisco’s in-switch containers. Those likely trade cost for better performance. 

Aruba’s addition of Pensando DSPs to CX10000 leverages DSPs for higher performance enforcement in data center switches. There’s likely a cost to them, but it’s unclear how that stacks up to the cost of a firewall with comparable throughput. It does seem less complicated than dealing with containers in switches and performance limitations or adding near-edge firewalls all over. So, there are some unclear trade-offs there. 

I’m sure people will let me know if there are any inaccuracies. I debated not including Aruba and Arista, but I hope that little bit is useful. For that matter, what’s new with Juniper is the central firewall control. As enforcement points proliferate, that’s certainly needed!

Links 

Elisity 

• https://www.elisity.com   
• Elisity blog about the 15.2 features: https://blog.elisity.com/elisity-releases-version-15.2  

Cisco 

• Cisco Service Insertion Blog: https://blogs.cisco.com/security/seamless-firewall-service-insertion-in-the-network-with-cisco-catalyst-switches   
• Cisco ASAv Data Sheet: https://www.cisco.com/c/en/us/products/collateral/security/adaptive-security-virtual-appliance-asav/adapt-security-virtual-appliance-ds.html 
• ASAc with Kubernetes mention: https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2021/pdf/BRKSEC-2417.pdf  
• https://blogs.cisco.com/internet-of-things/ot-remote-access-can-you-trust-your-technicians-laptop 

Juniper 

• https://www.networkworld.com/article/3708671/juniper-delivers-distributed-data-center-security-protection-firewalls.html 
• https://blogs.juniper.net/en-us/security/juniper-networks-evolves-modern-data-center-security-with-the-industrys-first-distributed-security-services-architecture  

Arista 

• https://www.arista.com/assets/data/pdf/MSS_SolutionBrief.pdf  
• https://www.arista.com/en/solutions/design-guides  

Aruba 

• https://www.networkworld.com/article/3709130/aruba-extends-policy-enforcement-across-campus-networks-wans.html#jump  
• https://www.arubanetworks.com/techdocs/VSG/docs/010-campus-design/esp-campus-design-052-segmentation/  

Disclosure Statement