In my first blog post I shared that I joined Ping to help lead the security revolution, encouraging the enterprise world to abandon the old perimeter-based security paradigm. Now, I'd like to dive into the key components of the Identity Defined Security model.
In a traditional security paradigm, we rely heavily upon the corporate perimeter to secure our critical assets. But there are a number of elements that have been weakening the perimeter-centric approach to security, most notably the dissolution of the perimeter as a meaningful delineation. The ever-increasing speed to push out into SaaS and IaaS solutions, combined with B2B mobile apps being used for business critical functionality, means that information assets increasingly reside outside the borders of our firewalls. Companies that cling to perimeter security controls find themselves using tools that simply aren't capable of accomplishing the task.
In place of the perimeter, we propose Identity Defined Security. In an identity-centric model, we assume that the internal network is no more secure than the Internet, and therefore, should be treated no differently.
Google gave us their model implementation of this in BeyondCorp. At Ping, we've created the Identity Defined Security Alliance to show how an organization can leverage collaborating technologies to support the flexibility of a cloud-enabled IT environment and the security of an internally controlled network. Better yet, we believe Identity Defined Security improves security while enhancing usability.
Let's take a look at the anatomy of Identity Defined Security:
Zero Trust networks. The idea of a corporate network with implicit trust is gone. We build all corporate networks with the assumption that anyone could be on the network, and give no open access to our corporate resources.
The key components of a Zero Trust network are:
Employees have open access to it over the public Internet, with no VPNs, ever.
If an unauthorized user accesses the network, you won't be concerned about it.
Strong endpoint controls. Properly configured resources can limit the damage done by a compromised endpoint, but the risk is always real. Once a bad actor has control of a system, they can find ways to view and change data in an unauthorized manner. In order to have confidence in our security posture, we must have assurance that the devices that connect to our critical assets are secure.
The key components of endpoint security are:
Device identification (is this a device we trust to access our resources?)
Controls against malicious software (are we appropriately blocking antivirus, anti-malware, application whitelisting, etc?)
Configuration management (are we maintaining OS and third-party patches?)
Strong, continuously adaptive authentication. The basis for all security is in authentication. It's a fundamental truth: If we don't know who the user is, we can't provide secure access. Yet, we've been working with outdated authentication mechanisms for decades. The password as single-factor authentication upon initiation of the transaction is still the norm out there. But it's simply not good enough for many use cases.
The key components of adaptive authentication are:
A centrally managed authentication system that manages authentication for all resources.
The appropriate level of authentication assurance based on the risk of the transaction. A simple username/password may be sufficient for low-risk activities, but multi-factor authentication is probably necessary for higher-risk activities. And for the highest-risk activities (like a high-dollar financial transaction, or an attempt to download the entire source code repository) we may even want another level, possibly with two-man authentication.
Continuous authentication throughout the session. Just because it was Robb at the beginning of the session, doesn't mean it's Robb now. Continuous authentication keeps an eye on changes in behavior, or context that would let us know if someone assumes control of the session.
Explicit access controls on external-facing resources. Exposing our internal resources to the Internet is scary. But with Zero Trust networks, this is how all our employees will access resources.
The key components of external resources are:
An access proxy sits in front of the resources and is the only way to access the resources.
The proxy supports an advanced rule set that determines which devices and which identities are allowed access.
Continuous access security to enforce additional authentication steps for higher-risk activities.
Behavioral analysis to let us know when a user is acting suspiciously. Did Robb just go from trustworthy employee to insider threat?
The ability to dynamically reduce user authorizations in response to anomalies discovered by the behavioral analysis tool.
Applications that can communicate with the authentication system to identify when high-risk activities are being performed.
In the coming months, I'll dive more deeply into each of these topics and talk about methods for implementing these controls. If you're looking for more information on this topic, you should seriously consider attending the Cloud Identity Summit in New Orleans June 6-9, where you can attend several sessions about the Identity Defined Security Alliance and architecture. If you're ready for more right now, check out the white paper, A Modern Identity Architecture for the Digital Enterprise, written by Pam Dingle.
The move to this paradigm doesn't require a complete abandonment of the controls and technologies we've been using for the last decade. Rather, it's a shift in our emphasis. We've been responsible for endpoint security and IAM for decades, but they've frequently taken a backseat to network-based controls that depend on a strong perimeter. In the future, instead of security being the "firewall folks," we need to be the known as the "trusted access team."
As always, I would love to hear from you if you have thoughts, suggestions or questions. You can reach me directly at CISO@pingidentity.com.