defender-for-apis

Name: defender-for-apis
Author: vinayaklatthe

53installs34forks

How to install defender-for-apis?

vinayaklatthe/microsoft-security-skills/defender-for-apis

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

Installs into the current project.

Summary

Guidance for Microsoft Defender for APIs — a Defender for Cloud plan that discovers, prioritizes by risk, and protects APIs published in Azure API Management against threats and abuse. Covers onboarding, security findings, and threat detection. WHEN: Defender for APIs, API threat

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender for APIs
2
3	Defender for APIs is a Microsoft Defender for Cloud plan that provides visibility into the
4	security posture of APIs published in Azure API Management, prioritises them by risk, and
5	detects active threats and abuse. It is detection and posture, not a WAF or API gateway.
6
7	## When to use
8	Use this skill when securing APIs that are already published through Azure API Management
9	and you need risk-based prioritisation plus runtime threat detection.
10
11	Do not use this skill for:
12	- Designing API security from scratch (use `api-security-design` for OWASP API Top 10)
13	- APIs fronted by Application Gateway / Front Door without APIM (out of scope today)
14	- WAF tuning or rate-limiting design (APIM policies, not Defender)
15
16	## Triage which APIs to protect first
17
18	Defender for APIs onboards everything in APIM by default. The work is prioritisation.
19	Use this table to rank your inventory:
20
21	\| Risk signal \| Priority \| Why it matters first \|
22	\|---\|---\|---\|
23	\| Externally exposed + unauthenticated \| P0 - this week \| Already an attack surface; one bad request from internet \|
24	\| Externally exposed + handles sensitive data (PII, payment, health) \| P0 - this week \| Sensitive-data exposure (OWASP API3) and BOLA risk \|
25	\| Externally exposed + authenticated \| P1 - this month \| Auth bypass / token abuse risk \|
26	\| Internal + handles sensitive data \| P2 - this quarter \| Insider risk; lateral movement scenarios \|
27	\| Inactive or unused for >90 days \| Decommission \| Free attack surface reduction \|
28	\| Internal + non-sensitive \| P3 - monitor only \| Low immediate risk \|
29
30	> Rule of thumb: if Defender for APIs surfaces more than 50 findings on day one, do not
31	> try to fix all of them. Filter to externally exposed + sensitive-data first - that is
32	> usually 5-15 APIs and 80% of real risk.
33
34	## Approach
35
36	1. Enable the plan at subscription scope — Defender for APIs is a per-API priced plan inside
37	Defender for Cloud (billed per million API calls). Enable on the subscription containing your
38	APIM instances. The first 30 days are free for evaluation.
39	Verify: Defender for Cloud → Environment settings → Defender plans shows "APIs: On".
40	2. Onboard APIs into the plan — From *Defender for Cloud → Workload protections → Defender
41	for APIs → Onboard*, select APIM instances. Onboarding does not require redeploying APIs.
42	Verify: API inventory populates within ~1 hour; each API shows a risk score and findings.
43	3. Triage by the risk table above — Filter inventory to External + Unauthenticated and
44	External + Sensitive data findings. Treat these as P0.
45	4. Remediate at the APIM layer — Defender does not fix; APIM policies do.
46	- Unauthenticated → add `<validate-jwt>` or subscription-key policy
47	- Sensitive data exposure → review `set-body` / response-mask policies
48	- Excessive enumeration → add `<rate-limit-by-key>` policy
49	- Inactive APIs → deprecate or revoke product visibility
50	Verify: re-scan finding clears within 24 hours of APIM policy publish.
51	5. Wire detections to your SOC — Defender alerts flow into Defender for Cloud, Defender XDR,
52	and Sentinel via the Microsoft Defender XDR connector. Build automation rules for
53	unauthenticated-access spikes and credential-stuffing patterns.
54	*Verify: a test malicious request (e.g. enumeration burst from one IP) generates an alert
55	within 15 minutes in the Defender XDR portal.*
56	6. Iterate monthly — New APIs appear; old ones go inactive. Re-run the triage table monthly
57	so risk priority stays current.
58
59	## Guardrails
60	- APIM-only scope. Defender for APIs only sees APIs fronted by Azure API Management. APIs
61	on Application Gateway, Front Door, or direct App Service exposure are invisible to it -
62	route them through APIM or use other controls.
63	- Detection is not protection. Defender finds the problem; APIM policies fix it. Treat
64	Defender as your prioritisation engine, not your security perimeter.
65	- Pricing scales with calls. High-traffic APIs (hundreds of millions of calls/month) can
66	generate significant Defender for APIs cost. Use the Azure Pricing Calculator before scaling.
67	- Sensitive-data detection is sampled. Defender inspects a percentage of API responses; do
68	not rely on it as a complete DLP control - pair with response-masking APIM policies for
69	known-sensitive fields.
70	- Onboarding changes nothing in your API. N

People who liked this also viewed

6 picks

Type

defender-for-apis

53installs34forks

View on GitHub

How to install defender-for-apis?

vinayaklatthe/microsoft-security-skills/defender-for-apis

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender for APIs
2
3	Defender for APIs is a Microsoft Defender for Cloud plan that provides visibility into the
4	security posture of APIs published in Azure API Management, prioritises them by risk, and
5	detects active threats and abuse. It is detection and posture, not a WAF or API gateway.
6
7	## When to use
8	Use this skill when securing APIs that are already published through Azure API Management
9	and you need risk-based prioritisation plus runtime threat detection.
10
11	Do not use this skill for:
12	- Designing API security from scratch (use `api-security-design` for OWASP API Top 10)
13	- APIs fronted by Application Gateway / Front Door without APIM (out of scope today)
14	- WAF tuning or rate-limiting design (APIM policies, not Defender)
15
16	## Triage which APIs to protect first
17
18	Defender for APIs onboards everything in APIM by default. The work is prioritisation.
19	Use this table to rank your inventory:
20
21	\| Risk signal \| Priority \| Why it matters first \|
22	\|---\|---\|---\|
23	\| Externally exposed + unauthenticated \| P0 - this week \| Already an attack surface; one bad request from internet \|
24	\| Externally exposed + handles sensitive data (PII, payment, health) \| P0 - this week \| Sensitive-data exposure (OWASP API3) and BOLA risk \|
25	\| Externally exposed + authenticated \| P1 - this month \| Auth bypass / token abuse risk \|
26	\| Internal + handles sensitive data \| P2 - this quarter \| Insider risk; lateral movement scenarios \|
27	\| Inactive or unused for >90 days \| Decommission \| Free attack surface reduction \|
28	\| Internal + non-sensitive \| P3 - monitor only \| Low immediate risk \|
29
30	> Rule of thumb: if Defender for APIs surfaces more than 50 findings on day one, do not
31	> try to fix all of them. Filter to externally exposed + sensitive-data first - that is
32	> usually 5-15 APIs and 80% of real risk.
33
34	## Approach
35
36	1. Enable the plan at subscription scope — Defender for APIs is a per-API priced plan inside
37	Defender for Cloud (billed per million API calls). Enable on the subscription containing your
38	APIM instances. The first 30 days are free for evaluation.
39	Verify: Defender for Cloud → Environment settings → Defender plans shows "APIs: On".
40	2. Onboard APIs into the plan — From *Defender for Cloud → Workload protections → Defender
41	for APIs → Onboard*, select APIM instances. Onboarding does not require redeploying APIs.
42	Verify: API inventory populates within ~1 hour; each API shows a risk score and findings.
43	3. Triage by the risk table above — Filter inventory to External + Unauthenticated and
44	External + Sensitive data findings. Treat these as P0.
45	4. Remediate at the APIM layer — Defender does not fix; APIM policies do.
46	- Unauthenticated → add `<validate-jwt>` or subscription-key policy
47	- Sensitive data exposure → review `set-body` / response-mask policies
48	- Excessive enumeration → add `<rate-limit-by-key>` policy
49	- Inactive APIs → deprecate or revoke product visibility
50	Verify: re-scan finding clears within 24 hours of APIM policy publish.
51	5. Wire detections to your SOC — Defender alerts flow into Defender for Cloud, Defender XDR,
52	and Sentinel via the Microsoft Defender XDR connector. Build automation rules for
53	unauthenticated-access spikes and credential-stuffing patterns.
54	*Verify: a test malicious request (e.g. enumeration burst from one IP) generates an alert
55	within 15 minutes in the Defender XDR portal.*
56	6. Iterate monthly — New APIs appear; old ones go inactive. Re-run the triage table monthly
57	so risk priority stays current.
58
59	## Guardrails
60	- APIM-only scope. Defender for APIs only sees APIs fronted by Azure API Management. APIs
61	on Application Gateway, Front Door, or direct App Service exposure are invisible to it -
62	route them through APIM or use other controls.
63	- Detection is not protection. Defender finds the problem; APIM policies fix it. Treat
64	Defender as your prioritisation engine, not your security perimeter.
65	- Pricing scales with calls. High-traffic APIs (hundreds of millions of calls/month) can
66	generate significant Defender for APIs cost. Use the Azure Pricing Calculator before scaling.
67	- Sensitive-data detection is sampled. Defender inspects a percentage of API responses; do
68	not rely on it as a complete DLP control - pair with response-masking APIM policies for
69	known-sensitive fields.
70	- Onboarding changes nothing in your API. N

People who liked this also viewed

6 picks

Type