Implementing Conditional Access: How to Challenge Authentication Traffic
A cornerstone of IT networking utopia is the free flow of information, which under the covers means the free flow of network data. That might sound great in theory, but life doesn’t exist in a vacuum and the real world is full of bad people who do really bad things.
The reality of our modern IT networks is:
- You can’t trust any account or any device
- Way too many resources are protected by simple, easy-to-crack passwords
- Human analysis of possible security events is slow and out-of-band
- Most networks have already been compromised in some fashion, or will be soon
So what are modern, forward-looking security teams doing? Many of them are creating security initiatives to manage their authentication traffic and implement conditional access. By doing so, they are ultimately given the option to challenge and/or block authentication traffic, which is a relatively new concept.
You might be thinking: “We have firewalls and intrusion detection systems, we block network traffic all the time!” Yes, but how often are you actually blocking authentication traffic inside your network? The actual part of the network traffic where a user identifies themselves, either via a password and/or multifactor authentication (MFA), has traditionally been enough for “secure identity management”.
… But is it really? There is a lot more “authentication stuff” occurring within network transactions than most non-IT folks realize. Take your typical Microsoft Active Directory environment for example: As users seamlessly move about the network, using different web servers and running different applications, their machines and software are constantly authenticating to Active Directory Domain Controllers on their behalf using standard methods like NTLM, LDAP, and Kerberos. When good people are simply doing their jobs, all this authentication normally works great.
But what about when it doesn’t? What happens when bad programs create malicious network authentication traffic? Do Active Directory Domain Controllers (DCs) know when they are receiving authentication requests from good folks and applications versus bad ones? The answer is no. As it turns out: It’s even easier to circumvent Active Directory security than most of us realized.
Another reality of today’s network is the migration toward cloud computing. Whatever solution we implement must also integrate tightly with our current and future cloud strategy, as well as all the hybrid options along the way. Most organizations are moving away from multiple IDs and toward a Single-Sign-On (SSO) implementation, with their AD credentials being their single Identity to access applications and resources located both on-premises and in the cloud. Because of the complexity of cloud migration, securing and managing Active Directory authentication becomes more important than ever.
The solution that many security teams are moving towards, slowly and sometimes even reluctantly, is to force all Active Directory authentication traffic to flow through some type of decision and analysis engine prior to traffic reaching DCs. This analysis occurs in either active or passive mode, with active mode having the ability to block any authentication based on policy, as well as the capability to require successful MFA before releasing authentication traffic to a DC. This analysis should also involve machine learning functionalities to build a baseline of normal behavior for accounts and machines — so teams can differentiate risky activity from normal activity — as well as detect identity-based attacks like Pass-The-Hash, Golden Ticket, Kerberoasting, etc.
Why are some security teams moving toward this type of a solution reluctantly? Because in order to analyze AD authentication traffic, in real-time and prior to the traffic reaching DCs, you’ll need to deploy either an agent on your DCs, or deploy some type of proxy server that requires the re-routing of DC traffic. Historically, both ideas have been heresy to AD administrators, but that’s slowly changing… because really, what other options are there?
Microsoft has known vulnerabilities in their authentication methods, and compromising a network is not that difficult, thanks in part to email phishing attacks and human gullibility. Many security leaders realize that we need to move toward analyzing AD authentication traffic in real time, and this secure authentication management process needs to become part of our standard Identity & Access Management (IAM) programs. Will there be resistance? Of course, but again we need to move forward in order to keep up with the bad guys. As a white hat hacker recently explained: “You’re never going to stop me from getting into your network. All you can do is detect and contain.”
What can we do once we have the ability to analyze AD authentication traffic in real time? We can now implement a Conditional Access program, one that allows us to contain bad actors by preventing them from moving around our networks. Part of this Conditional Access functionality requires the ability to make decisions based on the behavior and risk scores of accounts and machines, which we can now do, in part, through the analysis of live authentication traffic.
When a hacker or insider threat attempts to access resources in your network, they will need to authenticate with AD Domain Controllers, and this is where Conditional Access becomes critical. Because don’t forget: You won’t be able to stop bad actors from getting in; not 100% of them. The key is preventing their lateral movement and a great method is using Conditional Access to either block or force MFA whenever the intruders attempt to move beyond the initial compromised machine. A solution that merely detects an attack after the fact is not enough anymore. The increased sophistication and efficiency with which hackers successfully breach our networks requires us to move toward containment of attacks, in real time.
Here are some examples of authentication policies that a good Conditional Access system could provide:
- IF an account is performing abnormal behavior, then force MFA
- Each user account is setup for MFA, and additionally service accounts can be setup to have a human MFA authorizer on their behalf
- IF an account is privileged, then always force MFA
- IF the Destination is a “Legacy App” w/o native MFA ability, then force MFA
- IF the Destination is within a “Critical” Active Directory OU, then force MFA
- IF a Service Account is attempting to RDP, then BLOCK
- IF a User’s Risk Score is High, then force MFA (to all endpoints, or just critical ones)
- IF a User is part of a specific AD_GROUP, and their Risk Score is Medium or High, then force MFA
- IF a User is located within a specific OU, and their Risk Score is High, then BLOCK all Authentication requests
- IF a User is involved in an identity-based attack (e.g. PtH, Golden Ticket), then put them on a BAD_LIST
- IF a User is on a BAD_LIST, then BLOCK all Authentication requests
- IF a User’s or endpoint’s Risk Score becomes High, then integrate with other security tools and platforms (e.g. SSO portals) and add to their BAD_LIST
Change is necessary: Not too long ago did the idea of cloud computing and moving important applications and databases into the cloud seem inconceivable to most security teams. But times have changed, and money trumps everything. A cornerstone of IT Cloud utopia is that everything is better, faster, and cheaper in the cloud. The truth, however, is far less simple. Despite the promises of the cloud, many organizations are employing a hybrid network approach, with on-premises Active Directory being a reality for many years to come. Whether it is the complexity of moving away from legacy systems or industry regulations, the ability to completely move to the cloud is simply not feasible for many organizations.
Organizations with hybrid environments will usually connect their on-premises network with their cloud by using some type of federated trust, which often involves some type of IDaaS (Identity-as-a-Service) platform. A good Conditional Access program should integrate with your IDaaS platform and have the ability to provide the same decision and analysis engine to protect access to cloud servers and applications. End users don’t differentiate between applications running on-premises versus those in the cloud, and they want the ability to jump back and forth between them as the same user. In order to achieve this, every user’s cloud behavior should also be analyzed by Conditional Access policies.
Many organizations have an IAM program, or at least an identity-focused project, but few have a specific secure authentication management sub-component that includes Conditional Access. Security teams should strongly consider creating and implementing these critical components sooner rather than later. They can start by running in passive mode while their policies mature and pass multiple rounds of rigorous testing.
However, the move to active mode, with the ability to block authentication traffic and force MFA, needs to be on the roadmap. Because even though 100% prevention is unattainable, a modern day Conditional Access approach provides the best path forward to the next best alternative: detect and contain.
Posted by Tom Stanton on September 19, 2019 5:39 PM