An Understandable Guide to Zero Trust Architecture (“ZTA”)

While cybersecurity professionals are generally nice people, and I have nothing against them, they have trust issues. Their spouse, friends, and family may not appreciate the lack of trust, but it goes a long way towards protecting the systems entrusted to them. Cybersecurity best practices are to employ a Zero Trust Architecture (“ZTA”) to the company’s systems to prevent unauthorized actors from gaining access.

ZTA is a shift away from an implied trust architecture which assumes certain users or devices are inherently trustworthy. ZTA replaces the trusted third party with a system that should operate correctly even someone in the transaction is not to be trusted. An Ericom Software survey found that 80% of firms are moving to a zero trust strategy in 2022. Amazon, Google, IBM, and Microsoft have all adopted some form of a zero trust strategy. This transition to ZTA better protects company data, reduces breach detection time, and is better suited for cloud environments.

The National Institute of Standards and Technology Special Publication 800-207 defines ZTA as a “cybersecurity plan that utilizes zero trust concepts, [such as least privileged access,] and encompasses component relationships, workflow planning and access policies.” In other words, older architectures granted devices or users implied trust within the system, whereas ZTA requires constant re-authentication and re-authorization. This distinction will make more sense as we briefly walk through the SolarWinds breach.

Older architectures granted devices or users implied trust within the system, whereas ZTA requires constant re-authentication and re-authorization.

The now infamous SolarWinds hack highlights the vulnerabilities of a “supply chain attack” and how ZTA can help to lower the chances of such an incident. The Committee on National Security Systems defines supply chain attacks as “attacks that allow the adversary to utilize implants or other vulnerabilities inserted prior to installation in order to infiltrate data, or manipulate information technology hardware, software, operating systems, peripherals (information technology products) or services at any point during the life cycle.” SolarWinds’ widely used software called Orion, which was used by many government agencies and large corporations, was infiltrated by third-party actors. Once inside SolarWinds’ system, hackers to insert malicious code into the Orion software, which was then installed, unknowingly, via updates sent out by SolarWinds.

The hackers exploited SolarWinds’ systems rather than the networks of SolarWinds customers, hitching a ride on the back of a software service that could introduce malware deeply to thousands of these customers. In a generalized, non-technical description, what I mean by system is a company’s software and hardware, whereas a network concerns the connections of the computers to each other and any connections facing the public internet. A common example, as explained by Ted Claypoole, is a castle. The castle is protected by a moat that isolates it from the broader world (i.e. the internet), but once someone is in the castle, if there are not additional security measures, then the intruder has the keys to the kingdom. Sure there are guards walking around inside the castle, but unless something looks particularly suspicious, out of place, or bizarre nothing is questioned.

ZTA is not focused on a single moat protecting against the outside, but instead on a series of checkpoints to ensure the access request is authenticated. Think of an airport where you first check-in with the airline and they make sure your ID matches the name on the printed ticket, then TSA checks your ID again and the gate agent scans your printed ticket. You are already in the airport, but the airport has trust issues which is why you rarely if ever hear about people getting on the wrong flights.

Dialing down, NIST boils down ZTA into seven tenets:

• First, any data sources and computing services are considered resources.

• Second, network location alone is not a sufficient basis to determine whether an access request meets the security requirements. Just because the device is inside the moat does not mean that it deserves to be trusted.

• Third, access to individual resources is limited to a per-session basis. Basically, don’t let users leave the pantry door open because they are going to come back later; the dog always manages to find the treats in the meantime.

• Fourth, a dynamic access policy should consider the user’s identity, application or service, and the requested asset. This means helps to create a type of log to note the software version, network location, time and date of the request, and installed credentials among a host of other attributes. An analogy here is how the insurance company makes you repeat your name, date of birth, and last four of your social security number even though you already typed it in and told the last two representatives.

• Fifth, monitor and measure the integrity and security of all devices and applications. Some devices have inherent vulnerabilities or do not need the same access as others. For example, your phone that connects to your employer’s network should not be able to access the same company information as your laptop. The phone is a less secure device and may not be managed by the company.

• Sixth, authentication and authorization to resources is dynamic, strictly enforced, and continually reevaluating trust. This tenant may sacrifice efficiency and speed in the name of security. For example, requiring users to authenticate their identity after two hours or when trying to open new documents. Companies may tailor these requirements to divisions or teams to help balance efficiency.

• Seventh, collect, evaluate, improve, and repeat. A company should be collecting as much data about the access requests, network traffic, and security posture in order to evaluate and improve the policies.

A company should be collecting as much data about the access requests, network traffic, and security posture in order to evaluate and improve the policies.

ZTA is an effective approach to security because of the multiple authorization and authentication checkpoints. By constantly asking users and devices to identify themselves, your company’s IT team increases the number of opportunities to detect whether something fishy is going on. Furthermore, ZTA can help limit contagion by catching incidents early in the process and segmenting them from the rest of the network. Although ZTA may slightly decrease overall user efficiency and experience, given a breach can hamper operational ability, create legal obligations, and increase regulatory scrutiny, it is a small sacrifice for the health of the company.

SolarWinds could have benefited from certain ZTA models, such as granular process-level micro-segmentation. These very detailed type controls help ensure that malicious actors are detected and not granted access. Sure, we can always play Monday morning quarterback and say what a company should have done after the fact, but understanding the data your organization controls, assessing the vulnerabilities of the systems, and implementing proportionate policies will help keep your name out of the papers. In the words of Joseph Stalin, “I trust no one, not even myself.”

This article is authored by Robert Botkin from Womble Bond Dickinson. We received permission from the firm to republish the article for the ADCG community. The original post can be found here.