Skip to main content

Analysis Report (AR19-133A) Microsoft Office 365 Security Observations

Summary

As the number of organizations migrating email services to Microsoft Office 365 (O365) and other cloud services increases, the use of third-party companies that move organizations to the cloud is also increasing. Organizations and their third-party partners need to be aware of the risks involved in transitioning to O365 and other cloud services.
This Analysis Report provides information on these risks as well as on cloud services configuration vulnerabilities; this report also includes recommendations for mitigating these risks and vulnerabilities.

Description

Since October 2018, the Cybersecurity and Infrastructure Security Agency (CISA) has conducted several engagements with customers who have used third-party partners to migrate their email services to O365.
The organizations that used a third party have had a mix of configurations that lowered their overall security posture (e.g., mailbox auditing disabled, unified audit log disabled, multi-factor authentication disabled on admin accounts). In addition, the majority of these organizations did not have a dedicated IT security team to focus on their security in the cloud. These security oversights have led to user and mailbox compromises and vulnerabilities.
Technical Details
The following list contains examples of configuration vulnerabilities:
  • Multi-factor authentication for administrator accounts not enabled by default: Azure Active Directory (AD) Global Administrators in an O365 environment have the highest level of administrator privileges at the tenant level. This is equivalent to the Domain Administrator in an on-premises AD environment. The Azure AD Global Administrator accounts are the first accounts created so that administrators can begin configuring their tenant and eventually migrate their users. Multi-factor authentication (MFA) is not enabled by default for these accounts.[1] There is a default Conditional Access policy available to customers, but the Global Administrator must explicitly enable this policy in order to enable MFA for these accounts. These accounts are exposed to internet access because they are based in the cloud. If not immediately secured, these cloud-based accounts could allow an attacker to maintain persistence as a customer migrates users to O365.
  • Mailbox auditing disabled: O365 mailbox auditing logs actions that mailbox owners, delegates, and administrators perform. Microsoft did not enable auditing by default in O365 prior to January 2019. Customers who procured their O365 environment before 2019 had to explicitly enable mailbox auditing.[2] Additionally, the O365 environment does not currently enable the unified audit log by default. The unified audit log contains events from Exchange Online, SharePoint Online, OneDrive, Azure AD, Microsoft Teams, PowerBI, and other O365 services.[3] An administrator must enable the unified audit log in the Security and Compliance Center before queries can be run.
  • Password sync enabled: Azure AD Connect integrates on-premises environments with Azure AD when customers migrate to O365.[4] This technology provides the capability to create Azure AD identities from on-premises AD identities or to match previously created Azure AD identities with on-premises AD identities. The on-premises identities become the authoritative identities in the cloud. In order to match identities, the AD identity needs to match certain attributes. If matched, the Azure AD identity is flagged as on-premises managed. Therefore, it is possible to create an AD identity that matches an administrator in Azure AD and create an account on-premises with the same username. One of the authentication options for Azure AD is “Password Sync.” If this option is enabled, the password from on-premises overwrites the password in Azure AD. In this particular situation, if the on-premises AD identity is compromised, then an attacker could move laterally to the cloud when the sync occurs. Note: Microsoft has disabled the capability to match certain administrator accounts as of October 2018. However, organizations may have performed administrator account matching prior to Microsoft disabling this function, thereby synching identities that may be have been compromised prior to migration. Additionally, regular user accounts are not protected by this capability being disabled.
  • Authentication unsupported by legacy protocols: Azure AD is the authentication method that O365 uses to authenticate with Exchange Online, which provides email services. There are a number of protocols associated with Exchange Online authentication that do not support modern authentication methods with MFA features. These protocols include Post Office Protocol (POP3), Internet Message Access Protocol (IMAP), and Simple Mail Transport Protocol (SMTP). Legacy protocols are used with older email clients, which do not support modern authentication. Legacy protocols can be disabled at the tenant level or at the user level. However, should an organization require older email clients as a business necessity, these protocols will not be disabled. This leaves email accounts exposed to the internet with only the username and password as the primary authentication method. One approach mitigate this issue is to inventory users who still require the use of a legacy email client and legacy email protocols. Using Azure AD Conditional Access policies can help reduce the number of users who have the ability to use legacy protocol authentication methods. Taking this step will greatly reduce the attack surface for organizations.[5]  

Solution


CISA encourages organizations to implement an organizational cloud strategy to protect their infrastructure assets through defending against attacks related to their O365 transition, and securing their O365 service.[6] Specifically, CISA recommends that administrators implement the following mitigations and best practices:
  • Use multi-factor authentication. This is the best mitigation technique to use to protect against credential theft for O365 users.
  • Enable unified audit logging in the Security and Compliance Center.
  • Enable mailbox auditing for each user.
  • Ensure Azure AD password sync is planned for and configured correctly, prior to migrating users.
  • Disable legacy email protocols, if not required, or limit their use to specific users.

Comments

Post a Comment

Popular posts from this blog

Site-to-site IPsec VPN with two FortiGates

In this example, you will allow transparent communication between two networks that are located behind different FortiGates at different offices using route-based IPsec VPN. The VPN will be created on both FortiGates by using the VPN Wizard's   Site to Site - FortiGate   template. In this example, one office will be referred to as HQ and the other will be referred to as Branch. 1. Configuring the HQ IPsec VPN On the HQ FortiGate, go to  VPN > IPsec Wizard . Select the  Site to Site  template, and select  FortiGate . In the  Authentication  step, set  IP Address  to the IP of the Branch FortiGate (in the example,  172.20.120.135 ). After you enter the gateway, an available interface will be assigned as the  Outgoing Interface . If you wish to use a different interface, select it from the drop-down menu. Set a secure  Pre-shared Key . In the  Policy & Routing  step, set the  Loca...
Post a Comment
Read more

Be fraud aware - What are phishing, smishing and vishing.

  You may have heard the terms phishing, smishing or vishing before, but what exactly do they mean? At their core, all three terms are a type of financial fraud which tricks unsuspecting victims into giving out sensitive personal information, handing over money or installing malware onto their device. The only difference between each term is the channel via which you can be targeted; phishing refers to scam emails, smishing refers to scam text or WhatsApp messages and vishing takes place over the phone. Phishing The most common phishing method encourages victims to visit a malicious website through a fake email message, which appears to be sent from a legitimate company or source (e.g. from a bank, HMRC, a delivery company or the NHS). For example, you might receive an email which appears to be from an organisation who you’re familiar with, asking you to click on a link. At this point you will be taken to a webpage on which you’re asked to submit sensitive data, such as passwords, ...
Post a Comment
Read more

Cisco Releases Security Updates for Cisco ASA 5506-X, 5508-X, 5516-X and Firepower// Cisco Bug IDs: CSCvp36425

A vulnerability in the cryptographic driver for Cisco Adaptive Security Appliance Software (ASA) and Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the device to reboot unexpectedly. The vulnerability is due to incomplete input validation of a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) ingress packet header. An attacker could exploit this vulnerability by sending a crafted TLS/SSL packet to an interface on the targeted device. An exploit could allow the attacker to cause the device to reload, which will result in a denial of service (DoS) condition. Note:  Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed and transparent firewall mode and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. A valid SSL or TLS session is required to exploit this vulnerability. Cisco has...
Post a Comment
Read more