Incident First Responder (Evidence Preservation and Escalation)

Definición

Un incident first responder (socorrista / primer respondiente) es la persona que descubre o recibe primero señales de un incidente y debe ejecutar acciones iniciales que:

1. No destruyan evidencia,
2. No alerten innecesariamente al adversario, y
3. Aceleren el handoff al equipo adecuado (SOC/IR/CSIRT).

No es “quien resuelve el incidente” (eso es IR/IM), sino quien preserva, documenta y escala correctamente.

Contexto

• En la práctica, el primer aviso no siempre viene del SOC: puede venir de un ingeniero de plataforma, SRE, dev, helpdesk o dueño del servicio.
• Los primeros minutos importan: un error típico (RAW) es apagar el host, lo que puede:
  • destruir evidencia en memoria/estado volátil, y
  • alertar al actor de amenazas, que puede escalar su impacto.
• El objetivo es preparar el terreno para una respuesta efectiva: ver Incident Response and Incident Management y Security Auditing and Monitoring.

Desarrollo (MIT-style)

1) Tareas del primer respondiente (visión operativa)

Basado en el RAW, tus responsabilidades iniciales suelen ser:

• Preservar evidencia (prioridad por volatilidad).
• Documentar acciones y tiempos (idealmente en UTC).
• Alertar a las partes interesadas correctas (SOC/IR/SMEs) usando playbooks, ticketing o árbol de llamadas.
• Ayudar como SME (si aplica) a decidir contención viable en tu división (sin improvisar cambios destructivos).

2) Preservación de evidencia y “orden de volatilidad” (RFC 3227)

El RAW remite a RFC 3227 y propone capturar evidencia en este orden (de más volátil a menos volátil):

1. Registros y caché

   • Son extremadamente volátiles; cambian en segundos.
   • Pueden ser críticos para entender actividad de malware, aunque a veces no es viable capturarlos “a tiempo”.

2. Tabla de enrutamiento, caché ARP, tabla de procesos, estadísticas del kernel y memoria (RAM)

   • Permite entender comunicación de red y estado del host “en el momento”.
   • La RAM es clave para entender payloads y comportamiento real (RAW: el malware puede ser modular y diferir de una muestra aislada).

3. Sistemas de archivos temporales

   • Pueden contener sesiones activas (p.ej., en servidores web) u otros artefactos de ejecución.

4. Disco

   • Imagen/snapshot para investigación y potencial uso legal.
   • Permite comparar con logs remotos y detectar intentos de borrado/anti-forense.

5. Registro y monitoreo remoto

   • Preservar lo más “hacia atrás” posible (retención no es infinita).
   • Importante si el incidente es más antiguo de lo que parece.

6. Configuración física y topología de red

   • Subred/segmento, conectividad y contexto para acotar el alcance.

7. Medios de archivo (backups)

   • Útil para estimar antigüedad comparando artefactos históricos, aunque suele ser menos volátil.

Regla práctica (RAW): no apagar y no desconectar red inmediatamente por defecto, porque puede destruir evidencia y alertar al atacante.

3) Dos “NO hacer” adicionales (IETF/RFC 3227)

El RAW destaca dos errores adicionales:

• No confíe en programas del sistema: en un host comprometido, binaries/herramientas pueden estar alteradas.
  • Preferir herramientas de recolección confiables (kit de respuesta, binarios verificados, medios de solo lectura) y/o recolección remota desde controles (EDR, SIEM, appliance).
• No ejecute programas que modifiquen tiempos de acceso: el atime puede ser evidencia.
  • Evitar “copiar y pegar” archivos de forma ingenua; usar técnicas/herramientas que minimicen contaminación (y documentar cualquier acción).

4) Cadena de custodia (Chain of Custody)

El RAW enfatiza que, para que la evidencia sea admisible y confiable, debes poder demostrar que no fue manipulada:

• Mantener un registro (log) de evidencia: qué se capturó, cuándo, por quién, cómo, dónde se almacenó.
• Probar integridad: hashes (p.ej., SHA-256) y verificación periódica.
• Analizar copias, no el original; demostrar que la copia sigue coincidiendo con la evidencia original.

Plantilla mínima (para evidencias digitales):

5) Alertar a stakeholders: playbooks, ticketing y árboles de llamadas

El RAW recomienda preparar mecanismos de escalado antes de que ocurra el incidente:

• Playbooks: pasos predefinidos por tipo de incidente (phishing, account compromise, etc.) y enlazados entre sí.
• Ticketing automatizado (RAW menciona Jira): registrar y escalar según severidad; notifica stakeholders.
• Árbol de llamadas: define a quién informar, quién informa a quién y cómo escalar si alguien no está disponible.

Información útil al escalar (para reducir ida/vuelta):

• Qué viste (síntomas) y cuándo.
• Activo afectado y criticidad.
• Acciones realizadas (y por qué).
• Evidencia preservada (y dónde está).
• Riesgo inmediato (propagación/exfiltración/impacto en BAU).

6) Contención: qué debes saber (sin destruir evidencia)

El primer respondiente rara vez “contiene” solo, pero el RAW recomienda entender métodos típicos:

• Segmentación de red (mover a segmento aislado) para evitar propagación.
• Aislamiento físico (confiscar estación/servidor) para preservar evidencia y cortar acciones.
• Aislamiento virtual (EDR) para limitar comunicaciones de forma remota (con caveat: si EDR está comprometido puede fallar).
• Alternativa en casos puntuales (RAW): ralentizar conectividad para ganar tiempo de observación y reducir sospecha del atacante.

Ver también: Secure Network Architecture and Segmentation.

7) Documentación de acciones (hasta el handoff)

El RAW insiste en documentar acciones incluso bajo presión. Una plantilla mínima de “action log” debería capturar:

• Hora de solicitud (preferible UTC).
• Acción realizada y descripción.
• Razón para ejecutar la acción.
• Aprobador.
• Responsable (owner) de ejecución.
• Hora de ejecución.
• Cambios observados tras ejecutar.

Para continuidad de negocio/BCP y métricas asociadas, ver Business Continuity Plan (BCP) and Business Impact Analysis (BIA).

Ejemplos

Ejemplo 1 — Servidor “comprometido” detectado por ingeniería (RAW, adaptado)

1. Pausar cambios y no apagar el host.
2. Iniciar action log en UTC con lo que observas y lo que haces.
3. Preservar evidencia volátil (orden RFC 3227): procesos/estado de red/RAM (según tooling y procedimiento interno).
4. Escalar a SOC/IR por ticket o árbol de llamadas; adjuntar contexto y evidencias.
5. Coordinar contención viable (segmentación/EDR/aislamiento físico) sin perder evidencia crítica.
6. Mantener cadena de custodia de cualquier evidencia recolectada.

Pitfalls / Errores comunes

• Apagar el host o “tirar del cable” sin coordinación: pérdida de evidencia y posible escalada del atacante (RAW).
• Ejecutar herramientas del propio host comprometido y contaminar evidencia (RAW).
• Modificar atime/metadatos por copiar archivos sin control (RAW).
• No documentar acciones/tiempos: no hay línea temporal fiable ni handoff limpio.
• Alertar a personas equivocadas o sin el contexto mínimo: retrasos críticos.

Diagrama

flowchart TD
  D[Señal / sospecha] --> LOG[Iniciar action log (UTC)]
  LOG --> PRES[Preservar evidencia (orden volatilidad)]
  PRES --> ESC[Escalar a SOC/IR (ticket/call tree)]
  ESC --> DEC{Contención viable\nsin destruir evidencia?}
  DEC -->|Sí| CON[Contener (segmentación / EDR / físico)]
  DEC -->|No| OBS[Observar y preparar\ncontención coordinada]
  CON --> HAND[Handoff: evidencias + timeline + owners]
  OBS --> HAND

Referencias

1. TryHackMe — Introducción a la respuesta y gestión de incidentes: https://tryhackme.com/jr/introtoirandim
2. TryHackMe — Logging for Accountability: https://tryhackme.com/room/loggingforaccountability
3. IETF RFC 3227 — Guidelines for Evidence Collection and Archiving: https://datatracker.ietf.org/doc/html/rfc3227#section-2.1
4. TryHackMe — Intro Network Security (mencionada en contención por segmentación): https://tryhackme.com/room/intronetworksecurity