LinkedIn
Twitter
Recently, I received a question about how Entra ID (formerly Azure Active Directory) and Office 365 can be integrated into the Google Security Operations (SecOps) platform. This isn’t the first time this has been raised and while we do have documentation for this, there are some details that I’ve found folks seeking, including the configuration on the Entra ID side. Based on that, I’ve broken this topic into bite size pieces:
- This blog will introduce feed management and discuss Entra ID application creation along with gathering key values
- The second blog focuses on API permissions needed to access O365 and Entra ID logs
- Finally, we apply this information to Google SecOps Feed Management, troubleshoot and review the data ingested
Let’s start breaking down how we integrate Entra ID, Office 365 and Google SecOps.
Entra ID is a cloud-based identity and access management service that can be used to access resources, such as Office 365. If you sign up for Office 365, you have an Entra ID tenant. The licensing of your service will drive your ability to ingest data. Having an Office 365 E5 and its accompanying Microsoft Entra ID P2 license is supported and is what this blog is based upon. I was able to get my hands on a Microsoft 365 Business Standard license coupled with an Entra ID Free license and started receiving Exchange audit events, but not the Entra ID audit or sign-in logs.
Like any SaaS offering, there is a default set of logs available with these solutions. While we can quibble if there is enough logging in them, that is a topic for another day. In fact, I wrote a blog a few months back about Google SecOps being able to ingest Microsoft Graph Activity logs to mitigate this gap, so check that out if you are interested.
Before we can build content using Entra ID and Office 365 logs, we need to be able to ingest them. To do that, Google SecOps uses the Feed Management capability to ingest this data. Feed management can be found under Settings -> SIEM Settings and then selecting Feeds.
Feeds can originate from 3rd party APIs, like Entra ID and Office 365, but can also work with AWS Data Firehose, S3 buckets and SQS, GCP Pub/Sub and Cloud Storage, Azure Blob Storage and HTTP files and webhooks, though that is beyond our scope today.
3rd party API feeds are associated with a log type. In the case of Entra ID, this is pretty straightforward but in the case of Office 365, there are multiple content types so it’s important to provide a descriptive feed name, as you can see above, to describe the type of data coming in from a specific feed. More on this in a subsequent blog.
To collect all of the available Entra ID and Office 365 events, we need to set up multiple feeds. The process to set these feeds up is nearly identical, but before we do that, there are some actions that need to be taken in the Microsoft tenant. The key values that we will need for these fields are the tenant ID, the application (client) ID and a secret value.
The simplest of these three items is the tenant ID. This is a GUID that represents your tenant and can be found on the Overview page of the Entra ID Admin Center. There are other places to find this and Entra ID can be accessed via the Azure portal as well, but for consistency's sake, I am going to base everything on using the Entra ID Admin Center as our starting point.
Once we have our tenant ID, we need an application (also called a client) ID. These terms are often used interchangeably, including in the Overview section of the application itself. The need for an application creates a decision point for us. Chances are if you are integrating your tenant with other tools, you may already have applications defined within Entra ID already. These applications are designed to provide access to the API permissions that are part of Azure, so the existence of one or many applications in an organization is not uncommon.
The challenge is to keep track of what each application in your tenant is supposed to interface with and its associated secrets, permissions and roles are maintained. Because applications are gateways to the underlying APIs and their associated data, it is critical to understand which applications have access to what data within Azure.
We are going to create a new application that will serve as our integration point into Google SecOps. We can quickly and easily create our application just by clicking Add -> App Registration from within our tenant and specify a name for our app, in this case GoogleSecOps Integration, and click Register.
With our application created, we can now see that we have in our application, the Application (client) ID and our Directory (tenant) ID. That’s two of the three pieces of data needed to set up our feed.
The third piece of data that we need is a client secret. This is a value that must be secured as it provides access to the application and the associated API permissions. We can navigate to the Certificates & secrets page in our application and select New client secret. After providing a description, we can set a time to live on the client secret. It’s important to note that when the client secret expires, a new one will need to be generated and the new client secret will need to be added to the existing feeds, otherwise data will stop flowing from those sources! Once you’ve set your retention, click Add.
Once we create our secret, we have one opportunity to save this value. If you don’t save it at creation and come back to the client secret page, the value will not be available and a new secret will need to be created, so make sure you capture this value!
With that, we have the three key values that are needed to create our feed. However, this doesn’t mean we are done in the Microsoft tenant yet. We still need to define permissions to the underlying APIs to gain access to the data through our application.
We’ll call this a cliffhanger and wrap up our first blog in this mini-series here.
Next time we will discuss the permissions needed to gain access to the data sets needed for Entra ID and Office 365.