The Case for Zero Trust

In 2009, a coordinated cyber attack against dozens of major companies, including Google, Adobe, Yahoo, and Northrop Grumman, resulted in the penetration of numerous corporate networks and the installation of malware on computers thought to be safe behind a protected perimeter. Worse, since the compromised computers within the network were considered to be “friendly” to their peer computers on the network, they benefited from privileged access and a potential escalation of the security breach.

The attack became an international incident and resulted in a rethinking of corporate network infrastructure and even the wisdom of corporate firewalls. In 2010, a Forrester Research analyst named John Kindervag coined the term Zero Trust to refer to an alternative networking model that assumed no secure network perimeter and instead obligated each client and service to mutually identify themselves and communicate over encrypted connections. Over the next several years following the attack, Google implemented Zero Trust within its own network and published its learnings in a series of white papers under the BeyondCorp moniker.

Traditional Corporate Networking Model

It has long been the case that in order to defend their systems from intrusion, corporations would establish a corporate network, a “secure” perimeter around a private network containing the company’s prized technical assets. Contact from outside the perimeter was treated with suspicion, but systems within were assumed to be friendly. This perimeter was often called a corporate firewall and can be compared to the moat surrounding a castle, which represents the corporate network in the analogy.

In a real castle, the problem with this paradigm is that if the moat and wall are penetrated by a nefarious actor, the contents of the castle are exposed to foul play. Worse, the inhabitants tend to trust their security perimeter and therefore treat contact within the walls as friendly. Lulled to a false sense of security, they are more vulnerable within the walls than they would be without, where they might continuously treat their surroundings and contacts with appropriate suspicion. In the same way, users and computational resources within a corporate firewall may trust their peers more than is warranted, given that an incursion is not only possible but likely.

The castle analogy, while useful, begins to break down when modern corporate networking realities are addressed. Nearly every enterprise has a cloud presence and many extend their network perimeter to encompass cloud-based services. As well, users working from home or on the road often can establish a privileged connection through the corporate firewall with the use of a VPN, opening another possible vector for intrusion.

The Zero Trust Alternative

Zero Trust networks contain no concept of “friends”. Each interaction between users and systems–initiated both within the corporation and outside–must ensure that each actor can prove their identity, and their communication must be encrypted.

Zero Trust’s principles, according to Google, who market their flavor of it as BeyondCorp:

1. Connecting from a particular network must not determine which services you can access
2. Access to services is granted based on what we know about you and your device
3. All-access to services must be authenticated, authorized, and encrypted

These principles deserve further treatment:

1. Connecting from a particular network must not determine which services you can access

We’ve established that demarcating a private network implies–but doesn’t ensure–security. In fact, the expectation that a private network is secure reduces awareness of risk. As such, all networks, including one’s own, should be presumed to be insecure. Compartmentalizing networks into small units, often based around Identity Access Management (IAM) controls such as those provided by cloud computing platforms, as well as Virtual Private Clouds (VPCs), are referred to as microperimetry. This help reduce the blast radius–the surface area of possible damage–of a security vulnerability but should not be a primary defense. Otherwise, they run the risk of replacing one corporate castle-and-moat with a series of castles and moats, reflecting the same inherent risk.

2. Access to services is granted based on what we know about you and your device

A common practice in Zero Trust implementations is to allow access to services only from systems that are managed by the corporate IT organization. In this fashion, they can ensure that the client’s operating system is patched for any known security vulnerabilities, that adequate anti-virus software is installed, and that other security components are in place. Knowing that the client system is secure prior to an attempt to contact another service in the network dramatically reduces the opportunity for a nefarious party to successfully penetrate the system.

Often a centralized Device Inventory Service is used to collect data on known devices and to ensure that they meet security requirements for access. Access requests can use the contents of the device inventory database to determine whether a request should be approved or denied based on the last known security state of the device.

Single Sign-On (SSO) systems are typically used in Zero Trust when a human user wishes to access a system. Identifying themselves with their centrally-managed username and password from a secured system known to the IT department significantly reduces the risk that an unwanted user can gain access. In addition, modern security practices recommend using Multi-Factor Authentication (MFA) to prevent a stolen password from being used by another party. MFA requires that a user have a physical device–for instance, a mobile device or USB dongle–in addition to their password in order to gain access to a system. In combination with SSO, MFA provides exceptionally high certainty that the user is known and worthy of trust. Finally, access is granted according to the principle of least privilege, which means that user access should be constrained to only data and functions serving the user’s legitimate business purpose.

3. All-access to services must be authenticated, authorized, and encrypted

An authenticated user should also be sure that the system they are accessing is known to them. An imposter, such as in a man-in-the-middle attack, can be detected if the service is able to identify itself by a pre-arranged means or through a chain of trust, as with a certificate. Once both client and service have mutually proven their identities, a determination must be made as to whether the given client should be provided access to the service and the data it contains. This authorization can be aided by IAM rules and the identity information contained in the directory backing the SSO system. Once approved, all communication between the client and service should be encrypted such that a packet-sniffing network peer has no visibility of the contents.

Nortal and Zero Trust

As credentialed partners with Microsoft Azure, Google GCP, and Amazon AWS, we have extensive expertise in deploying cloud and hybrid architectures. In both greenfield implementations and legacy migrations, we have applied best practices and guided our clients in improving their security stance. We provide consulting services and custom software solutions to clients around the world, including numerous Fortune 500 corporations. Allow us to assist you with your security architecture needs.