BAS VS Pentesting VS Red Teaming

Las pruebas de seguridad ofensivas tienen distintos enfoques. Los más conocidos son breach and attack simulation, el pentesting y el red teaming. Su objetivo común es determinar las fortalezas y debilidades de las defensas de seguridad de los sistemas mediante evaluaciones basadas en ataques. Pero difieren en su ejecución, al menos como se conciben comúnmente. Se diferencian principalmente en si implican pruebas manuales, si evalúan la superficie de ataque de forma continua, si atacan con conocimiento previo del contrato por parte de los equipos de seguridad de las organizaciones, si incluyen la seguridad a un nivel distinto al del sistema informático, y si solo tienen un objetivo específico importante. En Fluid Attacks vemos las carencias en la forma en que la mayoría de productos y proveedores llevan a cabo algunos de estos enfoques y planteamos nuestra propia manera, basada en lo que percibimos como el presente y el futuro de la ciberseguridad.

En este artículo del blog, hablamos de las diferencias entre breach and attack simulation, pentesting y red teaming, y explicamos cómo nos salimos del molde en estos dos últimos métodos. En el transcurso, enlazamos otras entradas en las que abordamos en detalle estos enfoques por separado.

En este artículo hablaremos de tres de estos enfoques: breach and attack simulation (BAS), pentesting y red teaming. Los equipos de desarrollo, y las empresas en general, recurren a ellos para evaluar la detección, la resistencia y la respuesta de sus sistemas frente a los ataques que pueden realizar los criminales en la actualidad. Como repetiremos más adelante, en el caso del red teaming, las pruebas de seguridad pueden incluir instalaciones físicas y empleados como objetivo de evaluación.

Las soluciones de breach and attack simulation se han introducido en el mercado de las pruebas de seguridad más recientemente que las soluciones de pentesting. En algunos casos, son objeto de comparaciones con el propósito de responder cuál es la mejor. Sin embargo, dado que comparten el objetivo que hemos mencionado anteriormente, existe confusión en torno a en qué se diferencian.

La mayoría de descripciones de BAS coinciden en que este enfoque pone a prueba la eficacia de los controles de seguridad de los sistemas de las organizaciones mediante simulaciones de ataques. En especial, evalúa si los controles están configurados correctamente y pueden detectar, resistir y responder adecuadamente a las amenazas y técnicas más recientes. (Para saber a qué controles se presta más atención, lee nuestro artículo de blog sobre BAS).

Pentesting es un término bastante familiar para algunos. Nosotros lo describimos como la simulación de ataques que un verdadero actor de amenaza puede llevar a cabo contra los sistemas. Suele consistir en buscar vulnerabilidades y generar exploits para eludir las defensas del sistema y los objetivos suelen ser los mismos controles que se prueban con las soluciones BAS.

Para diferenciar entre los dos enfoques, algunas fuentes afirman que BAS responde a la pregunta de si los controles de seguridad operativos funcionan correctamente, mientras que el pentesting evalúa si los atacantes logran acceder al sistema. Pero estas no parecen ser dos cosas distintas. Para explicar a qué se refieren estas fuentes, es importante entender que no todas las soluciones BAS se parecen al pen testing estándar.

Ahora comparemos este último tipo con el pentesting tal y como se concibe comúnmente:

Sus diferencias radican en la ejecución. Una de ellas es que la mayoría de las soluciones de BAS se basan únicamente en herramientas, mientras que el pentesting siempre se realiza manualmente. En efecto, las pruebas de penetración las realizan personas, quienes pueden usar exploits de forma creativa en función del contexto de las empresas e imitar la conducta habitual de los criminales. (Por eso, a lo largo de este escrito nos referiremos siempre a "pentesting manual"). A pesar de las afirmaciones aparentemente legítimas de algunos proveedores de que sus herramientas aprovechan esta metodología, hemos argumentado en una entrada anterior que no existe tal cosa como el pentesting automatizado.

El trabajo manual ayuda a la precisión y a detectar los problemas que representan la mayor exposición a ataques. (Para saber más, lee nuestro reporte del 2022). Los hackers éticos, o pentesters, utilizan las mismas herramientas y técnicas que utilizaría un atacante malicioso. A diferencia de las herramientas, pueden comenzar tan pronto como los especialistas en ciberseguridad y los equipos de respuesta, entre otras entidades (p. ej., el US Computer Emergency Readiness Team), anuncien las amenazas. Esto evita que se produzca un lapso de tiempo durante el cual las amenazas actuales puedan afectar a los sistemas.

Otra diferencia es que las soluciones de BAS siempre prueban los sistemas de forma continua, mientras que la mayoría de las ofertas de pentesting solo los evalúan regularmente. Nótese que decimos "la mayoría": existe un modelo que aborda la necesidad de pentesting y se denomina pruebas de penetración como servicio (PTaaS). Respecto al gasto en ciberseguridad, la opinión general es que tener personas realizando pruebas de seguridad es más costoso que confiar en la automatización. Pero teniendo en cuenta lo explicado anteriormente, en realidad puede ser más costoso a largo plazo limitarse solo a la automatización y evitar las evaluaciones manuales continuas.

En Fluid Attacks, reconocemos las limitaciones en la forma en que se lleva a cabo el pentesting en la industria. Entendemos que, dado que las amenazas evolucionan constante y rápidamente, las pruebas de seguridad deben apoyar la prevención de manera eficaz. Pueden hacerlo proporcionando estados precisos y actualizados de la seguridad de los sistemas. Por este motivo, ofrecemos una solución de pentesting junto con pruebas de seguridad automatizadas en un único servicio, Hacking Continuo. Combinamos la automatización y el trabajo manual para evaluar los sistemas de forma continua. Nuestro escáner de vulnerabilidades se ejecuta permanentemente y, al mismo tiempo, asignamos múltiples hackers éticos para explorar los sistemas. Esta metodología permite a las organizaciones asegurarse de que cada cambio en sus sistemas puede resistir los incesantes esfuerzos de los atacantes para penetrar en ellos.

Ahora que hemos resuelto las diferencias entre BAS y pentesting, tal y como los ofrecen la mayoría de los demás proveedores, pasemos a ver las diferencias entre el pentesting y el red teaming.

Red teaming es otro término familiar que se refiere a la simulación de ataques del mundo real. En este enfoque, los especialistas en seguridad atacan bajo la modalidad de lo que se conoce como "ejercicios de red team". Básicamente se trata de operaciones en las que ellos, el red team, avanzan ofensivamente hacia objetivos específicos. En estos ejercicios pueden crearse diferentes equipos: el blue team, el white team y el purple team.

Básicamente, el blue team es un grupo de especialistas en seguridad defensiva (p. ej., consultores de respuesta a incidentes) de la organización objetivo que gestiona los controles de seguridad para hacer frente a las intrusiones de (en este contexto) el red team. El white team es el grupo que convoca y aprueba el inicio y la interrupción de los ataques. Y el purple team se encarga de analizar las interacciones entre el red team y el blue team y de sugerir correcciones, entre otras cosas.

Lo anterior sugiere un par de diferencias con otros enfoques de seguridad ofensiva en términos de ejecución. Por ejemplo: en red teaming, ninguno, o algunos, de los defensores saben que los atacantes están contratados por la organización objetivo, mientras que en pentesting todos los defensores son plenamente conscientes de ello.

Hemos incluido esto en un artículo pasado como una de nuestras políticas de gestión sugeridas para llevar a cabo pruebas de seguridad ofensivas. En pocas palabras, los red teams deben actuar igual que los actores de amenazas maliciosas, que no notifican cuándo, cómo y dónde van a atacar, qué técnicas utilizan, a qué información han accedido, etc.

Además, como se podría suponer por nuestra definición de los ejercicios de red team, en red teaming, los atacantes suelen tener en su mira solo algunos objetivos específicos, mientras que en pentesting el propósito suele ser encontrar todas las vulnerabilidades y puntos débiles de un sistema.

Otra diferencia, que ya hemos mencionado antes, es que red teaming puede tener como objetivo a los empleados y las instalaciones físicas de una organización, mientras que las soluciones de pentesting suelen atacar solo los sistemas informáticos. Esto significa que un red team realizaría actividades como ingeniería social (p. ej., intentar influir en los empleados para que asuman riesgos de seguridad) e intentaría penetrar en las instalaciones de la empresa (p. ej., para instalar dispositivos).

En Fluid Attacks, ofrecemos nuestra solución de red teaming en la que acordamos con nuestros clientes qué objetivos atacar. Nuevamente, lo hacemos combinando herramientas automatizadas e ingenio humano para evaluar los objetivos continuamente.

Es fácil adivinar que las diferencias entre breach and attack simulation y el red teaming coinciden con las que existen entre el primero y el pentesting. Es decir, las soluciones de BAS normalmente se basan en la automatización y realizan pruebas continuamente, mientras que las soluciones de red teaming se basan en hackers éticos y normalmente solo realizan pruebas periódicas.

Hay otra cuestión por abordar. Algunos proveedores afirman que sus herramientas de BAS tienen características de red team y blue team. Es decir, emulan a los actuales atacantes y proporcionan información sobre cómo mitigar problemas de seguridad. Así, ayudan con las tareas de un purple team. Pero todo esto parece un esfuerzo por asemejar las acciones de las herramientas a lo que ocurre en un ejercicio de red teaming. Al final, mientras la organización esté dirigida por humanos, que entran en pánico en el momento de descubrir una brecha, se ven influidos por factores sociales, cometen errores, etc., estas herramientas no podrían poner a prueba las operaciones de blue team. Ya hemos mencionado anteriormente cómo las herramientas están limitadas también en sus operaciones de red team. En resumen, siempre es necesaria la intervención manual continua. Combinarla con análisis automatizados ayuda a hacerse una idea precisa y rápida del estado de seguridad de las organizaciones.

En Fluid Attacks realizamos pruebas de seguridad ofensivas de forma continua, combinando automatización y trabajo manual. Tómate tu tiempo para aprender más sobre nuestras soluciones de pentesting y red teaming.

También puedes consultar nuestra prueba gratuita de 21 días de pruebas de seguridad automatizadas. Puedes cambiar tu suscripción a nuestro plan más completo en cualquier momento para incluir pruebas de seguridad ofensivas.