What is the Security Services Platform (SSP) in VMware vDefend?

When I started working with vDefend, I quickly noticed that SSP is often treated as “that thing you also have to deploy”. In reality it’s the foundation for a big part of the vDefend feature set. This is the first post in a small series about SSP. Here I explain what SSP is and what runs on it. In the next posts I’ll go through what’s new in SSP 5.1 and 5.2.

What is SSP?

SSP is a high-performance, scalable platform that runs vDefend features like the Security Segmentation Report and Score, Security Intelligence, Metrics, Network Detection and Response, Malware Prevention and Network Traffic Analysis. Think of it as a scale-out data lake that ingests network flow records and telemetry. On top of that data it gives you flow visibility, security assessment scores, policy recommendations and guided workflows.

Under the hood it’s Kubernetes. You deploy it with the SSP Installer (SSPi) appliance, and once it’s running you can follow what’s happening with plain kubectl commands. I used that in a previous post to follow an NSX onboarding.

What doesn’t run on SSP?

This one confuses people. The enforcement itself stays in NSX. Distributed Firewall, Gateway Firewall and the malware policy and service VM management are still done through the NSX API. So your firewall keeps working without SSP. What you miss is the analysis, the guided workflows and the advanced threat prevention on top of it.

Why a separate platform?

Processing flow data from a whole private cloud needs its own scalable layer, separate from the NSX management plane. SSP is a self-contained, scale-out platform with a simplified network design and streamlined lifecycle management. That makes deploying Security Intelligence, NDR and Malware Prevention a lot easier than it used to be.

Related

Resolve SSP 5.1.1 Errors During NSX Onboarding

During the deployment of SSP (Security Services Platform) 5.1.1, I ran into an issue while onboarding the NSX instance.

This error means that there is still an old SSP installation onboarded in NSX. In my lab environment this was the case and the old SSP installation got corrupted due to storage issues and could not get correctly ofboarded and decommisioned. Luckily there is a kb that can help you clean up NSX and SSP.

https://knowledge.broadcom.com/external/article/382295/offboarding-a-site-during-force-deletion.html

This kb explains that a scripts needs to be ran at SSP version 5.0 or 5.1 to get the onboarded NSX sites properly offboarded.

  1. Download the right script for the version of SSP
  2. Upload the script to the SSPi, Installer appliance of SSP.
  3. Login via ssh to the SSPi appliance as sysadmin user (for SSP 5.1) and make the script executable (chmod 777)

Next you can run the script:

Example usage:
./site-offboarding-cleanup-nsx-ssp5.1.sh [-h|--host <mgr_host_ip>] [-u|--username <username>] [-p|--password <password>]
site-offboarding-cleanup-nsx-ssp5.1.sh

./site-offboarding-cleanup-nsx-ssp5.1.sh -h 10.10.10.0 -u admin -p p@ssw0rd

After running the script the NSX site cleanup is complete, and you can go try to onboard NSX again to SSP. During the onboarding you can follow the onboarding process:

k get site -A
k describe site 098ad7b9-cdea-46b8-82a7-1f2e3d1fd366  -n nsxi-platform

When you see “OnboardingInProgress”, you just have to hold on a little bit until it says “OnboardingComplete”.

In the SSP you now shall see that NSX is correctly onboarded!