Recently we identified that a couple of the AAD Rego rulesets dealing with AAD conditional access, do not check that the tenant policies were configured exactly as specified in the baseline document instructions. The purpose of this issue is to review the code for all the Rego rulesets that examine conditional access to ensure they are coded consistent with each of the configuration characteristics described the baseline implementation instructions.
Example policy 3.7
This describes a problem that was found with AAD Rego policy 3.7. In the baseline document instructions the following three characteristics of the Access controls > Grant > Grant Access configuration of the conditional access policy are described. Before it was fixed, in some cases 3.7 could have been configured incorrectly in the tenant but still pass the ScubaGear check.
Require device to be marked as compliant
Require Microsoft Entra hybrid joined device
Require one of the selected controls
The original Rego code examined if the user ticked the box Require device to be marked as compliant or if they ticked the box Require Microsoft Entra hybrid joined device but nothing else. It did not check if the box Require one of the selected controls was checked and it did not check if the user checked any irrelevant boxes such as Example terms of us (which would fundamentally change the way the access policy is applied). In this context, Example terms of us should not be checked and the code should validate that.
Because of the original code flaw, the non compliant configuration in the screenshot below would Pass in ScubaGear.
Implementation notes
[ ] Perform a review of the Rego policies related to conditional access as describe above. Helper rulesets are within the scope of this review.
[ ] Review the pull request linked here for a reference of how the code flaw described above for 3.7 was corrected.
[ ] For any Rego policies identified as needed an update, examine the respective unit tests and functional tests to determine if any new tests (or updates to existing tests) are needed to exercise additional logic paths.
[ ] Create new coding issues to rectify any problems found
💡 Summary
Recently we identified that a couple of the AAD Rego rulesets dealing with AAD conditional access, do not check that the tenant policies were configured exactly as specified in the baseline document instructions. The purpose of this issue is to review the code for all the Rego rulesets that examine conditional access to ensure they are coded consistent with each of the configuration characteristics described the baseline implementation instructions.
Example policy 3.7
This describes a problem that was found with AAD Rego policy 3.7. In the baseline document instructions the following three characteristics of the Access controls > Grant > Grant Access configuration of the conditional access policy are described. Before it was fixed, in some cases 3.7 could have been configured incorrectly in the tenant but still pass the ScubaGear check.
The original Rego code examined if the user ticked the box Require device to be marked as compliant or if they ticked the box Require Microsoft Entra hybrid joined device but nothing else. It did not check if the box Require one of the selected controls was checked and it did not check if the user checked any irrelevant boxes such as Example terms of us (which would fundamentally change the way the access policy is applied). In this context, Example terms of us should not be checked and the code should validate that.
Because of the original code flaw, the non compliant configuration in the screenshot below would Pass in ScubaGear.
Implementation notes
[ ] Perform a review of the Rego policies related to conditional access as describe above. Helper rulesets are within the scope of this review.
[ ] Review the pull request linked here for a reference of how the code flaw described above for 3.7 was corrected.
[ ] For any Rego policies identified as needed an update, examine the respective unit tests and functional tests to determine if any new tests (or updates to existing tests) are needed to exercise additional logic paths.
[ ] Create new coding issues to rectify any problems found