mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-07-17 13:15:16 +03:00
Initial commit - 611 cybersecurity skills across all subdomains
This commit is contained in:
@@ -0,0 +1,156 @@
|
||||
# Deploying Software-Defined Perimeter
|
||||
|
||||
---
|
||||
domain: cybersecurity
|
||||
subdomain: zero-trust-architecture
|
||||
author: mahipal
|
||||
tags: [zero-trust, sdp, software-defined-perimeter, network-access, ztna]
|
||||
difficulty: advanced
|
||||
estimated_time: 4-6 hours
|
||||
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.
|
||||
|
||||
## Architecture
|
||||
|
||||
### SDP Components (CSA Specification)
|
||||
|
||||
```
|
||||
┌─────────────────────┐
|
||||
│ SDP Controller │
|
||||
│ - Authentication │
|
||||
│ - Authorization │
|
||||
│ - Policy management │
|
||||
│ - Key management │
|
||||
└──────────┬──────────┘
|
||||
│
|
||||
┌──────┴──────┐
|
||||
│ │
|
||||
v v
|
||||
┌────────┐ ┌────────────┐
|
||||
│ IH │ │ AH │
|
||||
│(Client)│ │(Gateway) │
|
||||
│ │ │ │
|
||||
│ SPA │──│ Protected │
|
||||
│ mTLS │ │ Resources │
|
||||
└────────┘ └────────────┘
|
||||
|
||||
IH = Initiating Host (User Device)
|
||||
AH = Accepting Host (Application Gateway)
|
||||
SPA = Single Packet Authorization
|
||||
```
|
||||
|
||||
### SDP Deployment Models
|
||||
1. **Client-to-Gateway**: User device connects through SDP gateway to backend applications
|
||||
2. **Client-to-Server**: Direct connection between user and application server
|
||||
3. **Server-to-Server**: Workload-to-workload communication through SDP
|
||||
4. **Gateway-to-Gateway**: Site-to-site connectivity replacing traditional VPN tunnels
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Single Packet Authorization (SPA)
|
||||
SPA is a network security mechanism where the SDP gateway drops all TCP/UDP packets by default. A cryptographically signed single packet must be sent before any connection is established. The gateway validates the SPA packet, and only then opens a temporary port for the authenticated session. This makes the gateway invisible to port scanners.
|
||||
|
||||
### Mutual TLS (mTLS)
|
||||
After SPA validation, both the client and server authenticate each other using X.509 certificates. This bidirectional authentication prevents man-in-the-middle attacks and ensures both endpoints are verified.
|
||||
|
||||
### Dynamic Provisioning
|
||||
SDP connections are provisioned on-demand based on real-time policy evaluation. No persistent network tunnels exist; each session is individually authorized and encrypted.
|
||||
|
||||
## Procedure
|
||||
|
||||
### Phase 1: SDP Controller Deployment
|
||||
|
||||
1. **Deploy SDP Controller**
|
||||
- Install SDP controller on hardened, redundant infrastructure
|
||||
- Configure PKI integration for certificate issuance
|
||||
- Set up authentication backend (LDAP, SAML, OIDC)
|
||||
- Configure policy database with application definitions
|
||||
- Enable audit logging for all controller decisions
|
||||
|
||||
2. **Configure Authentication**
|
||||
- Integrate with enterprise IdP via SAML 2.0 or OIDC
|
||||
- Configure device certificate enrollment (SCEP/EST)
|
||||
- Enable multi-factor authentication requirements
|
||||
- Set up certificate revocation checking (OCSP/CRL)
|
||||
|
||||
3. **Define Access Policies**
|
||||
- Map users/groups to authorized applications
|
||||
- Define device posture requirements per application
|
||||
- Configure contextual conditions (location, time, risk level)
|
||||
- Set session duration and re-authentication intervals
|
||||
|
||||
### Phase 2: SDP Gateway Deployment
|
||||
|
||||
4. **Deploy Accepting Hosts (Gateways)**
|
||||
- Install SDP gateway instances in front of protected applications
|
||||
- Configure default-drop firewall rules (deny all inbound)
|
||||
- Enable SPA listener on designated ports
|
||||
- Configure mTLS with controller-issued certificates
|
||||
- Set up health monitoring and failover
|
||||
|
||||
5. **Configure Application Definitions**
|
||||
- Register each protected application with the controller
|
||||
- Define backend server IPs, ports, and protocols
|
||||
- Configure load balancing for multi-instance applications
|
||||
- Set up application health checks
|
||||
|
||||
### Phase 3: Client Deployment
|
||||
|
||||
6. **Deploy Initiating Hosts (Clients)**
|
||||
- Install SDP client software on user endpoints
|
||||
- Enroll device certificates through automated provisioning
|
||||
- Configure SPA key material distribution
|
||||
- Test authentication flow: SPA → mTLS → application access
|
||||
|
||||
7. **Validate End-to-End Flow**
|
||||
- Verify SPA packets are accepted by gateway
|
||||
- Confirm mTLS handshake succeeds with valid certificates
|
||||
- Test application access through the SDP tunnel
|
||||
- Verify unauthorized access is blocked (no SPA = invisible gateway)
|
||||
|
||||
### Phase 4: Operational Validation
|
||||
|
||||
8. **Security Testing**
|
||||
- Port scan the SDP gateway to confirm invisibility (all ports show filtered/closed)
|
||||
- Attempt connection without valid SPA (must fail silently)
|
||||
- Test with revoked client certificate (must be denied)
|
||||
- Attempt lateral movement from one authorized app to another unauthorized app
|
||||
- Validate audit trail completeness
|
||||
|
||||
9. **Monitoring and Maintenance**
|
||||
- Configure SIEM integration for SDP controller and gateway logs
|
||||
- Set up alerting for failed SPA attempts and certificate errors
|
||||
- Establish certificate rotation schedule
|
||||
- Document incident response procedures for SDP events
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] SDP Controller deployed with HA and audit logging
|
||||
- [ ] IdP integration tested with SAML/OIDC and MFA
|
||||
- [ ] SDP Gateways deployed with default-drop firewall
|
||||
- [ ] SPA mechanism validated (gateway invisible to port scans)
|
||||
- [ ] mTLS established between clients and gateways
|
||||
- [ ] Access policies enforce least-privilege per user/app
|
||||
- [ ] Device certificate enrollment automated
|
||||
- [ ] Unauthorized access attempts blocked silently
|
||||
- [ ] Lateral movement between apps prevented
|
||||
- [ ] Logs streaming to SIEM with alerting configured
|
||||
- [ ] Certificate rotation and revocation procedures tested
|
||||
|
||||
## References
|
||||
|
||||
- CSA Software-Defined Perimeter Architecture Guide v3
|
||||
- CSA SDP Specification v2.0
|
||||
- NIST SP 800-207: Zero Trust Architecture
|
||||
- CISA Zero Trust Maturity Model v2.0
|
||||
- fwknop: Single Packet Authorization implementation
|
||||
Reference in New Issue
Block a user