Make your way to zero-trust network security with Microsoft 365
Recently we have discussed the subject of zero-trust network security, but at the Security and Compliance Virtual conference that took place recently, experts talked a lot about zero-trust architecture in Microsoft 365 environment, and we’ve decided to share some of the most interesting insights from the conference.
The notion of zero-trust was introduced back in 2010 by John Kindervag, but recently it has gained extra notoriety and interest in security industry primarily due to the volume of data breaches, we’ve seen across organizations. These breaches proved that traditional network perimeter architectures have serious flaws, and just don’t work in today’s world of progressive workforce mobility, a movement to cloud services, and BYOD model.
The crux of zero-trust concept is about making sure every time a resource is accessed you can assess, how trustworthy that access or request is.
When we think about Zero Trust, it’s more like Zero Trust in the network, where:
- Every asset you have is available on the open internet (because that’s the way things are in real life).
- You assume breach, supposing that somebody’s already in the network and you have to set up policies, and controls to avoid data leakage.
- There’s no inherited trust, and you must always verify.
Organizations today are connected to a variety of complex ecosystems – they have broad on-premises infrastructure, they are leveraging cloud services, have vast array of partners with access to their network, they may be using IoT devices to manage buildings and infrastructure, industrial control systems, have supply chains in terms of doing B2B types of transactions. Handling all that stuff requires a complex approach to integrated protection and governance of sensitive data across devices, apps and cloud services. This is what Microsoft has to offer:
Zero-trust concept here is built around identity and conditional access. Creating a policy, you may use various conditions, under which controls, managing access to data, are implemented. For example, your company will be able to define conditions, based on things like which users are trying to sign in, with which application, which device they are using, and wherein the world are they trying to sign in from.
Let’s see, how zero trust works from the position of admins, setting up policies, and the perspective of users doing their job. In the end, we’ll share some best practices.
The main portal for admins to configure conditional access will be Azure Active Directory (AAD). As an example, let’s set MFA for every access to SharePoint. Basically, you have two elements: Assignments and Access controls. Under the Assignments, conditions are listed, and they are the selectors for the policy. If these conditions are met, AAD will fire the policy.
Microsoft has recently added two cool features to these conditions. The first one is that now conditional access policies may be assigned by roles, so if you want, for example, your Exchange admin to be under a specific policy, that’s much easier to do. The other new thing is that you’ll have the full support for B2B, as you may grant access to business partners under conditions you prefer.
Every internal, and external application, whether it’s Microsoft, and third-party SaaS, or your on-premises applications (connected through the app proxy), may be under the management of the conditional access, creating consistent security model for all workloads.
Below the setting of sign-in risk as a selector is shown — one just has to pick the proper risk levels to fire that policy on.
It’s high time to look at the controls that are applied when the policy matches. In the first section of Grant controls, you pick extra stuff users will be required to do (like MFA) or to have (like a complaint or AAD joined device) to get access.
In this example, we’ll select MFA. One of the side benefits of MFA is it gives you the step up into the second factor of authentication if something risky is detected, but it will also eliminate some prompts, if a situation looks safe enough. For example, if users are within an IP range that AAD knows, and trusts (like your own set of IPs), in a location that users are always logging in from (maybe their home), the same device all the time, AAD can actually start to reduce some second-factor obstacles, still preserving the same security level.
Granting access is just a beginning, there’s also the ability to instruct the system to do downstream things with Session controls. Selecting to Use app enforced restrictions, you let apps provide only limited capabilities under certain conditions. If AAD detects something suspicious about the session, it will pass this additional information to the cloud app, which in its turn, will enable limited experience, without the ability to download, print or sync files.
Conditional access app control lets you invoke Microsoft Cloud App Security (MCAS), to get some rich front signal, and auditing, while monitoring user’s behavior within the app in question. Let’s say you have a user who’s at risk because of a sketchy login, and you may want to see, what that assumed attacker is doing, literally and laterally follow him/her. This gives you incredible power in terms of thinking about your security model and additional controls needed. While using this feature, you’re verifying and controlling everything by redirecting a user through a MCAS reverse proxy (not to the app itself), which lets you inspect and export traffic logs.
From the user’s perspective let’s view device-based conditional access policy. Trying to sign in from an unmanaged untrusted personal device will result in the MFA challenge, and ban to download, print or sync information (to control the data flow).
The situation on a managed device will be frictionless with true app single sign-on (SSO), and without the need for additional MFA challenges. Thus, the user experience improves, and the security controls are maintained, because of the certificate-based nature of the environment, in which we do device-based conditional access.
Conditional access and identity security are not limited only to signing in to your applications. It is possible to incorporate these into data itself with Azure Information Protection (AIP). Labels may be applied automatically or by users creating the file in Office and third-party apps. Through this classification, you can apply encryption at the file level, and only the proper identity can unlock the information. Encrypted files can be stored in any location (OneDrive, Dropbox, USB key, e-mail, etc.), but for the person or system to get access to it, credentials should be entered to prove the identity.
Block legacy authentication
This recently added capability is intended to exclude legacy protocols that won’t allow to carry out the MFA challenge and monitor the session. Turning on this policy is important, as the attackers are using tools relying on the protocols, like POP, IMAP, SMTP, etc. When you stop the use of these clients altogether, you eliminate all the vulnerabilities that come along with these protocols. Microsoft has found statistically that this policy stops 66% of the compromises in your work.
Excited to try this out — look for Conditions, then Client apps and choose Other clients not to let in any apps using legacy authentication.
This is how the denial to log in resulting from this policy will look like with Pegasus client.
Require MFA for admins
Having an experience in the investigations of major breaches, Microsoft is creating a set of turnkey baseline policies, which you must simply turn on. Among these is configuring stronger credentials for admins.
Identity Secure Score
Extending a little bit farther in terms of guidance, best practices, and how to create a very secure environment in the Zero Trust mindset, Identity Secure Score was introduced.
Secure Score has been around for a while in Office 365, and then in Microsoft 365. Eventually, specific places were defined for different admin roles: there’s an identity specific place for the identity admin, a network specific place for the network admin, the infrastructure admin, and so forth. The Identity Secure Score is what identity folks can address to see what makes the biggest impact on improving the security posture, and then build a plan around it.
On top of the Improvement actions are Enable MFA for Azure AD privileged users. Clicking on it, you will see the quick explanation of what to do, and at the bottom, there is a Get started button, which will take you right back to that baseline policy to turn it on. If this recommendation is enabled by a Third-party product, or if you want to Ignore it, as it doesn’t apply to your environment, you have such options under the Status drop-down.
Building zero-trust network is the right way to achieve security goals. By putting conditional access restrictions in place, you extend the horizon of productivity, as employees work effectively, while the data remains protected from downloading to the local drive and from the attacks, as MFA has 99.9% effectiveness in blocking identity-based attacks. Knowledge is power, start empowering your company now!