entra-id-protection

Name: entra-id-protection
Author: vinayaklatthe

161stars34forks

How to install entra-id-protection?

vinayaklatthe/microsoft-security-skills/entra-id-protection

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill entra-id-protection

Installs into the current project.

Summary

Guidance for Microsoft Entra ID Protection — risk-based identity security that detects user and sign-in risk and automates remediation. Covers risk detections, risk-based Conditional Access, self-remediation via MFA / secure password change, risky-user investigation, and streamin

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Entra ID Protection
2
3	Microsoft Entra ID Protection uses Microsoft's threat intelligence and ML to detect identity
4	risk (user risk and sign-in risk), automate remediation, and surface a queue of risky users
5	and sign-ins for investigation. Requires Entra ID P2 to enable risk policies.
6
7	## When to use
8	Adding risk-based, adaptive protection on top of Entra ID and Conditional Access. Use this skill
9	to choose risk thresholds, decide between self-remediation and SOC investigation, and stream
10	signals to Sentinel.
11
12	Do not use this skill for on-prem AD attack detection (`defender-for-identity`), authoring
13	plain CA policies (`conditional-access-mfa`), or PIM activation (`azure-pim`).
14
15	## Map the risk signal to the response
16
17	\| Risk type \| Examples \| Recommended response \|
18	\|---\|---\|---\|
19	\| Sign-in risk (this request) \| Anonymous IP, atypical travel, malware-linked IP, unfamiliar sign-in properties \| Risk-based CA → require MFA \|
20	\| User risk (this identity) \| Leaked credentials (TI feeds), Microsoft / partner-reported compromise \| Risk-based CA → require secure password change \|
21	\| Both medium+ on same user \| Active session takeover indicators \| Block + force secure password change + analyst review \|
22
23	> Rule of thumb: start risk policies at High threshold, run for 30 days, then expand to
24	> Medium once user registration and remediation flows are proven. Starting at Medium without
25	> SSPR + MFA registration causes lockouts.
26
27	## Approach
28
29	1. Confirm prerequisites — Entra ID P2 licensing, MFA + SSPR registration enforced for the
30	target user scope (registration policy in Authentication methods).
31	*Verify: `Authentication methods activity` report shows > 95% of in-scope users registered
32	for at least one strong method.*
33
34	2. Use risk-based Conditional Access, not legacy built-in risk policies — Author CA
35	policies with Sign-in risk and User risk conditions. Legacy "User risk policy" /
36	"Sign-in risk policy" toggles are deprecated in favour of CA.
37	Verify: no legacy risk policies enabled; risk conditions appear in CA What-If results.
38
39	3. Tier 1 - High risk only — First policy set: High sign-in risk → require MFA; High user
40	risk → require secure password change. Exclude break-glass accounts from every risk policy.
41	*Verify: report-only for 14 days shows < 5 false positives per 1,000 sign-ins before
42	enforcing.*
43
44	4. Tier 2 - Medium expansion — After 30 days of clean Tier 1 metrics, expand to Medium
45	sign-in risk → MFA. Don't extend user risk to Medium without an analyst review queue.
46
47	5. Investigate the queue — Triage Risky users, Risky sign-ins, Risk detections
48	daily. Confirm compromise (forces remediation + trains the model) or dismiss false positives.
49	Never bulk-dismiss without review - dismisses teach the model wrong signal.
50	Verify: weekly risky-user queue < 1% of monthly active users in a healthy tenant.
51
52	6. Stream to Sentinel — Diagnostic settings → send `RiskyUsers`, `UserRiskEvents`,
53	`RiskyServicePrincipals` to a Log Analytics workspace. Correlate with MDI and MDE in
54	Defender XDR incidents.
55
56	## Guardrails
57	- Break-glass accounts excluded from every risk policy. A leaked-credential detection on
58	the wrong account can lock you out of the tenant.
59	- MFA + SSPR registration first. Self-remediation only works when users can complete it.
60	Without registration, risk policies become lockouts.
61	- Start at High, expand to Medium. Medium thresholds without tuning generate noise and
62	user friction.
63	- Don't dismiss bulk false positives. Dismiss = "this was safe" which trains the model.
64	Use confirm-safe / confirm-compromise deliberately, not as a queue cleanup tool.
65	- Workload identity risk is separate. Service principals have their own risk detections
66	- cover them with a parallel policy.
67
68	## Common anti-patterns
69	- "Use the legacy User risk / Sign-in risk policy toggles" - Deprecated. Use CA risk
70	conditions which

People who liked this also viewed

6 picks

Type

entra-id-protection

161stars34forks

View on GitHub

How to install entra-id-protection?

vinayaklatthe/microsoft-security-skills/entra-id-protection

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill entra-id-protection

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Entra ID Protection
2
3	Microsoft Entra ID Protection uses Microsoft's threat intelligence and ML to detect identity
4	risk (user risk and sign-in risk), automate remediation, and surface a queue of risky users
5	and sign-ins for investigation. Requires Entra ID P2 to enable risk policies.
6
7	## When to use
8	Adding risk-based, adaptive protection on top of Entra ID and Conditional Access. Use this skill
9	to choose risk thresholds, decide between self-remediation and SOC investigation, and stream
10	signals to Sentinel.
11
12	Do not use this skill for on-prem AD attack detection (`defender-for-identity`), authoring
13	plain CA policies (`conditional-access-mfa`), or PIM activation (`azure-pim`).
14
15	## Map the risk signal to the response
16
17	\| Risk type \| Examples \| Recommended response \|
18	\|---\|---\|---\|
19	\| Sign-in risk (this request) \| Anonymous IP, atypical travel, malware-linked IP, unfamiliar sign-in properties \| Risk-based CA → require MFA \|
20	\| User risk (this identity) \| Leaked credentials (TI feeds), Microsoft / partner-reported compromise \| Risk-based CA → require secure password change \|
21	\| Both medium+ on same user \| Active session takeover indicators \| Block + force secure password change + analyst review \|
22
23	> Rule of thumb: start risk policies at High threshold, run for 30 days, then expand to
24	> Medium once user registration and remediation flows are proven. Starting at Medium without
25	> SSPR + MFA registration causes lockouts.
26
27	## Approach
28
29	1. Confirm prerequisites — Entra ID P2 licensing, MFA + SSPR registration enforced for the
30	target user scope (registration policy in Authentication methods).
31	*Verify: `Authentication methods activity` report shows > 95% of in-scope users registered
32	for at least one strong method.*
33
34	2. Use risk-based Conditional Access, not legacy built-in risk policies — Author CA
35	policies with Sign-in risk and User risk conditions. Legacy "User risk policy" /
36	"Sign-in risk policy" toggles are deprecated in favour of CA.
37	Verify: no legacy risk policies enabled; risk conditions appear in CA What-If results.
38
39	3. Tier 1 - High risk only — First policy set: High sign-in risk → require MFA; High user
40	risk → require secure password change. Exclude break-glass accounts from every risk policy.
41	*Verify: report-only for 14 days shows < 5 false positives per 1,000 sign-ins before
42	enforcing.*
43
44	4. Tier 2 - Medium expansion — After 30 days of clean Tier 1 metrics, expand to Medium
45	sign-in risk → MFA. Don't extend user risk to Medium without an analyst review queue.
46
47	5. Investigate the queue — Triage Risky users, Risky sign-ins, Risk detections
48	daily. Confirm compromise (forces remediation + trains the model) or dismiss false positives.
49	Never bulk-dismiss without review - dismisses teach the model wrong signal.
50	Verify: weekly risky-user queue < 1% of monthly active users in a healthy tenant.
51
52	6. Stream to Sentinel — Diagnostic settings → send `RiskyUsers`, `UserRiskEvents`,
53	`RiskyServicePrincipals` to a Log Analytics workspace. Correlate with MDI and MDE in
54	Defender XDR incidents.
55
56	## Guardrails
57	- Break-glass accounts excluded from every risk policy. A leaked-credential detection on
58	the wrong account can lock you out of the tenant.
59	- MFA + SSPR registration first. Self-remediation only works when users can complete it.
60	Without registration, risk policies become lockouts.
61	- Start at High, expand to Medium. Medium thresholds without tuning generate noise and
62	user friction.
63	- Don't dismiss bulk false positives. Dismiss = "this was safe" which trains the model.
64	Use confirm-safe / confirm-compromise deliberately, not as a queue cleanup tool.
65	- Workload identity risk is separate. Service principals have their own risk detections
66	- cover them with a parallel policy.
67
68	## Common anti-patterns
69	- "Use the legacy User risk / Sign-in risk policy toggles" - Deprecated. Use CA risk
70	conditions which

People who liked this also viewed

6 picks

Type