defender-xdr

Name: defender-xdr
Author: vinayaklatthe

54installs34forks

How to install defender-xdr?

vinayaklatthe/microsoft-security-skills/defender-xdr

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill defender-xdr

Installs into the current project.

Summary

Guidance for Microsoft Defender XDR — the unified extended detection and response suite that correlates signals across endpoints, identities, email, and cloud apps into prioritised incidents with attack-graph context. Covers onboarding the four core workloads, incident investigat

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender XDR
2
3	Microsoft Defender XDR is a unified pre- and post-breach defence suite. It natively correlates
4	signals across endpoints (MDE), identities (MDI + Entra ID Protection), email/collaboration
5	(MDO), and cloud apps (MDA) to deliver a single prioritised incident with the full attack
6	story - graph, timeline, evidence, and recommended actions.
7
8	## When to use
9	Running coordinated detection and response across the Microsoft 365 estate from one portal
10	(security.microsoft.com), instead of investigating each workload in isolation. Also when you
11	need the attack disruption feature - it requires the XDR correlation.
12
13	Do not use this skill when ingesting third-party logs or writing custom KQL detections
14	across non-Microsoft sources (`sentinel`), merging Sentinel + Defender into one portal
15	(`unified-secops-platform`), or tuning endpoint-only policies (`defender-for-endpoint`).
16
17	## Map the signal to the source workload
18
19	XDR is only as good as the workloads feeding it. Use this to confirm what's onboarded and
20	which alerts are missing.
21
22	\| If the signal is... \| Source workload \| Required licence \|
23	\|---\|---\|---\|
24	\| Process tree, network connection, file hash on a device \| Defender for Endpoint (MDE) P2 \| M365 E5 / MDE P2 \|
25	\| Kerberos anomaly, DCSync, AD CS abuse, on-prem lateral movement \| Defender for Identity (MDI) \| M365 E5 / EMS E5 \|
26	\| Risky sign-in, leaked credentials, anomalous token use \| Entra ID Protection \| Entra ID P2 \|
27	\| Phishing URL click, malicious attachment detonation, BEC \| Defender for Office 365 P2 \| M365 E5 / MDO P2 \|
28	\| Risky OAuth app, anomalous SaaS upload, MCAS-style alert \| Defender for Cloud Apps (MDA) \| MDA standalone or E5 \|
29	\| Azure resource alert, AKS pod compromise \| Defender for Cloud \| DfC plan-based \|
30
31	> Rule of thumb: if an incident shows "1 alert, 1 entity," a workload is missing. A real
32	> attack always touches at least two of the above.
33
34	## Approach
35
36	1. Onboard the core workloads first — In order: MDE (highest endpoint signal), MDI (lateral
37	movement), Entra ID Protection, MDO. Add MDA when SaaS apps are in scope. Each workload
38	onboarded to its own portal still surfaces in the unified Defender portal.
39	*Verify: `Incidents` view shows alerts from at least 3 different `ServiceSource` values
40	after 24 hours.*
41
42	2. Configure unified RBAC before broad enablement — Move from per-workload roles to
43	Microsoft Defender XDR Unified RBAC (security.microsoft.com → Permissions). Build
44	custom roles scoped by data source + permission level. Pilot in active-directory mode for
45	30 days before enforcing.
46	*Verify: a Tier-1 analyst can triage and contain but not modify policies; a Tier-3 can
47	tune detections but not change RBAC.*
48
49	3. Investigate by incident, not by alert — Incidents group related alerts, assets, and
50	evidence with an attack graph. Always start from the Incidents queue. The attack graph
51	shows the kill chain across workloads in one view.
52	*Verify: open a multi-alert incident; the graph shows entities (user, device, mailbox,
53	IP) linked across workloads.*
54
55	4. Enable automatic attack disruption — Defender XDR can contain high-confidence active
56	attacks (disable a user, isolate a device, contain a mailbox) using cross-signal
57	confidence ≥ 99%. Roll out in report-only for 14 days, review actions, then enforce.
58	Verify: review `Action center` for past 14 days; no false positives in disruption actions.
59
60	5. Advanced hunting — Query the shared schema in KQL (`DeviceEvents`, `IdentityLogonEvents`,
61	`EmailEvents`, `CloudAppEvents`). Promote useful hunts into custom detection rules with
62	incident grouping and impacted entities mapped.
63	*Verify: each custom rule has entity mappings; without them, alerts don't join into
64	incidents.*
65
66	6. **Automated Investigation & Remediat

People who liked this also viewed

6 picks

Type

defender-xdr

54installs34forks

View on GitHub

How to install defender-xdr?

vinayaklatthe/microsoft-security-skills/defender-xdr

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill defender-xdr

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender XDR
2
3	Microsoft Defender XDR is a unified pre- and post-breach defence suite. It natively correlates
4	signals across endpoints (MDE), identities (MDI + Entra ID Protection), email/collaboration
5	(MDO), and cloud apps (MDA) to deliver a single prioritised incident with the full attack
6	story - graph, timeline, evidence, and recommended actions.
7
8	## When to use
9	Running coordinated detection and response across the Microsoft 365 estate from one portal
10	(security.microsoft.com), instead of investigating each workload in isolation. Also when you
11	need the attack disruption feature - it requires the XDR correlation.
12
13	Do not use this skill when ingesting third-party logs or writing custom KQL detections
14	across non-Microsoft sources (`sentinel`), merging Sentinel + Defender into one portal
15	(`unified-secops-platform`), or tuning endpoint-only policies (`defender-for-endpoint`).
16
17	## Map the signal to the source workload
18
19	XDR is only as good as the workloads feeding it. Use this to confirm what's onboarded and
20	which alerts are missing.
21
22	\| If the signal is... \| Source workload \| Required licence \|
23	\|---\|---\|---\|
24	\| Process tree, network connection, file hash on a device \| Defender for Endpoint (MDE) P2 \| M365 E5 / MDE P2 \|
25	\| Kerberos anomaly, DCSync, AD CS abuse, on-prem lateral movement \| Defender for Identity (MDI) \| M365 E5 / EMS E5 \|
26	\| Risky sign-in, leaked credentials, anomalous token use \| Entra ID Protection \| Entra ID P2 \|
27	\| Phishing URL click, malicious attachment detonation, BEC \| Defender for Office 365 P2 \| M365 E5 / MDO P2 \|
28	\| Risky OAuth app, anomalous SaaS upload, MCAS-style alert \| Defender for Cloud Apps (MDA) \| MDA standalone or E5 \|
29	\| Azure resource alert, AKS pod compromise \| Defender for Cloud \| DfC plan-based \|
30
31	> Rule of thumb: if an incident shows "1 alert, 1 entity," a workload is missing. A real
32	> attack always touches at least two of the above.
33
34	## Approach
35
36	1. Onboard the core workloads first — In order: MDE (highest endpoint signal), MDI (lateral
37	movement), Entra ID Protection, MDO. Add MDA when SaaS apps are in scope. Each workload
38	onboarded to its own portal still surfaces in the unified Defender portal.
39	*Verify: `Incidents` view shows alerts from at least 3 different `ServiceSource` values
40	after 24 hours.*
41
42	2. Configure unified RBAC before broad enablement — Move from per-workload roles to
43	Microsoft Defender XDR Unified RBAC (security.microsoft.com → Permissions). Build
44	custom roles scoped by data source + permission level. Pilot in active-directory mode for
45	30 days before enforcing.
46	*Verify: a Tier-1 analyst can triage and contain but not modify policies; a Tier-3 can
47	tune detections but not change RBAC.*
48
49	3. Investigate by incident, not by alert — Incidents group related alerts, assets, and
50	evidence with an attack graph. Always start from the Incidents queue. The attack graph
51	shows the kill chain across workloads in one view.
52	*Verify: open a multi-alert incident; the graph shows entities (user, device, mailbox,
53	IP) linked across workloads.*
54
55	4. Enable automatic attack disruption — Defender XDR can contain high-confidence active
56	attacks (disable a user, isolate a device, contain a mailbox) using cross-signal
57	confidence ≥ 99%. Roll out in report-only for 14 days, review actions, then enforce.
58	Verify: review `Action center` for past 14 days; no false positives in disruption actions.
59
60	5. Advanced hunting — Query the shared schema in KQL (`DeviceEvents`, `IdentityLogonEvents`,
61	`EmailEvents`, `CloudAppEvents`). Promote useful hunts into custom detection rules with
62	incident grouping and impacted entities mapped.
63	*Verify: each custom rule has entity mappings; without them, alerts don't join into
64	incidents.*
65
66	6. **Automated Investigation & Remediat

People who liked this also viewed

6 picks

Type