Rethink Your Access Strategy, Think BeyondCorp

Years ago, Forrester declared dead the old security mantra, “trust but verify,” and coined the term zero trust. The argument was that we trusted everything based on an initial successful authentication, but never reallyverified thereafter. Per usual, buzz words like this go through their hype cycle, starting with a lot of excitement and often not resulting in much action in the near-term. Zero trust, and its spin-offs (the application is the new perimeter, etc.) are now making traction in real-world architectures and implementations. A big proponent of this security strategy, Google, has made large strides in implementing it, and has even been so kind to publish their process of doing so. They’ve dubbed it, BeyondCorp.

Google recently published a blog post to tout their 4thresearch paper on the topic, which described how they maintained productivity while going through the long process of migrating. To sum up the BeyondCorp architecture, there is no longer a differentiation between on-prem access and remote access…it’s just access. All authentication and access requests follow the same path through a centralized access gateway regardless of the user’s location or device. However, authentication challenges and access decisions may differ based on a number of risk factors. The gateway serves up authentication prompts, but also allows for fine-grained, attribute-based access control based on a risk profile. This provides consistency and simplicity for users, which is extremely valuable in lessening the likelihood of successful attacks (as I’ve described in past writings).

To illustrate, if a user is attempting to connect to their company’s web app that only has company announcements that may as well be public (low risk), and attempting to connect from their office desk or from their corporate-issued laptop (low risk), then maybe as a security admin I choose to only require username and password for access. But suppose the user is attempting to connect to a financial-related application (high risk), from somewhere in Russia (high risk), and from an unknown device (high risk). I, as the security admin, may have a policy on my access gateway that deems this too risky and denies access, or at the very least, prompts the user for a 2nd or even 3rd factor to verify identity. Furthermore, with fine-grained, attribute-based access control, I may decide to give access requests that match that level of risk a scaled-down form of access…maybe read-only instead of read/write.

Does any of this sound familiar to you? If you use an IDaaS service such as those from F5 partners Microsoft Azure AD, Ping, or Okta, you’re already doing this to some extent. There are other components that make up the BeyondCorp model, however the access gateway is certainly the crux of the entire architecture. Google is now offering up their “identity-aware proxy” (IAP) for other companies to use, but it's not without limitations. Besides only being able to use this with apps on the Google Compute Platform (GCP), some customers noted challenges with granularity and flexibility of controlling access, wishing for configurable session length, per application policies rather than per GCP, and ability to do flexible step-up 2nd factor authentication.

Not coincidentally, F5 offers an access solution that offers these capabilities, and more. And it works for ALL of your environments rather than only apps residing within GCP. Whether completely in the cloud or in a hybrid manner, F5 offers a secure, centralized, and scalable access solution to fit any architecture. To learn more, visit f5.com/apm.