Security Leader's Guide to the Zero Trust Model with Ping Identity and AWS

"Trust no one, Suspect Everyone"

More than just a Cold War cinematic catchphrase,¹ this mantra is a way of life for the security leaders of today. Security pros increasingly are adhering to the zero trust model,² which is based on the philosophy that there should be no implicit trust in a corporate network. As users and devices go mobile and apps move to the cloud, leading enterprises now build networks on the assumption that anyone could be on the network at any time, and they deny open access to corporate resources residing inside those networks.

The old paradigm of a perimeter-based security approach is being replaced by a new one based on zero trust—and it’s a zero trust model with identity at its core.
 

Zero trust has gained added importance over the past few years, and with a distributed workforce, enterprises are moved to a security model that:
 

• Puts user identity at its center.
• Does not rely on the traditional firewall perimeter with VPN. 
• Allows convenient and secure access to resources.
• Provides the highest possible level of security assurance. 

As the zero trust model becomes more widely adopted, security leaders are implementing identity and access management (IAM) controls that grant users access to the network from anywhere while still maintaining tight, centralized security. This is what is known as Identity Defined Security: a security architecture based on identity.
 

So how do you go about creating a zero trust model built upon an Identity Defined Security architecture? By keeping four principles in mind.

All the security controls in the world won't do you any good if you don't know who your user is.

You can no longer count on employees accessing proprietary applications from behind the corporate firewall over computers issued by your organization, or an environment where consumers access your website from a single place. The digital enterprise continues to give employees, partners and customers unprecedented access to applications and data outside the firewall, and it is imperative you move to dynamic and continuous authentication so that you can be sure the user is exactly who you think they are, at all times.

Strong, continuously adaptive authentication is based on a centrally managed system that manages authentication for all resources. It serves up the appropriate level of authentication assurance based on the risk of the transaction. It also embraces continuous authentication, which keeps an eye on changes in behavior or context that would let you know if someone other than the original user assumes control of the session.

Also, just because you know who a user is doesn’t mean the user should have free rein over all your resources. Strong authorization based on a single control layer that determines access policy for each application and application page ensures that not only do you know who your user is, you know the user is accessing only the information and data that you want that particular user to access.
 

Old Architecture: A security perimeter surrounds the organization.
New Architecture: Security based on identity, not on permiter.

The days of relying on usernames and passwords for authentication are long gone. In many organizations, this outdated approach has been replaced with two-factor authentication (2FA), which requires users to submit two pieces of evidence. But recently, numerous assailants have bypassed 2FA measures to make off with the loot—literally. For instance, thieves siphoned German bank accounts in 2017 by redirecting text messages banks used for sending one-time passcodes (OTPs) to phone numbers controlled instead by the attackers⁴.

That’s why a smarter way to authenticate is multi-factor authentication (MFA). MFA best practices also require at least two factors, but the difference between MFA and 2FA is that the factors fall into distinct categories. In order to authenticate, a user must supply something from at least two different categories, such as a password and a fingerprint or a PIN and a one-time passcode (OTP) issued from a hard token. These categories are:

Something you know: typically a password or PIN

Something you have: like a credit card, mobile phone or hard token

Something you are: such as biometrics including a fingerprint, retina or facial pattern

In addition, you can apply risk-based (or step-up) authentication to dynamically assess the risk associated with the request. Using passive contextual mechanisms, such as geolocation and computing environment, allows you to collect data about the user and step up requirements if the user’s behavior falls outside of the user’s typical profile.

To the end user, all flavors of single sign-on (SSO) look similar and do what they need to do: offer a smooth, seamless user experience. But to the security leader, some are far more secure than others, and here is where federated SSO shines.

In the traditional model, enterprises use SSO solutions based on password vaulting and password replay. This simple SSO model has several drawbacks, however. Encrypted passwords aren’t foolproof, and these SSO systems are often homegrown, proprietary solutions that work with a limited number of resources and devices. For a secure mechanism to get to SaaS apps and other resources with a single click, you must look to federated SSO.

Federated SSO replaces passwords with signed assertions (or tokens), which minimize attack vectors. It also takes advantage of standards to securely exchange user information across partners, suppliers and customers, offering organizations better control over who has access to what information and resources, regardless of where those resources live and which types of devices users choose for access. With federated SSO, users authenticate once and then use that authenticated session to access all of the applications they’re authorized to use.
 

Most enterprises have a mess of siloed access and authorization policies that manage access for network, firewall, legacy web apps, APIs, private cloud and SaaS applications. This creates holes in security and is expensive, time-consuming and difficult to maintain.

A better way to manage access is to use a single control layer that determines access policy for each application and application page. A proxy, which protects all resources by executing centralized policies, can use a mix of contextual data to determine whether the user should be authorized to access the resource.

Modern access management (AM) solutions allow you to deploy these gateways for both on-premises environments and for private cloud environments, in order to protect both applications and APIs with a dynamic set of policies that are centrally defined and managed. Using modern identity protocols such as OAuth and OpenID Connect provides assurance that security best practices are followed to defend against today’s and future threats.

When building a zero trust model, these four principles—putting identity at the center of a network protected by MFA, federated SSO and proxy servers—are best practices for strong network security in a world where employees, partners and customers are accessing applications and APIs on premises and in the cloud.

To be sure, other technologies play a role in securing your network (and you can learn more about those technologies from an organization of solution providers who have formed the Identity Defined Security Alliance), but the best practices highlighted here in this guide can and should be a cornerstone of your enterprise’s zero trust model.

To see how Identity Defined Security can secure your enterprise credentials, applications and data, please watch our video Identity Defined Security with the Ping Identity Platform.
 

Ping Identity and AWS have teamed up to bring robust identity and access management (IAM) solutions on the AWS Cloud. With Ping Identity, you can deploy your identity security infrastructure on AWS and:

1. Incorporate AWS services into your identity ecosystem

Bring new AWS services into your environment without worrying about how authentication will work. Ping Identity integrates with the most widely adopted AWS services to meet your cloud and identity needs as you expand your cloud presence and add new capabilities, users and locations.

2. Secure the largest migrations on AWS

Make your move to the cloud with confidence by partnering with experts in identity management and AWS. Our team has extensive history solving the most complex authentication use cases for global enterprise customers that deploy on AWS.

3. Scale identity services in record time on AWS

Accelerate your digital transformation in the cloud with a custom identity and security solution. Ping supports business-critical identity scenarios with enterprise-proven scalability, availability and manageability that protects you as you evolve.

4. Procure Ping solutions via the AWS Marketplace (here)