Zero Trust

chdelay

History

Zero Trust is a methodology for securing your IT infrastructure. It changes the model for securing an organization’s IT infrastructure. Zero trust as a methodology has been developing for the last 20 years.

Originally, an organization’s IT systems were closed off from the world. To access resources, you had to travel to an office. That office would have networking equipment that connected the endpoints to server-based resources.

Since organizations are more dynamic than users coming into an office, the network and infrastructure had to open up to facilitate work with partners, travelling workers, and so on. Systems such as VPN and Citrix were implemented to allow this more dynamic workplace. In addition, during an organization’s digital transformation, more tools needed to be made available to customers. This began with an organization’s website and grew into more complex digital tools. These tools increased a company’s efficiency as customers had access to self-service portals where they can conduct business from anywhere in the world, at any time. These new tools necessitated a secure way to provide these resources on the internet. This led to DMZ and extranet networks, which allowed the company to open up to the world yet maintain segmentation and security.

As time passed there became more entry points into an organization’s network. It was no longer the case that you could keep your network closed off and assume a certain level of trust within the network. This also became true with the advent of wireless networking. Tools were developed to provide real-time health assessments of endpoints prior to being allowed on the corporate network. These included security technologies such as Cisco’s Network Admission Control (NAC) and Microsoft’s Network Access Protection (NAP). Again, these tools accessed the endpoints health and allowed the endpoint on the wireless network if it was healthy and isolated the endpoint on a remediation network until the device was brought back to a healthy state.

So, what we saw was the opening of the corporate network and attempt to put security controls in place to mitigate the security issues that were brought about by the opening up of the network.

At the same time, we saw the intensity and sophistications of attacks rapidly increase over time. Early attacks such as the “I Love You” virus and Morris worm were very basic in their implementation and aims. Also, early attacks were driven more by curiosity and experimentation, as well as for bragging rights. Those attacks have escalated over the years. Now many attacks are done either by nation state actors or by organized crime whose goal is financial reward. Hacking tools are predominant and easily accessible by anyone with an internet connection. There are tools such as Metasploit Framework that allows an attacker to choose their target, the exploit, the payload, and execute an attack with a simple command.

The understanding that corporate networks are full of various entry points has been understood for some time, as mentioned before. Early in my career when attending security conferences corporate networks referred to as the M&M model. With a hard exterior, but a soft chewy inside. The point of this comparison is to illustrate that once an attacker had penetrated a firewall or was able to utilize one of the established ingress points there was no security to prevent access to any internal resources.

Obviously, this change in the way that technology and networks were utilized in combination with the increase in threats, something had to change.

Introducing Zero Trust

Zero trust is based on 3 principles.

Verify explicitly: This means that the health and security posture needs to continuously be evaluated in real time. As an example, let us use the example of a user accessing an application. In the past if the user simply presented the correct username and password, they were granted access to an application. When Zero Trust is implemented the user risk and sign-in risk is evaluated in real time, based on risk data collected on the internet and characteristics of the typical user sign-in. If the user or sign-in is determined risky by this real time evaluation, the user is prompted to MFA. A message is delivered to the Microsoft Authenticator app on their mobile phone, if the user initiated the sign-in the user approves the sign-in on their Microsoft Authenticator verifying that it is in fact them logging in. The Machine Learning (ML) engine that identified the sign-in as risky now understands that this sign-in was legitimate and can learn that this type of sign-in is normal for the user. This will result in less MFA prompts for the user without decreasing the secure validation of the sign-in.

Use least privilege: The goal is to give each user just the privileges that they need to complete their job or a given task, and no more. Additionally, there is a just in time (JIT) component to least privilege. This means giving that user that access just for the time that they need that access. So, if that user typically works 9 AM – 5 PM, they most likely do not need that level of access outside of those hours. Azure PIM can provide this level of least privilege and JIT. For administration a role can be selected that just gives the user the permissions they need for their task. And in addition, the user can be made to elevate just prior to beginning their work. And their elevation can be time-bound, so access goes away after a pre-determined amount of time has passed.

Assume breach: The security posture of Assume breach forces an organization to take many steps that they would not otherwise take. These steps include use of the previous two cited principles of Use least privilege and verify explicitly. It also includes additional steps like hardening services by implementing a secure hardened configuration. It also includes the use of encryption to protect data at rest and in transit.

There are six areas where Zero Trust needs to be implemented. Those six areas include Identity, Devices, Apps, Infrastructure, Networking, and Data.

Identity

Identity: It has been commonly said that Identity is the new perimeter or control plane. That is because identity is how access is gated. Identity is the most important component of Zero Trust.

Authentication

There are 3 authentication options for synced Azure Active Directory Identities: Federation, Password Hash Synchronization (PHS), and Pass-through Authentication (PTA).

Federation is where you leverage ADFS to create a trust between the on-premises Active Directory and Azure Active Directory. With this configuration identities are validated on-premises.

Password Hash Synchronization is a combination of two technologies. The first is sync, in other words synchronizing identities and their passwords with Azure Active Directory. The second is leveraging the passwords that are synced to Azure to authenticate users. The two are distinct. For example, you can use Pass through Authentication to authenticate users to Azure AD, while still having their passwords synced to Azure AD.

Pass through Authentication authenticates users to the on-premises Active Directory. Typically, organizations use this configuration when they are not yet ready to sync passwords to Azure Active Directory.

The recommended configuration is to use Password Hash Synchronization for both synchronization and authentication.

Using Password Hash Synchronization has many benefits. These benefits include using the high availability of the Azure to service logins instead of having a dependency on on-premises servers that are limited in availability and scalability. Additionally, Azure AD Password Protection can be utilized to secure all of those authentications including using features such as Smart Lockout.

Identity Journey

Longer term and this could be much longer term would be to move to cloud identities instead of synced identities. So, the beginning state would be to start with on-premises identities that are synced to Azure AD. Next, your organization would identify roles that have no on-premises identities, or in other words identities that rely only on cloud workloads. Then as you hire new employees in those roles you could add them as Cloud accounts. Once you verify that everything is working well with those employees you could work on migrating existing synced accounts to cloud accounts.

Conditional Access

Conditional Access is a key driver of Zero Trust for Identities. Conditional Access is an authorization rules engine that secures access to cloud applications. With conditional access you can leverage a variety of conditions and controls to ensure that authentications are done in a secure manner.

Conditional access policies should apply to every app. Where possible minimize the number of conditional access policies. Before deploying conditional access policies to production, use report-only mode to determine the impact of conditional access policies.

Implement a naming convention for conditional access polices. The recommended naming convention is: <Sequence Number><Cloud App><Response>For<Principal>When<Conditions>.

At the very least you should include a sequence number as a pre-fix. This makes it easier to communicate about policies, especially when submitting and reviewing change control.

Conditional Access Break Glass Accounts

Within Azure Active Directory it is necessary back practice to configure Break Glass accounts. These accounts are to be utilized only during emergencies when other administrative accounts are not working. These accounts should only be used for emergencies and not logged into during any other time. Azure AD sign-in logs should be monitored to ensure that these accounts are not being used. There should be a minimum of two break glass accounts.

In terms of conditional access at least one of the break glass accounts should be excluded from MFA and should be excluded from all conditional access policies.

Implementing Conditional Access Policies

One thing to consider to ease the implementation of Conditional Access Policies is the use of Log Analytics and KQL. The first step is to move your Azure AD logs to Log Analytics. Then you can start using Kusto Query Language (KQL) to filter the logs to find any potential issues, such as service accounts which may not work well when interrupted by a required actions such as MFA, that is imposed by a Conditional Access Policy. However, prior to doing this you will need to create the Conditional Access Policy in Report only mode. Then based on the analysis of the logs you may decide to add exclusions to your policy. Then once you have added the appropriate exclusions you can change the policy to the On state.

MFA

Multifactor Authentication is a strong authentication method that can be leveraged to enhance the security of identities. MFA can use authenticator apps such as Microsoft Authenticator, Phone Calls, and SMS. Passwords by themselves do not provide a high level of security. This is due to the many problems associated with passwords. Since users must remember passwords for so many services including personal services, users end up using the same password across services. So, if a user uses the same password for a social media account as they do for the work account, this is problematic. This is problematic because if the user’s social media account is compromised then their work account is effectively compromised.

There are various strategies for leveraging MFA. Some organizations MFA every login. The issue with this is that it can become very tedious for the user. This is assuming you are not leveraging Windows Hello for Business. WHfB authenticates a user and sends an MFA claim. This is a great solution as MFA is transparent to the user. A more common approach is to use MFA for untrusted scenarios. For example, if the user is not on a trusted network, or is not a managed device. However, a common Zero Trust approach is to use Identity Protection to determine whether the application access should require MFA. For example, if the user is at high risk, they are forced to MFA.

Identity Protection

Identity protection determines the risk of the User or the Sign-in. Identity Protection determines risk by characteristics of the authentication, such as location or OS. Identity Protection also accounts for behavioral characteristics such as impossible travel, unlikely travel, and access from previously not used locations. In addition, Microsoft through its analytics and telemetry data can determine if an account has been compromised or the user’s password has been exposed.

For Identity Protection there are 3 settings high risk, medium risk, and low risk. As you make your decision on what policies to enable it is important that you have a better understanding of the differences in the implications of these risk levels.

High Risk is going to have a very low False Positive Rate. The implication is that if a user or sign-in is identified as high risk that it is very, very likely that the account or sign-in is compromised. However, the downside/trade-off to this precision is that true positive rate is lower. Which basically means there are users and/or sign-ins that are compromised but have not been detected.

So, when you leverage the High or Medium Risk scores the False Positive Rate is going to be higher. In other words, more accounts  or sign-ins that are identified as compromised will in fact not be compromised. However, what you gain from these settings is a true positive rate. So, again in other words, it identifies more accounts that are compromised than with the high-risk settings.

Legacy Authentication

Some applications use legacy authentication methods such as basic authentication and ActiveSync instead of Modern Authentication. Some examples are Exchange Online (EXO) and SharePoint Online (SPO). These applications can use modern authentication, but require a process to eliminate legacy auth. For example, legacy authentication for EXO typically happens when using older mail clients. Newer clients such as Outlook can use Modern Authentication. For SharePoint there may be applications that interact with SPO that use legacy authentication. Those applications or services need to be determined. Then those apps should be updated to use Modern Authentication.

Conditional access can be used to block legacy authentication. It is recommended to block legacy authentication. However, as mentioned above removing legacy auth will require proper planning and a process to ween applications off it and move it to modern authentication.

Terms of Use

Terms of use allow you to present an Acceptable Use policy or notice to the user. The user then must acknowledge the text before they can continue to the application. Terms of use are used to present a written policy to the user, prior to the user accessing the application. The Terms of use can be a block of text or for longer policies a PDF file can be displayed to the user.

In addition, user acceptance of the Terms of use is tracked. The terms of use documents are shown inline in the browser. And expiration and re-acceptance periods are configurable

Privileged Accounts

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) is a tool that allows you to securely manage Privileged Identities in Azure. PIM allows you to assign which users are allowed to elevate to Privileged Roles. Elevation can be time bound, limiting the time that those accounts are elevated. Elevation can require approvals, which provides control over when elevations occur. Additionally, there is strong auditing and reporting on elevations, approvals, and assignments.

The primary goal with PIM is to limit the time that accounts are elevated to a privileged role. The less time that a user is elevated the less time it is available to be used by an attacker if compromised. Generally, most organizations start using PIM with Global Administrator and slowly expand the number of accounts that are covered by PIM.

Use Cloud Accounts for Administration

You have two options for the types of accounts you use for administrative/privileged accounts in Azure and Azure Active Directory. You can use synced accounts, which are accounts synced from an on-premises Active Directory. Alternatively, you can use cloud only accounts. These accounts are accounts that exist only in Azure. The use of synced accounts for privileged roles should be avoided. The reason for this avoidance is that if the on-premises account is compromised and that account is a privileged account in Azure AD, then Azure AD will be compromised as well. If using synced accounts is necessary for your organization, consider using cloud accounts just for the Global Administrator role.

Governance

Access Reviews

Access Reviews is a tool that can be used for reviewing membership in a group and membership in a privileged role. It can also be used to review application access. One of the issues with trying to maintain the least privilege is removing users from a privileged role after they have moved on to a new job or left the organization. Additionally, users as they move from role to role may over time be added to more and more privileged groups without ever being removed from a previous role. Maintaining the hygiene of user’s access can be challenging, especially if attempted to be done manually. Access Reviews can be setup and run periodically. Access Reviews can be used to determine whether a user should still be in a group or a privileged role. Then if the user no longer needs to be in that role, they can be manually or automatically removed.

Access Packages

Access Packages is a tool for entitlements management. It is used to provide access to a user. For example, let us use an HR generalist as an example. That role may require membership in certain groups and require access to a set of applications. You can setup this role in Azure AD. Then when an employee is hired in an HR generalist role, they can request access to an access package. The reviewer for the access package can then approve/deny access to the access package. Types of access that can be managed by access reviews are:

Passwords

Self Service Password Reset (SSPR)

Self Service Password Reset is self-explanatory. SSPR allows users to reset their password if they have forgotten their password. It allows self-service, which minimizes help desk costs. It can be used with both cloud and synced accounts. SSPR can require up to 2 methods of verification.

The following methods can be used for verification/authentication: Microsoft Authenticator app notification, Microsoft Authenticator app code, email, phone, or security questions. There are pre-configured questions that can be used, and the organization can create their own custom questions as well.

Azure AD Password Protection

Azure AD Password Protection is a security tool that prevents users from changing their password  to an easily guessable or commonly known password. Azure AD Password Protection can add this protection to both Azure AD and on-premises Active Directory accounts. There are two password lists that are used to provide this protection. The first in a Global banned password list. This is a list that is maintained by Microsoft. The second is a custom banned password list that is maintained by your organization. For the on-premises protection there are some lightweight components that need to be installed. The password lists are updated periodically to keep the domain controller’s policy up to date. This is done without exposing Domain Controllers directly to the internet.

Azure Password Protection also includes a feature named Smart Lockout:

Smart lockout helps lock out bad actors that try to guess your users’ passwords or use brute-force methods to get in. Smart lockout can recognize sign-ins that come from valid users and treat them differently than ones of attackers and other unknown sources. Attackers get locked out, while your users continue to access their accounts and be productive. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout

Passwordless

Azure supports 3 methods of Passwordless: Windows Hello for Business (WHfB), Microsoft Authenticator, and FIDO2 security key.

Windows Hello for Business (WHfB) is a strong authentication method that leverages Windows Hello for authenticating the user. Methods for authenticating are facial recognition, fingerprint, or PIN. WHfB provides an MFA claim when authenticating to Azure AD. Therefore, it is a seamless method of MFA.

Microsoft Authenticator is an authenticator app. It is used to prompt the user when they authenticate. Acknowledging the prompt communicates to Azure AD that the user is in fact the source of the original authentication.

FIDO2 security key leverages a public/private key pair and is typically used in conjunction with a biometric authenticator such as fingerprint. When the user attempts to authenticate they are sent a challenge. The challenge is signed with the private key on the FIDO2 device. Typically, the user must submit their thumbprint or perform some task to acknowledge they are the source of the authentication.

B2B

Azure Active Directory (Azure AD) B2B collaboration is a feature within External Identities that lets you invite guest users to collaborate with your organization. With B2B collaboration, you can securely share your company’s applications and services with guest users from any other organization, while maintaining control over your own corporate data. Work safely and securely with external partners, large or small, even if they don’t have Azure AD or an IT department. https://docs.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b#:~:text=Azure%20Active%20Directory%20(Azure%20AD,to%20collaborate%20with%20your%20organization.&text=Developers%20can%20use%20Azure%20AD,%2Dservice%20sign%2Dup%20portals.

There are two features that enhance B2B with greater controls. These two features are Cross Tenant Access Policies (XTAP) and Tenant Restrictions. Cross Tenant Access Policies provide the following features:

  • Inbound Controls – Allows admins to define tenants from which users are allowed to be invited. This can also be scoped to a group in an external tenant.
  • Inbound Trust Settings – Allows admins to accept MFA, HAADJ, and Compliant Device claims from external tenants which can be used to satisfy Conditional Access policies.
  • Outbound Controls – Allows admins to control what external tenants their users are allowed to authenticate to. This can be scoped on a per user/group basis.
  • Tenant Restrictions – allows admins to control the external accounts used on their network. This can be scoped by app, group, and user on a per-foreign-tenant basis.

Log Analytics & Workbooks

Log Analytics

Log Analytics is a tool in the Azure portal used to edit and run log queries with data in Azure Monitor Logs. You may write a simple query that returns a set of records and then use features of Log Analytics to sort, filter, and analyze them. Or you may write a more advanced query to perform statistical analysis and visualize the results in a chart to identify a particular trend. Whether you work with the results of your queries interactively or use them with other Azure Monitor features such as log query alerts or workbooks, Log Analytics is the tool that you’re going to use to write and test them.

https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview

Workbooks

Workbooks allow you to create visualizations of data collected in Azure. Typically, the data that is visualized comes from logs and Log Analytics. Azure AD has several workbooks already created.

Kusto Query Language (KQL)

Kusto Query Language is a powerful tool to explore your data and discover patterns, identify anomalies and outliers, create statistical modeling, and more. The query uses schema entities that are organized in a hierarchy similar to SQL’s: databases, tables, and columns.

Kusto Query Language (KQL) overview- Azure Data Explorer | Microsoft Docs

It is tremendously important that at least some of your IT staff be trained in KQL. This will make it much easier to implement many of these technologies. For example, let us take Identity Protection. When you roll out Identity Protection, it will be initially rolled out initially it will be in report only mode. You can then use KQL to query the logs to see what applications or service accounts might not work well with Identity Protection. You can also use it to validate that Identity Protection is behaving the way you expect. However, first your logs must be sent to Log Analytics.

Microsoft Defender for Identity (MDI)

Microsoft for Identity is an important tool for protecting your on-premises identities.

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

  • Defender for Identity enables SecOp analysts and security professionals struggling to detect advanced attacks in hybrid environments to:
  • Monitor users, entity behavior, and activities with learning-based analytics
  • Protect user identities and credentials stored in Active Directory
  • Identify and investigate suspicious user activities and advanced attacks throughout the kill chain
  • Provide clear incident information on a simple timeline for fast triage

What is Microsoft Defender for Identity? | Microsoft Docs

Zero Trust for Devices

Conditional Access Policies

Trusted Locations

Early on in the journey, most organization adopting Azure AD start with Trusted Locations. In other words the organization will require the authentication to originate from a trusted location. A trusted location is based on IP addresses. So, Conditional Access is used to require this. There are Named Locations that can be created. Normally, those Named Locations are associated with the IP addresses that originate from the corporate network.

There are limitations to this approach. The limitation is that all this does is allow authorization to a user coming from a particular IP address. Since, this is just based on IP address, the state of the machine is not evaluated. With a Zero Trust approach you want to validate that the authentication is coming from a managed machine. A managed machine has policies applied to it, to help harden the device, and make it more sescure. However, ultimately you want to only allow devices that are evaluated for their risk level, and are evaluated for their compliance to policies.

Requiring Managed Device

There are two ways to require a managed device.

The first way is to use Filter for Devices. You can use Filter for Devices to require Hybrid Azure AD Joined devices, Azure Joined Devices, and Compliant devices. Compliant devices is the only one of these options that provide real time status of the device.

The second way is to use Grant controls. There are two Grant Controls associated with this: Require device to be marked as compliant and Require Hybrid Azure AD joined device. Require device to marked as compliant is the preferred control as it gives real time compliance status of the device. However, as you adopt the cloud model, there will be a period of time where not all machines are managed by Intune. So, to help bridge that time you would use both compliance and Hybrid Azure AD joined. So, policies would be configured to require either one of those configurations.

Intune

Intune management of all devices is the desired end state. The reason for this is that Intune compliance can be used to validate the secure configuration of the device. So, preferably Hybrid Azure AD Joined devices, Azure AD Joined device, and Azure AD registered devices, would all be managed by Intune.

Implement Compliance Polices to enforce:

  • OS and Patch Level
  • Disk Encryption
  • Password Policy
  • Firewall
  • Anti-Virus
  • Anti-Spyware

And in conjuction with Microsoft Defender for Endoint (MDE), the real time risk of the device can be evaluated.

Journey to Modern Identity for Windows Devices

As mentioned above there is a journy that begins with Hybrid Azure AD Joined devices and continues through moving to Azure Joined Machines.

As organizations adopt Azure they need to a starting point. And that starting point is Hybrid Azure AD Joined devices. Hybrid Azure AD Joined devices are devices that are joined to both on-premises Active Directory and Azure Active Directory. So, to get to this first state the devices that are joined to on-premises AD need to be joined to Azure AD. This is accomplished by configuring Azure AD Connect.

The next step in the journey is to moving all devices to be managed by and report their compliance status to Intune. This is an important step for Zero Trust as getting real time compliance and risk data is important for maintaining the security of your environment. While Hybrid Azure AD Joined devices may be managed by Group Policy, there is typically no method in place to report compliance to those policies. Moving to Intune allows you to not only monitor compliance to those policies but in combination with MDE can be used to identify risk. An important aspect of moving to Intune is to transition your Group Policies to Intune policies. So, you will need to map your policies as close to Intune policies as you can. Keep in mind this policy migration process is a great oppurtunity to get rid of policies that are no longer necessary or particularly useful.

As we move along the journey the next step would be to move workloads to Azure or the cloud. This is especially true for workloads that are commonly used by desktop clients. Some common scenarios are moving File Shares to OneDrive, Exchange to Exchange Onlne (EXO), and SharePoint to SharePoint Online (SPO).

Once workloads are moved to Azure, then you can start considering moving to Azure Joined devices. Keep in mind that Azure Joined devices can still work on-premises. Those machines can continue to leverage Kerberos and NTLM for authentication to application that are on-premises and only support legacy authentication.

Usually inline with moving to Azure Joined devices it is common to move to AutoPilot for deployment. AutoPilot eases deployment. It allows you to ship a new device to a user, they connect it to the network, login, and it gets setup with the settings and applications that are necessary for them to work.

The journey above can be separated into a number of journeys and those journeys can be used to hep plan your deployment of each of these technologies. Those journeys are detailed below:

Enterprise Access Model

Enteprise Access Model is a model for securing Devices, Accounts, Intermediaries, and Interface. For the purpose of this dissussion we will be focusing on devices.

As seen in the graphic below, devices are logically separated into 3 categories: Enterprise Security, Specialized Security, and Priviledged Security. The Enterprise Security would be an ordinary users workstation, Specialized Security would be for a user that has additonal privileges or access, and Privledged Security would be for a user that uses a Priviledged account to perform administration, or has access to very sensitive data.

As illustrated in the graphic below, as you move to the right additional security controls are applied. Additonally, as you move to the right, the cost of securing those machines goes up, as additional security tools and specialized administration will be required. And finally, as you move to the right the security becomes more burdersome on the user. Fore example, a user that is on an Enterprise Security machine will be able to browse the internet, while a user on a Priviledged Security machine will only be able to access internet sites that are used for administration, such as the Azure Portal.

Zero Trust for Apps & Data

When it comes to Zero Trust and especially the controls around applications many of the controls control data as well as applications. The two are closely linked as the pupose of application is to view, create, and interact with data.

Conditional Access

For securing applications and implementing Zero Trust conditional access provides a number of tools in combination with other technologies. Conditional Access can be used in conjuction with the Mobile Application Management (MAM) tools available in Intune to protect applications and data. In addition, Microsoft Defender for Cloud Apps (formely known as Cloud App Security)  can be leveraged through conditional access to protect applications and data.

App Protection Policies

App Protection Policies are a component of Intune Mobile Application Management. Application Policies are used to enforce rules on applications that in turn protect data. Below are the controls that can be implemented via App Protection Policies:

  • Prevent backups of corporated data
  • Prevent saving copies of cororate data
  • Control transferring corporate data between apps
  • Control the sources from where applications can open data
  • Resrict cut/copy/paste
  • Encrypt corporate data
  • Restrict printing of corporate data
  • Require PIN to access application

In addition App Protection Policies can implement Conditional Launch. Conditional Launch can be used to prevent launching an app if:

  • The mobile devices does not meet a minimium OS levelr
  • The iOS devices is jailbroken
  • Device exceeds a predefined threat level

All of these tools in combination secure the data that is accessed by the application. In addition these tools prevent the launch of an application if the underlying platform is not in a healthy state.

Once the App Protection Policies are created they can then be implemented via Conditional Access Policies.

Conditional Access App Control

In addition to App Protection Policies, there are also a Conditional Access driven feature named Conditional Access App Control.  Conditional Access App Control allows Microsoft Defender for Cloud Apps (previously named Microsoft Cloud App Security) to be used to secure applications and data. Microsoft Defender for Cloud Apps proxies the users connection to the application the user is accessing. Proxying the connection allows for inspection of the application data and allows controls and monitoring to be implemented.

Conditional Access App Control can be used to implemnent a Monitor policy, a block downloads policy, or a custom policy.  In combination with the MCAS policy, the following can be accomplished:

  • Block Cut/Copy/Paste
  • Content inspection
  • Control downloads based on Classification, DLP, or Malware detection
  • Control uploads based on Classification, DLP, or Malware detection

Microsoft Defender for Cloud Apps

Microsoft Defender for Cloud Apps is a key tool for protecting applications. Microsoft Defender for Cloud Apps can do all of the following:

  • Discover Shadow IT applications and their risk
  • Compliance and Risk data for applications
  • Ability to saction or block applications
  • Investigate risky access to applications
  • Analyze traffic levels to applications
  • Determine traffic to risky applications
  • Identify the users that generate the most traffic to applications
  • Discover apps on devices and their associated risk
  • Identify sensitive information and apply labels

Protection of Sensitive Files and Information

Sensitive files are stored in a number of locations within an organization. Files are stored in SharePoint, on file shares, and on devices. Due to this there are a variety of tools that can be used to discover these sentitive files.

Classification

Information is classified based upon the contents of the file. Examples of classification are High Business Impact, Medium Business Impact, and Low Business Impact. Such an example of classification can be based upon a number of factors including the disruption to the business if the information was made widely available.

Labeling

Labelign is adding tags or labels to documents that indicates the classification level of the document. This labeling is important for several reasons. The first is employees can be trained on how to handle each level of classification, and based on the labeling how to properly handle the labeled documents. In other words, labeling communicates the classification level of that document.

Protection

Data that is labeled then needs to be protected. One level of protection is by employees knowing how to properly handle data. For example, an employee should know to protect customer data from exposure. In additoin there are software tools that can enforce protection. For example Azure Information protection can scan for documents and label them based upon their contents. More importantly, AIP can encrypt documents to prevent unauthorized access to the documents.

Zero Trust for Network

Zero Trust for Network involves 3 categories of protection: Segmentation, Encryption, and Threat Detection and Prevention.

Segmentation

It is important to segment resources in the network. Let us take for example a web site. A web server is segmented from the internet with a Firewall typically. Of course the data for the website comes from another resource server, typically a SQL server. The Web Server can connect to the SQL server to access the data, however the client that is loading the web page cannot, that is because the SQL server is segmented from the Client and the Web Server. In, addition the Web Server does not have unfettered access to the SQL server. The Web Server can retrieve data from the SQL server over a port such as 1433, however, it cannot connect to an RDP port like 3389.

In total, this is the concept of segmentation and requires planning to implement properly. Some common tools for implementing segmentation in Azure is Network Security Groups and Azure Firewall.

Bastion Host

In my previous example I mentioned RDP. RDP is a technology to connect to the desktop of a server or client remotely. Many organizations still manage servers via Remote Desktop. When you have Virtual Machines in Azure you may manage them via RDP. However, from a security perspectve you would not want to make RDP for your servers available directly on the internet. To allow you to manage your servers with RDP, but to still do it a secure manner there is a feature named Bastion Host. Bastion Host is essentially a web page that is accessed via the Azure Portal that provides an RDP session. So, the system admin logs into the Azure Portal, accesses the Bastion Host webpage over TLS, and then that service connects to RDP on the server. This allows secure administration via the internet, without making RDP directly over the internet.

Azure Firewall

Azure Firewall is a network firewall that provides protection for Layers 3 through 7 of the OSI model. It can be used to secure entry points to networks and Virtual Networks in Azure. Azure Firewall has a Premium SKU which adds additional features for finding and blocking malicious traffic.

Network Security Groups (NSG)

Network Security Groups allow or deny traffic to a Virtual NIC, Subnet, or Virtual Network. NSG rules can be created to allow or deny traffic from the Internet, VNETs, or Azure services. Like many firewalls the NSG rules for traffic end with a deny all rule. So, if network traffic is not specifically allowed with a rule that has a higher priority (lower priority number) then the traffic is blocked.

Azure Web Application Firewall

Azure Web Application Firewall is a service that protects your web applications from attacks and malicious activity. Azure Web Application Firewall works at Layer 7 of the OSI model. For example, Web Application Firewall has protections for the Open Web Application Security Project (OWASP) Top 10. For example the OWASP Top 10 vulnerabilities for 2021 are the following: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, and Server-Side Request Forgery. https://owasp.org/Top10/

Azure Web Application Firewall can be used to secure traffic passing through Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN). Azure Application Gateway is a regional load balancing solution for Web applications. Azure Front Door is a global load balancing solution. Azure Front Door recieves traffic at an endpoint that is local to the user and then uses high bandwidth backend services to deliver traffic back and forth to the Web Application. This leads to lower latency and a better experience for the client. Azure CDN is Microsoft’s implementation of a CDN. A CDN is to provide highly available and local access to static content, such as images and videos. A CDN leverages caching on servers around the globe to provide quick access and low latency to the client accessing the static content.

Encryption

Encryption services in a Azure are provided by Transport Layer Securty (TLS). Azure is currently being migrated to TLS 1.2.

Threat Detection and Prevention

Aside from segmentation and encryption there are additional security considerations, especially from a Zero Trust perspective. Zero trust is about being able to proactively identity and prevent threats, this is accomplished by constantly evaluating the health of the network and network traffic.

Azure DDOS Protection

Distributed denial of service (DDoS) attacks are some of the largest availability and security concerns facing customers that are moving their applications to the cloud. A DDoS attack attempts to exhaust an application’s resources, making the application unavailable to legitimate users. DDoS attacks can be targeted at any endpoint that is publicly reachable through the internet.

Azure DDoS Protection Standard, combined with application design best practices, provides enhanced DDoS mitigation features to defend against DDoS attacks. It is automatically tuned to help protect your specific Azure resources in a virtual network. Protection is simple to enable on any new or existing virtual network, and it requires no application or resource changes.

https://docs.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview

<Azure Web Application Firewall>

Zero Trust for Infrastructure

Zero Trust for Infrastructure is the remaining pillar of Zero Trust. Infrastructure refers to the workloads that are hosted in Azure, or even othe cloud services. These workloads include Virtual Machines, Containers, and SQL.

Implementing Zero Trust for Infrastructure includes: Secure Dependant identity systems, Establish a platform security baseline, Harden service communications, Secure administrative access, and Monitor for anomolous behavior.

Secure dependent identity systems

Identity is the new security boundary. And ultimately if Identity and Identity systems are not secure, securing workloads to some degree will be ineffective. This includes securing identity systems such as Active Directory and Azure Active Directory. Imlementing the Zero Trust for Identity findings will assist in securing these systems. In addition, Identity Secure Score can be used to further secure Azure Active Directory: What is identity secure score? – Azure Active Directory | Microsoft Docs.

Establish a platform security baseline

Platform security baselines are critical to maintaining security. You need to be able to compare a current state to a previous state to determine if any, including malicious changes have been made to a system. In order to establish a baseline for Azure itself there are a number of tools that can be utilized. These include tools such as Azure Blueprints, Azure Resource Manager Templates, and Azure Policy. Azure Blueprints are used for the initial configuration of the management and can be composed of different building blocks including ARM templates, resource groups, and Azure Policy. Azure Resource Manager Templates are JSON files that define an Azure resource and can be used to deploy Azure Resources. Finally, Azure Policy are the rules for Azure, including what permissions are allowed, and what monitoring must be in place for a given resource. In addition, Azure Arc can be used to control configuration of Virtual Machines across cloud service, including Azure, Google Cloud Platform, and Amazon Web Services.

Harden Service Communications

Protecting data in transit is critically important for services that are accessible over the internet. This includes encryption for data security and signing for data integrity. TLS is the mechanism for securing service communications. TLS is implemented throughout Azure and Azure AD. Currently, Azure is being migrated to TLS 1.2. This migration is estimated to be completed in September 2022.

Secure Administrative Access

Controlling what users can modify services is an important aspect of maintaining a secure configuration of a system. Minimizing the amount of time that a given user has the privleges to change a system is critilcal as well. Administrative access can be secure in a number of ways. This include using Privileged Admin Workstations for privileged users. The accounts that are used for privileged administration should be cloud accounts, and not synced accounts. Privileged Identity Management should be used for provisioning privileged access. Users should elevate when required to use their privileges (JIT), and their elevatin should be time bout to limit the duration of their elevation. Finally, access to Virtual Machines should require JIT access.

Monitor for Anomlous Behavior

From a monitoring perspective you want to be able to detect changes to systems, including attempted changes. Specifically, you want to be able to identify attacks and threats to those systems. There are several tools for monitoring for Anomolous Behavior. Azure Arc has monitoring capabilities for many types of workloads including SQL, Kubernetes, and Virtual Machines. And these virtual machines can be on premises, in Azure, in GCP, or in AWS. Microsoft Defender for cloud plans has threat protection for a number of workloads including: Servers, App Service, Databases, Storage, Containers, Key Vault, Resource Manager, and DNS.

Conclusion

Zero Trust centers on the capability to continaully evaluate for risk. It also centers on the capability to use a risk determination to gate access to resources. Most of this capability is delivered through Conditional Access. However, there are still many tools and technologies that work with Conditional Access, such as Intune and Microsoft Defender for Identity.