Resposta a Incidents de Ciberseguretat

Introducció

La resposta a incidents és la fase crítica en la qual l'organització actua per contenir el dany, erradicar la causa arrel i recuperar la normalitat operativa. Una resposta mal executada pot convertir un incident menor en una catàstrofe que afecti la continuïtat del negoci, la reputació i fins i tot impliqui sancions legals.

El marc de referència més acceptat és el del NIST SP 800-61 (Computer Security Incident Handling Guide), que defineix quatre fases: Preparació, Detecció i Anàlisi, Contenció/Erradicació/Recuperació, i Activitat Post-incident.

flowchart LR
    A[Preparació] --> B[Detecció i Anàlisi]
    B --> C[Contenció]
    C --> D[Erradicació]
    D --> E[Recuperació]
    E --> F[Lliçons Apreses]
    F --> A
    style A fill:#4CAF50
    style C fill:#FF9800
    style D fill:#F44336
    style E fill:#2196F3
    style F fill:#9C27B0

Fase 1: Preparació

La preparació és l'única fase que pot completar-se abans que es produeixi l'incident. Una organització ben preparada respon en hores; una mal preparada, en setmanes.

Equip de Resposta a Incidents (CSIRT/CERT)

Un CSIRT (Computer Security Incident Response Team) és l'equip encarregat de gestionar incidents. Pot ser:

• Intern: equip dedicat dins l'organització (viable per a grans empreses)
• Extern: contractat a un proveïdor MSSP (Managed Security Service Provider)
• Híbrid: equip intern reforçat per suport extern en incidents greus

Rols típics d'un CSIRT:

Rol	Responsabilitat
Incident Manager	Coordina la resposta, pren decisions
Analyst L1/L2/L3	Analitza alertes i evidències
Forensics Specialist	Adquireix i analitza evidències
Communication Lead	Gestiona comunicació interna i externa
Legal/Compliance	Assessora en aspectes legals i notificació

Playbooks d'incidents

Un playbook és un guió d'actuació predefinit per a un tipus específic d'incident. Permet que qualsevol analista, fins i tot amb poca experiència, pugui seguir els passos correctes sota pressió.

Exemple de playbook per a Ransomware:

PLAYBOOK: RANSOMWARE
Versió: 2.1 | Darrera revisió: 2024-01

TRIGGERS:
- Alerta SIEM: múltiples fitxers xifrats en poc temps
- Usuari reporta missatge de rescat
- Antivirus detecta ransomware conegut

FASE CONTENCIÓ (primeres 30 minuts):
[ ] 1. Aïllar immediatament el sistema afectat de la xarxa
      → `netsh interface set interface "Ethernet" admin=disabled`
[ ] 2. No apagar el sistema (preservar evidències en RAM)
[ ] 3. Notificar al Incident Manager
[ ] 4. Identificar sistemes potencialment afectats (lateral movement?)
[ ] 5. Bloquejar credencials compromeses (si se saben)
[ ] 6. Activar el Pla de Continuïtat de Negoci si cal

FASE INVESTIGACIÓ:
[ ] 7. Capturar imatge de memòria RAM
[ ] 8. Identificar variant de ransomware (ID Ransomware: https://id-ransomware.malwarehunterteam.com)
[ ] 9. Revisar Event Logs: Event ID 4688 (process creation), 4663 (file access)
[ ] 10. Determinar vector d'entrada (phishing, RDP exposed, vuln?)
[ ] 11. Identificar el pacient zero i timeline de l'atac

FASE ERRADICACIÓ:
[ ] 12. Eliminar malware de tots els sistemes afectats
[ ] 13. Canviar TOTES les credencials de l'entorn
[ ] 14. Eliminar backdoors si s'han detectat
[ ] 15. Aplicar pegats per a la vulnerabilitat explotada

FASE RECUPERACIÓ:
[ ] 16. Restaurar des de backup (verificar que el backup no estigui xifrat)
[ ] 17. Monitoratge intensiu post-recuperació (48-72h)
[ ] 18. Validació que el sistema funciona correctament

DECISIÓ DE PAGAMENT:
⚠️ No pagar sense consultar legal i asseguradora
⚠️ El pagament no garanteix la recuperació de dades
⚠️ El pagament pot ser il·legal (si l'atacant és en llista sancionada)

Miniactivitat

Busca informació sobre l'atac de ransomware WannaCry (2017) i el Colonial Pipeline (2021). Per a cada cas:

1. Quin va ser el vector d'entrada?
2. Quant van durar fins a la recuperació?
3. Es va pagar el rescat? Quin va ser el resultat?
4. Quines mesures preventives haurien evitat l'atac?

Eines de resposta a incidents

Eina	Categoria	Ús
TheHive	IRM (Incident Response Management)	Gestió de casos d'incidents
MISP	Threat Intelligence	Compartir IoCs entre organitzacions
Velociraptor	EDR/DFIR	Recollida forense remota a gran escala
GRR Rapid Response	DFIR	Investigació remota en flota
Cortex	SOAR	Automatització de resposta

Fase 2: Contenció

La contenció té com a objectiu aturar el dany sense destruir evidències. Hi ha dos tipus:

Contenció a curt termini

Accions immediates per aturar la propagació: - Aïllament de xarxa: desconnectar el sistema afectat de la xarxa - Bloqueig de comptes: deshabilitar comptes compromesos - Bloqueig de tràfic: bloquejar IPs malicioses en el firewall/proxy - Segmentació d'emergència: crear VLAN d'aïllament per als sistemes afectats

# Exemple: aïllar un sistema Linux de la xarxa mantenint-lo encès
# (per preservar evidències en RAM)
sudo ip link set eth0 down

# O des d'un altre sistema (si tenim accés SSH):
ssh admin@sistema-afectat "sudo ip link set eth0 down"

No apagar el sistema!

Apagar el sistema destrueix la memòria RAM, que pot contenir: - Contrasenyes en text clar - Claus de xifrat del ransomware - Connexions de xarxa actives - Processos maliciosos en curs

Sempre captura la RAM abans d'apagar.

Contenció a llarg termini

Per a incidents que requereixen temps de resolució: - Sistemes alternatius (failover) - Pla de Continuïtat de Negoci (BCP) - Comunicació als usuaris afectats

Fase 3: Erradicació

Un cop contingut l'incident, cal eliminar completament la causa arrel:

1. Eliminar malware: no val amb l'antivirus; si hi ha un APT, cal reconstruir el sistema
2. Tancar vulnerabilitats: aplicar pegats, tancar ports, desactivar serveis
3. Eliminar backdoors: revisar tasques programades, serveis, comptes nous
4. Canviar credencials: totes les credencials de l'entorn afectat

Trampa comuna

Molts equips recuperen sistemes sense erradicar completament la causa. El resultat: el mateix atac torna a passar en dies o setmanes. L'erradicació ha de ser exhaustiva.

Exemple: verificació post-erradicació en Linux

# Verificar comptes nous sospitosos
grep -E "uid=[0-9]{1,3}\(" /etc/passwd | grep -v "nologin\|false"

# Verificar tasques programades de tots els usuaris
for user in $(cut -f1 -d: /etc/passwd); do
    crontab -u $user -l 2>/dev/null | grep -v "^#"
done

# Verificar serveis nous
systemctl list-units --type=service --state=running

# Verificar connexions actives
ss -tunp

# Verificar fitxers modificats recentment (últimes 48h)
find /etc /usr/bin /usr/sbin /home -newer /tmp/timestamp -type f 2>/dev/null

Fase 4: Recuperació

La recuperació ha de ser gradual i monitoritzada:

1. Restauració des de backup verificat: confirmar que el backup és anterior a l'incident
2. Reconstrucció del sistema (si el backup no és fiable): fresh install + configuració
3. Proves funcionals: verificar que tot funciona correctament
4. Monitoratge intensiu: 72-168h de monitoratge reforçat post-recuperació
5. Retorn progressiu: primer un usuari pilot, després tots

flowchart TD
    A[Backup disponible?] -->|Sí| B[Verificar integritat del backup]
    A -->|No| C[Reconstruir des de zero]
    B -->|OK| D[Restaurar en entorn de proves]
    B -->|Corrupte| C
    D -->|Proves OK| E[Restaurar en producció]
    C --> D
    E --> F[Monitoratge intensiu 72h]
    F -->|Tot OK| G[Retorn a normalitat]
    F -->|Anomalies| H[Investigar i repetir cicle]

Fase 5: Ciberresiliència

La ciberresiliència és la capacitat d'una organització de mantenir les seves operacions crítiques malgrat un ciberatac. Va més enllà de la recuperació puntual.

Principis de ciberresiliència (NIST SP 800-160 Vol. 2)

• Anticipate: identificar possibles adversaris i les seves TTPs
• Withstand: resistir un atac en curs mantenint funcions crítiques
• Recover: restaurar les funcions afectades ràpidament
• Adapt: adaptar-se per millorar la postura de seguretat

Redundància i alta disponibilitat

flowchart LR
    subgraph Actiu
        A[Servidor Principal]
        B[Base de dades Principal]
    end
    subgraph Passiu
        C[Servidor DR]
        D[Base de dades DR]
    end
    A -->|Replica| C
    B -->|Replica| D
    E[Load Balancer] --> A
    E -.->|Failover| C

Lliçons apreses (Post-mortem)

El post-mortem és el procés d'anàlisi que es fa 48-72h després de tancar un incident. L'objectiu NO és trobar culpables, sinó millorar els processos.

Estructura d'un post-mortem "blameless"

# Post-mortem: [Nom de l'incident]
Data: YYYY-MM-DD
Durada: X hores
Severitat: Crítica/Alta/Mitja/Baixa
Equip: [noms]

## Resum executiu (5 línies màx)

## Cronologia detallada
| Hora | Acció | Actor |
|------|-------|-------|
| 14:32 | Primera alerta SIEM detectada | Sistema |
| 14:35 | Analyst L1 investiga alerta | J. García |
...

## Causes arrel (5 Whys)
Per què va passar? → Perquè...
Per què va passar X? → Perquè...
[fins a 5 nivells]

## Impacte
- Sistemes afectats:
- Dades compromeses:
- Temps d'inactivitat:
- Cost estimat:

## Accions de millora
| Acció | Responsable | Data límit | Prioritat |
|-------|-------------|------------|-----------|
| Implementar MFA | IT Security | 2024-03-01 | Alta |

## Lliçons apreses
1. ...
2. ...

Miniactivitat

Amb la informació pública sobre l'incident de SolarWinds (2020):

1. Construeix una cronologia simplificada de l'incident
2. Identifica les fases de contenció que es van activar
3. Quines lliçons apreses van publicar les empreses afectades?
4. Quines millores de seguretat van implementar com a resultat?

Eines de gestió d'incidents: TheHive

TheHive és una plataforma open source de gestió d'incidents de ciberseguretat. Permet:

• Crear i gestionar casos d'incidents
• Assignar tasques als membres de l'equip
• Adjuntar evidències i IoCs
• Integrar-se amb MISP per a threat intelligence
• Generar informes d'incident

# docker-compose.yml de TheHive (simplificat)
version: '3'
services:
  thehive:
    image: strangebee/thehive:5
    ports:
      - "9000:9000"
    environment:
      - TH_SECRET=supersecretkey
    depends_on:
      - elasticsearch
      - cassandra

  cortex:
    image: thehiveproject/cortex:3
    ports:
      - "9001:9001"

Activitats del mòdul

AC5014 — Simulació de resposta a incident Seguint el playbook de ransomware proporcionat, simula la resposta a un incident de ransomware en un entorn de laboratori Docker. Documenta cada acció i el seu resultat.

PR5011 — Pràctica SIEM Wazuh Desplega Wazuh en Docker, genera events d'incident simulats i gestiona-los seguint el procés de resposta complet fins al post-mortem.