Módulo 1: Fundamentos de la respuesta a incidentes y el proceso PICERL

La respuesta a incidentes (Incident Response, IR) es la disciplina que determina si una intrusión se convierte en una anécdota documentada en un informe post-mortem o en una filtración de datos con notificación a la AEPD, pérdida de clientes y titulares de prensa. Este módulo sienta las bases teóricas y operativas que vertebran todo el curso: el ciclo de vida formal de un incidente según el estándar de referencia del sector (NIST SP 800-61 Rev. 2), su equivalente mnemotécnico PICERL usado en la certificación GCIH de SANS, la estructura de un equipo de respuesta (CSIRT/CERT), los criterios de clasificación y priorización que evitan que un analista junior colapse ante 40 alertas simultáneas, y el montaje del laboratorio DFIR aislado que usarás en cada práctica del curso. Si vienes de administración de sistemas o de un SOC de nivel 1, este módulo es el puente hacia el pensamiento forense: dejar de «arreglar el problema» para empezar a «investigar, contener y aprender del incidente».

Aviso legal y ético antes de empezar

Todo el contenido práctico de este curso —capturas de memoria, análisis de disco, adquisición de evidencia, uso de herramientas ofensivas o de post-explotación con fines de simulación— debe ejecutarse exclusivamente en el laboratorio aislado que construirás en este módulo, sobre sistemas y datos de tu propiedad o sobre los que tengas autorización expresa y por escrito. Actuar sobre sistemas de terceros sin autorización es un delito.

En España, el marco penal relevante incluye el artículo 197 bis del Código Penal (acceso e interceptación ilícita de sistemas de información, introducido por la LO 1/2015) y el artículo 588 sexies LECrim, que regula el registro remoto de equipos informáticos y la cadena de custodia de la evidencia digital en el proceso penal español. Si en tu trabajo real llegas a intervenir en un incidente, documenta siempre: quién recogió la evidencia, cuándo, cómo (herramienta y hash), dónde se almacenó y quién tuvo acceso después. Sin cadena de custodia, la evidencia puede ser inadmisible o impugnable, aunque el análisis técnico sea impecable.

Qué aprenderás en este módulo

• Por qué las organizaciones necesitan un proceso de IR formal y documentado, y no solo «gente que sabe de seguridad apagando fuegos».
• Las cuatro fases del ciclo de vida de NIST SP 800-61 Rev. 2 y qué actividades concretas contiene cada una.
• El mnemotécnico PICERL de SANS (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) y cómo se mapea contra las fases de NIST.
• Roles, responsabilidades y modelos organizativos de un CSIRT/CERT (interno, coordinador, comercial).
• Cómo clasificar y priorizar un incidente según impacto funcional, impacto informativo y recuperabilidad, siguiendo el esquema de NIST.
• Las métricas MTTD y MTTR: qué miden, cómo se calculan y por qué le importan a un CISO.
• Cómo montar desde cero el laboratorio DFIR aislado (VM de analista + víctimas Windows/Linux en red host-only) que usarás durante todo el curso, incluida la verificación de integridad de evidencia con hashes SHA-256.

Por qué existe un proceso formal de respuesta a incidentes

La tentación del administrador de sistemas ante un servidor comprometido es reiniciarlo, reinstalarlo o «limpiarlo» cuanto antes para restaurar el servicio. Ese instinto es exactamente lo contrario de lo que exige una respuesta a incidentes rigurosa, y es la causa más común de que las organizaciones repitan el mismo compromiso semanas después. Un proceso formal de IR existe por tres motivos que se refuerzan entre sí:

• Contener sin destruir evidencia. Apagar una máquina comprometida destruye la memoria RAM (procesos en ejecución, claves de cifrado, malware sin persistencia en disco, conexiones de red activas) antes de poder capturarla. Sin proceso, se pierde la causa raíz.
• Repetibilidad y defensibilidad. Un incidente grave puede acabar en un procedimiento judicial, una auditoría regulatoria (RGPD/AEPD, PCI-DSS, ISO 27001) o una reclamación de seguro de ciberriesgo. Todas esas instancias exigen poder demostrar qué se hizo, cuándo y por qué, con documentación coherente y reproducible.
• Reducción de impacto medible. El coste de una filtración crece con el tiempo que el atacante permanece en la red (dwell time). Un proceso estructurado con fases claras de detección y contención reduce ese tiempo de forma sistemática, en lugar de depender de la suerte o de la pericia individual de quien esté de guardia esa noche.

El documento de referencia del sector —y examinable en certificaciones como GCIH, CySA+ o CISSP— es el NIST Special Publication 800-61 Revisión 2, titulado «Computer Security Incident Handling Guide», publicado por el NIST (National Institute of Standards and Technology) de EE. UU. Aunque tiene más de una década, su ciclo de vida de cuatro fases sigue siendo el modelo dominante en la industria y la base de casi todo playbook de IR moderno.

El ciclo de vida de NIST SP 800-61 Rev. 2

NIST estructura la respuesta a incidentes en cuatro fases, representadas habitualmente como un ciclo (no un proceso lineal de un solo uso): la fase de post-incidente retroalimenta la de preparación, y durante la contención/erradicación es frecuente volver a detección y análisis al descubrir nuevos indicadores.

Fase 1 — Preparation (Preparación)

Es la fase más importante y la más infravalorada por los equipos que no han sufrido aún un incidente serio. Ocurre antes de que exista un incidente y determina si las tres fases siguientes se ejecutarán con eficacia o con caos. Incluye:

• Redactar y aprobar el plan de respuesta a incidentes (IRP) y los playbooks por tipo de amenaza (ransomware, compromiso de credenciales, exfiltración de datos, DDoS…).
• Constituir el CSIRT: roles, cadena de mando, datos de contacto 24/7, vías de escalado.
• Desplegar y mantener herramientas de detección (EDR, SIEM, IDS/IPS, logging centralizado) y asegurarse de que retienen logs el tiempo suficiente para investigar.
• Preparar el kit de primera respuesta (jump bag): discos duros forenses limpios, cables, bloqueadores de escritura, portátil de análisis, documentación de contactos legales y de comunicación.
• Formación y simulacros (tabletop exercises) periódicos con el equipo y con stakeholders no técnicos (legal, comunicación, dirección).
• Establecer acuerdos previos con proveedores externos (forense, legal, comunicación de crisis) para no negociar contratos en plena crisis.

Fase 2 — Detection & Analysis (Detección y análisis)

Es donde se identifica que algo anómalo está ocurriendo y se determina si constituye realmente un incidente de seguridad. NIST distingue explícitamente entre un evento (cualquier suceso observable en un sistema o red, la inmensa mayoría benignos) y un incidente (una violación real o inminente de las políticas de seguridad). Actividades típicas:

• Correlación de alertas de múltiples fuentes (SIEM, EDR, proxy, firewall, IDS) para descartar falsos positivos.
• Triage inicial: ¿qué activo está afectado?, ¿qué criticidad tiene?, ¿hay indicios de movimiento lateral o exfiltración?
• Documentación exhaustiva desde el primer minuto: cada acción, hora exacta, analista responsable, cada archivo o log recogido con su hash.
• Clasificación y priorización formal del incidente (ver sección dedicada más abajo).
• Notificación a los stakeholders según el playbook (dirección, legal, y si aplica, autoridad regulatoria dentro de plazo).

Esta fase es, con diferencia, la que más tiempo consume y la que separa a un analista competente de uno mediocre: un exceso de falsos positivos agota al equipo (alert fatigue); un triage descuidado deja pasar un incidente crítico camuflado entre ruido.

Fase 3 — Containment, Eradication & Recovery (Contención, erradicación y recuperación)

NIST agrupa estas tres actividades en una sola fase porque en la práctica se solapan y se repiten de forma iterativa. Conviene, no obstante, entenderlas por separado:

• Contención: detener la propagación del incidente sin destruir evidencia. Se distingue entre contención a corto plazo (aislar el host de la red, deshabilitar una cuenta comprometida, bloquear un IoC en el firewall) y contención a largo plazo (parcheo temporal, reconstrucción planificada de sistemas). Antes de cualquier acción de contención que altere el sistema, se debe capturar evidencia volátil (memoria RAM, conexiones de red, procesos) si aún no se ha hecho.
• Erradicación: eliminar la causa raíz del incidente —malware, cuentas creadas por el atacante, persistencia, vulnerabilidad explotada— y no solo sus síntomas visibles. Un fallo común es limpiar el malware pero dejar la credencial robada activa o la vulnerabilidad sin parchear, lo que provoca reinfección en días.
• Recuperación: restaurar los sistemas afectados a operación normal de forma controlada y verificada (desde backups limpios y verificados, con monitorización reforzada durante el periodo posterior), confirmando que no queda persistencia del atacante antes de devolver el sistema a producción.

Fase 4 — Post-Incident Activity (Actividad post-incidente)

La fase que casi ningún equipo ejecuta con la disciplina necesaria, y la que NIST señala como crítica para la mejora continua. Incluye:

• La reunión de lecciones aprendidas (lessons learned meeting), idealmente en los días inmediatamente posteriores al cierre del incidente, con todos los implicados.
• Redacción del informe final: cronología completa, causa raíz, coste estimado, eficacia de la respuesta, indicadores de compromiso (IoC) para alimentar la detección futura.
• Actualización de playbooks, reglas de detección y controles preventivos a partir de lo aprendido.
• Retención de la evidencia según la política legal y regulatoria aplicable (puede ser exigida durante años en procedimientos judiciales o auditorías).
• Cálculo y registro de métricas del incidente (MTTD, MTTR, coste) para series históricas.

Esta fase retroalimenta directamente la Fase 1: cada incidente cerrado debe dejar la organización mejor preparada para el siguiente, cerrando el ciclo.

PICERL: el mnemotécnico de SANS

SANS, en su formación GCIH (GIAC Certified Incident Handler) y en el curso SEC504, popularizó un desglose en seis fases más granular que las cuatro de NIST, condensado en el acrónimo PICERL: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. No es un modelo distinto de NIST, sino una subdivisión más fina de la misma lógica: donde NIST fusiona Contención/Erradicación/Recuperación en una fase y separa Detección/Análisis como una sola, SANS separa Identificación como fase propia y desglosa Contención-Erradicación-Recuperación en tres fases independientes con entregables propios. En la práctica profesional verás ambos términos usados de forma intercambiable; lo importante es entender que describen el mismo ciclo con distinto nivel de granularidad.

Fase PICERL	Objetivo principal	Entregable típico
Preparation	Tener personas, procesos y herramientas listos antes de que ocurra el incidente	IRP aprobado, playbooks, jump bag, CSIRT constituido, laboratorio/herramientas desplegadas
Identification	Confirmar que un evento anómalo es realmente un incidente de seguridad y delimitar su alcance	Ticket de incidente abierto, clasificación de severidad, alcance inicial (hosts/usuarios afectados)
Containment	Frenar la propagación del atacante sin perder evidencia volátil	Sistemas aislados/segmentados, evidencia volátil capturada, cuentas comprometidas bloqueadas
Eradication	Eliminar la causa raíz: malware, persistencia, vulnerabilidad explotada, accesos del atacante	Confirmación de limpieza, parches aplicados, credenciales rotadas, IoC documentados
Recovery	Devolver los sistemas a operación normal de forma verificada y monitorizada	Sistemas restaurados desde backup limpio, validación funcional, monitorización reforzada activa
Lessons Learned	Convertir el incidente en mejora medible del programa de seguridad	Informe final, actualización de playbooks/detecciones, métricas (MTTD/MTTR) registradas

Roles y estructura de un CSIRT/CERT

CSIRT (Computer Security Incident Response Team) y CERT (Computer Emergency Response Team) son términos en gran medida equivalentes en el uso actual del sector; CERT fue originalmente una marca registrada asociada al CERT/CC de Carnegie Mellon, por lo que muchas organizaciones optan por CSIRT como término genérico. Existen tres modelos organizativos habituales:

• CSIRT interno: sirve exclusivamente a la organización que lo constituye (un banco, una administración pública, una gran empresa). Es el modelo más común en compañías con madurez de seguridad media-alta.
• CSIRT coordinador/nacional: coordina la respuesta entre múltiples organizaciones de un sector o país (en España, por ejemplo, INCIBE-CERT para el ámbito ciudadano/empresarial y el CCN-CERT para el sector público).
• CSIRT comercial/MSSP: presta servicios de respuesta a incidentes a terceros bajo contrato (proveedores de servicios de seguridad gestionada).

Con independencia del modelo, un CSIRT funcional necesita cubrir estos roles (una persona puede asumir varios en equipos pequeños):

• Incident Commander / Team Lead: coordina la respuesta global, toma decisiones de negocio (¿aislamos el ERP en horario de facturación?) y es la interfaz con dirección.
• Analista de seguridad / Incident Handler: ejecuta el triage técnico, la investigación y las acciones de contención.
• Analista forense: adquisición y análisis profundo de evidencia (disco, memoria, red) cuando el caso lo requiere.
• Enlace legal: valora obligaciones de notificación (RGPD/AEPD, NIS2, contractuales) y gestiona la cadena de custodia desde la perspectiva jurídica.
• Comunicación/PR: gestiona la comunicación interna y, si procede, externa (clientes, prensa, reguladores).
• Enlace con IT/Operaciones: ejecuta cambios de infraestructura (aislamiento de red, restauración de backups) bajo indicación del equipo de IR.

Clasificación y priorización de incidentes

No todos los incidentes merecen la misma urgencia, y tratar una infección de adware en un puesto de usuario con la misma prioridad que una exfiltración activa desde el servidor de base de datos es un error de triage que cuesta caro. NIST SP 800-61 Rev. 2 propone valorar el impacto de un incidente en tres dimensiones independientes:

• Impacto funcional: en qué medida el incidente degrada la capacidad de la organización para prestar sus servicios (desde «ninguno» hasta «pérdida total de un servicio crítico»).
• Impacto informativo: en qué medida se ha visto comprometida la confidencialidad, integridad o disponibilidad de la información (desde «sin exposición de datos» hasta «exfiltración confirmada de datos sensibles o regulados»).
• Recuperabilidad: cuánto esfuerzo y tiempo requiere la recuperación, lo que a su vez determina si el incidente se gestiona con recursos internos o requiere activar apoyo externo/regular a nivel nacional.

La combinación de estas tres dimensiones —junto con la criticidad del activo afectado y el número de sistemas/usuarios implicados— determina la severidad asignada al incidente (habitualmente en una escala de 3 a 5 niveles: crítico, alto, medio, bajo, informativo), que a su vez determina los SLA de respuesta, quién debe ser notificado y si se activa el protocolo de crisis completo. Un CSIRT maduro documenta esta matriz de clasificación por adelantado (en la fase de Preparación) precisamente para no tener que discutirla bajo presión durante el incidente.

Métricas clave: MTTD y MTTR

Dos métricas dominan cualquier conversación con dirección o con un CISO sobre la madurez del programa de respuesta a incidentes:

• MTTD (Mean Time to Detect): tiempo medio transcurrido entre el momento en que ocurre el compromiso inicial y el momento en que la organización lo detecta. Un MTTD alto indica visibilidad insuficiente (logging incompleto, falta de EDR, reglas de detección débiles) y suele correlacionar con el «dwell time» del atacante (el tiempo que permanece dentro de la red sin ser descubierto). Este curso evita citar aquí una cifra concreta de dwell time medio: varía sustancialmente según el informe, el sector y el año, y solo debe usarse en clase o en un informe real citando la fuente primaria vigente (p. ej. el informe anual M-Trends de Mandiant/Google Cloud) en el momento de la consulta.
• MTTR (Mean Time to Respond / Recover): tiempo medio transcurrido desde la detección hasta la contención efectiva (o, según la definición que use la organización, hasta la recuperación completa del servicio). Un MTTR bajo refleja playbooks bien rodados, automatización de respuesta y un equipo entrenado.

Ambas métricas se calculan por incidente y se agregan en series temporales (media o mediana mensual/trimestral) para detectar tendencias. Son también las métricas que con más frecuencia aparecen en cuadros de mando ejecutivos y en informes de aseguradoras de ciberriesgo, porque son fáciles de entender para una audiencia no técnica y correlacionan directamente con el coste esperado de un incidente.

El laboratorio DFIR del curso: montaje paso a paso

Todo el trabajo práctico de este curso se realiza en un laboratorio virtualizado, aislado de tu red doméstica/corporativa y de Internet salvo cuando sea estrictamente necesario para actualizar herramientas. El objetivo es replicar, a pequeña escala, la topología mínima de una investigación real: un puesto de analista con herramientas forenses y una o varias «víctimas» sobre las que practicar detección, contención y análisis.

Requisitos de hardware recomendados

• CPU con soporte de virtualización habilitado en BIOS/UEFI (Intel VT-x / AMD-V).
• Mínimo 16 GB de RAM (8 GB es el límite absoluto y limitará ejecutar varias VMs a la vez; 32 GB es cómodo).
• Al menos 150-200 GB libres en disco (SSD muy recomendable: el análisis forense es intensivo en I/O).

Software de virtualización

Cualquiera de estas dos opciones es válida para el curso; usa la que ya conozcas:

• VirtualBox (Oracle, gratuito): sencillo, multiplataforma, suficiente para todo el curso.
• VMware Workstation Pro / VMware Fusion (Broadcom): mejor rendimiento y snapshots más rápidos en máquinas potentes; Workstation Pro es gratuito para uso personal desde 2024.

Topología del laboratorio

La estructura mínima recomendada consta de tres máquinas virtuales conectadas exclusivamente por una red host-only (o «solo anfitrión»), es decir, una red virtual que NO tiene salida a Internet ni a tu red física, y que solo conecta entre sí a las VMs del laboratorio y al equipo anfitrión:

• VM-Analista: tu estación de trabajo forense. Sistema operativo recomendado: una distribución orientada a DFIR como SIFT Workstation (SANS) o REMnux (análisis de malware), o bien un Windows/Linux «limpio» con las herramientas del curso instaladas manualmente (Autopsy, Volatility 3, Wireshark, KAPE, etc., que se detallan en módulos posteriores).
• VM-Víctima-Windows: una instalación de Windows 10/11 (o Windows Server) que actuará como sistema comprometido en los ejercicios. Nunca actives licencias reales de producción en esta VM; usa medios de evaluación de Microsoft.
• VM-Víctima-Linux: una distribución Linux habitual en servidores (Ubuntu Server o Debian son las más usadas en los ejercicios del curso).

Pasos de configuración de la red host-only

1. En VirtualBox: Archivo > Herramientas > Administrador de red host-only (o Host Network Manager según versión) → crear una red nueva (por ejemplo, vboxnet0, rango típico 192.168.56.0/24). En VMware: crear una red tipo Host-only (VMnet asociada, p. ej. VMnet1) desde el Virtual Network Editor.
2. En la configuración de red de cada VM (Analista, Víctima-Windows, Víctima-Linux), asignar el adaptador de red a esa red host-only. No añadir un segundo adaptador NAT/Bridge salvo cuando necesites actualizar herramientas puntualmente, y desactivarlo de nuevo después.
3. Verificar conectividad entre las tres VMs con ping en ambas direcciones y anotar las IPs asignadas (fijas o por DHCP interno de la red host-only) en tu bitácora del laboratorio.
4. Confirmar explícitamente que ninguna VM tiene salida a Internet mientras el adaptador NAT esté desactivado: es la garantía de que ningún malware de prácticas puede filtrar datos ni «llamar a casa».

Snapshots: tu red de seguridad

Antes de ejecutar cualquier ejercicio que modifique el estado de una VM víctima (infectarla deliberadamente, simular persistencia de atacante, etc.), toma una snapshot del estado limpio. Esto te permite volver atrás en segundos si algo sale mal, y es también la técnica que usarás para preparar «escenarios» reutilizables: snapshot limpio → aplicar el escenario del ejercicio → snapshot «comprometido» → practicar el análisis → revertir al snapshot limpio para el siguiente intento.

• VirtualBox: clic derecho sobre la VM → Tomar instantánea (o VBoxManage snapshot <vm> take <nombre> desde línea de comandos).
• VMware: VM > Snapshot > Take Snapshot.

Verificación de integridad de la evidencia con hashes

Un principio elemental en DFIR: toda evidencia digital debe hashearse en el momento de la adquisición, y ese hash debe volver a calcularse antes de cada análisis posterior para demostrar que el archivo no se ha alterado. SHA-256 es el algoritmo estándar actual (MD5 y SHA-1 siguen citándose en literatura antigua pero están criptográficamente debilitados y no deberían usarse como única prueba de integridad en un caso serio). Practica ya estos dos comandos, porque los usarás en cada módulo del curso:

En Windows (PowerShell), para hashear una imagen de disco o un volcado de memoria adquirido:

Get-FileHash -Algorithm SHA256 -Path C:Evidenciadisco-victima.E01

# Guardar el resultado en un fichero de log de cadena de custodia:
Get-FileHash -Algorithm SHA256 -Path C:Evidenciadisco-victima.E01 |
    Select-Object Algorithm, Hash, Path |
    Out-File -Append C:Evidenciahashes.log

En Linux (la VM-Analista si usas SIFT/REMnux, o cualquier distro), equivalente con sha256sum:

# Calcular el hash de la evidencia adquirida:
sha256sum /evidencia/disco-victima.dd > /evidencia/disco-victima.sha256

# Verificar más tarde que el archivo no se ha alterado:
sha256sum -c /evidencia/disco-victima.sha256

Regla práctica para todo el curso: cada vez que adquieras un artefacto (imagen de disco, volcado de memoria, exportación de logs, captura de tráfico .pcap), calcula su hash SHA-256 inmediatamente y regístralo en tu bitácora de laboratorio junto con la fecha/hora UTC, el comando exacto usado y tu identificación como analista. Es la versión de laboratorio de la cadena de custodia real que exigiría un procedimiento judicial en España bajo el art. 588 sexies LECrim.

Errores comunes del respondedor novato

• Apagar el sistema comprometido inmediatamente. Destruye la memoria volátil (RAM) antes de poder capturarla, eliminando evidencia de procesos maliciosos sin persistencia en disco, claves de cifrado en uso y conexiones de red activas.
• Investigar directamente sobre el sistema en producción sin trabajar sobre una copia/imagen, contaminando la línea temporal (timestamps de acceso) y arriesgando la integridad de la evidencia.
• Saltarse la fase de Identificación y pasar directo a «limpiar» sin haber delimitado el alcance real del incidente, dejando hosts comprometidos sin detectar que reinfectan el entorno tras la recuperación.
• No documentar en tiempo real. Reconstruir la cronología de memoria dos días después introduce errores y omisiones que debilitan tanto el informe técnico como su valor como evidencia.
• Comunicación descontrolada. Enviar correos internos sobre el incidente por un canal que el propio atacante podría estar monitorizando (si hay compromiso de correo corporativo), alertándolo antes de completar la contención.
• Confundir erradicación con contención. Dar por cerrado el incidente tras aislar el host, sin haber identificado y eliminado la causa raíz (credencial robada, vulnerabilidad, persistencia), lo que provoca reincidencia días después.
• Ignorar la fase de Lessons Learned por presión de «volver a la normalidad», perdiendo la oportunidad de convertir el incidente en mejora real del programa de seguridad.

Ejercicio propuesto

Antes del próximo módulo, completa estas dos tareas en tu bitácora de laboratorio:

1. Monta el laboratorio completo descrito en este módulo: VM-Analista + VM-Víctima-Windows + VM-Víctima-Linux conectadas por red host-only, sin salida a Internet. Verifica conectividad entre las tres con ping y documenta las IPs asignadas. Toma una snapshot «estado limpio» de cada VM víctima.
2. Practica la cadena de integridad: crea un archivo de texto cualquiera en tu VM-Analista simulando ser un artefacto de evidencia (por ejemplo, evidencia-ejercicio1.txt), calcula su hash SHA-256 con Get-FileHash (Windows) o sha256sum (Linux), regístralo en un log con fecha/hora UTC, modifica un solo carácter del archivo y vuelve a calcular el hash para comprobar que cambia por completo. Redacta en tres o cuatro líneas por qué esta comprobación es la base de la cadena de custodia digital.

Guarda las capturas de pantalla de ambos ejercicios: las usarás como referencia en módulos posteriores cuando adquieras evidencia real (memoria y disco) de las VMs víctima.

Preguntas frecuentes

¿Es lo mismo NIST SP 800-61 que PICERL de SANS?

Describen el mismo ciclo de vida con distinto nivel de granularidad. NIST SP 800-61 Rev. 2 define cuatro fases (Preparation; Detection & Analysis; Containment, Eradication & Recovery; Post-Incident Activity). SANS, en su formación GCIH/SEC504, desglosa la tercera fase de NIST en tres fases independientes y separa Identificación de Detección/Análisis, resultando en seis fases resumidas en el acrónimo PICERL. En el examen GCIH y en la práctica profesional encontrarás ambos términos usados indistintamente.

¿Necesito hardware potente para el laboratorio del curso?

El mínimo funcional es 16 GB de RAM, un procesador con virtualización habilitada (VT-x/AMD-V) y 150-200 GB de disco libre, preferiblemente SSD. Con 8 GB de RAM podrás avanzar, pero tendrás que ejecutar las VMs de una en una en lugar de simultáneamente, lo que ralentiza bastante los ejercicios de red.

¿Por qué la red del laboratorio debe estar aislada de Internet?

Porque en módulos posteriores trabajarás con muestras de malware real o simulado y con técnicas de post-explotación con fines didácticos. Una red host-only sin salida a Internet garantiza que nada de eso pueda propagarse a tu red doméstica/corporativa ni «llamar a casa» a un servidor de mando y control real. Es además la práctica estándar en cualquier laboratorio DFIR profesional.

¿Qué diferencia hay entre CSIRT y CERT?

En el uso actual son términos prácticamente equivalentes: ambos designan un equipo de respuesta a incidentes de seguridad. La diferencia es histórica: CERT fue originalmente una marca asociada al CERT Coordination Center de Carnegie Mellon, por lo que muchas organizaciones y estándares internacionales prefieren el término genérico CSIRT (Computer Security Incident Response Team) para evitar cuestiones de marca registrada.

¿Por qué se recalcula el hash de la evidencia varias veces durante una investigación?

Porque el hash es la única prueba matemática de que un archivo de evidencia no se ha modificado desde su adquisición. Se calcula en el momento de adquirir la evidencia (por ejemplo, al crear una imagen de disco) y se vuelve a calcular cada vez que se accede a ella para analizarla, comparando ambos valores. Si no coinciden, la evidencia se considera comprometida y pierde valor probatorio; si coinciden, se demuestra la integridad de la cadena de custodia.

El proceso PICERL/NIST y el laboratorio que has montado en este módulo son el armazón sobre el que se apoya el resto del curso: en los próximos módulos usarás estas mismas VMs para practicar adquisición de memoria volátil, análisis de disco con Autopsy, análisis de logs de Windows y Linux, y reconstrucción de la línea temporal de un ataque completo. Vuelve a esta guía cada vez que necesites recordar en qué fase del proceso te encuentras y qué entregable corresponde a cada una.

«Incident response is a critical component of information security programs; it is an important part of information security programs because performing incident response effectively is a complex undertaking. Establishing a successful incident response capability requires substantial planning and resources.»
— NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide. Fuente: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf