El acceso restringido suena a control de seguridad. Para Frontier Cyber Security AI, este es solo un proceso de incorporación de proveedores.
No hay duda de que la IA en ciberseguridad está pasando de demostraciones a pequeña escala a pruebas empresariales en etapas iniciales. De hecho, algunos de los sistemas de IA de ciberseguridad más avanzados tienen el potencial de acelerar significativamente el descubrimiento de vulnerabilidades; Factores en código e infraestructura; Y comprima el trabajo que debe realizarse de una vez en unas pocas horas.
Los estándares defensivos son reales.
Sin embargo, la cuestión principal no es simplemente si una organización puede obtener acceso a un programa restringido. La cuestión principal es si la organización está preparada para vincular esta capacidad a su código fuente, registros, aplicaciones en la nube, vulnerabilidades identificadas y/o flujos de trabajo de respuesta a incidentes.
Ingeniero principal Ingeniero principal y OASIS Contribuye a los estándares de seguridad de IA en CoSAI e IETF.
Una lista de espera determina quién tiene acceso a un programa. Ese acceso no determina si su uso es seguro.
Esto representa un punto ciego en los sistemas de evaluación de muchas organizaciones. Al evaluar soluciones de ciberseguridad basadas en IA, muchas organizaciones aplican el mismo enfoque que usarían al comprar productos de seguridad tradicionales.
Específicamente, analizan los resultados de las pruebas comparativas, las tasas de falsos positivos, los idiomas admitidos, los modelos de implementación y los costos.
Si bien todos estos factores serían relevantes para una solución de ciberseguridad basada en IA, ninguno de ellos explica la capacidad de la solución para pensar/analizar vulnerabilidades, desarrollar exploits para esas vulnerabilidades o comunicarse con herramientas relacionadas con la seguridad.
Como tal, cualquier sistema con estas capacidades será mucho más que un simple “escáner”. En cambio, el sistema representará parte del entorno de control de la organización.
Por lo tanto, antes de integrar uno de estos sistemas en un activo empresarial real, los líderes tecnológicos necesitan sus propias pruebas de aceptación, a las que yo me refiero como pruebas de aceptación de IA cibernética.
Esta prueba consta de cinco “puertas” separadas, cada una de las cuales debe dar como resultado una respuesta de “conexión” o “no conexión” antes de que se permita al sistema trabajar en cualquier dato/herramienta/flujo de trabajo de producción.
Las pruebas de aceptación de Cyber AI no pretenden aplicar el mismo nivel de escrutinio a cada esfuerzo de prueba. Una prueba de espacio aislado, un piloto interno, una implementación de producción completa y un sistema controlado regulatoriamente no deberían compartir la misma línea base de control.
El problema comienza cuando las organizaciones tratan su acceso a producción como un espacio aislado porque el proveedor ya les ha dado permiso para hacerlo.
Distribución: ¿Quién puede llegar al modelo?
“Acceso restringido” generalmente significa que el vendedor tiene acceso limitado a clientes, socios o defensores críticos seleccionados. Esto no explica necesariamente quién tiene acceso diario al entorno del modelo.
Los compradores empresariales deben preguntar cómo se autentica el acceso, si el alcance de las credenciales, cómo se gestiona el acceso de contratistas y socios, y si las rutas de acceso se monitorean por separado de la actividad habitual de los usuarios.
Una capacidad puede estar limitada por la política, pero es funcionalmente amplia si el personal de apoyo, los contratistas y los socios de integración tienen raíces en el mismo entorno.
Una revisión distribuida debería responder una pregunta: ¿Quién puede tocar el sistema que puede tocar nuestros datos?
Conectarse o no conectarse: ¿Podemos rastrear todas las rutas de acceso al entorno del modelo, incluido el soporte de proveedores, los contratistas y los socios de integración?
Datos: el código no es el único activo sensible
Cuando un modelo de ciberIA revisa código, registros, telemetría o resultados de vulnerabilidad, la organización necesita saber qué sale de su alcance. El código fuente es la preocupación obvia, pero los registros pueden revelar nombres de host, identificadores de suscriptores, rutas de acceso o cronogramas de eventos.
El aviso puede contener detalles arquitectónicos. Los resultados del deterioro pueden revelar un deterioro anormal antes de que se complete la reparación. Los metadatos también pueden volverse confidenciales cuando se agrupan entre sistemas.
El proveedor debe proporcionar un diagrama de flujo de datos que muestre dónde se procesan, dónde se almacenan los resultados, cuánto tiempo se conservan y quién puede acceder a ellos. Si el programa implica una defensa compartida, la organización también necesita saber qué resultados se pueden compartir con otros participantes y sobre qué base.
Conexión o no conexión: ¿Sabemos exactamente qué códigos, indicaciones, registros, telemetría y hallazgos abandonan nuestro perímetro cuando este sistema está en ejecución?
Capacidad: Cuatro niveles, cuatro perfiles de riesgo
Las empresas deben distinguir entre lo que el modelo sabe y lo que el modelo puede hacer. Un punto de partida útil es separar las capacidades en cuatro niveles: monitorear, analizar, recomendar y actuar.
El seguimiento y el análisis son procesos de sólo lectura. El modelo revisa una copia de código en el espacio aislado, analiza registros, examina datos de configuración o resume los hallazgos de vulnerabilidad. El principal riesgo es la exposición de los datos, no la acción operativa. Estas capas suelen ser las mejores candidatas para un piloto inicial una vez que se han definido los límites de los datos.
Las recomendaciones aumentan el riesgo. Modele borradores de reglas de detección, proponga parches o identifique rutas de explotación. El resultado puede ser consultivo, pero aún afecta las decisiones posteriores. Eso significa que la gente necesita validación antes de que algo entre en producción.
La ley es el nivel de riesgo más alto. El modelo puede activar escáneres, emitir tickets, modificar reglas, consultar telemetría de producción, ejecutar scripts de corrección o llamar a servicios en la nube. Una vez que el modelo puede activar herramientas, la evaluación debe incluir el radio de ráfaga, la reversibilidad, los umbrales de aprobación y las restricciones de tiempo de ejecución.
Se requieren planes claros de aprobación, registro y reversión para cada acción antes de iniciar el piloto.
Los modelos no deberían tomar decisiones por su propia autoridad. En las arquitecturas de seguridad de IA maduras, las decisiones de autorización se encuentran fuera del modelo y se aplican mediante sistemas de políticas deterministas. El modelo puede recomendar acciones, pero las políticas determinan qué accesos, acciones o cambios están permitidos.
Conectar o no conectar: ¿Se limita el modelo a la observación y el análisis únicamente, a menos que un sistema de políticas externas autorice la acción?
Contención: el interruptor de apagado debe estar en su lugar antes de que comience el piloto.
Las organizaciones no deben esperar a que ocurra un incidente para decidir cómo obtener el acceso. Los equipos necesitan saber cómo deshabilitar credenciales, deshabilitar API y bloquear el acceso a la red. Se deben documentar los plazos esperados y se deben ejecutar ejercicios antes de que el modelo analice los datos confidenciales.
Si reducir el modelo requiere varios equipos, un ticket de soporte del proveedor y una reunión para acordar la propiedad, el plan de contención es inadecuado para una herramienta que opera a la velocidad de una máquina.
Los modelos de registro también deberían estar fuera de su alcance. Las indicaciones, salidas, uso de herramientas y resultados generados deben almacenarse donde el modelo no pueda acceder a ellos ni modificarlos. El registro forense debe sobrevivir al modo de falla presente en la investigación.
Conectar o no conectar: ¿Podemos revocar el acceso durante un período de tiempo y almacenar evidencia utilizando registros a los que el modelo no puede acceder?
Responsabilidad: un propietario, no un comité
Frontier Cyber AI abarca seguridad, ingeniería, legal, privacidad, adquisiciones y riesgo ejecutivo. La responsabilidad compartida es atractiva, pero a menudo se convierte en una responsabilidad ambigua.
Antes de ingresar a un programa de acceso restringido, una empresa debe asignar un propietario interno. Esa persona posee el alcance del acceso, las expectativas de monitoreo, los límites para compartir datos, los procesos de incidentes y la decisión de mantener, pausar o cortar el acceso. El comité podrá hacer recomendaciones. No deberían ser el único sistema de acción.
Conectar o no conectar: ¿Tiene una persona el poder de pausar o cancelar el acceso sin llamar al comité?
Decisiones empresariales reales
La ciberIA de frontera puede mejorar las capacidades defensivas. Pero el acceso al programa no debe confundirse con la disposición a utilizarlo.
El proceso de acceso restringido del proveedor responde a una pregunta: ¿A quién se le permite el acceso? Las pruebas de aceptación de la IA cibernética proporcionan otra respuesta: ¿a qué vamos a conectar esta capacidad y podemos controlar el resultado?
Esta es una decisión de la empresa, no del proveedor. Una lista de espera determina quién obtiene acceso. Las pruebas de aceptación determinan si Access es seguro de usar.
Hemos presentado el mejor software de cifrado.
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
