Los equipos de seguridad que evalúan Sysdig AI Defense deberían comprobar si las llamadas a herramientas que constan en los registros del agente se corresponden con los procesos que las ejecutan realmente. Sysdig anunció la disponibilidad general el 4 de noviembre. La pregunta de evaluación útil es concreta: cuando una herramienta inicia procesos adicionales, ¿puede el equipo identificar la acción, la identidad responsable y la respuesta del control a partir de evidencia recopilada fuera del propio resumen del agente?
Qué anunció Sysdig
El comunicado de Sysdig describe supervisión tanto del entorno de ejecución del agente como del sistema operativo, con políticas que al principio solo generan alertas y que después pueden configurarse para impedir las acciones no permitidas. Especifica disponibilidad general para macOS y Windows. La explicación del lanzamiento describe la relación entre las acciones que declara el agente y la actividad observada. SecurityWeek cubre por separado el lanzamiento.
Se trata de afirmaciones del proveedor sobre capacidades y de cobertura del lanzamiento, no de una prueba independiente de cobertura o prevención completas. Maetra no ha probado el producto. La evaluación que sigue es un análisis de Maetra dirigido a responsables de seguridad en tiempo de ejecución que estén evaluando su propio entorno. No presupone que cada host, subproceso o servicio gestionado sea observable.
Defina un límite de observación antes de la prueba
Elija un flujo de trabajo de agente que no sea de producción y una tarea inocua con un resultado conocido. Por ejemplo, pida al agente que genere un informe pequeño a partir de archivos de prueba mediante un comando que inicie un proceso auxiliar. Mantenga fuera del ejercicio las credenciales reales y la información de clientes. Anote el host, la versión del agente, el entorno de ejecución del agente, la identidad, la herramienta y la salida esperada antes de empezar.
La prueba debe responder si pueden relacionarse dos registros diferentes. Un registro describe la llamada a una herramienta solicitada. Otro registra la actividad del host que siguió. Una explicación legible del agente puede ayudar a un investigador a entender la intención, pero no puede establecer qué procesos se ejecutaron ni qué archivos tocaron.
Pida al evaluador del producto que indique exactamente dónde opera la recopilación. Un comando local, un proceso dentro de un contenedor y un trabajo delegado a un servicio alojado pueden requerir rutas de observación distintas. Si la prueba incluye solo el portátil, su conclusión debería cubrir únicamente ese límite probado. Ampliar la conclusión a una cuenta en la nube requeriría evidencia adicional.
Reconciliar los registros en lugar de contarlos
Una llamada a una herramienta y un proceso son unidades diferentes. Varios procesos pueden ser consecuencias normales de un comando autorizado. Un desajuste numérico por sí solo no demuestra comportamiento malicioso, ausencia de cobertura de seguridad ni desviación de la tarea.
Para la sesión de prueba, conserve las siguientes referencias:
- La tarea solicitada y el registro de llamada a una herramienta del agente.
- Las relaciones de procesos observadas en el host y las marcas de tiempo pertinentes.
- La identidad y los permisos utilizados para la operación.
- Los archivos o destinos implicados, utilizando valores de prueba seguros.
- La configuración de la política y su modo de respuesta activo.
- El artefacto resultante y cualquier laguna en la recopilación de datos.
Siga una cadena de procesos desde la solicitud original, pasando por el auxiliar, hasta la salida. Luego pida a alguien que no haya ejecutado el ejercicio que explique la secuencia a partir de esos registros. Si no puede conectar un proceso hijo con la tarea que lo originó, documente el enlace que falta. Evite cubrir la brecha con la propia afirmación del agente de que todo se completó correctamente.
Un auxiliar benigno y conocido proporciona una línea base útil. Repita el ejercicio con un destino o archivo de prueba deliberadamente no permitido, dentro del entorno de prueba autorizado, para examinar cómo responde la política. La prueba debería diseñarse de modo que una autorización inesperada tenga un efecto contenido e inocuo.
Separe las alertas de la aplicación
Una alerta puede ser precisa y aun así la acción completarse. Antes de ejecutar una prueba de bloqueo, confirme que la política seleccionada está configurada para aplicar la respuesta prevista. Registre ese modo junto con el resultado. Un panel que muestra una detección no demuestra por sí mismo que se haya impedido la escritura, la carga o el inicio del proceso.
Para una prueba inocua de escritura bloqueada, inspeccione el destino después. Conserve tanto el evento de seguridad como el resultado en el destino. Si el producto detiene un proceso después de que se inicia, identifique qué puede establecer la prueba sobre los efectos ocurridos antes de la terminación. Evite describir la terminación del proceso como prueba de que no pudo haberse movido ningún dato.
Examine también la ruta de excepción. Registre quién puede aprobar una excepción, la acción que cubre y cuánto dura. Una evaluación se vuelve menos informativa si una excepción amplia cambia silenciosamente las condiciones entre los casos permitidos y denegados. Restaure la configuración de prueba y conserve el registro del cambio cuando termine el ejercicio.
Utilice el resultado para mejorar una vía de investigación
El resultado de la evaluación debería ser un informe breve de lo que se observó, lo que hizo la política y qué límites siguen sin probarse. Indique los fallos de recopilación junto con las correlaciones exitosas. Esto ofrece al responsable de seguridad algo útil para la preparación ante incidentes sin convertir una demostración del producto en una afirmación general de garantía.
Esto difiere de investigar extensiones maliciosas del agente: la tarea inmediata es relacionar una solicitud de herramienta ordinaria con su ejecución en el host y comprobar el modo de respuesta. La guía de Maetra sobre evidencia para auditoría de IA ofrece una planificación de evidencia relacionada.
Maetra Secure analiza prompts, mensajes, llamadas a herramientas y salidas en busca de amenazas en tiempo de ejecución. Audit ofrece un historial de eventos inspeccionable. Estas capacidades no implican recopilación de procesos a nivel de kernel ni una integración nativa con Sysdig. Utilice la documentación de Maetra para definir la evidencia a nivel de aplicación que necesita junto con sus herramientas de seguridad del host.