Table of Contents
New SITs Focus on Credentials
Now available in tenants, message center notification MC402123 (July 19, Microsoft 365 roadmap item 88941) covers the preview of 42 new sensitive information types (SITs) designed to protect different kinds of credentials (keys, passwords, and tokens) used in IT environments, including Azure, Amazon, GitHub, Slack, and Google. Most of the new SITs are of the Credential type, and there’s one called All Credential Types that’s a bundle of all the other new credential SITs.
Microsoft has steadily been increasing the set of available SITs. In April 2021, they released a bunch of country-specific SITs, while earlier this year, they introduced the concept of a bundled entity, or a set of SITs that can be processed as a single item (hence the bundled credential entity). The new set brings the total of Microsoft-created SITs to 306.
Sensitive information types are used with data loss prevention (DLP) policies and auto-labeling policies (with the right licenses). Each SIT contains patterns and definitions to detect a specific kind of data. In this case, the new SITs focus on things like usernames and passwords, Azure AD access tokens, storage account keys, and SQL server connection strings. Using the new SITs should allow organizations to clamp down on people circulating credentials in emails and Teams messages, which is a form of data leakage that you really don’t want to happen.
Checking Out Credentials Sensitive Information Types
I cover how to create a custom sensitive information type for Azure AD passwords in this article and experienced some issues using the custom SIT in production, so I was eager to discover what Microsoft delivered in their Azure AD User Credentials SIT.
One of the ways of discovering how an SIT works is to use the Test feature built into the Purview compliance portal. Open the portal, go to Data classification, and select the SIT you’re interested in. When SITs become generally available, Microsoft usually allows you to see details of the patterns used for a SIT. For now, you can’t, but you can test an SIT by uploading a text file containing test data to see whether Purview can detect any issues with the data using the SIT.
I couldn’t get a test to work for the Azure AD User Credentials SIT, even using the guidance in the SIT documentation. To make sure that I was doing the right thing, I tried with an Azure AD access token, and that worked (Figure 1), probably because tokens follow a clearly defined structure that’s relatively easy to define in a pattern.
I’m not sure that anyone would want to cut and paste an Azure AD access token into an email or Teams chat, but I’m glad that I can detect and block this information if necessary (Figure 2).
Testing the Azure AD User Credentials SIT in a DLP Policy
To test further, I configured a DLP policy to monitor for Azure AD user credentials in Teams chat. After waiting 15 minutes or so to let the policy become effective, I made multiple attempts to share username and password information through Teams chat. As Figure 3 shows, most attempts failed.
In fact, the only time the SIT detected a problem was when I used the Microsoft 365 service domain in a username. I don’t know many tenants that use service domains for user principal names (and email addresses), so this capability is sadly disappointing to say the least. I know that creating a pattern to detect different kinds of user credentials is difficult, but it’s hardly the cutting edge of software development.
All Fixed in General Availability
Oh well, the 42 new SITs are in preview, so we can expect that everything won’t work perfectly. The fact that SITs do not do exactly what you might expect underlines the need to test sensitive information types in realistic conditions using your data. If you don’t, you might end up sadly disappointed.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.