Los flujos de trabajo generados por IA son un desastre de seguridad silencioso
OPINIÓN
Un analista de seguridad de una gran empresa descubrió recientemente que se copiaron documentos confidenciales de recursos humanos en un canal de Microsoft Teams al que podían acceder cientos de empleados. No fue causado por un interno malicioso, una cuenta de administrador comprometida o un atacante sofisticado. Fue causado por un flujo de trabajo de Power Automate.
El flujo de trabajo fue creado por un desarrollador que quería automatizar la aprobación de documentos entre SharePoint y Teams. Para avanzar más rápido, el desarrollador utilizó un asistente de inteligencia artificial para generar la lógica de automatización. Funcionalmente, el flujo de trabajo funcionó. Los documentos se trasladaron de un lugar a otro. Se han enviado notificaciones. El proceso de aprobación se hizo más rápido.
El problema era que nadie había revisado los permisos, el flujo de datos o las implicaciones de seguridad detrás de la automatización. Este es el riesgo al que se enfrentan muchas empresas.
Asistentes de codificación de IA ahora se utilizan para generar rápidamente scripts, flujos de trabajo, consultas e integraciones. Al mismo tiempo, Microsoft 365 está en el centro de la mayoría de los entornos corporativos. Incluye correos electrónicos, documentos, conversaciones de Teams, sitios de SharePoint, archivos de OneDrive, datos de identidad, registros de cumplimiento y procesos comerciales.
Por sí solas, las herramientas de codificación de IA y las plataformas de automatización de Microsoft 365 ofrecen un valor de productividad real. Juntos, crean un problema de seguridad silencioso pero grave: una automatización que funciona pero que nadie comprende del todo.
Por qué los flujos de trabajo generados por IA plantean un riesgo diferente
La mayoría de las empresas ya tienen cierto nivel de control sobre el desarrollo de software tradicional. El código normalmente pasa por revisiones por pares, pruebas, canales de implementación y controles de seguridad. Este no suele ser el caso con la automatización de Microsoft 365.
Los flujos de Power Automate, los scripts de Graph API, las automatizaciones de SharePoint, las consultas de eDiscovery, las integraciones de Teams y los scripts de PowerShell suelen ser creados por administradores, analistas de negocios, desarrolladores y usuarios avanzados. Su objetivo principal suele ser simple: acelerar un proceso.
Cuando se agrega la IA, la barrera a la automatización cae aún más. Un usuario ya no necesita amplios conocimientos sobre los permisos de Microsoft Graph, el comportamiento del conector, la herencia de SharePoint, las políticas de DLP o el registro de auditoría. Pueden describir lo que quieren en un inglés sencillo y tener un guión o flujo de trabajo funcional en minutos. Eso suena eficiente. También es peligroso.
El problema no es que la IA esté creando intencionalmente una automatización maliciosa. El problema es que la IA a menudo produce código que parece correcto porque funciona. Pero trabajar no es sinónimo de seguridad. Muchos usuarios prueban si la automatización completa la tarea. Mucho menos comprobar si se tienen en cuenta los privilegios mínimos, la clasificación de datos, los límites de acceso, las reglas de retención o los requisitos de auditoría.
Esto crea una automatización en la sombra dentro de Microsoft 365: los flujos de trabajo y los scripts se ejecutan silenciosamente y tienen acceso a datos confidenciales de la empresa.
donde algo sale mal
1. Los permisos excesivos se vuelven normales
Los scripts de Microsoft Graph generados por IA a menudo tienden a tener permisos amplios porque el acceso amplio aumenta la probabilidad de que el código funcione.
Un desarrollador puede solicitar una secuencia de comandos que lea archivos de SharePoint y publique actualizaciones en Teams. El código generado puede requerir permisos amplios a nivel de inquilino en lugar de acceso limitado a un sitio, biblioteca o canal específico.
La empresa ve una automatización exitosa. La seguridad hereda una nueva ruta privilegiada.
Si la cuenta de servicio, el registro de la aplicación o la identidad de la automatización se ven comprometidos posteriormente, los atacantes pueden obtener mucho más acceso del necesario para el caso de uso original.
2. Los flujos de trabajo se convierten en canales silenciosos de fuga de datos
Power Automate facilita la transferencia de información entre SharePoint, Teams, Outlook, OneDrive, Excel, herramientas de software como servicio (SaaS) de terceros y destinatarios externos.
Es precisamente esta conveniencia la que lo hace arriesgado.
Un flujo de distribución de informes mensual podría enviar sin darse cuenta datos de nómina, registros de clientes, documentos legales o archivos comerciales confidenciales al canal de Teams o al buzón externo incorrecto. Debido a que estos flujos de trabajo son automáticos, las divulgaciones pueden continuar durante semanas o meses antes de que alguien se dé cuenta.
Este no es un escenario de incumplimiento dramático. En cierto modo es incluso peor porque parece una actividad empresarial normal.
3. La automatización del cumplimiento puede generar riesgos legales
Los equipos de seguridad y cumplimiento también utilizan la IA para generar búsquedas de eDiscovery, consultas de auditoría, scripts de riesgo interno y flujos de trabajo relacionados con la retención.
Una consulta de eDiscovery mal redactada puede recopilar demasiados datos, perder evidencia importante, exponer comunicaciones privilegiadas o manejar mal las solicitudes de retención.
En industrias reguladas, esto puede ser más que un error técnico. Puede dar lugar a hallazgos de auditoría, litigios, problemas de privacidad y riesgos regulatorios.
La velocidad ha cambiado. En el pasado, desarrollar la automatización empresarial requería tiempo y experiencia. Hoy en día, un usuario puede generar un script de PowerShell, una integración de Graph API o un flujo de trabajo de Power Automate en minutos. Esto significa que los equipos de seguridad ya no revisan la automatización al mismo ritmo en que se crea.
La vieja suposición de que sólo los desarrolladores experimentados crean flujos de trabajo de producción ya no es válida. La IA ha permitido a muchas más personas crear una automatización poderosa, incluidas personas que no comprenden el modelo de seguridad detrás de lo que están implementando.
Muchas organizaciones están ciegas en esto. Controlan aplicaciones, infraestructura de nube, puntos finales e identidades, pero a menudo tienen poca visibilidad de la capa de automatización que los conecta a todos.
Prohibir los asistentes de IA no es una respuesta realista. Bloquear la automatización tampoco es realista. Ambos son parte de la forma en que funcionan las empresas modernas en la actualidad.
La mejor respuesta es control.
Los equipos de seguridad deberían tratar la automatización generada por IA como si fuera código. Los flujos de Power Automate, los scripts de Graph, los registros de aplicaciones, las cuentas de servicio, las consultas de eDiscovery y las automatizaciones de PowerShell deben revisarse antes de su puesta en funcionamiento.
También debe imponer privilegios mínimos en la automatización de Microsoft 365. Los permisos de gráficos amplios, el acceso de administrador persistente, los conectores demasiado permisivos y las cuentas de servicios compartidos deben tratarse como resultados de alto riesgo.
Las empresas necesitan un inventario de flujos de trabajo y scripts que se ejecutan en Microsoft 365. Si los equipos de seguridad no saben que existe un flujo de trabajo, no pueden evaluar su riesgo.
El seguimiento también es importante. Se deben revisar continuamente los nuevos flujos, los cambios de conectores, las concesiones de permisos, las actividades de intercambio externo, los movimientos inusuales de archivos y los eventos de consentimiento de aplicaciones.
Por último, los desarrolladores y los ciudadanos desarrolladores necesitan una orientación clara: el código generado por IA no es un código aprobado. Es un borrador que aún requiere revisión humana.
Es posible que la próxima vulnerabilidad de seguridad de las grandes empresas no sea el malware generado por IA.
Tal vez sea la automatización empresarial generada por IA la que parece inocua, pasa pruebas funcionales e introduce silenciosamente permisos excesivos, exposición de datos y fallas de cumplimiento en Microsoft 365. El flujo de trabajo no parecerá sospechoso. No se activan alarmas. Simplemente hará lo que se le pidió que hiciera. Y es exactamente por eso que es peligroso.
No te pierdas el último podcast de Dark Reading Confidential. ¿Los CISO necesitan un código de ética? Sobornos, trabajos que no se presentan, capital de riesgo “sucio” y productos de estantería: el experto de la industria Robert “RSnake” Hansen explica por qué cree que es hora de elaborar un código de ética para el CISO. Esto podría garantizar que los jefes de ciberseguridad no se involucren en negocios autónomos que podrían poner en peligro la seguridad corporativa e incluso nacional. ¡Escuche ahora!
Este contenido de ciberseguridad nos ha llegado de: DarkReading
Puedes encontrar la noticia original en el enlace que sigue: https://www.darkreading.com/cyber-risk/ai-generated-workflows-silent-security-disaster
