Problem sending or receiving protected emails externally?

Last week was the tenth time I helped an organization that couldn’t send protected emails externally.

In other words, it’s worth a blog article.

It’s all about a very common misconfiguration of Conditional Access.

The scenario is that (RMS) protected emails can be opened internally but if they are either sent or received externally, they can’t be opened in Outlook.


In all cases the issue have been that the sender’s organization has required MFA for all users to all cloud apps.

Multifactor Authentication (MFA) is in most cases what we want to enforce to increase the security but in this case it simply doesn’t work.

Let me start to explain how to solve this issue.

If your MFA Conditional Access rule looks like the following you simply need to exclude the app Microsoft Azure Information Protection from the specific rule.

All users All Cloud apps Require MFA
image image



If you have other Conditional Access rules that require MFA against the app Microsoft Azure Information Protection, you need to exclude this for external users.

As soon as the exclusion has been done, protected emails will be able to be opened (decrypted) in Outlook.


Let me explain why

Outlook as an App supports MFA. For example, if MFA is required internally, you can sign-in to Outlook to your own organization with MFA. The problem comes when you need to decrypt a rights protected message (rpmsg). One of the best things with RMS encryption is that is works seamless with Office files both internally and externally. During decryption, the authentication of your signed-in account in Office is used to verify your permissions against the organization that encrypted the content, both internally and externally (without any additional password/certificate that most 3-party solutions use).
The problem when you need to authenticate to decrypt a protected message that comes from an external organization is that Outlook uses the signed in account and its token to authenticate to the sender’s tenant. If MFA is required Outlook doesn’t support  re-authenticating to the sender’s organization with MFA against this tenant.

Publicerat i Conditional Access, Microsoft Information Protection | Märkt , , | Lämna en kommentar

Protect your environment by reviewing your applications!

To be able to protect our organization as well as preventing information leakage we not only need to secure our own environment we also need to identify what kind of apps and services that are in use by our users.

Microsoft Defender for Cloud Apps, formerly known as MCAS is a great tool to both get to know what kind of apps that are in use, get more knowledge about the apps as well as blocking unwanted application.

There is two different kind of apps that we can identify with Microsoft Defender for Cloud Apps.

  • Cloud Apps used from our network (based on FW/proxy logs) and/or devices (via Defender for Endpoint).
  • OAuth apps that integrate with our Azure AD, for instance, to sign in a user and/or access a user’s Microsoft 365 information such as calendar, email, and files.

There are a lot of news coming around OAuth apps, lets save that for a coming blog post and focus on the other type of apps, discovered cloud apps.


The risk of not knowing what 3-party apps that are being used is everything from information leakage to identity theft.

It’s called Shadow IT when users start using unsanctioned services to perform their work. With this tool we can easily identify if this is the case either by identify that large number of users accessing the same unsanctioned app or that a lot of data are transferred to a specific unknown app.

Another security risk that it common is that users reuse their work email adress as well as their password for 3-party solutions. We have seen several cases where a web service has been hacked and credentials stolen from this application have been used to get access to the company.

Microsoft Defender for Cloud Apps have built in alerts that reports both new apps that are being identified for high usage as well as new breaches with apps that are in use by our business. We can also create our own alerts and use Power Automate to get the alert into any destination we want and even take automatic actions.


A major challenge with Microsoft Defender for Cloud Apps is to identify ownership within the organization because this is such a broad product.

If we identify Shadow IT, we need to involve several parts of the organization to review what actions we need to take.

Examples include:

  • Make sure that we provide our business with the services they need to do their job.
  • Inform and educate how to use sanctioned apps and services
  • Once we have identified and informed about a sanctioned solution, we can block the unsanctioned solution.

However, it can be more critical in some cases where we need to act as quickly as possible to prevent information leakage. This assumes that we have a playbook with actions for this type of alerts.

For example, an alarm occurs that large amount of data are uploaded to an unsanctioned cloud app with a low score that turns out to be a service for anonymously sharing information.

A first step that our security operation can take is to start monitoring the service. This results in users being informed that their activities are being logged. If it turns out to be something that is approved by the business, the user can still move on.



A prerequisite to be able to monitor and block the app is that Microsoft Defender for Endpoint is running on the device.

How to get started

If you are working in IT and don’t have the business and its management involved, start by giving them information that Microsoft Defender for Cloud Apps has identified.

One good example as a first introduction for the management is to generate a Cloud Discovery executive report.


Today this is done from the Microsoft Defender for Cloud Apps -portal and the Cloud Discovery part. In a few months this will integrated as a coherent part of the Microsoft 365 Defender portal. Stay tuned for more information around news within Microsoft Defender for Cloud Apps.

More information about Microsoft Defender for Cloud Apps

Publicerat i Microsoft Defender | Märkt | Lämna en kommentar

Restrict information sharing based on sensitivity

Both Teams and SharePoint are good solutions for sharing and collaborating with sensitive information internally as well as externally.

With help of Sensitivity labels, we can define rules and permissions for everything from allow/block external guests, sharing of files, as well as conditions for accessing different Teams and SharePoint sites.

In the most cases a certain team or project often includes different kinds of files with different sensitivity. Everything from public non-sensitive information to more confidential information that all have different rules and regulations.

All settings around “Groups & Sites” that we can define in Sensitivity Labels are based on existing Teams/SharePoint settings.

The biggest challenge is most often when we use Teams or restricted channels in Teams to restrict access to certain information. Even if we set a Team or a Teams channel as private, the default setting for sharing is that files can be shared to anyone within your organization.


In the most cases we have specific private Team and/or private channel to restrict access to only the members. But…

Regardless of the private setting of the team and channel that restrict access to the specific location, files within this team can be shared to users outside of the Team/Channel.


This is due to the following global setting in SharePoint


Within information security, it is of course most advantageous to change the global settings for Shares to ”Specific people”. This does not allow files to be shared to anyone other than those who have access to the Team or channel.

However, it is often difficult to change the global setting as there is uncertainty about the need for information sharing. After all, it is usually a small part of our information that is actually more sensitive.

This week we have got new functionality within Microsoft Information Protection that solves this challenge.

We can now, based on the sensitivity of both the team and specific documents, control just sharing settings. This applies both to who we can share files with, and to control whether we allow edit or view only access to the shared document.

Some examples, if we have Team sites including private channels where we need to restrict sharing to only members of the Team/Channel, we can define this setting on the sensitivity label of the site.

image image

If sensitive information is located in a nonrestrictive team we can restrict the sharing setting only on these files.


For more information how to configure sensitivity labels with default sharing link type in SharePoint and OneDrive:

Use sensitivity labels to configure the default sharing link type for sites and documents in SharePoint and OneDrive – Microsoft 365 Compliance | Microsoft Docs

Publicerat i Microsoft Information Protection | Märkt | Lämna en kommentar

Classify information based on Teams location

Information classification is used to separate information into different categories. Everything from legal cases to sensitive projects often includes different kinds of information. It could contain both public information meant to be spread/shared officially and more sensitive highly confidential information restricted to certain users.

However, a common business request is the ability to classify information based on a certain location such as Team sites or SharePoint sites. Today the classification/Sensitivity label of the site only control how information can be accessed and shared and doesn’t affect the sensitivity label of the files within the team.

Notice that this picture has been customized to visualize that sensitivity label of the Team and the files doesn’t reflect.
Notice that this picture has been customized to visualize that sensitivity label of the Team and the files doesn’t reflect.

Default label per SharePoint/Team site

What’s in roadmap and currently in private preview is that a default sensitivity label can be configured per site. A site with configured default sensitivity label will automatically apply this label to all documents created or uploaded to this site. The exception is documents that already have been manually or automatically classified with a sensitivity label.
Documents with another default label will be relabeled with the default label configured for the Team/SharePoint Site.

In this example two different files are uploaded to Confidential team for Project Beta.

· The excel file is already manually labeled as Public.

· The document is just created with a default label (Business).

Within 2 minutes Teams shows that the Excel file remains classified as Public while the document has been relabeled as Confidential \ Project Beta


When a new document (excel workbook in this example) is created from this site it is labeled by default as Confidential \ Project Beta


If you want to try this out, the product owner at Microsoft have written an article with guidelines

Publicerat i Microsoft Information Protection | Märkt | Lämna en kommentar

Detect and protect sensitive IT information

What we have seen is that organizations are often good at verifying permissions and access to their IT (security) systems, but what most organizations miss is to restrict and protect extracted data such as logs and reports from these systems. Information that contains both system information and user data that in the wrong hands can be used by criminals to map our IT environment and identify vulnerabilities or violate laws and regulations regarding sensitive user information.

We need to support our analysts and IT staff to identify sensitive IT / System information, get the information correctly classified and protected. This has just become much easier! Since last week, we have new built-in trainable classifiers, where we have a classifier just for IT information. Trainable classifier is there to help us identify information based on analyzing existing information and using AI to find similarities with new information. You can read more about how trainable classifiers works and how to create your own classifiers in this blog post

The trainable classifier IT refers to information technology and cybersecurity topics such as network settings, information security, hardware and software issues. If we compare this trainable classifier with the Sensitivity info type “IP Address”, it only identifies IP addresses while this identifies the combination of network, hardware, software and user information.

Here is a list of all the new predefined trainable classifiers that meet several common business needs.


Trainable Classifiers can be used in combination with several services such as

  • Sensitivity Labels to detect, classify and protect information
  • Retention Policies to determine whether information should be deleted or retained for a defined period
  • Microsoft Defender for Cloud Apps (formerly known as MCAS) which can scan connected cloud services to identify and (for certain services such as M365) automatically classify / protect data-at-rest information.

I have configured a sensitivity label to support the organization to classify and restrict sensitive IT information such as incident reports and forensic reports. The label is set to automatically detect the information and recommend the end user to classify with this label.

image image

For example, if someone download alerts reports including sensitive security/compliance incidents from the Defender portals and open them in M365 apps, the user will be prompted to use this label.

image image

Detect sensitive IT information from MCAS

In this example I download threat analytics information around the Log4j exploitation including exposed devices.

Detect sensitive IT information from Defender

The limitation with recommended and auto labeling is that csv files are not supported, the reports / logs need to be in xlsx or docx format.

However, we can both identify and restrict the rights of these files.

Identify sensitive IT information at rest.

As I mentioned earlier, we can use Microsoft Defender for Cloud Apps (MCAS) to identify and act on information found by trainable classifiers.

By creating an information protection policy, we can retrieve Trainable classifiers as conditions. The result is that we will identify all files located in SharePoint / Teams / OneDrive that contain this type of information. Here we can identify data that is also in other formats, such as csv files.

image image

Since we have support to use the trainable classifier with Microsoft Defender for Cloud Apps we can also create session policies to define rules with Conditional access for this information. We can for instance block download or access from unmanaged devices. In this session policy I require MFA to be able to download files including sensitive IT information


The result looks like this where files including sensitive IT data require higher security verification to be downloaded

Detect sensitive IT information session

Publicerat i Microsoft Information Protection | Märkt | Lämna en kommentar

Attack Simulation Training

For decades successful intrusions have occurred by tricking a user to either execute something or leak sensitive information like passwords or other secrets.
As our security solutions are improved and protection increases, we can clearly see how attacks in the form of social engineering like phishing (Email/IM), smishing (SMS), vishing  (Voice calls) increases.

Basically, if the attacker wants something that could be hard to get by attacking a system it is often easier to contact some internal user(s) either by email/IM or phone and let them do the work. Like getting someone from the inside to open the locked door to your environment.

If we look at how most ransomware attacks are performed, it is usually about tricking a user into clicking on a link or executing a code. This concerns both users in working life and in private, where we know that the consequences can be devastating.

So, what can we do to prevent this?

It’s mostly about education, training, and awareness! We need to continue educating our new and existing employees. Teach them how to identify anomalies in the message so they become more careful. They need to be able to validate the sender, the text and above all the reasonableness/probability of the message they receive.
This need to be done with a combination of training and practice.
This is where Microsoft Defender Attack Simulations comes in. Attack simulation training in the Microsoft 365 Defender can run realistic attack scenarios in your organization. These simulated attacks can help you identify and find vulnerable users to prevent a real attack.image

A simulated attack like this phishing attempt from DHL can either be based on a predefined template

Attack simulation also allows us to customized one in a local language, in this case from the local service desk.


We also get predefined trainings to choose from to educate the users.


Note that this video is fast-forwarded and cropped to show the user experience.

Let’s take a look how this is done from the M365 Defender Portal

We find Attack simulation training on the Email & Collaboration chapter in the Security portal.
Here we can simulate attacks and follow up the result of current and previous simulations.


This solution is continuously updated to reflect several of the attacks we see in real life.

At the time of writing, we have the following techniques to choose from when simulating an attack.


For the moment we have 91 prepared payloads that we can choose from.


We also have the possibility to create our own payload. This can be helpful for simulating a scenario from our own organization as well in our own language.

We define what source the email should have; we can set whatever email address we like for the purpose of the simulation


We can either import an existing email or create one our self and attach a phishing link


Based on the simulated technique we got recommended trainings to choose from.


We can assign the training to either all users or only the one that got phished (clicked on the email or shared their credentials)


We can customize the existing default landing page, create our own or use a custom URL.


We can schedule the training and make it region aware to reflect real case scenarios.


Will my email protection solution block these emails?

No, these emails are placed directly in the user’s inbox and never passes the Exchange/Mail servers.

3 important steps to get started

  1. Plan your simulation well, make sure it sanctioned by the business and its management
  2. Combine the training with information campaigns and explain the “why” and background why this is important
  3. This is not a one-shot, the training must be recurring in order to maintain both the attention of our existing and new employees.
Publicerat i Microsoft Defender | Märkt | Lämna en kommentar

Microsoft 365 Defender – The success story from Forefront Stirling

Svenska – English

 image_thumb[2]I have now been working for over 15 years with Microsoft security solutions and I have just been recognized as a Microsoft MVP (Most Valuable Professional) for the 11th year in a row.

It is now that I am starting to feel old, but also a little nostalgic and above all proud to have been involved in this success story.

I started my work with a solution called ISA (Internet Security & Acceleration) Server in 2003 which later became Microsoft Forefront TMG (Threat Management Gateway). In 2010, I got a job for Microsoft where I was on site in Redmond / Seattle and developed the test questions for an upcoming certification/exam within Forefront. The following year, I was rewarded as a MVP within Microsoft Forefront. However, this exam was never released publicly and a few years later, Microsoft dropped the Forefront investment. I continued to work with Microsoft’s new security solutions and was instead recognized as a MVP within Enterprise Security for a year or so until Microsoft started developing services in the cloud. I was involved from the start and was rewarded as a MVP within Enterprise Mobility (+Security).

During this journey, I’ve followed the evolution from Forefront to what is today called Microsoft 365 Defender.

12 years ago, Like Defender, Forefront was a product family with different security solutions for different services, where Forefront TMG was the firewall and proxy solution, Forefront for Exchange / SharePoint protected our e-mail and collaboration services to Forefront Client Security which protected our clients. At this time, everything was locally installed services, and we had no cloud services that we needed to protect.

Above all, I remember Forefront Stirling which was the code name of a beta project that I imagewas very committed to. It was about sharing signals between all Forefront Products. The aim was to prevent an attack by means of the cooperation of all systems. For example, if a malicious file was found by Forefront on a Client, an alert went to Forefront for Exchange that blocked outgoing e-mail from this user to prevent the spread. The TMG firewall was able to prevent traffic from the client to block a hacker from getting a session against the infected client.

Microsoft realized that it is not enough to have a security solution for each service, but also that these solutions must communicate with each other to detect and prevent an attack.

Microsoft was pioneers with this idea and far ahead of its competitors.

However, the market was not quite ready yet.
A challenge with the intended solution was how IT departments often worked at this time. Especially in large organizations, there were different teams that worked and were responsible for different things, everything from the network team to those who handled server solutions (Exchange, SQL etc.) and the clients. IT security was not part of their work and where usually a separate team (if it even existed) Back then there was a resistance that someone outside the team would gain access or interfere with something that was their responsibility.

A lot has happened in these 12 years.

This beta project, Forefront Stirling did not become a reality… until now!

IT environment changes

Our IT environment has undergone a major change in recent years. Most organizations today have more critical services in the cloud than in local infrastructure. Our users are connected from different types of devices and work more remotely than from an office. The identity is called the new perimeter. Furthermore, we live in an information age where organizations’ information is created at a higher rate than ever and stored in different places. An interesting fact is that 90% of all the world’s information has been created in the last two years.

The threats and attacks have changed

Intrusions / attacks have also changed at the same rate where we see more sophisticated attacks. Attacks that are no longer based on malicious code to the same extent but instead on manipulation and use of the organization’s existing services.

In other words, we need protection that responds to the new way of working, the hybrid IT environments, and the current threats.

Microsoft 365 Defender

In the same way as Forefront once was, Defender is now a product family with custom protection for different parts of our environment. Like Forefront Stirling, Microsoft 365 Defender connects these solutions to share signals and jointly prevent an attack. Defender and what goes under MCAS today also monitors cloud services other than just Microsoft, such as Google, DropBox and Amazon. Defender for EndPoint is expanded to several platforms to also monitor tablets and phones from iOS, Android and Linux. To be able to detect and prevent an intrusion, we need to monitor all our services and devices.

Given how we are currently connected and current threats, the measures have also been fig25adapted. For 10 years ago, it was relevant to block something in an external firewall because our devices were usually connected from an internal network/local office. Today, the most common action is to block an identity or isolate a device no matter where it is connected. Zero-trust is a concept that every organization should adapt as we can no longer rely on a certain network or device.

Microsoft began as a pioneer with innovation and is now a world leader in IT security solutions. It’s a satisfying and amazing feeling to be able to implement these solutions, see how we can detect intrusions in good time and how our MDR (Microsoft Detect & Response) team can stop many of these attacks before they do any damage.

2021 Gartner Magic Quadrant for Endpoint Protection Platforms. Quadrants include Leaders, Challengers, Niche Players, and Visionaries.

Publicerat i Microsoft Defender | 1 kommentar

Microsoft 365 Defender – Historien från Forefront Stirling

Swedish – English

imageJag har nu jobbat i över 15 år med Microsofts säkerhetslösningar och jag har precis blivit utnämnd till Microsoft Most Valuable Proffesional, MVP för 11:e året i rad.

Det är nu jag börjar känna mig gammal, lite nostalgisk men framför allt stolt över att ha varit med längs denna resa.

Jag började jobba med ISA (Internet Security & Acceleration) Server som sedan blev Microsoft Forefront TMG (Threat Management Gateway).

2010 fick jag ett jobb för Microsoft där jag var med i Redmond/Seattle och tog fram testfrågorna till en kommande certifiering inom Forefront. Året efter blev jag blev utnämnd MVP inom Microsoft Forefront. Den här certifieringen släpptes dock aldrig offentligt och några år därefter la Microsoft ner Forefront-satsningen. Jag fortsatte att arbeta med Microsofts nya säkerhetslösningar och blev i stället utnämnd till MVP inom Enterprise Security i något år till Microsoft började utveckla sina molntjänster. Här var jag med från start och blev MVP inom Enterprise Mobility (+ Security). Under den här resan har jag sett det som idag går under Microsoft 365 Defender växa fram.

Forefront var för 12 år sedan likt Defender en produktportfölj med olika säkerhetslösningar för olika tjänster, allt ifrån Forefront TMG som var brandväggen och proxylösningen, Forefront for Exchange/SharePoint som skyddade våra e-post och samarbetstjänster, till Forefront Client Security som skyddade våra klienter. På den här tiden var allt lokalt installerade tjänster och vi hade inga molntjänster som vi behövde skydda.

Framför allt minns jag Forefront Stirling som var kodnamnet av ett beta-projekt som jag imagevar väldigt engagerad i. Det gick ut på att dela signaler mellan alla Forefront Produkter. Syftet var att kunna förhindra en attack med hjälp av att alla system samarbetar. Exempelvis om det kom in skadlig kod som påträffades av Forefront på en klient gick ett larm till Forefront for Exchange som blockerade utgående e-post från denna användare för att motverka spridning via e-post. TMG brandväggen kunde förhindra trafik från klienten för att blockera att en hacker fick upp en session mot den infekterade klienten.

Microsoft insåg att det inte räcker att ha en säkerhetslösning för varje tjänst utan också att dessa lösningar måste kommunicera med varandra för att tillsammans detektera och förhindra en attack.

Microsoft var tidiga med den här idén och långt före sina konkurrenter. Dock var marknaden inte riktigt redo än. En utmaning med den tilltänkta lösningen var hur IT avdelningar ofta arbetade på den här tiden. Framför allt i stora organisationer fanns det olika team som jobbade och ansvarade för olika saker, allt ifrån nätverksteamet till de som hanterade serverlösningar och klienterna. IT-säkerhet var inte en naturlig del av dessa team, utan var oftast ett separat team (om det ens existerade). De fanns ett motstånd att någon utifrån teamet skulle få tillgång eller påverka något som ansvarades av respektive team.

Beta projektet Forefront Stirling blev inte verklighet… förrän nu!

Vår IT-miljö har förändrats

Vår IT-miljö har genomgått en stor förändring under de senaste åren. De flesta organisationer har idag mer kritiska tjänster i molnet än i lokal infrastruktur, våra användare är anslutna från olika typer av enheter och jobbar mer på distans än från ett kontor. Identiteten kallas för den nya perimetern. Vidare lever vi i en informationsålder där organisationers information skapas i högre takt än någonsin och lagras på olika platser. Intressant fakta är att 90% av all världens information har skapats under de senaste två åren.

Hoten och attackerna har förändrats

Även tillvägagångssätten för intrång/attacker har ändrats i samma takt, där vi ser mer sofistikerade attacker. Attacker som inte längre bygger på skadlig kod i samma utsträckning utan i stället om manipulation och nyttjande av organisationens egna tjänster. Allt för att kringgå klassiska antivirus-system och andra säkerhetslösningar.

Vi behöver med andra ord ett skydd som bemöter det nya arbetssättet, den hybrida IT-miljön och den rådande hotbilden.

Microsoft 365 Defender

På samma sätt som Forefront en gång var är nu Defender en produktfamilj med anpassade skydd för olika delar av vår miljö. Likt Forefront Stirling knyter Microsoft 365 Defender ihop dessa lösningar för att dela larm och gemensamt kunna förhindra en attack. Defender och det som idag går under MCAS övervakar även andra molntjänster än bara Microsoft, exempelvis Google, DropBox och Amazon. Defender for EndPoint byggs ut till flera plattformar för att övervaka även plattor och telefoner, allt ifrån iOS, Android och Linux. För att både detektera och förhindra ett intrång behöver vi övervaka alla våra tjänster och enheter.

Med tanke på hur vi idag är uppkopplade och rådande hotbild har även åtgärderna Actions based on detection from Defender
anpassats. För tio år sedan var det relevant att blockera något i en extern brandvägg eftersom våra enheter oftast satt uppkopplade från ett internt kontor. Idag är den vanligaste åtgärden att blockera en identitet eller isolera enhet oavsett var den är uppkopplad. Zero-trust är ett koncept som varje organisation bör arbeta efter då vi inte längre kan förlita oss på ett visst nätverk eller enhet.

Microsoft har gått från att vara tidiga pionjärer med nytänkande till att nu vara världsledande inom säkerhetslösningar. Det är en tillfredställande och fantastisk känsla att få införa de här lösningarna, se hur vi kan detektera intrång i god tid och hur vårt MDR (Microsoft Detect & Response) -team kan stoppa många av dessa attacker innan de gör någon skada.

2021 Gartner Magic Quadrant for Endpoint Protection Platforms. Quadrants include Leaders, Challengers, Niche Players, and Visionaries.

Publicerat i Microsoft Defender | 1 kommentar

Conditional Access for sensitive information

Every organization have some extra sensitive information that requires more caution from its users. Common examples that emphasize sensitivity can be for example extra authentication or terms of use approval before they get access to the information. It’s all about raising awareness to reduce the risk of accidental information leaks!

Microsoft has now started a preview of a solution that can assist with this.

In Conditional Access we can now configure conditions for accessing certain SharePoint Sites/Teams based on the sensitivity label of these sites.

In the example below the user can access Public, Business and Confidential sites but to get access to information stored in classified Secret sites, we require MFA.

CA to sensitive information

It works the same in Microsoft Teams where Multifactor authentication is triggered when you access the team sites files:

CA to sensitive information Teams

If we need to raise awareness with more clarity, Terms of Use is a good complement.

CA TOU to sensitive information

The trick is a new feature in Conditional Access called Authentication Context where we can define conditions and then add this context to the site and group setting of a Sensitivity label

Let´s have a look on the configuration

We first create a new authentication context from the new part in Conditional Access. In my example I call this “TOU Secret Inf”


We can then create a Conditional Access Policy for this authentication context:


Then define the conditions we want, in my case MFA and Terms of Use:


We then configure the sensitivity label with this new authentication context that are now available (in preview)


If for some reason you haven’t started classifying your Sites (I’d mainly recommend starting with that), you can use the PowerShell management for SharePoint and use the Set-SPOSite command to define what Conditional Access policy that should be used for the specific site.

This is done in the format:

Set-SPOSite -Identity <site url> -ConditionalAccessPolicy AuthenticationContext -AuthenticationContextName ”same name as provided in AAD”

You have more information on docs

Good luck Smile

Publicerat i Microsoft Information Protection | Märkt | Lämna en kommentar

MCAS and AAD Identity Protection threat detection and automatic response

Now it’s time for part 2 around MCAS. (Part 1)

This blog post is about threat detection and automatic response where we start with
Azure AD Identity Protection.

AAD Identity ProtectionAzure AD Identity Protection monitor and responds on threats against our Azure AD identities. Based on behavior and existing information from Microsoft graph (that analyses 6.5 trillion signals per day) our sign-ins and users get a risk investigations score. The risks are categorizes into three tiers: low, medium, and high. We can define a Sign-in risk policy that either enforce MFA or block the specific sign-in based on the risk.
We can also define a User risk policy that act on the AAD account itself. My recommendation for most organizations is to enforce MFA followed by password reset for internal user accounts classified as High Risk. There is a low false-positive rate, and it indicates that the account has been breached in some way.

There are major benefits with the automatic risk detection that you get from Microsoft. However, there may be other signals and activities where you want to impose the same consequence with enforced MFA followed by a password reset.

For instance, we have Defender for Identity (previously known as Azure ATP) that is cloud based version of the deprecated Advanced Threat Analytics, ATA. Defender for Identity detects threats against our local Active Directory and its accounts in a similar way as AAD Identity Protection. Historically, the solution has ”only” monitored and alerted in case of intrusion and other suspected behaviors. But now we can also generate an automatic response based on activities from Defender for Identity.

This is done by Microsoft Cloud App Security (MCAS) that can integrate both Azure AD Identity Protection as well as Defender for Identity. This gives us insight where we can track events by the same user both in the on-premises environment and in the cloud.

There are cases where we have false positive of low-risk alertss in both solutions but if we see multiple alarms for the same user in different environments, it is probably something we should act on!

The strength with MCAS is also that it is integrated by default and monitors activities in Office 365 as well as the Azure platform but can also be extended to monitor other cloud services such as Google, Dropbox, Amazon, etc.

This allows us to follow through MCAS if, for example, we have less suspicious sign-in attempts to activities with data exfiltration from both on-premises file servers and other cloud services with the same account.  We can automatically ACT on these activities with MCAS

Let’s take a look at MCAS and the new Policies categorization.

Here we find the threat detection category, which includes, among other things, the standard policies imported from AAD Identity Protection and Defender for Identity.


We also have the option to create our own activity policies based on activities from the different sources and best of all, we can also configure an action.

As you can see in the image above, we have an Action column.

If we start by looking at a policy that triggers potential ransomware activities. In this case, if files with common ransomware file extensions are detected, we have defined an action for this.


Although it is rare for an account to be hijacked during a ransomware incident, there is reason to reset the user’s password. As in this example, we will stop syncing data for this user when this alarm is triggered.


We can, among other actions, impose Confirm user compromised.

The reason I started this blog post with AAD Identity Protection and recommended settings for a User Risk policy is because this is a prerequisite for this action to work.

Based on whether we have configured the User Risk Policy to block the user account or enforce the password reset, we get this result when the MCAS policy triggers.

When this happens, we can see that the user loses all access to Office 365 and for example that OneDrive stops syncing data.

MCAS-AADIDPRansomwareIn larger environments, there is a longer delay than the example above before the policy is triggered!

clip_image001[8]We had also triggered an alert (which in itself cannot be read until the current user has the right to reach their email again) but the alert could also be sent to someone’s manager.
The advantage of a custom notification is that we can customize the explanation to why an account is forced to change a password.

The Security Operation team can monitor this event either through the MCAS policy or through AAD Identity Protection.


There has also been a long-awaited Policy where I would recommend some actions.

clip_image002MCAS calculates an investigation priority score based on all signals of the monitored services for all identities in our environment. The MCAS dashboard includes a top list of accounts with the highest risk score. This is not something that previously existed as a dedicated alert.

We have now a new Policy in preview called Investigation Priority Score Increased that alerts if a user has a hefty increase in risk score.


Here I have some recommended settings to evaluate this. It is common for service accounts and other non-user accounts to be detected so my recommendation is to evaluate this on a defined group of user accounts.

We can then automate an action that both sends an alert and enforce the user for MFA and Password Reset. When this is done it will automatically lower the user’s risk score.


As our detect and response (MDR) team use to say,
happy hunting everyone!

Publicerat i MCAS | Märkt | Lämna en kommentar