Do something useful with risky applications data

[gdasher]

Prerequisites

• This issue has an informative and human-readable title.

💡 Summary

Filing this issue so that we don't forget these ideas. Now that we have data on risky apps in the raw scuba gear data, we should do an investigation to figure out what useful new baseline statements can be made based on this data. Example ideas:

1. No test apps have risky permissions with admin consent. Could pattern match based on display name looking for ("Dev", "Test", "Nonprod", etc) to find apps in a production tenant with high levels of access.

2. API Keys are regularly rotated--could flag "Password Credentials" are no older than 120 days (say). Could allow key creds (which are still risky but could be baked with more secure storage options) and federated auth to not have this requirement.

3. Preference for key credentials and federated credentials vs. API keys (potential should policy or flagged list).

4. Report with list of apps with risky permissions for admin review, like CAP table.

Motivation and context

TAs are targeting M365 tenants based on exploiting over privileged service principals and apps with admin consented permissions.

Implementation notes

These could be implemented with the data we already are extracting.

Acceptance criteria

• at least a few baselines are created a around high privilege service principals
• baselines are tested with customers
• this issue is decomposed into meaningful implementation issues.