Protecting your enterprise against Ransomware with Zero Trust Architecture

Leave a Comment / By / 6. April 2020

So I decided to write this blogpost based upon that I’ve been working with a couple of clients which have had some difficult times after ransomware attacks. We have also seen an uprising when it comes to Ransomware attacks. There are some different attack vectors that are used to the “patient zero” but this is typically based upon phising email with attachments or drive by downloads or even by exploiting known vulnerabilities. 

The consequences can be high, as many businesses are essentially “shut-down” because it infects and encrypts systems and files needed for the day-to-day operations.

So looking at the scenario with a traditional setup
1: User get’s an email with a email attachment which has a certain payload or a phising site to use drive-by downloads. (This either to steal account information or compromise device)

2: User starts the process which is within the attachment, the payload starts a network process which compromises the device.

3: The compromised device starts either look for shared files or network based resource which the compromised resource has access to to start infecting files. Or the compromised device is then used as a device to get further access to the solution.

As part of another blog post I discussed about moving to Azure AD based clients and how this would reduce the risk of ransomware in a large organization (https://msandbu.org/ransomware-and-moving-to-azure-ad-based-clients/) but I didn’t discuss so much about how the security layer fits in.

The problem and tradisional flat networks and remote access

Most ransomware attacks are based upon infecting a Windows based device which is domain based and then leveraging access to file shares and other network based resources. In most organizations they have a typical flat network structure and are using some form av remote access solution using MFA to get remote access to the infrastructure to get access to the data and applications. You can look at this as a door guard which is validating who you are to get access to the inside, but not doing any further evaluation once you are inside.

Now typically these devices are put into a segmented network zone where they can only access a certain set of applications or data. When on the inside they can access all the data since they come from a “trusted location” and this also provides SSO to internal resources.

What if the VPN solution itself has a vulnerability so that remote attackers can get access to the inside and going passed the MFA solution? This breaks the entire perimeter solution model and has been a big issue the last six months, where many large vendors had known issues.

So what if a machine on the inside is compromised different ransomware variants will spread either using smb protocols and other mapped service which might be available inside the networks. The problem is that on the inside, most machines and users are seen as trusted. With most traditional antivirus solutions for instance they can detect and react on a comprosmied endpoint but still this information is to relayed to other sources, so the user and the client can still freely roam network shares and applications.

Different layers of Security is needed

This is where zero-trust comes in, where the main idea is that all devices and users regardless of where they are in the network are based as they are coming from an untrusted network. To always verify who and what is connecting to applications/services or data. A simple way to look at this is having a doorguard which is constantly monitoring you and validating what you are doing once you get inside.

The main idea behind Zero-Trust approach (Which I’ve outlined in the earlier article –> https://msandbu.org/demystify-zero-trust-design-never-trust-always-verify/ ) is to always verify (and continuously the device/user/application/data/transport) Just to give some scenarioes here.

  • If a user is successfully authenticated to company resources, can we trust that the machine the user is sitting on is not compromised?
  • If a user comes from a “clean” device, but is being logged in from a unknown location?
  • If a legitimate user logs in, but suddenly starts downloading 1000s of files from Onedrive? 
  • If a user is conecting to resources but the endpoint is suddenly trying to authenticate to other resources or trying to access resources on the shared network

Overview of Zero-Trust Capabilities

So how can we implement a Zero Trust based security strategy using Microsoft? The outline of this article is to go into detail on the different aspects of the Microsoft ecosystem but also how to integrate these services with other services that most companies have, because Microsoft still has some limitations which needs 3.party services are needed to provide visibility across the entire landscape.

Now this blogpost will be setup go trough the different aspects of the functionality that Microsoft provides first and then showing how you can implement this in an existing infrastructure.

Validate the User

From an user perspective it is about how can we validate who the user really is? or that someone else is not pretending to be someone else when trying to authenticate?

Microsoft has certain security mechanisms which can we can implement to ensure that only valid users are allowed to authenticate

  • Azure Active Directory – Conditional Access with MFA – First of is that we can define that all users will require do to MFA to get access to applications and data, this provides a higher level of security since it would require attackers to have access to a user account and someones phone.
  • Azure ATP – Is a product which is aimed at monitoring and protecting on-premises Active Directory, monitoring both events and network traffic coming in to your domain controllers and mapping behaviour against known attacks. Azure ATP can be integrated with Cloud App Security, Microsoft Defender ATP as well. This is part of a new preview program for unified identity risk score (https://techcommunity.microsoft.com/t5/enterprise-mobility-security/introducing-investigation-priority-built-on-user-and-entity/ba-p/360853)
  • Azure Identity Protection – This allows Azure Active Directory to take automatic action if there is a risk accociated with a user-account. The following risk detections are available.
    Atypical travel Sign in from an atypical location based on the user’s recent sign-ins.
    Anonymous IP address Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs).
    Unfamiliar sign-in properties Sign in with properties we’ve not seen recently for the given user.
    Malware linked IP address Sign in from a malware linked IP address
    Leaked Credentials This risk detection indicates that the user’s valid credentials have been leaked
    Azure AD threat intelligence Microsoft’s internal and external threat intelligence sources have identified a known attack pattern

    Now based upon this detection mechanisms, Azure Active Directory can for instance reset the user’s password or require MFA if there is a certain level of risk involved.

Validate the Device

The second aspect is when a user successfully authenticates to a application or to service we want to make sure that there is no risk associated with the device the user is coming from. Having multiple security mechanisms that applying to the user makes no sense if the user is logging in from a compromised device. Therefore we need to have some form of health attestation from the device to ensure that there is no risk from the device as well.

As part of the ecosystem that Microsoft has there is essentially two products that look at the risk from a device perspective.

  • Intune – Provides for device management. Intune in itself cannot detect in real-time what is going on on the device. But provides Device Compliance policies we can ensure that a device is following a baseline security policy. Compliance Policies can then mark a device as uncompliant if it does not fullfill all the requirements in the policy. This can be a policy where we define for instance
    • Device Encryption – such as Bitlocker
    • Minimum OS Version
    • Require Secure Boot
    • Require Antivirus, Firewall, Anti Malware and so on.This information is then reported back to Azure Active Directory as part of device validation. Now the last part of the compliance policy that Intune has it to integrated with Defender ATP which can do realtime detection on what is happening on device. Defender ATP can report back information to Intune if there is a risk on a device which will then mark the device as uncompliant and therefore the user might not be able to access the application because of the policy.
  • Microsoft Defender ATP – Provides for real-time detection on the device with a sensor on the device which monitors, processes, registry, network connections also providing in-memory detection and also mapping attack techniques against the mitre att&ck framework. As mentioned above, Defender ATP can be integrated with Intune to be used for providing access based upon compliance. Defender ATP also integrates with Azure ATP to provide an holostic view.

NOTE: Currently, Azure ATP integration with Windows Defender ATP supports only users and machines from the on-premises AD. Users from Azure AD and virtual machines that are managed in Azure will not be displayed as part of the integration.

Now when we have both information from the client and device on what is going on, we can make a better choice if they are allowed access to applications or data based upon the risk that they present.

Validate the Transport/Session

So once a users gets access we might want to validate what kind of actions the user is doing to ensure it is not a comprimised account/machine doing malicious activities such as mass downloading information from a corporate file share or application. This is again, constantly verifying what the user is doing in a session.

Much of the features that Microsoft have here is based upon Cloud App Security, which allows us to define policies based upon activity or session for instance. An example of this might be

  • What is the user doing in Office 365? Doing mass downloads on files on SharePoint?
  • Is the User deleting files within SharePoint or deleting records within Salesforce?

Another option that Microsoft has as part of Cloud app security is setting up something called Access Control where you use Cloud App Security as a forward web proxy for your applications.

Now Cloud App Security can provide these types of insight into web applications if there is an API that is can plug into and is on the supported list of applications (Which you can read here –> https://docs.microsoft.com/en-us/cloud-app-security/proxy-intro-aad ) and again, if you do have a web application that is not on this list (which you most likely do, how can you verify what the user is actually doing? You can of course add policies on top to limit what the user can do, such as block access and block upload/download but nothing more granular that this.

So can we use this for everything?

Now in the heart of this is Conditional Access which allows us to define access to applications based upon trust and risk level. Then we can apply actions using Cloud App Security. We can also Azure Active Directory App Proxy to also provide access to web services running inside our datacenter as well which is then published trough Azure AD and is secured using the same security mechanisms. At the center lies Azure Active Directory.

So now I have gone trough most of the different services that Microsoft has in terms of building a zero-trust based architecture. So will these products cover all scenarioes? Not really.

In most cases you have other use-cases where you might need to access certain data or applications which are not directly integrateable with the Microsoft Security Stack. For instance if you need to access a remote desktop or access something trough VPN? Lastly to verify the transport when a VPN tunnel is active we need to monitor the network traffic going in to ensure that there is no malicious traffic and also being able to detect if there is any risk.

Microsoft can provide threat intelligence on the networking stack when it comes to Microsoft Azure, but on-premises it requires other solutions to do traffic inspection / threat intelligence but not as an isolated service it needs to be integrated to be able to exchange information. If our firewall finds suspicious behavior or traffic it should reflect with risk on Azure Active Directory.

Luckily there are a lot of 3.party products which integrate with this security stack to enhance and provide insight into those other workloads to provide the same security across.

Citrix Analytics for Security

  • Citrix Analytics – Is for Citrix workloads and integrates into Security Graph API to pull information as part of their analytics engine and can provide automated actions against users within a Citrix enviroment. Citrix can also be integrated into Azure AD for authentication.
  • Jamf – Provides compliance check for Mac OSX devices into Intune.
  • VMware – Provides integration with Azure AD from an authentication perspective.
  • Palo Alto – Provides Security Graph API integration from Cortex.

Another general rule of thumb is if that you have services or applications which can leverage SAML based authentication or support ADAL based authentication, you should always integrate with this Azure Active Directory because then you leverage all the information and risk detection from the services above. There is also some other services which allow you to use Azure AD to integrate with legacy solutions such as

  • Azure MFA NPS Extension – This allows you to integrate Azure AD MFA as an Radius solution for legacy MFA solutions. It does not provide a full zero trust architecture but provides a higher level of security for sign-ins.

Provide Azure MFA capabilities using NPS - Azure Active Directory ...

I’ve added all these what now?

Now to provide this context level based access, it is based upon Conditional Access, which essentially is a Azure AD service. This means that all authentication needs to be handled trough Azure Active Directory. Now the challenge is that a lot of traditional service which are based upon Kerberos / NTLM based service which still does not rely on Azure AD for authentication. Now of course these services are simpler to implement if you use Azure AD based devices. This requires a change of how our users work, and also how they access services such as file/print/applications. So looking back at the service scenario which I highlighted earlier

So looking at the scenario again a the security products
1: User get’s an email with a email attachment which has a certain payload or a phising site to use drive-by downloads. (If not detected and removed by Office 365 ATP)

2: User starts the process which is within the attachment, the payload starts a network process which compromises the device. (Defender ATP detect malicious activity and removes the payload and kills the process, risk is detected and reported to Azure Active Directory)

3: The compromised device starts either look for shared files or network based resource which the compromised resource has access to to start infecting files. Or the compromised device is then used as a device to get further access to the solution. (If Defender ATP could not remove the threat, but report the risk, with the higher risk level back to Azure AD, this means that Conditional Access would trigger when the users tries to get access to an application such as Office 365 and such)

We can also now define access levels per application or service.

Now I haven’t touch to much upon the other important aspects of backup and business continuity and also the networking aspect but ill come back on that in a later blog post.

What is Microsoft doing moving forward?

Microsoft is constantly adding new features which uses Azure Active Directory as the main authentication engine for other legacy service as well with new features now such as.

With more and more services being placed behind a centralized identity solution where you have these security service it makes it easier to protect your services and applications. However it is important that Microsoft does not provide a solution for the entire stack and you would need 3.party services to handle the layers which Microsoft does not cover. So it is important to have a connected security stack to provide the holistic view.

Getting started

Microsoft has the last couple of weeks added a lot of great content to get started with on a zero-trust journey such as this Zero Trust Assessment tool (https://www.microsoft.com/security/blog/2020/04/02/announcing-microsoft-zero-trust-assessment-tool/) also this Zero-Trust Vision Whitepaper –> https://aka.ms/Zero-Trust-Vision

 

 

 

 

Leave a Reply

Scroll to Top