Tribu de hackers red team 5.0

Este artículo es el quinto de una serie basada en el libro Tribe of Hackers Red Team de Carey y Jin (2019). Como ya comenté en el primer artículo, en este libro encontramos las respuestas de 47 expertos en red teaming a las mismas 21 preguntas. En las entradas anteriores, hice referencia a las opiniones de (1.0) Carey, (2.0) Donnelly, (3.0) Weidman, y (4.0) Secor. Para esta ocasión, decidí centrarme en las respuestas de Carlos Pérez (Darkoperator), el primer latinoamericano incluido en la serie, quien lleva más de veinte años en el mundo de la ciberseguridad.

Carlos trabajó para el gobierno de Puerto Rico, realizando pentesting y ayudando a proteger sus redes. Más tarde, se unió a Compaq/HP como arquitecto sénior de soluciones para las prácticas de consultoría de seguridad y redes para clientes en Sudamérica, Centroamérica y el Caribe. También trabajó en Tenable como director de ingeniería inversa y, en el momento de la entrevista del libro, era el líder de práctica para la investigación en TrustedSec. Actualmente, Carlos es conocido por sus contribuciones a herramientas de seguridad de código abierto como DNSRecon y Metasploit.

Carlos comienza recomendando conocimientos específicos, divididos en técnicos y no técnicos, que él considera necesarios para quienes quieran formar parte de un red team. En el aspecto técnico, inicia refiriéndose a una base sólida en lógica de programación, un conocimiento esencial para la correcta adaptación a diversos lenguajes de programación, así como para la producción y alteración de herramientas. A continuación, Carlos sugiere una buena comprensión de las redes porque, según dice, la mayoría de las acciones atravesarán este tipo de ambiente. Además, según Carlos, tendrás que entender cómo se configuran, se mantienen y se aseguran los sistemas. Y deberías mantener un método de práctica y aprendizaje constantes, siempre con el objetivo de evitar cualquier sesgo técnico.

En el aspecto no técnico, Carlos comienza destacando la importancia de conocer acerca de las estructuras, la comunicación y el trabajo en equipo de una organización. Precisamente, en cuanto al acto de expresar ideas, reconoce que muchos en este campo son introvertidos. Sin embargo, sin pelos en la lengua, Carlos advierte que si no eres capaz de transmitir información sobre riesgos, mitigación y apoyo de una manera que los responsables de la toma de decisiones puedan utilizar y comprender, entonces habrás fracasado. Por último, él añade la importancia de aprender sobre las nuevas tendencias y buenas prácticas en la industria de TI (que a veces son ignoradas por los profesionales), por ejemplo, Cloud y DevOps.

Al igual que otros expertos cuyas opiniones se han presentado en esta serie, Carlos nos recuerda que no es necesario participar en actividades ilegales para adquirir habilidades de red team. La información, el entrenamiento y el material de referencia para aprender todos los aspectos están disponibles públicamente, y todo puede simularse en un ámbito de prueba para ensayar y validar conceptos. No cometas el estúpido error de jugar al chico/chica malo/a cuando probablemente puedas aprender las mismas habilidades en el proceso para convertirte en un hacker ético, siendo un hacker ético.

Empecemos por el trabajo en equipo. De acuerdo con Carlos, cada miembro del red team debería tener un conocimiento claro del cliente y de los sistemas que se van a evaluar. La planificación debe realizarse precisamente en grupo. Todos los miembros pueden compartir sus opiniones desde el principio, y el equipo puede discutirlas con la intención de llegar a acuerdos. A medida que avance el proyecto, deben realizarse reuniones periódicas para revisar las acciones. Al final de un contrato, debe hacerse un intercambio de opiniones en el que los egos queden a un lado y se diga sinceramente lo que hay que mejorar.

Para Carlos, es falso decir que las nuevas técnicas y exploits deben mantenerse en secreto, incluso de los clientes, para evitar perder ventajas en otros contratos. Red teaming no consiste simplemente en emular, sino que también implica cultivar una relación con el cliente, en la que el pensamiento crítico puede ayudar a gestionar los riesgos potenciales y mejorar la ciberseguridad.

Cuando, por ejemplo, en un ejercicio de pentesting o de simulación de ataque los equipos de seguridad del cliente consiguen descubrirte, ten en cuenta algo que Carlos comparte desde su experiencia: No tiene por qué ser algo negativo con tu trabajo y tus capacidades; puede ser que en el lado del cliente ya hayan aprendido de proyectos anteriores y hayan aplicado las medidas necesarias. De acuerdo con sus palabras, puedes recordarte que tu tarea es ayudarles a poner a prueba su seguridad y hacer que sus sistemas sean más seguros.

A la pregunta de cuándo introducir un red team en el programa de seguridad de una organización, Carlos responde (en términos de condiciones): En esa organización tiene que haber una cultura de involucrar a la seguridad desde el principio del proceso, cuando tenga sentido hacerlo, y una disposición a escuchar ideas críticas alternadas de los planes cuando estos se expongan. Debe ser una empresa que reconozca la necesidad y esté dispuesta a someter a evaluación sus proyectos y sistemas para identificar debilidades y vulnerabilidades en ellos. Pero no solo eso, según Carlos, la organización debe estar dispuesta a asumir esfuerzos para eliminar y mitigar los riesgos señalados por el red team.

El criterio de Carlos es bastante valioso cuando sugiere que es mejor no implementar los servicios de un red team dentro de una empresa, al menos no en ese momento, en el que su equipo de seguridad está algo aislado de los procesos generales de la toma de decisiones. Además, para él, no es buena idea convocar a los red teams cuando, más que una colaboración, lo que hay entre los grupos de esa empresa es solo competencia y conflicto.

Adicionalmente, Carlos menciona un control de seguridad fácil y sencillo que una empresa puede implementar ahora que el phishing y el malware son tan empleados para comprometer redes o sistemas. Se trata de abordar primero las vías de entrada más comunes. Según Carlos, la mayoría de las compañías no bloquean ni controlan la ejecución de HTA, Windows Scripting Host o macros de Office. Después de bloquear las rutas de entrada, el equipo de seguridad puede empezar a perfilar el comportamiento típico dentro del entorno para construir un sistema de detección automática de comportamientos anormales.

No olvides que puedes acceder a la entrevista completa con Carlos Pérez en el libro de Carey y Jin. Por cierto, recuerda que si quieres formar parte del red team de Fluid Attacks, puedes consultar nuestra página de Trabaja con nosotros. Y si necesitas información sobre nuestros servicios y soluciones para tu organización, puedes hacer click aquí para contactarnos.