Skip to content

Plan: Align Defender Findings with Azure Defender Severity + Prod/Non-Prod Split

Created: 2026-02-18 Completed: 2026-02-18 Status: Complete

Context

Our Jira tracking has 3 severity tiers (P1/Medium/Low) based on our own assessment, but Defender for Cloud uses 4 tiers (Critical/High/Medium/Low). The current Jira categories are significantly misaligned — items we categorized as Low or Medium are actually Critical in Defender (e.g., AAD-only auth, storage public access, shared key access). Additionally, items marked “Done” in Jira still appear active in Defender, suggesting partial fixes. Since the security score is based on Defender’s assessment, we need to realign.

The user also wants a prod vs non-prod split so remediation can be prioritized (prod-first waves).


Step 1: Pull Live Defender Data via az CLI

Run az security assessment list to get every unhealthy finding with:

  • Recommendation title
  • Defender severity (Critical/High/Medium/Low)
  • Affected resource name + resource group
  • Status (Unhealthy/NotApplicable)

Save output to security/findings-2026-02-18.json for reference.

Parse the output to build a mapping: recommendation title → Defender severity → [affected resources].


Step 2: Create “High” Severity Epic

We’re missing a “High” tier. Create:

EpicSummaryPriorityLabels
NEWDefender - HighHighDefender, defender-high

Updated Epic structure becomes:

  • DEVOPS-82: Defender - P1 (Critical) → rename to “Defender - Critical” for consistency
  • NEW: Defender - High
  • DEVOPS-83: Defender - Medium (keep)
  • DEVOPS-84: Defender - Low (keep)
  • DEVOPS-85: Defender - Non-Issue (keep)
  • DEVOPS-86: Defender - Won’t Do (keep)

Step 3: Add Prod/Non-Prod Labels

Classify each affected resource using naming convention:

  • prod: names containing prod, prodwest, sharsprod
  • non-prod: names containing nonprod, dev, uat, qa, training, regression, developeraccess
  • ambiguous: flag for user confirmation

Add labels to Jira issues:

  • env-prod — finding affects at least one prod resource
  • env-nonprod — finding affects at least one non-prod resource
  • Issues affecting both environments get both labels

Step 4: Re-triage All Existing Issues

Using the az CLI data, update every existing Jira issue:

  1. Change severity to match Defender’s actual rating:
    • Update Epic Link (parent) to the matching severity Epic
    • Update priority to match
    • Update severity label (defender-critical, defender-high, defender-medium, defender-low)
  2. Add env labels (env-prod, env-nonprod)
  3. Reopen “Done” items that are still Unhealthy in Defender — transition back to “To Do” with a comment explaining it’s still active

Known re-categorizations from the Defender screenshot:

  • DEVOPS-25 (AAD-only auth): Medium → Critical
  • DEVOPS-26 (prevent shared key): Low → Critical
  • DEVOPS-28 (public access disallowed): Done/Low → reopen as Critical
  • DEVOPS-34 (machine vuln findings): Done/Low → reopen, verify severity

Step 5: Create New Jira Issues for Untracked Findings

Cross-reference az CLI findings against existing Jira tickets. For any new finding not yet tracked, create a Jira Task under the appropriate severity Epic with:

  • Defender label + severity label + env label(s)
  • Description including affected resources and Defender recommendation details
  • Priority matching the Epic

Step 6: Update Process Documentation

security/defender-process.md — Update to reflect 3 severity tiers:

EpicSeveritySLAUse For
Defender - HighHigh1 weekMatches Defender High (includes Critical)
Defender - MediumMedium2 weeksMatches Defender Medium
Defender - LowLow1-2 sprintsMatches Defender Low

Add:

  • Severity now directly maps to Defender’s risk level (no more custom assessment)
  • Environment labels section (env-prod, env-nonprod)
  • Wave prioritization strategy
  • Updated JQL filters for env-based queries

Step 7: Update Register

security/defender-register.md — Restructure to match new severity tiers:

  • Add “High” section
  • Move items to correct severity based on Defender data
  • Add environment column to tables
  • Update summary counts
  • Add new JQL filters for env-based queries
  • Mark reopened items with note

Step 8: Wave Prioritization Summary

Document recommended execution waves:

WaveScopePriority
1High + prodImmediate
2High + non-prod, Medium + prodNext sprint
3Medium + non-prod, Low + prodFollowing sprint
4Low + non-prodBacklog

Execution Order

#ActionDepends On
1Pull az security assessment list
2Create “High” Epic in Jira
3Parse findings → build severity + resource mappingStep 1
4Classify resources as prod/non-prod, flag ambiguousStep 3
5Present ambiguous resources for user confirmationStep 4
6Re-triage existing issues (severity + env labels)Steps 2, 3, 5
7Reopen “Done” items still active in DefenderStep 3
8Create new issues for untracked findingsSteps 2, 3, 5
9Update defender-process.mdStep 2
10Update defender-register.mdSteps 6, 7, 8

Steps 1 and 2 run in parallel. Steps 3-5 are sequential. Steps 6, 7, 8 can run in parallel after step 5.


Files Modified

  • security/defender-process.md — Add High tier, env labels, wave strategy
  • security/defender-register.md — Restructure with correct severities, env column
  • security/findings-2026-02-18.json — New: raw az CLI output for reference

Verification

  1. az security assessment list unhealthy count matches open Jira tickets
  2. Every Jira issue severity label matches Defender’s actual severity
  3. Every Jira issue has at least one env label (env-prod or env-nonprod)
  4. No “Done” items in Jira that are still “Unhealthy” in Defender
  5. JQL: project = DEVOPS AND labels = Defender AND labels = env-prod AND parent = DEVOPS-82 returns High+prod items

Email Cross-Reference

30 Defender “attack path” emails found in Outlook 05_Reference folder (Jan 27 - Feb 15, 2026). All are the same alert type: “Internet exposed Azure VM with high severity vulnerabilities” — an Azure VM reachable from the internet with high severity vulns allowing RCE. These relate to DEVOPS-35 (NSG ports), DEVOPS-36 (Windows security config), DEVOPS-42 (SQL Server on machines vulns). The volume (~30 alerts in 3 weeks) underscores the urgency of the VM-related findings.


Results (2026-02-18)

Jira Changes Made

ActionCountDetails
Epic renamed1DEVOPS-82: “Defender - P1 (Critical)” → “Defender - High”
Epic closed1DEVOPS-109: redundant High epic
Issues re-triaged17Moved to correct Defender severity Epic
Done items reopened9Still Unhealthy in Defender, transitioned back to To Do
Epic Links fixed9Used customfield_10007 for reopened items
New issues created42DEVOPS-110 through DEVOPS-151 (23 High + 19 Medium)
Env labels addedallenv-prod and/or env-nonprod on every active issue

Final Jira State

CategoryEpicOpenClosedTotal
HighDEVOPS-8234034
MediumDEVOPS-8339039
LowDEVOPS-8417522
Total90595
  • Wave 1 (High + prod): 27 items ready for immediate prioritization
  • 86 of 90 open items have env labels (3 “not found” items + DEVOPS-58 fixed = all labeled)
  • 4 confirmed Done items match Defender (no longer Unhealthy)
  • 3 items to investigate (DEVOPS-30, 40, 41 — not found in current Defender data)

Documentation Updated

  • security/defender-process.md — 3-tier severity, risk labels, env labels, wave strategy, updated JQL
  • security/defender-register.md — Complete rewrite with correct severities, env column, all new issues
  • security/defender-guide.md — NEW: comprehensive 9-section how-to guide for the team
  • security/findings-2026-02-18.json — Parsed Defender data (2,449 assessments → 271 recommendations)
  • security/parse_defender.py — Reusable script for monthly intake