Respuesta a Incidentes según NIST SP 800-61r3: Guía Práctica

Qué cambió en Rev.3

El tema 'Qué cambió en Rev.3' es una parte central del trabajo sobre Incident Response según NIST. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, anote Govern, Identify, Protect, Detect, Respond y Recover, preparación continua, integración de IR en la gestión de riesgos, Lessons learned, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los próximos pasos.

Govern, Identify y Protect como infraestructura

El tema 'Govern, Identify y Protect como infraestructura' es una parte central del trabajo sobre Incident Response según NIST. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, anote Govern, Identify, Protect, Detect, Respond y Recover, preparación continua, integración de IR en la gestión de riesgos, Lessons learned, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los próximos pasos.

Detect, Respond y Recover

El tema 'Detect, Respond y Recover' es una parte central del trabajo sobre Incident Response según NIST. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, anote Govern, Identify, Protect, Detect, Respond y Recover, preparación continua, integración de IR en la gestión de riesgos, Lessons learned, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los próximos pasos.

Roles, comunicación y documentación

La documentación de Incident Response según NIST debe permitir que una persona que no participó en el trabajo comprenda lo sucedido y recree la conclusión. Se separa entre hechos, interpretación, suposiciones y decisiones, y se vincula cada afirmación con una evidencia, consulta o captura de pantalla.

Una estructura útil incluye Resumen, Alcance, Línea de tiempo, Evidencia, Impacto, Acciones, Limitaciones y Próximos pasos. En un informe de PT se añaden Remedio y Retest; en una investigación se añaden Contención, Recuperación y Lecciones aprendidas.

Mejora después de un incidente

La mejora de Incident Response según NIST debe comenzar con una Línea Base. Se mide el volumen, la tasa de casos útiles, el tiempo de investigación, las fuentes faltantes y el motivo del cierre. Un cambio que reduce las Alertas pero oculta la actividad real no es un éxito.

Las opciones de Ajuste incluyen umbral, ventana de tiempo, Lista de Permitidos enfocada, Contexto de activo, Supresión y excepción basada en un proceso aprobado. Cada excepción debe tener un propietario, una validez y una condición de cancelación. Después del cambio, se ejecuta un conjunto de pruebas y se compara antes/después.

Puntos de control únicos

En este tema, se recomienda construir previamente un mapa de evidencia enfocado. Los principales puntos de control son: Govern, Identify, Protect, Detect, Respond y Recover, preparación continua, integración de IR en la gestión de riesgos, Lecciones aprendidas. La lista no es una lista de verificación automática; cada elemento se elige porque puede vincular una entidad, acción y tiempo o explicar un comportamiento legítimo.

• Govern, Identify, Protect, Detect, Respond y Recover: Defina cuál es el valor esperado, qué se considerará una anomalía y qué otra fuente confirmará el hallazgo.
• Preparación continua: Defina cuál es el valor esperado, qué se considerará una anomalía y qué otra fuente confirmará el hallazgo.
• Integración de IR en la gestión de riesgos: Defina cuál es el valor esperado, qué se considerará una anomalía y qué otra fuente confirmará el hallazgo.
• Lessons learned: Defina cuál es el valor esperado, qué se considerará una anomalía y qué otra fuente confirmará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede usar tiempo, Host, User y Parent; si la carga útil está cifrada, se usa Metadata, volumen, frecuencia y contexto TLS/DNS.

Proceso de trabajo recomendado

1. Defina un Scope y una pregunta de trabajo sobre Incident Response según NIST.
2. Anote las fuentes de datos y las evidencias necesarias: Govern, Identify, Protect, Detect, Respond y Recover, preparación continua, integración de IR en la gestión de riesgos, Lecciones aprendidas.
3. Cree una línea base corta de comportamiento normal o resultado esperado.
4. Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
5. Construya una línea de tiempo o una tabla de comparación y separe los hechos de la interpretación.
6. Realice un Pivot a una fuente adicional para confirmar o refutar la explicación inicial.
7. Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es el mapeo de un Playbook existente a las funciones de CSF 2.0. El propósito del ejercicio no es demostrar una capacidad de ataque, sino practicar la recopilación, comparación y documentación de manera segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al final del ejercicio, se debe entregar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o una exportación de la evidencia, una línea de tiempo corta, una hipótesis inicial, una evidencia de confirmación, una limitación y una recomendación. Cuando no hay suficiente evidencia, la conclusión correcta es que el escenario no ha sido probado.

Lista de verificación práctica

• ✓Verifique y documente: Fuente de la evidencia.
• ✓Verifique y documente: Hora de recolección y zona horaria.
• ✓Verifique y documente: Hash y Cadena de Custodia.
• ✓Verifique y documente: Herramienta y versión.
• ✓Verifique y documente: Acciones de respuesta realizadas.
• ✓Verifique y documente: Línea de tiempo y suposiciones de trabajo.
• ✓Indique la zona horaria, la versión de la herramienta y la hora de recolección.
• ✓Guarde los datos brutos antes de filtrar o modificar.
• ✓Escriba lo que el hallazgo prueba y lo que aún se desconoce.
• ✓Defina un propietario y una acción de seguimiento con una fecha límite.

Errores comunes

• Modificar el sistema antes de preservar la evidencia.
• No documentar la zona horaria.
• No calcular el Hash.
• Confundir hechos con suposiciones.
• No documentar quién tuvo la evidencia en su poder.
• Priorizar la integridad teórica sobre la contención inmediata del daño.

Resumen y CTA

Incident Response según NIST SP 800-61r3: Guía Práctica es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencias relevantes, conserve el contexto y el tiempo, y elija una acción que pueda justificarse y revisarse.

En el programa Cybersecurity & AI de HPI se practican estos principios utilizando sistemas, registros y laboratorios. Un paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes