Cristián Rojas.
¿Cómo definiría Red Team? ¿Es igual al hacking ético?
Para hablar de Red Team, hay que hablar también de Blue Team. Ambos son equipos que funcionan dentro de la organización: mientras el Blue Team está continuamente mejorando la seguridad en la organización, implementando medidas que permitan reforzar la infraestructura tecnoló- gica, el Red Team busca vulnerar las medidas integradas por este “equipo azul” o encontrar vulnerabilidades que Blue Team no ha controlado.
¿De qué manera funciona una auditoría de este tipo?
Más que una auditoría, Red Team hace un trabajo continuo de buscar vulnerabilidades en la organización. Por lo general, usa las mismas herramientas que utiliza un Ethical Hacker (scanners, frameworks de explotación, engaño por phishing, etc) y apunta a atacar lo más posible: estaciones de trabajo, servidores, documentos en papel, infraestructura física, personas, etc.
Lo más común es que funcione como un trabajo interno, una iniciativa propia de las organizaciones, más que un servicio externo.
¿De qué forma se puede ajustar el ataque a lo que la empresa necesita saber?
Eso depende mucho de qué es lo que la compañía desea saber. Existe la tentación a responder “todo”, pero como el Red Team depende del CISO (Chief Information Securiry Officer) o del Departamento de Riesgo Tecnológico, que dicta los lineamientos y política de ciberseguridad, debe haber previamente una planificación al respecto.
¿Cómo ayuda Red Team a mejorar la seguridad?
El principal valor que aporta a una empresa un Red Team es la continuidad. Un Ethical Hacking es algo periódico, realizado por parte de alguien externo, mientras que el trabajo de un Red Team es algo continuo, que permanece en el tiempo.
¿Cuáles son las claves para formar un “equipo rojo”?
La clave es que las recomendaciones que genere el Red Team sean accionadas, por ejemplo en lo que se refiere al parchado y actualizaciones de seguridad de sistemas. Muchas veces este tipo de vulnerabilidades son descubiertas, las recomendaciones son emitidas para luego ser ignoradas o sobrepasadas por necesidades de negocio, lo cual causa frustración entre los profesionales en ciberseguridad, quienes luego son culpados cuando los ataques ocurren. En resumen, lo más importante es: “Si vas a tener un Red Team, hazle caso”.
¿Qué innovaciones se pueden ver hoy en los Red Teams?
La principal innovación que se ve hoy en los Red Teams es una disciplina llamada Threat Hunting, la cual consiste en la búsqueda proactiva de vulnerabilidades en la infraestructura tecnológica de la organización. Puede sonar muy parecido a lo que hace un Red Team en el día a día, pero Threat Hunting añade un elemento adicional muy valioso: la búsqueda de vulnerabilidades que no son detectadas por herramientas disponibles actualmente mediante investigación basada en evidencia. Es algo así como un “CSI tecnológico”.
A su juicio, ¿un Red Team es accesible para todas las organizaciones?
En esa pregunta hay un “gran depende”. Puede ser tremendamente útil, pero si no hay alguna iniciativa en la cual los hallazgos del Red Team sean accionados (vulnerabilidades mitigadas, políticas mejoradas, etc.), ya sea por el Blue Team o por la organización completa, no tiene sentido implementar un “equipo rojo”.
¿Es parte habitual hoy de los programas de seguridad de las empresas?
Yo diría que tales programas están en su “infancia” en Chile. La ciberseguridad es algo que lleva menos de dos años siendo un tema importante, e independientemente de las iniciativas que el Estado pudiera ejecutar, las empresas están recién implementando áreas de ciberseguridad o riesgo tecnológico. Sin embargo, este tipo de equipos debería empezar a aparecer progresivamente, sobre todo en empresas grandes.
¿Recomendaría que las empresas incorporen un Red Team en sus estrategias de seguridad?
Más que recomendar un Red Team, mi consejo es que cualquier iniciativa de ciberseguridad en las organizaciones (monitoreo, uso de SIEM/IDS/IPS, concientización, Red Team, etc.) debe necesariamente ir acompañada de un accionamiento, el controlar riesgos y mitigar las vulnerabilidades encontradas. De otra manera, tales iniciativas no tienen ningún sentido.
Cristián Rojas es Ingeniero Civil en Computación y Magíster en Ciencias Mención Computación de la Universidad de Chile, Profesional Certificado en Desarrollo de Software Seguro (CSSLP); Implementador Líder ISO/IEC 27001:2013 y Consultor Experto en Seguridad de la Información.
