VMware vDefend Security for VCF 5.x Administrator (6V0-21.25)

vDefend Architecture Overview#

vDefend consolidates NSX security features (formerly distributed across multiple products) into a unified network security platform. At its core, vDefend = NSX-T security rebranded with enhanced detection capabilities.

vDefend = NSX Security Features + Enhanced Detection:
All vDefend components (DFW, Gateway FW, IDS/IPS, NDR, NTA, Malware Prevention) operate natively within NSX infrastructure. No additional appliances required for DFW or IDS/IPS (unlike legacy firewall plugins). The architecture is purely software-defined, with kernel-level enforcement on every ESXi hypervisor.

vDefend Component Stack:

1. Distributed Firewall (DFW): Kernel-level L2-L7 stateful firewall on every ESXi host. Enforces micro-segmentation rules at the vNIC level. Inspects east-west traffic between VMs without requiring traffic hairpinning through an external appliance.

2. Gateway Firewall: Stateful inspection on NSX Edge nodes (Tier-0 and Tier-1 gateways). Protects north-south traffic entering/leaving the VCF environment. Supports URL filtering and TLS inspection for advanced threat prevention.

3. IDS/IPS: Signature-based intrusion detection and prevention. Available in Distributed mode (per-host, east-west) and Gateway mode (per-edge, north-south). Uses Broadcom Threat Intelligence Cloud for signature updates.

4. Malware Prevention: Multi-technique malware detection using ML, static analysis, and cloud-based dynamic analysis (sandboxing). Requires Guest Introspection (thin agent in VM + Service VM on each cluster).

5. Network Traffic Analysis (NTA): Flow-based analytics that discovers application communication patterns. Foundation for zero-trust micro-segmentation design. Answers: "who talks to whom?"

6. Network Detection & Response (NDR): Cloud-delivered ML-based behavioral threat detection. Correlates signals from all other vDefend components into unified attack campaigns. Maps detections to MITRE ATT&CK framework.

Key Architectural Principles:

• Hypervisor-native: All enforcement happens in the ESXi kernel, not in the guest OS. Cannot be bypassed by compromised VMs.
• Distributed: Every host is a firewall. No chokepoint, no traffic steering, no bottleneck.
• Policy follows workload: When a VM migrates (vMotion), its security policy moves with it. No reconfiguration required.

- Closed-loop security: DFW prevents → IDS/IPS detects → NTA analyzes → NDR correlates → DFW responds. Integrated feedback cycle.

VCF Integration: vDefend is managed via NSX Manager (which is part of every VCF instance). DFW rules, IDS/IPS profiles, and NTA data are all accessible from the NSX Manager UI. VCF Operations integrates vDefend alerts into the unified operations dashboard for cross-component correlation (security + performance + availability in one view).

Evolution from NSX Security:

• NSX-T 3.x: DFW and Gateway FW capabilities existed but were marketed as part of NSX. IDS/IPS was gateway-only. No NDR.
• NSX 4.x / VCF 5.2: Distributed IDS/IPS introduced. Malware Prevention with Guest Introspection added. NTA capabilities expanded.
• vDefend (VCF 9.0): All security components consolidated under the "vDefend" brand. NDR introduced as cloud-delivered service. DFW 1-2-3-4 workflow added for guided micro-segmentation. Rule Analysis for automated rule optimization.

Key Takeaways

• vDefend = DFW + Gateway FW + IDS/IPS + Malware Prevention + NTA + NDR. All components run natively within NSX infrastructure — no additional appliances for DFW/IDS.
• Hypervisor-native enforcement: DFW rules enforced at vNIC level in ESXi kernel. Cannot be bypassed by guest OS. Policy follows VM on vMotion.
• NDR is cloud-delivered (requires connectivity to Broadcom cloud). IDS/IPS and DFW work fully on-premises including air-gapped environments.

Distributed Firewall (DFW) Deep Dive#

DFW is the foundation of vDefend. Every ESXi host runs a kernel module (VSIP — vSwitch InterPosition filter) that enforces firewall rules at the vNIC level, inspecting every packet entering or leaving a VM before it hits the virtual switch.

DFW Architecture — Kernel-Level Enforcement

The DFW operates at Layer 2-7, positioned between the VM's vNIC and the vSwitch port. This position is critical: traffic is inspected BEFORE it reaches the network, making it impossible for a compromised VM to bypass the firewall. Unlike perimeter firewalls that only inspect north-south traffic, DFW inspects east-west (VM-to-VM) traffic on the same host without hairpinning to an external appliance.

Data Plane Components:

• VSIP Filter: Kernel module on each ESXi host. Processes rules per-vNIC. Stateful — tracks connection state (SYN/SYN-ACK/ACK) and allows return traffic automatically.
• Connection Table: Per-host state table tracking active connections. Default size: 512K entries (configurable). When full, new connections are dropped — monitor via esxtop or VCF Operations.
• Rule Table: Per-vNIC rule set compiled from NSX Manager policies. Rules evaluated top-to-bottom within each category. First match wins.

Control Plane:

• NSX Manager pushes compiled rule sets to each transport node (ESXi host).

- Rules are organized into Policy Categories (evaluated in order): Emergency → Infrastructure → Environment → Application → Default.

• Within each category, rules are evaluated by Section (ordered), then by Rule within each section.

DFW Rule Design Patterns

Applied-To Scope: Controls which vNICs process a rule. CRITICAL for performance:

• Applied-To = "DFW" (all vNICs): Every vNIC evaluates the rule. Expensive at scale.
• Applied-To = Security Group: Only vNICs in the group evaluate the rule. Recommended.
• Best Practice: Always scope Applied-To to the narrowest group possible.

Rule Categories — When to Use Each:

• Emergency: Block active threats immediately (highest priority). Example: quarantine compromised VM by IP.
• Infrastructure: Protect management plane (vCenter, NSX Manager, ESXi). Example: allow only admin subnet to SSH to ESXi.
• Environment: Enforce zone boundaries (Dev/Staging/Prod). Example: deny all traffic from Dev to Prod segments.

- Application: Micro-segmentation rules per application tier. Example: allow Web→App on TCP 8080, App→DB on TCP 3306.

• Default: Catch-all rule at the bottom. Typically set to "deny all" for zero-trust, or "allow all" during initial rollout.

Security Groups & Dynamic Membership:

• Static Groups: Manually assigned VMs. Simple but doesn't scale.
• Dynamic Groups: Membership based on criteria — VM name pattern, OS type, tags, segment membership. Auto-updates as VMs are created/moved/deleted.
• Tag-Based Groups: Most flexible. Apply NSX tags to VMs via automation (VCF Automation, PowerCLI, API). Tags can represent: application tier (web/app/db), environment (dev/prod), compliance zone (PCI/HIPAA), business unit.

DFW Rule Optimization

Rule Analysis (vDefend DFW 1-2-3-4): Automated rule hygiene that identifies seven optimization opportunities:

• Duplicate Rules: Identical source/destination/service/action across sections.
• Redundant Rules: Rule covered by a broader rule above it.
• Shadow Rules: Rule that can never match because a higher-priority rule catches all its traffic.
• Contradictions: Rules with conflicting actions for the same traffic match.
• Overly Permissive: Rules using "Any" for source, destination, or service.
• Consolidation: Multiple rules that could be merged using groups.
• Ineffective: Rules with zero hit count over 30+ days (candidates for removal).

DFW Performance Considerations:

• Rule Count Impact: Linear degradation with rule count per vNIC. Keep below 1,000 rules per vNIC for optimal performance.
• Connection Table: Monitor utilization. At 80%+ capacity, new connections may be delayed or dropped.
• Group Size: Dynamic groups with 10,000+ members cause membership computation overhead. Split into sub-groups.
• Logging: Enable selectively. Full logging on all rules generates massive syslog volume (200 bytes/rule/hit).

Traceflow for DFW Validation:

NSX Traceflow injects a tagged packet between two endpoints and reports: which DFW rules it matched, whether it was allowed/dropped, the path through the network. Essential for validating micro-segmentation rules before enforcement.

Exclusion List: VMs that should bypass DFW entirely (e.g., NSX Manager, backup appliances). Add via NSX Manager → Security → Distributed Firewall → Exclusion List. Use sparingly — excluded VMs have no DFW protection.

Key Takeaways

• Exam Focus:Understand that rule count matters. A rule "allow VM1 to VM2" versus "allow all prod VMs (security group) to all db VMs (security group)" are semantically identical but vastly different in scale. Design policies using security groups, not individual VM rules. This is the difference betwee
• Exam Focus:Time-based rules are useful for compliance (enforce access restrictions) and incident response (temporarily open firewall for troubleshooting, auto-close after 1 hour). Combined with logging, they provide audit trail of network access patterns.
• Log Storage Planning:Each firewall rule log entry ~200 bytes. At 10,000 packets/sec, that's 2MB/sec logs, or 172GB/day. For central syslog, ensure network bandwidth available (100Mbps recommended for large deployments). Use syslog rotation, compression, and archival to manage storage.

Gateway Firewall & North-South Security#

Gateway Firewall inspects traffic crossing Tier-0 and Tier-1 gateways. Provides N-S (north-south, ingress/egress) protection with stateful inspection and advanced threat features.

Gateway Firewall Architecture

Deployment: Gateway Firewall runs on NSX Edge nodes as part of the Tier-0 and Tier-1 gateway service routers. Unlike DFW (which is distributed across every ESXi host), Gateway FW is centralized on Edge nodes — all north-south traffic must transit through Edge nodes.

Traffic Flow: External network → Physical router → Tier-0 Gateway (Gateway FW inspects here) → Tier-1 Gateway (optional second inspection) → Overlay segment → VM.

Gateway FW vs DFW — When to Use Each:

• Gateway FW: North-south perimeter enforcement. Inspects traffic entering/leaving the VCF environment. Use for: external-facing rules (block IPs, geo-filtering, protocol restrictions), NAT-aware inspection, TLS decryption for inbound services.
• DFW: East-west micro-segmentation. Inspects traffic between VMs within the VCF environment. Use for: zero-trust policies, application tier isolation, lateral movement prevention.
• Best Practice: Use BOTH. Gateway FW as perimeter defense. DFW as internal defense. Defense in depth.

Gateway Firewall Rule Categories:

Same category structure as DFW: Emergency → Infrastructure → Environment → Application → Default. Rules applied per-gateway (Tier-0 or Tier-1). Applied-To scope is the specific gateway.

Gateway IDS/IPS:

• IDS/IPS can be enabled on Gateway Firewall rules (in addition to DFW rules).
• Gateway IDS inspects north-south traffic at the edge — catches threats at the perimeter.
• Performance consideration: IDS/IPS on Edge nodes reduces maximum throughput. Plan Edge sizing accordingly (Large Edge VM for IDS-enabled deployments).

Gateway Firewall Services:

• Stateful Inspection: Connection tracking for TCP/UDP/ICMP with session timeout management.
• URL Filtering: Category-based web filtering on Tier-1 gateways. Block access to known-malicious URLs, phishing sites, command-and-control domains.
• TLS Inspection: Decrypt and inspect HTTPS traffic at the gateway. Requires CA certificate deployment to client VMs for re-encryption. Use selectively — impacts performance and requires certificate management.
• FQDN-Based Rules: Allow/deny based on fully qualified domain name (e.g., allow .broadcom.com, deny .malware-domain.com). DNS snooping on the gateway resolves FQDNs to IPs dynamically.

Gateway Firewall Scaling:

• Each Edge node has a maximum connection table size and throughput limit.
• For high-traffic environments: deploy Edge nodes in active-active (ECMP) mode behind the Tier-0 gateway.
• IDS/IPS reduces throughput by 20-40% depending on signature count and traffic profile.
• Monitor Edge CPU and memory via VCF Operations to detect saturation.

Exam Considerations:

• Understand the difference between Gateway FW (centralized, north-south) and DFW (distributed, east-west).
• Know that Gateway IDS/IPS is supported on BOTH Tier-0 and Tier-1 gateways.
• URL filtering and TLS inspection are Gateway FW features — NOT available on DFW.
• Gateway FW rules reference the specific gateway (Tier-0 or Tier-1) as the Applied-To scope.

Key Takeaways

• Gateway FW = north-south perimeter defense on Edge nodes. DFW = east-west micro-segmentation on ESXi hosts. Use both for defense-in-depth.
• Gateway FW exclusive features: URL filtering, TLS inspection, FQDN-based rules. These are NOT available on DFW.
• Gateway IDS/IPS supported on both Tier-0 and Tier-1 gateways. Reduces Edge throughput by 20-40% — factor into Edge sizing.

IDS/IPS & Signature-Based Detection#

IDS/IPS detects and prevents attacks using threat signatures distributed by Broadcom's Threat Intelligence Cloud. vDefend supports IDS/IPS on both Distributed Firewall (east-west, per-host) and Gateway Firewall (north-south, on Edge nodes).

IDS vs IPS — Operational Modes

IDS (Intrusion Detection System): Monitor-only mode. Detects malicious traffic and generates alerts but does NOT block. Traffic continues to flow. Use during initial deployment and tuning phase.

IPS (Intrusion Prevention System): Inline enforcement mode. Detects AND blocks malicious traffic. Dropped packets logged with signature details. Use after tuning in IDS mode to avoid false-positive-induced outages.

Deployment Architecture

Distributed IDS/IPS: Runs on each ESXi host as part of the VSIP kernel module. Inspects east-west traffic between VMs. Activated per-rule in DFW policy (add IDS/IPS profile to DFW rules). Each host processes signatures locally — no traffic steering to external appliance.

Gateway IDS/IPS: Runs on NSX Edge nodes (Tier-0 and Tier-1 gateways). Inspects north-south traffic entering/leaving the VCF environment. Activated per-rule in Gateway Firewall policy. Inspects traffic at the gateway before routing to external networks.

Key Difference: Distributed IDS catches lateral movement (attacker moving between VMs inside the datacenter). Gateway IDS catches perimeter threats (external attacks entering via internet/WAN). Both are needed for defense-in-depth.

Signature Management

Signature Sources: Broadcom Threat Intelligence Cloud delivers signature updates. NSX Manager downloads signatures on a configurable schedule (default: daily check). Signatures classified by:

• CVSS Score: 0-10 severity rating. Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9).
• Attack Type: Exploit, malware, C2 (command-and-control), recon, DoS.
• Protocol: HTTP, DNS, SMB, SSH, TLS, custom protocols.

Signature Profiles: Group signatures by risk tolerance:

• Critical: Only CVSS 9.0+ signatures active. Minimal false positives. For sensitive production tiers.
• Moderate: CVSS 7.0+ active. Balanced detection/false positive ratio. Recommended default.
• Aggressive: All signatures active. Maximum detection but highest false positive rate. For high-security zones (PCI, financial).
• Custom: Administrator selects specific signatures. For tuned environments.

IDS/IPS Tuning Methodology

Phase 1 — Baseline (Days 1-30): Deploy in IDS (detect-only) mode across all segments. Monitor alerts via VCF Operations or syslog/SIEM. Identify false positives — legitimate traffic flagged as malicious.

Phase 2 — Tune (Days 30-45): Disable signatures generating false positives (whitelist by source/destination/signature ID). Adjust profiles per application tier. Create exclusions for known-good traffic patterns (e.g., vulnerability scanners, backup tools).

Phase 3 — Enforce (Day 45+): Switch from IDS to IPS mode tier-by-tier. Start with least-critical tier (dev/test). Monitor for blocked legitimate traffic. Gradually promote to production tiers.

Phase 4 — Continuous: Review new signature updates monthly. Re-tune after infrastructure changes (new applications, network redesign). Track metrics: detection rate, false positive rate, time-to-response.

Custom Signatures: Create custom IDS/IPS rules using Suricata rule syntax for organization-specific threats or zero-day patterns. Upload via NSX Manager → Security → IDS/IPS → Signatures → Custom.

Performance Impact: Distributed IDS/IPS adds CPU overhead per host (varies by signature count and traffic volume). Monitor ESXi host CPU via VCF Operations. If CPU exceeds 80% sustained, reduce signature count or scope IDS to specific segments only.

Key Takeaways

• False Positive Management:Common cause of IDS/IPS rollout failure. Strategy: (1) Deploy in monitor mode for 30 days, (2) analyze logs for repetitive false positives, (3) disable problematic signatures, (4) switch to prevention mode. Most common false positives: legitimate DNS tunneling, legacy encry

Network Detection & Response (NDR)#

NDR is ML-powered behavioral threat detection. Unlike IDS/IPS (signature-based), NDR detects novel attacks by analyzing network behavior patterns, lateral movement, and command-and-control communications. NDR fills the gap where signature-based detection fails — zero-day exploits, living-off-the-land attacks, and encrypted threat channels.

NDR Architecture

NDR operates as a cloud-delivered analytics service integrated with the vDefend platform:

Data Collection Layer:

• Network sensors on each ESXi host collect metadata (NOT full packet capture): source/destination IP, port, protocol, byte count, packet count, timing, DNS queries, TLS certificate details.
• Telemetry is encrypted and sent to Broadcom's NDR cloud analytics platform.
• No raw payload data leaves the datacenter — only metadata and flow summaries.

Analytics Engine (Cloud-Delivered):

• Aggregation Engine: Collects signals from IDS/IPS, NTA, and Malware Prevention. Combines individual alerts into correlated campaigns.

- Correlation Engine: Links related events across time, hosts, and users. Example: DNS anomaly on VM-A at T1 → unusual outbound connection from VM-A at T2 → lateral movement to VM-B at T3 → data exfiltration attempt at T4. Individual events are low-confidence; correlated campaign is high-confidence.

• Context Engine: Enriches detections with MITRE ATT&CK framework mapping. Each detection maps to specific tactics (Initial Access, Lateral Movement, Exfiltration) and techniques (T1566 Phishing, T1021 Remote Services, T1048 Exfiltration Over Alternative Protocol).

Detection Capabilities:

• Lateral Movement Detection: Identifies when an attacker pivots between VMs using legitimate protocols (RDP, SSH, WMI, SMB). Detects anomalous access patterns even when credentials are valid.
• Command & Control (C2) Detection: Identifies beaconing patterns (periodic outbound connections to external hosts), DNS tunneling, covert channels over HTTPS.
• Data Exfiltration Detection: Detects unusual data volumes leaving high-value VMs, staging behavior (data aggregation before exfiltration), encoding/compression of outbound data.
• Credential Theft Detection: Identifies Kerberoasting, pass-the-hash, and other credential harvesting techniques via network behavior patterns.

NDR Campaigns & Response

Campaign View: NDR groups related detections into "campaigns" representing a single attack lifecycle. Each campaign shows: affected VMs, timeline of events, MITRE ATT&CK mapping, confidence score (0-100%), recommended response actions.

Confidence Scoring: NDR uses ML to assign confidence scores. Low confidence (< 30%): likely benign anomaly. Medium (30-70%): requires analyst review. High (> 70%): likely malicious, recommend immediate action. Scores improve over time as the ML model learns the environment.

Integration Points:

• SIEM Integration: Forward NDR campaigns to Splunk, QRadar, Sentinel via syslog/API.
• SOAR Integration: Trigger automated playbooks (quarantine VM, block IP, notify SOC) based on campaign confidence score.
• VCF Operations: NDR alerts appear in unified VCF Operations dashboard alongside performance and availability alerts.

NDR Baseline Period: 7-14 days for initial ML model training. During baseline, expect elevated false positive rate (> 10%). After training, false positive rate should drop below 2%. Plan phased rollout: start with a canary group of VMs, validate detection quality, then expand organization-wide.

Privacy Considerations: NDR sends metadata to Broadcom cloud — NO payload data. For air-gapped environments, NDR requires network connectivity to Broadcom analytics platform. If air-gapped operation is required, NDR cannot function (IDS/IPS and DFW still work locally).

Network Traffic Analysis (NTA) & Micro-Segmentation#

NTA analyzes flows to understand application communication patterns, forming the foundation for zero-trust micro-segmentation design. NTA answers the critical question: "Who talks to whom, on which ports, and how often?"

NTA Architecture

Flow Collection: NSX distributed firewall captures flow records (NetFlow/IPFIX-style) from every vNIC. Each flow record contains: source VM, destination VM, protocol, port, byte count, packet count, timestamps. Flow data is aggregated by the NSX Manager and presented via the NSX Intelligence UI (if licensed) or exported to VCF Operations / external analytics.

Flow Visualization: NTA presents communication patterns as a flow graph showing VMs as nodes and connections as edges. Administrators can filter by: segment, security group, application tier, time range. This visualization reveals unexpected communication paths — a web server talking directly to a database server that should route through the app tier.

NTA for Micro-Segmentation Planning

The crawl-walk-run methodology for zero-trust implementation depends on NTA:

Step 1 — Discover (NTA Baseline, 2-4 weeks):

• Enable NTA flow collection across all segments.
• Allow all traffic (default allow rule) during discovery.
• NTA builds a communication matrix: which VMs talk to which VMs, on which ports.
• Identify application tiers automatically: web frontends (HTTP/HTTPS inbound), app servers (custom ports), databases (3306/5432/1433), management (SSH/RDP/SNMP).

Step 2 — Analyze (1-2 weeks):

• Export flow matrix from NTA.
• Classify flows: expected (application-required), unexpected (potential security risk), management (admin access).
• Design micro-segmentation rules based on OBSERVED traffic, not assumed traffic.
• Target 95%+ coverage: rules should account for 95% of observed flows.
• Identify flows that should NOT exist (lateral movement candidates, unencrypted sensitive data).

Step 3 — Design Rules (1-2 weeks):

• Create security groups based on NTA-discovered application topology.
• Write DFW rules: explicit allow for expected flows, implicit deny for everything else.
• Use tag-based groups for dynamic environments (VMs frequently created/destroyed).
• Scope Applied-To narrowly (per application group, not "All").

Step 4 — Test (2-4 weeks):

• Deploy rules in "Allow + Log" mode (not enforce yet).
• Monitor DFW logs for legitimate traffic that would be blocked.
• Tune rules: add missing allow rules for discovered flows.
• Validate with Traceflow: inject test packets between tiers to verify path.

Step 5 — Enforce (ongoing):

• Switch default rule from "Allow" to "Drop" per segment/tier.
• Start with least critical workloads (dev/test).
• Monitor for blocked legitimate traffic (check DFW drop logs).
• Gradually enforce across all tiers over 4-8 weeks.

Step 6 — Continuous Monitoring:

• NTA continues to analyze flows post-enforcement.
• Detect policy violations: traffic that bypasses rules or new unexpected flows.
• Alert on deviations from baseline (new communication patterns may indicate compromise or application changes).

NTA + VCF Automation Integration: In mature environments, NTA flow data feeds into VCF Automation policies. When new VMs are deployed via cloud templates, they automatically receive appropriate DFW rules based on their tags and the NTA-validated communication model. This creates a self-maintaining zero-trust environment.

Recommendation Engine: vDefend DFW 1-2-3-4 leverages NTA analytics to recommend segmentation rules automatically. The engine discovers communication patterns, identifies unprotected traffic, and suggests DFW rules — reducing manual analysis effort by 60-80% for initial micro-segmentation design.

Key Takeaways

• Exam Focus:NTA is the foundation for zero-trust micro-segmentation. Use NTA to baseline current communication, validate micro-segmentation rules, and detect policy violations. In exam, emphasize: (1) baseline first, (2) design by communication need, (3) reduce rule complexity through security groups

Malware Prevention & Zero-Trust Design#

Malware Prevention Module: Cloud-based and on-premises file inspection integrated with the vDefend platform. Malware Prevention uses a multi-technique approach combining machine learning, static analysis, dynamic analysis (sandboxing), and memory analysis.

Malware Prevention Architecture

Guest Introspection (GI): A lightweight agent (thin agent) runs inside each VM, monitoring file system, process, and registry activity. GI communicates with the Service VM (SVA — Security Virtual Appliance) on each ESXi host. The SVA performs initial file analysis and forwards suspicious files to the cloud sandbox if needed.

Detection Pipeline:

1. File Access Event: GI agent detects file write/execute in guest VM.
2. Local Cache Check: SVA checks file hash against local cache of known-good/known-bad files.
3. Static Analysis: If not cached, SVA performs static analysis (file structure, embedded strings, entropy analysis, PE header inspection).
4. Cloud Sandbox: If static analysis is inconclusive, file is sent to Broadcom cloud sandbox for dynamic analysis (execution in isolated environment, behavior monitoring, network call analysis).
5. Verdict: File classified as Clean, Malicious, or Suspicious. Verdict cached locally for future lookups.
6. Action: Based on policy — Allow, Block, or Quarantine.

Detection Techniques:

• Machine Learning: Trained models classify files based on structural features without executing them. Fast (milliseconds) but may miss novel malware.
• Static Analysis: Examines file without execution. Detects known packing, obfuscation, suspicious imports. Catches known malware variants.
• Dynamic Analysis (Sandbox): Executes file in cloud sandbox. Monitors behavior: file system changes, registry modifications, network connections, process spawning. Catches zero-day malware that evades static analysis.
• Memory Analysis: Inspects process memory for injection techniques, reflective DLL loading, shellcode patterns.

Deployment Considerations:

• SVA Sizing: One SVA per ESXi host cluster. Large (8 vCPU, 16GB RAM) for high file volume environments.
• Network: SVA requires connectivity to Broadcom cloud for sandbox analysis. Latency to cloud affects time-to-verdict for unknown files.
• Air-Gapped: Local analysis only (no cloud sandbox). Reduced detection capability for zero-day threats. ML and static analysis still functional.

Zero-Trust Security Design for VCF

Zero-trust operates on the principle "never trust, always verify." In a VCF environment, zero-trust means every network connection is authenticated, authorized, and encrypted — regardless of whether it originates inside or outside the datacenter perimeter.

Zero-Trust Architecture Pillars in VCF:

1. Micro-Segmentation (DFW): Isolate every workload. Default deny between all VMs. Explicit allow only for required communication paths.
2. Identity-Based Access: NSX security groups based on VM identity (tags, attributes), not IP addresses. IPs change; identity persists.

3. Least Privilege: Each application tier gets minimum required network access. Web tier → App tier on specific ports only. No direct Web → DB.

4. Continuous Verification: NTA monitors for deviations from approved communication patterns. IDS/IPS inspects allowed traffic for threats. NDR detects behavioral anomalies.
5. Encryption: vSAN encryption at rest, NSX IPsec for in-transit encryption between hosts.

Zero-Trust Implementation Playbook (Crawl-Walk-Run):

Crawl Phase (Weeks 1-4): Deploy DFW in monitor mode. Enable NTA flow collection. Run IDS in detection mode. Establish baseline. Zero enforcement — observe and learn.

Walk Phase (Weeks 5-12): Implement zone-based segmentation (Environment category rules). Separate Dev/Staging/Prod at network level. Deploy IDS/IPS signatures with tuned profiles. Begin application-tier micro-segmentation on non-critical workloads.

Run Phase (Weeks 13-20): Full micro-segmentation on all workloads. Default deny rule enforced. IPS in prevention mode. NDR active with automated response playbooks. Continuous NTA monitoring for policy compliance.

Common Failure Patterns:

- Jumping to "Run" without baseline → production outages from blocked legitimate traffic.
- Using IP-based rules instead of tag-based groups → rules break when VMs change IP.
- Enabling all IDS signatures simultaneously → alert fatigue from false positives.
- Not involving application teams → missing required communication paths in rules.

Key Takeaways

• Exam Focus - Zero-Trust Implementation:The key pattern is crawl-walk-run. Most organizations fail by jumping to "run" (full enforcement) without baseline. This causes production outages. Correct approach: (1) 30-day baseline with monitoring, (2) Tier-by-tier enforcement starting with least complex,

vDefend Suite Architecture — All Components Deep Dive#

vDefend represents Broadcom's consolidated security suite for VMware Cloud Foundation. It unifies multiple formerly separate security products into a single platform with integrated licensing and management.

vDefend Product Consolidation

vDefend replaces and consolidates:

- NSX Distributed Firewall (DFW) → vDefend Distributed Firewall
- NSX Gateway Firewall (GWF) → vDefend Gateway Firewall
- NSX Advanced Threat Prevention (ATP) → vDefend Advanced Threat Prevention (includes IDS/IPS, Malware Prevention, NTA, NDR)

All vDefend components run natively within the NSX infrastructure — no additional appliances required for DFW, Gateway FW, or IDS/IPS. Malware Prevention requires Guest Introspection (SVA on each cluster). NDR requires cloud connectivity.

Component Integration Architecture:

┌─────────────────────────────────────────────────┐
│                vDefend Platform                   │
│  ┌──────────────┐  ┌──────────────┐             │
│  │ DFW          │  │ Gateway FW   │  Layer 2-7   │
│  │ (E-W traffic)│  │ (N-S traffic)│  Firewalling │
│  └──────────────┘  └──────────────┘             │
│  ┌──────────────┐  ┌──────────────┐             │
│  │ IDS/IPS      │  │ Malware Prev │  Threat      │
│  │ (Signatures) │  │ (Sandbox+ML) │  Prevention  │
│  └──────────────┘  └──────────────┘             │
│  ┌──────────────┐  ┌──────────────┐             │
│  │ NTA          │  │ NDR          │  Detection & │
│  │ (Flow Analy.)│  │ (ML Behavior)│  Response    │
│  └──────────────┘  └──────────────┘             │
└─────────────────────────────────────────────────┘

Data Flow Between Components:

1. DFW/GWF → generates firewall logs (allow/deny/drop events)
2. IDS/IPS → generates signature-match alerts
3. Malware Prevention → generates file verdict events
4. NTA → generates flow baseline and anomaly alerts
5. NDR Aggregation Engine → correlates all signals into unified campaigns

All components feed telemetry to NSX Manager, which provides a unified security dashboard. NDR additionally sends encrypted metadata to Broadcom cloud for ML analysis.

Licensing Tiers

vDefend Firewall: Includes DFW + Gateway Firewall. Licensed per core. Bundled with VCF Enterprise or available as standalone add-on.

vDefend Firewall with Advanced Threat Prevention: Includes DFW + Gateway FW + IDS/IPS + Malware Prevention + NTA + NDR. Licensed per core. Requires separate ATP license on top of vDefend Firewall license.

Core Counting: vDefend licenses count physical CPU cores on ESXi hosts where vDefend features are activated. Minimum 16 cores per CPU (same as VCF base licensing).

Operational Workflow — Day 2 Security Operations

Security Operations Center (SOC) Integration:

• Tier 1 (Alert Triage): VCF Operations dashboards show DFW allow/deny trends, IDS alert volume, NDR campaign count. SOC analyst reviews high-confidence NDR campaigns first.
• Tier 2 (Investigation): Analyst uses Traceflow to validate alert, reviews NTA flow history for affected VMs, checks Malware Prevention verdicts for related files.
• Tier 3 (Response): Remediate via DFW Emergency rules (quarantine compromised VM), update IDS signatures, submit false-positive reports, update micro-segmentation rules.

Compliance Reporting: vDefend provides audit-ready reports for: DFW rule changes (who changed what, when), IDS/IPS detection history, flow analysis compliance (which VMs communicate across compliance boundaries). Maps to frameworks: PCI-DSS (network segmentation), HIPAA (access controls), SOC 2 (monitoring).

DFW Rule Engine Internals#

The Distributed Firewall rule engine is the enforcement engine for zero-trust security. Understanding its internals is critical for performance optimization and troubleshooting.

Rule Processing Pipeline

When a packet arrives at a VM's vNIC, the VSIP filter processes it through this pipeline:

1. Connection Table Lookup: Check if packet belongs to an existing tracked connection. If yes, apply the existing connection's action (fast path — bypasses rule evaluation). If no, proceed to rule evaluation (slow path).

2. Rule Evaluation (Slow Path): Evaluate rules category by category in order: Emergency → Infrastructure → Environment → Application → Default. Within each category, evaluate sections top-to-bottom. Within each section, evaluate rules top-to-bottom. First matching rule wins — no further evaluation.

3. Action Execution: Apply the matched rule's action: Allow (pass packet, create connection table entry), Drop (silently discard packet), Reject (discard + send TCP RST or ICMP unreachable to source).

4. Logging: If rule has logging enabled, write syslog entry with: rule ID, action, source/dest IP, port, protocol, timestamp.

Connection Table Architecture

The connection table is the performance-critical component:

• Default Size: 512K entries per host (configurable via advanced settings).
• Entry Lifecycle: Created on first packet of new connection. Updated with byte/packet counters. Removed on connection close (TCP FIN/RST) or timeout (TCP: 24hr, UDP: 60sec, ICMP: 10sec).

- Monitoring: esxtop → press 'n' → check connection count per vNIC. VCF Operations → Host → Network → DFW Connection Count metric.

• Saturation: When table is full (512K active connections), new connections are DROPPED. Symptom: intermittent connectivity for new connections while existing connections work fine.
• Tuning: Increase table size for high-connection hosts (load balancers, proxies). Decrease timeouts for environments with many short-lived connections.

Applied-To Optimization

Applied-To controls which hosts/vNICs evaluate a rule. This is the single most important performance lever:

Scope: "DFW" (All): Every vNIC on every host evaluates this rule. Worst performance. Use only for Emergency rules (quarantine).

Scope: Security Group: Only vNICs in the group evaluate. Recommended. Example: "Applied-To: Web-Tier-Group" — only web VMs process the rule.

Scope: Specific VM: Single VM evaluates. Most restrictive. Use for targeted rules.

Performance Impact: A host with 50 VMs and 1,000 rules Applied-To "All" processes 50,000 rule evaluations per new connection. With Applied-To scoped to groups of 10 VMs, it processes 10,000 — 5x reduction.

Rule Consolidation Strategies

1. Use Security Groups instead of individual IPs: One rule with group source/destination instead of N rules per VM pair.
2. Use service groups: Combine related ports (HTTP + HTTPS + HTTP/2) into a single service object.

3. Merge bi-directional rules: If A→B and B→A on same ports, use a single "allow" rule (stateful tracking handles return traffic automatically).

4. Eliminate duplicate/shadow rules: Use DFW Rule Analysis (1-2-3-4) to identify and remove.

Troubleshooting DFW Issues

Packet drops with no matching rule: the DFW has NO implicit deny. The last rule in the Application category is the default rule, set to ALLOW out of the box so VM-to-VM traffic is not broken during host preparation; it is configurable to Drop/Reject under Security > Distributed Firewall and cannot be deleted. If traffic is dropping with no matching rule, someone has already flipped that default to Drop — check it first.

Intermittent connectivity: Check connection table utilization. If near capacity, existing connections work but new ones fail randomly.

Rule not matching expected traffic: Verify group membership is correct (dynamic groups may have stale membership). Use Traceflow to see which rule matched. Check rule order — a broader rule higher in the list may be matching first.

High CPU on ESXi host: Check DFW rule count per vNIC (nsxcli > get firewall rules). Reduce Applied-To scope. Consider reducing IDS/IPS signature count if combined with DFW.

DFW Exclusion List Issues: VMs on the exclusion list bypass ALL DFW rules. If a VM stops being firewalled unexpectedly, check the exclusion list first.

Key Takeaways

• Exam Tip:When asked about DFW performance bottlenecks, consider: (1) rule count per vNIC, (2) Applied-To scope (avoid "All"), (3) connection table saturation, (4) group membership explosion (dynamic groups with 1000+ members). Solutions: narrow Applied-To, consolidate rules, use static groups where

Zero-Trust Migration Playbook#

Transitioning from perimeter-based to zero-trust requires phased deployment. This playbook provides a practical migration path for VCF environments using vDefend.

Pre-Migration Assessment (Week 0)

1. Inventory: Catalog all VMs, applications, and network segments in the VCF environment. Tag each VM with application role, tier, environment, and compliance zone.
2. Communication Mapping: Use NTA to discover existing communication patterns (2-4 week baseline).
3. Risk Assessment: Identify high-value assets (databases with PII, financial systems, intellectual property). These get micro-segmented first.
4. Stakeholder Alignment: Brief application teams on the migration plan. They must validate that discovered communication paths are correct and identify any seasonal or batch traffic patterns.

Phase 1 — Zone Segmentation (Weeks 1-4)

Objective: Separate major zones (Dev/Staging/Prod/Management) with DFW rules.

Implementation:

• Create environment tags: env:dev, env:staging, env:prod, env:mgmt.
• Apply tags to all VMs (manual or via VCF Automation integration).
• Create DFW rules in Environment category:

  - Allow intra-zone traffic (dev→dev, prod→prod).
  - Deny cross-zone traffic by default (dev→prod blocked).

• Explicit exceptions for required cross-zone communication (CI/CD pipeline, monitoring).
• Deploy in monitor+log mode for 1 week, then enforce.

Validation: Traceflow between zones should show deny. VCF Operations alerts should show zero blocked legitimate traffic.

Phase 2 — Application Tier Micro-Segmentation (Weeks 5-12)

Objective: Isolate application tiers (Web, App, DB) within each zone.

Implementation:

• Create application tier tags: tier:web, tier:app, tier:db, tier:mgmt-tools.
• Design tier-based rules in Application category:

  - Web→App: Allow on application ports (TCP 8080, 8443).
  - App→DB: Allow on database ports (TCP 3306, 5432, 1433).
  - Web→DB: DENY (enforce separation of concerns).
  - Mgmt→All: Allow on management ports (SSH 22, HTTPS 443, SNMP 161).
  - All→DNS/NTP: Allow infrastructure services.

• Enable IDS/IPS in detection mode on inter-tier traffic.
• Deploy per-application, starting with least critical.

Validation: Traceflow validates allowed paths. NTA confirms no unexpected flows. IDS/IPS generates baseline alert volume.

Phase 3 — Workload-Level Micro-Segmentation (Weeks 13-20)

Objective: Isolate individual workloads — each VM group gets only the access it needs.

Implementation:

• Create application-specific groups: app:payroll-web, app:payroll-api, app:payroll-db.
• Design workload-level rules:

  - payroll-web→payroll-api: Allow TCP 8443.
  - payroll-api→payroll-db: Allow TCP 5432.
  - payroll-*→anything-else: DENY.

• Switch default rule from "Allow" to "Drop" for each secured application.
• Enable IPS (prevention mode) after 30-day IDS tuning.
• Enable Malware Prevention on high-value VMs.

Phase 4 — Continuous Enforcement (Ongoing)

• NTA monitors for new/changed communication patterns.
• NDR detects behavioral anomalies and lateral movement.
• Automated response: High-confidence NDR campaigns trigger DFW Emergency quarantine rules via SOAR integration.
• Rule hygiene: Monthly review using DFW Rule Analysis. Remove unused rules, consolidate duplicates.
• Compliance reporting: Generate quarterly audit reports mapping DFW rules to compliance requirements (PCI-DSS, HIPAA).

Migration Timeline Summary:

• Small environment (< 200 VMs): 8-12 weeks
• Medium environment (200-1000 VMs): 12-20 weeks
• Large environment (> 1000 VMs): 20-30 weeks with dedicated team

Common Pitfalls:

1. Skipping the NTA baseline → designing rules based on assumptions, not facts.
2. Enforcing too quickly → production outages from blocked legitimate traffic.
3. IP-based rules → rules break when VMs migrate or change IP.
4. Ignoring application team input → missing seasonal or batch communication paths.
5. Not monitoring after enforcement → security rules become stale as applications evolve.

IDS/IPS Design & Tuning#

Intrusion Detection/Prevention is a critical layer of vDefend, providing signature-based threat detection for both east-west and north-south traffic.

IDS/IPS Design for VCF Environments

Deployment Strategy — Defense in Depth:

Layer 1 — Gateway IDS/IPS (Perimeter):

• Deploy on Tier-0 gateway rules for all inbound/outbound traffic.
• Profile: Moderate or Aggressive (depends on internet exposure).
• Purpose: Catch known threats at the boundary before they reach workloads.
• Capacity: Edge node sizing affects throughput. Large Edge VM (8 vCPU, 32GB) handles up to 10 Gbps with IDS enabled.

Layer 2 — Distributed IDS/IPS (East-West):

• Deploy on DFW rules between application tiers.
• Profile: Critical or Moderate (avoid Aggressive on high-traffic tiers).
• Purpose: Detect lateral movement — attacker already inside, moving between VMs.
• Capacity: Per-host processing. Monitor ESXi CPU impact.

Layer 3 — Application-Specific:

• Deploy custom signature profiles per application tier.
• Web tier: HTTP/TLS inspection signatures (SQL injection, XSS, path traversal).
• Database tier: SQL protocol anomaly signatures.
• Infrastructure: SSH brute-force, SNMP exploitation, management protocol abuse.

Signature Profile Design

Tiered Approach — Match profile severity to workload criticality:

Production Database Tier:

• Profile: Critical + custom SQL signatures.
• Mode: IPS (prevention) after tuning.
• Rationale: High-value data, low tolerance for compromise, narrow protocol set (easy to tune).

Production Web Tier:

• Profile: Moderate.
• Mode: IPS after 45-day tuning.
• Rationale: High attack surface (internet-facing), diverse traffic patterns require longer tuning.

Development Environment:

• Profile: Critical only.
• Mode: IDS (detect-only) permanently.
• Rationale: Frequent code changes generate false positives. Detection provides visibility without blocking developer productivity.

Management Infrastructure (vCenter, NSX, ESXi):

• Profile: Aggressive.
• Mode: IPS.
• Rationale: Management plane compromise is catastrophic. Narrow, predictable traffic patterns produce few false positives.

Tuning Deep Dive

False Positive Categories:

1. Legitimate scanning tools (vulnerability scanners, SNMP monitors) → Whitelist source IP + signature ID.
2. Legacy protocols (older TLS versions, non-standard HTTP) → Disable specific protocol anomaly signatures for affected segments.
3. Custom applications using unusual patterns (binary protocols over HTTP ports) → Create exclusion rules or custom allow signatures.
4. Backup/replication traffic (high-volume data transfer triggers DDoS signatures) → Whitelist backup server IPs for DDoS signature category.

Metrics to Track:

• True Positive Rate: % of alerts that are genuine threats. Target: > 80%.
• False Positive Rate: % of alerts that are benign. Target: < 5% after tuning.
• Mean Time to Detect (MTTD): Time from attack start to first alert. Target: < 5 minutes for known signatures.
• Signature Coverage: % of MITRE ATT&CK techniques covered. Track gaps quarterly.

Operational Procedures:

• Signature Update Review: Monthly review of new signatures before activation. Test in lab/dev first.
• Quarterly Tuning Review: Re-evaluate disabled signatures, check for new false positive patterns.

- Incident Response Integration: IDS/IPS alerts feed into SIEM/SOAR. Define playbooks for high-severity signatures (CVSS 9+): auto-quarantine → SOC notification → forensic capture → remediation.

Key Takeaways

• Exam Tip:When asked about IDS/IPS scale deployment, mention: (1) Gateway IDS for perimeter, (2) Distributed IDS for east-west, (3) Profile selection per tier, (4) False-positive tuning process, (5) Custom signatures for zero-days. Do NOT simply say "enable IPS on all rules"; that's naive and misses

Network Detection & Response (NDR) Deep Dive#

Network Detection & Response is Broadcom's cloud-delivered analytics platform integrated with vDefend. NDR provides behavioral threat detection using machine learning, complementing signature-based IDS/IPS detection.

NDR Detection Engine Architecture

The NDR detection engine uses three types of ML models:

Supervised Models: Trained on known-malicious traffic patterns (labeled datasets from Broadcom threat research). Detect known attack variants even when signatures don't exist. Updated continuously via cloud model updates.

Unsupervised Models: Learn "normal" for each environment without labeled data. Detect deviations from learned baseline. Catches zero-day attacks that don't match any known pattern. Requires 7-14 day baseline period per environment.

Deep Learning Models: Neural networks analyzing complex traffic patterns across multiple dimensions simultaneously. Detect subtle, multi-stage attacks that simpler models miss. Higher computational cost but lower false positive rate for complex scenarios.

MITRE ATT&CK Integration

Every NDR detection is mapped to the MITRE ATT&CK framework:

Initial Access (TA0001): Phishing links in email attachments, exploitation of public-facing applications.

Execution (TA0002): Remote code execution, scripting engine abuse.

Persistence (TA0003): Scheduled tasks, registry modifications for auto-start.

Lateral Movement (TA0008): RDP/SSH pivoting, SMB file sharing exploitation, WMI remote execution.

Collection (TA0009): Data staging on network shares, screen capture uploads.

Exfiltration (TA0010): Data transfer to cloud storage, DNS tunneling, HTTP/S data smuggling.

Command & Control (TA0011): Beaconing patterns, domain generation algorithms (DGA), encrypted C2 channels.

This mapping enables SOC analysts to understand attack progression and prioritize response.

Campaign Correlation Engine

NDR's primary value is correlating individual low-confidence events into high-confidence campaigns:

Example Attack Campaign:

T+0: NTA detects unusual DNS query from VM-web-01 to suspicious domain (confidence: 15%).

T+5min: IDS detects encoded PowerShell download on VM-web-01 (confidence: 40%).

T+15min: NDR detects VM-web-01 making RDP connection to VM-db-01 — first ever RDP between these VMs (confidence: 55%).

T+20min: NDR detects large data transfer from VM-db-01 to external IP (confidence: 70%).

Individual events: Low confidence, easily lost in noise.
Correlated Campaign: High confidence (85%), clear attack chain, automated MITRE mapping.

Response Actions:

• Automated: DFW Emergency rule quarantines VM-web-01 (block all traffic).
• SOC Alert: Campaign details pushed to SIEM with full timeline.
• Evidence Capture: NTA flow records preserved for forensic analysis.
• Playbook Execution: SOAR platform runs incident response procedures.

NDR Deployment Best Practices

1. Start Small: Deploy on one workload domain. Validate detection quality before expanding.
2. Tune During Baseline: Work with the SOC team during the 14-day baseline to identify expected anomalies (batch jobs, backup windows, maintenance activities).
3. Integrate Early: Connect NDR to SIEM/SOAR before going live. Ensure automated playbooks are tested.
4. Monitor Cloud Connectivity: NDR requires stable, low-latency connection to Broadcom analytics cloud. Monitor connectivity and alert on interruptions.
5. Review Campaigns Weekly: SOC analysts should review all medium+ confidence campaigns weekly. Feedback loop (confirm/dismiss) improves ML model accuracy.

Limitations:

• Requires cloud connectivity (not available in air-gapped environments).
• Encrypted payload inspection is NOT performed (only metadata analysis). End-to-end encrypted C2 channels may evade if they mimic normal traffic patterns perfectly.
• 7-14 day baseline means no meaningful detections during initial deployment period.

Key Takeaways

• Exam Tip:When designing NDR deployment, emphasize: (1) encrypted telemetry to Broadcom cloud, (2) correlation across flows/hosts/time (not just single packet detection), (3) MITRE ATT&CK mapping for standardized response, (4) integration with SIEM + SOAR for automated playbooks, (5) confidence scori

Lab Exercise: Zero-Trust Enforcement with vDefend#

Lab Exercise: Zero-Trust Enforcement with vDefend — Practical Reference

This exercise guides you through implementing a complete zero-trust micro-segmentation deployment in a Holodeck lab environment using vDefend DFW, IDS/IPS, and NTA.

Lab Prerequisites:

• VCF management domain operational with NSX configured.
• At least 6 VMs deployed across 3 application tiers: 2x Web (nginx), 2x App (tomcat), 2x DB (postgresql).
• All VMs connected to NSX overlay segments.
• VCF Operations deployed and collecting metrics.

Exercise 1 — NTA Flow Baseline (30 minutes):

1. Access NSX Manager → Plan & Troubleshoot → Traffic Analysis.
2. Enable flow collection for all workload segments.
3. Generate traffic: curl from Web VMs to App VMs (port 8080), App VMs query DB VMs (port 5432).
4. Review flow visualization — verify expected communication paths appear.
5. Identify unexpected flows (e.g., Web→DB direct communication that should not exist).

6. Export flow data for rule design.

Exercise 2 — Security Group Design (20 minutes):

1. NSX Manager → Inventory → Groups → Add Group.
2. Create dynamic groups:
   - "Web-Tier": Membership criteria = Tag equals "tier:web"
   - "App-Tier": Membership criteria = Tag equals "tier:app"
   - "DB-Tier": Membership criteria = Tag equals "tier:db"
3. Apply tags to VMs: NSX Manager → Inventory → Virtual Machines → select VM → Tags → Add.
4. Verify group membership: click each group → Members tab → confirm correct VMs listed.

Exercise 3 — DFW Rule Implementation (30 minutes):

1. NSX Manager → Security → Distributed Firewall.
2. Create new section "App-Microseg" in Application category.
3. Add rules:
   Rule 1: Source=Web-Tier, Dest=App-Tier, Service=TCP-8080, Action=Allow, Applied-To=Web-Tier,App-Tier, Log=Yes
   Rule 2: Source=App-Tier, Dest=DB-Tier, Service=TCP-5432, Action=Allow, Applied-To=App-Tier,DB-Tier, Log=Yes
   Rule 3: Source=Any, Dest=Web-Tier, Service=HTTPS, Action=Allow, Applied-To=Web-Tier, Log=Yes
   Rule 4: Source=Any, Dest=Any, Action=Drop, Applied-To=Web-Tier,App-Tier,DB-Tier, Log=Yes
4. Publish rules.
5. Validate: curl from Web VM to App VM on 8080 → should succeed.
6. Validate: curl from Web VM to DB VM on 5432 → should be BLOCKED.
7. Use Traceflow: NSX Manager → Plan & Troubleshoot → Traceflow → trace Web→DB on 5432 → verify DROP by rule 4.

Exercise 4 — IDS/IPS Deployment (20 minutes):

1. NSX Manager → Security → IDS/IPS & Malware Prevention → Settings → Enable.
2. Download latest signature bundle.
3. Create IDS profile: "Lab-Detection" with Critical + High signatures enabled.
4. Apply IDS profile to rule 1 (Web→App traffic) and rule 2 (App→DB traffic).
5. Generate test alert: use curl to send a test pattern matching a known signature (e.g., SQL injection attempt in URL parameter).
6. Verify alert appears in NSX Manager → Security → IDS/IPS → Events.

Exercise 5 — Validation & Monitoring (20 minutes):

1. VCF Operations → dashboards → verify DFW metrics (allow/drop counts, top talkers).

2. Check syslog for DFW rule hit logs — verify expected allow/drop entries.
3. Review IDS events — confirm test alert captured with correct signature details.
4. Generate compliance report from NTA showing micro-segmentation coverage.

Lab Completion Criteria:

- DFW rules enforce tier-based isolation (Web↔App↔DB allowed, Web→DB blocked).

• IDS detects simulated attack on allowed traffic paths.
• Traceflow confirms correct rule matching for both allowed and denied paths.
• VCF Operations dashboard shows DFW and IDS metrics.