Categories

This article describes the out-of-the-box policies that are shipped as part of CoreSuite.  

Teams Policies 


One of the big challenges of Microsoft Teams is how quickly and easily it can grow out of control. Users can easily create new teams and new channels, and there is very little incentive to clean up Teams after they are no longer used. This has both security and productivity implications. From a security standpoint, files and other data can be placed in Teams without anyone monitoring whether the appropriate users who can see those documents are members of the Team or Channel. Guest users can be added without putting any sort of “end of access” date. From a productivity standpoint, as files and data accumulate in Teams it can be difficult for employees to know if they are accessing the correct and most relevant information. Imagine searching Teams for a customer list and returning 10 different Excel spreadsheets, all named “Latest”.  


Inactive Teams  


Inactive Teams identifies teams where there is no user activity occurring.  Operators can configure how long a Team must be inactive before it is a policy violation (I.e., 90 days). You can decide whether to archive or delete the team, and you can route an approval request to the team owner before taking action.    


Empty Teams  


Empty teams are those teams which have no members.  With Empty Teams you can choose to archive or remove the Team. 


Teams without owners 


Teams without owners cause difficulties if no one is monitoring usage of the team, which can result in inappropriate members being added to the team, sensitive content being shared, and no one there to curate or manage. Microsoft recommends a minimum of two group owners per Team.  This workflow allows you to email a specified user or all members of the Team requesting that they identify and add a Team owner.  


Teams without multiple owners 


Similar to above, Teams without multiple owners identifies groups with only a single owner, and sends an email to the owner or a specified user requesting that they identify and add additional Team owners. 


Public Teams  


For organizations that want to limit the number of Teams employees can join, Public Teams are something to be actively monitored.  Many organizations have chosen a periodic attestation process to require Public Teams owners to attest that the Team is still necessary.  This workflow will email a group owner or specific user asking them to attest that the Team is still needed. Otherwise, the Team will be archived or removed.   


Teams with guest users 


Teams with guest users identifies those teams who have guest users as members of the team.  This can be a security risk as they may have access to files and content intended for employees only.  This workflow emails the group owner or a specified user requesting that they attest that the guest users still need access to the Team. Otherwise, the guest owners are removed from the Team.   


Teams with guest users with a certain sensitivity label 


Sensitivity labels allow organizations to define different levels of sensitive information being shared. The Teams with guest users with a certain sensitivity label policy allows you to identify those teams that should not have guest users based on the sensitivity of the information being shared. With this policy you can identify the sensitivity label. This workflow emails the group owner or a specified user requesting that they attest that the guest users still need access to the Team. Otherwise, the guest owners are removed from the Team.  


Inactive Teams users with Audio Conferencing license 


This policy helps to identify those users who have been assigned an Audio Conferencing license, but who are not actively using Teams Voice. You can identify the threshold for inactivity, and then the workflow can send an email to the user’s manager or a specified address asking whether the license is still needed. If not, the license is removed from the user.  


Security and Identity Playbook 

23.02 introduces a new Security and Identity Management Playbook. Based on our experience with hundreds of companies managing their Microsoft 365 tenants, these are recommended practices for identifying and resolving common issues with security and identity management.  


Inactive last 60 days but not blocked users 

Problem to be solved: Security best practices suggest disabling the accounts of inactive users to reduce potential breaches. 

Policy description: Finds users inactive for the last 60 days with active credentials. This list excludes guests. 

Remediation action: This policy will email the inactive account’s manager or a named account to attest that the account should remain active. Otherwise, it will disable all those accounts that have been inactive in the last 60 days. 


Admin without MFA 

Problem to be solved: MFA is a must-have for all privileged users to reduce security risk due to compromised identity. MFA provides additional assurance that the individual attempting to gain access is who they claim to be. With MFA, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise, thus reducing the risk.  

Policy definition: Find all users with admin roles and without MFA 

Remediation action: This policy will email the inactive account’s manager or a named account to attest that the account does not require MFA. Otherwise, it will re-enable MFA for targeted users.  


Admin with password not changed in the last 90 days 

Problem to be solved: Microsoft suggests ensuring the passwords of admin accounts and shared accounts change on a regular basis. Ensure all admin and shared accounts have signed in and changed their passwords at least once in the last 90 days.  

Policy definition: Find all admin accounts that have not changed their password in the last 90 days 

Remediation action: This policy will email the inactive account’s manager or a named account to attest that the account password does not need to change. Otherwise, it will force a password change for the user upon their next login. 


Microsoft 365 Groups without Owners 

Problem to be solved: Having M365 groups without owners cause difficulties if no one is monitoring usage of the group, which can result in inappropriate members being added, sensitive content being shared, and no one there to curate or manage.  

Policy definition: Find all M365 groups that have total owners equal to zero. 

Remediation action: This policy will trigger an email to a named user asking that a group owner be identified.  


Inactive Guests in the last 90 days 

Problem to be solved: Removing guest users that are no long active minimizes the risk that these accounts can be compromised.  

Policy definition: Find all guest users that have been inactive for the last 90 days 

Remediation action: This policy will remove the inactive users.  


External Users in security groups 

Problem to be solved: External users that have access to resources and data due to their membership in security groups need periodic attestation to ensure they are not forgotten, and they have the least possible privileges.  

Policy definition: Find all external members that have been added to security groups 

Remediation action: This policy requires a named user attest that external users should still belong to the security groups of which they are a member. If not attested to, they will be removed from the group.  


External Users in Microsoft 365 groups 

Problem to be solved: External users that have access to resources and data due to their membership in M365 groups need periodic attestation to ensure they are not forgotten, and they have the least possible access.  

Policy definition: Find all external members that have been added to M365 groups 

Remediation action: This policy requires a named user attest that external users should still belong to the security groups of which they are a member. If not attested to, they will be removed from the group. 


Admin on-cloud without strong password 

Problem to be solved: Security best practices suggest to set strong passwords for cloud users. Strong passwords have to include one mandatory element that is complexity to avoid security breach, especially for admin accounts.  

Policy definition: Find all Admins with 'Account type' = ONCLOUD and who have been identified as not having a strong password 

Remediation Action:  This policy forces admins without strong password to re-set the password to include complexity. 


Users without MFA 

Problem to be solved: MFA is a critical capability for users to reduce security risk due to compromised identity. MFA provides additional assurance that the individual attempting to gain access is who they claim to be.   

Policy definition: Find all users without MFA enabled 

Remediation action: This policy will re-enable MFA for targeted users. 


Users without default MFA method

Problem to be solved: Enabling MFA for users is a two step process. The user must first enroll in MFA, at which point it can be enabled.  An unenrolled account is more vulnerable than even one where MFA is not enabled since it provides an opportunity for a bad actor to take over an account by enrolling with false credentials.   

Policy definition: Find all users where no strong authentication method has yet been identified.   

Remediation action: This policy emails the user asking them to complete MFA enrollment process and identify a default authentication method.