Custom reporting with Office 365 Audit log data could be implemented using Audit Logs fetched from the Security and Compliance center. In the previous blogs here, we have seen how to use PowerShell and Office 365 Management API to fetch the data. In this blog, we will look at planning, prerequisites and rationale to help decide between the approaches.

The Office 365 Audit logs could be fetched from the Security and Compliance center once enabled. Currently logging is not enabled by default and needs to be enabled from the Security and Compliance center. This could be turned on (if not done already) via the Start recording user and admin activity on the Audit log search page in the Security & Compliance Center. This is going to be automatically On by Microsoft in future. Once enabled, the Audit information across all Office 365 services are tracked.

The Audit log search in Security and Compliance center allows to search the audit logs but is limited in what is provided. Also it takes a long time to obtain the results.

In order to provide efficiency and performance, the data could be pulled from Office 365 Audit logs but needs custom hosting.

Planning and prerequisites:

Few considerations for custom processes are as follows:

  1. Need additional compute to process the data – since the audit log data is huge and queries take a longer time, it is recommended to do a periodic job to fetch the data from the Office 365 audit log using a custom process. This could be done using a PowerShell job or Azure Function App as detailed below.
  2.  Need additional hosting for storing Office 365 Audit log data – The records could range from 5000 to 20000 per hour depending on the data sources and relevant data size. Hence to make it easier to retrieve the data later, it is advisable to store the data in a custom database. Since the data cost could be significant for this, it is recommended to use either dedicated hosting or NOSQL hosting such as Azure Tables/CosmosDB (Azure) or SimpleDB / DynamoDB (AWS)
  3. Might need additional Service Account or Azure AD App – Since the data will be retrieved using an elevated process, it is recommended to run it with an Azure AD app or service account to gather the data. For more information about this, please refer to this blog here.

Scenarios:

Some of the scenarios when the Office 365 Audit log data could be useful.

  1. Creating custom reports for user activities and actions
  2. Storing audit log data for greater than 90 days
  3. Custom data reporting and alerts not supported in Security and Compliance center

Approaches:

Below are few approaches to pull the data from the Office 365 Audit Logs. Also have listed the benefits and limitations of the approaches in order to help decide on implementation.

Using PowerShell

Search-UnifiedAuditLog of Exchange Online PowerShell could be used to retrieve data from Office 365 Audit log. More implementation details could be found at the blog here.

Benefits:

  1. No additional compute hosting required. The PowerShell could be run on a local system with a service account or on a server.
  2. One off data-pull could be done and retrieved when needed
  3. Data more than 90 days could be retrieved from Office 365 Audit log
  4. No session time out constraints as long the PowerShell console can stay active
  5. Local date formats could be used to fetch data

Limitations:

  1. Need Tenant Admin rights when connecting to Exchange PowerShell so the cmdlets could be downloaded
  2. Needs connection to Exchange online PowerShell every time the data needs to be retrieved
  3. Couldn’t be run on cloud using Azure or AWS as connection with Exchange Online PowerShell cmdlet is not possible in serverless environment
  4. Could run for longer period that could range to hours of continuous run

Using Office 365 Management API :

The Office Management API provides another way to retrieve data from Azure Logs using a subscription service and Azure AD App. For more detailed information, please check the blog here.

Benefits:

  1. Support of any language such as C#, Javascript, Python etc.
  2. Parallel processing allows greater speed and flexibility of data management
  3. Controlled data pull depending on data size to increase efficiency and performance

Limitations:

  1. Additional compute hosting required such as serverless workloads or web jobs to process the data
  2. Need an Azure AD app or OAuth layer to connect to the subscription service
  3. Need additional Time zone processing since all dates are in GMT for retrieving data
  4. Session timeout might occur in data pull involving large datasets. So advisable to use smaller time slot windows for data pull
  5. Multilevel data pull required to fetch the audit log. Please check the blog here to get more information

Final Thoughts

Both PowerShell and Office 365 Management Activity APIs are a great way to fetch Office 365 Audit log data in order to create custom reports. The above points could be used to decide on an approach to fetch the data efficiently and process it. For more details on the steps of the process, please check the blog here (PowerShell) and here (Office 365 Management API).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s