En este momento estás viendo El código generado por IA refuerza la necesidad de la seguridad previa a la ejecución a trabajar a toda marcha para aplicar parches en PHP
Revisar código desconocido antes de su ejecución puede ayudar a los equipos de seguridad a hacer cumplir las políticas y reducir las investigaciones evitables.

El código generado por IA refuerza la necesidad de la seguridad previa a la ejecución a trabajar a toda marcha para aplicar parches en PHP

  • Autor de la entrada:
  • Categoría de la entrada:Análisis
  • Última modificación de la entrada:

Un programa desconocido se ejecuta en la estación de trabajo de un desarrollador, accede a credenciales almacenadas y se conecta a un servidor externo. Su comportamiento activa una alerta de un sistema de detección y respuesta en el terminal (EDR, por sus siglas en inglés), lo que obliga al analista a responder a dos preguntas: ¿es el código malicioso y qué acciones ha realizado ya?.

La IA generativa puede complicar esta evaluación, ya que ayuda tanto a los atacantes como a los desarrolladores a crear código desconocido. Los atacantes pueden utilizarla para redactar y revisar código malicioso, mientras que los desarrolladores la emplean para generar scripts y aplicaciones legítimos. Los equipos de seguridad deben evaluar el código desconocido proveniente de ambas fuentes, sin asumir que el hecho de que sea nuevo implica necesariamente que sea peligroso.

Cuando dicho código se ejecuta teniendo acceso a credenciales o a sistemas de despliegue, esperar a que se observe un comportamiento sospechoso puede llevar a que los equipos tengan que investigar una exposición cuando esta ya ha ocurrido. El desafío reside en determinar qué elementos deben revisarse y restringirse antes de la ejecución, y qué aspectos requieren, por el contrario, una supervisión durante el tiempo de ejecución y el criterio de un analista.

El código desconocido aumenta la carga de trabajo de los analistas.

El volumen de alertas suele plantearse como un problema de dotación de personal; sin embargo, también es un problema de toma de decisiones. Los casos que requieren una revisión manual consumen el tiempo de los analistas, quienes deben decidir si contener la actividad, permitir que continúe o escalar la investigación.

Alguien debe determinar qué ha sucedido, qué es capaz de hacer el artefacto en cuestión y si está justificado aplicar medidas de contención. Un archivo sospechoso en una máquina de pruebas aislada genera un determinado nivel de urgencia; no obstante, ese mismo archivo ejecutándose en un entorno de compilación —con acceso a claves de firma, credenciales en la nube o permisos de despliegue— exige una investigación mucho más exhaustiva.

La IA puede ayudar a los atacantes a generar variantes de código malicioso, lo que complica las comprobaciones que dependen de archivos o firmas identificados previamente. Sin embargo, un nuevo hash de archivo no implica necesariamente una nueva técnica de ataque. La detección basada en el comportamiento sigue siendo fundamental, ya que distintos archivos pueden llevar a cabo las mismas acciones maliciosas.

La carga de trabajo depende de la frecuencia con la que el código desconocido genera alertas que los controles automatizados no pueden resolver.

Las puntuaciones de riesgo requieren reglas de aplicación.

La asignación de puntuaciones probabilísticas resulta útil, dado que los entornos reales son complejos y desordenados. Las señales suelen ser incompletas, el comportamiento varía según el contexto y los atacantes generan ambigüedad de forma deliberada. Una puntuación ayuda a priorizar qué elementos requieren atención inmediata.

Una puntuación de riesgo resulta una base insuficiente para la aplicación de medidas si la organización no ha definido qué acciones debe desencadenar dicha puntuación. Las políticas deben especificar cuándo bloquear una actividad, restringir permisos o exigir una revisión, teniendo en cuenta el sistema afectado y los niveles de acceso de los que dispone el código.

Las organizaciones deben ser capaces de explicar qué regla, evidencia y contexto ambiental condujeron a una decisión de permitir o bloquear una acción. Casos similares deben recibir un tratamiento equivalente, mientras que las excepciones documentadas deben justificar las diferencias legítimas en el nivel de riesgo.

Tras la ejecución, la investigación se amplía.

Una vez que se ejecuta un código sospechoso, es necesario llevar a cabo una investigación para determinar qué es dicho código y qué acciones ha realizado. Los analistas deben verificar si el código accedió a credenciales, estableció mecanismos para mantener su persistencia, se comunicó con sistemas controlados por atacantes o afectó a otros equipos. Incluso cuando no se detecta una vulneración, este proceso consume una cantidad considerable de tiempo.

Los flujos de trabajo de desarrollo pueden ampliar la exposición a riesgos. El script de instalación de un paquete puede ejecutarse con los permisos de la cuenta que realiza la instalación. Asimismo, los scripts generados por inteligencia artificial pueden ejecutarse bajo cuentas de servicio con privilegios, lo que otorga a código no revisado acceso a credenciales o sistemas de despliegue.

La detección y la contención pueden limitar un ataque; sin embargo, es posible que los analistas deban determinar qué ocurrió antes de que se aplicara la contención. Los controles preventivos pueden complementar estas capacidades al identificar infracciones de políticas antes de que el código llegue a sistemas sensibles.

Verificar el código y limitar el acceso antes de la ejecución.

Comience por analizar los flujos de trabajo que introducen o ejecutan código desconocido, tales como descargas, agentes de programación basados ​​en IA, instalaciones de paquetes y procesos de integración y entrega continuas (CI/CD). Revise qué cuentas ejecutan dicho código y si sus permisos exceden lo necesario para la tarea en cuestión.

Antes de que un código desconocido se ejecute en un entorno de producción o con privilegios, las organizaciones pueden verificar su origen, revisar su contenido y, cuando proceda, probarlo en un entorno aislado. Los controles de aplicaciones pueden restringir qué elementos tienen permitido ejecutarse, mientras que la limitación de permisos puede restringir el acceso del código aprobado. Si bien estas medidas permiten identificar o mitigar ciertos riesgos, no pueden determinar todas las acciones que el código podría realizar durante su ejecución.

La supervisión en tiempo de ejecución sigue siendo necesaria, ya que algunos comportamientos maliciosos solo se manifiestan durante la ejecución. Los controles preventivos y las restricciones de ejecución pueden complementar las soluciones EDR (detección y respuesta en terminales), bloqueando infracciones de políticas identificables y proporcionando a los analistas un mayor contexto. Los equipos deben evaluar si estos controles logran reducir el tiempo de investigación sin generar un exceso de bloqueos erróneos ni obstaculizar las tareas legítimas.