End to End email protection with Microsoft 365–Part 6

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

End to End email protection with Microsoft 365 – Part 4

End to End email protection with Microsoft 365 – Part 5

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.


Email reporting and auditing

It’s now time to look at all the logging that occurs during even the simply process of receiving and viewing an email. For starters there is:

Message tracing

and

Message trace in the modern Exchange admin center

Message trace in the Security & Compliance Center follows email messages as they travel through your Exchange Online organization. You can determine if a message was received, rejected, deferred, or delivered by the service. It also shows what actions were taken on the message before it reached its final status.

There is also reporting options like:

Mail flow insights in the Security & Compliance Center

and

Mail flow reports in the Reports dashboard in Security & Compliance Center

as well as:

Microsoft 365 Reports in the admin center – Email activity

If you want to specifically look at email security there is:

Email security reports in the Security & Compliance Center

as well as:

Defender for Office 365 reports in the Reports dashboard in the Security & Compliance Center

and

Reports for data loss prevention (DLP)

I have also spoken about the importance of the Unified Audit Logs (UAL) in Microsoft 365:

Enable activity auditing in Office 365

Unified Audit Logs in Microsoft 365

and you need to ensure that these have been enabled so that you can:

View mailbox auditing

Starting in January 2019, Microsoft is turning on mailbox audit logging by default for all organizations. This means that certain actions performed by mailbox owners, delegates, and admins are automatically logged, and the corresponding mailbox audit records will be available when you search for them in the mailbox audit log.

Here are some benefits of mailbox auditing on by default:

  • Auditing is automatically enabled when you create a new mailbox. You don’t need to manually enable it for new users.

  • You don’t need to manage the mailbox actions that are audited. A predefined set of mailbox actions are audited by default for each logon type (Admin, Delegate, and Owner).

  • When Microsoft releases a new mailbox action, the action might be automatically added to the list of mailbox actions that are audited by default (subject to the user having the appropriate license). This means you don’t need to monitor add new actions on mailboxes.

  • You have a consistent mailbox auditing policy across your organization (because you’re auditing the same actions for all mailboxes).

With this auditing enabled you can do things like:

Reporting mailbox logins

and

Search the Office 365 activity log for failed logins

as well as

Audit Office 365 user logins via PowerShell

Many of the reports that you find in the Microsoft 365 Admin area can be scheduled to be sent via email per:

Scheduling compliance reports

Apart from auditing and security you can also do more typical things like:

Viewing mailbox usage

Viewing Email apps usage

The availability of all this data is covered here:

Reporting and message trace data availability and latency

typically being 90 days.


User reporting and auditing

For information more specifically about user logins into the service and the Identity container, the best place to look is in Azure Active Directory (AD).

What are Azure Active Directory reports?

Find activity reports in the Azure portal

Azure Active Directory sign-in activity reports – preview

Audit activity reports in the Azure Active Directory portal

and if you want use PowerShell

Azure AD PowerShell cmdlets for reporting

Device reporting and auditing

There are lots of options when it comes to monitoring and reporting on devices. Apart from what is offered locally you also have:

Intune report

Create diagnostic settings to send platform logs and metrics to different destinations

Manage devices with endpoint security in Microsoft Intune

You can even get telemetry data and analytics reports from your desktop applications via:

Windows Desktop Application Program


Aggregated data reporting and monitoring

As you can see with all the options above, it is easy to get to information overload trying to keep up with all those signals. Luckily Microsoft provides a range of services to aggregate all this for you to make monitoring and report easier.

The first is Microsoft Cloud App Security services:

Cloud App Discovery/Security

Microsoft Cloud App Security overview

Microsoft Cloud App Security data security and privacy

There are plenty of reasons why you really should have Microsoft Cloud App Security in your environment:

A great security add on for Microsoft 365

Office 365 Cloud App Discovery

Next, is Microsoft Defender for Endpoint that will aggregate security and threat information for devices in your environment and make it available in a single console.

Overview of Microsoft Defender Security Center

Microsoft Defender Security Center portal overview

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint evaluation lab

Finally for me, there is Azure Sentinel, which I see as really the ultimate hub for event reporting, monitoring and alrtign across the whole service.

Another great security add on for Microsoft 365

Introduction to Azure Sentinel

Azure Sentinel is a service that growing in features rapidly:

A couple of new additions to Azure Sentinel

Stay ahead of threats with new innovations from Azure Sentinel


Summary

Hopefully, all this gives you some insight into all the auditing and usage data that Microsoft 365 captures during any interaction within the service. One of the biggest benefits is also how this information is integrated between services, especially those that aggregate information lime Microsoft Cloud App Security and Azure Sentinel. This means you don’t have to crawl through individual log entries, you can use a dashboard and drill down from there. I also like the fact that all of these services and data are accessible using a scripting tool like PowerShell if you want to automate this further.

Remember, throughout this six part series I’ve just looked at what happens when a single email is delivered and view with Microsoft 365. If you expand that out to all the services and capabilities that Microsoft 365 provides you can hopefully get a better appreciate of the protection it provides in place for your data on many different levels.

The call to action for readers is to go away and implement all the security features that Microsoft 365 provides. This may of course vary by the license that you have. You should then consider what additional security offerings the Microsoft cloud stack can offer that makes sense for your business, then implement those. Remember, security is not a destination, it is journey.

Get Intune and Endpoint policies using PowerShell

Recently, I wrote an article about how to use PowerShell to connect to Intune and Microsoft Endpoint Manager. You’ll find it here:

Intune connection PowerShell script

Having a script that just connects to Intune doesn’t achieve a whole lot now does it? It’s now time to put that connection script to good use.

image

I’ve created another script, that once connected to Intune will allow you to display all the policy names you have configure in both Intune and Endpoint Manager as shown above. You can find that script here:

https://github.com/directorcia/Office365/blob/master/intune-policy-get.ps1

You’ll need to use my script to connect to Intune first. Once you have you can run the second script.

Although these scripts don’t do a huge amount, they will help you hopefully more easily connect to Intune with PowerShell and understand how you can also use PowerShell to work with information in both Intune and Endpoint Manager.

I’ll work on more advanced scripts for Intune and Endpoint that I’ll share in the future. However, this should hopefully get you up and running with automating device management in Microsoft 365.

End to End email protection with Microsoft 365–Part 5

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

End to End email protection with Microsoft 365 – Part 4

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In the previous part we had arrived at the stage where the user had successfully logged into a Windows 10 device.

At this point, the user is most likely to launch Outlook to read their emails. Visually the process is going to look like:

image

The email has been delivered from outside the Microsoft 365 Service to the Data container. The User has authenticated themselves via various methods to the Device container. An App on the device will now apply the User authentication to allow the App access to Data container to retrieve the email so it can be displayed to the User.

The focus for this articles will be the access of the App (Outlook) to the email Data as mentioned.

When it comes to the security of this interaction the place to start is to ensure that the App (Outlook) is supported and up to date. The first thing to check is:

What version of Outlook do I have?

and make sure that it is supported by the Service:

Office versions and connectivity to Office 365 services

Given that most Microsoft 365 plans come with a subscription to Office on the desktop, the assumption here is that it is fact supported. There are various ways to:

Download and install or reinstall Microsoft 365 or Office 2019 on a PC or Mac

but for simplicity the assumption will be that it is installed and maintained using:

Deploy Microsoft 365 Apps with Microsoft Endpoint Configuration Manager

It is obviously very important to ensure that all applications that access secure data are updated regularly.

Choose how to manage updates to Microsoft 365 Apps

How to install the latest applicable updates for Microsoft Outlook (US English only)

The assumption will be that, via whatever method, the Microsoft Office desktop application are indeed up to date.

When the Outlook app runs, it will do so on the device, which will be typically connected to the public Internet. this means it is going to need top copy data from the secure Data container in the above model to the secure Device container which lives in another location.

Transferring secure data across an insecure medium like the Internet involves a lot of technology. A lot of them you can read here:

Exchange-Outlook Protocols Documentation

however the most relevant is probably:

How Exchange Online uses TLS to secure email connections

Microsoft 365 is also moving to TLS 1.2 in Office 365 for further security.

Once the email data has traversed from the Data container in Microsoft 365 to Outlook on the user Device is typically stored in an OST file on the local machine.

Introduction to Outlook Data Files (.pst and .ost)

This OST data file is not itself encrypted but the location in which it resides on the device is encrypted using BitLocker.

Outlook incorporates a number of in-built security features including:

Outlook blocked access to the following potentially unsafe attachments

Security Behavior of the Outlook Object Model

Protected Properties and Methods

New feature in Office 2016 can block macros and help prevent infection

Plan security settings for VBA macros in Office 2016

Enable or disable macros in Office files

Overview of the Junk Email Filter

Emails in Outlook will also be protected by Defender for Office 365:

Zero-hour auto purge (ZAP) in Exchange Online

Safe Links in Microsoft Defender for Office 365

Safe Attachments in Microsoft Defender for Office 365

Yet another layer of protection will be:

Microsoft Defender for Endpoint

including technologies like Attack Surface Reduction (ASR) which I have detailed previously:

Attack surface reduction for Windows 10

Further data protection can then be provided by Windows Information Protection (WIP) per:

Protect your enterprise data using Windows Information Protection (WIP)

“Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps.”

For example, if WIP was implemented, it would prevent user saving corporate attachment to non-compliant devices. Perhaps like a USB key.

Further still there is:

Azure Information Protection

which protects information no matter where it travels.

So even when a copy of the email is sitting in Outlook on the desktop it is and can be protected by a wide variety of technologies in Microsoft 365.

image

If we now take a step back and have a look at a summary of many of the protections we have been talking about so far we would see something like shown above. Remember here that all we have focused so far on is email! Many of these protections will in fact protect information as well as the protection it provides for email. The take away is, in a nutshell, there is a lot of stuff protecting user data provided by Microsoft 365.

Although there is a lot of protection capabilities in Microsoft 365, many of the protection services are either not enabled by default, require unique policies or have generic policies. It is important for each organisation to evaluate what their security requirements are (i.e. what they want to protect) and then implement the services available to them in Microsoft 365 to meet these requirements. The take away is, if you want all the protection features available in you need to configure them, they don’t all magically work to your requirements out of the box!

Also, simply enabling or configuring all these services is something that will need to be continually reviewed and adjusted over time. We’ll also cover that topic in some details in upcoming articles.

Now you can enable all these services and make everything super secure but doesn’t provide absolute security, because that simply doesn’t exist. It will certainly mitigate the majority of threats out there but it still means that the whole environment needs to be monitored constantly to ensure nothing is getting through. Remember, every time we cross a container boundary above, logs are generated. Where and how to use these logs will be the subject of the next part in this series, so stay tuned.

End to End email protection with Microsoft 365–Part 6


New Intune connection PowerShell script

image

I’ve uploaded a new connection to Intune script that is freely available on my Github repository. You’ll find it here:

https://github.com/directorcia/Office365/blob/master/Intune-connect.ps1

image

Once it has been run you can run commands like:

get-autopilotprofile

as shown above.

To allow this script to operate correctly you’ll need the following two modules installed:

WindowsAutoPilotIntune

and

Microsoft.Graph.Intune

Both of these will be installed as part of my o365-setup.ps1 and o365-update.ps1 scripts, which are also freely available.

image

I’ve also added this Intune connection script to the connection selector script (c.ps1) in the same repository.

image

When intune-connect.ps1 runs you’ll be prompted for your credentials as normal.

image

Then you password and MFA if required.

image

Because connection to Intune via PowerShell now uses the Microsoft Graph, you’ll need to allow the above permissions as shown once.

SNAGHTML95fe247f

You’ll find those permissions, when you accepted them, in Azure AD, User, Applications as shown above inside the Azure portal. In there will be an application called Microsoft Intune PowerShell as shown above.

image

If you select that Microsoft Intune PowerShell and scroll down to the bottom of the screen that is displayed, you can select a link View granted permissions as shown above.

image

You will then see all the permission granted to that user for accessing the Graph. You can also remove these if you ever want to as well here.

Having access to Intune and Autopilot via PowerShell will make automating device management much easier.

End to End email protection with Microsoft 365–Part 4

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.

For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.

A range of hardware device protection is available and recommended including:

and should already be in place to protect the device.

We will also assume that the Windows device is fully up to date

How to keep your Windows computer up to date

The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):

Azure AD joined devices

Join your work device to your organization’s network

Tutorial: Join a new Windows 10 device with Azure AD during a first run

When that device is turned on we want it to complete the:

Secure Windows boot process

Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:

Manage device security with endpoint security policies in Microsoft Intune

Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.

Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:

Use compliance policies to set rules for devices you manage

All of this is achieved via:

Microsoft Endpoint Manager

which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:

Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10

Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.

The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.

Windows Hello for Business Overview

Windows Hello addresses the following problems with passwords:

  • Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.

  • Server breaches can expose symmetric network credentials (passwords).

  • Passwords are subject to replay attacks.

  • Users can inadvertently expose their passwords due to phishing attacks.

Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.

Why a PIN is better than a password

How Windows Hello for Business works

These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Your Pa$$word doesn’t matter

All your creds are belong to us!

So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.

Five steps to securing your identity infrastructure

Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:

Multifactor Unlock

It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.

Enable multi-factor authentication for free

Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.

It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.

Conceptual Conditional signal plus decision to get enforcement

What is Conditional Access?

For example, user account access can be blocked if it comes from outside a specific country or region.

Conditional Access: Block access by location

and enforcing MFA

Conditional Access: Require MFA for all users

Conditional Access: Require MFA for administrators

Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.

Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.

End to End email protection with Microsoft 365–Part 5

Need to Know podcast–Episode 261

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-261-mark-oshea/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

I speak with a returning guest Mark O’Shea around the changes we’ve seen recently in Microsoft 365, especially around device management and Microsoft Endpoint Manager. The whole device deployment and management landscape is changing fast. It all used to be about Intune but now the focus is really Endpoint Manager and Mark helps us understand the why’s and what fors.

I’ve also got a swag of Microsoft Cloud news to share with you to bring up to date with the latest happenings.

As always, thanks for being a subscriber and don’t hesitate to share what I do with others.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Resources

@intunedin

Intunedin.net

@directorcia

What’s New with Microsoft 365 | November 2020 [VIDEO]

What’s New in Microsoft Teams | November 2020

Teams Breakout rooms go GA

Microsoft Edge v.88: Deprecate support for FTP protocol

Microsoft Edge v.88: Adobe Flash support will be removed

Microsoft Edge v.88: Alerts if your passwords are found in an online leak

Add to OneDrive is generally available

Introducing the SharePoint Success Site – Drive adoption and get the most out of SharePoint

Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them

New datacenters for Sweden, Denmark, and Chile

CIAOPS Patron community

Need to Know podcast–Episode 260

We welcome back Brenton Johnson to speak about his success with Intune and how he’s using it to manage devices for his customers. Brenton shares his journey as well as some handy best practices during our chat.

Of course, there is also all the Microsoft Cloud news to get through, so sit back and enjoy this bumper episode.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-260-brenton-johnson/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@contactbrenton

@directorcia

Uptake Digital

Power Apps Community plan

Meet the Microsoft Pluton processor – The security chip designed for the future of Windows PCs

The Microsoft Cloud App Security (MCAS) Ninja Training is Here!

Extend data loss prevention to your devices with Microsoft Endpoint Data Loss Prevention, now generally available

It’s Time to Hang Up on Phone Transports for Authentication

See how to easily keep tabs on your Azure Sentinel ingestion costs

What’s new: Microsoft 365 Defender connector now in Public Preview for Azure Sentinel

Microsoft’s Cloud PC: Leak reveals new details on upcoming Azure-powered remote desktop

What’s New in Microsoft Teams | October 2020

The definitive guide to Productivity Score

Intune Data Collection Policy Error 0x87d1fde8

State = error

State Details = -2016281112 (Remediation failed)

image

It all started when I was checking my Intune Configuration policies and I found that all of a sudden I have a new policy called Intune data collection policy as shown above, that I didn’t created. Worse, it had errors!

image

When I looked at a specific device that was affected, as shown above, I could see two errors on the device. One was from a user designated as System account, which was also somewhat puzzling.

image

Digging further I found that the State was Error and the State details were -2016281112 (Remediation failed) as you can see above.

image

At the most granular level, I found the Error code was 0x87d1fde8 as shown above.

image

It turns out that the Intune data collection policy gets created when you use Endpoint Analytics as shown above.

image

This gives you some really nice reports as shown above on your Windows devices. You can read more about it here:

What is Endpoint Analytics?

I had now solved where the mystery Intune data collection policy came from and after much research it turns out that the device errors are because of licensing as you can read here:

Licensing Prerequisites

which says:

Endpoint analytics is included in the following plans:

Proactive remediations also require one of the following licenses for the managed devices:

  • Windows 10 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5)

  • Windows 10 Education A3 or A5 (included in Microsoft 365 A3 or A5)

  • Windows Virtual Desktop Access E3 or E5

The error I was seeing was due to those machines only being Windows 10 Pro, NOT Win 10 Enterprise! Endpoint Analytics currently only works with Windows 10 Enterprise licensed devices.

Once I had changed the Intune data collection policy to exclude the Windows 10 Pro machines the errors went away, as did the duplicate System account as well.

Hopefully, Microsoft will consider extending Endpoint Analytics to Windows 10 Pro machines as well, but for now you’ll need to exclude them from any Intune data collection policy if you don’t want errors in Endpoint Manager.