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. 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. Many organizations are interested in blocking based on geolocation. In Duo Beyond, the policy looks like this: Either the device is corporate-owned and “blessed,” or it isn’t. For example, Duo customers such as KAYAK want to block access to critical applications from non-managed personal devices. BlockingĪ policy for blocking is best suited to situations where you don’t have wiggle room. 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. 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. And if the warning is about something that the user can’t take action on, it’s even more frustrating. 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.
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. Using Duo Beyond as an example of the BeyondCorp model, a simple policy that results in a warning might look like this:
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. 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. You can use warning policies to drive behavior. Responding - taking short-term actions to react to a particular situation.Mitigating - loosening or reversing the effects of another policy based on certain risk scenarios.Logging - taking note of a condition or event.Blocking - the heaviest of the policies, preventing access entirely.Warning - strongly recommending or requiring action at some point in the future.Here are some of the types of access policies to consider. Like a multi-use tool, you can use them to bludgeon, nudge, slice, or tap. Your access policies are much more flexible than a stop-or-go approach. And enforcing policies consistently for both sides of the firewall is a key tenet of the BeyondCorp model. 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. Your access proxy takes on the role of enforcing access to corporate resources, regardless of whether they’re outside or inside your traditional perimeter. In this post, we’ll talk about creating access policies. Setting up the access proxy and its policies.Deploying certificates to identify trusted devices.Enrolling your users and their endpoints.The steps may not happen in sequential order, but they are generally: In our first blog post introducing the BeyondCorp concept, we discussed what organizations should think about when trying it for themselves. Industry News March 29th, 2017 Wendy Nather BeyondCorp: Creating Access Policies