Ask any CISO about a trend that they think will help push security postures forward and you’ll inevitably hear the same thing: the elimination of the perimeter and the rise of the zero trust mindset. In the old perimeter model, users were typically only authenticated once to access the network, while with many zero trust approaches users are much more frequently authenticated. However, this creates a clear challenge of “usability vs. security” that every CISO is all too aware of: using short enough session times to reduce risk while at the same time not causing too much user friction by asking them to log in constantly. What if we could do away with that friction entirely and provide continuous authentication of users by bringing together two different technologies?
Being able to continuously authenticate users’ access to critical web and API services without causing them to pay the price of increased friction may sound like a lofty goal, but it can be achieved through the integration of technologies you likely already have. By combining technologies built to continuously monitor applications and APIs for attacks and anomalous behavior with identity technologies already deployed to authenticate users give administrators the ability to protect their critical applications without unduly inconveniencing the user.
How Zero Trust Works—And Why It Often Doesn’t
The zero trust model is a response to a breakdown in traditional perimeter-based security models. While everyone is familiar with the failures of the historical perimeter-based model, certain trends have accelerated businesses towards a future where zero trust is badly needed—whether they want to or not. Specifically, this shift has been driven by the combination of historic trends, like BYOD and mobile workforces, and accelerated by the effects of digital transformation and a global pandemic, necessitating the ability for workforces to be able to work from anywhere in the world. All taken together, these macro forces have resulted in organizations unable to rely on historic perimeters and, instead, needing to be able to authenticate and authorize users regardless of their physical or network location.
Zero trust seeks to allow exactly this change. By no longer tying the ability to authenticate to a user’s physical location inside a corporate office building, but instead, allowing them to authenticate from home or anywhere else in the world, it allows businesses to function in the modern landscape we all find ourselves in.
However, in practice, this leads to an uncomfortable risk scenario for most organizations. Current approaches to zero trust authenticate and authorize users only at the “front door” when they first attempt to use an application or API, but then, they’re stuck making an uncomfortable choice on monitoring risk going forward. What happens when an attacker has stolen a user’s credentials and successfully authenticates, but now downloads highly sensitive corporate data, like source code, HR data, or internal emails? Or where a legitimate user authenticates, but because they now work from a home device without corporate endpoint security controls their session is stolen by an attacker who now attacks and compromises all the sensitive internal services the employee had access to?
Due to the lack of coverage over the applications and APIs being used, there are only two approaches to covering risk like this in today’s zero trust world: either make the user re-authenticate every few minutes (which will lead to a revolt by users), or allow them to authenticate themselves only once a week or month which makes for happier users, but does nothing to stop the threats they face.
Clearly, there needs to be a better way forward of continuously authenticating users without driving them crazy.
Enabling The Future of Zero Trust With Continuous Authentication
In order to truly be successful, security teams need to be able to monitor the applications and APIs users are accessing and pair that visibility with their identity solution. So that if anomalous behavior occurs, it can trigger re-authentication only when necessary. The goal is to use authentication throughout the session to ensure security—but in a thoughtful and limited manner, to avoid unduly burdening the user. The key is to know when a re-authentication has actually become necessary due to some malicious or simply anomalous event taking place. This is where the combination of identity technology with application and API protection technology comes into play.
A missing key piece of what will enable a continuous authentication future is the ability to connect real-time monitoring of applications and APIs that users are accessing. On their own, whenever an application and API protection technology detects an attack or behavioral anomaly in the way the application or API is being used, it can flag this activity, block it, and generate an alert. But there’s an opportunity to do something much more powerful here. This information can also be used as a signal that a user session has become suspect. By integrating identity technology and application and API protection, it can signal to the identity provider to apply a more rigorous re-authentication whenever one of these alerts is triggered—disrupting any attack that might be underway. Conversely, if there is no sign of anomalous behavior, users can be allowed to go longer between re-authentications, providing a better user experience without compromising security.
What Mitigating A Real-World Attack Scenario Looks Like
Consider how this might look in a real-world attack. An attacker has guessed an employee’s credentials or stolen their session via malware, and once logged in, the attacker identifies a sensitive enterprise application to target. The attacker accesses that target application and notices that there is a predictable ID in the URL, thereby changing the ID value they’re able to access the sensitive HR data of other employees. They write a script to iterate through all the IDs pulling down confidential HR data for tens of thousands of employees globally for the company and then hold the company ransom threatening to publish this information externally. From an identity perspective since they had authenticated correctly with the victim employee’s credentials, there’s nothing that would have stopped the attacker from performing this attack in today’s world of only authenticating the user at the “front door.” However, by integrating the identity solution with technology protecting the applications and APIs, this sort of breach can be thwarted. As soon as the attacker attempts to enumerate other employees’ data, the application and API protection technology blocks the attack and sends an event to the identity solution, which then triggers an escalated set of re-authentication prompts, locking the attacker out entirely.
The Way Forward: Better Together
In essence, using application and API protection in tandem with identity solutions means being able to achieve the dream of zero trust and continuous authentication today. By continuously monitoring applications and APIs for attacks and behavioral anomalies and then triggering more rigorous re-authentication whenever attacks or anomalies are detected, you can avoid impairing usability—and burning bridges with the rest of the organization— while maintaining security. Luckily, both of the building blocks for this approach already exist, and by finding ways to integrate them, we can turn the powerful dreams of continuous authentication into reality.
Zane Lackey, Signal Sciences CSO, also contributed to this article. Zane is CSO and co-founder of Signal Sciences. Prior to co-founding Signal Sciences, Zane led a security team at the forefront of the DevOps/Cloud shift as CISO of Etsy and is the Author of “Building a Modern Security Program” published by O’Reilly. Follow him @zanelackey