[08/08/2022] Los equipos rojos son un mal necesario -literalmente- en el panorama actual de las ciberamenazas. Las motivaciones para participar en actividades de pruebas ofensivas pueden variar desde los requisitos normativos hasta las aspiraciones de certificación. Los programas de seguridad verdaderamente proactivos y progresivos incorporan operaciones ofensivas casi inmediatamente, a medida que se construye y define la seguridad.
La mayoría de las organizaciones comienzan con el escaneo de vulnerabilidades y luego pasan a las pruebas de penetración (pentesting), llevando el escaneo de vulnerabilidades un paso más allá de adivinar que una vulnerabilidad podría ser explotada, a probar exactamente cómo puede serlo. Los programas de equipos rojos se asocian a menudo, de forma incorrecta, con el pentesting, pero se trata de una función muy diferente.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
El pentesting busca encontrar todo lo posible sin un objetivo definitivo en mente, probando una amplia gama de posibles ataques para confirmar el éxito o el fracaso de ese exploit, o la actividad posterior al exploit. Los pentests generalmente no hacen vectores de acceso iniciales. Las operaciones del equipo púrpura son un punto intermedio natural entre el pentesting y la progresión del equipo rojo para completar esos descubrimientos y mitigarlos activamente en tiempo real para aumentar la resistencia probada frente a la postergada.
Los equipos rojos llevan este modelo de madurez un paso más allá, ejecutando operaciones altamente selectivas que utilizan el ciclo de vida completo del hacking, desde el acceso inicial hasta la exfiltración de datos, para atacar a las personas, los procesos y la tecnología de una organización de forma sigilosa, como si se tratara de una APT. Los equipos rojos adecuados son el siguiente paso en la defensa proactiva, tras las operaciones del equipo púrpura, antes de escalar a verdaderas operaciones de emulación de adversarios.
"Desde la perspectiva del CISO, la incorporación de equipos rojos en su programa de ciberseguridad va más allá de las listas de comprobación y de las evaluaciones de seguridad a grandes rasgos, y facilita técnicas específicas y sofisticadas para poner de manifiesto las vulnerabilidades reales, las lagunas y las deficiencias de sus riesgos más prioritarios", afirma Chris Hughes, CISO de Aquia. Con los modernos marcos de cumplimiento del panorama de amenazas, marcar la casilla de "pentesting" no es suficiente. Hay que pensar y entrenar como luchan los adversarios, e identificar las vías de ataque antes que ellos".
Con esta perspectiva en mente, aquí hay algunas estrategias y políticas que he observado desde la perspectiva de un operador que los líderes pueden implementar para apoyar el éxito del programa de equipo rojo.
1. Deje de limitar el alcance del equipo rojo
Deje que los recursos de su equipo rojo pirateen como lo hacen los adversarios sofisticados. ¿Sabe quién no tiene alcance? Cozy Bear. Deep Panda. APT11. Si está al alcance del enemigo, debería estar al alcance de los equipos rojos. Una vez un gerente dijo en una reunión con otros gerentes que "se sienten cómodos con la idea de que habrá una pérdida de productividad para ciertos usuarios, por un pequeño período de tiempo, durante una operación de equipo rojo. Si somos vulnerables a ese tipo de actividad, tenemos que saberlo ahora por adelantado, antes de que alguien sin las limitaciones de sus "preferencias" lo intente". Hasta el día de hoy fue la cosa más empoderadora que jamás me haya dicho un gerente en mi nombre. Su postura nos permitió llegar a las conclusiones más impactantes y, por lo tanto, a las correcciones basadas en el valor.
2. Capitular las reuniones obligatorias del equipo rojo
El trabajo del equipo rojo es emular a los adversarios, no estar al tanto de lo que ocurre en el departamento de seguridad. Participan en los informes de las partes interesadas y en las inmersiones técnicas inmediatamente después de una operación, pero no asisten a las reuniones como su función principal. Es mucho más eficaz conseguir que un gestor esté en la misma página sobre la narrativa del ataque, los objetivos, los hallazgos y sus calificaciones, y luego hacer que esa persona socialice los resultados en nombre del equipo rojo.
Los miembros del equipo rojo deben ser considerados operadores "detrás de la cortina", mientras que los gerentes y líderes son la primera línea de enlace. Una reunión a la que asista todo el equipo rojo es muy costosa para su empresa y su departamento.
A la inversa, no haga que el equipo rojo sea completamente inaccesible. De hecho, en muchos casos suaviza su trabajo tener relación con otros miembros de la seguridad y de la organización. Cuanto más se les vea como personas y empleados con intereses creados en el éxito de la empresa como todos los demás, menos resistencia encontrarán durante sus pruebas. Las reuniones centradas en la estrategia, GRC, mapeo de controles, CI/CD y otros stand ups del equipo no requieren del equipo rojo.
[11 herramientas de pentesting utilizadas por profesionales]
3. Llevar a cabo informes de las partes interesadas separados de los informes técnicos
Ahorrar tiempo es una cosa, pero gran parte de la información que se repasa en la "maleza" de una inmersión técnica estará fuera de la profundidad y el alcance de una reunión con las partes interesadas. Una de las audiencias se preocupará por la narrativa, las métricas a lo largo del tiempo, los hallazgos persistentes y la mitigación o aceptación de los riesgos resultantes. A la otra le van a importar los puertos, los servicios, la sintaxis, los métodos y el propósito. Tenerlos a todos en la misma reunión para ahorrar tiempo es, en realidad, una pérdida de tiempo. Es más eficaz y eficiente hacer que los equipos rojos elaboren y entreguen por separado dos versiones de sus informes: una para los ejecutivos y los profanos, y otra para los equipos de remediación y orientación técnica.
4. Asignar calificaciones de riesgo y hacer un seguimiento con los propietarios del riesgo
Esto ocurre a nivel de las partes interesadas. Un miembro del equipo rojo puede asignar una calificación de riesgo y adivinar cómo se manejará ese hallazgo después del hecho. Sin saber quién es el propietario del riesgo y a quién hay que hacer un seguimiento de la corrección, su experiencia se quedará ahí. A menudo, en los informes ejecutivos se nos pregunta: "¿Cuál fue el resultado de este hallazgo? ¿En qué punto nos encontramos para remediarlo?" y los equipos rojos no pueden responder. Nos quedamos en nuestro camino y lo entregamos sin saber si se ha corregido, o incluso si se ha revisado. Está ayudando al equipo rojo a ayudar a las partes interesadas dándoles una persona de contacto correlativa al riesgo asociado con sus hallazgos.
5. Estandarizar la asignación de hallazgos y calificaciones de riesgo
Es hora de ir más allá de las clasificaciones CVSS. Son buenas para conocer la dificultad general y la posibilidad de que una vulnerabilidad sea explotada en la naturaleza, pero carecen de contexto organizativo. Si se deja en manos de los equipos rojos, asignarán arbitrariamente una calificación baja, media, alta o crítica. A menudo se reúnen para discutir por qué un miembro del equipo etiquetó un hallazgo con una gravedad particular, y las respuestas varían desde la dificultad de acceso requerida hasta, "¿No tenemos que pensar en esto en un sentido más amplio? Esta vez no ha sido tan grave, pero si está en otro sitio podría ser peor".
La verdad es que las calificaciones asignadas a los hallazgos son subjetivas, por lo que conviene insertar en esa ecuación toda la objetividad posible. Esta es una de las razones por las que soy un gran fan de las calificaciones de riesgo: inherente y residual. La calificación de riesgo inherente tiene en cuenta los factores técnicos y temporales para obtener una calificación ponderada de probabilidad e impacto. Luego se calculan juntos para obtener el riesgo inherente.
Esto es lo más parecido al CVSS sin filtrar que estamos acostumbrados a ver, pero con más metadatos detrás. A partir de la puntuación de riesgo inherente, que suele ser más alta, se asigna también una puntuación de control basada en la red única y en los factores de mitigación para esa organización. El control multiplicado por el riesgo inherente produce un riesgo residual ponderado para esa vulnerabilidad en particular, personalizado para su organización. Esta información es mucho más valiosa.
6. Ser consciente de la cadencia de las operaciones
Los equipos rojos no son pentesters. La cadencia de operaciones del equipo rojo es completamente diferente a la de un equipo de pentest. Los pentesters tienen un conjunto estándar de vulnerabilidades y desconfiguraciones que prueban para tratar de encontrar "todo lo posible", para dar a los defensores la oportunidad de asegurar la cosa tan bien como puedan. Los equipos de pentest también tratan de activar las alertas y ser capaces de informar sobre los hallazgos positivos recogidos por las soluciones EDR y SIEM.
Desde el punto de vista de los probadores, los compromisos de pentest tienen un período de prueba de dos a tres semanas, una semana para redactar el informe y, por lo general, se da la vuelta y se inicia un nuevo compromiso a la semana siguiente. Desde el punto de vista del cliente, por lo general se hace uno al año y se dispone de los 12 meses siguientes para remediarlo.
Por el contrario, los equipos rojos tienen objetivos claros y definidos que tienen un alcance limitado. No realizan todo lo que es posible. Realizan solo las acciones necesarias para alcanzar los objetivos, porque reconocen que cada acción podría, en cualquier momento, alertar a los equipos defensivos de su presencia, y los equipos rojos no quieren una carrera contra el reloj. Los equipos rojos también operan de forma clandestina y necesitan más tiempo para investigar, preparar y probar cadenas de muerte que representen de forma realista el comportamiento de los APT.
Por lo tanto, la cadencia y el ciclo de vida de una operación de equipo rojo serán más lentos y largos, porque el alcance es toda la organización. Téngalo en cuenta cuando establezca los objetivos y resultados clave (OKR, por sus siglas en inglés) del equipo rojo para el año. Por no mencionar que de una operación de equipo rojo suelen salir muchos hallazgos y no todos ellos tienen un TTP correlativo o una mitigación directa. Los equipos de remediación necesitarán tiempo para trabajar en los hallazgos y mitigarlos en la medida de lo posible. Esto es para evitar la fatiga de los hallazgos del equipo azul, que puede pedir al equipo rojo que cancele o posponga operaciones adicionales durante un trimestre, dependiendo de lo atrasados que estén.
7. Haga un seguimiento de todas las métricas
No todas las métricas que demuestran el éxito de un programa ofensivo provienen del equipo rojo. Las métricas del equipo rojo utilizadas para seguir el éxito de las pruebas, y por tanto de la actividad de remediación, incluyen el tiempo medio de permanencia: ¿Cuánto tiempo fueron capaces de persistir en el entorno haciendo descubrimiento y pivote sin ser alertados?
Una métrica del lado azul, además de las mitigaciones recién creadas, como las reglas SIEM y las detecciones EDR, incluirá el tiempo medio de investigación: ¿Cuánto tiempo después de que se produjera la alerta se tardó en empezar a investigar y triar la serenidad del incidente?
Otros factores provendrán de los equipos de inteligencia de ciberamenazas (CTI) y de riesgos en forma de reducción de las puntuaciones de riesgo residual en los hallazgos, mejora de los conocimientos sobre la resistencia frente a actores de amenazas emulados, y probabilidad de que sus libros de jugadas vistos en la naturaleza tengan éxito. Los equipos de CTI podrán centrarse en los actores de amenazas relevantes al saber definitivamente contra qué tácticas se puede y no se puede defender.
A continuación, la concienciación en materia de seguridad y la formación en resiliencia pueden adaptarse a esos métodos. Además, las investigaciones manuales en torno a esos métodos estarán más orientadas al valor, y no serán un juego de adivinar y comprobar los falsos positivos o los falsos negativos.
Por último, tener medidas y procesos de seguridad confirmados en la práctica significa que los departamentos de seguridad entregan la documentación, los informes y los resultados a un auditor y no se les vuelve a preguntar. El GRC también puede demostrar la diligencia y el cuidado debidos a los investigadores reguladores y a las empresas de seguros de ciberseguridad para el inevitable día en que se produzca un día cero. Cuando las actividades del equipo rojo tienen éxito, el efecto se traslada a los departamentos y funciones empresariales.
8. Segregar las funciones y responsabilidades de los equipos rojos
Las operaciones optimizadas de los equipos rojos provienen de un bucle de retroalimentación continua que involucra al CTI, a los equipos rojos, a los ingenieros de detección y al riesgo, todos trabajando juntos para reducir la superficie de ataque en un contexto de valor para la organización. Estas funciones no serán las mismas en todos los organigramas, pero en mi opinión, es mejor tener las responsabilidades separadas.
Muchas organizaciones de seguridad son pequeñas y tendrán a la misma persona con varios sombreros, pero al menos un empleado a tiempo completo dedicado a cada una de estas funciones aumenta significativamente la calidad de las operaciones. En este sentido, los equipos de seguridad también deben estar segregados bajo un director de operaciones, un COO, CRO o CISO, mientras que la gestión de la vulnerabilidad, la gestión de la corrección y las operaciones de TI deben estar bajo un CIO o un director de tecnología. Hacer que el departamento informante (seguridad) responda a la misma cabeza que las personas a las que informa, provoca fricciones y hace que su líder senior sea menos defensor cuando ambas partes necesitan ser aplacadas.
9. Establecer expectativas realistas
Cuando los equipos rojos informan de un plan de operaciones, le darán los objetivos pertinentes y el enfoque aproximado que piensan adoptar para ello. Suele ser algo general como "vía RCE" o "captura de credenciales vía MiTM". La principal preocupación de las partes interesadas es la pérdida de productividad o la denegación de servicio (DoS), y aunque ese nunca es el objetivo, el equipo rojo no enumerará cada paso y método que planea utilizar.
De hecho, durante el desarrollo de los exploits, a menudo tenemos que cambiar nuestras ideas originales mientras depuramos las cargas útiles y aseguramos una ejecución fluida de la TTP. Ser realista con la información que obtendrá de su equipo rojo antes, durante y después de una operación va a disminuir las frustraciones y la impresión de falta de voluntad por parte del equipo rojo.
10. Dé a los equipos rojos dispositivos de ataque fuera de la red
Los equipos rojos, por sus propias buenas prácticas, quemarán y convertirán su propia infraestructura de ataque para cada operación. Para cada operación, las necesidades de esa ruta de ataque se pondrán en marcha y se probarán de nuevo. Por parte de la administración, darles dispositivos segregados de los agentes EDR, AV y SIEM de la empresa, les permitirá probar las campañas de phishing, las páginas de aterrizaje y las cargas útiles, y solucionar cualquier error para que no se pierda el valioso tiempo de la operación durante el periodo de vulnerabilidad.
Esto parece contrario a la intuición, pero los equipos rojos no almacenan datos sensibles de la empresa en estos dispositivos y se pueden seguir aplicando directrices de seguridad para ellos (contraseñas de 20 dígitos, MFA, cifrado de disco, etc.). Los equipos rojos deberían almacenar la información obtenida y exfiltrada en una operación en un entorno de nube seguro. Por lo tanto, el dispositivo realmente sirve como un terminal para las devoluciones de llamada, cuyos comandos también deben registrarse en un servidor remoto. Esto es muy beneficioso para los equipos rojos, ya que es una pérdida de tiempo y recursos de la empresa que accidentalmente quemen una dirección IP o un dominio malicioso en las pruebas semanas antes de que la operación se ponga en marcha, solo para que la operación termine en un SOC con un falso positivo.
11. No amplíe los objetivos del equipo rojo a mitad de la operación
A menudo ocurre que, una vez que se han cumplido los objetivos y se ha diseñado un escenario, surge otro objetivo. Se anuncia una auditoría o se avecina una renovación, y añadir algunas cosas más a la lista de objetivos no parece una gran petición. "¿No podemos hacer que añadan esto mientras están ahí?". La respuesta es no. Una vez más, cuando un equipo rojo se encuentra en un entorno, tiene acceso a muchos recursos y puede hacer muchas cosas, pero se mantiene en el objetivo y evita todo lo que no contribuye al objetivo directo. La ampliación del alcance durante una operación significa que ya no se rigen por un plan de operaciones, que podría tener limitaciones de comportamiento impulsadas por el CTI. Algunos objetivos pueden parecer estrechamente relacionados, pero necesitan ser puntuados en su propia operación para mantenerse fieles a la destreza del equipo rojo.
Todo se reduce a una política eficaz
Al igual que la seguridad es responsabilidad de todos, el éxito de un equipo rojo es responsabilidad de las partes interesadas y de los responsables políticos tanto como de los propios operadores. Los líderes tienen la capacidad de defender a sus equipos ofensivos frente a la política de la organización, los cambios y las opiniones de las partes interesadas. Reconocemos que no siempre somos el departamento favorito de todos, pero los equipos rojos no pueden ser eficaces y tener las manos atadas.
Al fin y al cabo, están ahí para hacer un trabajo que garantice los intereses de la organización y de los clientes. Usted puede hacer su parte rompiendo los silos, comprendiendo y facilitando las técnicas adecuadas, y creyendo y defendiendo sus métodos cuando se pongan en duda. Cualquier equipo rojo seguiría a ese líder en la ciberguerra.
Basado en el artículo de Maril Vernon (CSO) y editado por CIO Perú
Maril Vernon, "SheWhoHacks", es una experta en seguridad informática especializada en pentesting que ha ayudado a las personas a iniciar nuevas carreras en ciberseguridad desde una larga permanencia en una industria no técnica. Después de entrar en la seguridad cibernética para la Guardia Nacional en el 2018, en poco más de un año ha logrado siete certificaciones en pentesting y seguridad en un tiempo sin precedentes, incluyendo: Metasploit Pro Certified Specialist, AppSpider Pro Certified Specialist, AWS Cloud Certified Practitioner, Atomic Purple Teaming y Security+. La experiencia de Maril aparecerá como editor colaborador del CIS AWS Foundation Benchmark v1.3 y CSFI.