Skip to content

Policy sets

Alexander Filipin edited this page Nov 2, 2020 · 18 revisions

Design principals

You can find the basic principals my policy sets are following here.

Philosophy

My policy sets all follow a granular principle in which policies complement each other. Let's see what this means using parts of the policy set 'Device trust with AADP1' as example.

Complement

First we create a base protection

Base protection - All apps Require MFA or trusted device or trusted location

Base protection - Register security information Require trusted device or location For internal users

You notice that this will require MFA or trusted device or trusted location for all apps. But for some apps this will not be enough. This base protection is now extended by the application protection and we can add this on top of the base protection, e.g.

Application protection - Specific apps Require trusted device

So if we have an app for which the base protection is not sufficient, we can simply add it to one of the application protection policies for additional protection, but this would be a conscious decision. Our base protection, on the other hand, is aimed at all applications and when we add a new application we only have to ask ourselves, does the app require more than the base protection?

Granular

If we take a closer look at the policies, we see that I do not have policies with controls that are logically ANDed. Instead I have them granular split into separate policies.

Here in the admin protection

Admin protection - All apps Require MFA For M365 admins

Admin protection - All apps Require trusted device For M365 admins

Admin protection - All apps Require trusted location For M365 admins

Why? It gives us flexibility, let's imagine that normally we would have liked to switch on all three of the above mentioned controls. But now we work with an external consultant who also has admin rights. In the granular structure we can simply exclude them from the 'trusted device' and 'trusted location' policy and still get the MFA protection. If all controls were in one policy we would have a problem because we would also have to exempt them from the MFA requirement.

And here in the application protection

Application protection - Specific apps Require MFA

Application protection - Specific apps Require trusted device

Application protection - Specific apps Require trusted location

Instead of building fixed application classifications that require specific combinations of controls, the granular approach applies here as well. So when we are dealing with an application, we simply ask ourselves, "Is the base protection sufficient? If not, we can ask ourselves, do we need MFA, do we need a trusted device, do we need a trusted location. Depending on how the questions turn out, we simply add the application to the policies, very granular and individual, a kind of tagging.

You can find the policy sets here.