Mejorá la seguridad de tu organización con hallazgos de evaluaciones de compromiso

Introducción

Las evaluaciones de compromiso (CA, Compromise Assessments) son herramientas críticas para descubrir amenazas que ya están dentro de tu infraestructura pero que los sistemas tradicionales de detección no identifican. Según el análisis de Kaspersky en 2025, el 71% de los incidentes afectaron a organizaciones en META (Medio Oriente, Turquía, África), y el 40.7% de los hallazgos de alta severidad surgieron de evaluaciones post-incidente, donde el equipo de respuesta actuó solo sobre un alerta específica sin explorar el resto del entorno.

En este artículo, te mostramos cómo convertir los hallazgos de una CA en acciones concretas para EKS, enfocándonos en tres familias de detección con mayor impacto: persistencia avanzada, movimiento lateral y actividad anómala de procesos. Además, te damos una guía paso a paso para integrar estas mejoras en tu pipeline de seguridad, validando cada paso con comandos y configuraciones exactas.

Qué es y para qué sirve

Una evaluación de compromiso es un análisis independiente que combina:

• Inteligencia de amenazas (incluyendo fuentes darknet).
• Escaneo forense de endpoints (memoria, disco, registros).
• Revisión sistemática de logs de seguridad y tráfico de red.
• Investigación inicial de respuesta a incidentes (IR) si se detecta actividad maliciosa.

El objetivo no es solo detectar malware obvio, sino identificar amenazas persistentes avanzadas (APTs) que usan técnicas de evasión como:

• Persistencia múltiple: cron jobs, WMI subscriptions, claves de registro modificadas.
• Movimiento lateral: credenciales robadas, exploits de Kerberos, Pass-the-Hash.
• Técnicas de evasión: living-off-the-land binaries (LOLBins), fileless malware.

Según los datos de Kaspersky 2025, el 52% de los incidentes de alta severidad se detectan después de 90 días, lo que aumenta el riesgo de exfiltración de datos y daño reputacional. Las evaluaciones proactivas (como auditorías generales o checks de due diligence en fusiones) reducen la probabilidad de hallazgos de alta severidad en un 36%, mientras que las reactivas (post-incidente) tienen un 28% de hallazgos de alta severidad.

Prerequisitos

Para aplicar las mejoras en EKS que mencionamos en esta guía, necesitás:

• Rol IAM con AmazonEKSClusterPolicy, AmazonEKSVPCResourceController, y permisos para crear namespaces y pods.
• Acceso a la consola de AWS con permisos para configurar AWS GuardDuty, Amazon Detective, y AWS Config.

• Si tu clúster EKS usa AWS Fargate, asegurate de que los namespaces críticos (como kube-system) estén excluidos de la configuración de Fargate para evitar falsos positivos en detección.
• Verificá que tu VPC tenga flujos de tráfico al servicio de AWS API (sts.amazonaws.com, eks.amazonaws.com) para que las herramientas de auditoría se comuniquen correctamente.

Guía paso a paso

Paso 1: Auditar el clúster EKS con Kube-bench

# Instalá Kube-bench
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.8.0/kube-bench_0.8.0_linux_amd64.deb -o kube-bench.deb
sudo dpkg -i kube-bench.deb

# Ejecutá el escaneo en modo "master" (control plane) y "node" (nodos)
kube-bench master --benchmark cis-1.8 --json | jq '.[] | select(.status != "PASS")' > findings_kube_bench.json
kube-bench node --benchmark cis-1.8 --json | jq '.[] | select(.status != "PASS")' >> findings_kube_bench.json

• Archivo findings_kube_bench.json con hallazgos no conformes (ej.: políticas de red en kube-system con permisos 0644).
• Ejemplo de hallazgo crítico:

  {
    "test_number": "1.1.1",
    "test_desc": "Ensure that the --allow-privileged argument is set to false",
    "status": "FAIL",
    "remediation": "Edit the kube-apiserver manifest file /etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the below parameter. --allow-privileged=false"
  }
  

1. Para el hallazgo 1.1.1, editá el manifiesto del kube-apiserver en los nodos masters:

   # /etc/kubernetes/manifests/kube-apiserver.yaml
   spec:
     containers:
     - command:
       - kube-apiserver
       - --allow-privileged=false
   

1. Reiniciá el kubelet en los nodos afectados:

   sudo systemctl restart kubelet
   

Paso 2: Implementar políticas de red con Calico para bloquear movimiento lateral

# Instalá Calico en EKS (usando eksctl)
eksctl create addon --name vpc-cni --cluster <NOMBRE-CLUSTER> --service-account-role-arn <ARN-ROL-IAM> --version v1.12.5-eksbuild.1
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

# Creá una política para bloquear tráfico entre namespaces no autorizados
cat <<EOF | kubectl apply -f -
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace-traffic
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          access-allowed: "true"
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          access-allowed: "true"
EOF

• Los pods solo pueden comunicarse si sus namespaces tienen la etiqueta access-allowed: "true".
• Verificá con:

  kubectl get networkpolicy
  kubectl describe networkpolicy deny-cross-namespace-traffic
  

• Si los pods pierden conectividad, revisá las etiquetas en los namespaces:

  kubectl label namespace default access-allowed=true
  kubectl label namespace kube-system access-allowed=true
  

Paso 3: Detectar actividad anómala en tiempo real con Falco

# Instalá Falco con Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco -n falco --create-namespace --set falco.driver.kind=ebpf

# Creá reglas personalizadas para EKS (ej.: detectar pods con permisos de root)
cat <<EOF | kubectl apply -f -
apiVersion: falco.org/v1alpha1
kind: FalcoRules
metadata:
  name: eks-security-rules
spec:
  rules:
  - rule: "EKS High Privilege Pod"
    desc: "Detecta pods con permisos de root ejecutando comandos sensibles"
    condition: >
      spawned_process and container and user.name = 0 and
      (proc.name in (bash, sh, zsh, python, python3) or
       spawned_process and container and proc.name = curl)
    output: >
      "Pod con permisos de root ejecutando comando sensible (user=%user.name container=%container.info proc=%proc.name)"
    priority: CRITICAL
EOF

• Falco enviará alertas a AWS Security Hub (si está configurado) o a un webhook de Slack.
• Verificá las alertas con:

  kubectl get falcorules -n falco
  kubectl logs -n falco -l app=falco
  

helm upgrade falco falcosecurity/falco -n falco \
  --set falco.aws.securityhub.enabled=true \
  --set falco.aws.securityhub.region=<TU-REGION-AWS>

Paso 4: Escaneo de imágenes en CI/CD con Trivy

# .github/workflows/trivy-scan.yml (para GitHub Actions)
name: Trivy Scan
on: [push]
jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: 'ghcr.io/tu-organizacion/tu-app:latest'
        format: 'sarif'
        output: 'trivy-results.sarif'
    - name: Upload Trivy scan results to GitHub Security tab
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: 'trivy-results.sarif'

• Archivo trivy-results.sarif con vulnerabilidades mapeadas (ej.: CVE-2025-1234 en una imagen base).
• Si hay vulnerabilidades CRITICAL, el pipeline fallará:

  CRITICAL: [UNKNOWN] CVE-2025-1234 (severity: CRITICAL)
  

• Bloqueá el despliegue si hay vulnerabilidades CRITICAL o HIGH en imágenes.
• Usá Trivy en modo «misconfig» para detectar errores de configuración en Helm charts:

  trivy config ./charts/tu-app
  

Paso 5: Configurar AWS GuardDuty para EKS

# Habilitá GuardDuty para EKS
aws guardduty create-detector --enable --finding-publishing-frequency STANDARD

# Creá un *filter* para alertas relacionadas con EKS
aws guardduty create-filter \
  --detector-id <ID-DE-DETECTOR> \
  --name "EKS Security Alerts" \
  --action ARCHIVE \
  --finding-criteria '{"criterion": [{"field": "type","equals": {"value": "Policy:S3/BucketAnonymousAccessGranted"}, "description": "Bloquea accesos anónimos a buckets S3 desde pods EKS"}]}'

• GuardDuty generará alertas como:

– Behavior:EC2/NetworkPortUnusual (escaneo de puertos en nodos).

# Asociá GuardDuty con Detective
aws detective create-graph \
  --region <REGION> \
  --graph-arn arn:aws:detective:us-east-1:<ACCOUNT>:graph:<GRAFH-ID>

Consideraciones y buenas prácticas

Limitaciones de las evaluaciones de compromiso

1. Alcance limitado: Una CA no reemplaza un pentest completo. Si tu organización tiene aplicaciones críticas, combiná ambos enfoques.
2. Falsos positivos: Herramientas como Falco pueden alertar sobre actividad legítima (ej.: un sidecar de logging corriendo como root). Revisá las reglas personalizadas antes de aplicarlas en producción.
3. Costo de almacenamiento: Las evaluaciones forenses generan logs masivos (ej.: registros de kube-apiserver por 90 días). Configurá políticas de retención en Amazon S3 con lifecycle rules:

   # s3-lifecycle.json
   {
     "Rules": [
       {
         "ID": "RetainLogs90Days",
         "Status": "Enabled",
         "Filter": {"Prefix": "logs/kube/"},
         "Expiration": {"Days": 90},
         "Transitions": [
           {"Days": 30, "StorageClass": "STANDARD_IA"},
           {"Days": 60, "StorageClass": "GLACIER"}
         ]
       }
     ]
   }
   

Alternativas a Calico

• Cilium: Ideal para clústeres con alto tráfico de red (usa eBPF).
• Network Policies de Kubernetes: Limitado a políticas básicas (sin DDoS protection).

Errores comunes en EKS

Los hallazgos de una evaluación de compromiso no son un informe más: son una hoja de ruta para reducir el riesgo de ataques persistentes. Los datos de 2025 de Kaspersky muestran que las organizaciones que implementan:

1. Auditorías proactivas (Kube-bench, Falco).
2. Políticas de red granulares (Calico).
3. Escaneo de imágenes en CI/CD (Trivy).
4. Monitoreo continuo (GuardDuty + Detective).

Para EKS, el enfoque debe ser multicapa:

• Capa de control plane: Auditar con Kube-bench y configurar políticas de red.
• Capa de nodos: Monitorear con Falco y GuardDuty.
• Capa de aplicaciones: Escanear imágenes antes del despliegue.

1. Ejecutá una CA interna con herramientas como kube-hunter para validar los hallazgos.
2. Integrá los resultados con tu SOAR (ej.: PagerDuty, Splunk Phantom).
3. Repetí el proceso cada 90 días (según el MTTD de 2025, este es el umbral crítico).

Fuentes

• Kaspersky Compromise Assessment Findings 2025
• Google Security Blog: Best Practices for EKS Security
• Cloudflare Status: Incidentes de infraestructura
• Kube-bench GitHub
• Falco Documentation