Los incidentes de seguridad son un caso muy interesante de informe técnico, ya que tienen unas características particulares que debemos tener en cuenta a la hora de plasmarlas en un informe.
Os mostramos a continuación unos consejos (adicionales a los ya vistos en artículos anteriores) para que vuestros informes de incidentes de seguridad salgan “niquelados”.
Conoce tus tipos de informe
Los incidentes de seguridad tienen varias fases, existiendo varios tipos de informe en función de la audiencia y el objeto del mismo. Conocer qué es lo que esperan recibir en su informe es la mitad del éxito.
Tipos de informe:
- Informe de detección: Se ha detectado y confirmado un incidente de seguridad. En este informe (dirigido a los responsables técnicos) se cuenta en 2-3 párrafos lo que se sabe hasta el momento del incidente, estimando sistemas afectados e impacto. El objetivo es iniciar la respuesta ante el incidente, primando la rapidez sobre la exactitud.
- Informes “de batalla”: Son actualizaciones del informe de detección, resumiendo las acciones tomadas por el equipo de respuesta ante incidentes. A medida que se va avanzando en la respuesta, estos informes tendrían que incrementar su exactitud (vamos sabiendo con más detalle lo sucedido).
- Informes de crisis: El objetivo es el mismo que los informes de batalla, pero la audiencia pasa a ser personal no técnico (dirección y/o legal). Prima la claridad del mensaje, y se debe de tener cuidado con lo que se dice (ojito con la exactitud)
- Informes de IOC (Indicators of Compromise): Son informes destinados a compartir inteligencias con otros departamentos o entidades. En muchos casos están anonimizados (sin información del origen), y constan de 1-2 párrafos introductorios y de un listado de IOC (Indicadores de Compromiso) para que sean comprobados por los receptores.
Consejo 1: Identifica el tipo de informe que tienes que redactar.
Estructura tu informe
A lo largo de los artículos hemos propuesto una estructura de informes técnicos básica. En el caso de incidentes de seguridad proponemos una ampliación a esta estructura avanzada:
- Resumen ejecutivo: Qué ha pasado. Claro y conciso, sin terminología técnica.
- Timeline del incidente: Ver apartado propio.
- Datos del entorno.
- Gestión del incidente: Qué acciones se han tomado para responder al incidente.
- Análisis forense: Si se han realizado análisis forenses, resultados de los mismos (puede ir también como anexo en función de su extensión).
- Análisis de malware: Si se han realizado análisis de malware, resultados de los mismos (puede ir también como anexo en función de su extensión).
- Impacto del incidente: Determinamos (o estimamos) el impacto del incidente (datos perdidos, equipos afectados, daños causados, etc…)
- Atribución: Indicamos (en la medida de lo posible, ojo) quién ha podido ser el causante del incidente
- Recomendaciones de seguridad: Qué medidas debemos tomar para que este incidente no se vuelva a repetir.
- Lecciones aprendidas: Qué se ha hecho bien, qué se ha hecho mal y qué acciones se deben tomar para hacerlo mejor en el próximo incidente.
- Anexo 1: IOC (listado por categorías)
- Anexo2: Evidencias (todo aquello que por su extensión no tiene cabida en la gestión del incidente).
Consejo 2: Estructura correctamente tu informe (recuerda el uso de plantillas)
Exactitud por encima de todo
La exactitud es clave en la respuesta ante un incidente. Dado que en buena parte de la gestión todo son incógnitas, el tener puntos de referencia verificados es crítico para el éxito de la respuesta.
Cuando se redacta el informe es muy importante recalcar todas las afirmaciones realizadas y reforzarlas con evidencias. Si dices en tu informe “se buscaron en los logs del servidor web conexiones de la IP atacante y se comprobó que la primera conexión se produjo el 7 de enero a las 16:32h”, demuéstralo con un extracto de los logs.
Una táctica muy útil es la de poner en el informe los comandos ejecutados, añadiendo debajo la parte de la salida que nos interesa. Siguiendo con el ejemplo anterior, mostraríamos el log del servidor web y el comando empleado:
Si se añaden los logs en bruto en un soporte físico, estamos ofreciendo al lector del informe la repetibilidad de nuestras acciones (es decir, poder ejecutar el mismo comando sobre los mismos logs y obtener el mismo resultado), lo cual incrementa la credibilidad de vuestro informe.
Consejo 3: Mantén la mayor exactitud posible en tu informe. Intenta dar repetibilidad de tus acciones siempre que puedas.
Cuenta lo que se ha hecho
Redactar el informe de un incidente de seguridad es a veces una tarea peliaguda, porque cabe la posibilidad de que tu informe sea analizado con lupa (o microscopio electrónico), cuestionando todas y cada una de tus decisiones.
El problema es que la respuesta ante incidentes parte de una premisa básica (la detección del incidente), pero luego puede tomar múltiples caminos en función de las acciones tomadas, el momento en el que se llevan a cabo y la persona que las ordena.
Nuestro jefe es garante de una gran sabiduría popular, y comenta a veces cuando hablamos de respuesta ante incidentes que “a cojón visto, macho seguro” (versión castiza de “es fácil hablar a toro pasado”).
Nos ha tocado leer una buena pila de informes de incidentes, y en los primeros siempre existe esa sensación de “con lo fácil que era cómo es que no lo han visto antes” (sobre todo si el informe está bien escrito y lo explica todo con claridad). Luego te toca a ti uno de esos incidentes bien complicados, y te das cuenta de que sobre el terreno las cosas “ya no son tan fáciles”.
Lo que se pretende decir es que no hay que adornar las acciones tomadas ni modificarlas para que quedemos mejor en el incidente. Como hemos dicho antes, un informe tiene que ser exacto, tanto en lo bueno como en lo malo (y para eso están las lecciones aprendidas). Un lector con experiencia sabrá ponerse en vuestra piel y evaluar sin problema si las acciones tomadas han sido o no correctas.
Consejo 4: No adornes las acciones tomadas, cuenta lo hecho tal y como se hizo
Distingue claramente hechos de hipótesis
Uno de los errores más frecuentes en la redacción de informes de incidentes de seguridad suele ser dar por hechas suposiciones de los investigadores, es decir, convertir hipótesis en hechos. En respuesta ante incidentes es crítico el saber distinguir entre ambos.
Los hechos son, como indica la RAE, acciones que mantenemos como sólidas (al menos hasta que otro hecho de mayor peso nos diga lo contrario). Ejemplos de hechos:
- En el servidor PEPITO hay 4 cuentas de usuario con privilegios de administrador.
- La usuaria MENGANITA inició sesión en el servidor PEPITO el 7 de enero a las 14:32h.
- Se encontraron varios ficheros .zip de 1Gb con datos de la Organización en la carpeta /tmp del servidor PEPITO.
Las hipótesis (suposiciones de algo posible o imposible para sacar de ello una consecuencia) son necesarias para la respuesta ante un incidente, ya que en primer lugar prácticamente nunca vamos a tener toda la información necesaria para saber con exactitud lo sucedido. En segundo lugar, las hipótesis son en realidad una herramienta de trabajo del analista, ya que las necesita para realizar su investigación. Pongamos algunos ejemplos de hipótesis:
- Los atacantes del servidor PEPITO son norcoreanos.
- La usuaria MENGANITA tenía una contraseña débil en su cuenta.
- Los atacantes emplearon los privilegios de la usuaria MENGANITA para acceder al servidor PEPITO.
- Una conspiración judeo-masónica-gallega-zurda-bebedora-de-Cruzcampo ha usado 4 0-days para robar información de la Organización.
Si os dais cuenta, las cuatro hipótesis son posibles (en tanto que son físicamente realizables), pero la última si la analizamos con detalle sea poco probable. En todo caso, una vez puestas encima de la mesa lo que debemos hacer es evaluar esas hipótesis e intentar contrastarlas con hechos.
Tomemos por ejemplo la tercera hipótesis: “Los atacantes emplearon los privilegios de la usuaria MENGANITA para acceder al servidor PEPITO”. Esta hipótesis puede comprobarse con una cierta facilidad, ya que bastaría con comprobar que:
- La usuaria MENGANITA tenía privilegios sobre el servidor PEPITO (preguntando al controlador de dominio o accediendo al servidor).
- La usuaria MENGANITA ha iniciado sesión en el servidor PEPITO (buscando en los logs del servidor PEPITO o en los del controlador de dominio).
En un informe de un incidente de seguridad no tiene cabida la opinión. Por mucho que tu instinto diga “han sido los norcoreanos”, si no tienes datos que soporten esa opinión, no deberías ponerla en tu informe.
Consejo 5: Toda hipótesis tiene que estar sustentada con hechos.
Data todas tus acciones y genera una timeline de eventos
La documentación de los tiempos es muy importante en una respuesta ante incidentes. Por poner un ejemplo, a la hora de redactar un informe deberías de tener marcados todos estos tiempos:
- Detección de una pieza de malware en el equipo X.
- Extracción del dominio de mando y control de un malware.
- Solicitud de bloqueo del dominio a seguridad perimetral.
- Bloqueo efectivo del dominio.
Estos tiempos son fundamentales a la hora de evaluar una respuesta ante incidentes y comprobar que se ha actuado de forma correcta (por ejemplo, puede ocurrir que se hubiera solicitado el bloqueo un día y que no se hubiera aplicado hasta el siguiente).
Otra ventaja adicional de documentar los tiempos del incidente es que permiten generar una línea temporal de eventos, algo que permite narrar el evento de forma resumida con facilidad. Veamos un ejemplo:
- 15/Ene 23:45h – Los atacantes envían el correo malicioso a diversos usuarios.
- 16/Ene 09:32h – La usuaria MENGANITA abre el correo malicioso e infecta su equipo.
- 16/Ene 09:33h – El malware contacta con el C2 HTTP atacantes.com
- 16/Ene 10:01h – Los atacantes inician sesión en el servidor PEPITO con las credenciales de MENGANITA.
- 16/Ene 10:01h – Los atacantes acceden a diversas bases de datos del servidor PEPITO, extrayendo información y guardándola en la carpeta /tmp
- 17/Ene 12:07h – Los administradores de sistemas reciben una alarma de disco al 90% en el directorio raíz del servidor PEPITO. Al observar los contenidos deciden alertar a ciberseguridad.
- 17/Ene 12:10h – El personal de ciberseguridad verifica que se trata de un incidente de seguridad.
- 17/Ene 15:33h – Se analizan los accesos al servidor PEPITO y se comprueba que la usuaria MENGANITA parece ser la originaria. Se solicita un volcado de memoria y unos datos de triage de su equipo.
- 17/Ene 17:27h – El CAU entrega los datos de triage del equipo.
- 17/Ene 18:49h – Ciberseguridad detecta la existencia del malware de acceso remoto ZUTANITO en el equipo de MENGANITA, y localiza el C2 HTTP atacantes.com, solicitando a seguridad perimetral su bloqueo urgente.
- 17/Ene 19:01h – Seguridad perimetral bloquea de forma efectiva el dominio.
- 17/Ene 19:09h – Ciberseguridad revisa todos los logs del proxy de salida y comprueba que el equipo de MENGANITA es el único que ha contactado con ese dominio de C2.
- 17/Ene 19:32h – Ciberseguridad localiza el correo malicioso, y avisa al resto de usuarios para que procedan a su eliminación.
En unas líneas, y con ayuda de los tiempos, se explica perfectamente el incidente junto con las medidas tomadas y lo que ha costado cada paso. De esta forma quedan bien claros los esfuerzos realizados y la demostración de la debida diligencia en la gestión del incidente.
Consejo 6: Pon fecha y hora a todas las acciones, y genera una línea temporal de eventos.
Crea un listado de equipos y usuarios afectados
A medida que va avanzando el incidente, ten un listado de usuarios y equipos afectados, y preséntalo como un apartado o un anexo. De esta forma facilitarás la fase de recuperación (cambio de contraseñas, formateo de equipos, etc…) del resto de compañeros de Sistemas/CAU, y ayudarás a calcular el impacto del incidente (¿cómo? ¿qué FULANO está comprometido?).
[Nota extra]: Cuando listes los equipos, usa el nombre del equipo, la dirección IP y (si puedes) la MAC. No será la primera vez que un DHCP o un nombre mal leído formatea el equipo equivocado (y, sobre todo, deja un malware suelto).
Consejo 7: Genera dos listados: uno con los usuarios y otro con los equipos afectados.
