Lateral Security for VMware Cloud Foundation with VMware vDefend

VCF 5.2architectvcdxsecurityautomationPages 862-937

Delivers centralized enterprise-grade security services for VMware Cloud Foundation using VMware vDefend. Activates vDefend Distributed Firewall (DFW) to secure both VCF management and VI workload domains (with NSX on DVPGs feature from NSX 4.2 to protect VLAN-backed vSphere distributed port groups). Optionally deploys NSX Application Platform (NAPP) and Security Intelligence to provide flow visibility and policy recommendations.

Key Components: NSX, vDefend, SDDC Manager, vCenter, ESXi, Tanzu

Logical Design: vDefend is built into the VCF private cloud fabric. Each NSX Manager (distinct per workload domain — management domain has its own, VI WLDs use their own or shared NSX) enforces DFW for its scope. Single VCF instance with single AZ is in scope. Federation across WLDs is NOT in scope. Optional NAPP is deployed on a dedicated Tanzu Kubernetes Cluster managed by the management domain vSphere Supervisor.

Design Decisions

Implementation

Operations

VCDX Defense

Quiz (15)

Flashcards (15)

63 design decisions

DD-ID	Decision	Quality
SEC-NAPP-001	Deploy NAPP only for workload domains	Manageability
Decision: Deploy NAPP only for workload domains Rationale: Management domain policies are prescriptive and documented in this VVS Implication: No significant trade-offs identified for this decision. Component: NAPP
SEC-NAPP-002	Use TKG Cluster on vSphere Supervisor	Manageability
Decision: Use TKG Cluster on vSphere Supervisor Rationale: Fully supported; lifecycle managed by vCenter Implication: TKG clusters must be compatible with NAPP and vCenter Component: NAPP
SEC-NAPP-003	Dedicated TKG Cluster per NAPP instance	Manageability
Decision: Dedicated TKG Cluster per NAPP instance Rationale: NAPP requires dedicated Kubernetes cluster Implication: Each TKG reserves CPU/memory/storage in management domain Component: NAPP
SEC-NAPP-004	Manage all WLD NAPP instances in management domain Supervisor	Manageability
Decision: Manage all WLD NAPP instances in management domain Supervisor Rationale: Single Supervisor reduces resource consumption; NAPP linked to NSX cluster and should be deployed close Implication: Management domain cluster must be sized for multiple NAPP instances Component: NAPP
SEC-NAPP-005	Use NSX Application Platform Automation Appliance	Manageability
Decision: Use NSX Application Platform Automation Appliance Rationale: Automates deployment/configuration with prescriptive design (3 routed networks, HA-Proxy) Implication: Max 5 NAPP instances; beyond that requires manual deployment Component: NAPP
SEC-NAPP-006	Deploy NAPP with 4 worker nodes; scale-out after sizing	Manageability
Decision: Deploy NAPP with 4 worker nodes; scale-out after sizing Rationale: Minimum for flow metrics; use sizing tool after 1 week of data Implication: Worker count may need to grow Component: NAPP
SEC-NAPP-007	Use vSAN Default Storage Policy	Manageability
Decision: Use vSAN Default Storage Policy Rationale: Optimized via thin provisioning Implication: Must not modify the Default VM Storage Policy post-deployment Component: NAPP
SEC-VIWLD-001	Segment workloads into zones for policy enforcement	Manageability
Decision: Segment workloads into zones for policy enforcement Rationale: Separate prod/non-prod for broad-based policy Implication: Broad zones can expose many workloads to unintended connections Component: VIWLD
SEC-VIWLD-002	Static membership groups for dedicated CIDR/IP subnets	Manageability
Decision: Static membership groups for dedicated CIDR/IP subnets Rationale: Efficient at scale Implication: Not resilient to network architecture changes; must maintain Component: VIWLD
SEC-VIWLD-003	Dynamic membership groups for zones, app boundaries, tiers	Manageability
Decision: Dynamic membership groups for zones, app boundaries, tiers Rationale: Flexible; independent of network architecture Implication: Automation must tag new workloads Component: VIWLD
SEC-VIWLD-004	IP-based groups for external inventory	Manageability
Decision: IP-based groups for external inventory Rationale: Simplifies policy to external/physical servers Implication: No significant trade-offs identified for this decision. Component: VIWLD
SEC-VIWLD-005	Limit nested group levels to 3 or less	Manageability
Decision: Limit nested group levels to 3 or less Rationale: Reduces complexity and compute burden Implication: No significant trade-offs identified for this decision. Component: VIWLD
SEC-VIWLD-006	Leverage 'Applied To' at policy/rule	Security
Decision: Leverage 'Applied To' at policy/rule Rationale: Prevents large firewall tables on unrelated vNICs Implication: IP-based and AD groups cannot be used in Applied To Component: VIWLD
SEC-VIWLD-007	Common services policy in Infrastructure category	Manageability
Decision: Common services policy in Infrastructure category Rationale: AD/DNS/patching/SIEM need own sections Implication: RFC1918 may be used when endpoints unknown Component: VIWLD
SEC-VIWLD-008	Block insecure protocols in Infrastructure category	Manageability
Decision: Block insecure protocols in Infrastructure category Rationale: Prevent exploitation of older/unpatched OS Implication: Must configure exceptions Component: VIWLD
SEC-VIWLD-009	Inter-zone exception rules in Environment category	Manageability
Decision: Inter-zone exception rules in Environment category Rationale: Allow specific inter-zone traffic; document for compliance Implication: Creates potential for lateral movement if misconfigured Component: VIWLD
SEC-VIWLD-010	Block inter-zone traffic by default	Manageability
Decision: Block inter-zone traffic by default Rationale: Prevent lateral movement from compromised workload Implication: May block legitimate traffic Component: VIWLD
SEC-VIWLD-011	Inter-app policy between applications	Manageability
Decision: Inter-app policy between applications Rationale: Secures app-to-app communication Implication: Does not prevent lateral movement within application Component: VIWLD
SEC-VIWLD-012	Micro-segmentation per application	Manageability
Decision: Micro-segmentation per application Rationale: Zero-trust model Implication: More complex configuration Component: VIWLD
SEC-VIWLD-013	Block insecure protocols in Application category	Manageability
Decision: Block insecure protocols in Application category Rationale: Block Telnet, FTP, SMBv1, LLMNR, etc. Implication: Can block legitimate traffic if exceptions not configured Component: VIWLD
SEC-VIWLD-014	L7 rule services coupled with correlating context profile	Manageability
Decision: L7 rule services coupled with correlating context profile Rationale: Optimized DPI Implication: More rules required Component: VIWLD
SEC-VIWLD-015	Separate L7 rules by service + context profile	Manageability
Decision: Separate L7 rules by service + context profile Rationale: Optimized DPI Implication: More rules required Component: VIWLD
SEC-VIWLD-016	Use Security Intelligence for policy recommendations	Security
Decision: Use Security Intelligence for policy recommendations Rationale: Avoid cumbersome manual analysis Implication: Requires NAPP + Security Intelligence Component: VIWLD
SEC-MWLD-001	Target VDS prepared for NSX (for DVPGs)	Manageability
Decision: Target VDS prepared for NSX (for DVPGs) Rationale: NSX on DVPGs requires NSX-prepared VDS for VLAN TZ Implication: Multi-VDS profiles require manual VLAN TZ config Component: MWLD
SEC-MWLD-002	Verify DFW policy before enabling NSX on DVPGs	Manageability
Decision: Verify DFW policy before enabling NSX on DVPGs Rationale: DFW immediately affects workloads post-activation Implication: Manual policy verification required Component: MWLD
SEC-MWLD-003	Activate NSX on DVPGs on management domain cluster	Manageability
Decision: Activate NSX on DVPGs on management domain cluster Rationale: Enable DFW on VCF management VM DVPG Implication: Existing DFW policy takes immediate effect Component: MWLD
SEC-MWLD-004	Remove SDDC Manager, vCenters, VI WLD NSX Managers from User Excluded Group	Manageability
Decision: Remove SDDC Manager, vCenters, VI WLD NSX Managers from User Excluded Group Rationale: Enforce DFW on management components Implication: Manual removal required Component: MWLD
SEC-MWLD-005	Leave management domain NSX Manager in User Excluded Group	Manageability
Decision: Leave management domain NSX Manager in User Excluded Group Rationale: Avoid self-lockout from misconfiguration Implication: Management domain NSX Manager cannot be DFW-protected Component: MWLD
SEC-MWLD-006	Leave management domain NSX Edge Nodes in System Excluded VMs	Manageability
Decision: Leave management domain NSX Edge Nodes in System Excluded VMs Rationale: Cannot be changed Implication: Cannot protect Edge Node management traffic with DFW Component: MWLD
SEC-MWLD-007	Use default Security and IP Discovery segment profiles for DVPGs	Security
Decision: Use default Security and IP Discovery segment profiles for DVPGs Rationale: Defaults applied post-activation; tuned for DVPGs Implication: Manual change implementation required Component: MWLD
SEC-MWLD-008	Segment VCF into macro-security zones per NSX domain	Security
Decision: Segment VCF into macro-security zones per NSX domain Rationale: Align with natural boundaries; rapid DFW policy Implication: Must create NSX security groups in advance Component: MWLD
SEC-MWLD-009	Per-management-component groups with dynamic membership on NSX Tags	ManageabilitySecurity
Decision: Per-management-component groups with dynamic membership on NSX Tags Rationale: Flexible dynamic security posture Implication: Tags lost on vCenter RDU; must re-tag Component: MWLD
SEC-MWLD-010	Per-vCenter SSO domain groups using dynamic VM name criteria	Manageability
Decision: Per-vCenter SSO domain groups using dynamic VM name criteria Rationale: Auto-apply to new WLD vCenters Implication: Requires naming convention Component: MWLD
SEC-MWLD-011	Aria Suite group by AVN network dynamic criteria	Manageability
Decision: Aria Suite group by AVN network dynamic criteria Rationale: Dynamically includes Aria VMs Implication: Manual group creation Component: MWLD
SEC-MWLD-012	Static IP-based groups for ESXi mgmt, Edge Nodes, IP storage	Manageability
Decision: Static IP-based groups for ESXi mgmt, Edge Nodes, IP storage Rationale: Not part of DFW scope but need traffic allowance Implication: Manual group creation Component: MWLD
SEC-MWLD-013	Use entire dedicated CIDR (including future) for IP groups	Manageability
Decision: Use entire dedicated CIDR (including future) for IP groups Rationale: Easier LCM on host/WLD/Edge commissioning Implication: VCF IP schema must be architected in advance Component: MWLD
SEC-MWLD-014	Nested parent group per WLD (vCenter + NSX Mgrs + ESXi + Edge + storage)	Manageability
Decision: Nested parent group per WLD (vCenter + NSX Mgrs + ESXi + Edge + storage) Rationale: Optimizes DFW policy publishing Implication: More groups to manage Component: MWLD
SEC-MWLD-015	Tag-based groups for Supervisor/TKG/HA-Proxy	Security
Decision: Tag-based groups for Supervisor/TKG/HA-Proxy Rationale: Dynamic security posture Implication: Tags must be applied in advance Component: MWLD
SEC-MWLD-016	Nested group: Supervisor + TKG + HA-Proxy	Manageability
Decision: Nested group: Supervisor + TKG + HA-Proxy Rationale: Optimizes policy publishing Implication: More groups to manage Component: MWLD
SEC-MWLD-018	Group via VCF Mgmt DVPG dynamic criteria	Manageability
Decision: Group via VCF Mgmt DVPG dynamic criteria Rationale: Auto-includes new VCF mgmt VMs Implication: More groups to manage Component: MWLD
SEC-MWLD-019	Top-level nested group for all VCF mgmt components	Manageability
Decision: Top-level nested group for all VCF mgmt components Rationale: Single reference in Applied To Implication: More groups to manage Component: MWLD
SEC-MWLD-020	Per-infrastructure-service IP/CIDR groups	Manageability
Decision: Per-infrastructure-service IP/CIDR groups Rationale: Infrastructure services are outside VCF Implication: More groups to manage Component: MWLD
SEC-MWLD-021	Configure DFW Infrastructure category policy for VCF	Manageability
Decision: Configure DFW Infrastructure category policy for VCF Rationale: Systematic arrangement of policies Implication: Activating NSX DVPGs enforces across all DVPG ports; DENY rules can cause connectivity loss Component: MWLD
SEC-MWLD-022	Applied To = VCF top-level nested group	Manageability
Decision: Applied To = VCF top-level nested group Rationale: Auto-apply to new VCF VMs; policy-level Applied To overrides rule-level Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-023	Allow Bastion (TCP/22, 443, ICMP, RDP if needed) to VCF mgmt	Manageability
Decision: Allow Bastion (TCP/22, 443, ICMP, RDP if needed) to VCF mgmt Rationale: Admin access from bastion Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-024	Allow VCF mgmt → infra services (DNS 53, NTP 123, DHCP 67, SSH 22, FTP 21, SMTP 25/587)	Manageability
Decision: Allow VCF mgmt → infra services (DNS 53, NTP 123, DHCP 67, SSH 22, FTP 21, SMTP 25/587) Rationale: Shared services access Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-025	Allow VCF mgmt → Microsoft AD (LDAP 389, 636; Kerberos 88; TCP/3268, 3269)	Security
Decision: Allow VCF mgmt → Microsoft AD (LDAP 389, 636; Kerberos 88; TCP/3268, 3269) Rationale: AD authentication Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-026	Allow VCF mgmt → depot.broadcom.com (HTTPS)	Manageability
Decision: Allow VCF mgmt → depot.broadcom.com (HTTPS) Rationale: Upgrade/patch binaries Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-027	Allow 3rd-party automation tools (TCP/22, 443, ICMP)	Manageability
Decision: Allow 3rd-party automation tools (TCP/22, 443, ICMP) Rationale: Integration with external tools Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-028	Configure Environment category policy for VCF management	Manageability
Decision: Configure Environment category policy for VCF management Rationale: Systematic policy arrangement Implication: NSX DVPGs enforces on all DVPG ports Component: MWLD
SEC-MWLD-029	Allow NSX Manager → SDDC Manager (TCP/22, 443)	Manageability
Decision: Allow NSX Manager → SDDC Manager (TCP/22, 443) Rationale: NSX Manager lifecycle managed by SDDC Manager Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-030	Allow SDDC Manager → VCF instance (TCP/5480, ICMP)	Manageability
Decision: Allow SDDC Manager → VCF instance (TCP/5480, ICMP) Rationale: Mgmt interface and connectivity tests Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-031	Allow vCenter ELM traffic (TCP/443, 389, 636, 2012, 2020, 8084, ICMP)	Manageability
Decision: Allow vCenter ELM traffic (TCP/443, 389, 636, 2012, 2020, 8084, ICMP) Rationale: vCenter Enhanced Linked Mode Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-032	Allow vCenter RDU traffic (TCP/5480, 5432)	Manageability
Decision: Allow vCenter RDU traffic (TCP/5480, 5432) Rationale: Reduced Downtime Upgrade Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-033	Block insecure protocols (RDP, SMBv1)	Security
Decision: Block insecure protocols (RDP, SMBv1) Rationale: Security hardening Implication: No significant trade-offs identified for this decision. Component: MWLD
SEC-MWLD-034	Aria Suite Environment category policies	Manageability
Decision: Aria Suite Environment category policies Rationale: Aria traffic on NSX VLAN/Overlay segments Implication: Single rule for all Aria internal traffic is suboptimal for micro-seg Component: MWLD
SEC-MWLD-039	vSphere Supervisor + NAPP Environment category policies	Manageability
Decision: vSphere Supervisor + NAPP Environment category policies Rationale: Supervisor deployed on DVPGs by Automation Appliance Implication: Default drop rule with logging Component: MWLD
SEC-MWLD-044	Application category per-WLD policies (NSX Manager, vCenter, ESXi comms with specific ports)	Manageability
Decision: Application category per-WLD policies (NSX Manager, vCenter, ESXi comms with specific ports) Rationale: Granular per-WLD protection Implication: NSX Managers in User Excluded Group so rules don't apply to them Component: MWLD
SEC-LCM-001	SDDC Manager for NSX LCM	Manageability
Decision: SDDC Manager for NSX LCM Rationale: Manages product binaries and NSX upgrades Implication: No significant trade-offs identified for this decision. Component: LCM
SEC-LCM-002	Deploy NSX Upgrade Coordinator before NAPP upgrade	Manageability
Decision: Deploy NSX Upgrade Coordinator before NAPP upgrade Rationale: Orchestrates upgrade steps Implication: Per-NSX-instance Upgrade Coordinator Component: LCM
SEC-LCM-003	vSphere Client for Supervisor LCM	Manageability
Decision: vSphere Client for Supervisor LCM Rationale: Not integrated with SDDC Manager Implication: Manual deployment/patching/upgrades Component: LCM
SEC-LCM-004	kubectl for TKG cluster LCM	Manageability
Decision: kubectl for TKG cluster LCM Rationale: Not integrated with SDDC Manager Implication: No significant trade-offs identified for this decision. Component: LCM
SEC-LCM-005	Ops practice for host/Edge/WLD commissioning	Manageability
Decision: Ops practice for host/Edge/WLD commissioning Rationale: ESXi, Edge, WLD groups must be updated before commissioning Implication: Runbook/automation required; vCenter RDU loses tags → re-tag required Component: LCM

Prerequisites

VCF 5.2+ with healthy management domain and optional VI WLDs
vDefend Firewall license
Completed P&P Workbook including NAPP sizing if applicable
DNS forward/reverse for NAPP Automation Appliance and cluster
Stages
1. Plan and prepare VCF environment
2. (Optional) Deploy NSX Application Platform via Automation Appliance
3. (Optional) Enable Security Intelligence and configure flow collection
4. Configure VI workload domain security (DFW policies + Security Intelligence recommendations)

Implementation Procedure

Implementation

Automated configuration for management domain security (NSX on DVPGs, DFW policies, remove from User Excluded Group)

Dfw Rule Configuration

Applied ToVCF01 (top-level nested group at policy level — takes precedence over rule-level)

Malware FeedsMalicious IP Feeds enabled by default for greenfield with DFW rules in Infrastructure category

Infrastructure Category Example

NameSourceDestinationServiceAction

Bastion Zone to VCFBASTIONVCF01HTTPS/SSH/ICMP/RDPAllow

VCF to DNSVCF01DNS_SVCDNS-TCP/DNS-UDPAllow
VCF to NTPVCF01NTP_SVCNTPAllow
VCF to ADVCF01AD_SVCLDAP/LDAPS/Kerberos/TCP 3268,3269Allow
BackupVCF01BACKUP_SERVERSICMP/HTTPS/FTP/SSHAllow
Broadcom DepotVCF01depot.broadcom.comHTTPSAllow
3rd Party ToolsTOOLSVCF01HTTPS/SSH/ICMPAllow
User Excluded Group Operations
Remove
SDDC Manager
All vCenter Servers
VI workload domain NSX Managers
Leave
Management domain NSX Manager appliances

Automation

Terraform Provider plugin (open-source) to automate management domain DFW config and application security for VI workload domains.

Day-2 Operations Tasks

Operations

As needed

Operational Verification

As needed

Certificate Management

As needed

NSX certificate management via standard VCF processes; NAPP certificate management via Kubernetes ingress/HA-Proxy setup

As needed

Logging Guidance

As needed

Disable logging for broad-based allow-all rules (reduces noise)

As needed

Lifecycle Management

As needed

NSX upgrades via SDDC Manager; NAPP upgrades via NSX Upgrade Coordinator; Supervisor LCM manual via vSphere Client; TKG via kubectl. DFW rules and gro

As needed

Monitoring Points

Verify NSX Manager health
Verify DFW is realized on prepared hosts
Verify NAPP pods are healthy (kubectl)
Verify Security Intelligence is collecting flows

Troubleshooting

Log granular rules for troubleshooting (SEC-VIWLD-023)

Cause:

Fix:

Likely Panelist Questions

Q: Why did you choose this architecture?

See design decisions for rationale

Failure Scenarios

ANY/ANY/ALLOW default during migration (low risk of outages) vs. DENY default (true zero-trust)

Impact:

Mitigation:

Tag-based dynamic groups (flexible) vs. IP-based static groups (resilient to tag loss like vCenter RDU)

Impact:

Mitigation:

Failing to re-tag vCenter after Reduced Downtime Upgrade (RDU) — policy will not apply to new VM

Impact:

Mitigation:

Site Protection and Disaster Recovery VVS: DFW policy replication considerations

Impact:

Mitigation:

Misconfigured DENY in Infrastructure category → widespread connectivity loss; always verify in monitor mode

Impact:

Mitigation:

Trade-off Analysis

Trade-Offs Analysis

Chosen:

Justification:

Macro-segmentation (fast to implement, easy to maintain) vs. micro-segmentation (zero-trust but complex)

Chosen:

Justification:

Quiz — Lateral Security with vDefend

0/15

What NSX 4.2 feature enables vDefend DFW on VMs connected to vSphere VLAN distributed port groups?

NSX Federation
NSX on DVPGs
NSX Gateway Firewall
NSX Distributed IDS

NSX on DVPGs (NSX 4.2) enables DFW protection on VMs in vSphere VLAN DVPGs for VCF management domain.

In what order are DFW policy categories evaluated?

Application → Environment → Infrastructure → Emergency → Ethernet
Ethernet → Emergency → Infrastructure → Environment → Application
Emergency → Ethernet → Infrastructure → Application → Environment
Infrastructure → Environment → Application → Emergency → Ethernet

Evaluation is top-down: Ethernet → Emergency → Infrastructure → Environment → Application.

Per SEC-MWLD-004, which mgmt components are removed from the DFW User Excluded Group?

All mgmt VMs including mgmt NSX Manager
SDDC Manager, vCenter Servers, VI WLD NSX Managers only
Only vCenter Servers
NSX Edge Nodes

SDDC Manager, vCenters, and VI WLD NSX Managers are removed; mgmt domain NSX Manager (SEC-MWLD-005) and NSX Edge Nodes (SEC-MWLD-006) stay excluded.

Why must the management domain NSX Manager remain in the User Excluded Group?

It does not support DFW
To prevent self-lockout from policy misconfiguration
Licensing constraint
Performance reasons

Keeping mgmt NSX Manager in the User Excluded Group ensures DFW misconfiguration cannot lock out access to the mgmt plane.

NSX Application Platform minimum worker node count is:

SEC-NAPP-006: minimum 4 workers; scale out based on flow ingestion.

Each NAPP worker node requires:

8 vCPU / 32 GB
16 vCPU / 64 GB
32 vCPU / 128 GB
4 vCPU / 16 GB

Per Table 637: workers require 16 vCPU, 64 GB RAM, 64 GB storage each (100% reserved in production).

What is the 1-to-1 relationship in NAPP architecture?

NAPP to vCenter
NAPP to NSX Manager cluster
NAPP to VI workload domain
NAPP to TKG cluster

One NAPP instance maps to one NSX Manager cluster (per VCF 5.2/NSX 4.2).

What is the maximum number of NAPP instances per NAPP Automation Appliance?

3
5
8
Unlimited

SEC-NAPP-005: maximum 5 NAPP instances per Automation Appliance; more requires manual deployment.

When a vCenter undergoes Reduced Downtime Upgrade (RDU), what happens to NSX tags?

Preserved on new VM
Lost — must be re-applied
Copied to a backup tag
Automatically re-applied by SDDC Manager

SEC-LCM-009: tags are lost in RDU; new VM must be re-tagged to maintain DFW policy coverage.

Q10

Which groups CANNOT be used in the 'Applied To' field?

VM name groups
Tag-based groups
IP-based and AD groups
Segment-based groups

SEC-VIWLD-006: IP-based and AD groups cannot be used in Applied To; use dynamic object groups instead.

Q11

Security Intelligence recommendations are published in which DFW category?

Infrastructure
Environment
Application
Emergency

Per SEC-VIWLD-022: Security Intelligence recommendations publish into the Application category to secure specific applications.

Q12

What license add-on is REQUIRED for this validated solution?

vDefend Firewall
vDefend Firewall with ATP
NSX Enterprise Plus
NSX Data Center

vDefend Firewall add-on includes DFW, Gateway FW, Security Intelligence, and Container Security with Antrea. ATP adds IDPS/Malware/NTA/NDR optionally.

Q13

Which is the correct Environment category rule for vCenter ELM?

TCP/22, 80
TCP/443, 389, 636, 2012, 2020, 8084, ICMP
TCP/902 only
UDP/53 only

SEC-MWLD-031: vCenter ELM requires TCP/443, 389 (LDAP), 636 (LDAPS), 2012 (RPC), 2020 (vSphere Auth), 8084 (vSphere LCM), and ICMP.

Q14

For management domain grouping, what criterion is used for Aria Suite VMs?

NSX tags
Dynamic membership based on AVN networks
Static IP addresses
VM folder

SEC-MWLD-011: dynamic membership on AVN networks auto-includes all Aria VMs as they're deployed.

Q15

Which L7 best practice should be avoided?

Separate rule per protocol with matching context profile
Service=ANY with a specific context profile
Using HTTP service with HTTP context profile
Matching service port to context profile

Avoid service=ANY with context profile — it sends unnecessary packets to DPI engine and is suboptimal.

Flashcards — Lateral Security with vDefend

Card 1 of 15

What does vDefend DFW provide?

Complete L2-L7 visibility and enforcement with automated policy delivery for VCF private cloud workloads. Enforced on every vNIC; policy follows VM during vMotion.

Labs

Enable NSX on DVPGs and Protect VCF Management Domain

Activate NSX on DVPGs on the mgmt domain cluster, create macro-segmentation groups, apply Infrastructure and Environment DFW policies, and remove SDDC Manager/vCenters/VI NSX Managers from User Excluded Group.

Starting State: VCF 5.2 mgmt domain healthy; vDefend Firewall licensed; P&P Workbook completed; mgmt VMs identified; NSX-prepared VDS.

Deploy NSX Application Platform and Enable Security Intelligence

Deploy NAPP via NSX Application Platform Automation Appliance, integrate with VI WLD NSX Manager, and enable Security Intelligence for flow visibility.

Starting State: vSphere Supervisor enabled on mgmt domain cluster with TKG; HA-Proxy or NSX ALB for ingress; 3 routed networks; DNS records for NAPP FQDNs; vDefend Firewall license.

Micro-segmentation of a 3-Tier Application

Design and implement micro-segmentation for a Web/App/DB application using dynamic tag-based groups, Application category policy, and Layer 7 rules.

Starting State: VI WLD DFW active with Infrastructure and Environment categories configured; 3-tier app deployed (Web-VM, App-VM, DB-VM); vendor documentation with port requirements.

Mark complete