| name | deploying-software-defined-perimeter |
| description | Deploy a Software-Defined Perimeter using the CSA v2.0 specification with Single Packet Authorization, mutual TLS, and SDP controller/gateway configuration to enforce zero trust network access. |
| domain | cybersecurity |
| subdomain | zero-trust-architecture |
| tags | ["zero-trust","sdp","software-defined-perimeter","network-access","ztna"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["PR.AA-01","PR.AA-05","PR.IR-01","GV.PO-01"] |
Deploying Software-Defined Perimeter
Prerequisites
- Understanding of zero trust principles (NIST SP 800-207)
- Knowledge of CSA Software-Defined Perimeter specification
- Familiarity with PKI and mutual TLS authentication
- Experience with network security architecture
Overview
A Software-Defined Perimeter (SDP) implements zero trust by creating a dynamically provisioned, identity-centric perimeter around individual resources. Defined by the Cloud Security Alliance (CSA), SDP makes application infrastructure invisible to unauthorized users through a "dark cloud" approach where services are hidden until authenticated and authorized. Unlike traditional VPN, SDP establishes one-to-one encrypted connections between verified users and specific applications.
This skill covers deploying SDP using the CSA v2.0 specification, implementing Single Packet Authorization (SPA), configuring the SDP controller and gateway, and validating the deployment against NIST SP 800-207 requirements.
When to Use
- When deploying or configuring deploying software defined perimeter capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Common Misconfigurations & Verification
- Gateway not actually default-drop: if the Accepting Host firewall still permits inbound on the service port, or the app server is reachable on a second NIC/public IP that bypasses the gateway, the dark-cloud property is gone. Confirm the
iptables/security-group default policy is DROP for all inbound except the SPA listener.
- SPA disabled or pre-shared key reused: running the gateway with SPA off, or sharing one HMAC/HOTP key across all clients, lets anyone who captured a packet replay it. Use per-client SPA keys and enable replay protection.
- mTLS client-auth optional: a gateway that requests but does not require a client certificate falls back to server-only TLS, so any user reaches the app after SPA. Set client-cert verification to mandatory and enable OCSP/CRL revocation.
- No revocation checking: a stolen or revoked device certificate still works until CRL/OCSP is enforced.
Verify: from an unauthorized host run nmap -sS -p- <gateway-ip> with no SPA sent and confirm ALL ports show filtered (gateway invisible). Attempt a TLS connection with no client cert and confirm rejection; replay a captured SPA packet and confirm denial; test a revoked cert and confirm access fails, with each attempt logged to the SIEM.
