Pratum Blog

Microsoft Office 365 Security Best Practices and Recommendations

Introduction

Since we first published this blog in 2018, Microsoft has updated its default audit settings, including improved mailbox auditing starting in January 2019. But even as Microsoft ups its game, it’s critical for you to review, configure and tune the appropriate settings within Microsoft 365’s various services to ensure that you’re meeting proper risk tolerance levels.

Microsoft leverages a defense-in-depth approach in an effort to adhere to operational best practices to provide physical, logical, and data layer protections. These layers help to protect all 365 users, but every organization must ensure that their implementation and configuration of their tenant are configured securely.

Pratum highly recommends that you review the following guide and implement its ideas as needed. Remember: These defaults impact new mailboxes. Audit settings should be reviewed for any accounts created prior to January 2019.

Business E-mail Compromise

Phishing causes a considerable share of all breaches and cyber incidents within organizations, especially those with Microsoft 365. Forensic analysis typically reveals the culprit is an e-mail that posed as a shared document hosted in a domain that looks remarkably like OneDrive. When the user clicks the link, they arrive at a sign-in page that mirrors Microsoft’s 365 login page. Unfortunately, the credentials entered within this fake screen go straight to the attacker, who may then have complete access to the user’s e-mails and files. That’s what makes multifactor authentication (MFA) one of the most successful ways of preventing an attacker from gaining access even after they have compromised a password.

It’s also critical that you recognize when a password has been compromised. It becomes even more important if the attacker successfully authenticates to the victim's data. This information is key to investigating what activity was performed or determining whether it triggers breach notification requirements.

To ensure you have sufficient data to detect these threats or perform a proper investigation, you must ensure your Microsoft 365 tenant is auditing all the crucial areas. In January 2019, Microsoft recognized the need for this information and enabled it with respect to mailbox auditing.

Reference: Manage Mailbox Auditing

Verify mailbox auditing is on by default
Get-OrganizationConfig | Format-List AuditDisabled

Enable Audit Logging

Event data containing critical information; such as user and system activity, changes, authentication details, etc.; is extremely important to have captured log data to detect threats, especially when performing an investigation. An administrator must manually enable the “Office 365 audit log search.” This feature may record user and admin activity for 90 days; however, it is best to validate which retention settings are configured based on licensing/configuration. This data can typically and should be piped to a security information and event management (SIEM) solution for additional monitoring and correlation. Note that only mailbox audit events for E5 users are available in the audit log searches within the Security & Compliance Center or through the Office 365 Management Activity API.

Reference: Enabling Audit Logging

Use the Security & Compliance Center to turn on audit log search
  • In the Security & Compliance Center, go to Search & investigation > Audit log search.
  • Click Start recording user and admin activities.
Enabling auditing via Powershell
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
Validate whether auditing is enabled/disabled via Powershell
Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled

Enable Mailbox Auditing

In Office 365, administrators should enable mailbox audit logging to record mailbox access activity. By default, mailbox auditing is disabled. If a security incident occurs, there may be very little data if any regarding an attacker’s activity. However, once audit logging is enabled, the audit log can be searched for mailbox activity. Additionally, when mailbox audit logging is turned on, some actions performed by administrators, delegates, and owners are logged by default. It is recommended to enable at a minimum the default logs as well as the referenced commands below; however, each organization should determine what logging level is needed.

We highly recommend enabling the ‘UpdateInboxRules’ setting for all types of users. Attackers commonly set up a forwarding rule that forwards a copy of the user's inbox to a second address such as a Gmail account. This provides them persistent access to the user’s e-mail even after they update their password! We recommend auditing and reviewing these rules. Be prepared to add logic to filter out legitimate, employee-created forwarding rules. We recommend using logic that looks for forwarding rules that are redirecting e-mail outside of the organization or tenant domain. Even if an employee is attempting to forward e-mail to their personal mailbox, this is a bad practice, as the data is no longer controlled or protected by company policies.

Reference: Enabling Mailbox Auditing, Mailbox Auditing Actions

Enabling auditing via Powershell for all user mailboxes in your organization
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditEnabled $true
Increasing audit levels via Powershell for all user mailboxes in your organization
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditOwner @{Add="MailboxLogin","HardDelete","SoftDelete","MoveToDeletedItems"}
Validate whether auditing is enabled/disabled via Powershell
A value of True for the AuditEnabled property verifies that mailbox audit logging is enabled.
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | FL Name,Audit*

Enable and Enforce Multi-Factor Authentication

Pratum highly recommends the use of multi-factor authentication. User accounts are compromised daily resulting in the increased risk to losing control of key data and information. Business email compromise and credential harvesting attacks are a constant threat to an organization. One of the best security defenses to thwart this loss is requiring users to use multi-factor authentication (MFA) to access key systems, such as email and file sharing. MFA can significantly decrease the success of an attacker tactics even when they compromise the user’s password, as they would also need to compromise the additional factor. These additional factors can be in many forms, such as a hard token or an application on a smart device. There exist multiple methods and solutions for multi-factor authentication for Microsoft 365, and the configuration options will vary depending on licensing. Azure, Intune, and Enterprise Mobile Device Management plans offer additional capabilities when deploying or enforcing this security feature.

Reference: Enabling Azure Multi-factor Authentication, Requiring MFA for Intune Enrollment

Conditional Access Policies

Administrators can review and enforce additional restrictions or relax certain policies such as multi-factor authentication requirements when users are accessing resources from a trusted location or compliant device. These scenarios increase the likelihood the user accessing the resource is trusted and therefore decrease the security requirements needed to authorize the user. This feature works very well to find the right balance between security and convenience. Furthermore, restricting access from locations and devices that employees should never be logging in from can also be enforced and alerted against. An Azure AD Premium license is required for use of conditional access policies.

Reference: Configuring Conditional Access Policies, Azure AD License Comparison

Mobile Device Management

Mobile device management (MDM) should be reviewed and understood by each organization. Ensuring the proper policies are defined and agreements are in place for employees of the business. Exchange Administration can be configured to define policies on which devices/users can communicate with the email servers. Policies to enforce compliance to company policies such as device encryption should be enabled as well as which devices can connect. For additional features and control, plans can be purchased for Microsoft Intune and/or Enterprise Mobility Security.

Reference: MDM for Office 365 versus Microsoft Intune

Exchange Administration

Configuring Exchange Email Encryption Rule

Users that are communicating via email, and have a E3 or higher license, can leverage Office 365’s Message Encryption feature. An administrator can also define a mail flow rule to encrypt email messages that contain a keyword in the subject. Encryption with Rights Protection can be leveraged to reduce the ability for users that receive encrypted messages to forward them to unintended recipients, print, or access them within certain time restrictions.

Reference: Define a Mail Flow Rule to Encrypt Email

Define Spoofing Filter Rule

A rule can be created via Exchange Admin Center to set the spam confidence level (SCL) to ‘9’ if the messages sender’s address domain belongs to any of the organizations valid domains and the message is received from ‘Outside the organization.’ A spoofing filter rule definition will help limit the amount of phishing emails that are delivered.

Configure DMARC and SPF Records to Validate Email

Implementing DMARC (Domain-based Message Authentication, Reporting and Conformance) with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) is recommended for all organizations. These features provide an additional layer of protection against spoofing and phishing emails. They can also help to reduce the risk of business email compromise attacks. DMARC settings will tell the Exchange servers what to do with messages that were transmitted with the organization’s domain that fail SPF or DKIM validation checks.

A DMARC TXT Record also helps to prevent spoofing and phishing attacks by verifying the IP address of an email's author against the alleged owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. The destination email server can validate the message that originated from the authorized outbound email servers.

An SPF record is used to define IP’s that are authorized to transmit email for a given domain. This way, if an attacker spoofs the organizations domain from an IP address not on the list it can fail delivery to the recipient automatically.

DKIM should be configured once the SPF and DMARC records have bene created. DKIM adds a digital signature to each email message’s header information. It is highly recommended the DMARC settings are reviewed and deployed with careful consideration such not to disrupt intended mail flow.

Reference: Define DMARC to Validate Email

Define DMARC Failure Rule

After DMARC is configured for an organization a rule should be created in the Exchange Admin Center to direct where mail that fails the DMARC validation is directed. A definition can be created such as ‘Deliver the message to the hosted quarantine’ if ‘authentication-results’ header contains “dmarc=fail” and sender’s address domain portion belongs to any of the organizations valid domains and the message is received from ‘Outside the organization.’ Under Additional properties the Sender address matches should be set to Header.

Define Data Exfiltration Rule Restrictions

Business email compromise can result in attackers configuring mailbox forwarding rules to send a copy of email outside of the organization to a 3rd party email domain. Employees may also desire to send copies of emails to personal email accounts. These forwards reduce the overall security of the organization. A rule can be created in the Exchange Admin Center to reject any messages and include an explanation that client forwarding rules to external domains are not permitted. This rule can be defined if a message is sent ‘outside the organization’ and the message type is ‘auto-forward’ and the email is received from ‘inside the organization.’ It may also be beneficial to configure alert definitions based on these conditions to ensure an account was not compromised. An alert definition can be defined while creating the rule to email a notification to the defined contact upon triggering.

Configure Connection Filters

Enabling the safe list of IP addresses that are permitted for each respective domain can help to reduce trusted senders from getting blocked.

Reference: Connection Filters

Configure Alert Policies

Configuring alert policies can help track user and administrator activities, malware threats, and data loss incidents within each organization. Alerts should be defined for malware incidents, email forwarding/redirect rules, anomaly detection, and suspicious activity at a minimum. It is highly recommended event data is also transmitted to a SIEM solution for correlation and long-term event storage. If a traditional SIEM is not being leveraged, consider Microsoft's Cloud Native SIEM, Sentinel. They allow for free logging of many Microsoft 365 events for 30 and even 90 days in certain scenarios. Additional fees may apply and typically include data storage within log analytics or any custom event sources. Consider a managed service provider such as Pratum to assist with a fully managed environment.

Manage Office 365 Secure Score

Microsoft Secure Score will help analyze each organizations Office 365 security based on administrative activities as well as audit security settings and make recommendations. A score is then provided based on the settings and is re-evaluated in an on-going basis. Secure score is a fantastic tool that will help you understand and evaluate how you are offsetting risk by leveraging the various security features across 365. It is highly recommended all of the results are evaluated and considered for your organization. *Note: Settings should be carefully reviewed and exceptions may need to be made to not disrupt mail flow for legitimate emails which are being spoofed intentionally. The Secure Score feature is being heavily supported and being rolled out across multiple areas of the Microsoft 365 cloud. This scoring feature should be reviewed on a reoccurring basis as it provides a valuable amount of data and is becoming more sophisticated with each release.

Reference: Secure Score Overview

Security & Compliance Features

There exists a multitude of features highlighted below within Microsoft 365 that should be reviewed and configured with appropriate settings. These features should each be used in accordance to the business’s IT Security requirements, the following should also be considered/configured within the Security and Compliance section.

Data Loss Prevention – Policy protection to assist with identifying and protecting sensitive data.

Data Governance – Assists with classifying content, defining retention rules and data destruction.

Classifications – Labels can be applied to email or documents to enforce policies such as retention settings or sensitivity.

Data Privacy – GDPR requirements and access to their personal data.

Threat Management – Threat tracking and attack simulators can be performed to assess risk.

Customer Lockbox

Customer lockbox requests allow organizations to control how a Microsoft support engineer accesses company data when necessary to do so. It is available through the E5 plan or with the advanced compliance license. This feature should be enabled if available.

Reference: Enable Customer Lockbox

Summary

Microsoft has millions of users leveraging Microsoft Office 365 with expectations of over two thirds of its business customers being in the cloud by 2019. Microsoft leverages a defense-in-depth approach in effort to adhere to operational best practices to provide physical, logical, and data layer protections. These layers help to protect all individuals that leverage 365, however, it is the responsibility of each organization that uses 365 ensure their implementation and configuration of their tenant is also configured securely. Each business has the responsibility to review, configure and tune the appropriate settings within the various areas of Microsoft 365’s services to ensure proper risk tolerance levels are met.

For assistance with evaluating your organizations risk or cyber security needs, please contact Pratum.

Editor's Note: This post was originally published in July 2018 and has been updated for accuracy and comprehensiveness.
Technology vs. Terminology

Over the years, the idea of intrusion prevention has morphed well beyond the traditional packet inspection. So when you have a conversation about intrusion prevention, it’s important to make sure that you agree on its definition.

In this world, semantics matter. Using an old network-based IPS appliance as your intrusion prevention system may be exactly what you ordered. But it also may leave you horribly exposed when you thought you were getting a more wholistic solution. Clear communication around objectives and the ways to meet those objectives is always better than simply asking for specific methods and technologies.

Information security technologies constantly mature to keep pace with the ever-growing threat, and that blurs lines between traditional technologies or methods. Along the way, the words used to describe various tools evolve. And that means that simply ordering up a tool based on a name you recognize from the past could leave you less prepared for threats than you think.

Intrusion prevention, specifically, currently means many things to different people. Some still look at it in the traditional packet sense. Some consider it a host-based system that looks at network activity, OS and kernel functions, and application calls. Others look at it as an entire methodology that not only detects behavior but can modify security configurations on the fly across an entire organization to address threats in real-time. Needless to say, the idea of intrusion prevention is not the same today that it was even 10 years ago.

The changing views of Intrusion detection (IDS) and prevention (IPS) have followed roughly this progression:

  • At first, IDS simply alerted to potentially malicious or abnormal behavior based on the signature of the data payload in a packet.
  • Then we moved to actively blocking these suspicious packets in IPS. But these were still network-based systems. Traffic had to flow through a choke point to be inspected along its travels.
  • As threats changed, we moved to host-based IPS and looked at packets as they reached their destination. This helped address threats that somehow bypassed a network IPS or came from an internal source.

Focus on Your Security Objectives — Not Just a Technology

As protection methods and terminology evolve to respond to the cybersecurity threat landscape, cybersecurity professionals must work with each other, with infrastructure and application development teams and with business leadership to understand the protection objectives they have to meet.

Consider the evolution of firewalls as one example of how we must constantly update our thinking about a technology:

  • Traditional firewalls operated at Layer 3 of the OSI model. It was clean and simple. Once a packet reached Layer 3, IP addresses were assigned, and we could identify the source and destination. Administrators created rules that permitted or blocked traffic based on that information.
  • Then we moved to inspecting the ports the traffic was flowing to. Next, we moved up the stack to inspect the payload and compare it to the port. We knew we shouldn’t see FTP commands in an SMTP packet, so we’d block that traffic.
  • Today, we have Next Generation Firewalls (NGFW) and Web Application Firewalls (WAF) that inspect all seven layers and use combinations of rules to govern whether a packet reaches its destination.

See the Control Environment as a Whole

When evaluating technologies, it’s critical to view the control environment in a very wholistic way. I like the Cyber Kill Chain developed by Lockheed Martin, which helps frame protection scenarios by showing the following seven stages in the lifecycle of a cyber attack:

1. Reconnaissance – Harvest e-mail addresses, conference information, etc.

2. Weaponization – Coupling exploit with backdoor into deliverable payload.

3. Delivery – Delivering weaponized bundle to the victim via e-mail, web, USB, etc.

4. Exploitation – Exploiting a vulnerability to execute code on victim’s system.

5. Installation – Installing malware on the asset. 

6. Command & Control (C2) – ommand channel for remote manipulation of victim. 

7. Actions on Objectives – With “Hands on Keyboard” access, intruders accomplish their goals. 

Clearly, it takes many different technologies and methods to prevent intrusions. Each step of the kill chain affords us the opportunity to identify, protect, detect, respond and recover.

Many organizations need an outside opinion to help them step back from their own environment and see the right solutions for the entire landscape. To get help forming your most effective strategy, check out our cybersecurity consulting services or contact us today.

Guidelines for a Tangled Legal Landscape

When you discover that a hacker has penetrated your system, the scramble is on to respond properly. And nobody is going to be the first to suggest, “Let’s tell all our customers what just happened!” But as tempting as it is to bury a breach deeper than a political scandal, that move has a couple of drawbacks:

1. Any good public relations consultant will tell you that the best way to manage bad news is to get out ahead of it and drive the narrative.

2. Burying news of the breach is probably illegal.

But even when you genuinely want to follow your legal obligations for reporting breaches, the law doesn’t make it easy. All 50 states have their own codes in this area. You can look up your state’s notification laws on a site like this one. After you’ve waded through all the statutes, however, the way forward will almost certainly remain murky.

Matthew McKinney, an attorney with BrownWinick in Des Moines, Iowa, says, “What’s commonly misunderstood about breach notification? Almost everything. It’s still the Wild West. There’s no universal standard. The biggest thing is the uncertainty and the lack of uniformity.”

In many states, lawmakers and industry associations are working to pass codes built on frameworks that offer uniform standards across state lines. In Iowa, for example, McKinney is working with the Iowa Insurance Division on a new act the Division crafted that proposes to implement standards for insurance companies and that follows a model developed by the National Association of Insurance Commissioners.

In the meantime, answers to breach notification questions almost always start with, “Well, it depends…” But the following guidelines address some common questions.

Which industries are subject to breach notification requirements?

As with most data privacy laws, the healthcare and financial services industries face the heaviest breach notification frequency given they often hold the most sensitive and valuable personal data. HIPAA, for example, established some of the earliest requirements for notifications of compromised data. But at this point, nearly every business has notification responsibilities to follow.

What are my first steps regarding notification when a breach happens?

Ideally, you have a solid incident response plan in place, so no one has to figure out next steps under the pressure of a crisis. As part of that plan, make sure you’re building a relationship in advance with a digital forensics team, qualified attorneys and a cyber insurance firm.

As we’ll discuss below, the forensics team can help clarify your notification requirements based on what data was actually affected.

McKinney says it’s also important to have legal counsel available as soon as you discover the breach due to potential liability considerations, the benefit of privileged communications, and compliance with some strict breach notification requirements that, in some cases, have windows as short as 72 hours.

What events trigger a notification requirement?

This is where things start getting fuzzy.

One thing that generally doesn’t matter is the number of customers affected. So thinking, “We’re not Facebook, so our little breach doesn’t really matter” won’t get you off the hook. The key factor, McKinney says, is whether the breached data is protected by the law.

That means it’s time to contact your digital forensics firm. McKinney says the difference between accessible and accessed information can determine whether a notification is required in some states. Bad actors may not even realize the treasure trove they’ve found, so they can leave protected data untouched. It’s like a burglar who walks right past a folder full of classified information laying on someone’s desk. A digital forensics team can track the hackers’ steps and help a company determine exactly what was compromised and whether notification may be required.

That information will help you understand your notification requirements based largely on two factors: Was the compromised data encrypted and is the data protected by the law, such as PII (personally identifiable information)?

“Every state is so different, but a generalized theme is that if it’s encrypted, then you have some pretty good protections against having to do a notification in many states,” McKinney says.

Your legal obligations will also depend on whether hackers could link up two pieces of PII using what they stole. “We’re not going to require notification if the compromised information only reveals the type or color of a car,” McKinney says. “But we’re looking for whether bad actors can marry up two concepts, such as your name and date of birth. If you have that situation, and it’s unencrypted, you’re mostly likely going to be navigating the breach notification maze.”

What laws apply to my situation?

“We do a lot of ‘conflict of laws’ analysis” to untangle all the relevant jurisdictions, McKinney says. Key questions an attorney will guide a company through include:

  • In what state(s) is the data located?
  • In what state(s) are the affected customers located?
  • In what state did the “harm” occur?
  • Who owns or is responsible for the data?

It’s easy to see the thicket of statues in play in a situation like this one: A company headquartered in Illinois, has offices in five other states, and stores data on servers owned by a third party in Nevada. The business serves customers in 30 states. When a breach occurs, which state’s notification laws are in effect?

Specific contract details also affect which law is relevant and who might be responsible. “If I give you a hard drive, do you own it and hold all responsibility for the data stored on it?” McKinney asks. “Alternatively, if you just possess the hard drive temporarily, for service purposes, what responsibilities do you have? Importantly, your master services agreement or statement of work may address who owns the data and could very well play into which state law applies.”

What constitutes a notification?

By now, you know the answer depends on your state and the individual facts of each incident. Notification requirements have varying rules covering timing, messaging and whether a company must provide credit monitoring.

For regulated industries, one best practice McKinney recommends is to let any pertinent regulatory agencies know about a breach right away. “You don’t want your state insurance regulator or banking superintendent to learn through the newspaper that you had a breach,” he says.

What happens if I fail to provide the required notification?

McKinney points to several potential penalties:

  • Civil penalties – The state attorney general could bring an action and seek significant fines for failure to follow requirements.
  • Federal penalties – The Federal Trade Commission may take action against companies it concludes have made false or misleading statements related to security and privacy or those who violated trade practices and seek fines.
  • Private lawsuits – McKinney describes this potential scenario that could generate a suit: A company is breached and fails to notify customers as required by law, leading to customers having their identity stolen and eventually financial harm. A customer could bring a suit claiming that they would have changed their username and password if the company had notified them of the breach.

Clearly, the best responses to data breaches are put in place months before the breach occurs. By creating a solid incident response plan, taking steps such as segmenting access to your system and properly patching all your software, you can prepare for and possibly stop breaches altogether. To talk with one of our experts about starting your plan, contact us today.

Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.