In the previous two installments of this series, we demonstrated how you can create a custom solution for end users and administrators to track AIP protected documents. In this final installment, we will walk you through a sample application that can be used to notify security professionals and/or end users when an access denied event is received for an AIP protected file. As you may recall, the classic Track and Revoke portal for AIP was able to notify a document owner when someone opened or tried to access a protected document. It is also good to remember that a user needed to register each protected document in order to enable these notifications.
As we previously mentioned, we now have RMS activity logs integrated with the Azure Information Protection labeling activity. With this integration, you could generate access denied alerts that can be sent to an end user (aka document owner) or your system of choice (SIEM, etc.).
In today’s post, we will show you how to:
Staying true to form, we continue to rely on serverless computing to host this application. The following steps describes the steps necessary to create an Azure Function application that monitors the AIP logs in Log Analytics for “AccessDenied” events.
The requirements for this sample solution are like the prior blog which you can view here.
NOTE: This sample application uses code to send an email to the document owner via the Microsoft Graph. However, you can pick up these alerts directly from the Microsoft Security Graph as discussed by my colleague Preeti on her blog. You have several options to connect to the Graph Security API including but not limited to Logic Apps, Power Automate (fka Flow) and PowerApps.
Like the previous two blogs, we are using an Azure Function, but this instance has a timer based triggered so that we can query Log Analytics once a day. You can of course configure your application to query as often as required within the allowed limits.
For more details on how to setup some of the requirements, please refer to our first blog post in the series.
Once we have authenticated the application to Azure AD, we start by performing a query in Log Analytics for all events where the activity equals “AccessDenied”.
Here is a view of the Kusto query:
This is the code that leverages the query and formats the return values into a JSON string.
We then create an email message making sure that we DO NOT share the location of the person who tried to open the document with the document owner.
The document owner will receive an email like the one below. You can of course create much better-looking templates for your emails that reflect your branding choices.
At that point, the document owner can either try to contact the person they shared the document with or refer the matter to their security team if they do not recognize the email address in the alert.
So far, we have obtained the list of access denied events from Log Analytics for the past 24 hours and have sent email notification to each document owner. Although we did not share the location (IP Address in this case) of the person who tried to open the protected document, this information may be helpful to the security team in your organization. Keeping that in mind, we have the option to send an alert to Azure Sentinel via the Graph Security API as you will see below.
For this part, we borrowed the code from our colleague Chi Nguyen’s QuickStarts samples. Please refer to the Csharp project for details on the requirements.
The code below takes all properties from the AIP activity and builds a list that is then passed on to a new Threat Indicator (TI). The new TI is then sent to Azure Sentinel via the Graph Security API.
Here is the TI Controller:
Let us look at the alert in Azure Sentinel. Navigate to your Azure Sentinel | Logs | SecurityInsights | ThreatIntelligenceIndicator and enter “ThreatIntelligenceIndicator” in the query box.
You should see a list of TIs from your application as shown below:
Expanding one of the alerts should look like this:
Here is the rest of the alert. For convenience, I put the source IP address on the NetworkIP address field of the TI.
And here are all the AIP Log properties stashed neatly away within the Tags property of the TI:
As you can see above, our custom TI has all the information retrieved from the Log Analytics query and I can now use it in combination with other types of alerts or information. You can of course send these types of alerts to Microsoft Defender ATP by changing the TargetProduct in the TI code shown prior.
That concludes this 3-part series on how you can build custom solutions to interact with AIP labeling and access data for users and administrators. We hope you found these concepts and samples useful and as always, keep your feedback coming and don’t forget to share any solutions you may come up with.
You can find the sample code for this solution in this GitHub repo.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.