Is SDP the future of AAA?

   

AA what??? That’s a term I haven’t heard for a while, probably since I was teaching Active Directory 10 years back…, however during a very interesting discussion with a customer about the future of SDP he brought it up. So what is AAA? 

AAA stands for Authentication, Authorization, Accounting. These are the basic requirements of all directories (including AD).  

  1. Allow user authentication – validating that a user is indeed who he/she claims to be. 
  2. Authorization – allow the user to access specific resources according to his/her role and attributes (most directories are using RBAC – Role-Based Access Control, and I’m not going to go into attribute-based access control here). 
  3. Accounting – every action must be audited for compliance and DFIR reasons. (This has really become a huge issue in the last couple of years with all kinds of security analytics solutions crunching the authN/authZ data to detect compromised credentials).  

The flow with the AAA solution is: 

  1. A user gets authenticated (username/password, MFA, etc.). 
  2. Since a user is assigned to specific roles the user is now authorized to access specific services.  
    *Note: this is usually enforced by the services themselves. 
  3. The user’s activities (authentication, authorization and access to resources) are being logged. 

Eventually, the AAA solutions abstract this flow into policies such as “UserX is allowed to access ApplicationY”.  

Now let’s think about the requirements in today’s world

A user actually represents a context of a person accessing an application, and there’s a lot of this context we want to use for the authentication *AND* authorization decisions.  

For example – the person’s location, the device being used, the state of the device and more.  

Same thing goes for the application – what’s the business impact of the application? What operation is the user attempting to perform?  

A simple example – an employee is attempting to access sensitive business plan documents, from an unmanaged device and from a location they’ve never been in before. Simple answer, right? BLOOOOOOOOCK! 

Modern AAA solutions (such as Azure AD, Okta and others) have taken it to this level and they support (some) of these requirements, like device state, IP address blacklist/whitelist, Goe-location based policies, etc..  

Even the modern AAA solutions have three major drawbacks 

  1. They're missing "network level" authentication.
    Your applications have to be accessible at the network level, even if they’re IdP” aware to allow end-users accessThis means you need to open the relevant IP addresses and ports (Web, SSH, RDP, etc’) at the network level, and make them accessible to the end-users even before they are authenticated. Having this open network access is “loved” by attackers (see Verizon’s 2018 DBIR) for scanning, brute forcing and leveraging network level vulnerabilities for gaining an initial foothold in the target organization 
  2. They don’t support “dynamic” authorization. 
    The AAA solutions make a decision only once, and that’s when you’re being authenticated. Once you’ve been granted the authorization (access) token you can use it for as long as it’s alive, even if you’ve switched locations, are accessing a more sensitive application, or have a support ticket which has just been  opened, which gives  you access to a production environment (which normally you can’t access). 
  3. They’re missing the application context. 
    Many applications require different authorization based on the application’s context. For example, executing privileged commands (sudo) in an SSH application maybe allowed only from a managed device, or if a user have authenticated using a 2-factor authentication. Obviously, the same example is also relevant for specific “sensitive” URLs in a web application which may require additional authentication or a tighter access policy. 

AAA solutions don’t (and can’t) “see the application context to determine the operation being executed and can’t enforce an authentication policy based on the specific operation in question.  

What does it have to do with SDP? A lot! 

Until now – all network connectivity was disconnected from the directories AAA model. You had a firewall to allow a source IP:Port access a destination IP:Port. No user authentication, no role authorization and no auditing with user, device or application contexts. 

There were heroic attempts by Network Access Control (NAC) solutions to solve this problem and allow access to the network (aka “The Perimeter”) only once the user (and/or device) were authenticated. Let’s call it “Perimeter authorization”.  

However, in today’s world, where you have apps, services and administration consoles running across 20 different networks (on-premises, cloud, multiple regions, etc.) and you want them to be accessible by your users from anywhere, from any device; trying to make a single perimeter is doomed to failure 

Enter the Software Defined Perimeter, the SDP!  

The main concept of SDP is abstracting the network access (IPs and ports) policies into user /and device and application authorization policies. Instead of applying the IP:Port “Allowed to” IP:Port policy, SDP solutions allow you to create “UserX from DeviceY downloading a sensitive file from ApplicationZ” policy, or “UserX from DeviceY running ‘sudo’ command on a production server”.  

Using SDP solutions actually allows you to extend the AAA model into new realms! 

  1. Your “network level” access is now abstracted enough to fit the AAA model – a user needs to authenticate and is only then authorized to SSH (access port 22) on a production VM. 
  2. You can support “dynamic” authorization – for example that same user, SSHing into a production box, can be validated for device health, location and can even be integrated with a ticketing system, validating that there’s an actual need to access a production server on a Friday night. This is thanks to the authorization decision being “evaluated” at access time (vs. the authentication time of the AAA solutions).  
  3. You can control authorization based on the application context – a user attempting to download a sensitive file, or perform a sensitive operation, within an application while working from home can be blocked immediately, while other operations within the same application are allowed.  

While SDP isn’t replacing the AAA solutions, it does allow you to extend the AAA model into areas which were previously managed with network level policies and solutions.  


Michael Dubinsky, VP Product

Written by Michael Dubinsky, VP Product

Michael Dubinsky is an experienced entrepreneur and product executive leading Luminate’s product strategy and execution. Prior to joining Luminate, Michael was leading the product team for Aorato (acquired by Microsoft) and successfully launched the product as Microsoft Advanced Threat Analytics, achieving wide enterprise customer adoption. Previously Michael held multiple customer-facing roles at Microsoft and HP.