?

Leveraging Edge Computing in a Zero Trust Architecture

This article describes how the early initiatives in software-defined networking contribute to the goal of implementing a Zero Trust architecture through incremental advancements in network programmability.

October 20, 2020 9 minute read

One myth of implementing Zero Trust in the data center network is that it requires a significant shift or disruption in existing infrastructure. Fundamental changes in how networks are provisioned and secured have evolved over the years. The National Institute of Standards and Technology (NIST) on Zero Trust Architecture describes this shift as an "evolving set of network security paradigms." 

In many organizations, this evolution will be accomplished by incremental successes which provide the foundation to implement the organization's security posture protecting the target assets.

Let’s examine the evolution of one technical component key to implementing a Zero Trust architecture — programmable, edge-accelerated, SmartNIC technology for the data center.

This is a journey of how the underlying technology that has evolved over many years.

OpenFlow, the first SDN standard

One aspect of my role at WWT is to incubate emerging technology using the Advanced Technology Center (ATC). My position was posted as an ‘investment' in evaluating and implementing software-defined networking (SDN) concepts and provide guidance for customers when evolving to programmable networks. WWT was an early adopter of SDN — we developed and deployed a production SDN solution to manage connectivity within the ATC. We used white box OpenFlow switches and an SDN controller. The  Software-Defined Networking Matrix Switching white paper was published in January 2015.

In 2014 I introduced the concept of security-defined routing (SDR) at a cybergamut talk. SDR combines cyber analytics and SDN to protect the network. The SDR solution used Snort to monitor network traffic and generate alerts to a log file. The application monitored log files and used OpenFlow to deny and mirror suspect traffic for transaction monitoring and archiving for regulatory compliance and troubleshooting.

Both the Matrix Switch and SDR are programmable networks using OpenFlow and White Box Switches. The concept of P4, Programming Protocol-Independent Packet Processors, was introduced around this timeframe as an evolution of OpenFlow. The goal of P4 was to future proof OpenFlow by offering a programmatic abstraction for matching headers and parsing packets. 

SDR and Zero Trust conceptually align with the OODA loop cycle of observe–orient–decide–act. The process of implementing Zero Trust in the data center to bound east-west communication involves analyzing the application characteristics, filtering the information, deciding where to apply the policy and then acting by enabling the policy.

Cisco enters the SDN market

Cisco began shipping Application Centric Infrastructure (ACI) in mid to late 2014 and this SDN solution captured the attention of data center network operators and relegated OpenFlow SDN solutions to niche players. ACI was immediately popular due to Cisco’s command of data center networking. The technical sessions for ACI at CiscoLive were standing room only; lines formed down hallways. 

Cisco ACI abstracted the network fabric to appear as one big switch managed by the Application Policy Infrastructure Controller (APIC), their SDN controller. It was a steep learning curve for network operators, and because of the often-siloed organizational structure of most organizations, the full promise of combining applications and infrastructure was never realized. Most network operators implemented network-centric mode and did not implement Zero Trust by applying policy to the leaf switches.

While ACI implements a white-list policy approach, applying policy on network devices for complex rulesets can exhaust ternary content-addressable memory (TCAM). TCAM is a specialized piece of memory in hardware where access-lists (ACLs) are stored. The TCAM size limits the number of rules (access-lists).

Cisco ACI was successful in abstracting the network and offering a robust API to programmatically provision the network and policy, however, network operators failed to capitalize its full capability. Many network engineers lacked the foundational knowledge of network programmability and did not exploit these features.

NSX: VMware’s network virtualization platform

The VMware NSX approach to Zero Trust is to enforce security policy in the hypervisor, as each hypervisor has visibility to the traffic flows. This approach eliminated the 'hair-pinning' of traffic from the host to the leaf switch for policy enforcement.

Because of the organizational silos, VMware gained traction with the server and application teams, Cisco with the network operators. Both approaches had their merits and flaws. Implementing a granular white-list policy consumed TCAM on the leaf switch and CPU cycles on the host.

Application dependency mapping (ADM) and security

To apply a granular white-list policy you must first gain insight into the characteristics of the applications and identify what ports and protocols are used for communication. In the 2017-2018 timeframe, we saw Cisco release Tetration, and Illumio introduced their Adaptive Security Platform (ASP).

Both offerings include a data collection component, analysis component and offer enforcement through agents configuring the host firewall to enforce east-west traffic. The process of collecting data from host agents, analyzing the data and host-based enforcement align with the OODA loop cycle of observe–orient–decide–act.

These solutions allow for the export of policy via APIs and streaming message services.

Extending the utility of ADM policy with Ansible

In 2018 I developed an Ansible interface to Cisco Tetration Network Policy Publisher, which is published on Cisco DevNet  Code Exchange and presented at AnsibleFest Austin. Ansible provides the network and security administrator access to these modules and a playbook that can iterate over the published policy (think Access-Control Lists, or ACLs) and apply the policy using Ansible modules for Cisco ACI or firewalls, as well as other network devices or load balancers.

The solution was presented at the 2019 DevNet Create and   Ansible Durham Meetup: Enabling Policy Migration in the Data Center With Ansible.

Throughout 2019, this solution contributed to our migration from the legacy data center fabric to ACI using a hybrid deployment: network-centric with white-list policy. Visibility agents on hosts provided telemetry to Tetration. The policy was extracted via the API, manipulated and then applied as a policy to ACI.

The rush to containers and cloud

Meanwhile, the adoption of containerized applications accelerated, and workloads were rapidly moving to the cloud. AWS revamped its virtualization infrastructure by developing the AWS Nitro System, combining hardware with a lightweight hypervisor which offloads encryption and policy decisions to a PCIe card. Introduced in 2017, it was running on all AWS Instances by 2019.

Unlock the potential of software-defined networks

Not all workloads can, or will, run in the cloud. Let's look at how the stories converge. The P4 programming language and supporting hardware offer a greater degree of flexibility for parsing packets and matching header fields than the OpenFlow specification. OpenFlow was designed around the concept of a match-action pipeline. Fields in the packet header are matched, and actions include discarding, modifying, or forwarding the packet out one or more ports.

P4 provides the ability to write software and install it on  P4 switches directly, as opposed to an OpenFlow controller populating the flow tables of a 'dumb' OpenFlow switch.

Enter Pensando Systems

The Pensando founders include former Cisco engineers who were instrumental in the development of Cisco ACI. Emerging from stealth mode in 2019, the company introduced a PCIe based Pensando Distributed Services Card (DSC) network interface with a programmable P4 processor. The system is intent-based, with an SDN controller (Policy Services Manager, PSM) managing the associated DSC cards. 

One key component of the P4 architecture enables VNF (Virtual Network Function) offloading and executing common network functions like firewalls and load-balancers. Because the Pensando DSC is built with the P4 processor, these functions are implemented on the DSC rather than in software on the computing resource.

In the Zero Trust model, with the challenges of applying a granular white-list policy using ACI or NSX, the ruleset consumes limited hardware and software resources. By offloading this functionality to the DSC, we eliminate the hair-pinning and TCAM exhaustion or consumption of CPU cycles and memory on the host. The DSC can support one million IPv4/IPv6 stateless ACL entries.

Both Cisco Tetration and the Illumino Adaptive Security Platform implement the policy for a Zero Trust model by using an agent on the host operating system (OS). Many organizations are reluctant to install agents on hosts for data collection and enforcement. Installing agents adds another level of configuration management complexity and security exposure. Enforcing policy in the OS may add complexity to troubleshooting connectivity issues.

Agentless flow data

Tetration provides the option to ingest telemetry using ERSPAN sensors as an alternative to the collection agent installed on hosts. Port mirroring is a common OpenFlow/P4 use case, demonstrated in the SDR solution. By using the programmability of the DSC, traffic flows are mirrored to a Tetration ERSPAN collector for analysis.

Once analyzed by Tetration, the Ansible modules and playbooks developed for the Ansible interface to Cisco Tetration Network Policy Publisher (ansible-tetration) are used to retrieve the white-list ruleset for the modeled application.

I have recently developed an Ansible collection which instantiates policy through Apps and Network Security Policy definitions on the PSM. The policy distributed to the DSC cards, implementing granular rules and enabling a Zero Trust model without impacting the associated host or network resources.

Project Monterey

Project Monterey was announced at  VMworld 2020 as a collaboration between VMware, Inc. and Pensando Systems to integrate VMware Cloud Foundation (vSphere, vSAN, and NSX) to run on the Pensando Distributed Services Card (DSC). This integration offloads the granular firewall functionality from a host-based implementation to the DSC, preserving the host compute resources for application workloads. Project Monterey is targeted at the SmartNIC vendors NVIDIA and Intel in addition to Pensando. Project Monterey has not been released, but is a roadmap for the future.

An evolving set of network security paradigms

In this article, we examine how the adoption of OpenFlow and its successor P4 have contributed to the journey of implementing a Zero Trust architecture in the data center. Throughout the 6-year time span, the industry has developed and adopted new configuration management tools, as well as different approaches to SDN. Data collection and analysis platforms have been introduced and deployed.

In retrospect, the promise of programmable networks is not yet fully realized, however much has been accomplished and limitations continue to be overcome.

Reach out to us if you would like to see a demonstration of applying policy generated by Tetration to the Pensando PSM.
Share this

Comments