Download the PDF 

Zero Trust Features of the Tellabs OLAN system

Introduction

Purpose

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

Applies To

This applies to all Tellabs OLAN equipment and software.

Definitions

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.

OLAN Zero Trust Model

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:

• Granular Access and Least Privileges:
  • "prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible."  
  • "enforce least privileges needed to perform the action in the request."
• Policy Enforcement Point: "Access is granted through a policy decision point (PDP) and corresponding policy enforcement point (PEP)."
• "shrinking implicit trust zones"
• Secured Communications: "All communication is secured regardless of network location."
• Secured Access: "Access to individual enterprise resources is granted on a per-session basis."
• Monitored Access: "The enterprise monitors and measures the integrity and security posture of all owned and associated assets."
• "Microsegmentation" - Placing individuals or group of resources on a unique network segment possibly protected by a gateway component.
• "Device Application Sandboxing" - Having vetted applications or processes run compartmentalized on assets.

This white paper will explore each of these tenets and how it applies to the Tellabs OLAN product.

Granular Access and Least Privileges

• A core principle of zero trust is: "prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible."
• Also as stated in the NIST document and frequently invoked within the STIGs: "enforce least privileges needed to perform the action in the request."

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.

Policy Enforcement Point

• "Access is granted through a policy decision point (PDP) and corresponding policy enforcement point (PEP)."

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:

• OLAN Management via Panorama PON which acts as the Policy Engine and Policy Enforcement Point for the entire OLAN network.  This is outlined in the section above.
• External NAC agents that serve as the Policy Engine for network users and the Tellabs OLAN system which acts as the PEP or Policy Enforcement Point.

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:

• Aruba Clearpass
• Cisco ISE
• ForeScout CounterACT
• Windows Policy Server

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:

• Granting of access at the port level - Each user is authenticated to the system prior to granting access to the system. This is done via the authentication backends of the NAC appliances which allows for a very robust set of checks on the user login credentials, login location, etc.  No devices are trusted, each user and device is authenticated.  This is the hallmark of a zero trust architecture.  Additionally all access whether granted or denied is logged to syslog along with all relevant information to act as a backup to the radius server logs in the case of a breach.
• Enforcement of Device Compliance - Many of these NAC engines support limiting network access until the device is deemed compliant and is fully compliant with organizational security guidelines.  As an example, ensuring it is a known device, ensuring that security patches are up to date, ensuring the device has an agent running to monitor security.  Tellabs fully supports this on all NAC appliances and can limit network access via dynamically placed ACLs.  Unknown devices may be placed onto either a quarantine VLAN for observation or on a guest VLAN granting no access to internal resources.  OLAN acts as the PEP for all these scenarios.
• Profiling of Devices - Many of the NAC appliances support profiling devices to determine their manufacturer, software, etc and making that available to make policy decisions within the Policy Engine.  Tellabs fully supports profiling with these NAC engines by providing MAC information, credentials, certificates, device location, and LLDP data (device inventory).  This can be used to automatically configure access for devices or used as attributes in the policy decision within the NAC appliance.
• Web Redirection - Some NAC appliances support Web portals that allow web authentication while limiting the network access to ONLY the web portal which also directs the user to download the endpoint software and perform any required updates.  Tellabs OLAN is one of the few lan devices that support Web URL redirection to the NAC appliance portal of all user web traffic to enforce this method of authentication and device compliance enforcement.

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.

Shrinking Implicit Trust Zones

• Shrinking Trust Zones

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.  

Secured Communications

• "All communication is secured regardless of network location."

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.

Secured Access

• "Access to individual enterprise resources is granted on a per-session basis."

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.

Monitored Access

• "The enterprise monitors and measures the integrity and security posture of all owned and associated assets."

The OLT and EMS log all accesses to the system:

• All logins, logouts, and failed attempts are logged to the security log.
• All logs can be pushed via Syslog to one or more sites to ensure duplicate copies of logs for post analysis and comparison to ensure logs have not been compromised.
• All changes to the system are logged so that all actions are traceable back to a user.  
• All changes to user roles and attributes are logged.

Micro Segmentation

• Placing individuals or groups of resources on a unique network segment possibly protected by a gateway component.

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.

Device Application Sandboxing

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.