Simon Edwards, CEO y Fundador de SE Labs – Serie de entrevistas

Simon Edwards, CEO y Fundador de SE Labs, es un experto en pruebas de ciberseguridad con más de tres décadas de experiencia que abarca investigación de seguridad, evaluación de productos, periodismo técnico y normas de la industria. Antes de fundar SE Labs en 2015, Edwards dirigió Dennis Technology Labs, donde lideró iniciativas de pruebas de seguridad, y anteriormente pasó muchos años como periodista y editor tecnológico. También ha ocupado puestos de alta dirección en la Anti-Malware Testing Standards Organization (AMTSO), incluyendo Presidente, Director y Copresidente. Edwards ha estado probando productos de seguridad desde mediados de los años 90 y fue pionero en los primeros enfoques de pruebas de anti‑malware en entornos reales diseñados para evaluar cómo las tecnologías de seguridad se desempeñan contra ataques completos entregados por Internet, en lugar de muestras aisladas de malware.

SE Labs es una empresa independiente de pruebas y asesoría en ciberseguridad que evalúa cómo las tecnologías de seguridad funcionan frente a ataques realistas. Sus investigadores replican técnicas de atacantes a lo largo de toda la cadena de ataque para evaluar productos que incluyen protección de endpoints, detección y respuesta de endpoints (EDR), servicios de seguridad en la nube, firewalls, seguridad de correo electrónico y tecnologías de detección de red. Además de pruebas comparativas públicas, SE Labs ofrece certificación, pruebas avanzadas de seguridad, validación de productos y servicios de asesoría para empresas y proveedores de ciberseguridad. La compañía publica sus metodologías de pruebas y marcos de emulación de amenazas y está certificada bajo ISO/IEC 27001:2022 y BS EN ISO 9001:2015 para la provisión de pruebas de productos de seguridad informática.

Su carrera abarca más de tres décadas en periodismo tecnológico, consultoría de seguridad, pruebas independientes y roles de liderazgo en la Anti-Malware Testing Standards Organization (AMTSO). ¿Cómo ha influido esa experiencia en la forma que separa los avances genuinos en ciberseguridad impulsada por IA de las tecnologías que se posicionan principalmente como “IA” con fines de marketing?

El periodismo me enseñó a cuestionar las afirmaciones, mientras que las pruebas independientes me mostraron que la única respuesta fiable proviene de la evidencia. Las empresas de ciberseguridad han utilizado aprendizaje automático y toma de decisiones automatizada durante muchos años, por lo que añadir “IA” al nombre de un producto no representa necesariamente un avance técnico.

Tres aspectos básicos a considerar: ¿Qué está haciendo realmente la IA? ¿Qué resultado medible de seguridad mejora? ¿Y puede un probador independiente reproducir esa mejora?

Si la respuesta es simplemente que el producto analiza una gran cantidad de datos o automatiza un proceso existente, la etiqueta de IA puede estar más relacionada con el posicionamiento que con la capacidad.

Un avance genuino funciona bien contra ataques desconocidos o recién creados, mejora la protección o la respuesta, reduce la carga de los analistas y lo hace sin introducir riesgos inaceptables. ¡Cualquier otra cosa es una no‑mejora o una degradación!

“Impulsado por IA” se ha convertido en una afirmación común en los productos de ciberseguridad. ¿Cuáles son las capacidades más importantes que deberían probarse de forma independiente antes de que una organización acepte que una plataforma de seguridad basada en IA realmente entrega lo que el proveedor promete?

No comenzaría probando si un producto contiene IA. Comenzaría probando las afirmaciones de seguridad que se hacen sobre él. No me importa realmente cómo funciona un producto, siempre que funcione. Este es el objetivo exacto del programa de pruebas PIVOT, que está ganando mucha tracción en la industria en este momento.

Probar de esta manera significa exponer el producto a ataques completos y medir cómo responde. Probablemente debería detectar la actividad y luego podría impedir que el ataque progrese. Esto depende de cómo el producto está construido y configurado. Y de las afirmaciones de marketing que su proveedor está haciendo.

También necesitamos examinar la historia investigativa presentada al cliente. ¿Entendió el sistema lo que sucedió, conectó los eventos relevantes y hizo visible la evidencia a la persona que debe actuar sobre ella?

La prueba debe incluir variaciones desconocidas, configuraciones realistas del cliente y actividad empresarial normal. También debe medir falsos positivos, demandas de recursos y acciones que puedan considerarse potencialmente inseguras. Si el sistema es autónomo, necesitamos saber cuándo actúa, por qué actúa, qué permisos utiliza y si sus decisiones pueden revertirse.

Hemos visto algunas noticias sobre IA de seguridad que se vuelve rebelde y supera sus límites e incluso la ley. La pregunta importante no es si la plataforma parece inteligente. Es si produce resultados de seguridad consistentemente mejores y más seguros.

Los agentes de IA autónomos pueden ejecutar potencialmente reconocimiento, explotación, movimiento lateral y otras etapas de un ataque mucho más rápido que un atacante humano. ¿Cómo debe cambiar la prueba de ciberseguridad cuando los ataques comienzan a operar a velocidad de máquina?

La unidad de prueba debe cambiar del individuo técnico a la campaña completa que opera bajo presión de tiempo. Con eso me refiero a que, en lugar de probar diferentes formas de ataque durante una mañana o una semana, ciertas medidas de seguridad deben evaluarse rápidamente. De lo contrario no es realista, y el realismo es muy importante.

Las pruebas tradicionales pueden dejar brechas convenientes entre etapas para que cada evento se examine por separado. Un atacante autónomo puede comprimir la fase de reconocimiento, explotación y movimiento lateral en un período mucho más corto. Eso podría revelar debilidades que no son visibles en pruebas más lentas, incluidos retrasos en la telemetría, sistemas sobrecargados y acciones defensivas que llegan solo después de que el ataque haya alcanzado su objetivo.

Para dar un ejemplo extremadamente básico, si infiltramos una Mac, descargamos todos sus archivos y robamos las contraseñas de las cuentas, no sirve de mucho si el antivirus aparece un día después con la mala noticia.

Por lo tanto, probar las respuestas de seguridad ante atacantes de IA requiere instrumentación de alta resolución y medición precisa de la latencia de detección y respuesta. Debe examinar si el rendimiento se deteriora a medida que aumentan el volumen y la velocidad de la actividad, y si la defensa puede interrumpir un ataque sin esperar una decisión humana en cada etapa.

El ataque también puede adaptarse a lo que descubre. Las pruebas deben reflejar eso sin perder la verdad de base, la evidencia y la capacidad de reproducir los resultados. La velocidad de la máquina no debe implicar abandonar una metodología controlada. Necesitamos seguir diseñando pruebas controladas que puedan operar y medir los eventos a la misma velocidad que los sistemas evaluados.

SE Labs utiliza escenarios de ataque realistas basados en las tácticas y técnicas de grupos de amenazas como Scattered Spider. ¿Cómo recreas a estos adversarios en un entorno controlado asegurando que la prueba refleje cómo se desarrollaría un ataque real en lugar de simplemente probar contra una lista de verificación predefinida?

Comenzamos con los objetivos del adversario, sus comportamientos conocidos y la probable toma de decisiones, en lugar de tratar sus técnicas como una lista de compras.

La prueba sigue una cadena de ataque realista a través del reconocimiento, acceso inicial, ejecución, escalada de privilegios, actividad post‑compromiso y movimiento lateral. Lo importante es que el evaluador solo puede usar la información realmente descubierta durante el reconocimiento y el ataque. No proporcionamos al atacante conocimientos que no estarían disponibles en un compromiso real.

El escenario está delimitado y cuidadosamente controlado, pero no es simplemente una secuencia de pulsaciones de botones predefinidas. Si una ruta se bloquea, el atacante puede seguir una alternativa creíble dentro de las reglas de la prueba. Eso permite que el producto de seguridad influya en cómo se desarrolla el escenario.

Al mismo tiempo, se registra cada acción y resultado importante para que podamos explicar el resultado y comparar los productos de manera justa. Controlado no tiene que significar rígidamente guionado. Debe significar seguro, observable y respaldado por evidencia.

Los productos de ciberseguridad tradicionalmente se han evaluado intensamente por su capacidad para detectar amenazas. ¿Por qué las organizaciones deberían enfocarse cada vez más en la protección, contención y respuesta a incidentes al evaluar sistemas de seguridad impulsados por IA?

La detección no es lo mismo que la defensa. Una plataforma puede generar una alerta precisa mientras sigue permitiendo que el atacante alcance su objetivo. Por eso el programa de pruebas PIVOT incluye tanto la detección como la protección como partes conjuntas y separadas de la evaluación global.

Puedes comparar la detección de ciberseguridad con una cámara CCTV. Debe notar una intrusión y ofrecerte pistas sobre lo ocurrido, pero no detendrá físicamente a un intruso. La protección de ciberseguridad es mucho más activa. Puede expulsar o neutralizar al atacante, evitando daños.

Las organizaciones necesitan saber si el producto impidió la actividad inicial, interrumpió la cadena de ataque, restringió el movimiento lateral, protegió los activos importantes y apoyó la recuperación. Si un ataque tiene éxito, las siguientes preguntas son cuán rápido se contuvo y si el cliente recibió información suficiente y fiable para responder eficazmente.

Esto se vuelve particularmente importante con los sistemas impulsados por IA porque, aunque pueden producir resúmenes muy convincentes de lo ocurrido, una explicación persuasiva no sustituye a la protección. La explicación debe estar respaldada por evidencia y debe conducir a una acción adecuada.

Por lo tanto, medimos la detección y la protección por separado. También examinamos si la detección alegada era realmente visible y útil para el cliente. En última instancia, el valor de un sistema de seguridad reside en cambiar el resultado de un ataque, no solo en observarlo.

A medida que las plataformas de seguridad introducen agentes autónomos capaces de investigar alertas y tomar acciones de remediación, ¿cómo deberían los laboratorios independientes probar todo el flujo de trabajo humano‑y‑IA en lugar de evaluar la tecnología de detección subyacente de forma aislada?

La prueba debe seguir todo el proceso desde la primera actividad maliciosa hasta el resultado final de seguridad, que podría ser que el ataque sea detenido o que tenga éxito total, o algo intermedio.

Necesitamos examinar lo que el agente observó, lo que concluyó, lo que recomendó o hizo, lo que se mostró al operador humano y cómo respondió el operador (o qué opciones se le presentaron). Eso incluye la calidad de la evidencia, la claridad de la transferencia, el tiempo requerido, la cantidad de intervenciones y si el humano pudo entender, cuestionar o revertir la decisión del agente.

Los diferentes modos de operación también importan. Un agente que recomienda una acción para su aprobación presenta un riesgo diferente al de uno que puede aislar sistemas automáticamente, desactivar cuentas o modificar controles de seguridad.

Un sistema no ha tenido éxito simplemente porque su detector subyacente identificó el ataque. Si crea una cola incomprensible, oculta evidencia importante, recomienda la respuesta equivocada o lleva a cabo una acción disruptiva, el flujo de trabajo global ha fallado. Las pruebas independientes deben medir el rendimiento combinado de la tecnología, sus componentes autónomos y las personas que se espera que los utilicen.

Un riesgo de los benchmarks de seguridad estandarizados es que los proveedores pueden optimizar los productos específicamente para la prueba. ¿Cómo puede la evaluación independiente seguir siendo reproducible y justa al mismo tiempo que introduce suficiente imprevisibilidad para revelar cómo se desempeñan los productos frente a ataques desconocidos?

La reproducibilidad no requiere proporcionar a los participantes las preguntas del examen con antelación.

Una prueba creíble debe publicar su metodología, entorno, principios de puntuación, configuración del producto y requisitos de evidencia. Los proveedores deben comprender las reglas y tener una oportunidad justa de verificar que sus productos funcionan correctamente. Sin embargo, la campaña de ataque precisa, las cargas útiles y algunos de los vectores de ataque deben permanecer desconocidos hasta que se realice la prueba.

Por ejemplo, en PIVOT no revelamos qué grupos de ataque vamos a replicar hasta después de que finalicen las pruebas. ¡Los objetivos reales no reciben aviso previo antes de que comience un ataque!

Podemos combinar un núcleo estándar, que permite la comparación a lo largo del tiempo, con variaciones desconocidas que prueban la capacidad general. Establecer una línea base y un período de silencio oculto puede determinar cómo se comporta el producto antes del ataque. Luego la configuración debe controlarse, los registros preservarse y cualquier afirmación verificarse contra la propia evidencia del evaluador.

La equidad implica aplicar las mismas reglas y estándares de evidencia a cada participante. No significa repetir un ataque de forma tan predecible que un proveedor pueda reconocer el benchmark en lugar de reconocer la amenaza.

Además, la transparencia radical ayuda a los proveedores a reproducir los ataques, lo cual es importante si desean corregir los problemas que encuentren, como no detectar o protegerse contra una amenaza. SE Labs esencialmente entrena a sus clientes cuando se topan con problemas.

Los agentes de seguridad autónomos introducen una categoría diferente de riesgo porque una decisión errónea podría desencadenar una acción de remediación innecesaria o incluso disruptiva. ¿Cómo deberían las pruebas medir los falsos positivos, el razonamiento incorrecto y las acciones autónomas potencialmente dañinas junto con la precisión tradicional de detección?

Las pruebas tradicionales de falsos positivos son solo la primera capa. Con un agente autónomo, necesitamos distinguir entre una alerta falsa, una conclusión no respaldada y una acción incorrecta. Cada una tiene un impacto potencial diferente.

Las pruebas deben exponer el sistema a actividades legítimas que se asemejen a comportamientos maliciosos, así como a evidencia incompleta, ambigua o engañosa. Si el agente consume contenido no confiable, la prueba también debe examinar si ese contenido puede influir indebidamente en sus decisiones.

El razonamiento debe juzgarse por si la conclusión está respaldada por la evidencia disponible, no por cuán plausible o segura parezca la explicación. Para las acciones autónomas, debemos medir el alcance, la proporcionalidad, el uso de permisos, los controles de aprobación, la auditabilidad y la reversibilidad.

La puntuación debe reflejar las consecuencias. Una alerta innecesaria es incómoda; desactivar una cuenta importante o aislar un sistema crítico podría interrumpir la organización. Por lo tanto, una medida de seguridad útil debe considerar tanto la frecuencia de los errores como el daño que cada error podría causar.

Dicho todo esto, a veces el cliente elige una política que genera problemas. No es necesariamente culpa del proveedor de seguridad.

La IA generativa y los modelos de código abierto cada vez más capaces están reduciendo la barrera para automatizar partes del proceso de ataque. ¿Esperas que la IA haga que los ciberataques sean fundamentalmente más sofisticados, o el peligro mayor es que los atacantes simplemente puedan operar a una escala y velocidad dramáticamente mayores?

Mi expectativa es que el peligro más inmediato sea la escala, la velocidad y la reducción de costos.

La IA puede ayudar a los atacantes a recopilar información, personalizar la ingeniería social, modificar código y coordinar partes de una campaña. Algunos ataques se volverán más sofisticados como resultado, particularmente cuando la IA ayuda a combinar técnicas existentes o a adaptarlas a un objetivo concreto. Pero la IA no elimina la necesidad de acceso, credenciales, vulnerabilidades explotables o errores de los defensores.

La IA tampoco es muy buena produciendo exploits fiables, lo cual ya es bastante difícil incluso para un humano experto. Por lo tanto, reduce la probabilidad de ataques fundamentalmente más sofisticados, en mi fuerte opinión.

El cambio mayor es que actividades que antes requerían tiempo, habilidad o un equipo de personas pueden intentarse más rápidamente y contra muchos más objetivos. La IA puede elevar la competencia de atacantes relativamente ordinarios mientras permite a los atacantes más capaces ejecutar más operaciones simultáneamente.

Eso es significativo incluso si las técnicas de ataque subyacentes no son revolucionarias. El peligro no es necesariamente una forma completamente nueva de ciberataque. Son ataques familiares que se vuelven más rápidos, más baratos, más personalizados y mucho más numerosos.

A medida que los agentes de IA defensivos y ofensivos se vuelven más autónomos, ¿cómo deberá ser un entorno de pruebas de ciberseguridad creíble para mantenerse al día? ¿Podríamos eventualmente llegar a un punto en el que los productos de seguridad necesiten ser desafiados continuamente por adversarios de IA adaptativos en lugar de evaluarse principalmente mediante pruebas de seguridad periódicas?

Un entorno creíble deberá asemejarse a una organización viva en lugar de a una colección de objetivos aislados. Debería incluir puntos finales, sistemas de identidad, correo electrónico, redes, servicios en la nube, usuarios realistas y actividad empresarial normal. También debe proporcionar instrumentación completa para que cada decisión y consecuencia pueda ser reconstruida.

A los adversarios adaptativos podrían asignarse objetivos y límites, y luego permitirles elegir rutas según lo que descubran y cómo responda el producto defensivo. La prueba aún necesitaría condiciones iniciales controladas, una descripción fiable de lo que realmente ocurrió y la capacidad de reproducir eventos importantes. Sin esos elementos, las pruebas adaptativas podrían resultar impresionantes pero científicamente débiles.

Espero que las pruebas se vuelvan más continuas, particularmente cuando los productos, modelos y políticas pueden cambiar con frecuencia. Sin embargo, el desafío continuo debe complementar, no eliminar, las pruebas comparativas periódicas. Las organizaciones necesitan ambas: puntos de referencia controlados como PIVOT que respaldan la rendición de cuentas y la comparación, y una evaluación adaptativa continua que revele cómo se comportan los sistemas a medida que cambian las amenazas y los propios productos.

Creo que deberíamos preocuparnos más por el hecho de que humanos relativamente poco capacitados pueden vulnerar sistemas y redes, en lugar de los robots que crean la próxima generación de tecnología de ciberataques.

Gracias por la gran entrevista, los lectores que deseen obtener más información deberían visitar SE Labs.