-
Notifications
You must be signed in to change notification settings - Fork 72
Release history
Policies: 100, 101, 102, 103, 109
- Attribute assignment administrator
- Attribute assignment reader
- Attribute definition administrator
- Attribute definition reader
- Cloud App Security Administrator
- Edge administrator
- Exchange recipient administrator
- Identity Governance Administrator
- Knowledge manager
- Windows 365 Administrator
- Windows update deployment administrator
Policies 500, 501 and 505 have been updated to use 'Filter for devices' instead of 'Device state (Preview)' as 'Device state (Preview)' is being deprecated. Related Docs.
The "network trust" policy sets have been removed, the "device trust" policy sets have been renamed to "Category structure..." in preparation for persona based policy sets.
- Renamed policy 300 and 304 from "legacy authentication" to "other clients" to better distinguish between "other clients" and "active sync"
- Renamed policy 100, 101, 102, 103 and 109 from "M365 admins" to just "admins" because next to the AAD roles it also target the admin group that may e.g. include AWS, GCP admins etc.
- Optimized naming of policies 502, 504, 506, 507
- Changed sign-in frequency in policy 501 from 1h to 12h
Fixed required scopes to include "Policy.Read.All" and "Application.Read.All".
Switched to Microsoft.Graph PowerShell Module, the deploy guidance has been updated.
Policies: 100, 101, 102, 103, 109
- Attack payload author
- Attack simulation administrator
- Authentication policy administrator
- Azure AD joined device local administrator
- Domain name administrator
- Knowledge administrator
- Usage summary reports reader
- Form "...When using unknown or unsupported device platforms" to "...When using unknown device platforms"
- Reduced 502 to internal users, as app protection policies should not be applied to external users
- New policy 506 which can be used to limit unknown device platforms to browser session, this policy can be helpful if you e.g. have Linux usage and cannot simply block unknown device platforms with policy 302
- New policy 507 to limit external users to browser on iOS and Android to close the gap the update to 502 above did open
For more details take a look at the O365 data loss prevention explanation
Bugfix for policy 500, 501, 505: 'includeDeviceStates' and 'excludeDeviceStates' are no longer supported. Please use 'includeDevices' and 'excludeDevices'. Note: Currently policies with includeDevices/excludeDevices are NOT returned from Graph V1, hence you should only PATCH with Beta until this is fixed.
Bugfix for policy 406 and 407, changed includeApplications from All to None
Bugfix for policy 406 that was introduced in the 2020-10-31 policy repository update
Added the following roles to the M365 admin protection
- Directory writers
- Teams Devices Administrator
Naming consistency for policies 102 & 106
While Identity protection / risk has limitations with B2B users I no longer believe it's right to exclude them from the risk policies. For sign-in risk its not really important because a B2B user must always perform MFA due to the 200 base protection policies. However, while a B2B user with high user risk will not be able to perform a password change and gets blocked trying to access your resources I believe that's better than the compromised B2B user accessing your data.
For the mixed licensing sets (AADP1 and AADP2) the dynamic group should now include the B2B users, this is not part of this update and an open issue.
- Removed guest and external user exclusions from risk policies 202, 203, 204, 205, 206, 207
- Adjusted naming of risk policies 204, 205, 207 from "AADP2" users to "licensed" users
- Added new risk policies in the application protection for sensitive applications
Updated the clientAppTypes of policies 206 & 207 from modern auth to all (modern and legacy auth) since the API does not allow clientAppType conditions for the password change control.
- 206 - < RING > - Base protection - All apps: Require password change For internal users When high user risk is detected
- 207 - < RING > - Base protection - All apps: Require password change For AADP2 users When high user risk is detected
Updated the grant controls of policy 201 (limitation of MFA registration) to include MFA as grant control, this allows users to update their security information from a untrusted device or untrusted location if they are already registered for MFA.
Added the following policies to the policy repository that may be used for specific requirements and are not part of the policy sets:
- 108 - < RING > - Admin protection - Privileged systems: Require trusted device or trusted location
- 109 - < RING > - Admin protection - All apps: Require trusted device or trusted location For M365 admins
- 208 - < RING > - Base protection - All apps: Require MFA or trusted device
Removed the following policies from all policy sets, you can still find them in the repository
- 103 - < RING > - Admin protection - All apps: Block access For internal M365 admins When any sign-in risk is detected
- 107 - < RING > - Admin protection - Privileged systems: Block access For internal users When any sign-in risk is detected
- 203 - < RING > - Base protection - All apps: Block access For internal users When high sign-in risk is detected
- 205 - < RING > - Base protection - All apps: Block access For AADP2 users When high sign-in risk is detected
Changed the sign-in risk policies from medium risk only to medium and high risk
- 202 - < RING > - Base protection - All apps: Require MFA For internal users When medium or above sign-in risk is detected
- 204 - < RING > - Base protection - All apps: Require MFA For AADP2 users When medium or above sign-in risk is detected
- This effects all M365 admin protection policies: 100, 101, 102, 103 and the new 109
All JSONs templates have been updated with clientAppTypes related to the clientAppTypes changes (Link to Microsoft Blog will be added once available)
Before this change most templates did not contain clientAppType information
"clientAppTypes": []
Now the clientAppType information is mandatory and all templates were updated
"clientAppTypes": [
"browser",
"mobileAppsAndDesktopClients"
]
Background information: Previously, the policies only affected modern authentication unless legacy authentication was explicitly specified. The combination of browser & mobileAppsAndDesktopClients now makes it clear that most policies only affect modern authentication. This could lead to the idea that a security hole is created, but all policy sets include policies to block legacy authentication (300 & 301) to close this hole.
If you want to create a policy that targets modern and legacy authentication you can do this with the following clientAppTypes. Be aware that legacy authentication scenarios will break if you enforce controls that are not supported by legacy authentication. I recommend to use policies 300 & 301 to perform a impact analysis on legacy authentication and block it while keeping the other policies targeted to modern authentication.
"clientAppTypes": [
"All"
],
- Long-term Require app protection policy will replace Require approved client app. There will be no need to require both in the future. Before this update the policy sets have required BOTH an app protection policy and approved client app for O365. Since not all applications support app protection policies yet, this may have caused problems in the previous policy sets. I have now removed the policy to require a approved client app from all policy sets (it's still in the repository). Instead policy 502 does now require a app protection policy OR approved client app. The behavior will be that apps that support the app protection policy grant, will need to have an app protection policy, but the apps that don't support it yet will have to be on the approved app list. Once all apps support app protection policies I will switch 502 back to only require app protection policies.
- Added user risk policies
- Added new policies to limit legacy auth to trusted locations, security quick win while you are working on blocking
- Renamed risk policies to SIGN-IN risk policies in preparation for the upcoming USER risk in Conditional Access
- Added a endpoint parameter to specify which Graph endpoint should be used (V1.0, Beta, Canary) - defaults to V1.0
- The automation now creates a AAD group for administrative accounts that will be targeted in the M365 admin protection. This group can be used for administrative accounts that do NOT have a AAD privileged role. For example this could be a admin in one of the other M365 RBAC systems, e.g. Security and Compliance Center. You will have to manually populate this group.
This version contains breaking changes which do not make it possible to update existing V1.0 deployments.
- Added support for ring based deployment
- Added support for permanent and temporary exclusion group per policy
- Added new M365 admin roles to protection (Hybrid identity administrator, Network administrator, Printer administrator, Printer technician)
- Adjusted templates from 'deviceStates' to 'devices'
- Each policy in the repository now has a well known assigned number
- Switched repository to report only mode
- Updating policies is no longer based on display Name it now requires the policy id in the JSON file
Initial release