security-hardening

What this skill does

# Security Hardening

## Purpose

Proactive reduction of attack surface across infrastructure layers through systematic configuration hardening, least-privilege enforcement, and automated security controls. Applies industry-standard CIS Benchmarks and zero-trust principles to operating systems, containers, cloud configurations, networks, and databases.

## When to Use This Skill

Invoke this skill when:
- Hardening production infrastructure before deployment
- Meeting compliance requirements (SOC 2, PCI-DSS, HIPAA, FedRAMP)
- Implementing zero-trust security architecture
- Reducing container or cloud misconfiguration risks
- Preparing for security audits or penetration tests
- Automating security baseline enforcement
- Responding to vulnerability scan findings

## Hardening Layers

Security hardening applies across five infrastructure layers:

### Layer 1: Operating System (Linux)
- Kernel parameter tuning (sysctl)
- SSH configuration hardening
- User and group management
- File system permissions and mount options
- Service minimization
- SELinux/AppArmor enforcement

### Layer 2: Container
- Minimal base images (Chainguard, Distroless, Alpine)
- Non-root container execution
- Read-only root filesystems
- Seccomp and AppArmor profiles
- Resource limits and capabilities dropping
- Pod Security Standards enforcement

### Layer 3: Cloud Configuration
- IAM least privilege and MFA enforcement
- Network security groups and NACL configuration
- Encryption at rest and in transit
- Public access blocking
- Logging and monitoring enablement
- CSPM (Cloud Security Posture Management) integration

### Layer 4: Network
- Default-deny network policies
- Network segmentation and micro-segmentation
- TLS/mTLS enforcement
- Firewall rule minimization
- DNS security (DNSSEC, DNS filtering)

### Layer 5: Database
- Authentication and authorization hardening
- Connection encryption (SSL/TLS)
- Audit logging enablement
- Network isolation and access control
- Role-based permissions with least privilege

## Core Hardening Principles

### 1. Default Deny, Explicit Allow
Start with all access denied, explicitly permit only required operations. Apply default-deny firewall rules and network policies, then allow specific traffic.

### 2. Least Privilege Access
Grant minimum permissions required for operation. Use RBAC, IAM policies with specific resources, and database roles with limited permissions (no DELETE or DDL unless required).

### 3. Defense in Depth
Implement multiple overlapping security controls: network firewalls, authentication, authorization, audit logging, and encryption working together.

### 4. Minimal Attack Surface
Remove unnecessary components, services, and permissions. Use minimal container base images, disable unused services, and drop all Linux capabilities unless required.

### 5. Fail Securely
On error or misconfiguration, default to secure state. Authentication failures deny access, missing configurations use restrictive defaults, and monitoring failures trigger immediate alerts.

## Hardening Priority Framework

Prioritize hardening efforts based on exposure and data sensitivity:

### Critical Priority: Internet-Facing Systems
**Apply immediately:**
- Container hardening (minimal images, non-root, read-only)
- Network segmentation (DMZ, WAF, DDoS protection)
- TLS termination and certificate management
- Rate limiting and authentication
- Real-time monitoring and alerting

**Tools:** Trivy, Falco, ModSecurity, Cloudflare

### High Priority: Systems with Sensitive Data
**Apply before production:**
- Encryption at rest (AES-256, KMS-managed keys)
- Strict access controls (RBAC, least privilege)
- Comprehensive audit logging
- Database connection encryption
- Regular vulnerability scanning

**Tools:** Checkov, Prowler, Lynis, OpenSCAP

### Standard Priority: Internal Systems
**Apply systematically:**
- OS hardening (CIS Benchmarks)
- Service minimization
- Patch management automation
- Configuration management
- Basic monitoring

**Tools:** Ansible, Puppet, kube-bench, docker-bench-security

## CIS Benchmark Integration

CIS (Center for Internet Security) Benchmarks provide industry-standard hardening guidance.

### Automated CIS Scanning

**Docker CIS Benchmark:**
```bash
docker run --rm -it \
  --net host \
  --pid host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  docker/docker-bench-security
```

**Kubernetes CIS Benchmark:**
```bash
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench
```

**Linux CIS Benchmark:**
```bash
# Using Lynis
lynis audit system --quick

# Using OpenSCAP
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml
```

### Key CIS Controls Mapping

| CIS Control | Hardening Action | Layer |
|-------------|------------------|-------|
| 4.1 Secure Configuration | Apply hardening baselines | All layers |
| 5.1 Account Management | Enforce least privilege, MFA | OS, Cloud |
| 6.1 Access Control | RBAC, network policies | All layers |
| 8.1 Audit Log Management | Enable comprehensive logging | All layers |
| 13.1 Network Monitoring | Deploy IDS/IPS, flow logs | Network |
| 3.1 Data Protection | Enable encryption at rest/transit | Cloud, Database |

For detailed CIS control mapping, see `references/cis-benchmark-mapping.md`.

## Container Base Image Selection

Choose base images based on security requirements and compatibility needs:

| Use Case | Recommended Base | Size | CVEs | Trade-off |
|----------|------------------|------|------|-----------|
| **Production apps** | Chainguard Images | ~10MB | 0 | Minimal, zero CVEs |
| **Minimal Linux** | Alpine | ~5MB | Few | Small, auditable |
| **Compatibility** | Distroless | ~20MB | Few | No shell, harder debug |
| **Debugging** | Debian slim | ~80MB | More | Has debugging tools |
| **Legacy apps** | Ubuntu | ~100MB | Many | Full compatibility |

**Production recommendation:** Chainguard Images or Distroless for production, Alpine for development.

## Verification and Auditing

Hardening must be verified continuously, not just at implementation.

### Automated Security Scanning

**Container vulnerability scanning:**
```bash
# Trivy: Comprehensive vulnerability and misconfiguration scanner
trivy image --severity HIGH,CRITICAL myapp:latest

# Grype: Fast vulnerability scanner
grype myapp:latest
```

**Infrastructure as Code scanning:**
```bash
# Checkov: Multi-cloud IaC scanner
checkov -d terraform/ --framework terraform

# Terrascan: Policy-as-code scanner
terrascan scan -t terraform -d terraform/
```

**Kubernetes security scanning:**
```bash
# Kubesec: Security risk analysis
kubesec scan k8s/deployment.yaml

# Polaris: Configuration validation
polaris audit --format=pretty

# Trivy K8s scanning
trivy k8s --report summary cluster
```

**Cloud security posture:**
```bash
# Prowler: AWS security assessment
prowler aws --services s3 iam ec2

# ScoutSuite: Multi-cloud security audit
scout aws --services s3 iam ec2
```

### Continuous Verification Pipeline

Integrate security scanning into CI/CD:

```yaml
# GitHub Actions example
name: Security Hardening Verification

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 0 * * *'  # Daily scan

jobs:
  container-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:test .

      - name: Scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:test'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # Fail on findings

  iac-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan IaC with Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          so