Announcing Updates to the M365 Attack Simulator

Overview

The Microsoft 365 Attack Simulation team is pleased to announce the release of several new features in our phish simulation tool. This includes:

• an attachment-based phishing attack
• the ability to filter your simulation user targets by directory metadata like title, city, and department
• the inclusion of IP addresses and client data in the simulation detail report
• Simulation phish message simulations are included in your user phish submission reports 

Attachment Attack

We know that phishing attacks that use attachments are very popular and an effective way for attackers to get malicious code to run on your endpoints. Teaching your users to be wary of attachments can reduce your overall risk. To help you educate your users of this risk, we’ve added a new type of simulation attack called Spear Phishing (Attachment) to the catalog.

To launch an attachment attack, navigate to the home page of the Attack simulator:

Then, click Launch Attack and walk through the wizard:

First, give the attachment attack campaign a relevant, distinctive name.

Second, select users from your directory that you wish to target with the attachment attack.

Third, configure the attack with the sender, the name and type of the attachment, and the subject line of the email.

Fourth, enter a custom email template, or use one from the existing library. Remember that the point of the attachment attack is to get the user to open the attachment, so don’t necessarily include a credential harvesting link, but do reference the attachment in the body of the email.

Lastly, confirm that you are ready to send the simulation off.

Within minutes, your users will receive the phishing email and will be able to see the attachment. This attachment does NOT contain any malicious content or executable code. Instead, it relies on a hidden image file which makes a call back to Microsoft’s servers to indicate that the user has opened the file.

Here, you see the user has opened the file, which contains similar content to what you would see on the final page of a credential harvesting simulation. The user’s name is populated, along with some educational messaging about the dangers of phishing.

If you have enabled the Outlook Reporting add-in for your organization, note that the user should go ahead and report this message as phishing.

Once they select report phishing, the user will be asked to confirm the report. Note below that we’re including these reported messages in your report phish message pipeline via the Outlook reporting add-in so you can now track which of your users correctly reported this message as part of the simulation.

After the users have performed their actions, the simulation administrator can then review the final output of the campaign in the Attack Simulator portal.

Directory Filtering

Another quality of life feature we have added is the ability to perform an filtered search of your directory based on metadata like Title, Department, and City. This allows the simulation administrator to refine target groups based on existing directory data instead of having to manually select those users, leverage CSVs, or create custom directory groups. We encourage organizations to target high risk segments of their user population with more frequent simulations to further reduce your risk of getting phished.

Advanced Reporting Updates

The final feature we’ve made available is the inclusion of detailed client information in the detail report of any given campaign, including username, action performed, datetime stamp, IP address, and client type information. This will allow you to better understand where your users are performing the risky actions.

Outlook Reporting Add-In Integration

We’re also including simulation phish messages in the normal reporting pipeline so that you can now track which of your users has correctly reported phish messages as part of the simulation exercise.  This can be found by navigating to Threat Management–>Explorer–>View Submissions–>User Submissions.

Wrapping it up

So, there you have it – a whirlwind tour though the new updates to Office 365 ATP’s Attack Simulator. We’d like to encourage you to start taking advantage of the new functionality by the following the link (https://protection.office.com/attacksimulator) and we look forward to your feedback! More information on Attack Simulator can be found in the Attack Simulator documentation on Microsoft Docs.

Introducing the integrated Microsoft Threat Protection solution (public preview)

Every day, attackers compromise endpoints, identities, and email to infiltrate and quickly expand their foothold in an organization. Customers need protection across these attack vectors to defend against evolving threats. Microsoft Threat Protection is an integrated solution that’s built on our best-in-class Microsoft 365 security suite: Microsoft Defender Advanced Threat Protection (ATP) for endpoints, Office 365 ATP for email and collaboration tools, Azure ATP for identity-based threats, and Microsoft Cloud App Security (MCAS) for SaaS applications.  

Within the suite we’ve been expanding our threat detection and automated investigation and response capabilities, as well as adding cross-product visibility, with additions such as automated incident response in Office 365 ATP, integration of MCAS and Microsoft Defender ATP for deep insight into cloud app usage, integration of Azure ATP with Microsoft Defender ATP, and more.  

Starting today, across the threat landscape security teams can correlate alerts to focus on what matters most, automate investigation and response and self-heal affected assets, and simplify hunting for indicators of attack unique to an organization. They can also use Microsoft Threat Protection to centrally view all detections, impacted assets, automated actions taken, and related evidence. 

Move from alerts to incidents

We are introducing the concept of “incidents,” previously available only for endpoints. These incidents correlate alerts across threat vectors to determine the full scope of the threat across Microsoft 365 products.

For example, we can correlate the following attack sequence: Office 365 ATP observes a malicious email attachment. That attachment contains a weaponized Word document that is opened on the endpoint and observed by Microsoft Defender ATP. The attack then launches queries to the domain controller in search of user accounts to abuse, which is observed by Azure ATP. And, finally, corporate data is exfiltrated to a personal OneDrive account, which is observed by Microsoft Cloud App Security.   

All related alerts across the suite products presented as a single incident (alerts view) 

Cross-product incident (Incident overview) 

Automate threat response

Critical threat information is shared in real time between Microsoft Threat Protection products to help stop the progression of an attack. The central Microsoft Threat Protection logic orchestrates and triggers actions on the individual products. This includes blocking malicious entities and initiating automatic investigation and remediation. 

For example, if a malicious file is detected on an endpoint protected by Microsoft Defender ATP, it will instruct Office 365 ATP to scan and remove the file from all e-mail messages. The file will be blocked on sight by the entire Microsoft 365 security suite. 

Self-heal compromised devices, user identities, and mailboxes

Leveraging the capabilities of the suite products, the integrated solution uses AI-powered automatic actions and playbooks to return all impacted assets to a secure state. Within the portal security teams can use the Action Center to centrally view results of all automated investigations and self-healing actions and approve or undo specific actions.

Action Center – see pending and historical actions taken by analysts 

Cross-product threat hunting

Security teams can leverage their unique organizational knowledge like proprietary indicators of compromise, org–specific behavioral patterns, or free–form research to hunt for signs of compromise by creating custom queries over raw data. Microsoft Threat Protection provides query-based access to 30 days of historic raw signals and alert data across endpoint and Office 365 data.  

Query-based hunting on top of email and endpoint raw data 

Security professionals and customers with the Microsoft 365 E5 license are invited to explore the integrated Microsoft Threat Protection solution public preview. (Eligibility Requirements).  

Visit http://aka.ms/EnableMTP today to learn more. 

Introducing the integrated Microsoft Threat Protection solution (public preview)

Every day, attackers compromise endpoints, identities, and email to infiltrate and quickly expand their foothold in an organization. Customers need protection across these attack vectors to defend against evolving threats. Microsoft Threat Protection is an integrated solution that’s built on our best-in-class Microsoft 365 security suite: Microsoft Defender Advanced Threat Protection (ATP) for endpoints, Office 365 ATP for email and collaboration tools, Azure ATP for identity-based threats, and Microsoft Cloud App Security (MCAS) for SaaS applications.  

Within the suite we’ve been expanding our threat detection and automated investigation and response capabilities, as well as adding cross-product visibility, with additions such as automated incident response in Office 365 ATP, integration of MCAS and Microsoft Defender ATP for deep insight into cloud app usage, integration of Azure ATP with Microsoft Defender ATP, and more.  

Starting today, across the threat landscape security teams can correlate alerts to focus on what matters most, automate investigation and response and self-heal affected assets, and simplify hunting for indicators of attack unique to an organization. They can also use Microsoft Threat Protection to centrally view all detections, impacted assets, automated actions taken, and related evidence. 

Move from alerts to incidents

We are introducing the concept of “incidents,” previously available only for endpoints. These incidents correlate alerts across threat vectors to determine the full scope of the threat across Microsoft 365 products.

For example, we can correlate the following attack sequence: Office 365 ATP observes a malicious email attachment. That attachment contains a weaponized Word document that is opened on the endpoint and observed by Microsoft Defender ATP. The attack then launches queries to the domain controller in search of user accounts to abuse, which is observed by Azure ATP. And, finally, corporate data is exfiltrated to a personal OneDrive account, which is observed by Microsoft Cloud App Security.   

All related alerts across the suite products presented as a single incident (alerts view) 

Cross-product incident (Incident overview) 

Automate threat response

Critical threat information is shared in real time between Microsoft Threat Protection products to help stop the progression of an attack. The central Microsoft Threat Protection logic orchestrates and triggers actions on the individual products. This includes blocking malicious entities and initiating automatic investigation and remediation. 

For example, if a malicious file is detected on an endpoint protected by Microsoft Defender ATP, it will instruct Office 365 ATP to scan and remove the file from all e-mail messages. The file will be blocked on sight by the entire Microsoft 365 security suite. 

Self-heal compromised devices, user identities, and mailboxes

Leveraging the capabilities of the suite products, the integrated solution uses AI-powered automatic actions and playbooks to return all impacted assets to a secure state. Within the portal security teams can use the Action Center to centrally view results of all automated investigations and self-healing actions and approve or undo specific actions.

Action Center – see pending and historical actions taken by analysts 

Cross-product threat hunting

Security teams can leverage their unique organizational knowledge like proprietary indicators of compromise, org–specific behavioral patterns, or free–form research to hunt for signs of compromise by creating custom queries over raw data. Microsoft Threat Protection provides query-based access to 30 days of historic raw signals and alert data across endpoint and Office 365 data.  

Query-based hunting on top of email and endpoint raw data 

Security professionals and customers with Microsoft 365 Security E5 and all M365 E5 licenses are invited to explore the integrated Microsoft Threat Protection solution public preview. (Eligibility Requirements).  

Visit http://aka.ms/EnableMTP today to learn more. 

SharePoint Dev Weekly – Episode 63

Am a keen follower of Microsoft's SharePoint Blog and proud to provide this direct from the Microsoft Tech Community:

In addition to drawing attention to the latest advancements being delivered by the SharePoint Community and Microsoft, Vesa and Waldek’s discussion this week focused on: The continued necessity for code analysis – server-side and browser-side. Fortunately, the job is made easier with the great contributions being delivered by the SPFx community that help drive solid coding projects. Thank you. In the coming week there are more events, fine tuning 1.10 release, CLI updates, and work on Fluid Framework capabilities sure to save users many hours of time.

This episode was recorded on Monday, December 9, 2019.

• SharePoint Dev Weekly – Episode 63 – at SharePoint Dev Blog

The above is kindly provided by the Microsoft Tech Community!

SharePoint Development Community (PnP) – December 2019 update

Am a keen follower of Microsoft's SharePoint Blog and proud to provide this direct from the Microsoft Tech Community:

Latest monthly summary of SharePoint Development guidance for SharePoint Online and on-premises is now available from the SharePoint Dev Blog. Check the latest news, samples and other guidance from this summary.

• SharePoint Dev Ecosystem / SharePoint PnP – December 2019 update – at SP Dev Blog

The above is kindly provided by the Microsoft Tech Community!

A behind the scenes look at how we secure the Microsoft 365 platform

Hey everyone, and welcome to this first post on a topic that we will be talking a lot more about over time!

Microsoft 365 is one of the world’s largest enterprise and consumer cloud services, and customer trust is the foundation of our business: customers and people all around the world rely on us to securely operate and maintain some of their most critical assets. To maintain that trust, we invest heavily in securing the infrastructure that powers our services and hosts this data on behalf of our customers – keeping customer data private and secure is THE top priority for our business. This post, and the other ones we’ll share in this series, will shed light on what we do behind the scenes to secure the infrastructure powering the Microsoft 365 service.

As we think about how to secure our infrastructure, we recognize that the service continues to grow and evolve, both in terms of our user base and in terms of the products and experiences we provide to our customers, and so we must constantly work to stay on top of an ever-increasing surface area. Meanwhile, bad actors are not sitting still, either. Attacker groups seeking to exploit enterprise and consumer data continue to evolve, and customers looking to secure their most sensitive data are going up against the most sophisticated and well-funded adversarial organizations in the world, including nation state attackers with seemingly limitless resources.

To secure the service for our customers given these challenges, we focus on these three areas:

• Building tools and architecture that protect the service from compromise
• Building the capability to detect and respond to threats if a successful attack does occur
• Continuous assessment and validation of the security posture of the service

In the rest of this post we will briefly explore each of these areas, or if you’d like to go deep, you can check out the full whitepaper here.

Designing for Security

Before getting into each of these areas, we wanted to touch on some of the major principles that guide our approach to service security. Here are some of the concepts that form the foundation of what we do to secure service infrastructure:

• Data Privacy: We strongly believe customers own their data, and that we are just custodians of the service that hosts their data.  Our service is architected to enable our engineers to operate it without ever touching customer data unless and until specifically requested by the customer. 
• Assume Breach: Every entity in the service, whether it is personnel administering the service or the service infrastructure itself, is treated as though compromise is a real possibility. Policies governing access to the service are designed with this principle in mind, as is our approach to defense in depth with continuous monitoring and validation.
• Least Privilege: as above, access to a resource is granted only as needed and with the minimal permissions necessary to perform the task that is needed.
• Breach Boundaries: The service is designed with breach boundaries, meaning that identities and infrastructure in one boundary are isolated from resources in other boundaries. Compromise of one boundary should not lead to compromise of others.
• Service Fabric Integrated Security: Security priorities and requirements are built into the design of new features and capabilities, ensuring that our strong security posture scales with the service. At the scale and complexity of Microsoft 365, security is not something that can be bolted on to the service at the end.
• Automated and Automatic: We focus on developing durable products and architectures that can intelligently and automatically enforce service security while giving our engineers the power to safely manage response to security threats at scale. Again, the scale of Microsoft 365 is a key consideration here as our security solutions must handle millions of machines and thousands of internal operators.
• Adaptive Security: Our security capabilities adapt to and are enhanced by continuous evaluation of the threats facing the service. In some cases, our systems adapt automatically through machine learning models that categorize normal behavior (as opposed to attacker behavior which would represent a deviation from the norm). In other cases, we regularly assess service security posture through penetration testing and automated assessment, feeding the results of that back into product development.

The next sections will look into how we put these principles into practice to protect the service, mitigate risk if compromise does occur, and validate our security posture to make sure all of this works.

Minimizing the Risk of Compromise

Our favorite attack is the one that never gets started because we prevented it from happening in the first place. Broadly speaking, protecting the service from attack focuses on two vectors: people (making sure that the Microsoft employees who build and manage the service cannot compromise or damage it), and the technical infrastructure of the service itself (making sure that the machinery running the service has integrated defenses and is architected and configured in a most-secure default configuration).

When it comes to securing the infrastructure from internal operators, our motto here is Zero Standing Access (ZSA). This means that, by default, the teams and personnel charged with developing, maintaining, and repairing core Microsoft 365 services have no elevated access to the service infrastructure, and any elevated privileges must be authorized as shown in the flow below.

Illustration of the Lockbox JIT request process. No account has standing administrative rights in the service. Just in time (JIT) accounts are provisioned with just enough access (JEA) to perform the action that is needed

It is important to keep in mind that even with the approved elevated privileges, a specific restrictive account is provisioned just for that activity. This account is bound by time, scope and approved actions.  Ultimately, this is all about making sure that the blast radius for a single account is minimized: even if an internal operator’s account is compromised, it is by design prevented from doing any damage unless additional steps are taken.

Our protections go beyond restricting the blast radius of accounts. Network controls restrict the types of connections that can be made into our services, we also restrict the types of connections permitted between service partitions. This reduces the surface area for attackers to target for initial entry, and it also makes it harder for attackers to move around the service to find what they’re looking for.

Mitigating Risk if the Worst Happens

The assume breach model goes beyond designing architectural protections and access control policies: it means that no matter how effective those protections are, we cannot trust that they will always hold. We must assume a non-zero probability of successful attack, no matter how confident we are in our defenses. We need to have the ability to detect and mitigate these attacks against the service infrastructure before they result in a compromise of customer data.

Our work in this space spans security monitoring and incident response:

• Security Monitoring: this is about building systems and processes to catch compromise to the infrastructure in real time and at scale, allowing us to respond to and stop attacks before they propagate throughout the service
• Incident Response: we need tools and processes to mitigate risk and evict attackers, also in real time and at scale, in response to the alerts raised by our monitoring systems

Incident response is cloud-powered and service-aware. It can be triggered autonomously for basic actions, or manually for more complex scenarios. Remediation can take effect on a small number of machines, or across a service partition if necessary

As the diagram illustrates, automation and scale are priorities for us in this area. For us to catch and stop attacks against a service the size of Microsoft 365, our systems need to be intelligent enough to proactively and accurately alert us to potential issues, and we need the ability to respond quickly and at scale. Anything less simply won’t do given the scale of the service.

Constant Validation

Our assume breach principle is all about planning for the worst – given how seriously we take this philosophy, we would be remiss if we did not have a plan for mitigating potential gaps in our security posture. Indeed, we validate our security posture regularly, automatically, and through cloud-based tools (we hope that you notice a trend here).

We have two primary forms of validation:

• Architectural and configuration assessment: verifying that promises we make about our service architecture (for example, that specific networks are correctly segmented or that machines are up to date with required patches) hold and do not regress.
• Post-exploitation validation: simulating attacks directly against our infrastructure, with the goal of verifying that our monitoring and response systems work as expected in the production environment.

Both forms of validation run directly against the service infrastructure, and they do so continuously. If any regression in security posture does occur, we want to learn about it as quickly as possible so that we can repair it before it gets exploited by attackers.

Learn More

Securing the infrastructure of one of the world’s largest cloud services requires us to stay ahead of attackers while also keeping up with constantly increasing service scale and complexity. Maintaining customer trust in Microsoft 365 requires us to design our services to a robust set of core security principles and to make sure those principles are embedded deeply into service design and operations.

We have written a whitepaper that looks deeper into what this means, and we will expand on this and other security topics critical to our business in future papers. We hope you find this interesting and informative and look forward to hearing any feedback.

Thank you

@Adam Hall on behalf of the entire Datacenter Security team

A behind the scenes look at how we secure the Microsoft 365 platform

Hey everyone, and welcome to this first post on a topic that we will be talking a lot more about over time!

Microsoft 365 is one of the world’s largest enterprise and consumer cloud services, and customer trust is the foundation of our business: customers and people all around the world rely on us to securely operate and maintain some of their most critical assets. To maintain that trust, we invest heavily in securing the infrastructure that powers our services and hosts this data on behalf of our customers – keeping customer data private and secure is THE top priority for our business. This post, and the other ones we’ll share in this series, will shed light on what we do behind the scenes to secure the infrastructure powering the Microsoft 365 service.

As we think about how to secure our infrastructure, we recognize that the service continues to grow and evolve, both in terms of our user base and in terms of the products and experiences we provide to our customers, and so we must constantly work to stay on top of an ever-increasing surface area. Meanwhile, bad actors are not sitting still, either. Attacker groups seeking to exploit enterprise and consumer data continue to evolve, and customers looking to secure their most sensitive data are going up against the most sophisticated and well-funded adversarial organizations in the world, including nation state attackers with seemingly limitless resources.

To secure the service for our customers given these challenges, we focus on these three areas:

• Building tools and architecture that protect the service from compromise
• Building the capability to detect and respond to threats if a successful attack does occur
• Continuous assessment and validation of the security posture of the service

In the rest of this post we will briefly explore each of these areas, or if you’d like to go deep, you can check out the full whitepaper here.

Designing for Security

Before getting into each of these areas, we wanted to touch on some of the major principles that guide our approach to service security. Here are some of the concepts that form the foundation of what we do to secure service infrastructure:

• Data Privacy: We strongly believe customers own their data, and that we are just custodians of the service that hosts their data.  Our service is architected to enable our engineers to operate it without ever touching customer data unless and until specifically requested by the customer. 
• Assume Breach: Every entity in the service, whether it is personnel administering the service or the service infrastructure itself, is treated as though compromise is a real possibility. Policies governing access to the service are designed with this principle in mind, as is our approach to defense in depth with continuous monitoring and validation.
• Least Privilege: as above, access to a resource is granted only as needed and with the minimal permissions necessary to perform the task that is needed.
• Breach Boundaries: The service is designed with breach boundaries, meaning that identities and infrastructure in one boundary are isolated from resources in other boundaries. Compromise of one boundary should not lead to compromise of others.
• Service Fabric Integrated Security: Security priorities and requirements are built into the design of new features and capabilities, ensuring that our strong security posture scales with the service. At the scale and complexity of Microsoft 365, security is not something that can be bolted on to the service at the end.
• Automated and Automatic: We focus on developing durable products and architectures that can intelligently and automatically enforce service security while giving our engineers the power to safely manage response to security threats at scale. Again, the scale of Microsoft 365 is a key consideration here as our security solutions must handle millions of machines and thousands of internal operators.
• Adaptive Security: Our security capabilities adapt to and are enhanced by continuous evaluation of the threats facing the service. In some cases, our systems adapt automatically through machine learning models that categorize normal behavior (as opposed to attacker behavior which would represent a deviation from the norm). In other cases, we regularly assess service security posture through penetration testing and automated assessment, feeding the results of that back into product development.

The next sections will look into how we put these principles into practice to protect the service, mitigate risk if compromise does occur, and validate our security posture to make sure all of this works.

Minimizing the Risk of Compromise

Our favorite attack is the one that never gets started because we prevented it from happening in the first place. Broadly speaking, protecting the service from attack focuses on two vectors: people (making sure that the Microsoft employees who build and manage the service cannot compromise or damage it), and the technical infrastructure of the service itself (making sure that the machinery running the service has integrated defenses and is architected and configured in a most-secure default configuration).

When it comes to securing the infrastructure from internal operators, our motto here is Zero Standing Access (ZSA). This means that, by default, the teams and personnel charged with developing, maintaining, and repairing core Microsoft 365 services have no elevated access to the service infrastructure, and any elevated privileges must be authorized as shown in the flow below.

Illustration of the Lockbox JIT request process. No account has standing administrative rights in the service. Just in time (JIT) accounts are provisioned with just enough access (JEA) to perform the action that is needed

It is important to keep in mind that even with the approved elevated privileges, a specific restrictive account is provisioned just for that activity. This account is bound by time, scope and approved actions.  Ultimately, this is all about making sure that the blast radius for a single account is minimized: even if an internal operator’s account is compromised, it is by design prevented from doing any damage unless additional steps are taken.

Our protections go beyond restricting the blast radius of accounts. Network controls restrict the types of connections that can be made into our services, we also restrict the types of connections permitted between service partitions. This reduces the surface area for attackers to target for initial entry, and it also makes it harder for attackers to move around the service to find what they’re looking for.

Mitigating Risk if the Worst Happens

The assume breach model goes beyond designing architectural protections and access control policies: it means that no matter how effective those protections are, we cannot trust that they will always hold. We must assume a non-zero probability of successful attack, no matter how confident we are in our defenses. We need to have the ability to detect and mitigate these attacks against the service infrastructure before they result in a compromise of customer data.

Our work in this space spans security monitoring and incident response:

• Security Monitoring: this is about building systems and processes to catch compromise to the infrastructure in real time and at scale, allowing us to respond to and stop attacks before they propagate throughout the service
• Incident Response: we need tools and processes to mitigate risk and evict attackers, also in real time and at scale, in response to the alerts raised by our monitoring systems

Incident response is cloud-powered and service-aware. It can be triggered autonomously for basic actions, or manually for more complex scenarios. Remediation can take effect on a small number of machines, or across a service partition if necessary

As the diagram illustrates, automation and scale are priorities for us in this area. For us to catch and stop attacks against a service the size of Microsoft 365, our systems need to be intelligent enough to proactively and accurately alert us to potential issues, and we need the ability to respond quickly and at scale. Anything less simply won’t do given the scale of the service.

Constant Validation

Our assume breach principle is all about planning for the worst – given how seriously we take this philosophy, we would be remiss if we did not have a plan for mitigating potential gaps in our security posture. Indeed, we validate our security posture regularly, automatically, and through cloud-based tools (we hope that you notice a trend here).

We have two primary forms of validation:

• Architectural and configuration assessment: verifying that promises we make about our service architecture (for example, that specific networks are correctly segmented or that machines are up to date with required patches) hold and do not regress.
• Post-exploitation validation: simulating attacks directly against our infrastructure, with the goal of verifying that our monitoring and response systems work as expected in the production environment.

Both forms of validation run directly against the service infrastructure, and they do so continuously. If any regression in security posture does occur, we want to learn about it as quickly as possible so that we can repair it before it gets exploited by attackers.

Learn More

Securing the infrastructure of one of the world’s largest cloud services requires us to stay ahead of attackers while also keeping up with constantly increasing service scale and complexity. Maintaining customer trust in Microsoft 365 requires us to design our services to a robust set of core security principles and to make sure those principles are embedded deeply into service design and operations.

We have written a whitepaper that looks deeper into what this means, and we will expand on this and other security topics critical to our business in future papers. We hope you find this interesting and informative and look forward to hearing any feedback.

Thank you

@Adam Hall on behalf of the entire Datacenter Security team

New enhancements to Office 365 Message Encryption

We are excited to announce a few new enhancements to Office 365 Message Encryption that help broaden protection and simplify reading protected messages. Updates include:

• Support for PDF attachments
• Support for Shared Mailboxes
• Mac prelicensing

Please read further for more details.

Support for PDF attachments

Office 365 Message Encryption enables users to seamlessly apply protection to the email and its attachments. That means the attachment inherits the same protection applied to the email – further protecting the sensitive content.

Previously only Office document  (e.g. Word, PowerPoint, Excel) were supported, but we are excited to share that Office 365 Message Encryption now also supports PDF attachments.

Recipients will be able to preview the protected PDF directly from Outlook on the web by end of December.  

 You can learn how to enable this setting here.

Support for shared mailbox

We are happy to announce support for viewing protected content sent to a shared mailbox. Enterprise users who have been directly assigned access to a shared mailbox can now open and view protected content in that shared mailbox. Viewing of protected emails in  is now supported cross-platform (e.g. Outlook on the web, Outlook Desktop, Outlook for Mac, and Outlook for iOS and Android) with opening of supported protected attachments on Office in Windows and Mac, and Outlook on the web. Supported attachments include PowerPoint, Excel, and Word files. This functionality is now Generally Available, and no additional configuration is required to enable this. You can learn more here.

Outlook pre-licensing for Mac

In order to allow authorized users to view protected emails and attachments, Exchange automatically attaches a pre-license to protected messages. This eliminates the need for the client to make a service call to retrieve a use license and enables offline viewing of protected content. This functionality has been available on Windows Outlook by default for some time, and we are happy to announce that this has now also been enabled for Outlook on Mac and is Generally Available.

Get started

All these updates are available today. Please review documentation for further details. For any questions you can refer to our documentation.

Thank you!