Una de las principales funciones de un SOC es la Gestión de Incidentes de Seguridad. Este servicio comprende la notificación de incidentes a los afectados así como a los responsables de la red atacante, en la mayoría de los casos. Aunque pueda parecer que es algo poco importante, considero que es una de las fases más cruciales en la gestión de incidentes, ya que debe transmitir claramente a la persona interesada los hechos ocurridos, la importancia del problema y la solución del mismo.
Parece un mal endémico del personal técnico el no tener una buena capacidad de redacción y síntesis; podemos hablar sobre multitud de conceptos técnicos, utilizando una infinitud de palabras en inglés pero parece que no seamos capaces de sintentizar y trasladar a un lenguaje más coloquial un incidente de seguridad que hayamos detectado.
Repasando un documento de ENISA sobre ejercicios para la gente de un CERT, revisé el que habla del contacto con terceros para la notificación de un incidente. En este ejercicio se practica la forma en que se avisa a los interesados de algo que ha ocurrido, cuáles han sido las posibles consecuencias y qué deseamos que hagan para solucionarlo.
Esto que parece tan simple, en ocasiones se convierte en un correo electrónico con un texto “copy-pasteado” hecho con retales de otros correos, con información sin aclarar muy bien de dónde sale o qué representa y con unas instrucciones un poco vagas. Por esto, quería recoger las ideas que propone ENISA para la redacción de una buena notificación.
Por mi experiencia, el correo debe ser breve y conciso en lo que se desea transmitir, y ajustarse al perfil del destinatario del correo, normalmente personal técnico pero sin grandes conocimientos de seguridad, para que este correo no genere rechazo.
Lo primero de todo es presentarse. En un par de líneas, debemos decir quiénes somos. Este paso tendrá que omitirse si ya nos conocen porque no queremos resultar repetitivos ni queremos que se vea nuestro correo como algo automático que redactamos sin pensar. No podemos dejar que la información empiece en el tercer o cuarto párrafo, que es lo que realmente queremos transmitir del incidente.
Lo segundo es una descripción clara de lo que ha ocurrido. Debemos dejar de lado los tecnicismos, las definiciones extensas o referencias a otros sitios. “Ha recibido un ataque al servidor web tal desde tal, cuyas consecuencias han sido/han podido ser…” sería una forma aceptable. Pensadlo un momento. A un responsable de departamento le dará igual si ha sido una inyección SQL en el parámetro id del recurso vulnerable.php, poniendo nosequé cosa o si se trata de un RFI apuntando a un servidor de Rusia o Botswana. Esto puede ir más adelante, pero no en este momento, donde queremos transmitirle lo que ha ocurrido y el impacto que haya podido tener. Debemos evitar extendernos demasiado. También facilitará la lectura y evitará que confundamos al receptor. Un párrafo únicamente a modo de resumen ejecutivo será más que suficiente.
Ahora las evidencias. Una vez ha comprendido lo que ha ocurrido, podemos explicarle el cómo. Ya podemos nombrar qué técnica o herramienta se ha utilizado o qué vulnerabilidad ha sido explotada; podemos hablar de siglas y aportar cuantas evidencias tengamos de nuestros registros de cortafuegos, IDS o cualquier sistema de monitorización que ayude a entender técnicamente lo ocurrido. Qué impacto y consecuencias ha podido tener, por qué ha ocurrido ahora (algún servidor desactualizado, por ejemplo); pero tampoco sin llegar a aburrir. Ofrecer la mayor información posible no significa aportar la mayor cantidad de datos. Copiar una captura del registro de alertas del IDS repetidas, aunque sea una docena, no aporta nada y puede causar un efecto disuasorio. Si tenemos más datos, se puede entregar como adjunto pero las evidencias técnicas deben ser las mínimas necesarias para comprender el alcance y su impacto. En un par de párrafos con referencias a los archivos adjuntos podemos dejarlo claro.
Por último, tenemos las acciones que queremos que tomen. Quizá sea necesario que nos aporten más información para conocer el alcance o efectividad del incidente; o quizá queramos que reinstalen un sistema por completo, pero debe quedar lo más claro posible aquello que queremos que hagan. Hay que evitar ambigüedades o acciones poco precisas, teniendo en cuenta que quizá no tengan muchos conocimientos de seguridad. También hay que dejarles a ellos un poco de margen de maniobra, ya que ellos conocerán mejor que nadie sus sistemas y qué acciones pueden ser las mejores, pero habrá que asegurarse de que hayan comprendido el problema y cómo solucionarlo.
Un vez hemos transmitido el mensaje que queríamos debemos despedirnos con información sobre nosotros mismos. Se debe incluir un pie de firma con los datos de contacto y firmar digitalmente el correo. Siempre se habla de la poca seguridad de los correos y debemos transmitir una imagen de profesionalidad, utilizando firmas que certifiquen la autenticidad y la integridad del mensaje. Si enviamos información confidencial, deberemos cifrar el mensaje con un mecanismo acordado previamente entre las partes.
Como conclusión, quiero remarcar que los correos deben ser concisos y aportar la mayor información sin parecer un correo automático o una captura de un log del sistema, ya que estos crean poco interés en el receptor y puede que se le dé menos importancia de la que tenga en realidad. Utilizar un lenguaje entendible por personas con poco conocimiento en seguridad y huir de texto pegado de registros de sistemas. Esto último puede ir en archivos adjuntos.
Se debe transmitir la importancia en este primer correo y, si fuera necesario, enviar tantos correos como nos solicite el destinatario para aclararle sus dudas, pero que no caigan en saco roto por parecer siempre iguales.
