mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-07-13 19:05:17 +03:00
Initial commit - 611 cybersecurity skills across all subdomains
This commit is contained in:
@@ -0,0 +1,331 @@
|
||||
---
|
||||
name: implementing-microsegmentation-with-guardicore
|
||||
description: >
|
||||
Implementing microsegmentation using Akamai Guardicore Segmentation to map application
|
||||
dependencies, create granular network policies, visualize east-west traffic flows,
|
||||
and enforce least-privilege communication between workloads across data centers and cloud.
|
||||
domain: cybersecurity
|
||||
subdomain: zero-trust-architecture
|
||||
tags: [microsegmentation, guardicore, akamai, zero-trust, east-west-traffic, network-segmentation, lateral-movement]
|
||||
version: "1.0"
|
||||
author: mahipal
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Implementing Microsegmentation with Guardicore
|
||||
|
||||
## When to Use
|
||||
|
||||
- When implementing east-west traffic controls to prevent lateral movement within data centers
|
||||
- When needing application-level visibility into network communication patterns before writing segmentation policies
|
||||
- When segmenting workloads across heterogeneous environments (VMs, containers, bare metal, cloud)
|
||||
- When compliance frameworks (PCI DSS, HIPAA) require network segmentation validation
|
||||
- When deploying zero trust at the network layer with process-level granularity
|
||||
|
||||
**Do not use** for perimeter-only security (use traditional firewalls), for environments with fewer than 50 workloads where VLANs/security groups suffice, or when network team lacks capacity for ongoing policy management.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Akamai Guardicore Segmentation license (Enterprise or Premium)
|
||||
- Guardicore Management Server deployed (on-prem or SaaS)
|
||||
- Agent deployment access to target workloads (Linux, Windows, Kubernetes)
|
||||
- Network visibility: SPAN/TAP ports or VPC flow logs for agentless collection
|
||||
- Application owner engagement for dependency validation
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Deploy Guardicore Agents on Workloads
|
||||
|
||||
Install agents to collect process-level network communication data.
|
||||
|
||||
```bash
|
||||
# Linux agent installation
|
||||
curl -sSL https://management.guardicore.com/api/v3.0/agents/download/linux \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-o gc-agent-installer.sh
|
||||
chmod +x gc-agent-installer.sh
|
||||
sudo ./gc-agent-installer.sh \
|
||||
--management-url=https://management.guardicore.com \
|
||||
--site-id=datacenter-east \
|
||||
--label="web-tier"
|
||||
|
||||
# Windows agent installation (PowerShell)
|
||||
# Invoke-WebRequest -Uri "https://management.guardicore.com/api/v3.0/agents/download/windows" `
|
||||
# -Headers @{"Authorization"="Bearer $GC_API_TOKEN"} `
|
||||
# -OutFile gc-agent-installer.exe
|
||||
# Start-Process -FilePath .\gc-agent-installer.exe `
|
||||
# -ArgumentList "--management-url=https://management.guardicore.com","--site-id=datacenter-east" `
|
||||
# -Wait
|
||||
|
||||
# Kubernetes DaemonSet deployment
|
||||
cat > gc-daemonset.yaml << 'EOF'
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
name: guardicore-agent
|
||||
namespace: guardicore
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: gc-agent
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: gc-agent
|
||||
spec:
|
||||
hostNetwork: true
|
||||
hostPID: true
|
||||
containers:
|
||||
- name: gc-agent
|
||||
image: guardicore/agent:latest
|
||||
securityContext:
|
||||
privileged: true
|
||||
env:
|
||||
- name: GC_MANAGEMENT_URL
|
||||
value: "https://management.guardicore.com"
|
||||
- name: GC_API_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: gc-credentials
|
||||
key: api-key
|
||||
volumeMounts:
|
||||
- mountPath: /host
|
||||
name: host-root
|
||||
volumes:
|
||||
- name: host-root
|
||||
hostPath:
|
||||
path: /
|
||||
EOF
|
||||
kubectl apply -f gc-daemonset.yaml
|
||||
|
||||
# Verify agent enrollment
|
||||
curl -s "https://management.guardicore.com/api/v3.0/agents?status=active" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" | python3 -m json.tool
|
||||
```
|
||||
|
||||
### Step 2: Map Application Dependencies with Reveal
|
||||
|
||||
Use Guardicore Reveal to discover and visualize application communication patterns.
|
||||
|
||||
```bash
|
||||
# Query discovered application flows via API
|
||||
curl -s "https://management.guardicore.com/api/v3.0/connections" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{
|
||||
"time_range": {"from": "2026-02-17T00:00:00Z", "to": "2026-02-24T00:00:00Z"},
|
||||
"filter": {
|
||||
"source_label": "web-tier",
|
||||
"destination_label": "app-tier"
|
||||
},
|
||||
"aggregation": "process",
|
||||
"limit": 1000
|
||||
}' | python3 -m json.tool
|
||||
|
||||
# Export application dependency map
|
||||
curl -s "https://management.guardicore.com/api/v3.0/maps/export" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{
|
||||
"format": "json",
|
||||
"labels": ["web-tier", "app-tier", "db-tier"],
|
||||
"time_range": "7d"
|
||||
}' -o app-dependency-map.json
|
||||
|
||||
# Typical discovery findings:
|
||||
# web-tier -> app-tier: TCP 8080, 8443 (expected)
|
||||
# app-tier -> db-tier: TCP 5432, 3306 (expected)
|
||||
# web-tier -> db-tier: TCP 5432 (UNEXPECTED - should be blocked)
|
||||
# app-tier -> internet: TCP 443 (verify if needed)
|
||||
```
|
||||
|
||||
### Step 3: Create Segmentation Labels and Policies
|
||||
|
||||
Define labels and create ring-fence policies around applications.
|
||||
|
||||
```bash
|
||||
# Create labels for application tiers
|
||||
curl -X POST "https://management.guardicore.com/api/v3.0/labels" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "PCI-CDE",
|
||||
"description": "Cardholder Data Environment workloads",
|
||||
"criteria": {"ip_ranges": ["10.10.0.0/16"]},
|
||||
"color": "#FF0000"
|
||||
}'
|
||||
|
||||
# Create segmentation policy: Allow web-to-app communication
|
||||
curl -X POST "https://management.guardicore.com/api/v3.0/policies" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "Web-to-App Allowed",
|
||||
"action": "ALLOW",
|
||||
"priority": 100,
|
||||
"source": {"labels": ["web-tier"]},
|
||||
"destination": {"labels": ["app-tier"]},
|
||||
"services": [
|
||||
{"protocol": "TCP", "port": 8080},
|
||||
{"protocol": "TCP", "port": 8443}
|
||||
],
|
||||
"log": true,
|
||||
"enabled": true,
|
||||
"section": "application-segmentation"
|
||||
}'
|
||||
|
||||
# Create deny policy: Block web-to-database direct access
|
||||
curl -X POST "https://management.guardicore.com/api/v3.0/policies" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "Block Web-to-DB Direct",
|
||||
"action": "DENY",
|
||||
"priority": 200,
|
||||
"source": {"labels": ["web-tier"]},
|
||||
"destination": {"labels": ["db-tier"]},
|
||||
"services": [{"protocol": "TCP", "port_range": "1-65535"}],
|
||||
"log": true,
|
||||
"alert": true,
|
||||
"enabled": true
|
||||
}'
|
||||
|
||||
# Create ring-fence policy for PCI CDE
|
||||
curl -X POST "https://management.guardicore.com/api/v3.0/policies" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"name": "PCI CDE Ring Fence",
|
||||
"action": "DENY",
|
||||
"priority": 50,
|
||||
"source": {"labels": ["!PCI-CDE"]},
|
||||
"destination": {"labels": ["PCI-CDE"]},
|
||||
"services": [{"protocol": "TCP", "port_range": "1-65535"}],
|
||||
"log": true,
|
||||
"alert": true,
|
||||
"enabled": true
|
||||
}'
|
||||
```
|
||||
|
||||
### Step 4: Test Policies in Reveal Mode Before Enforcement
|
||||
|
||||
Simulate policy enforcement without blocking traffic.
|
||||
|
||||
```bash
|
||||
# Enable reveal mode (log-only) for new policies
|
||||
curl -X PATCH "https://management.guardicore.com/api/v3.0/policies/POLICY_ID" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{"enforcement_mode": "REVEAL"}'
|
||||
|
||||
# Check what would be blocked in reveal mode
|
||||
curl -s "https://management.guardicore.com/api/v3.0/violations" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{
|
||||
"time_range": "24h",
|
||||
"policy_id": "POLICY_ID",
|
||||
"limit": 100
|
||||
}' | python3 -c "
|
||||
import json, sys
|
||||
data = json.load(sys.stdin)
|
||||
for v in data.get('violations', []):
|
||||
print(f\"{v['source_ip']}:{v['source_process']} -> {v['dest_ip']}:{v['dest_port']} [{v['action']}]\")
|
||||
"
|
||||
|
||||
# After validation, switch to enforcement
|
||||
curl -X PATCH "https://management.guardicore.com/api/v3.0/policies/POLICY_ID" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{"enforcement_mode": "ENFORCE"}'
|
||||
```
|
||||
|
||||
### Step 5: Monitor and Respond to Policy Violations
|
||||
|
||||
Set up alerting and continuous monitoring for segmentation violations.
|
||||
|
||||
```bash
|
||||
# Configure SIEM integration for policy violations
|
||||
curl -X POST "https://management.guardicore.com/api/v3.0/integrations/syslog" \
|
||||
-H "Authorization: Bearer ${GC_API_TOKEN}" \
|
||||
-d '{
|
||||
"name": "Splunk SIEM",
|
||||
"host": "splunk-syslog.company.com",
|
||||
"port": 514,
|
||||
"protocol": "TCP",
|
||||
"format": "CEF",
|
||||
"events": ["policy_violation", "agent_status", "deception_alert"]
|
||||
}'
|
||||
|
||||
# Splunk query for microsegmentation violations
|
||||
# index=guardicore sourcetype=guardicore:policy
|
||||
# | where action="DENY" AND enforcement_mode="ENFORCE"
|
||||
# | stats count by src_ip, dst_ip, dst_port, policy_name
|
||||
# | sort -count
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| Microsegmentation | Network security technique creating granular security zones around individual workloads or applications to control east-west traffic |
|
||||
| Reveal Mode | Guardicore's simulation mode that logs policy decisions without enforcing them, allowing validation before blocking |
|
||||
| Ring-Fence Policy | Isolation policy that restricts all traffic into or out of a defined group of assets (e.g., PCI CDE) |
|
||||
| Application Dependency Map | Visual representation of discovered network communication patterns between workloads showing processes, ports, and protocols |
|
||||
| East-West Traffic | Network traffic flowing laterally between workloads within a data center, as opposed to north-south traffic crossing the perimeter |
|
||||
| Process-Level Visibility | Guardicore's ability to identify which process on a workload initiated or received a network connection |
|
||||
|
||||
## Tools & Systems
|
||||
|
||||
- **Akamai Guardicore Segmentation**: Agent-based microsegmentation platform with application visualization and policy enforcement
|
||||
- **Guardicore Reveal**: Network visualization engine mapping application dependencies across hybrid environments
|
||||
- **Guardicore Centra**: Management console for policy creation, monitoring, and incident investigation
|
||||
- **Guardicore Agents**: Lightweight agents deployed on workloads collecting process-level network telemetry
|
||||
- **Guardicore Insight**: Analytics engine for compliance reporting and segmentation effectiveness measurement
|
||||
|
||||
## Common Scenarios
|
||||
|
||||
### Scenario: PCI DSS Microsegmentation for E-Commerce Platform
|
||||
|
||||
**Context**: An e-commerce company must isolate its Cardholder Data Environment (CDE) from the rest of the corporate network for PCI DSS compliance. The CDE spans 200 servers across on-prem and AWS.
|
||||
|
||||
**Approach**:
|
||||
1. Deploy Guardicore agents on all 200 CDE servers and 300 non-CDE servers
|
||||
2. Run Reveal for 2 weeks to map all communication patterns into and out of the CDE
|
||||
3. Identify and remediate unexpected flows (e.g., dev servers connecting to production CDE)
|
||||
4. Create ring-fence policy blocking all non-CDE to CDE traffic by default
|
||||
5. Create explicit allow policies for validated CDE communication paths
|
||||
6. Test in Reveal mode for 1 week, validate no legitimate traffic blocked
|
||||
7. Switch to enforcement mode and monitor for violations
|
||||
8. Generate PCI DSS segmentation validation report showing enforced controls
|
||||
|
||||
**Pitfalls**: Agent deployment on legacy systems (Windows Server 2012) may require manual installation. Ring-fence policies must account for management traffic (monitoring, patching, backup). Start with broad allow rules and progressively tighten. Application owners must validate dependency maps before enforcement.
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
Microsegmentation Deployment Report
|
||||
==================================================
|
||||
Organization: E-Commerce Corp
|
||||
Report Date: 2026-02-23
|
||||
|
||||
AGENT DEPLOYMENT:
|
||||
Total workloads: 500
|
||||
Agents installed: 487 (97.4%)
|
||||
Agents active: 482 (98.9%)
|
||||
Agentless (flow logs): 13
|
||||
|
||||
POLICY COVERAGE:
|
||||
Total policies: 45
|
||||
Allow rules: 38
|
||||
Deny rules: 7
|
||||
Reveal mode: 3
|
||||
Enforced: 42
|
||||
|
||||
TRAFFIC ANALYSIS (7 days):
|
||||
Total flows observed: 2,456,789
|
||||
Flows matching allow: 2,441,234 (99.4%)
|
||||
Flows matching deny: 15,555 (0.6%)
|
||||
Unclassified flows: 0
|
||||
|
||||
PCI CDE ISOLATION:
|
||||
CDE workloads: 200
|
||||
Ring-fence violations: 0 (last 30 days)
|
||||
Authorized CDE entry points: 4
|
||||
Lateral movement paths blocked: 95%
|
||||
```
|
||||
Reference in New Issue
Block a user