Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MS.AAD.3.7 and MS.AAD.3.8 assume you're running Hybrid #194

Closed
JonesMikael opened this issue May 27, 2024 · 4 comments
Closed

MS.AAD.3.7 and MS.AAD.3.8 assume you're running Hybrid #194

JonesMikael opened this issue May 27, 2024 · 4 comments

Comments

@JonesMikael
Copy link

JonesMikael commented May 27, 2024

I have som suggestions on the following tests:

MS.AAD.3.7: Managed devices SHOULD be required for authentication.
MS.AAD.3.8: Managed Devices SHOULD be required to register MFA.

They assume you're running a Hybrid environment and that you tick both [v] Require device to be marked as compliant and [v] Require Microsoft Entra hybrid joined device. Many of our customers are moving away from Hybrid or at least moving their devices to Entra ID Joined so the [v] Require Microsoft Entra hybrid joined device is no longer required for them.

Maybe change the test to just require one of them if that's suitable for your environment?

@soulemike
Copy link
Contributor

soulemike commented May 27, 2024

It is a thought I fought with a fair bit while transcribing the original rego to pester tests. If we deviate our tests too far from the CISA controls it causes an issue and as we aren't authoritative for them we don't want to mislead any users of Maester. So there is a thought of having like an -alternate that would add a warning that understanding of the intent of the control is necessary.

For MS.AAD.3.7 & MS.AAD.3.8 The logic should test for OR on the CA policy config, are you seeing a different outcome or would just prefer to avoid having a CA policy testing for a setting that isn't used?

@JonesMikael
Copy link
Author

Thanks for clarifying. I totally agree that we should follow good official regulations/practices - makes our life so much easier when describing our setup. CISA Strong Authentication & Secure Registration - MS.AAD.3.7v1 states this so it's rather them who should change it :)

What I see in most deployments are customers in hybrid environments are moving to Entra ID Joined + Compliance policies in place to make sure the device is Compliant and that is what you want to require. When this in place, most customers leave all Group Policies behind or even delete them and simply don't care about on-prem joined devices. if you leave [v] Require Microsoft Entra hybrid joined device you risk that a perpetrator could join a rouge device to your on-prem Active Directory and be able to access your cloud environment through that.

Of course, I could simply change the test to suit our environment.

I think in general, an -alternate or -deviation would be a good idea that still marks the test as green and "Passed as deviation" for those few tests where it's common to have an alternate solution for some customers but still considered "secure". I'm sure there are other tests like it, for example MS.AAD.7.6: Activation of the Global Administrator role SHALL require approval. Where we do agree, in some organisations that is not practical if they are a one-man shop :)

@merill
Copy link
Contributor

merill commented May 28, 2024

I suggest adding a parameter to the test along the lines of -SkipHybridJoinCheck

The default policy aligns with CISA and customers can always adjust them to their risk model. In this case it improves the security posture over what CISA have currently defined.

@soulemike soulemike mentioned this issue May 29, 2024
@soulemike
Copy link
Contributor

Thanks for the suggestion @JonesMikael, this has been added. If an environment does not meet the CISA control definition, then it will fall back to testing the alternate configuration and still pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants