Policies with a lower priority affecting score

[mrapoc]

I have noticed that when a policy (usually default) does not have a recommended setting, but a custom policy (for example) with a higher priority does, it still marks negatively.

It would be beneficial that if the recommended setting is applied regardless of other policies it should be marked as correct.

[cammurray]

Hey @mrapoc, this is by design due to the way that policies work.

Whilst we can determine based on the priority, we can't determine based on the scope of the policies that the policy is in use/or not in use.

Give you an example; if an organisation has two domains contoso.com, fabrikam.com. You could create a policy for contoso and a policy for fabrikam (based on the recipient scope), those policies would have different orders - and both are 'active' but for different recipient domains. The policies are applied based on going through them in priority order and assessing them against the scope - first hit wins. Effectively; the priority order is not the only factor in determining if a policy is in use or not.

So from the perspective of the report, we have to consider that any policy that is not disabled, could effectively be active for users in the organisation based on scope, and the dangers of accidental policy "enablement" due to priority orders are even higher when using groups for scoping (not domains), or if you have a large amount of recipient domains.

It's for this reason that we suggest either; disabling the policy that is not in use so that it cannot become "active" for a user if there is a scope exemption, or making sure that all policies meet the bar to reduce that risk.

[mrapoc]

Hi So in this case it was the default always on policy which cannot be disabled. You’d recommend setting the recommended settings within this rather than create a new policy? If we used a standard preset policy is there any logic to ignore the built in default as this would set all the required settings in most cases but not modify the default so would show as not protected

…

________________________________ From: Cam Murray ***@***.***> Sent: Thursday, November 16, 2023 3:21:42 AM To: cammurray/orca ***@***.***> Cc: mrapoc ***@***.***>; Mention ***@***.***> Subject: Re: [cammurray/orca] Policies with a lower priority affecting score (Issue #267) Hey @mrapoc<https://github.com/mrapoc>, this is by design due to the way that policies work. Whilst we can determine based on the priority, we can't determine based on the scope of the policies that the policy is in use/or not in use. Give you an example; if an organisation has two domains contoso.com, fabrikam.com. You could create a policy for contoso and a policy for fabrikam (based on the recipient scope), those policies would have different orders - and both are 'active' but for different recipient domains. The policies are applied based on going through them in priority order and assessing them against the scope - first hit wins. Effectively; the priority order is not the only factor in determining if a policy is in use or not. So from the perspective of the report, we have to consider that any policy that is not disabled, could effectively be active for users in the organisation based on scope, and the dangers of accidental policy "enablement" due to priority orders are even higher when using groups for scoping (not domains), or if you have a large amount of recipient domains. It's for this reason that we suggest either; disabling the policy that is not in use so that it cannot become "active" for a user if there is a scope exemption, or making sure that all policies meet the bar to reduce that risk. — Reply to this email directly, view it on GitHub<#267 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABWD4O4BATM6XK5MGUAHFU3YEWBENAVCNFSM6AAAAAA7K5QJGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTG4ZDSNJYHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[cammurray]

Hey @mrapoc thanks for responding.

I would recommend still ensuring the default policy meets your minimum bar as there is no “apply to all” option today in the policy scope - this means that it is possible these policies could be hit. I would always make sure your default policy meets your minimum bar.

There is a point around ignoring default in the instances where there is a baseline policy that has no exceptions (base line policies can still have an exception list, which would cause your default policy to hit or another lower ordered policy). We can definitely look at that (ignoring default in the instance of strict/standard policies being used, where there is no exceptions on the policy).

I have a backlog item #238 that has the intent for basic scope checks (where the exception/and condition are domains). But scope checks on groups aren’t really possible at the scope of this project, because that would mean we need to expand/assess groups to determine coverage - which might be fine on an org of 100-1000 users, but ORCA is used on tenants that are 50-100k+

What’s your thoughts?