visualize defender anti phishing policies

[jmosby1]

🗣 Description

This PR adds Tables describing the anti-phish policies related to SecuritySuite Group 2. The tables are added to the end of the SecuritySuite report similar to the report tables in AAD

💭 Motivation and context

It can be difficult to determine what is causing checks in SecuritySuite Group 2 without understanding the variables that are being checked. These tables provide additional context to help users track down what is missing from their policies. Closes #2024

🧪 Testing

Run Invoke-Scuba with a configuration file (use sample-config-files/scuba_compliance.yaml as a template) that includes SensitiveUsers and PartnerDomains. You should see the relevant tables at the bottom of the SecuritySuite report

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• PR targets the correct parent branch (e.g., main or release-name) for merge.
• Changes are limited to a single goal - eschew scope creep!
• Changes are sized such that they do not touch excessive number of files.
• All future TODOs are captured in issues, which are referenced in code comments.
• These code changes follow the ScubaGear content style guide.
• Related issues these changes resolve are linked preferably via closing keywords.
• All relevant type-of-change labels added.
• All relevant project fields are set.
• All relevant repo and/or project documentation updated to reflect these changes.
• Unit tests added/updated to cover PowerShell and Rego changes.
• Functional tests added/updated to cover PowerShell and Rego changes.
• All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

• PR passed smoke test check.

• PR/feature branch passes functional tests for relevant products, if applicable.

• Feature branch has been rebased against changes from parent branch, as needed.

  Use Update branch button below or use this reference to rebase from the command line.

• Resolved all merge conflicts on branch.

• Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge checklist

• Feature branch deleted after merge to clean up repository.
• Close issues resolved by this PR if the closing keywords did not activate.
• Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

[adhilto]

Thanks for working on this!

Some high-level feedback:

• Could you add a add description above the "Sensitive Users" and "Partner Domains" tables? In particular, I want to make it clear to the users that those tables come from their ScubaGear config file, which may or may not reflect their actual configuration. I'm picturing something like the paragraph above the DNS tables of the EXO report that explains what those tables are.
• A key piece that is missing is who the anti phish policies apply to. The provider already collects this data:
  • For custom rules, look at the anti_phish_rules key. The relevant fields are SentTo, SentToMemberOf, RecipientDomainIs, ExceptIfSentTo, ExceptIfSentToMemberOf, and ExceptIfRecipientDomainIs. One interesting piece about how those fields work is they are AND not OR conditions. As in if a rule applies a group and a domain, the rule only applies to users that are in both the group and the domain. ScubaGear specifically looks for rules that have all tenant domains in the RecipientDomainIs field and have the other 5 fields I listed empty.
  • For the standard and strict preset policies, look at the protection_policy_rules key. If SentTo, SentToMemberOf, RecipientDomainIs, ExceptIfSentTo, ExceptIfSentToMemberOf, and ExceptIfRecipientDomainIs are all null, the policy applies to everyone (that's specifically what ScubaGear is looking for for the preset policies). Note that's just for the preset policies, for the custom policies, M365 doesn't allow you to have them all be null.
  • The default policies always applies to all users.
• As to how to show that data, I don't recommend listing all the users, groups, and domains. There could potentially be long lists, too much for us to display in the reports. Instead, I recommend mirroring how the CAP tables at the bottom of the AAD report shows this information. For example, you could add a "Applicability" column:
  • If the policy applies to everyone as described above, say "All users"
  • Otherwise, have a bulleted list with entries for each field that isn't null, like "Users included: 2 users", "Groups included: 2 groups", "Domains included: 2 domains", "Users excluded: 2 users", etc. Since ScubaGear is looking for all domains to be added, we could even say something like "Domains included: 2 out of 4 tenant domains" for the domains entry to help users see if a policy is failing because they didn't include all domains.
• Could you turn the data in the "Safety Indicators" fields into bulleted lists?