Conflict of CISA.MS.AAD.3.3 and EIDSCA.AM02

[berny275]

In CISA.MS.AAD.3.3 step 3 is:

For Allow use of Microsoft Authenticator OTP select No

In EIDSCA.AM02 the recommended action is to enable it. In my tenancy I don't use OTP, so I'm disabling EIDSCA.AM02 as a test, but for people who are doing this for the first time, you need to figure out what works for you and go with that.

[moorereason]

It's not uncommon for standards to require opposing settings. You can have Maester exclude the tags/tests you want to ignore with the Invoke-Maester -ExcludeTag.

[soulemike]

Just as an aside to the idea above, we published a blog around controls. https://maester.dev/blog/compensating-controls

[SamErde]

All security controls (OK, most security controls) should be taken with full understanding of how they relate to your environment. You may have other mitigating controls that allow you to exclude or create exceptions for other security requirements -- or there may be cases where a setting simply isn't relevant to you.

In some cases, even recommendations from reputable benchmarks can be ill-advised in spite of being based on commonly accepted principals. For example, the CIS benchmarks indicate that the MAPS feature for Microsoft Defender should be disabled. This has the unfortunate effect of disabling almost all cloud-related protections for the product, which results in the endpoint being much less secure!

In your case case, CISA includes the instruction to disable Microsoft Authenticator's OTP functionality because authentication context information (location and the application that triggered the MFA request) is only shown in MFA prompts. That is, when you are prompted to approve an authentication attempt or when you are prompted to enter/match a given number to verify the authentication attempt. OTPs are time-based, but they're always there, visible in the Authenticator app with no prompt and no context information. Therefore, leaving OTP enabled would allow a "bypass" of MS.AAD.3.3, which states, "if Microsoft Authenticator is in use, configure Authenticator to display context information to users when they log in."

So how can you resolve this apparent conflict? You can leave the OTP option enabled (this can be a backup or bootstrap method) and use authentication strengths for different conditional access scenarios to strictly limit when OTPs are allowed and when stronger forms of MFA are required. Or, if you have enough other authentication methods available to users and are comfortable eliminating OTPs in Authenticator, you can follow the CISA guidelines and disable it.

(The important intent in EIDSCA is probably that some form of MFA be available to all users, but perhaps this can be further refined.)

To your point, either path does still leave you with a Maester report that shows at least one failure. This is an area that I think the project has some awesome potential for evaluating and scoring your security posture based on multiple conditions across multiple test suites. We could assess related controls and potentially provide a cumulative pass/fail based on the assessment of two or more complimentary controls. An entire layer of logic would need to be added, but is certainly possible to do. There's just a lot of work between the current state and that grand vision! 👷

In the shorter term, it is easy to exclude tests when running Maester.

In the medium term, I think we could add options to the maester-config.json file that (A) allows you to always skip specific tests while also (B) including a comment field that allows you to indicate why you chose to skip the test. That comment could be included in the report output and would also serve as a self-documenting configuration for you and your teammates that are involved in the process.

@Cloud-Architekt and @merill, do you have any other thoughts to add?

[Cloud-Architekt]

@SamErde: I completely agree with your statement and thoughts—especially the point that enforcement of the authentication method should be explicitly verified via Authentication Strength, not just by allowing the method in general.

Although we have the option to exclude EIDSCA.AM02, I’ll like also to have a in-depth discussion with the other co-authors of the Entra Attack & Defense playbook to review the current recommendation and provide more context in the description to explain the use cases where it might still make sense to keep it enabled.