As a follow-up to my last blog post on “Configuring the Azure Rights Management Connector with a Windows FCI File Server,” RMS can log every request that it makes for your organization, which includes requests from users, actions performed by RMS administrators in your organization, and actions performed by Microsoft operators to support your RMS deployment.
There are three limitations with User Activity Logging. The first is that the log files does not include the document name that is being accessed. For example, RMS will log that an unauthorized user attempted to access a document with a content-id of {GUID} but unless you have access to the document with that {GUID} then you cannot correlate the content-ID to the document name. This presents a catch-22, how do you know which document to extract the content-ID from to begin with? (For a complete list of the log file contents, see Logging and Analyzing Azure Rights Management Usage on Technet).
I have to give the RMS team at Microsoft credit, because they are extremely responsive and interested in feedback. You can tell they really love this product and the success of the product means a great deal to them. They may soon release a powershell script that allows you to extract the content-id from each document, and then you could manually insert that into a SQL database that would contain a mapping of content-ID’s to document names. Keeping this SQL database updated would require a custom application to be written.
I am assuming that the content-id script will be posted to the RMS blog, Connect.Microsoft.com or the RMS Yammer group when it is made available, since that is the location of the last announcement of Azure RMS powershell scripts:
http://blogs.technet.com/b/rms/archive/2014/04/11/microsoft-protection-powershell-cmdlets-ctp2.aspx
It would be much easier if the RMS user activity log contained a direct reference to the full document path (not just the file name). Because a file name in itself is unique only within the directory it resides in, for example:
F:\Share\Bank1\Purchase Order.docx
F:\Share\Bank2\Purchase Order.docx
As you can see, only having ‘Purchase Order.docx’ added to the log is not sufficient during a forensic analysis. Technically you could extract content-id from all documents named Purchase Order and then compare that to the log, but again, that is not efficient.
So my hope is that when Microsoft adds detail to the log file, that they consider adding the full path and not just the file name. It would be even better if the path included the server name too, because otherwise you might have two servers in your organization like this:
Server 1 > F:\Share\Bank1\Purchase Order.docx
The contents of Server 1 are replicated via DFS to an off-site DR server named Server 2:
Server 2 > F:\Share\Bank1\Purchase Order.docx
So in this scenario, having DFS log the path without the server name would not tell you which server was trying to be attacked.
A second limitation to configuring a Windows FCI File Server with RMS is that it will only protect Microsoft Office file types. Although Azure RMS does have the ability with the RMS Sharing App to create “pfiles” – this functionality is not built into the Windows FCI File Server API, and there is no command-line version of the RMS Sharing App. So if you needed to automate the enforcement of all files on a file share, (including having RMS protect both Microsoft and Non-Microsoft file types), you could use the recently announced Microsoft protection powershell scripts (currently in Community Preview on Connect.microsoft.com) to create pfiles against non-Microsoft file types. You could also write your own .NET app using the Azure RMS SDK 2.1 with the File API). Writing a script to traverse a file structure to perform this and have it run as a scheduled task would take a decent amount of development effort. Hopefully the script could be written to apply the same Azure RMS Template that the FCI file server is using for consistency.
A third limitation has to do with automating the log file parsing. For example, if your organizational security policy requires that you are notified when an unauthorized access attempt occurs, then you would need to write a program to access the logs directly on Azure storage. There are currently two vendors who are writing software to provide this level of logging and you can contact me at Joe dot Stocker at CatapultSystems.com and I can introduce you. Otherwise the only out of box option now is to use a powershell cmd-let to download the log files and then manually open each log file to inspect them for unauthorized access.
In Summary, the User Activity Logging that is available right now is sufficient for organizations that need to satisfy an audit requirements that unauthorized access attempts are logged somewhere. But outside of that narrow requirement, in practical terms, you would need to hire a company like Catapult Systems to write some custom code to alert you when unauthorized access takes place.
I would recommend that you ask the software developer to define the notification boundaries. For example, how do you define unauthorized access? Is it every time someone attempts to open a document that they do not have rights to access? Do you really care to be notified for failed attempts? Wouldn’t that fill up your inbox, and then you would start ignoring those emails? Or would you prefer to only be notify when an unsuccessful access attempt is followed by a successful access attempt (as this would indicate that a brute force attack was successful). Or perhaps you only care if greater than 10 access attempts occur rather than each individual one. As you can see, you will need to factor in some intelligence into whatever notification script you write yourself. My hope is that the commercial market will produce solutions that apply best of breed approaches to log forensics and notifications.
It would be awesome if Microsoft will add a report into Azure AD Premium for RMS logging analysis. Similar reports already exist, so theoretically it would not be too difficult for Microsoft to extend those rules into analyzing the RMS logs.
For example, here are the security reports included in the Azure AD base (free) followed by a comparison of what is available in AD Premium. The base offering has reports for:
- Sign ins from unknown sources
- Sign ins after multiple failures
- Sign ins from multiple geographies
The Premium offering adds reports for:
- Sign ins from IP address with suspicious activity
- Irregular sign in activity
- Users with anomalous sign in activity
- Which users are most actively using an application
- What devices a user has signed in from
Premium also offers email notification of anomalous behavior to Azure AD administrators. So what we (customers and partners) want is similar notifications for RMS activity logging for when documents are accessed using the same rules above. That should satisfy most audit requirements.
References
Logging and Analyzing Azure Rights Management Usage on Technet
The Cloud Technologist 