Editor’s note: This is the first in a series of posts about how Palo Alto Networks implements Zero Trust Network Access (ZTNA).
Picture this: an attacker has stolen the credentials of one of your employees. They may have purchased the information as part of a breach or phished the employee. Next the attacker logs in to your company and quickly accesses as many sensitive resources as they can, pilfering as much as they can.
This type of scenario is common. As attackers have grown more brazen, tight controls based on zero trust identity principles must be implemented to ensure adequate protection. The Cybersecurity and Infrastructure Security Agency (CISA) considers identity to be one of the five pillars of zero trust security. The National Institute of Standards and Technology (NIST) also puts a heavy focus on identity in NIST 800-207, the definitive standard for zero trust implementation.
For any large enterprise, implementing zero trust comes with myriad challenges. At Palo Alto Networks, when it comes to identity, we wanted to harden the way our users authenticate to our environment and align more closely with NIST guidance so that we can further improve our security posture.
Seeing as this post is only focused on identity in a Zero Trust environment, it should not be treated as a panacea for a broad zero trust implementation. There’s a significant amount of additional work required to implement zero trust as described in NIST 800-207, and you’ll need a strong background understanding of zero trust principles. This post assumes you have an advanced understanding of zero trust architecture. For those less familiar with zero trust, bear with me, I think you’ll learn a lot.
Our Approach to ZTNA 1.0
To enhance our zero trust identity strategy at Palo Alto Networks, we had to consider how we were applying our authentication policies. The new policies we create needed to better align with both NIST 800-207 and NIST 800-63B to provide a robust and streamlined authentication experience for our users.
Prior to developing our new policies, what is described in tenet 4 of NIST 800-207 (see section 2.1) was only loosely applied. Tenet 4, as described in NIST 800-207 states that:
Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
We had some dynamic policies in place; however, it was not flexible enough and did not account for the behavioral aspects of an authentication request. We changed our policies so that a “trust score” would be calculated to inform policy enforcement decisions.
To make the changes, we focused on these key areas:
- App-ID
- User-ID
- Authentication policies linked to our IdP
- HIP checks
- Policy changes in our IdP
- A revised multi-factor authentication (MFA) strategy
After we had rudimentary App-ID and User-ID controls in place, we had significantly more visibility to the traffic flows in our environment. This led us to profile our data flows so that we could make informed decisions about the logical locations of applications, application groupings, and to ensure that all control, management, and data plane traffic was adequately separated.
Using the data, we were also able to better determine if a traffic flow was expected. If something was unexpected, we have a number of controls we can use to maintain flexibility. The simplest would be to deny the unexpected flow. We can also prompt the user for multi-factor authentication if certain criteria are met.
Once we had all of this in place, we were able to further restrict traffic to protect our network and applications. For example, all database access is restricted with a least privilege model on both the application level and the network level.
We were able to block all unnecessary SMB traffic. SMB is a common protocol that is abused for exploitation and lateral movement. Restricting these flows makes it more complicated for an attacker to move around the environment without getting noticed.
Another outcome of the initial exercise was that we were able to restrict all SSH and RDP traffic unless it originates from jump hosts. The end result is that the most commonly abused protocols are forced through a bottleneck for heavy monitoring.
HIP profiles are an important part of our strategy. Our HIP profiles help to ensure that devices on our network are not only ours, but are reasonably healthy. If a device is found to be non-compliant with the checks performed, network access from that device is restricted until the issue(s) are corrected. A few examples of things we find important are: Is the drive for the machine encrypted? Is the device running real-time protection (in our case, Cortex XDR)?
Where We’re Going: ZTNA 2.0
We reworked the policies in our IdP to ensure that they conformed with our internal data classification standards and NIST 800-63B authenticator assurance levels. These changes also resulted in us rethinking our MFA strategy.
With phishing being the easiest way to infiltrate an enterprise, organizations realized that one way to thwart subsequent infiltration based on credentialed attacks was to implement MFA. This led to attackers developing ways to phish one of the most common MFA mechanisms: time-based one-time password (TOTP). If you’ve used an app like Authy or Google Authenticator, then you are likely already familiar with TOTP. For the curious, Evilginx2 is a tool commonly deployed to phish TOTP.
While TOTP does add a significant amount of protection as opposed to something like SMS (SMS is considered a RESTRICTED MFA mechanism as per NIST 800-63B), it is still something that can be phished. This brings us to FIDO2 and security keys, which are phishing resistant. The phishing resistance of FIDO2 stems from the way FIDO2 functions. A FIDO2 credential is scoped only to the site for which it is destined (webauthn, CTAP).
After we deployed security keys to our users, any phishing attempt of these users was thwarted. This is the kind of excellent result that aligns our strategy with the executive order from the White House regarding zero trust and strong authentication mechanisms. (OMB Zero Trust principles, Executive Order)
Scenario 1: High Risk
So how does this look in our environment?
For instance: if something is classified as a trade secret, then it is protected using authenticators that confirm with NIST 800-63B AAL3. Access to this resource would be restricted to specific network segments, specific users or groups, and require that the “trust score” for this transaction is low risk.
If all of those checks are green, the user would be prompted for their second factor for authentication. In this case, that second factor is limited to a security key that supports FIDO2. In order to comply with NIST 800-63B AAL3, PINs are enforced on the security key. For the user to authenticate they must not only tap their security key, they also have to enter their FIDO2 PIN to proceed.
Criteria that would be evaluated in order for the subject to proceed to the resource:
- Trust score is low risk
- Calculation based on factors such as:
- Device age (new device or not)
- Geo-location
- Velocity
- Calculation based on factors such as:
- User is in a group that allows access to this application
- Device is a Palo Alto Networks managed device
- HIP check has passed
- Network location is an acceptable PANW network location
- FIDO2 authenticator used to authenticate
Below is a non-exhaustive list of the criteria in place that would deny a request to the example resource:
- A trust score that would equate to anything greater than low risk
- This is calculated with a number of criteria that relate to user behavior
- Unauthorized user/group
- Unauthorized network segment
- Device is not Palo Alto Networks issued
- Operating system type is not a mobile OS
Scenario 2: Medium Risk
Here’s a more nuanced example: we may deem an application to be something that contains restricted information, but would not rise to the classification of trade secrets. For the sake of simplicity, let’s look at GMail.
To maintain productivity, this is an application that we cannot restrict in the same way that we would a code repository. Our users expect to be able to connect to GMail from their mobile devices. Some of the policy-based decisions to grant access would be:
- A trust score that would equate to medium or below
- Connection attempt is not coming from a blocked network region (ex. Tor nodes, embargoed countries, proxies, etc.)
- User is authorized to use the application
- Palo Alto Networks device vs. BYOD
- This can change the acceptable MFA mechanism and influence the trust score
As an additional layer, administrators of the application would be subject to a different set of policies. A non-exhaustive list of policy decisions for administrators would be:
- A trust score that is no greater than low
- User must be coming from an authorized network location
- Device must be a Palo Alto Networks issued device
- User must use a FIDO2 authenticator
- Operating system type must be on the allowed list
We can apply different rules and requirements based around the calculated trust score to ensure that we have proper attestation from our users.
NIST is the North Star
Using NIST as our guiding principle, we were able to develop changes that bolster security, reduce the opportunity for phishing attacks, streamline user access, and ensure uniformity. Leveraging APIs from our IdP allows for applications to quickly be onboarded into their correct “bucket”. This bucketing, based upon our internal data classification standards, gives us the ability to track and immediately remediate any configuration drift using XSOAR playbooks. Of course, our Zero Trust identity strategy is not a done deal. One priority for us is getting App-ID deployed 100% across our environment.
We would also like to use Dynamic User Groups (DUGs) in conjunction with Cloud Identity Engine to dynamically move users into and out of groups. We can use these group memberships to help better inform our authentication policies in our IdP.
To augment our HIP profiles, we are considering adding a number of custom checks. Some ideas for what we might look for would be custom values in the Windows registry or a plist on a MacOS device, and performing additional checks of running processes on the host. These changes will also help drive DUG memberships, and ultimately IdP policy decisions.
Working through this, we need to keep in mind that User-ID cannot be deployed 100% across an environment, because there are instances where it does not work. For example, with machine to machine communications we must rely on alternative mechanisms to inform access decisions.
All of this is to say that as our products continue to evolve, we are constantly seeking ways to utilize newly introduced features to better secure our environment.
One more thing that we would like to see in the near future is direct interaction between our IdP and our threat prevention tooling. The benefit of having this type of integration would result in more detailed trust scores, which will result in better policy decisions for our customers. These policy decisions will have a positive impact on security posture and experience for users.
P.S.
If you’d like to learn more about zero trust, here are some great resources:
Palo Alto Networks Zero Trust Reference Architecture
CISA Zero Trust Maturity Model
US DoD Zero Trust Reference Architecture
