Por qué los 'arneses' de IA son más importantes que los LLM de vanguardia para la ciberseguridad

A medida que la piratería informática basada en la IA se convierte en una amenaza mayor para la ciberseguridad y la seguridad nacional, la atención del público se ha centrado principalmente en unas pocas empresas líderes en IA que desarrollan modelos de lenguaje más potentes y de gran tamaño.

Estos modelos, y los miles de millones de dólares que hay detrás de ellos, son importantes, pero son sólo una parte de un cambio mayor. Las empresas ahora están construyendo sus propias plataformas tecnológicas que toman estos LLM de propósito general y los convierten en herramientas de ciberseguridad personalizadas.

Los profesionales de la industria se refieren a estas herramientas como “arnés”. Controlan el comportamiento del modelo, limitan sus riesgos y lo conectan a redes y sistemas de TI internos para que pueda funcionar de manera confiable a escala.

Una nueva investigación de Cato Networks compartida exclusivamente con CyberScoop muestra cuánta potencia puede provenir de un arnés. Emparejó los modelos ChatGPT 5.5 y GPT 5.5-Cyber ​​de OpenAI con su propia herramienta y probó las capacidades del agente para piratear la red de una víctima con la menor dirección humana posible.

En seis escenarios diferentes, la pareja logró cadenas de ataques completas de extremo a extremo, incluidos privilegios de administrador de dominio y acceso a Active Directory, a veces en tan solo 40 minutos.

«Lo más sorprendente es que primero vimos que era capaz de realizar razonamientos y ataques acelerados, e interactuar y hacer todo esto por sí mismo, como realizar todas las etapas de los ataques», dijo Guy Weisel, evangelista tecnológico de Cato Networks y uno de los autores detrás de la investigación.

Fundamentalmente, los escenarios más exitosos ocurrieron cuando al modelo se le dio el contexto operativo apropiado a partir del arnés técnico desarrollado por Cato Networks.

«Esto respalda el hecho de que no se trata sólo del modelo de frontera», dijo Weisel. “Encontramos que [our harness] Realmente ayuda al razonamiento” del LLM.

Una ilustración de una cadena de ataques de IA agente y un movimiento lateral dentro de las redes de víctimas. (Fuente: Cato Networks)

El agente recibió algunos recursos, aunque no abundantes, para completar sus tareas, incluido un host de ataque Kali Linux externo, la dirección IP pública del objetivo simulado y un conjunto de credenciales de dominio de bajo nivel adquiridas mediante phishing.

No se le proporcionó ningún otro detalle y tuvo que investigar más a fondo para obtener información clave, como mayor conocimiento del tipo de servidor (Microsoft Exchange), el sistema operativo del objetivo, la versión, el número de compilación, la topología de la red interna, el acceso a cuentas con mayores privilegios y otros activos críticos, ni se le proporcionó al agente ninguna ruta de ataque predeterminada.

La investigación de Cato Networks utiliza modelos OpenAI, pero sólo como ejemplo. Weisel dijo que cree que otros modelos probablemente lograrían resultados similares. En todo caso, si las tendencias actuales se mantienenes probable que el tipo de capacidades proporcionadas por LLM como GPT 5.5 sean de código abierto dentro de un año.

Cato Networks no está ni mucho menos solo. La mayoría de las empresas tienen sus propios sistemas de inteligencia artificial y los ejecutivos le dicen a CyberScoop que están desempeñando un papel cada vez más importante en la dirección más efectiva de los flujos de trabajo del modelo de frontera.

Si bien las herramientas de inteligencia artificial pueden tener dificultades para duplicar los flujos de trabajo humanos en otras áreas, los LLM han demostrado durante mucho tiempo potencial en ciberseguridad y codificación, y han mejorado enormemente en los últimos años. La administración Trump ha creado una nueva cámara de compensación federal para el intercambio de información entre los sectores público y privado sobre las vulnerabilidades descubiertas en la IA, mientras que grupos europeos están creando sus propias organizaciones para coordinar globalmente las amenazas cibernéticas de la IA.

Eric Doerr, director de productos de Tenable, dijo a CyberScoop que un arnés utilizado en la empresa llamado “Hexa” ofrece una ventaja defensiva: puede funcionar con diferentes LLM comerciales y al mismo tiempo ofrecer resultados consistentes.

“Una de las primeras cosas que hacemos cuando tenemos un [new] «El modelo es decir: 'Bueno, ejecutémoslo en Hexa y veamos qué aprendemos'», dijo Doerr. «Tenemos un montón de puntos de referencia. ¿Es lo mismo, es mejor? ¿Dónde es mejor? ¿Dónde es peor?

Hexa está destinado a garantizar que, cualquiera que sea el modelo o modelos que se vuelvan dominantes, Tenable podrá integrarlo en su pila tecnológica y proteger sus activos más sensibles de comportamientos no deseados. Eso libera al LLM para hacer lo que mejor sabe hacer: encontrar códigos vulnerables y establecer vías de ataque para explotarlos.

«Durante años, ha sido cierto que hay muchos más problemas potenciales con los que una empresa tiene que lidiar: vulnerabilidades de código, cosas que no están parcheadas, configuraciones erróneas», dijo Doerr. «Hay mucho más de lo que realmente se puede remediar, y realmente es necesario comprender la diferencia entre lo que es un problema teórico y un problema real».

Dan Rapp, director de inteligencia artificial y datos de Proofpoint, dijo que su arnés, «Satori», se ha convertido en una herramienta fundamental para mantener su inteligencia artificial en el camino y al mismo tiempo brindar a los humanos la capacidad de intervenir cuando las cosas van mal.

«Creo que lo que estamos viendo en la base de los modelos de frontera es que tenemos inteligencia pura, poder de razonamiento puro, pero para lograr que estos sistemas funcionen de la manera deseada, tanto la ingeniería de contexto (el contenido proporcionado que garantiza que sea preciso y relevante) como la ingeniería de aprovechamiento son esenciales para lograr que los sistemas funcionen bien», dijo Rapp a CyberScoop.

Ese fue un tema común en las entrevistas con las empresas. Si bien los modelos de frontera van y vienen, o son superados por competidores internacionales, siempre será necesario que el modelo opere con datos y contexto que a menudo sólo la organización puede proporcionar.

Sugiere que, si bien los formuladores de políticas y los expertos en ciberseguridad se han centrado en la difusión de modelos fronterizos más nuevos y poderosos, la industria (y probablemente pronto la clandestinidad cibercriminal) ha desarrollado rápidamente el tipo de infraestructura técnica que se está volviendo mucho más importante para las tareas ciberdefensivas y ofensivas de la IA.

«Hemos tenido que arrancar bastantes de estos sistemas desde los primeros principios, y lo que siempre se reduce a cuán efectivo es con la herramienta llamando… trayendo datos, enriqueciendo el contexto», dijo John Hopper, vicepresidente de ingeniería de producto en SpecterOps.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Los scripts en su página de pago son ahora un problema de PCI DSS – CYBERDEFENSA.MX

Un evaluador independiente de PCI probó Reflectiz según las nuevas reglas PCI DSS. Aquí está el veredicto: Vea la evaluación QSA completa aquí →

Cuando un cliente ingresa su número de tarjeta en su proceso de pago, su navegador ejecuta mucho más que su código. Etiquetas de análisis, un administrador de etiquetas, un widget de soporte, un iframe de pago: un proceso de pago moderno carga docenas de scripts de terceros y cualquiera de ellos puede convertirse en un skimmer.

Así funciona Magecart. Sansec ha contado más de 100.000 sitios afectados por el robo de información web y los ataques a la cadena de suministro. El Incumplimiento de British Airways en 2018 Solo expuso 380.000 transacciones y una multa que comenzó en £183 millones.

La parte peligrosa: el código malicioso suele llegar a través de un script que ya has aprobado. Los atacantes comprometen a un proveedor externo y la carga útil se aloja en un script que usted ha ejecutado durante meses. Nada parece nuevo. Lo que cambió es el comportamiento del script, no su presencia en la página.

PCI DSS v4.0.1 cierra esa brecha con dos requisitos, ahora plenamente vigentes. 6.4.3 dice inventariar cada script de página de pago, autorizarlo y demostrar su integridad. 11.6.1 dice detectar la manipulación del contenido de la página y los encabezados HTTP a medida que el navegador los recibe. Hecho a mano, a través de cientos de guiones que cambian constantemente, esto no escala. Los datos de Reflectiz muestran que aproximadamente el 30% de los guiones de las páginas de pago cambian en cualquier período de dos semanas.

Lo que encontró el QSA

Integrity360 Europe, un asesor de seguridad calificado de PCI y miembro de la mesa redonda de asesores ejecutivos globales de PCI SSC, revisó la plataforma Reflectiz PCI DSS con respecto a ambos requisitos y descubrió que puede respaldar eficazmente el cumplimiento. Destacaron tres cosas:

  • Observa el comportamiento, no solo los hash de los archivos. Una verificación de hash omite un intercambio silencioso del lado del proveedor. Reflectiz capta el guión en el momento en que comienza a buscar datos de la tarjeta.
  • Se implementa sin agentes. Sin cambios de código, sin fragmentos, dura días y sigue funcionando a través de refactorizaciones y migraciones de CMS.
  • Produce evidencia lista para QSA con un solo clic. Registro de auditoría completo por página, listo para su evaluación.

El SAQ una captura

Desde enero de 2025, los comerciantes pueden eliminar 6.4.3 y 11.6.1 del SAQ A solo si confirman que su sitio no es susceptible a ataques de script. ¿Redireccionamiento completo a tu procesador? Probablemente estés bien. ¿Incrustar un iframe de pago? Un script en la página principal aún puede secuestrar el pago antes de que los datos lleguen al marco seguro, y usted debe demostrar que no puede hacerlo. La pregunta frecuente número 1588 de PCI SSC apunta directamente a estos mismos controles.

Obtenga la evaluación completa

El documento técnico completo de Integrity360 Europe desglosa ambos requisitos línea por línea, el flujo de trabajo de monitoreo y exactamente lo que SAQ A exige ahora a los comerciantes de iframe.

Descargue el documento técnico →

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

La falla del kernel de Linux de un carácter permite el acceso raíz local, los exploits ahora son públicos – CYBERDEFENSA.MX

Investigadores de seguridad han publicado un exploit detallado y funcional para un kernel de Linux de uso libre que permite a un usuario local sin privilegios escalar a root y salir de un contenedor.

La falla, CVE-2026-23111, se encuentra en el código de filtrado de paquetes nf_tables del kernel y fue parcheado aguas arriba el 5 de febrero de 2026. Exodus Intelligence lanzó su tutorial técnico completo el 8 de junio, y ni siquiera es el primer exploit público: FuzzingLabs publicó un reproducción independiente allá por abril.

La falla se redujo a un solo carácter perdido, una marca invertida en nf_tables, y la solución ascendente lo eliminó en una línea. Ubuntu califica el defecto CVSS 7.8 (alto). Si el paquete del kernel de su distribución aún no incluye la solución, actualice y reinicie.

La configuración accesible es común: nf_tables más espacios de nombres de usuario sin privilegios, una característica de Linux que permite que una cuenta normal actúe como root dentro de una zona de pruebas privada y acceda al código del kernel que de otro modo no podría.

Ambos se envían de forma predeterminada en la mayoría de las computadoras de escritorio y en muchas versiones de servidores. No existe un vector remoto por sí solo. Este es un error que un atacante aprovecha después de establecerse, convertir un shell con pocos privilegios, un contenedor comprometido o una cuenta de servicio en root en el host.

Ciberseguridad

El investigador de Exodus, Oliver Sieber, que encontró el error a principios de 2025, lo encadenó a una raíz local completa. El exploit activa el uso después de la liberación, evita las protecciones de memoria integradas del kernel y luego toma el control de la ejecución para otorgarse root y salir del espacio de nombres del contenedor.

Lo demostró en Debian Bookworm, Debian Trixie, Ubuntu 22.04 LTS y Ubuntu 24.04 LTS.

FuzzingLabs reprodujo el error en RHEL 10 antes de Pwn2Own Berlin 2026, creando su propio exploit raíz por una ruta diferente. El cronograma es ajustado: la solución se envió el 5 de febrero, FuzzingLabs se publicó el 16 de abril y el artículo detallado de Exodus llegó el 8 de junio.

La técnica ahora está documentada en Debian, Ubuntu y Red Hat. Debido a que el error está en la línea principal, cualquier distribución que envíe un kernel vulnerable con ambas características habilitadas está expuesta, a menos que el endurecimiento o las restricciones de espacio de nombres de una distribución bloqueen la ruta.

CVE-2026-23111 aparece en medio de una gran cantidad de divulgaciones de raíz local de Linux. Las últimas semanas han traído Copy Fail, la cadena Dirty Frag, su variante Fragnesia, DirtyDecrypt, y una falla de ptrace de nueve años que lee /etc/shadow y ejecuta comandos como root.

Difieren en los detalles, pero comparten la parte que debería preocupar a los defensores: un punto de apoyo sin privilegios sigue convirtiéndose en root en instalaciones normales.

Actualice el kernel y reinicie. El error es solo local y necesita espacios de nombres de usuario sin privilegios, así que concéntrese primero en los sistemas que permiten que los usuarios o cargas de trabajo que no son de confianza los creen.

Ciberseguridad

Ubuntu tiene correcciones para 22.04, 24.04 y 25.10, y Debian corrigió Bookworm y Trixie, con un backport 6.1 para Bullseye LTS. Red Hat, SUSE y Amazon Linux también rastrean la falla; Consulte el aviso de su distribución para encontrar el paquete del kernel que coincida con el suyo, ya que la versión fija exacta varía. La solución inicial fue una sola línea de código.

Hay un panorama más amplio. en un revisión reciente del aumento de LPESynacktiv vincula el ritmo con la investigación asistida por IA y la diferenciación de parches que eliminan los exploits funcionales antes de que se propaguen las correcciones, y argumenta que el endurecimiento ordinario aún les da tiempo a los defensores.

La mayoría de estos errores se basan en características opcionales del kernel o valores predeterminados flexibles, por lo que cortar lo que los usuarios sin privilegios pueden alcanzar, en este caso los espacios de nombres de usuario, retrasa el exploit hasta que se implementa el parche.

No hay informes públicos de explotación en la naturaleza y ningún actor de amenazas ha sido vinculado a ella. El parche ha estado disponible desde febrero y el código de explotación es público desde abril.

Los nuevos ataques DDoS con IA son más inteligentes. Aprenda cómo defenderse en este seminario web – CYBERDEFENSA.MX

Todos los días, los piratas informáticos encuentran nuevas formas de bloquear sitios web y robar datos.

Pero ahora algo ha cambiado. Los hackers ya no trabajan solos. Ahora están utilizando poderosas herramientas de Inteligencia Artificial (IA) para hacer que sus ataques sean más rápidos, más fuertes y mucho más difíciles de detener.

Según actualizaciones recientes de Las noticias de los piratas informáticoslos malos actores están utilizando la IA para encontrar puntos débiles en los sistemas y lanzar «ataques DDoS» masivos que pueden desconectar su empresa en segundos.

Si su sitio web deja de funcionar, pierde dinero, pierde la confianza de los clientes y pasa días tratando de solucionar el problema.

👉 Guarde su asiento gratuito para el seminario web

La antigua forma de protección ya no funciona

En el pasado, podías configurar un firewall simple, actualizar tu software y sentirte seguro.

Ya no. Los ataques asistidos por IA pueden pensar y adaptarse. No sólo golpean la puerta de entrada; buscan puntos de entrada ocultos, API inteligentes y pequeños errores en la configuración de su nube. Hacen en minutos lo que antes a los hackers humanos les llevaba semanas planificar.

Si confía en viejos hábitos de seguridad, dejará su empresa expuesta.

¿La buena noticia? Puedes usar la IA para defenderte. Sólo necesitas conocer las nuevas reglas del juego.

Lo que aprenderá en este seminario web de 45 minutos

Estamos organizando un evento en línea en vivo para mostrarle exactamente cómo proteger su red de estas nuevas amenazas que se mueven rápidamente. Aquí hay un adelanto de lo que cubriremos:

  • La ventana de 12 horas: Por qué los principales expertos en seguridad dicen que es necesario reparar las fallas más rápido que nunca y cómo hacerlo sin dañar sus sistemas.
  • La trampa de la IA: El error número uno que cometen las empresas al configurar la seguridad en la nube es el que en realidad facilita la entrada de los ataques de IA.
  • La defensa inteligente: Cómo utilizar herramientas automatizadas para detectar una amenaza antes de que llegue a sus servidores principales.
  • Plano en vivo: Una lista de verificación simple, paso a paso, que puede brindarle a su equipo para proteger su negocio esta semana.

Asegure su lugar para este seminario web ➜

La seguridad de la IA es un tema importante en este momento y las plazas se están llenando muy rápidamente. No espere hasta que su sitio web se desconecte para pensar en la seguridad. Regístrese hoy, aprenda cómo proteger sus activos digitales y mantenga su negocio seguro.

PD: Incluso si no puedes verlo en vivo, ¡regístrate de todos modos! Le enviaremos por correo electrónico la grabación completa y la lista de verificación inmediatamente después de que finalice el evento. Haga clic aquí para registrarse ahora.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Los errores tipográficos ya no son un problema del usuario. Es un problema de la cadena de suministro – CYBERDEFENSA.MX

Los dominios similares generados por IA ahora están integrados dentro de scripts de terceros que se ejecutan en sus propiedades web. He aquí por qué su pila actual no puede verlos y qué requiere realmente la detección.

Descargue la Guía de expertos de CISO sobre Typosquatting en la era de la IA →

TL;DR

  • Typosquatting ya no es un problema de usuario. Los atacantes ahora incorporan dominios similares dentro de scripts legítimos de terceros. No se requiere una URL mal escrita ni una vulneración del servidor.
  • La IA rompió la economía de la defensa. Los LLM generan miles de variantes de dominio convincentes en minutos; el despliegue completo de la campaña lleva menos de diez años. Las cargas de paquetes maliciosos aumentaron 156% el año pasado. La investigación manual está muerta.
  • Tu pila de seguridad no puede ver esto. Los firewalls, WAF, EDR y CSP no tienen visibilidad de lo que hacen los scripts aprobados una vez que se ejecutan en el navegador.
  • El Ataque a Trust Wallet lo demostró. 8,5 millones de dólares robados en 48 horas a través de una extensión de Chrome troyanizada. No se disparó ninguna alerta, no porque algo fallara, sino porque no había nada mirando.

Esta no es una historia criptográfica

El 24 de diciembre de 2025, los usuarios de Trust Wallet comenzaron a perder dinero. No porque hayan hecho clic en un enlace de phishing. No porque reutilizaron una contraseña débil. No porque hayan hecho nada malo en absoluto.

Un gusano npm autorreplicante llamado Shai-Hulud había pasado meses recopilando credenciales de desarrollador: tokens de GitHub, claves de publicación de npm y credenciales de la API de Chrome Web Store. Esas claves permitieron a los atacantes enviar una versión troyanizada de la extensión Trust Wallet Chrome a través de canales oficiales. La verificación de Chrome pasó.

La extensión maliciosa se ejecutó completamente dentro de los navegadores de los usuarios, capturando silenciosamente frases iniciales y transmitiéndolas a la infraestructura del atacante en un dominio disfrazado de punto final de análisis del propio Trust Wallet. En 48 horas, se habían vaciado 2.500 carteras. Pérdida total: 8,5 millones de dólares. Ningún servidor fue vulnerado. Nunca se disparó ninguna alerta.

Elimine las frases iniciales y lo que queda es esto: un activo confiable entregado por el navegador se modificó silenciosamente para interceptar datos confidenciales del usuario antes de que la aplicación legítima pudiera procesarlos, invisible para los registros del servidor, firewalls, WAF y EDR. No porque esos controles estuvieran mal configurados, sino porque nunca fueron diseñados para observar lo que sucede dentro de una sesión del navegador, ni siquiera una sesión envenenada.

Cambie frases iniciales por datos de tarjetas de pago. Cambie la extensión de Chrome por un píxel de marketing, un widget de soporte o un marco de pruebas A/B. El ataque es idéntico. Una página de pago típica de comercio electrónico ejecuta entre 40 y 60 scripts de terceros. Cada uno es una conexión confiable. Allí podría pasar lo mismo.

Cómo llegó aquí la typosquatting: tres fases

Lo que hace que la Fase 3 sea una evolución genuina no es sólo la sofisticación, sino también la economía. Los LLM pueden generar miles de variaciones de dominio convincentes en minutos. Los ataques homógrafos combinan caracteres latinos, cirílicos y griegos para producir dominios que parecen visualmente idénticos en las barras de direcciones del navegador mientras evaden la detección de distancia de cadena. El registro de dominio, la emisión de SSL y la implementación completa de la campaña ahora demoran menos de diez minutos. Los datos de Sonatype muestran que las cargas de paquetes maliciosos a repositorios de código abierto aumentaron un 156% año tras año, por lo que el volumen por sí solo ha hecho que la investigación manual sea estructuralmente imposible.

Tres ataques que muestran el patrón

La typosquatting apunta a la capa de dominio, el compromiso de paquetes apunta a la cadena de suministro y el abuso del tiempo de ejecución del navegador apunta a lo que hace el código confiable después de ejecutarse.

1. Extensión Trust Wallet para Chrome (diciembre de 2025)

Shai-Hulud recopiló credenciales de desarrollador durante meses antes de lanzar una extensión troyanizada a través de los canales oficiales de Chrome Web Store. La extensión maliciosa capturó frases iniciales y las transmitió a un dominio de análisis similar. 2.500 carteras vaciadas. Se perdieron 8,5 millones de dólares. Tiempo de detección: cero. No existe visibilidad del lado del servidor para la ejecución en tiempo de ejecución del navegador.

2. ataque npm con tiza/depuración (septiembre de 2025)

Un correo electrónico de phishing dirigido a un único responsable del paquete dio a los atacantes acceso a 18 bibliotecas de JavaScript confiablesincluidos chalk y debug, con más de dos mil millones de descargas semanales combinadas. En 16 minutos, se inyectó código malicioso en todos ellos, conectando las API del navegador para interceptar silenciosamente el tráfico de red y las interacciones de billetera. La rápida contención limitó las pérdidas directas a alrededor de 500 dólares. La ventana de exposición no fue la historia. Fueron dos mil millones de descargas.

3. Ataque a la biblioteca Solana Web3.js (diciembre de 2024)

Los atacantes comprometieron una cuenta de acceso de publicación para la biblioteca npm @solana/web3.js a través de una campaña de phishing, luego publicaron versiones maliciosas que contenían una función oculta que interceptaba claves privadas a mitad de la transacción y las exfiltraba a un dominio controlado por el atacante registrado apenas unos días antes del ataque. Cualquier aplicación que se actualizara automáticamente dentro del período de cinco horas enviaba la puerta trasera directamente a sus usuarios. Casi 200.000 dólares se gastaron antes del descubrimiento.

Cómo ocurre el compromiso: la confianza reemplaza al engaño

La ingeniería social clásica necesitaba un ser humano al tanto, alguien que escribiera mal una URL, hiciera clic en un enlace, aprobara un mensaje y confiara en un remitente. El trabajo del atacante era generar confianza en el momento.

La generación actual de ataques se salta ese paso por completo. La confianza ya no se fabrica, se hereda. Su canal de compilación ya confía en npm. Su proveedor ya confía en su CDN. Su navegador ya confía en el proveedor. El atacante no necesita engañar a nadie; sólo necesitan insertarse en cualquier lugar de una cadena de confianza que ya les ha sido otorgada.

Llámelo subversión de la cadena de suministro: el engaño no está dirigido a una persona; está dirigido al gráfico de dependencia.

El punto ciego en su pila de seguridad

Un proveedor de marketing integrado en sus propiedades web hace referencia a una CDN de JavaScript registrada hace seis semanas. SSL válido. Dominio reconocible. Luego, el guión se actualiza silenciosamente.

En su página de pago, el navegador carga silenciosamente el script modificado. Una superposición invisible intercepta las pulsaciones de teclas antes de que lleguen a su aplicación. Los registros de su servidor registran una sesión normal. No hay incendios de alerta.

CSP es el control más citado como defensa. Pero CSP es una lista de invitados, no un monitor de comportamiento. Un script incluido en la lista de permitidos que lee los campos de su formulario de pago y filtra los datos todavía está totalmente permitido, porque el origen es confiable. CSP maneja la conexión. No puede manejar la ejecución.

El comportamiento malicioso en 2026 se difiere al tiempo de ejecución por diseño. Los paquetes de Shai-Hulud permanecieron inactivos durante el escaneo automatizado y solo se activaron bajo condiciones de tiempo de ejecución específicas. El análisis estático no puede detectar cargas útiles cargadas dinámicamente después de que comienza la ejecución.

Lo que realmente requiere la detección

El informe sobre el costo de una vulneración de datos de 2025 de IBM encontró que la vulneración promedio tarda 241 días para identificar. En los ataques a la cadena de suministro en los que el comportamiento malicioso se ejecuta silenciosamente en la memoria del navegador, esa ventana puede ser significativamente más larga, a menos que esté observando el tiempo de ejecución.

La detección requiere observar qué hacen realmente los scripts después de ejecutarse: con qué dominios se comunican, a qué elementos de la página acceden y cómo su comportamiento se desvía de las líneas base establecidas. Se trata de monitoreo del comportamiento en tiempo de ejecución, la única capa de la que carecen actualmente la mayoría de las pilas de seguridad empresarial.

Las características a monitorear para:

  • Exfiltración de datos inesperada: Scripts que leen campos de formulario y transmiten valores a dominios fuera de su lista aprobada
  • Resolución de dominio dinámico: Scripts que llaman a dominios registrados recientemente o que se resuelven de manera diferente a su línea base
  • Deriva conductual: Un script que se comportó normalmente la semana pasada ahora accede a diferentes elementos de la página esta semana.

Detectar un dominio sospechoso en su árbol de dependencia es necesario, pero no suficiente. El problema más difícil es comprender qué hace realmente el script cargado desde ese dominio. La ofuscación generada por IA ahora está diseñada específicamente para derrotar el análisis estático: el código pasa el linting, imita bibliotecas minificadas legítimas y no produce coincidencias de firmas.

Cerrar esa brecha requiere desofuscar el comportamiento en tiempo de ejecución, ejecutar el script en un entorno instrumentado y rastrear su comportamiento real, sin intentar leer su fuente. Eso significa sacar a la luz a qué accede realmente un script: campos de formulario, cookies, puntos finales de la red, independientemente de cuán confusa esté la fuente. Es el enfoque que Reflectiz construyó Desofuscador de IA alrededor, y se detalla en la guía a continuación.

Tu plan de acción

Si no está seguro de por dónde empezar, priorice por exposición: las páginas de pago primero, las páginas de autenticación en segundo lugar y todo lo demás después. He aquí una secuencia práctica:

Esta semana:

  • Audite scripts de terceros para dominios CDN registrados recientemente en su cadena de dependencia
  • Revise los informes de CSP, no solo las infracciones, sino también lo que realmente están haciendo sus orígenes aprobados.
  • Identifique qué páginas manejan datos confidenciales (pago, inicio de sesión, formularios PII) y priorice el monitoreo allí primero.

Este mes:

  • Implementar monitoreo del comportamiento en tiempo de ejecución para páginas de pago y autenticación
  • Establecer líneas de base de comportamiento para todos los scripts de terceros aprobados.
  • Implementar comprobaciones de integridad de subrecursos (SRI) cuando los scripts se autohospedan o se pueden almacenar en caché

Son necesarios un registro de dominio proactivo, un CSP estricto y DMARC aplicado. Cubren el registro de dominio, la entrega de scripts y la suplantación de correo electrónico. Ninguno de ellos cubre lo que sucede después de que un script de proveedor aprobado se modifica silenciosamente. Esa es la brecha que la mayoría de los equipos no ven hasta que es demasiado tarde.

Los controles anteriores le indican qué hacer. Asignarlos a su entorno real, inventario de proveedores y obligaciones de cumplimiento es donde la ejecución se detiene. Reflectiz ha publicado un Guía de expertos CISO con el marco completo: gobernanza de dominio, controles fundamentales, monitoreo del comportamiento en tiempo de ejecución y una hoja de ruta de implementación por fases construida en torno a esa brecha.

Descarga la guía aquí →

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Las estaciones de trabajo para desarrolladores ahora son parte de la cadena de suministro de software – CYBERDEFENSA.MX

Los atacantes de la cadena de suministro no sólo intentan introducir código malicioso en software confiable. Están intentando robar el acceso que hace posible el software confiable. Recientemente, tres campañas separadas llegaron a npm, PyPI y Docker Hub en un período de 48 horas, y las tres apuntaron a secretos de entornos de desarrollador y canalizaciones de CI/CD, incluidas claves API, credenciales de nube, claves SSH y tokens. Esta es una preocupación constante y se propaga a sí misma, como se ve en ataques como las campañas del «mini Shai Hulud».

Ese patrón debería cambiar la forma en que los equipos de seguridad piensan sobre la cadena de suministro de software.

Tradicionalmente, la seguridad se centraba en sistemas compartidos como repositorios de código fuente, plataformas CI/CD, registros de artefactos, administradores de paquetes y entornos de nube. El objetivo era proteger las cargas de trabajo y los datos de producción. Es absolutamente necesario que nos centremos en estos ámbitos, pero el panorama es incompleto.

La entrega de software moderno comienza antes de que el código llegue a Git. Comienza en la estación de trabajo del desarrollador, donde se escribe el código, se instalan las dependencias, se prueban las credenciales, se solicita a los asistentes de IA, se crean contenedores y comienzan las acciones confiables.

Las estaciones de trabajo de los desarrolladores son una parte real de la cadena de suministro de software. Tratarlos como «simples» puntos finales comunes deja brechas entre la seguridad de los puntos finales, la seguridad de la identidad, la seguridad de las aplicaciones y la gobernanza de la cadena de suministro.

Los ataques a la cadena de suministro se han convertido en operaciones de recolección de credenciales

Los incidentes recientes siguen apuntando a la misma verdad operativa. Los atacantes pueden utilizar paquetes envenenados, imágenes comprometidas, bots de dependencia, flujos de trabajo maliciosos o herramientas de desarrollo vulnerables, pero el objetivo recurrente es el acceso.

Eventos como las campañas TeamPCP y Shai-Hulud muestran cómo los ataques a la cadena de suministro convergen cada vez más en torno al robo de credenciales. En la campaña TeamPCP, los atacantes utilizaron paquetes comprometidos y herramientas de desarrollo para recolectar tokens, credenciales de nube, claves SSH, archivos de configuración npm y variables de entorno.

Shai-Hulud impulsó el mismo patrón aún más, convirtiendo los entornos de desarrolladores infectados en puntos de recopilación de credenciales que expusieron miles de secretos en GitHub, servicios en la nube, registros de paquetes y sistemas internos.

Esto no es sólo una manipulación del software. Se trata de una recopilación de credenciales en puntos en los que los desarrolladores y la automatización ya tienen confianza.

La cadena de suministro queda expuesta cuando los atacantes obtienen acceso a credenciales y contexto que les permiten alterar, publicar, construir, implementar o hacerse pasar por sistemas de software confiables. Los paquetes modificados y publicados en un ataque moderno a la cadena de suministro permanecen activos durante horas, mientras que las herramientas de automatización combinan actualizaciones maliciosas en minutos.

El hilo conductor de muchos de los ataques recientes han sido los secretos, ya sea como vector de acceso inicial o como objetivo de recopilación.

La ruta del atacante ahora pasa por el contexto del lado del desarrollador

La estación de trabajo del desarrollador es valiosa porque concentra el contexto. A menudo contiene repositorios locales, archivos .env, historial de shell, claves SSH, credenciales y configuraciones del administrador de paquetes, scripts de compilación, registros de depuración y sesiones del navegador. Esas piezas se vuelven mucho más peligrosas cuando se ven juntas.

Un token de acceso único puede parecer limitado de forma aislada. Un token que se encuentra junto a un control remoto de Git, un script de implementación, un archivo README, un perfil de nube y una configuración de CI le indica al atacante dónde encaja el token y qué podría desbloquear. En la campaña Shai-Hulud 2.0, por ejemplo, las credenciales de GitHub dominaron las credenciales expuestas y exfiltradas, cada una con potencial acceso de administrador a repositorios y flujos de trabajo de CI.

El compromiso local no es sólo un problema de dispositivo. Puede servir como mapa para el control de fuentes, cuentas en la nube, flujos de trabajo de publicación de paquetes, sistemas CI/CD, API internas e infraestructura adyacente a la producción.

Autoridad de entrega de software de Developer Machines Concentrate

Una computadora portátil estándar para empleados puede exponer datos corporativos. Una estación de trabajo de desarrollador puede exponer la capacidad de cambiar el software. Esa distinción es fundamental al considerar la seguridad de los terminales.

Los desarrolladores suelen necesitar un acceso amplio para realizar su trabajo. Clonan repositorios privados, se autentican en servicios en la nube, publican paquetes, acceden a entornos de prueba e interactúan con múltiples herramientas internas. Sus máquinas se convierten en una intersección funcional de código fuente, credenciales, automatización y autoridad de entrega.

Si bien no todos los desarrolladores tienen acceso a la producción, muchos sí tienen acceso suficiente para influir en los sistemas que eventualmente producirán resultados de producción. Un token de registro puede afectar a los paquetes. Un token de GitHub puede afectar repositorios o flujos de trabajo. Un perfil de nube puede exponer la infraestructura. Una credencial CI/CD puede afectar el comportamiento de la compilación.

A la junta y a los auditores no les importa si un desarrollador almacenó un secreto localmente. En realidad, el riesgo empresarial es que una exposición local proporcione a los atacantes un camino hacia los sistemas que crean, modifican, publican u operan software.

Ese cambio cambia las preguntas que los equipos de seguridad deberían plantearse:

  • ¿Puede identificar qué credenciales se pueden utilizar desde las estaciones de trabajo de los desarrolladores?
  • ¿Puede limitar el valor y la vida útil de esas credenciales?
  • ¿Puede detectar material confidencial antes de que ingrese al historial de Git, registros de CI, tickets, artefactos o chat?
  • ¿Puede revocar y rotar el acceso rápidamente cuando sospecha que la estación de trabajo está comprometida?
  • ¿Puedes notar la diferencia entre exposición local de bajo impacto y credenciales con privilegios similares a los de administrador?

Esas preguntas se sitúan entre AppSec, endpoints, identidad, plataforma y seguridad en la nube. Independientemente de cómo decida coordinar su organización, debe comprender cómo se conecta el comportamiento de los desarrolladores con los sistemas de entrega.

La automatización y la inteligencia artificial hacen que la superficie de exposición sea más delgada y rápida

La automatización ha comprimido el tiempo entre el compromiso y el impacto. Los robots de actualización de dependencias pueden abrir y fusionar cambios rápidamente. Los sistemas CI/CD pueden ejecutar flujos de trabajo confiables automáticamente. Los administradores de paquetes pueden ejecutar scripts de instalación. Los agentes de IA y los asistentes de codificación pueden leer archivos, llamar a herramientas, generar comandos, inspeccionar resultados y mover el contexto entre sistemas.

La automatización no es intrínsecamente insegura, pero normalmente cualquier automatización hereda la confianza, especialmente si se presenta en forma de agencia. Si una actualización de dependencia maliciosa parece rutinaria, un flujo de trabajo automatizado puede hacerla avanzar más rápido de lo que un revisor humano puede entender lo que sucedió.

IA en el circuito

El desarrollo asistido por IA añade otro conjunto de puntos de transferencia. Los datos confidenciales pueden aparecer en mensajes, salidas de terminales, llamadas a herramientas, código generado, memoria del agente, registros y configuración local copiados en una sesión de depuración. La cuestión es más amplia que si un proveedor de modelos almacena indicaciones. El problema más importante es que el contexto de desarrollo local ahora fluye a través de sistemas más semiautomatizados.

Los equipos de seguridad deben evaluar el riesgo de la codificación de IA a través de la misma lente que utilizan para el riesgo de la cadena de suministro. Los equipos deben responder: ¿qué fuentes y datos puede leer la herramienta? ¿Qué puede ejecutar? ¿A dónde va la producción? ¿Qué credenciales hay cerca? Y, quizás lo más importante, ¿qué confianza hereda el flujo de trabajo?

Los controles posteriores siguen siendo importantes, pero ya es demasiado tarde por sí solos

El escaneo de repositorios, la protección de sucursales, la política de CI/CD, la firma de artefactos, el análisis de dependencias y los controles de tiempo de ejecución siguen siendo esenciales. Crean puntos de cumplimiento compartidos y ayudan a los equipos a controlar el software a escala.

El problema ahora es el momento oportuno, gracias a la velocidad de los ataques modernos. Los atacantes ahora aprovechan las herramientas impulsadas por IA para explotar todos y cada uno de los secretos a los pocos segundos de ser descubiertos.

Las barandillas reducen la exposición potencial y el radio de explosión. La captura de material confidencial mientras un desarrollador edita un archivo, prepara una confirmación, ejecuta un comando local, instala una dependencia o interactúa con un asistente de inteligencia artificial mantiene el impacto al mínimo.

Los programas maduros distinguen entre acciones que deberían bloquearse, acciones que deberían dar advertencias y acciones que simplemente deberían generar telemetría para una investigación más profunda. El objetivo no es sepultar a los desarrolladores en fricciones.

Trate la estación de trabajo como un límite de la cadena de suministro local

La cadena de suministro de software moderna no comienza cuando se envía código. Comienza donde el código, las credenciales, la automatización y la confianza se unen por primera vez.

Es hora de tratar la estación de trabajo del desarrollador como un límite de la cadena de suministro local. Ese límite incluye el IDE, la terminal, el cliente Git, el administrador de paquetes, las herramientas de contenedor, la CLI en la nube, el sistema de compilación local, las prácticas de manejo de secretos, los asistentes de IA y los agentes de automatización. Es el lugar donde la acción de los desarrolladores individuales se convierte en un riesgo de entrega de software organizacional.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Cuáles son las alertas de SOC más riesgosas que quedan sin respuesta – CYBERDEFENSA.MX

¿Por qué las alertas SOC más riesgosas quedan sin respuesta?

Los equipos de operaciones de seguridad están inundados de alertas. Pero el verdadero problema no siempre es el volumen de alertas; son los puntos ciegos. Las alertas más peligrosas son aquellas que nadie investiga.

Un informe reciente de The Hacker News examinó por qué ciertas categorías de alertas de alto riesgo (WAF, DLP, OT/IoT, inteligencia de la web oscura y señales de la cadena de suministro) no se investigan constantemente en los SOC empresariales. Los hallazgos apuntan a una brecha estructural en la forma en que se brinda la cobertura de seguridad hoy en día: no una falta de herramientas, sino un techo incorporado en cada modelo existente.

Su modelo SOC tiene un límite máximo de cobertura

Los equipos internos del SOC son los primeros en sentir la brecha. Sobrecargados con alertas rutinarias de gran volumen, los analistas rara vez tienen la capacidad o la experiencia especializada para investigar eventos WAF, anomalías DLP o señales de entornos tecnológicos operativos. Estos tipos de alertas requieren un conocimiento profundo y específico del dominio que la mayoría de los equipos SOC simplemente no tienen en su personal.

Los MSSP y MDR enfrentan una versión diferente del mismo problema. Investigar alertas complejas y especializadas requiere mucho tiempo y requiere un contexto empresarial que los proveedores gestionados no tienen. La economía no funciona a su favor, por lo que escalan estas alertas al cliente, el mismo equipo interno que carecía de la capacidad para investigarlas en primer lugar.

Las plataformas de automatización AI SOC han logrado avances significativos en los tipos de alertas comunes, pero la mayoría tiene un límite de cuatro a seis categorías predefinidas. Se basan en una lógica de clasificación estática y prediseñada. Cuando una alerta queda fuera de esa lógica, ya sea una amenaza nueva, una fuente de alerta desconocida o un vector de ataque emergente, la plataforma le quita prioridad o la transmite.

El resultado es un punto ciego en la intersección de todos los modelos SOC existentes: las alertas con mayor probabilidad de resultar en una infracción son precisamente aquellas para las cuales nadie tiene un flujo de trabajo que manejar.

¿Quién ofrece verdadera cobertura?

El 21 de mayo de 2026, Seguridad radiante y la empresa alemana de ciberseguridad Cirosec están organizando un seminario web técnico para abordar esta brecha directamente: «Cobertura de alerta que nadie más puede clasificar».

La sesión examinará las razones estructurales detrás del límite de cobertura, analizará los tipos de alertas específicas que más comúnmente no se investigan y hará una demostración en vivo de cómo la plataforma AI SOC de Radiant las clasifica.

Radiant se basa en una arquitectura fundamentalmente diferente a la de otras plataformas AI SOC. En lugar de depender de manuales prediseñados, su IA genera una lógica de clasificación personalizada sobre la marcha, para cualquier tipo de alerta, incluidas las que la plataforma nunca ha visto antes.

Detalles del seminario web

  • Fecha: 21 de mayo de 2026
  • Tiempo: 15:00 CEST (6:00 a. m. PDT)
  • Formato: Microsoft Teams: sesión técnica e interactiva
  • Anfitrión: Cirosec y Seguridad Radiante
  • Idioma: Inglés

Regístrese aquí para registrarse (haga clic en traducir página para Traductor de inglés en tu navegador)

Nota importante: el webinar será en inglés.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

solo son rojo y azul en la misma habitación – CYBERDEFENSA.MX

Defender una red a las 2 am se parece mucho a esto: un analista copia y pega un hash de un PDF en una consulta SIEM. Se está reescribiendo a mano un guión del equipo rojo para que el equipo azul pueda usarlo. Un parche esperando una ventana de aprobación de cambios que es más larga que la propia ventana de explotación.

Nadie en esa cadena es incompetente.. Cada ser humano está haciendo su trabajo correctamente. El problema es el sistema, sus flujos de trabajo y sus confusas transferencias.

Por el contrario, el reloj del atacante casi ha desaparecido.

En 2024, el tiempo medio desde la publicación de un CVE hasta que un exploit funcionaba era de 56 días. Para 2025, se había reducido a 23 días. En lo que va de 2026, dura aproximadamente 10 horas en 3532 pares de exploits CVE de CISA KEV, VulnCheck KEV y ExploitDB.

Figura 1. La vulnerabilidad actual a la explotación de Windows es ahora de 10 horas

La pequeña buena noticia es que el reloj del defensor se ha acelerado para correr en horas.. La realmente mala noticia es que el reloj del atacante se ha adelantado y ahora funciona en segundos. Ni siquiera está cerca de ser una pelea justa.

Durante una década, la industria de la seguridad ha tenido un nombre para la práctica que se supone debe cerrar esta brecha: equipo morado. Es la respuesta correcta. Simplemente no ha sido práctico, hasta ahora.

¿Qué es realmente el equipo morado?

equipo morado es simple en concepto.

Red encuentra los caminos que tomaría un atacante. El azul valida si las detecciones de incendios y la prevención se mantienen. Ellos iteran. La salida del rojo se convierte en la entrada del azul. La salida del azul se convierte en la siguiente entrada del rojo. El bucle refuerza la postura de su organización continuamente en lugar de una vez por trimestre.

Esa es la idea y, nuevamente, es sólida. Lamentablemente, todo se desmorona en la ejecución.

Tres razones por las que el equipo morado tradicional no se ha puesto en práctica

Razón 1: El equipo morado humano crea demasiada fricción.

Casi nadie ejecuta el equipo morado como un bucle real. Los equipos no hablan con suficiente frecuencia y, cuando lo hacen, la gente se ve arrastrada a largas reuniones, informes detallados, largas autopsias y emergencias familiares. El cuello de botella casi siempre es humano, en el sentido más común.

Mire adónde van realmente las horas de los defensores.

  • No dentro de la EDR: se disparó.
  • No dentro del SIEM: estaba correlacionado.
  • No dentro del escáner: tenía el CVE.

El tiempo de respuesta muere en tránsito. El mensaje de Slack no leído. El hash copiado y pegado. El PDF se envió por correo electrónico para su revisión. El boleto esperando atención o aprobación. El guión del equipo rojo se está reconstruyendo a mano para el equipo azul. Esta es la entrega de espaguetis. Una vez que vea las ineficiencias y los puntos de falla, no podrá dejar de verlos.

Razón 2: Orquestar equipos y herramientas es el verdadero cuello de botella

El equipo de red posee firewalls. El SOC consume alertas. Ejercicios de carreras rojas. El azul genera detecciones. VM persigue CVE. Las operaciones de TI aplican parches.

Cada grupo opera una o más herramientas; cada herramienta emite un artefacto (un hallazgo, una alerta, un informe, un ticket) que se recoge, reinterpreta y entrega. Lo que estos equipos producen colectivamente debe ser un servicio: una postura de seguridad continuamente validada. En realidad, suele ser un desastre amañado por un jurado, pegado por humanos sobrecargados que escriben con los ojos llorosos en Jira a medianoche.

Así que el equipo morado sigue siendo en gran medida una aspiración. Una idea genial en las plataformas de proveedores. Quizás un ejercicio trimestral. Casi nunca operativo. Ciertamente no es lo suficientemente operativo.

Razón 3: los equipos morados tradicionales no pueden seguir el ritmo de los adversarios impulsados ​​por IA

Esto es lo que ha cambiado. Los atacantes obtuvieron un LLM. Los defensores todavía están completando un ticket de Jira.

Para la mayoría de las organizaciones, el proceso de aprobación de cambios por sí solo es ahora más largo que la ventana de explotación.

Un atacante asistido por IA puede comprometer un sistema en 73 segundos. Un defensor, que trabaja a través de la cadena de transferencia estándar entre SOC, los equipos rojo y azul y TI, normalmente tarda al menos 24 horas en implementar una solución.

Figura 2. Traspaso de espaguetis entre equipos

Un ejercicio trimestral del equipo morado, o incluso mensual, ya no es un bucle, es una casilla que hay que marcar, una instantánea de una batalla que ya ocurrió y, por lo general, un ejercicio inútil.

Ingrese al equipo morado autónomo

La misma tecnología que comprime el reloj del atacante puede comprimir el del defensor.

La buena noticia es que el equipo morado autónomo, por su propia naturaleza, es exactamente el tipo de flujo de trabajo en el que la IA es buena: un circuito estrecho y bien definido entre dos funciones especializadas, donde el cuello de botella siempre ha sido la transferencia humana y de conocimiento en lugar del trabajo en sí.

Cuando los agentes autónomos ejecutan las transferencias, el ciclo finalmente se cierra a la velocidad de la máquina.

  • Los hallazgos de Red se convierten automáticamente en las pruebas de Blue.
  • Los huecos del azul se convierten en el próximo ejercicio del rojo.
  • Sin pausas para el café, sin niños que regresan de la escuela, sin interrupciones durante las vacaciones.

El sistema que la gente ha estado describiendo durante diez años ahora finalmente puede funcionar como una metodología continua, no como un evento del calendario.

Esto no es «IA para seguridad» en el sentido que la mayoría de los proveedores han presentado durante el último año: generar una regla YARA, resumir una alerta, redactar un ticket. Esas son automatizaciones de tareas. Útil y cada vez más útil. Pero la verdadera autonomía es otra cosa.: un agente que ejecuta todo el bucle de un extremo a otro, con cada paso auditable para que pueda anularlo, resintonizarlo o revertirlo.

Y es un dial, no un acantilado. El rastreo es manual. La caminata está programada con asistencia de IA. La ejecución es de un extremo a otro con revisión humana solo cuando es necesario.

Cómo se ve el equipo morado autónomo en la práctica: BAS, Pentest automatizado y movilización impulsada por IA

Para ser efectivo, el equipo morado autónomo requiere tres componentes que funcionen como un solo sistema en lugar de herramientas separadas:

Pruebas de penetración automatizadas Esta es la pregunta de Red, que se responde continuamente: ¿puede un atacante alcanzar las joyas de la corona en su entorno, dadas las exposiciones y los controles actuales?

Simulación de ataques e infracciones (BAS) es la respuesta de azul: ¿lo bloqueó el firewall, lo detectó el EDR, se activó la regla SIEM, se desarrolló la respuesta de la manera que el runbook dice que debería?

Figura 3. BAS y Pentesting automatizado le ofrecen una visión completa

Movilización impulsada por IA es la parte que solía ser un humano escribiendo en Jira, ahora dirigida por una cadena de agentes especializados. Llega una alerta CISA. Un agente CTI lo enriquece frente a su entorno. Un agente de referencia decide que la amenaza es relevante y extrae la postura actual de los datos de BAS, pentest y exposición. Los agentes rojo y azul ejecutan la simulación y la validación en paralelo. Un agente movilizador implementa automáticamente soluciones de bajo riesgo, abre tickets para los moderados y marca el resto para revisión humana. Un agente reportero escribe una visión ejecutiva para el liderazgo y una visión técnica para el SOC.

No hay analistas en la cadena. Cada paso sigue siendo visible en la consola del operador. No hay caja negra, simplemente no hay humanos en el asiento que escribe en Jira.

El resultado no son 50.000 CVE clasificados por CVSS. Es una cola de acción continua en rojo y azul: qué es realmente explotable hoy, en comparación con sus controles reales, y qué hacer al respecto antes de que se cierre la ventana de explotación.

Eso es equipo morado, no sólo automatización. Es el bucle con el que la industria ha estado soñando y que finalmente funciona al ritmo que exigen ahora las amenazas impulsadas por la IA.

Véalo funcionando dentro de una empresa real

Un bucle continuo es la respuesta correcta. Pero «continuo» todavía implica un ritmo humano. Cuando los atacantes operan a la velocidad de una máquina, la brecha que importa no es entre ver y detectar; está entre detectar y demostrar lo suficientemente rápido como para que un adversario impulsado por IA no se entere primero.

Aquí es donde la validación pasa de continua a autónoma: los agentes de IA leen la alerta, determinan el alcance de la prueba, ejecutan la simulación, impulsan la solución y escriben el informe, mientras que el SOC se centra en el panorama general e, idealmente, recupera un poco de sueño muy necesario.

Analizaremos exactamente cómo se ve esto (la arquitectura, los flujos de trabajo de agencia, la realidad operativa de ejecutar esto dentro de una empresa real) al mismo tiempo. Cumbre de Validación Autónoma los días 12 y 14 de mayoorganizado por Frost & Sullivan y con la participación de profesionales de Kraft Heinz, Hacker Valley y Glow Financial Services, junto con el CTO de Picus, Volkan Erturk.

Véalo en acción en la cumbre →

Nota: Este artículo fue escrito por Sıla Özeren HacıoğluIngeniero de Investigación de Seguridad en Picus Security.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Los funcionarios de la agencia de espionaje dicen que la ansiedad por perder el empleo y moverse rápido y «seguro» son algunos de los principales desafíos en la reforma de la fuerza laboral de IA

Como muchas organizaciones, la Agencia Nacional de Inteligencia Geoespacial está tomando medidas para integrar herramientas de inteligencia artificial en sus operaciones comerciales.

Jay Harless, director de desarrollo humano de la NGA, dijo que la agencia está tratando de lograr un equilibrio: actuar lo suficientemente rápido como para mantener el ritmo de lo que los funcionarios de seguridad nacional de Estados Unidos ven cada vez más como una carrera armamentista de inteligencia artificial con países adversarios como Rusia y China, pero no tan rápido como para alterar los métodos probados de recopilación de inteligencia.

«Uno de nuestros principales impulsores es que nuestros adversarios estaban invirtiendo mucho, por lo que existe la presión de adelantarnos y hacerlo de forma segura», dijo Harless el martes en la conferencia de prensa. Foro federal de Workdaypresentado por Scoop News Group. «También nos damos cuenta de que algunos de nuestros adversarios pueden no tener los mismos límites legales y éticos que nosotros y nuestros socios necesitamos».

Harless dijo que la agencia y otros miembros de la comunidad de inteligencia están trabajando para construir sistemas con IA agente que opere y pueda acelerar la toma de decisiones «dentro de límites seguros». Eso significa construir nueva infraestructura de TI, protocolos de validación, monitorear sesgos o comportamientos deshonestos e implementar mecanismos de rendición de cuentas.

“Nos estamos moviendo rápido y con seguridad al distinguir lo que debe automatizarse, lo que debe aumentarse y lo que debe mantenerse puramente humano, porque hay algunas cosas que siempre serán [human-operated]”, dijo.

Una pieza clave es descubrir exactamente cómo debería encajar la IA en el trabajo. Sasha Muth, subdirectora de desarrollo humano de la NGA, dijo que la agencia prevé un esfuerzo de tres a cinco años para transformar su fuerza laboral y su infraestructura de TI para la era de la IA. Este año se dedicará en gran medida a poner en marcha “elementos estructurales” sobre cuándo y cómo los analistas utilizan la IA, y a reevaluar qué cualificaciones debería exigir la agencia para los puestos de nivel inicial.

Pero ese esfuerzo también está causando tensiones dentro de la fuerza laboral, y Muth reconoció que parte del desafío es convencer a los empleados de base de que la tecnología los ayudará, no los reemplazará. La agencia contrató a su primer director de inteligencia artificial en 2024, y su próximo plan estratégico de tres años se centrará en la gestión del cambio, el desarrollo profesional y la actualización de las habilidades laborales de los empleados.

Muth dijo que están enfocados en desarrollar sus necesidades de capital humano porque uno de sus mayores temores es que durante esa transición de cinco años «vamos a perder gran parte de nuestra experiencia» al automatizar funciones y no hacer lo suficiente para modernizar los requisitos laborales.

«Lo vemos como una gran transformación, no sólo por utilizar la tecnología, sino por mover a nuestra fuerza laboral junto con nosotros, tenerlos entusiasmados con los cambios y no temerosos, porque hay mucho miedo… de que su trabajo desaparezca, de que no lo tengan», dijo.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Las extensiones del navegador son el nuevo canal de consumo de IA del que nadie habla – CYBERDEFENSA.MX

Si bien gran parte del debate sobre la seguridad de la IA se centra en la protección del consumo de IA «en la sombra» y GenAI, hay una ventana abierta que nadie está protegiendo: las extensiones de navegador de IA.

A Un nuevo informe de LayerX expone cuán profundo es este punto ciego y por qué las extensiones de IA pueden ser la superficie de amenaza de IA más peligrosa en su red que no está en el radar de nadie.

Las extensiones de navegador de IA no activan su DLP y no aparecen en sus registros de SaaS. Viven dentro del propio navegador, con acceso directo a todo lo que sus empleados ven, escriben y permanecen conectados. Las extensiones de IA tienen un 60% más de probabilidades de tener una vulnerabilidad que las extensiones en promedio, tienen 3 veces más probabilidades de tener acceso a cookies, 2,5 veces más probabilidades de poder ejecutar scripts remotos en el navegador y 6 veces más probabilidades de haber aumentado sus permisos en el último año. Estas extensiones se instalan en segundos y pueden permanecer en su entorno indefinidamente.

La superficie de amenazas de la extensión del navegador es para todos, pero nadie está mirando

El primer concepto erróneo es que las extensiones son un riesgo de nicho. Algo limitado a un subconjunto de usuarios o casos extremos. Esa suposición es completamente errónea.

Según el informe, el 99% de los usuarios empresariales ejecutan al menos una extensión de navegador y más de una cuarta parte tiene más de 10 instaladas. Este no es un problema de cola larga; es universal.

Sin embargo, la mayoría de las organizaciones no pueden responder preguntas básicas. ¿Qué extensiones están en uso? ¿Quién los instaló? ¿Qué permisos tienen? ¿A qué datos pueden acceder?

Los equipos de seguridad han pasado años creando visibilidad de redes, puntos finales e identidades. Irónicamente, las extensiones del navegador siguen siendo un importante punto ciego.

Las extensiones de IA son el canal de consumo de IA del que nadie habla

Si bien gran parte de la conversación actual sobre la seguridad de la IA se centra en las plataformas SaaS y las API, este informe destaca un canal diferente y en gran medida ignorado: las extensiones de navegador de IA.

Estas herramientas se están extendiendo rápidamente. Aproximadamente 1 de cada 6 usuarios empresariales ya utiliza al menos una extensión de IA, y ese número no hace más que crecer.

Las organizaciones pueden bloquear o monitorear el acceso directo a las aplicaciones de IA. Pero las extensiones funcionan de manera diferente. Se encuentran dentro del navegador. Pueden acceder al contenido de la página, a las entradas del usuario y a los datos de la sesión sin activar los controles tradicionales.

De hecho, crean una capa no gobernada de uso de IA, que pasa por alto la visibilidad y la aplicación de políticas.

Las extensiones de IA no solo son populares. Son más riesgosos

Sería fácil suponer que las extensiones de IA conllevan un riesgo similar al de otras extensiones. Los datos muestran lo contrario.

Las extensiones de IA son significativamente más peligrosas. Tienen un 60% más de probabilidades que el promedio de tener un CVE, 3 veces más probabilidades de tener acceso a cookies, 2,5 veces más probabilidades de tener permisos de secuencias de comandos y 2 veces más probabilidades de poder manipular las pestañas del navegador.

Cada uno de estos permisos tiene implicaciones reales. El acceso a las cookies puede exponer los tokens de sesión. Los scripts permiten la extracción y manipulación de datos. El control de pestañas puede facilitar el phishing o la redirección silenciosa.

Esta combinación de adopción rápida, acceso elevado y gobernanza débil hace que las extensiones de IA sean un vector de amenaza emergente urgente.

Las extensiones no son estáticas. Cambian con el tiempo

Los equipos de seguridad suelen tratar las extensiones como estáticas. Algo que se puede aprobar una vez y olvidar. Pero no es así como funciona.

Las extensiones evolucionan. Reciben actualizaciones. Cambian de propietario. Amplian permisos.

El informe muestra que las extensiones de IA tienen casi seis veces más probabilidades de cambiar sus permisos con el tiempo, y que más del 60% de los usuarios tienen al menos una extensión de IA que cambió sus permisos durante el último año.

Esto crea un objetivo en movimiento que las listas permitidas tradicionales no pueden seguir. Una extensión que ayer era segura puede no serlo hoy.

La brecha de confianza en las extensiones del navegador es mayor de lo esperado

Los equipos de seguridad se basan en una variedad de señales de confianza para evaluar las extensiones, incluida la transparencia del editor, el recuento de instalaciones, la frecuencia de actualización y la presencia de una política de privacidad. Si bien estos no indican directamente un comportamiento malicioso, son clave para evaluar el riesgo general.

Una parte importante de las extensiones tiene bases de usuarios muy bajas. Más del 10% de todas las extensiones tienen menos de 1.000 usuarios, una cuarta parte tiene menos de 5.000 usuarios y un tercio tiene menos de 10.000 instalaciones. Esto es particularmente un desafío con las extensiones de IA, donde el 33% de las extensiones de IA tienen menos de 5.000 usuarios, y casi el 50% de las extensiones de IA tienen menos de 10.000 usuarios. Una gran base de usuarios es esencial para establecer una confianza continua, pero una vez más, las extensiones de IA están mostrando un riesgo sustancialmente mayor.

Además, alrededor del 40% de las extensiones no han recibido una actualización en más de un año, lo que sugiere que ya no se mantienen activamente. Las extensiones que no se actualizan periódicamente pueden contener vulnerabilidades no resueltas o código obsoleto que los atacantes aprovechan.

Como resultado, la mayoría de las extensiones utilizadas en entornos empresariales muestran señales débiles o faltantes en estas áreas. Esto plantea serias dudas sobre el manejo y el cumplimiento de los datos. También destaca el poco escrutinio que reciben las extensiones en comparación con otros componentes de software.

Convertir el conocimiento en acción: el camino a seguir para los CISO

El informe describe una dirección clara para los equipos de seguridad:

  1. Audite continuamente la superficie de amenazas de extensión de la organización: Dado que el 99 % de los usuarios empresariales ejecutan al menos una extensión, un inventario completo es un primer paso obligatorio hacia la reducción de riesgos. Los CISO deben realizar una auditoría de extensión en toda la organización que cubra todos los navegadores, puntos finales administrados y no administrados, en todos los usuarios.
  2. Aplique controles de seguridad específicos a las extensiones de IA: Las extensiones de IA representan un riesgo enorme debido a sus permisos elevados que pueden exponer sesiones de SaaS, identidades y datos confidenciales del navegador. Las organizaciones deberían aplicar políticas de gobernanza más estrictas para controlar cómo estas extensiones interactúan con los entornos empresariales.
  3. Analice el comportamiento de las extensiones, no solo los parámetros estáticos: Las aprobaciones estáticas no son suficientes. El riesgo debe evaluarse continuamente en función de los permisos, el comportamiento y los cambios a lo largo del tiempo.
  4. Hacer cumplir los requisitos de confianza y transparencia: Las extensiones que tienen un número de instalaciones muy bajo, carecen de políticas de privacidad o muestran un historial de mantenimiento deficiente deben tratarse como de mayor riesgo. Establecer criterios mínimos de confianza ayuda a reducir la exposición a extensiones no verificadas o abandonadas.

Una nueva lente sobre un viejo problema

Durante años, las extensiones del navegador se han tratado como una característica conveniente. Algo que permita la productividad y la personalización. Sin embargo, ya no son un riesgo periférico. Son una parte fundamental de la superficie de ataque empresarial. Ampliamente utilizados, altamente privilegiados y en gran medida no monitoreados, crean exposición directa a datos confidenciales y sesiones de usuarios.

Descargue el informe completo de seguridad de extensiones de LayerX para comprender el alcance completo de estos hallazgos, identificar dónde se encuentra realmente su exposición y obtener un camino claro para controlar esta creciente superficie de ataque sin interrumpir la productividad.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.