Data Retention and Destruction in Office 365

As organizations continue to invest heavily in cloud collaboration, the amount of information maintained in the form of documents, emails, or instant messages can balloon rapidly. Moving that data into a single space like Office 365 is a huge win in terms of discovery for admin and litigation teams, and usability for end users, but the incredible amount of space available to users means there’s a larger burden on administrators to ensure that data is both discoverable, and destroyed when it becomes older than the organization’s legal compliance period.

The first part of this is simple. You need to make sure that data retention is configured for your organization. Not only is this handy to meet your compliance requirements, it helps with overcoming the ‘oops’ moment for end users when they accidentally delete data, it enables you to take advantage of inactive mailboxes to save licenses, and it helps recover from malware in your tenancy by leveraging versioning in OneDrive and Teams.

To quickly enable retention, head to the security and compliance center and select ‘Retention’ from the Data Governance panel.


When you elect to create a new policy you’ll be prompted to name your policy and identify exactly what you’d like your policy to do. In this case, we’re electing to retain data for seven years and also delete it after that duration. Depending on your requirements you may opt to maintain the data indefinitely without deleting it, or have a pure data destruction policy which deletes all data after a certain period of time. Note that the advanced options allow you to target specific data types such as personally identifiable information and financial information based on global standards. Additionally you can create your own data tags or policies to enforce there as well if you have a special requirement.


Now that you’ve clarified how long you’d like to keep your data and if you’d like it purged after that period, you need to identify which data locations you’d like to apply that policy to. Note that you’ll need to create two retention policies, one for default locations like OneDrive, Exchange, and Sharepoint as well as a dedicated one for Teams chat and channel chat since Teams stores that data in an Azure chat service.


Now that we’ve ensured that we’ve got our bases covered in terms of data retention we’ll circle back soon to discuss eDiscovery practices, search and destroy of malicious content, as well as leveraging the Threat Explorer in the compliance center to make that process easier.


So it’s 2019, and we’ve got phishing well in hand. Right?

Let’s face it, phishing is not new and forms of social engineering have been around for as long as we’ve been trying to protect information on the internet. Anyone who’s responsible for protecting their organization’s users from unsolicited spam or social engineering can tell you that phishing is definitely still occurring on a regular basis. What many organizations today don’t realize, is that not only is phishing still occurring, it’s becoming more complex, occurrences are increasing at an alarming rate, and users’ behavior is not changing at the same pace.

People Click Links

I had a great opportunity to hear a couple of my peers speak recently and they referenced Verizon’s Data Breach Investigations Report (DBIR) from 2018 and pointed out a few alarming trends. Phishing_Industries

First, let’s start with the scary one; sanctioned phishing campaigns uncovered that a small subset of individuals click on literally every link they get in their inbox:

“Unfortunately, on average 4% of people in any given phishing campaign will click it”


Ok, so it’s only 4%. That’s not that bad, right? Well, consider a couple things; first, that individuals who have clicked on links in the past are far more likely to continue that trend, and that 4% of some of the largest organizations turns out to not be a trivial number at all. Walmart? 2.3M employees. JPMorgan? 256k employees. I wrote recently that a single compromised user gives an attacker a foothold in your organization and is often the start of most major data breaches.

So now that we know some individuals are susceptible, let’s take a look at the brighter side of that number; almost 80% of all users never click on a single link at all.

Reporting Incidents

It’s not a huge secret that today vendors rely heavily on samples being reported in order to improve detection rates. What is pretty interesting is that a vast majority of phishing campaigns go unreported, with only 17% being reported at all. This means that you have no idea how effective you are at blocking those messages inbound and that there are plenty of instances where potentially malicious content has been viewed inside your organization and you have no idea.


Bringing it All Together

Now that we’ve got a little transparency into some raw numbers, let’s spend a minute on a more positive note and outline some great features available to help combat the knowledge gap in end users and the drastic increase in inbound phish attempts.

Microsoft’s Security Intelligence Report outlines the increase in phishing messages their service identifies. They handle over 470 billion messages per month and saw a 250% increase over the span of 2018.


As phishing campaigns become more and more complex, so has the way service providers protect their end users from 0 day threats. Microsoft leverages the sender side signals of those 470 billion messages to develop a user first contact graph to leverage machine learning for impersonation protection. On top of that, ATP adds SafeLinks and Safe Attachment protection for Office. The technology proxies every single end user click through a Microsoft server to validate the target URL before directing the user there.  The cool thing about that statement? SafeLinks works in Office, including Office Mobile for your remote users. URLs embedded in attachments are equally protected.

Microsoft certainly isn’t the only provider who’s making great strides on the email front; vendors like ProofPoint, FireEye, Palo Alto, Menlo, etc. have all innovated in their own right as well. The thing that sets Microsoft apart is that they handle exponentially more mail than all other vendors and leverage machine learning and artificial intelligence to make use of that data to exponentially improve protection for their users.

Keep up the Good Fight

Unfortunately the world isn’t going to become a peaceful place overnight and people aren’t going to suddenly become benevolent to their neighbors. While I’ll keep waiting for that day to come and doing my part to see it to fruition, I’ll also work just as hard to stay on top of emerging trends to make the internet a safer place for everyone to learn, collaborate, and enjoy a bottomless sea of cat memes.

Big thanks to Cam and Daniel for sharing sources for data.



Implementing Group Based Licensing in Office 365

So here we are on election day and if you’re like me, you’re probably more than a little bit ready to think about something other than someone else’s political opinion. Well, here I am to help you out with a little diddy on licensing your users in Office 365.

Since managing licenses for thousands of individuals can become a struggle, most organizations will use some kind of automation. Something like the sample below can be scheduled to run and apply licenses with specific features based on a specific scenario. This works great if you don’t have any other options, but group based licensing doesn’t require any kind of on premises (or Azure) automation so if you’ve got licensing for it, definitely use it!

if($_.UserPrincipalName -like *”) { 

# Disabled Plans – Customize to meet the needs of AA 

 $DisabledPlans= @() 

 $disabledPlans +=“Stream_O365_E3” 

 $disabledPlans +=“TEAMS1” 

 $disabledPlans +=“DESKLESS” 

 $disabledPlans +=“FLOW_O365_P2” 

 $disabledPlans +=“POWERAPPS_O365_P2” 

 $disabledPlans +=“OFFICE_FORMS_PLAN_2” 


 $disabledPlans +=“YAMMER_EDU” 

 $disabledPlans +=“EXCHANGE_S_STANDARD” 

 $disabledPlans +=“MCOSTANDARD” 

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation US 

 $AccountSkuId “org:LicenseName” 

 $Option New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans $DisabledPlans 

 Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $Option -AddLicenses $AccountSkuId 


Elseif ($_.UserPrincipalName -like *”) { 

 #Disabling only EXO for another business unit 

 $DisabledPlans= @() 

 $DisabledPlans +=“EXCHANGE_S_STANDARD” 

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation US 

 $AccountSkuId “org:LicenseName” 

 $Option New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans $DisabledPlans 

 Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $Option -AddLicenses $AccountSkuId 



The struggle is that you’ll want to use a dynamic group to do it and it will require a filter to work. If you apply a dynamic group and the filter is wrong you might unlicense your users or overcommit, causing service disruption for those users. The first step is to determine which users will need which licenses. The easy ones that need to be considered are any users with mail hosted in Exchange Online that require licensing (everything but resource, shared, or discovery mailboxes). Those mailboxes will need to be included in the dynamic group we’ll create next, so let’s filter out everything else that needs to be excluded.

$Resources = Get-RemoteMailbox -resultsize unlimited | where {($_.RecipientTypeDetails -ne ‘userMailbox’) -and ($_.recipientTypeDetails -ne ‘DiscoveryMailbox’)}


Now that we’ve gathered what needs to be excluded from the group, let’s update any on premises attribute that’s replicated to Azure and can be filtered . I prefer to use ExtensionAttribute 1-15 if they’re available, but also leverage the ‘info’ attribute on premises so you can be granular with scripting logic later if you have to. In my case I chose to filter out anything with the word ‘Resource’ in ExtensionAttribute1:

$Resources| foreach{

[string]$upn = $_.userprincipalname

$user = Get-ADUser -Properties info,extensionattribute1,distinguishedname -filter {userprincipalname -eq $upn}

Since the info attribute is multivalued we’ll want to make sure we don’t bulldoze what’s already in the attribute before setting it. In this case I’m checking to see if there’s anything there and if there is, we’ll add ‘Resource’ on a new line in the same attribute.

if($ -eq $null)


    Set-ADUser $Sam -Replace @{info=‘Resource’;extensionAttribute1=‘Resource’



        Set-ADUser $Sam -Replace {info=$($`r`nresource;extensionAttribute1=‘Resource’

        Set-ADUser $Sam -Replace @{info=“resource”;extensionAttribute1=‘Resource’}




Great! Now that we’ve set an attribute to be excluded by the filter, let’s make the dynamic group in Azure to assign those licenses to. Since I’m a Shell kindof guy, here’s a sample to create the group.

New-AzureADMSGroup -DisplayName “Licensing – E3” `

-Description “Dynamic group created to automatically assign licenses to mail enabled users” `

-MailEnabled $False -MailNickName “group” -SecurityEnabled $True -GroupTypes “DynamicMembership” `

-MembershipRule “(user.mail -ne null) -and (user.AccountEnabled -eq True) -and (user.extensionattribute1 -ne ‘Resource’)” `

-MembershipRuleProcessingState “On”


Now that the more complicated portion of creating the dynamic group that fits your users, the last thing left to do is follow the simple documentation to assign licenses and features to that particular group.

Here’s to my favorite kind of people out there, those who know how to stuff the ballot box as well as their faces! #VotePizza #ChicagoStyle #LouMalnatti’s