Skip to content

MVP INSIGHTS: Trust no one!

Mustafa Toroman, Microsoft Azure MVP and Cloud Solution Architect at Devoteam M Cloud, finishes out our MVP Insights track on security and access in style. Mustafa brings you recommendations on what modern solutions to use to combat the ever-evolving threat of cyber attacks, right here!  

At this point you may think we are repeating ourselves, but the point cannot be understated: IT security has never been under more pressure by constant exposure to cyber threats.  

It is impossible to say where the next attack on your IT may be coming from. It can be anything from malware to compromised accounts, or even insider threats. These modern threats require modern solutions and an impactful one is the Zero Trust approach.  

But to understand Zero Trust, you need to understand where it originated:

Perimeter defence – how it all began

In the old world of on-premises, authentication was required only once. From that point, we were able to access anything we were authorised for. This approach was built on the idea of perimeter defence. All our resources were located on our local network; a network that we controlled and assumed was safe. If we protect the network, everything else is of course secure! Or is it?

Well, it turns out it definitely is not. The issue with perimeter defence is that once a network is breached, nothing can stop the attacker. If we follow Mandiant’s M-Trends report, in the period when on-premises resources were dominant, it took 200+ days on average to detect a breach. Imagine someone with access to all resources in your network for over 6 months and the damage that they can cause!  


Description automatically generated

Obviously, this approach was too risky and not working. And as cloud computing emerged, parameter defence completely fell apart. We were no longer protecting only resources on our local network but various cloud services. So, what can we do to stay secure? 

A new approach for a new age 

The answer to all our questions is Zero Trust.
Here we have a security framework that assumes breach and requires continuous validation to mitigate potential threats. With Zero Trust there is no traditional network edge that needs to be protected, as the network can be anywhere (local, cloud, hybrid…). The same goes for employees, who are no longer required to be in the office where the network is located. This shift means that you can be anywhere at any time and still have access to company resources. But how does Zero Trust help resolve access issues?

There are three key principles that Zero Trust addresses: 

  1. Continuous validation 
  2. Limiting blast radius 
  3. Automated response 

Now, let’s look at how Microsoft Azure builds a foundation for these principles and what tools that we have at our disposal.  

If you’re not on the list, you are not coming in! 

Zero Trust assumes breach and trusts no one. Every time any service or data is accessed, requests must be validated. To validate any request two things are required, authentication (to prove who we are) and authorization (to prove you are granted access to the resource). For this purpose Microsoft Azure uses Azure Active Directory (AAD) and Conditional Access (strengthening authentication with Multi Factor Authentication (MFA) goes without saying).

When we try to access certain resources, our identity and permissions need to be validated. AAD is using the OpenID Connect protocol for handling authorizations, and OAuth 2.0 for authentication. Every time we try to access new resources, we are being validated. 


Description automatically generated

But how do you handle access to especially sensitive or critical data?

This is where Conditional Access kicks in, requiring additional checks when sensitive data is accessed. If we try to use a basic service, a simple identity check may be sufficient. But in case of classified documents, we can require additional checks like additional MFA check, request from a trusted IP address, or request from a trusted device. Based on classification and sensitivity we can require any combination of additional checks before a request is approved. By doing so, we are limiting the chance of a malicious request being successful.  

God mode /off 

Next in line, let’s see how to limit blast radius. Blast radius is a reference to how large a radius from the point of impact a bomb has. In IT terms, it is used as a metaphor on damage done to your IT once it is breached. In order to limit the blast radius, we need to use the concept of least privileged access. Two options stand out for this task, Just-Enough-Access (JEA) and Just-In-Time (JIT). For JEA, any user has enough access to do their job but are restricted from any non-essential access points. If an account is compromised, damage can be sustained to resources that were required by the user but nothing outside of that. 

With JIT, you don’t have access to the resource by default and need to request it for a limited amount of time. We’ve seen more times than we would like to admit, that privileged accounts have unlimited access to everything and once a bad actor gains access to such an account, they can do whatever they want. In case an Enterprise Administrator account is compromised, we cannot even start to predict possible damages. It could be anything from stealing data to destroying resources and taking business down. 

To limit this, any privileged role is not active by default. When any user logs in with their account, they are just a regular user. Some of them are eligible for privileged roles but any of these roles need to be activated. So, when admins log in, they are just regular users and need to request activation of the admin role to perform certain tasks. Additional confirmations may be required before privileged roles are activated, like a supervisor or a co-worker approving request.

 In Microsoft Azure, Privileged Identity Management (PIM) is used both for JIT and JEA.

With PIM, we manage eligibility and activation for privileged roles. But we can also create reports and review assigned roles. If someone is assigned a role but didn’t use it for some time, they probably don’t require that role for their day-to-day work. (If you are interested in a deeper dive into the world of PIM – look no further)

For Azure Virtual Machines, we can also use Microsoft Defender for Cloud’s just-in-time (JIT) virtual machine (VM) access feature. Access to VMs is locked down and needs to be requested. If requested, access is granted over a specific port to a specific network (IP address) for a specific time.  

Automate everything 

When it comes to cloud, automation is nothing new and “automate everything” is a very common slogan. In cybersecurity, automation is key to a quick response. If a breach eventually happens, we want to limit its duration as much as possible. 

With increase in data, logs, and events that need to be monitored, it is very difficult to cover everything in real time. Thankfully, tools like Microsoft Sentinel help us monitor security related logs in real time and automate responses if anomaly is detected. Monitoring can be performed based on predefined queries which are executed every few minutes or Machine Learning algorithms that analyse data in search of an anomaly. 

If an anomaly is detected, our Logic Apps performs automated responses and stop possible threats. As an example, let’s say an admin is regularly performing their job during work hours from a known location. All of a sudden, the same admin is logged in from some exotic location in the middle of the night. Microsoft Sentinel will flag this as an anomaly. 

Possible automated response could be to temporarily suspend the account in question as the chance of activity being malicious is very high. Keep in mind that all anomalies are not threats and there can be few false positives every once in a while. There is a chance that this particular admin is on a vacation but was asked to urgently perform some tasks.  

Graphical user interface, application

Description automatically generated

Limiting the duration of the breach is vital. We mentioned that breaches were usually detected after 200+ days. The average number significantly dropped in recent years, as attackers were detected after 24 days in 2021 and 21 days in 2022 (median number of days before an attacker is detected according to Mandiant M-Trends). However, a study from IBM shows that in traditional, on premises IT environments, attackers are on average found after 280 days. Same study shows that businesses that contain breach in under 30 days can save $1 million in cost on average.

Zero Trust by default tries to prevent breaches by assuming breach. Every request needs to be validated, especially when classified and sensitive data is in play. If a breach happens, it’s crucial to limit the damage by narrowing blast radius and minimising time the attacker spends in the system. 

Trust no one and verify everything! Be smart and stay safe!