BeyondCorp: Creating Access Policies
In our first blog post introducing the BeyondCorp concept, we discussed what organizations should think about when trying it for themselves. The steps may not happen in sequential order, but they are generally:
- Enrolling your users and their endpoints
- Deploying certificates to identify trusted devices
- Setting up the access proxy and its policies
In this post, we’ll talk about creating access policies. Your access proxy takes on the role of enforcing access to corporate resources, regardless of whether they’re outside or inside your traditional perimeter. Enforcement strategy is one way we express risk tolerance; rightsizing those policies depends on factors such as sensitivity, threat, user community, regulatory requirements, and any number of other things. And enforcing policies consistently for both sides of the firewall is a key tenet of the BeyondCorp model.
More Than A Multipass
Your access policies are much more flexible than a stop-or-go approach. Like a multi-use tool, you can use them to bludgeon, nudge, slice, or tap. Here are some of the types of access policies to consider.
- Warning - strongly recommending or requiring action at some point in the future.
- Blocking - the heaviest of the policies, preventing access entirely.
- Logging - taking note of a condition or event.
- Mitigating - loosening or reversing the effects of another policy based on certain risk scenarios.
- Responding - taking short-term actions to react to a particular situation.
Warning
You can use warning policies to drive behavior. A warning is a reminder with a little weight behind it: if you don’t do what the reminder says, sooner or later you will suffer a consequence. For example, most organizations put a grace period in their policies to give users time to update their software before they’re either forcibly upgraded, or they’re blocked until they catch up.
Using Duo Beyond as an example of the BeyondCorp model, a simple policy that results in a warning might look like this:
So if a new version of a particular browser comes out, your users have one month to upgrade to it, or be blocked after that grace period has expired.
If your warning policy has no consequence attached to it — that is, the user may override or ignore the warning every time — then it’s little more than an irritating flag that pops up in the middle of that user’s workflow. And if the warning is about something that the user can’t take action on, it’s even more frustrating. If a system can’t be updated because of some other dependency, then the warning serves no purpose and just trains the user to ignore the irritant. When it comes to access policies, make sure that you’re asking for a concrete action that’s within the recipient’s capability, and be prepared to take an enforcement action within a reasonable time period based on your risk estimates.
Blocking
A policy for blocking is best suited to situations where you don’t have wiggle room. For example, Duo customers such as KAYAK want to block access to critical applications from non-managed personal devices. Either the device is corporate-owned and “blessed,” or it isn’t. In Duo Beyond, the policy looks like this:
Many organizations are interested in blocking based on geolocation. If you are quite sure that you never need to allow access from certain regions, a general block will work, but that’s not always an option if you do business with them or you have users who travel there. Bear in mind that blocking based on IP address or a derived geolocation won’t necessarily protect you from a determined attacker who can spoof those things, but in general, it can work as a filtering mechanism for large segments of the population who should not even be trying to authenticate to your applications.
Mitigating
There are some policies that are used to mitigate the effects of other policies. Multi-factor authentication is an important security control, but some users don’t like having to use it every time they need to use a resource. An organization may decide that after the initial authentication to a system, the risk is low enough to delay re-authenticating for a certain period of time. One example of this is “remembering” a user or device, or both. For Duo, you would set a policy like this one:
Another possible mitigating policy is to skip the second authentication factor for devices on particular trusted network segments. However, once you begin trusting something more when it’s on the “inside” of your network perimeter, you’re in danger of undermining what BeyondCorp is all about: the idea that you shouldn’t trust the inside any more than the outside. So use these “loosening” policies with caution.
Responding
Organizations can also put temporary policies in place to respond to a particular event. If a critical vulnerability is announced for a plugin, for example, and you know your users are at risk because the vulnerability is already being exploited, then you may want to block users until they get the patched version installed. In other words, you would shrink the time window or grace period of a regular policy for just this one situation.
Other response-type policies could include placing geolocation or network restrictions on a device that someone can’t find — until they either find it again, or determine that it was really lost or stolen. If they find it where they expected, they can use it again right away, but if someone else tries to use it from a different location, they won’t be able to access corporate data with it. The same idea applies to an employee who is leaving; while they work out the notice period, their access policies might be tightened so that they can’t access applications that contain large stores of sensitive data.
Managing Exceptions To Policies
(also known as: “Negative. I am a Meat Popsicle.”)
For every policy, there is an equal and opposite exception. There may be good reasons why a set of endpoints can’t be fully updated: they don’t have regular access to enough network bandwidth; they’re dependent on one application that requires a certified stack to operate; it’s too politically sensitive to block your CEO even if she rooted her own phone. You never allow traffic through an anonymized proxy, except that one time when an employee is traveling abroad and can’t access some home resources any other way.
Strictly speaking, a firewall is an exception in itself: you know it’s risky to connect to the Internet, but you do it anyway because there are strong business reasons to do so. The firewall embodies and manages those exceptions (“Okay, but only for web applications …”). For your users, have a workflow process ready to receive exception requests, and for yourself, be ready to record and approve them with reminders to follow up if the policy exceptions are only temporary.
Another purpose for adding policy exceptions is to introduce change over time. You may have stricter policies in place for a smaller user group to try them out before deploying them to the rest of the population. Exceptions can also help to troubleshoot all sorts of problems if you suspect they’re being caused by an access policy: for the one user, you create an exception for each policy in turn that you know is being applied to them, until the guilty one surfaces (or all of them are ruled out).
From The Big To The Small
Access policies can be used not only at the network and application levels, but also at the device and behavior levels. You can start by blocking access to whole categories of outliers (such as banning any use of an insecure browser), and then work your way towards requiring better endpoint hygiene, such as screen locks. In the case of Duo Mobile, you can require your users to validate their two-factor authentication (2FA) confirmation with a fingerprint on iOS, so that even if an attacker has access to the unlocked phone, they still can’t finish logging into the application.
The most important thing is to carve away at the devices, software, sources and behaviors you know you don’t want to allow, thereby reducing your exposure to attacks. Changing the security lifestyle of an organization takes dedicated work, but once you have the controls fit more closely to where they belong — the users, their devices, and the applications — then you’ll be addressing the gaps in today’s traditional security paradigm and moving Beyond it.
For more information on how to create access policies within Duo, check out this Duo Policy Guide.