¡Estimados amigos del blog!

En esta ocasión os traemos una aproximación al marco de trabajo RE@CT sobre respuesta a incidentes, que espero os sea de ayuda. A mí me cambio la vida, no soy el mismo, y ahora lo “codifico” todo así 🙂 Pero vayamos por partes.

Seguro que conoces la Matriz Mitre Att@ck, un repositorio, una nomenclatura para clasificar técnicas, tácticas y procedimientos empleados en el mundo del cibercrimen, que nos es tan útil a la hora a de difundir la información, clasificarla, gestionarla, etc.

Ahora venimos con RE@CT, el concepto es similar, una matriz en la que podemos identificar las técnicas empleadas en la respuesta a incidentes. Pero no te quedes con el DFIR, vamos a darle nuestra “visión”.

RE@CT

La matriz identifica las distintas fases en:

  • Preparación.
  • Identificación.
  • Contención.
  • Erradicación.
  • Recuperación
  • Lecciones aprendidas.

Quizás si te dedicas al DFIR profesionalmente tengas más o menos definidas estas fases en tus procesos, con estos u otros nombres, pero la visión que quiero darle a este framework no es para los expertos en la materia, sino para la gente un poco más trasversal, el lector medio que le interesa la ciber, pero quizás no sea su vertical.

Por ejemplo, la fase de preparación, MUY importante, nos duele la boca decirlo en las empresas: si no tienes “cámaras de video” luego no me pidas que revise el video…

Las técnicas que nos enumera la matriz son una guía fenomenal para nuestros departamentos de administración de sistemas, de seguridad, nuestro blue team, por ejemplo, RA1006 Set up a centralized long-term log storage .El framework no está diciendo que tenemos que tener un almacenamiento longevo para nuestros logs. No el que usamos en el SIEM en el mejor de los casos… uno más barato, lento, poco inteligente, pero que nos permita tirar de eventos pasados.

RA1103 y 04, acceso a los logs http. Tenemos los logs del server que hosteamos nosotros, pero no la web que tenemos en el proveedor… pero si nos hacen un defacement en la web pública nos quedamos sin poder investigar nada…porque claro… estaba “fuera”…

Logs de DHCP, se que los guardas… que los exportas de su ubicación por defecto…pero por si acaso, sirva esta guía para tener un control de cuales son estas medidas.

Si seguimos con la fase de identificación, encuentro un montón de ideas de las que siempre hablamos, ¿eres capaz de detectar un fichero borrado? Modificado? Una clave del registro?

Contención, la parte a la que más valor se le suele dar, ¿pero estás preparado? Puedes bloquear un puerto interno ¿ puedes cambiar una ACL en un Switch para una Vlan? Una mac? Todas estas reflexiones las debes hacer antes de tener un incidente, o al menos, tener claro el procedimiento. Nos pasa en muchos clientes que se puede, pero lo lleva “otra empresa” y no se sabe muy bien quien es… se pierde tiempo, que en la contención es primordial.

No creo que haga falta seguir con la enumeración. Lo que si es interesante es que igual que ocurre con Mitre, que tenemos un proyecto de la matriz navegable, con Re@Ct tenemos lo mismo, un mapa en el que podemos trabajar los ítems, dándole el enfoque que queramos.

En este caso, tenemos una categorización por colores de las técnicas enumeradas, en referencia a si son elementos generales, de red, correo, ficheros, procesos, etc… pero lo bueno del map es que podemos configurarlo de la manera que queramos, por ejemplo, pintando el grado de madurez de nuestra organización, imagina un semáforo, y pintamos para cada técnica, si lo tenemos bien (verde), si lo tenemos en el radar o pendiente (amarillo) o si no tenemos cobertura ninguna de la técnica ( rojo). Me parece muy interesante a la hora de documentar a clientes su estado de madurez ante una respuesta a incidentes.

No es Matrix, es la matriz RE@CT de respuesta a incidentes…

Pero el proyecto es mucho más ambicioso, ya que contempla la recopilación de playbooks, una comunidad donde podamos crear elementos “accionables” que además, podemos importar en nuestro The Hive/Cortex &MISP como elementos de automatización de tareas…

Pero por si fuera poco, es una pata del proyecto  Atomic Threat Coverage, lo que pretende ser el punto de unión de “todo esto” que hablamos de Mitre, reglas Sigma de detección, playbooks para automatizar, lenguaje de marcas para poder documentar mitigaciones, procesos de red team para generar el “ruido”, un proyecto BRUTAL que pone nombre y apellidos a toda la cadena de valor desde la nomenclatura del ataque, hasta la detección, hasta lecciones aprendidas, fortificación…

No es Matrix, es la matriz RE@CT de respuesta a incidentes…

Volvemos al principio, y remarco que, si bien esto es un proyecto ambicioso, orientado a la respuesta a incidentes, nos lo podemos llevar a nuestro terreno defensivo.

¡Sigue Aprendiendo!

Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼

>> Más info

¡Gracias por leernos! 😉

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like