Migrations to Microsoft’s Digital Workplace platform, Office 365, are well advanced, if not already completed. It is now time to improve processes, but above all, to secure them.
Several topics must be addressed when securing Office 365 including the need to be able to track actions to detect illicit behaviour or trace the cause of an incident.
In France, however, many companies have difficulty consolidating logs and defining supervision use cases. Mastering logging must be at the heart of this approach.
Supervision of administrative actions is a necessity
For this logging decryption, let’s take the case of the platform administrators.
As with other SaaS solutions (Google Cloud Platform, Salesforce, etc.), the breach of data integrity or confidentiality following an error or malicious action by a company administrator is one of the major risks identified by our customers.
By definition, Office 365 administrators have high privileges:
- Configuration of the various services – or workloads – and APIs;
- Managing permissions on OneDrive and user mailboxes;
- Management of the life cycle of collaboration spaces.
It is easy to imagine the disastrous consequences that could result from the malicious or uncontrolled use of these privileges. Indeed, settings such as SharePoint Online external sharing, API permissions or email configuration could become significant data leakage vectors.
On-premise IT best-practices (lifecycle, least privilege principle, rights segmentation, strong authentication, just-in-time access, etc.) must also be applied in the Cloud. The Cloud must be mastered and controlled.
However, the implementation of good practices, although necessary, is not enough. Indeed, they do not guarantee that administrators won’t carry out actions that compromise the level of security. One can therefore naturally wonder how it would be possible to audit the actions carried out and raise alerts if necessary.
What are the means provided by Microsoft? How can we prevent a malicious person from covering his tracks (which would make an attack more difficult to detect and reconstruct)?
To illustrate the different possibilities, we will follow the four examples below:
Figure 1 – Examples of configuration changes that may affect safety
What logs are available?
For historical and technical reasons, Office 365 inherently has several log sources: Unified Audit Logs, Exchange Logs and Azure Logs. These sources are complementary and must be analysed together in order to have an exhaustive view of the administrative actions performed.
Unified Audit Logs: unified logging of the different services
The most commonly cited and used source of logs is the “Unified Audit Logs”. These logs centralise the traces of users and administrators for all the platform’s services: SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft is progressively integrating the different sources and continues to add new logs.
To come back to our concrete examples, the interesting logs are:
- SharePoint Online External Sharing Policy Change: SharingPolicyChanged
- Assigning rights to a One Drive: SiteCollectionAdminAdded
- Assigning rights to a mailbox: AddMailboxPermission
- Changing an Administration Role: AddMembertoRole
These logs are accessible and exportable via the Compliance and Security Centers, the Office 365 Management and PowerShell APIs (via the Search-UnifiedAuditLog cmdlet). Note that logging must be enabled via the Compliance Center or PowerShell to be able to log and search.
It is possible to directly configure alerts related to the occurrence of certain logs in the Security and Compliance Centers.
Exchange Logs: logging of the messaging infrastructure
The second interesting source of logs is the “Exchange Logs“. These logs provide information about usage and administrative actions performed on the Exchange Online service as well as on personal or shared mailboxes. Two types of logs can be distinguished:
- Administrator Audit Logs: Service or mailbox administration logs (e.g. changing a user’s permissions, changing the retention time of a mailbox log etc.).
- Mailbox Audit Logs: Logs of use of a mailbox by the main user, a delegated user or a service administrator (e.g.: accessing the mailbox, sending an email in place of the main user, moving an item into a folder, permanent deletion, etc.).
To come back to our concrete examples, the logs that will interest us here are:
- Assigning rights to a mailbox: AddMailboxPermission
- Access to a folder or a mailbox: FolderBind (not enabled by default):
- Access to a mail: MailItemAccessed (only for users with an E5 license)
To go further with Administrator Audit Logs
Administrator Audit Logs are generated for any Exchange administration action that can be linked to a PowerShell cmdlet other than Get, Search or Test. These logs are linked to the Unified Logs and can be used in the Exchange Administration Center, Security and Compliance Centers, Office 365 Management and PowerShell APIs.
To go further with Mailbox Audit Logs
Mailbox Audit Logs are the only category of logs to be configurable (perimeter and granularity). These logs allow tracing of the actions performed by an owner, a delegate (user with permissions) and an admin (access via eDiscovery tools).
Since January 2019, the logging of Mailbox Audit Logs is enabled by default for all Office 365 tenants. To date, if logging is enabled by default, all mailboxes are audited (even if the “-AuditDisabled” parameter is set to “True”). The only way not to log the actions of a mailbox is to implement a by-pass rule with “Set-MailboxAuditBypassAssociation”.
However, it should be noted that some actions are not audited by default, such as the access of a delegate or an admin to a user’s mailbox. It is therefore essential to analyse the logs to be activated, during the initial configuration of the service.
Depending on the license level and configuration, these logs can be linked to the Unified Logs and be used in the Exchange Administration Center, the Office 365 Management and PowerShell APIs or the Security and Compliance Centers.
Azure Logs and Reports: Azure Active Directory Logging
The last, but not least important source of logs are the “Azure AD logs”. These logs provide complete traces of the Office 365 identity brick and the associated administration actions. Several categories of logs and reports are available:
- Azure Audit Logs: Logs for the administration of the identification brick or modification of items (e.g. assigning the “SharePoint Administrator” role, creating a security user or group, authorising an API, configuring guest users, etc.).
- Azure Sign-in Logs: Logs for connecting to an Office 365 service (or to applications / APIs based on Azure AD) with information regarding the connection chain (e.g. protocol, IP address, terminal, etc.).
- Risky Sign-in: Connection reports with indicators related to suspicious connections.
These logs and reports are accessible and exportable via the Azure portal, the Graph or Azure Management and PowerShell APIs. Some of the logs directly related to Office 365 are also found in the Unified Audit Logs.
To come back to our concrete examples, the interesting logs are:
- Modification of an administration role: AddMembertoRole
Figure 2 – Summary of Office 365 Logs Features
In summary, the Unified Audit Logs provide a consolidated view of the different services of Office 365, but some information may be missing. It will be necessary to ensure that the required logs are present, and then to investigate further into the logs and reports of Exchange or Azure.
What is the retention period for the various Office 365 logs?
Once the proper logs have been identified, the challenge of retention arises. How can you be sure that the logs are well preserved without being altered, for as long as is required by the company’s security policy and various regulations, such as the anti-terrorist law or the GDPR?
By construction, and contrary to Exchange and SharePoint on-premise solutions, all the logs mentioned above are unalterable – that is to say, they cannot be modified or deleted by the company administrators. Furthermore, the default retention periods defined by default cannot be modified (i.e. 90 days for Office 365 and 7 logs or 30 days for Azure logs with standard licenses). With one exception, an Exchange administrator has the ability to delete the logs from mailboxes by changing the associated retention time.
If we go back to our examples, we could imagine a malicious administrator giving himself rights to access a mailbox, then look at the mails and erase the access logs by setting a zero-retention time. In this case, only the privilege elevation made in the Administrator Audit Logs would be retained.
In order to comply with security or regulatory requirements, it may also be necessary to ensure that the logs of the various departments are kept for more than 7, 30 or 90 days.
3 steps to implement relevant logging within Office 365
- Definition and activation of the necessary logs: Unified Audit Logs may not be sufficient (monitoring of the Office 365 and Azure AD APIs, logging of administrator access to mailboxes, etc.);
- Configuration of an automatic export of the identified logs to an external storage or an independent SIEM (via PowerShell or the API Management);
- Monitoring the status of the tenant: implementing a dashboard of the tenant’s settings configuring alerts related to a change in log configuration (via the Security or Compliance Center, the Office 365 Management or PowerShell APIs), such as disabling Unified logs or a change in the retention of mailbox logs.
Figure 3 – Good Practices for Office 365 Logging
After carrying out these three actions, the company will have the necessary information to audit the tenant’s use and administration actions. However, this does not yet address the larger need for supervision of administrators. It may be useful to set up alerts (via the Security or Compliance Center or specialised third-party tools).
- (To go further) Implementation of basic supervision: definition of general security detection scenarios, identification of the logs concerned, activation of the associated alert in the Security or Compliance Centers;
- (To go even further) Setting up advanced supervision: identification of scenarios related to a business context, implementation, definition of the associated governance, continuous improvement.
What tools should be used to analyze the logs? Which detection scenarios should be prioritised? What governance should be put in place to define, implement and monitor alerts? These are all questions that need to be addressed in the implementation of the collaboration platform supervision.
It will also be necessary to take into account the regular changes made by Microsoft on these services, as well as on the structure of logs and APIs, especially since the preview and general availability functionalities coexist.
