Often, a data breach is caused by an internal actor within the company. Depending on the source, the percentage of data breaches caused by oversharing, malicious sharing, or accidental information sharing ranges from 20% – 40% of all breaches. In the grand scheme of things, that’s actually a fairly substantial number. So, what can an organization do to protect its information from its people? Especially if those same people are doing their job or don’t mean any harm. Enter Microsoft Purview’s Insider Risk Management. The purpose of the feature is exactly as it sounds. While other tools a cybersecurity team may have at their fingertips protect from external threats, Insider Risk Management (IRM) protects against security risks from within. This is the first post in a series of blogs I will write that digs deep into the capabilities and functionality of IRM and how to configure it to work within your organization. This post will provide an overview of Insider Risk Management and how it works to protect your data.
As always, please be aware of my blog disclaimer
For more information in this series on Insider Risk Management, please see the other posts I have written on this topic (the links will be active as the pages become active):
- An Overview of Insider Risk Management (this post)
- Configuring Your Tenant for Insider Risk Management
- Creating a Data Leak Policy
- Reviewing Alerts In Insider Risk Management
- Escalating an Alert in Insider Risk Management
Overview of Insider Risk Management
Traditionally, cybersecurity analysts would have to go through a myriad of logs from multiple sources to see if users are doing shady things. Often, the logs were hard to read and, at times, provided very little information beyond “David downloaded a file,” “David opened a file,” “David emailed a file,” and so on. Tools have been developed to assist the analysts in tracking information and making their lives a bit easier. IRM takes things a bit further, and instead of an analyst looking for the information, IRM does that for them and brings the information forward. What this means is that now analysts can devote their time more to reviewing the evidence and determining if there should be concerns, digging deeper into situations, and grouping the information for others to act upon than actually searching through all of the information just to find something that seems out of place. The following screenshot provides an idea of the kind of information IRM can provide on user activities:
Takes the Intent Out of the Result
Often, when reviewing for risky activities, an analyst tries to determine the user’s intent. “Are they really trying to exfiltrate data?” “Is the data sensitive?” “What is this user doing?” are all questions an analyst is trying to determine when digging through logs and results. The problem there is that it isn’t about intent; it’s about results. Whether Bob is emailing sensitive information to a recipient with malicious intent or copying a hundred files from a SharePoint library to a USB drive to use later on another company PC doesn’t really matter. What matters is the acts that Bob is taking are risky to the organization. His actions put the business and possibly the users at risk. IRM removes the intent from the equation. IRM looks at the various activities a user is doing and determines if more investigation may be warranted based on the configurations the administrators have placed on the system.
Sequential Activities for the Win
One key component that elevates IRM above standard methods of risky behavior detection is its ability to track sequential activities as a single activity to alert administrators as necessary. Think of it this way: you can see that David downloaded Doc1.docx from a SharePoint site. You might even know that this has been deemed sensitive, but what won’t show up without a lot of extra digging is that after downloading the document, David then removed the sensitivity label (or lowered it), renamed it, copied it from his desktop to a USB drive, and then came back and deleted the original document. Sure, all of this is tracked in the logs, but what if David did it over days instead of right away? That could potentially take some time to track down. IRM watches all of that for you and it places sequential activities like this as a higher severity because while any one of the actions is risky, all of them together make the actions extremely risky and potentially malicious in nature.
Integration with HR Systems
One last item I wanted to cover is that IRM can and does integrate with third-party HR systems like PeopleSoft, Workday, SuccessFactors, etc. This is extremely important because those systems often flag termination before security personnel are notified. Additionally, when someone knows they are leaving the company it isn’t uncommon that they take information with them. Often the thought is: “I created that, so I want to take it with me”, or “This could really give me a head start at the new job”, or even “This insider information would really help my new company and put me on the right foot with management” and so they’ll take it without considering that the information truly does not belong to them, or it contains information sensitive to the company they are leaving. When IRM knows that users are planning to leave the org, it actually puts higher scrutiny on that user. In other words, it boosts the scores for their activities higher than it normally would to flag them when maybe it wouldn’t be considered out of place. Even better, once “flagged” by the system, it isn’t looking at their actions for the next few weeks; it is also looking back 90 days because the user leaving may have started risky activities before they announced they were leaving.
There is a caveat to this, however. Microsoft calls this process integration with the HR Connector. It sounds like a direct connection to whichever third-party tool the organization uses. It’s not. Basically, the HR Connector is a method for the organization to upload a CSV file into Purview to notify IRM. Now I believe Microsoft did this for a reason. It was the only way they could easily make the HR Connector integrate with nearly any system without a ton of custom development on their part or the organization’s part. Really, all you need to do is generate a method by which you can perform daily (or more often as necessary) exports of a termination list to then be uploaded into Purview. In a future blog post, I will cover this process and how to build it out.
I’ll dig more into the particulars of IRM in future posts, but for now, I hope this helps you understand the importance of the application as part of your own data protection strategy
Thanks for reading!
Leave a Reply