Modern authentication methods are increasingly replacing the use of passwords in identity infrastructures. This eBook describes how new techniques can provide additional protection and security for cloud identities and shows you how to plan and architect a strong hybrid identity structure.
Evolution of Authentication
One of the things we want to do in our environment as we move to the cloud is to protect our identities. We want to protect our roles and make sure nobody gets privileged rights to information that they don’t need access to, as well as protect against ‘bad actors’ (giving access to our environment through social engineering or passwords being compromised).
Data shows that 81% of successful cyberattacks are due to compromised usernames and passwords. We know that passwords are inherently insecure. It’s easy to guess many people’s passwords. People try to think of passwords that they can remember – therefore, it’s easy for others to guess those passwords. That’s why modern authentication and having new ways to protect our environment becomes so important.
Identity Management Evolution
The traditional identity of ‘the user’ is on-premises, where we have our Active Directory environment on-premises. Everybody logs in from within a building, and there’s no single sign-on between cloud and on-premises apps. People log into cloud applications with one password and use another password for on-premises applications. Visibility into identity risk is limited to our corporate environment because we have control over it in an on-premises environment. We are encapsulated within our building, and our perimeter security is hopefully strong enough to maintain that level of security within our building, so that bad actors can’t come in. Bad actors don’t come in through compromised identities at this point because our applications are all in the same place as our users (there are no internet-facing applications in this traditional, old-school approach).
As we have moved to more advanced services such as cloud with Microsoft Azure, Amazon Web Services (AWS) or Microsoft 365, we are now starting to federate those on-premises systems with cloud identities to provide a single sign-on approach for our users. This makes it easier for them to have one login for all their cloud and on-premises applications. At this stage, we need to think about gate access, providing remediation actions, as well as auditing frameworks and analytics on the visibility of potentially at-risk devices and users. We also need to consider what we are doing to avoid privileged user rights that might cause some level of compromise within our environment. We can do that with some of the advanced techniques within Azure Active Directory and connect that to our on-premises Active Directory services to provide a level of security and advanced services to identify users at risk and have another authentication technique. This is where multi-factor authentication (MFA) comes into play. Forcing password resets and similar techniques fall into this ‘Advanced’ category.
Optimal identity management includes password-less authentication. Are we enabling password-less authentication? Are users no longer being required to enter their password? Are they using some other form of authentication, such as Windows Hello for Business? Are we using the Microsoft Authenticator app? Or some other level of identity management like security keys or a text message code to verify who we are? At this level, we’re enforcing MFA across the board for all our users. We’re not using it on a conditional basis, we’re using it full-time to make sure passwords are not the only gate to get us into our applications.
A Cautionary Tale
The following happened within a personal environment but could easily happen in a business environment and cause a lot of damage. While his 11-year-old son was at school, Dwayne received an email about an Xfinity account password being changed. He ignored it at first, thinking it was a phishing email but received it again and logged into his Xfinity account to investigate. He went into his son’s account and found an email address and phone number (for verification purposes) that did not belong to anyone in the family. He realized the account had been compromised by a bad actor. Luckily, Dwayne had all his accounts set up in a family-type environment (similar to a business environment where administrators have access to everyone else’s accounts). If this was not the case and his son was the only one in possession of his account, he would have lost his Xfinity account. As it was, Dwayne was able to go in as an administrator, get the recovery email and phone number changed, and immediately implement modern authentication.
Later that day, Dwayne received a message saying that a password had been changed on his Microsoft account. The bad actor had realized his son was using the same password and was able to get into his Microsoft account. Dwayne went in and took care of that as well.
When the son came home, he couldn’t get into his Fortnite account. He found that his username had been changed to somebody else. As there were no admin rights set up, the Fortnite account had been stolen – a big deal to an 11-year-old.
This story shows how easily passwords can be compromised. The passwords in the different accounts weren’t identical, but they were similar, and the attacker figured that out quickly and easily. Fortunately, Fortnite restored the son’s account after establishing authentication. Dwayne changed the password from a guessable one to a strong, randomly generated one.
How can we bring modern authentication into our environment? The most important type of modern authentication is multi-factor authentication. There are many ways we can use MFA as a secure authentication technique within our environment. Keep in mind that MFA is not a password and a PIN number – those are ultimately one factor (both things you need to remember and know). We need other pieces of information for multi-factor authentication: it’s generally a password plus some level of what you are, which is biometrics, or something you have, such as a phone for an authenticator app or push notification. Many government environments use an RSA token or some sort of code that resets itself regularly or different OATH codes where you have to grab a code from your authenticator app.
Once we get multi-factor authentication in place, it prevents just about every one of the identity attacks because attackers will not have access to the tools (whether that’s access to you for your face identification or access to your phone). They will have to get access to your account and your personal devices to make that authentication happen. Therefore, those attacks are generally stopped right at the source.
We can eliminate passwords by using these secure authentication methods. You may use Windows Hello or Windows Hello for Business, where you require your users to use facial recognition and a PIN on their devices. The Microsoft Authenticator app is very helpful in providing password-less authentication in your environment. The FIDO2 security keys are similar to RSA tokens.
Protecting access to Resources from Threats
We don’t just want to protect our identities; we want to provide our users with seamless access. We want to facilitate collaboration with our users, and we want to have a level of IT efficiencies. We also want a level of dynamic protection as well as the ability to learn from that. Microsoft provides many levels of service once you start unlocking these levels of modern authentication, in terms of conditional access policies and privileged identity management where we can now gain information through these services and through the utilization of modern authentication techniques so that we can learn more about what’s going on in our environment as well. Microsoft puts a lot of that in its machine-learning capabilities to understand where users and devices are at risk and find through cloud app security capabilities what applications are at risk.
Principle of Zero Trust
The principle of Zero Trust is that we are not going to trust that anybody is who they say they are. We understand that identities are commonly the source of compromise within our environment and potentially where bad actors try to socially engineer and find a way into our environment. First and foremost is through finding open ports as well as finding users that might not be educated enough to understand when they’re being probed for information to find out what their password is, and so on.
With the Zero Trust model, we constantly require our users to identify and verify who they are. In the corporate infrastructure, that might only be one time a day because we know that that person is within our building and it’s within our IP address. If we weren’t working remotely before, everybody now is working from home one way or another. We are all on public internet IP addresses. Generally, they’re not static IP addresses, they’re probably dynamic on your home network, and we are now trying to find out ways to adjust to that within our businesses. We’re trying to maintain the protection of our identities. Zero Trust provides that by telling us that if we’re accessing privileged materials or accessing corporate data, we need to enforce multi-factor authentication as an organization. 99.9% of attacks are thwarted by multi-factor authentication, so if you don’t have it, you are at a point where you could be compromised.
Zero Trust also looks at different conditions within the environment:
- Is the device a managed device on your corporate network using Microsoft Intune or some other mobile device management or mobile application management service?
- Where is it logging in from? Is it logging in from a region that is known to be a risk?
- Is the application highly sensitive?
- What is the risk of the user? Machine-learning capabilities can identify a user as a risk if, for example, there have been compromised situations within their passwords in the past.
This all works along with Azure Active Directory, as well as Microsoft Intune, and from where those conditions lie and where we see those conditions, actions take place. We could allow access because they’ve already utilized multi-factor authentication. We can block access and say, ‘No, we’re not going to trust that this user is who they say they are’. We can enforce multi-factor authentication as well as a password change at the same time. We continuously go through this validation as the user accesses different applications or different services depending on what they are – whether they’re on-premises, whether it’s sensitive information, whether they’re different cloud applications. We might give a little bit of leeway for Office applications versus something like Dropbox or Slack within our environment.
Azure AD Conditional Access
Conditional access is really that first step to Zero Trust. You can see how conditional access policies work in this diagram (below). We look at it in terms of the different conditions, the controls we have in place and then what we’re gaining access to. You can look down through all the different identities, the different device types, the different locations. Whether it’s a work-from-home location somewhere in any city, state, or country and the corporate network or what the apps are. Are we accessing Apps from the browser or are they client applications? And then, we look at what those conditions are around each of these areas, and we can set up policies based on the location, whether it’s a compliant device or a managed device.
So, there are powerful services and capabilities within Azure Active Directory Conditional Access, which works across Azure services, Microsoft 365 services, cloud applications outside of the Microsoft suite of products, and as on-premises applications.
Risk Events and Conditional Access
When we think about risk events and machine-learning capabilities within Microsoft, if you have a Microsoft premium-level licence of Azure AD P2 or EMS E5 you get the machine-learning pieces’ capabilities where it looks for risky sign-ins and risky users. We can get some in-depth information about what’s going on with certain users within our environment.
We can find what risk levels are based on: whether we see anonymous IP addresses, leaked credentials, or impossible travel (for example, seeing that someone has gone from the US to the UK and signed in 15 minutes apart).
Risk level management works with conditional access policies to identify and evaluate our environment. We maintain an ongoing audit of our environment; looking at each user, their credentials, seeing what they’re doing within the environment and what they’re trying to accomplish. We understand what they’re doing and evaluating their risk level because there might be something going on that we need to investigate.
This all falls into the realm of Azure Active Directory Identity Protection. It takes the Zero Trust concept a step further, where we’re now looking at the true risk of a user in our environment. Maybe we need to provide additional training to those users to help educate them on risks to the environment, based on not taking their sign-ins seriously or not utilizing certain services that they haven’t turned on or we haven’t enforced.
When we think about conditional access and identity management, we’re talking about identity management as the control plane. Conditional access puts the protection on that control plane and provides signals to make informed decisions and base them on what our policy is as an organization. It then forces the protection across various resources (shown in the diagram below at a basic level).
User and location, device, application, and real-time risk are identified as the signals, and we have to decide where we’re going to take those further. Are we going to handle devices differently depending on whether they are Windows, iOS or Android devices? Then we need to determine what they’re going to do to verify themselves. Are we going to just allow the verification, or are we going to require MFA? Or block access before they have access to apps and data?
Privileged and Identity Management (PIM)
We only want users to have access to what they need to have access to. Privileged identity management says you don’t need any more access to resources other than those needed to perform your job, but then takes it a step further and puts time basis and approvals on the activation of administrative roles. It’s ‘just in time’ access where if a user isn’t an admin in your environment every day, all day, but they might need to have a level of elevated privilege occasionally, then this is a useful way to avoid increasing the attack surface for bad actors to get into your environment. It also provides justification and approval rights at the management level before those rights are even activated for the user to use them. It requires multi-factor authentication – there’s no way around that. There’s an audit history of who gained these privileges, when they were used, and when the privileges were turned off. This feeds into access reviews, which ensure users still need roles.
The PIM Workflow begins with a plan to determine users and roles. We then assign roles to users, and this is the same for all admin users. After the user activates the role and it’s approved by management or help desk employees. The whole approval is within an auditable, administrative environment. We can identify potential attacks, stay compliant within our organization, as well as investigate what might be taking place within our environment.
For each role, we can set up a review on a monthly, quarterly or annual basis. We can review what a user needs access to and automate it where we send a justification email to the user to ask whether they still need access to a role. If they don’t respond, we can turn off access. This helps us control the number of administrative users we have.
Azure AD Password-less Authentication
Microsoft has recently taken password-less authentication a step forward. They’ve written some excellent white papers and blog articles within the Microsoft environment that are well worth reading. Search for ‘Azure Active Directory password-less authentication’, and they should come up. Keep in mind that there’s a constant tug of war between administrators, who need to keep a secure environment, and users, who want access to information when they want it. If a user finds it’s difficult to gain access to resources that’s where ‘shadow IT’ comes into play, where people try to find ways around security measures because they have become inconvenient. Initially, people found two-factor authentication problematic, but we’ve got away from that a bit now, and people are used to using their phones to verify access. Password-less authentication is like two-factor authentication in that we’re utilizing something we have but, since we’re getting away from passwords as the first level of authentication, we’re giving our users greater convenience as well as a greater level of security.
Conditional Access Policies
In this demo, we’re in Conditional Access Policies within Azure Active Directory. Cloud app, user and condition policies are already in place.
To add a policy based on your company’s needs, click on ‘New policy’. You can assign it to specific users or groups.
The Sales group might be travelling a lot and be in potentially risky areas, so we need to set their permissions accordingly. We can decide which apps they have access to.
Here we’ve selected Office 365, Exchange Online and SharePoint Online.
We can control user access based on conditions like risk, device platform and location.
Note: you need to specify your “trusted locations” first before then being able to exclude those locations from requiring the conditional access policy.
In ‘Access controls’, we can choose whether to grant or block access based on specific criteria. We can set our access requirements – for example, ‘Require multi-factor authentication’ or ‘Require device to be marked as compliant’.
We can see what this policy’s going to do by setting it to ‘Report-only’. We can see what users might have been prompted based on their daily activities and do some level of auditing before we enable the policy.
When you’re happy with all of your settings, remember to click the “Create” button.
Privileged Identity Management
If we go to Privileged Identity Management in Azure Active Directory, we can look at roles and capabilities. In Assignments, we can see who’s eligible for certain roles and who’s active. It’s important to have all our roles going through privileged identity management. This gives us auditability, the ability for access reviews, and so on, all within our environment.
Access reviews are helpful for privileged identity roles as well as guest access. We can set them up for a specific frequency – such as one-time, weekly, semi-annually. We can base reviews on different roles and memberships and choose the reviewers.
We can set what happens on completion. If a reviewer doesn’t respond, we can remove their access (for example, if they’ve left the company).
In ‘Authentication methods’, we can utilize four different types of password-less authentication method. The two main ones are Fast IDentity Online using the FIDO2 Security Key and Microsoft Authenticator.
You can quickly configure your users in the authentication methods policy. You can enable it for all users or just select users and enable it for sign-in and strong authentication.
The Microsoft Authenticator app is highly recommended. It’s available on all smartphone stores, and you can use it easily for both business and personal authentication.
In this eBook, you should have gained some insights into where passwords have gone and where they’re leaving our environment as well because it’s potentially a threat to just use passwords in your organization. Hopefully, you’ll start using multi-factor authentication, understand the principle of Zero Trust, use the services within Microsoft for conditional access and user risk identification, and protect your administrator roles with privileged identity management.