NSX Micro-Segmentation Design

Design security group taxonomy:

NSX Groups (tag-based, not IP-based):

• Group: Web-Servers — Criteria: Tag = 'tier:web' AND Tag = 'env:prod'
• Group: App-Servers — Criteria: Tag = 'tier:app' AND Tag = 'env:prod'
• Group: DB-Servers — Criteria: Tag = 'tier:db' AND Tag = 'env:prod'
• Group: Dev-All — Criteria: Tag = 'env:dev'
• Group: Mgmt-Infra — Criteria: Tag = 'tier:mgmt'
• Group: PCI-Scope — Criteria: Tag = 'compliance:pci' (VMs handling payment data)
• Group: Internet-Facing — Criteria: Tag = 'exposure:internet'

Tag assignment strategy:

• Automated: vSphere tags applied during VM provisioning (Aria Automation blueprint or SDDC Manager)
• Policy: Every VM must have at minimum: tier, env, and compliance tags
• No tag = no access (default-deny catches untagged VMs)

Design DFW rule categories and policies:

NSX DFW evaluates rules top-to-bottom across categories:

1. Ethernet (L2) → 2. Emergency → 3. Infrastructure → 4. Environment → 5. Application → Default

Category 1 — Emergency (highest priority):

Category 2 — Infrastructure:

Category 3 — Environment:

Design application-tier DFW rules:

Category 4 — Application (bulk of rules):

3-Tier Web Application:

PCI-scoped rules (stricter logging):

Default rule (last in each category):

Document rule management best practices:

1. Rule count management:

• Target: <200 rules total across all categories
• Use groups extensively (tag-based) rather than individual VM/IP rules
• Each new application: 3-5 rules (inbound, inter-tier, outbound, logging)

2. Rule lifecycle:

• New rule request: Change management approval required
• Rule review: Quarterly audit of all rules for relevance

   - Unused rule detection: NSX Flow Monitoring → rules with 0 hits in 90 days → decommission candidate

• Rule versioning: Export DFW config before every change (NSX API backup)

3. Applied-to scope:

• CRITICAL: Always set 'Applied To' on each rule or section
• Without 'Applied To': Rule is applied to EVERY vNIC in the environment (performance impact)
• Example: Web-to-App rule 'Applied To' = Group:Web-Servers + Group:App-Servers
• This pushes the rule only to hosts running those VMs, not all hosts

4. Exclusion list:

• VMs that should bypass DFW: NSX Manager, vCenter, SDDC Manager
• Reason: DFW interruption could lock out management access

   - Configure: NSX Manager UI → Security → Distributed Firewall → Exclusion List

Map east-west traffic flows:

Traffic flow diagram for 3-tier web application:

1. Client → Load Balancer (north-south, enters via Tier-0 Edge):
   - Ingress: Physical network → BGP → Tier-0 → LB VIP

• DFW enforcement: None (traffic not yet on overlay)

2. Load Balancer → Web Server (east-west within segment):

• LB distributes to web-prod-a segment VMs
• DFW: Rule A-001 allows TCP/443 from LB VIP group to Web-Servers group
• Enforcement point: DFW on destination host's dvPort (kernel module)

3. Web → App (east-west across segments):
   - Traffic: 172.16.1.x → 172.16.10.x (different segments, same Tier-1)

• Routing: Distributed Router (DR) on source host routes to App segment
• DFW: Rule A-002 allows TCP/8080 from Web-Servers to App-Servers
• Note: DR routing is in-kernel — traffic does NOT hairpin through Edge

4. App → DB (east-west across Tier-1 boundaries):
   - Traffic: 172.16.10.x → 172.16.20.x (different Tier-1 gateways)
   - Routing: Source DR → Tier-0 → Destination DR (inter-Tier-1 routing)

• DFW: Rule A-003 allows TCP/3306 from App-Servers to DB-Servers

5. DB → DB Replication (east-west within segment):
   - Traffic: 172.16.20.x → 172.16.20.y (same segment)

• No routing needed (L2 within segment)
• DFW: Rule A-004 allows TCP/3306 within DB-Servers group

Document each flow with: source, destination, port, routing path, DFW rule hit, and enforcement host.

Design Traceflow verification plan:

Traceflow: NSX built-in diagnostic tool that injects a tagged packet and traces its path through the overlay network.

Test plan:

For each test:

1. Run Traceflow in NSX Manager (Security → Traceflow)

2. Verify packet reaches intended hop (delivered or dropped at correct enforcement point)
3. Confirm DFW rule hit matches expected rule ID
4. Document any unexpected results for remediation

Design flow monitoring and logging:

1. NSX Distributed Firewall logging:

• Log level: Per-rule (not global — global logging creates excessive log volume)
• Log rules: All Emergency, Environment blocks, Application allows/blocks for PCI scope
• Do NOT log: High-frequency infrastructure rules (DNS, NTP) — creates log flood
• Log format: Syslog to centralized SIEM (Splunk, Aria Operations for Logs)
• Syslog destination: 172.16.200.10:514 (Aria Operations for Logs appliance)

2. Flow monitoring:

• IPFIX export: Enable on selected segments (not all — performance impact)
• Collector: Aria Operations for Networks (vRNI) or third-party IPFIX collector
• Use case: Discover undocumented traffic flows before tightening DFW rules
• Recommendation: Enable IPFIX for 2-4 weeks in monitoring mode before enforcing default-deny

3. NSX Intelligence (if licensed):

• Automated micro-segmentation recommendations based on observed traffic
• Visualizes all east-west flows between VMs
• Identifies VMs communicating outside their expected groups
• Use during initial deployment to refine DFW rules before enforcement

Design compliance verification:

1. SOC 2 requirements mapping:

• CC6.1 (Logical access): DFW default-deny + allow-list per application ✓
• CC6.6 (Network security): Micro-segmentation isolates PCI from non-PCI ✓
• CC7.1 (Detection): DFW logging + SIEM integration ✓
• CC7.2 (Monitoring): Flow monitoring + anomaly detection ✓

2. PCI-DSS compliance:

• Requirement 1: Firewall between PCI and non-PCI (DFW rule P-003) ✓
• Requirement 2: No default credentials (NSX admin password changed) ✓
• Requirement 10: Logging all access to PCI data (rules P-001, P-002 logged) ✓

3. Audit-ready documentation:

• Export: NSX DFW rule set as JSON/CSV (API: GET /policy/api/v1/infra/domains/default/security-policies)
• Mapping: Cross-reference each DFW rule to compliance requirement
• Review cadence: Quarterly rule review with security team
• Evidence: Traceflow results + flow monitoring exports for audit package

Create design decision D-009 — Network Security Model:

Decision: NSX Distributed Firewall with zero-trust, tag-based micro-segmentation
Alternatives:
A) Perimeter firewall only (Palo Alto / Fortinet at edge):

• Blocks north-south threats
• Cannot inspect east-west traffic between VMs on same host
• Rejected: 80% of data center traffic is east-west; perimeter-only is insufficient for SOC 2

B) Agent-based host firewall (iptables / Windows Firewall):

• Per-VM enforcement
• Difficult to manage at scale (600 VMs × individual rule sets)
• No centralized visibility or logging
• Rejected: Operational burden, no group-based policy, limited audit capability

C) NSX DFW + physical perimeter firewall (defense-in-depth):

• NSX DFW for east-west micro-segmentation
• Physical firewall for north-south inspection (IDS/IPS, SSL inspection)
• SELECTED: Best of both — DFW for internal isolation, physical for perimeter defense

Justification: NSX DFW provides kernel-level enforcement on every host without network hairpinning. Combined with physical perimeter firewall, this creates defense-in-depth aligned with zero-trust principles.

Prepare VCDX defense responses:

Challenge 1: 'How does DFW handle a rule with 10,000 VMs in the group?'
Response: DFW compiles rules into optimized filter tables per host. A group with 10,000 members is resolved once and pushed to all relevant hosts. Performance impact is minimal because the filter is evaluated per-packet at kernel level. The bottleneck would be group membership updates, not rule evaluation — membership changes trigger incremental updates, not full recompilation.

Challenge 2: 'What happens if NSX Manager goes down — do DFW rules stop working?'
Response: DFW rules are pushed to and cached on each host's kernel module. If NSX Manager becomes unavailable, existing rules continue to enforce. New rules cannot be pushed, and group membership changes are queued. VMs migrated via vMotion carry their DFW rules with them. This is a critical availability design — DFW operates independently of the management plane.

Challenge 3: 'Why tag-based groups instead of IP-based rules?'
Response: IP-based rules break when VMs get new IPs (DHCP renewal, migration, reprovisioning). Tag-based groups are dynamic — when a VM is tagged 'tier:web', it automatically joins the Web-Servers group and all applicable DFW rules apply immediately. This is essential for VCF automation where VMs are provisioned and decommissioned frequently.

Challenge 4: 'How would you implement a quarantine for a compromised VM?'
Response: Tag the VM with 'security:quarantine'. The Quarantined group in Emergency category (rule E-001) immediately drops all traffic. Because Emergency category rules evaluate first, they override all other allow rules. The VM is isolated within seconds without network changes. Forensics team can then add a targeted allow rule for their investigation tools only.

Document DFW operational procedures:

1. Day-0: Initial deployment:

• Deploy in monitor-only mode (rules set to Allow with logging)
• Enable IPFIX flow monitoring for 2-4 weeks
• Use NSX Intelligence to discover actual traffic patterns
• Build groups and rules based on observed traffic

2. Day-1: Enforcement:

   - Switch default rule from Allow → Drop (with logging)

• Validate: Traceflow for every documented flow
• Rollback plan: Revert default to Allow if critical traffic blocked
• Cutover window: Low-traffic period with full team on standby

3. Day-2: Ongoing operations:

• New application onboarding: Provide DFW rule template (3-5 rules per app)

   - Rule change: Change management process → test in dev → promote to prod

• Incident response: Quarantine procedure documented (tag + Emergency rule)
• Audit: Quarterly rule review, unused rule cleanup, compliance evidence export

4. Monitoring:

• Aria Operations for Logs: DFW log aggregation and correlation

   - Alert: >100 DFW drops/minute from production VMs → potential misconfiguration

• Dashboard: Top blocked flows, top talkers, rule hit counts

Create NSX security architecture summary diagram (text-based):

[Physical Network]
     |
     | BGP + BFD (ASN 65000 ↔ 65001)
     |
[Tier-0 Gateway] (Active-Active ECMP on 2 Edge VMs)
     |
     +--[Tier-1: Web]--[Seg: Web-Prod-A]--[DFW: A-001, A-002]
     |                  [Seg: Web-Prod-B]--[DFW: A-001, A-002]
     |
     +--[Tier-1: App]--[Seg: App-Prod]----[DFW: A-002, A-003, A-005]
     |                  [Seg: App-API]-----[DFW: A-002, A-003]
     |
     +--[Tier-1: DB]---[Seg: DB-Prod]-----[DFW: A-003, A-004]
     |                  [Seg: DB-Archive]--[DFW: A-003]
     |
     +--[Tier-1: Dev]--[Seg: Dev-General]--[DFW: V-001 (blocked from prod)]
                        [Seg: Test-QA]-----[DFW: V-001]

[DFW Category Order]: Emergency → Infrastructure → Environment → Application → Default-Deny
[Groups]: Tag-based (tier, env, compliance) — dynamic membership
[Logging]: Per-rule to Aria Operations for Logs via syslog
[Verification]: Traceflow + IPFIX flow monitoring

This diagram should be in the VCDX design document as the logical network security architecture.