security-hardening

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:

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:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Linux CIS Benchmark:

# 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:

# Trivy: Comprehensive vulnerability and misconfiguration scanner
trivy image --severity HIGH,CRITICAL myapp:latest

# Grype: Fast vulnerability scanner
grype myapp:latest

Infrastructure as Code scanning:

# Checkov: Multi-cloud IaC scanner
checkov -d terraform/ --framework terraform

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

Kubernetes security scanning:

# 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:

# 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:

# 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
          sof