Skip to content

🙏 Skip tests that are not feasible due to specific constraints #1264

@SonKneeJim

Description

@SonKneeJim

Describe the feature

The ability to manually skip or suppress selected tests with reasoning included and a flag to suggest they were manually skipped in the report.

How will this feature enhance your project and further the project’s overall goals? Who will benefit from this feature (i.e. all users, the project team)?

There are some tests that are not possible to pass in my current organisation due to constraints. Some of these tests we have compensating controls for and some are due to lack of required licensing that we simply will not get the funding for at this stage. The ability to skip these with a reason will allow us to focus on the tests we can attempt to resolve and also makes a more accurate report / statistics when presenting progress to management.

Describe alternatives you've considered

I am currently logging the tests that cannot be passed in our documentation. These are being manually checked on each new run of the Maester report as part of our processes.

Additional context

Some example scenarios:

Test: CISA.MS.AAD.2.1 - Users detected as high risk SHALL be blocked
Situation: We only have Entra ID P2 for our Entra admin accounts which make up around 2% of our user base. All other users have Entra ID P1 and when they match the risk related conditions that information is logged and our managed SOC to review and remediate as necessary. Entra ID P2 is needed for all users to ensure complliance to pass this test. This is the same for the other tests which require risk based policies.
I also note that the failure message suggests we do not have any policies targeting high risk sign-ins, when in fact we do for the specific admin users groups.

Test: MT.1006 - At least one Conditional Access policy is configured to require MFA for admins
Situation: We require phishing-resistant MFA for all accounts assigned to directory roles, but we do this by targeting security groups which contain the admin accounts, rather than creating a CAP which requires MFA from particular roles. So whilst the test logs this as a failure, we have in fact achieved the same protections, just using a different method.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions