SSP 5.1: DFW 1-2-3-4, a guided path to microsegmentation
This is part 2 of my SSP series. In the first post I explained what SSP is. SSP 5.1 arrived together with VCF 9.0, and one of its big additions is DFW 1-2-3-4. It’s a feature of Security Intelligence, available through SSP 5.1.
What is DFW 1-2-3-4?
It’s a guided workflow that takes you through segmentation in stages, following the lateral traffic patterns in your environment. Under the hood an analytics engine discovers communication patterns, identifies unprotected traffic and recommends firewall rules.
The idea is to prevent you from jumping straight to application-level microsegmentation without the visibility you need. Instead you start with the quick wins and work towards the application level.
The four stages
1. Security Segmentation Assessment & Report
You generate a Security Segmentation Report that shows your current posture. The segmentation score re-calibrates automatically when your environment changes, so you can track progress over time and show it to management or auditors.
2. Infrastructure (shared) services
Protect DNS, NTP, Syslog, SNMP, DHCP and LDAP first. The workflow discovers these services for you, or you can feed your known endpoints through a CSV file. Locking down DNS alone already removes some of the most common command and control and exfiltration paths.
3. Environment (zone) segmentation
Define zones like Dev and Production. You can import the metadata from a CSV, for example exported from a CMDB like ServiceNow or from vCenter. The workflow assigns the security tags, creates default zone-level rules and monitors for traffic leaking between zones.
4. Application microsegmentation
This stage has three steps:
- 4a. Map workloads to applications, again via CSV. The workflow auto-tags them and creates the application groups.
- 4b. Define ring-fencing for each application. The system recommends rules that only allow communication between the permitted entities.
- 4c. Continuously monitor the applications, before and after publishing rules, and fine-tune the rules between the application tiers.
My take
VMware says a typical rollout can be done in as little as a few weeks. I’d treat that as a best case, because the CSV input (zones, workload-to-application mapping) depends on how good your CMDB data is. But the structure alone is useful, especially in brownfield environments where nobody knows exactly what talks to what.
