Red, Blue y Purple Team: Combinar las funciones de Seguridad para optimizar los resultados

Los términos Red Team «Equipo Rojo» y Blue Team «Equipo Azul» se utilizan para hablar de dos equipos de Seguridad diferentes que trabajan enfrentados dentro de una organización. El objetivo de tener equipos adversarios es mejorar aún más la Seguridad de una organización. Sin embargo, este enfoque es imperfecto porque, por lo general, descuida errores fundamentales en la forma en que estos equipos cooperan entre sí. En lugar de colaborar estrechamente, suelen dejar pasar oportunidades que beneficiarían a ambos.

Cuando las organizaciones no son capaces de proteger todos los frentes, la ofensiva sigue logrando sus objetivos de invasión. Si el equipo ofensivo lo logra siempre con éxito, significa que no se ha maximizado el objetivo de su trabajo, que es ponérselo muy difícil a los atacantes reales. Lo mismo puede decirse de la defensa: si el equipo no comprende bien cómo trabajan los atacantes, tiene pocas probabilidades de crear una infraestructura resistente, que pueda obstaculizar y limitar a los atacantes hasta que puedan ser expulsados de las redes de forma segura.

La relación tradicional de adversarios no funciona; enfrentar al Red Team contra el Blue Team es cosa del pasado. Veremos cómo entrelazar las dos unidades para crear una relación simbiótica que permita obtener resultados mucho mejores para ambos equipos. Esto se conoce como el Purple Team «Equipo Morado» (consulte la figura 1). Además, la automatización desempeña un valioso papel en los entornos de Seguridad actuales, porque los resultados suelen ser mejores cuando los red y blue teams logran más con menos. Por eso hay que esforzarse por lograr más mediante la automatización.

El Red Team se centra generalmente en irrumpir en la organización y demostrar el riesgo existente, con el fin de que la organización pueda mejorar su Seguridad. Si el equipo logra su objetivo, significa que el valor y la utilidad general del equipo está disminuyendo. Hay que tener en cuenta que el principal trabajo de un equipo de este tipo es hacer más difícil el trabajo de los pen testers, pero con mucha frecuencia estos se enorgullecen de irrumpir en las organizaciones por medios triviales.

Esto no significa que contar con un Red Team y hacer tests de penetración no sea una inversión necesaria. Los tests de penetración son controles y prácticas de Seguridad muy eficaces, como se señala en documento técnico de SANS «State of Application Security: Closing the Gap»; sin embargo, los ataques actuales hacen necesario un nuevo enfoque para mejorar no solo el éxito del equipo atacante, sino también la defensa a largo plazo y, en resumen, la Seguridad general de la organización, que siempre ha sido el objetivo de los equipos.

La tarea del Blue Team es detectar a los adversarios e impedir que irrumpan en la infraestructura de la organización. Esta tarea es monumental: los límites de la infraestructura de IT de una organización a menudo no están definidos y cambian constantemente. Mantener actualizadas las aplicaciones resulta una labor demandante, y no hay que olvidar que siempre hay algún usuario que facilita, sin querer, la entrada de los atacantes en la organización. Otro aspecto a considerar: la organización se enfrenta a la amenaza cada vez mayor de los zero-day exploits, que un hacker puede usar para obtener acceso a la infraestructura. La IT invisible (Shadow IT), conocida también como «IT no autorizada», es una infraestructura no administrada por la organización que podría permitir a los atacantes entrar en su infraestructura. El papel del Blue Team sería el de un portero en un partido de fútbol, con la diferencia de que el poste cambia constantemente y los atacantes utilizan todo tipo de balones para marcar goles.

Incluso con estos desafíos, la prevención da sus frutos. Cuanto más esfuerzos se dediquen a la prevención, más probabilidades hay de que los atacantes opten por rendirse e irse a objetivos más sencillos. Si se le dedica más esfuerzo a la detección de posibles riesgos, es probable que se pueda frustrar a los hackers antes de que logren sus objetivos. De esta forma, ellos pierden su tiempo y su dinero, y la organización queda protegida. En este escenario, todos ganan, aunque inicialmente existiera un riesgo.

En el panorama actual de la Seguridad, la relación de adversarios tradicional no funciona. Enfrentar al Red Team contra el Blue Team es cosa del pasado. Es mucho mejor combinar las dos unidades para crear un «Purple Team» que mejore la cooperación y permita lograr mejores resultados. A continuación daremos algunos consejos para mejorar la fusión de ambos equipos.

Como hemos dicho, la tarea del Red Team es complicarse más la vida. Por lo tanto, si puede entrar por medios sencillos, por ejemplo, con credenciales filtradas, vulnerabilidades y exposiciones comunes u otros medios de bajo coste, lo más probable es que el equipo pueda invertir en otros aspectos de la Seguridad en lugar de hacerlo en tests de penetración. Entonces, ¿cómo puede el Red Team seguir contribuyendo y no perder ingresos ni su razón de ser? Los siguientes enfoques muestran rápidamente las ventajas y permiten que los equipos empiecen a colaborar para poner las cosas más difíciles.

Empecemos por el alcance. Determinar el alcance de un test de penetración no es una tarea sencilla. El Blue Team no siempre conoce necesariamente su propio ámbito por completo, ni sabe cómo trabajan los atacantes. Como pen tester, también es difícil determinar el ámbito a testear solo con la información proporcionada por el objetivo, generalmente en reuniones sobre el tema. Esto está lejos de ser ideal, porque los procesos de reconocimiento, detección y análisis de un test de penetración suelen detectar nuevas superficies de ataque. Cambiar el alcance del test después de determinarlo suele dejar una sensación agridulce, porque podría acarrear más gastos u obligar a los pen testers a trabajar con un ámbito limitado, mientras que los adversarios reales no sufrirían esas limitaciones.

En su lugar, sugerimos un enfoque mucho más práctico, rentable y eficiente. El test de penetración se divide en dos entregas. En primer lugar se produce una fase de reconocimiento, detección y análisis del objetivo con un ámbito fácil de determinar. Esto tiene un coste mucho menor que el de un test de penetración completo y permite a los diferentes equipos generar confianza entre ellos. O, en el caso de los pen testers internos, esta interacción permite al equipo centrarse en realizar un trabajo minucioso en las fases de reconocimiento, análisis y detección, que los pen testers suelen considerar como las más valiosas. Además, resulta una experiencia más satisfactoria para los pen testers porque se tiene en cuenta el ámbito que han propuesto y no sienten que los tests se están haciendo en los objetivos equivocados. En la figura 2 se detallan las fases abstractas de un test de penetración y cómo puede dividirse en dos entregas, creando un escenario en el que todas las partes involucradas salen ganando.

Image

El resultado de la fase de reconocimiento puede incluir resúmenes por colores de los activos que el Red Team considera que son más importantes y que deben incluirse en el ámbito, y puede abarcar todos los temas disponibles, lo que aumenta la superficie de ataque. Estos son:

• Servidores y aplicaciones clásicos, que son los aspectos típicos que se incluyen generalmente en un test de penetración tradicional.
• Aplicaciones y activos móviles que a menudo las organizaciones pasan por alto.
• Usuarios, preferiblemente una lista de quién está en cada unidad de Negocio; por ejemplo, gestión, operaciones de IT, desarrolladores, servicio de asistencia técnica y recepcionistas. Cada una de estas unidades tendrá su propia superficie de ataque (es decir, los altos cargos suelen ser objetivos de fraudes de phishing, el departamento de IT es objeto de ataques OSINT, y el servicio de asistencia técnica y los recepcionistas podrían ser vulnerables a las solicitudes de restablecimiento de contraseñas a través de llamadas telefónicas).
• Datos filtrados, servidores mal configurados y otras vulnerabilidades detectadas sin explotación. Se trata de objetivos de ataques sencillos que se pueden solucionar antes de que el Red Team se enfrente a la infraestructura.

El equipo puede proponer un ámbito de testeo con un informe en el que se detalle la superficie identificable de ataque que el Red Team podría detectar. El Blue Team puede entonces introducir en el informe los activos no identificados, y ambos equipos pueden finalmente llegar a un acuerdo completo y transparente sobre un ámbito que contenga los activos más importantes. En muchos casos, el informe de reconocimiento por sí solo contendrá suficientes detalles que el Blue Team querrá abordar para que este proceso aporte valor.

Lo siguiente que puede hacer el Red Team es revisar cómo ampliar los reportes de los tests de penetración. Estos informes suelen incluir un resumen ejecutivo, una descripción general de los hallazgos y detalles sobre los distintos hallazgos. Cuando se generen informes para la colaboración del Purple Team, pueden incluir los reportes habituales ampliados, para que tengan mayor valor para el Blue Team.

Por ejemplo, el Red Team debería esforzarse por ofrecer múltiples sugerencias para solucionar las diferentes vulnerabilidades detectadas. Estas sugerencias pueden incluirse en el resumen ejecutivo para que los ejecutivos vean las diferentes maneras de eliminar y mitigar los riesgos. Además, gracias a los amplios conocimientos del Red Team en materia de evasión de la Seguridad, este equipo puede aportar más recomendaciones en el informe sobre cómo detectar y responder adecuadamente a las vulnerabilidades identificadas. Lo ideal sería que el informe se centrara no solo en solucionar las vulnerabilidades, sino también en aconsejar cómo puede el Blue Team corregir los procesos para gestionar dichas vulnerabilidades de forma más fiable y consistente en el futuro. En la figura 3 se muestra cómo se puede ampliar y desarrollar un informe tradicional para que aporte más valor al Blue Team.

Image

Por último, el Red Team debe valorar las diferentes formas de presentar la información. Los editores de texto no son necesariamente el mejor formato, porque no facilitan la comunicación. Mientras el Blue Team se ocupa del cribado, parcheado y verificación, lo ideal es tener una forma de hacer el seguimiento de cada uno de los elementos en un sistema independiente. Además, el Red Team quiere seguir haciendo tests y evaluaciones de forma continua, y tener un portal exclusivo puede ayudarles a integrar al Blue Team y mantenerlos al día con notificaciones.

La colaboración es la clave para formar un Purple Team eficiente. Invite a los pentesters a su plataforma de colaboración y comience la conversación:

• Mantenga un debate continuo y sencillo sobre el progreso de la interacción.
• Utilice la plataforma para dirigirse directamente a las personas sobre un tema, de modo que cada miembro del equipo pueda interactuar de forma rápida y eficaz sin tener que rebuscar correos electrónicos ni recordar llamadas telefónicas.
• Utilice Microsoft Teams, Slack y otras plataformas de comunicación para invitar a terceros a interactuar directamente con su equipo y viceversa.

Después, pida al Red Team que intente desglosar los fragmentos individuales de código, como las bibliotecas o el código de saneamiento que se usa en todas las aplicaciones de la organización. En lugar de hacer que el Red Team lleve a cabo un test a gran escala en la primera ronda de la interacción, deje que se centre en el código que crea que debe protegerse y reforzarse. Además, el Blue Team puede centrar sus esfuerzos en asegurarse de que su software cumpla los requisitos de las bibliotecas en todas las aplicaciones. El Red Team también puede encargarse de que los IDEs (entornos de desarrollo integrado) informen sobre la lógica de programación insegura que use datos introducidos por los usuarios o que genere datos sin las bibliotecas de saneamiento adecuadas.

La mayoría de los Blue Teams ya realizan análisis de vulnerabilidades; los Red Teams, sin embargo, suelen irrumpir con medios sencillos. Es buena idea dejar que el Red Team ejecute un análisis preliminar de las vulnerabilidades y elabore un resumen de este informe, o proporcionar al Red Team un análisis existente y pedirles su opinión antes de llevar a cabo otras actividades de test de penetración. Con frecuencia, veremos que esas interacciones tempranas proporcionan tests de penetración de mayor valor y permiten al Blue Team entender mejor sus debilidades antes de confirmar la realización de un test.

Del mismo modo, antes de confirmar el ámbito y alcance del testeo, se recomienda considerar la posibilidad de facilitar al Red Team unas credenciales para activos de alto riesgo que podrían tener graves consecuencias en caso de verse comprometidos. A menudo, las aplicaciones presentarán más vulnerabilidades después de la autenticación. Este ejercicio es especialmente valioso si la aplicación es de alto riesgo, ya que permitiría identificar las posibles amenazas antes de que las credenciales de un usuario se vean comprometidas. Habilitar la autenticación multifactor en la aplicación reduce el riesgo y se podría considerar la posibilidad de limitar el ámbito de los tests a la superficie de contacto y otros activos externos. En la figura 4 se ilustra la naturaleza integral de la comunicación y la colaboración en el Purple Team.

Image

Si algo nos ha enseñado DevOps, es que la automatización es clave para combatir con éxito las amenazas. El Red Team puede realizar simulaciones de violaciones de perímetros de Seguridad para mejorar sus tests de penetración, ya que así se les permite centrarse en los aspectos importantes de los tests, en lugar de centrarse en las tareas más tediosas y repetitivas. Del mismo modo, el Blue Team puede aprovechar medidas similares para centrarse en las tácticas, las técnicas y los procedimientos de detección (TTPs) utilizados por el Red Team. JPCert tiene una visión general de los logs creados por Windows al ejecutar las herramientas que más probablemente utilizarán los intrusos en la red,3 y Thailand Cert comparte información de las diferentes amenazas y las herramientas que usan. El Blue Team debe anticiparse y asegurarse de que sus redes sean capaces de prevenir y detectar la ejecución de los TTPs del Red Team, y esto puede hacerse mediante automatización. El Blue Team también deberá considerar la posibilidad de invertir en medidas para bloquear y aislar automáticamente las presuntas amenazas en la red. En lugar de simplemente desconectar un host de la red, pueden incluir el host en una VLAN privada mientras el Blue Team realiza el cribado. El equipo también puede capturar y reproducir los ataques en distintos entornos para asegurarse de que toda la organización cumple las normas.

Atención con la automatización:

Al implementar la automatización, proceda con cuidado. Considere cómo se registra el proceso de automatización en los dispositivos, por ejemplo, para el análisis automático de un host en riesgo. Hay que tener cuidado también de no compartir sin querer más información con los atacantes, como las credenciales, porque esto les daría más control sobre el entorno. Por ejemplo, se podría decidir que una operación de análisis de las vulnerabilidades use las credenciales de administrador de dominio para analizar un host controlado por el atacante. En este caso, las credenciales podrían ser detectadas y descifradas o podrían transmitirse los códigos hash.

En un ejemplo exitoso de interacción del Purple Team, el Blue Team utilizó una plataforma de colaboración para ofrecer al Red Team una sesión de pantalla compartida en uno de los sistemas potencialmente vulnerables. El Red Team concluyó que se trataba de un falso positivo en tan solo 10 minutos, en lugar de las horas que hubiera tardado normalmente. Además, el Blue Team detectó anomalías en la plataforma de pago de la organización, sin saber si fueron causadas por el Red Team o por otros. Con los registros y las conversaciones, los equipos pudieron descubrir juntos una vulnerabilidad relacionada con la disponibilidad de la plataforma. Se aplicaron los parches necesarios a la plataforma y se corrigió un problema que podría haber causado daños durante varios años.

Para derrotar a los adversarios de forma más efectiva y mejorar la Seguridad general de nuestras organizaciones, los términos Blue y Red deben fusionarse bajo el concepto del Purple Team. Los equipos deben dejar de trabajar como simples adversarios y deben comenzar a colaborar y trabajar al unísono en el futuro. El potencial es tremendo y el listón de partida es muy bajo. La Seguridad de la Información ha llegado muy lejos, pero es esencial seguir desarrollando y buscando nuevas formas que nos permitan seguir defendiéndonos.

Chris Dale es instructor de SANS y enseña SANS SEC504: Hacker Tools, Techniques, Exploits, y Incident Handling. Como responsable de los grupos de tests de penetración y gestión de incidencias de Netsecurity, una empresa con sede en Noruega, Chris aporta una importante experiencia en materia de Seguridad y formación en desarrollo de sistemas, operaciones de TI y gestión de la Seguridad. Es un apasionado de la Seguridad y periódicamente imparte presentaciones, conferencias y talleres. Chris posee las certificaciones GCIH, GPEN, GSLC y GMOB, y participa en debates y en grupos de trabajo de las administraciones públicas para recomendar y mejorar la Seguridad en los sectores público y privado de Noruega