The purpose of this document is to discuss the Zero Trust Security Model as outlined in the NSA Cybersecurity Information publication "Embracing a Zero Trust Model" and the NIST Special Publication "SP800-207 Zero Trust Architecture" and how the Tellabs OLAN product line implements and supports the deployment of Zero Trust Network
This applies to all Tellabs OLAN equipment and software.
Zero Trust Architecture: Zero Trust is a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information fed from multiple sources to determine access and other system responses. The Zero Trust security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access to only what is needed and looks for anomalous or malicious activity.
NIST SP800-207 defines Zero Trust as follows:
Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero-trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.
Core principles taken from NIST SP800-207 and explored in this white paper are:
This white paper will explore each of these tenets and how it applies to the Tellabs OLAN product.
Tellabs always requires authentication for access to all data and services within the product. Additionally, the product times out access after configurable timeouts to ensure that authentication is frequent and idle sessions are not left unprotected.
Additionally, access to resources is very granular and each function of the system is configurable as to the level of access granted.
The access rights are grouped together into a role which is assigned to a user. This ensures that policy is consistently applied across the enterprise and that assignment errors cannot occur once policies have been created.
These fine-grained access policies can be used to tailor access to the least number of functions required to perform the user’s job. No additional access rights need to be granted and zero trust principles are satisfied.
All important security attributes are defined as profiles or policies that are then assigned to users to define their level of access to the system. The EMS then acts as the Policy Enforcement Point for all management actions within the system.
The model shown above is a standard Zero Trust model where a Policy Engine defines policies that are then enacted by the Policy Enforcement Point to protect resources.
The Tellabs OLAN system uses this model in two ways:
Tellabs OLAN supports many NAC or Network Access Control devices that can be utilized to control access to the network and its resources. The primary NAC controllers supported by OLAN today are:
Tellabs provides Industry standard interfaces and performs interop with each NAC appliance to ensure compatibility and proper operation and application of policy to the network. This happens in several ways:
In addition, the Zero Trust network diagram, there are a number of external components that help build the zero trust environment. Some are external to OLAN, some are a part of OLAN. Those components that are a part of OLAN are discussed below.
Threat Intelligence Feeds - The system supports some NAC appliances such as ForeScout and others that are able to watch all the user traffic and look for patterns or suspicious accesses. Tellabs OLANs to enable these threat analysis systems to immediately shut down any interface that is detected as suspicious by using RADIUS commands that either shut down access, or move the user to a quarantine VLAN where they can be safely observed and quarantined for study. These systems often look for signatures of software vulnerabilities or malware. Tellabs OLAN also has been tested with many of the endpoint software that is used by the NAC appliances to observe and make policy decisions about users.
Network and System Activity logs - The Tellabs OLAN system logs all user access to the system and also logs all changes made to the system so that administrators can determine what happened in any post mortem examination. Additionally, the system supports logging both locally and remotely via syslog so that multiple copies can be kept in multiple locations limiting the possibility of access log tampering. For the end users and devices, the mirroring functions used in conjunction with tools like ForeScout allow them to observe all user traffic and log any suspicious activity.
Data Access Policies - All data managed by the OLAN system is controlled by data access policies controlled by the EMS user roles. This ensures that only accesses necessary to perform job function are allowed. For end users, this has to be done via external systems as OLAN has no access to this.
Enterprise PKI - The EMS and OLT uses PKI for all access to the system. The EMS to OLT (OLAN) link is always encrypted with FIPS level encryption, secured by a PKI certificate and mutual authentication is performed of certificates. All EMS clients are secured with certificates to ensure that access is only via Tellabs software. Local site certificates can be utilized to limit access to a few trusted computers or individuals. In addition, 2FA is also supported to further secure these links.
ID Management System - The NIST document calls out LDAP as an example of an ID management system that supports this zero-trust architecture. The EMS does support Active Directory authentication of users and this can also be supported for OLT CLI users via a RADIUS Active Directory backend. This ensures that users can be managed at the enterprise level, and that users can be instantly denied access to the EMS and OLT resources via an action in Microsoft Active Directory.
The idea behind this is that in the past, typically, the network resources and infrastructure were protected by a perimeter firewall or border gateways that denied or granted access to the perimeter, but the enterprise was basically an open or trusted zone. This led to very large Implicit Trust Zones which, once the perimeter was breached left the systems behind very vulnerable to attack. The idea here is to shrink the trust zone to as small as possible so that any breach limits the scope of damage. Ideally, every endpoint would be zero trust.
All the components of the OLAN product, EMS, OLT and ONTs, implement a zero-trust policy and come pre-hardened out of the box for many types of access. When properly set up using the DoD deployment guides, all the components are completely hardened and only have access on ports where it is strictly needed for operations. All unnecessary ports are closed, and when Trusted Hosts is activated, cannot be managed or accessed by any host that is not on the trusted host list. To all other addresses, the OLT is completely dark and all packets from non-trusted hosts are silently discarded.
All devices without the correct certificates are denied even if in the trusted host list. The ONTs have no manageable interfaces and are managed via an inband channel on the PON interface that is not accessible via the data plane. Only the OLT can reach or manage the ONTs. The OLT also requires Authentication and can support 2FA. This layered approach implements all the best principles of Zero Trust networking where each component is fully hardened and does not have implicit trust for any node.
It should also be noted that the Tellabs OLT reduces the attack surface by a factor of typically 170:1. A single OLT can support up to 8192 Ethernet ports. This would result normally in at least 170x 48 port switches. Rather than having to secure 170x switches, you merely have to secure a single IP address. This effectively results in a more than 2 orders of magnitude decrease in attack surface. Securing a single OLT in most cases secures the entire network.
All communications within the Tellabs product is secured by FIPS140-2 encryption. The EMS to OLT connection which is used for management is FIPS encrypted. The EMS client to server links are all encrypted with FIPs 140-2 encryption. When properly installed per the Deployment Guide, the links are also secured by a certificate. All interfaces into and out of the OLT are secured.
The OLT in most DoD and large Enterprise environments is secured via 802.1x. The system will deny network access to the port until the user has authenticated via 802.1x using their user and/or machine credentials. This ensures that every user session is authenticated prior to any access.
The OLT and EMS log all accesses to the system:
The Tellabs OLT supports VLANs for network segmentation of users into their own network segment. Any user can be placed into any VLAN within the system. The system enforces strict segmentation and there is no leakage between VLANs. The system also uses profiles for configuration of the VLAN ensuring that users are properly configured onto the correct network segment and eliminating user errors in configuration.
The EMS supports being deployed within a Virtualized environment such as VMWare or Virtual Box and run on a virtual machine as recommended by the NIST document. This allows better compartmentalization and protection of the EMS application. Additionally, it allows very quick rollback should an instance become compromised to an earlier snapshot. Also, the hardening of the VM appliance ensures an additional layer of hardening or protection. Additionally, when a catastrophic failure occurs, a snapshot of the server can be loaded and be brought back online at another location within minutes at a backup site.
Also, the deployment strategy outlined in the OLAN deployment guide recommends isolating the EMS application software by limiting access to the machine to a single Admin user responsible for machine maintenance. All other users use the external EMS clients. This ensures a zero-trust architecture for the EMS server and protects all access and enforces no access to system resources except via the EMS management software.