DAP Overview
DAP or Dynamic Access Policies is a technology included in all ASA images used specifically for remote access VPN. As the name implies, DAP can be used to dynamically apply policy to specific remote access VPN connections based on any number of criteria. Although relatively straight forward to configure, it is seldom used in the real world. Many of the possibilities with DAP are simply deemed impossible and an alternate solution is chosen. This blog post will go over some things you can do with DAP and the appropriate VPN licensing.
Apply Multiple Access Lists
What? That’s impossible? Right? Even if it is possible, why?
Glad you asked. Let’s take a look at Acme University. Acme is a conglomerate of 30+ departments and colleges that all run their own IT departments. Acme uses a global single AD Domain for all colleges and individuals are placed in AD Groups based on their college affiliation. Acme would like to deploy remote access VPN and ensure only users within a given college can access the internal resources of that given college. Easy enough…
We can simply use VPN Groups and assign an access list to the VPN Group. In other words, if you are in the Mathematics department, you enter the Mathematics VPN Group, and are assigned the Mathematics Access List. We can even streamline this by using a backend RADIUS Server such as Cisco ISE to automatically assign the VPN Group or DACL based on the group membership. It’s a walk in the park.
Oh Oh! Acme is telling us that our plan is not going to work. The reason is many instructors teach in multiple departments. Take a second and think that all the way through. It’s rather complicated when you get down to the nitty-gritty. Let’s make it even tougher. Acme doesn’t want additional internal processes to create custom groups every time a new instructor is hired. Finally, we’ll even go a step further and say, “There is no pattern such as Mathematics goes with Physics” and there is nothing saying a single instructor cannot be in more than two groups.
If you paused and did the little thinking exercise, you likely considered creating groups for each possible combination and having those groups pre-staged. E.g. If you hire Bob for Mathematics, Chemistry, and Physics, put him in the AD Group “Math-Chem-Physics”. After a few more seconds, you likely came to the conclusion this is not feasible as the number of groups rises exponentially.
For Example:
Group 1
Group 1 + Group 2
Group 1 + Group 3
All the way through to Group 30. But we are nowhere near done!
Group 1 + Group 2 + Group 3
Group 1 + Group 2 + Group 4
Etc…
DAP Solution
While DAP records are run top down, they do not stop when a match is made. This is the key to the solution. DAP also has a mechanism in place to concatenate ACL Entries (ACES) into a new, dynamic ACL. The logic regarding permits, denies and priorities is a little complex, but the bottom line is the same. A quick way to skip all the complexity is to write your ACLs with only Permit Statements and use an explicit “Deny All” in your final rule.
You can build your DAP Policy like this (Logically), we’ll just use three groups:
Rule 1: If user is in Group 1 apply ACL 1
Rule 2: If user is in Group 2 apply ACL 2
Rule 3: If user is in Group 3 apply ACL 3
Rule 4: If a user is in any group apply the deny all
If a user is only in Group 1, Rule #2 and Rule #3 do not match and are ignored. Thus, the user only gets the Group 1 ACL. If a user is in Group 1 and Group 2, a new ACL is created specific to that user at the time the login occurs. Both Group 1 and Group 2 ACLs are combined into one. Of course, if a user is in all three groups, the ACL will be the combination of all three ACLs.
Instead of hundreds or thousands of VPN Groups and/or DACLs if using ISE, our entire policy is a single VPN Group with 31 DAP entries.
Corporate Owned Workstations
So, you have an absolutely excellent security group, and they do an absolutely excellent job of ensuring all workstations are up to date, have the right security software (AV, AM, Etc..), and those viruses don’t stand a chance!
The problem is, you can throw all that security policy out the window if your VPN solution is not limited to workstations you control. There is no mechanism, by default, that is capable of differentiating my corporate owned endpoint from my personal PC or even my mobile phone. For perspective, if your ASA is just doing AD authentication or even 2-factor with a MFA provider, there is nothing stopping me from logging into the VPN with my wildly infected Windows 98 PC. If you don’t have a next-gen firewall or full security stack between the VPN ASA and the internal network, you have a sad story. Not to mention the fact I can simply download every file you have on the entire network and there isn’t much you can do about it.
The Gold Standard solution is to utilize Cisco ISE with a posture check. Once this in place, you can watermark corporate owned endpoints. For example:
File: The workstation must have a single file on the workstation. A quick check would be something like adding an official sounding text file in the Windows folder somewhere, and then removing the .txt extension. If you would like to be fancy, you can put an encrypted file somewhere and then match the hash of the file. This solution is “Security by Obscurity”, and many would argue that is no security at all. However, I’m not one of them😊. There are a few reasons:
You can change the file whenever you want and configure ISE to accept the old or new file for a given period of time.
You can create additional policy that checks for additional applications such as Anti-Malware, a specific corporate application, or even a home-grown app that would never be on a personal PC.
The solution does require full, 2-factor authentication (AD Creds + Code) and the “3rd factor” is just a bonus.
I’m sure you see the point, and you can make the posture policy as simple or as complex as required. It could be a file, application, registry key, whether an application is running or not, the list of possibilities is endless and can be utilized in combination.
You can also use ISE as a secondary authentication mechanism and use a machine certificate as the primary. This can work well but requires certificate authentication and can be difficult to configure and confusing for the end users.
DAP Solution
You can use DAP to do the basic check on the workstation for the watermark. This is very easy to configure and does not require a separate Anyconnect module on the workstation. The “module” is there, but it is an extremely small footprint and is completely transparent to the end user.
This policy simply states if the file is NOT present, then apply a custom ACL named Personal-PC.
The biggest advantage to using DAP for this purpose is, it is easy to define policy for a corporate owned endpoint vs a non-corporate owned endpoint. There is no distinct difference, like there is in ISE, between a compliant workstation, an unknown workstation, and a non-compliant workstation.
Logically, the policy can be written like this:
If your AD Credentials are good AND your 2-factor is successful AND you have the watermark, THEN apply ACL Full-Employee.
If your AD Credentials are good AND your 2-factor is successful AND you DON’T have the watermark, THEN apply ACL Personal-PC.
The process is faster than the ISE Posture and does not require any interaction from the end user.
If you'd like to continue the conversation, contact us today!