Remediation Ballet es un pas de deux de patch y performance

Los recientes avances en inteligencia artificial (IA) han reavivado el espíritu de la remediación de vulnerabilidades totalmente automatizada. La industria está en auge con los intentos de proporcionar mitigaciones personalizadas que funcionan en su base de código y tienen en cuenta su entorno y circunstancias únicos, con la ayuda de la IA generativa. La tecnología es increíble y ya está mostrando signos de éxito. La gran pregunta sigue siendo: ¿estamos listos para aceptarlo?

Pregúntale a cualquier desarrollador que lo use copiloto de GitHub o cualquiera de las alternativas, y encontrará maravillosos ejemplos de cómo la IA puede generar sugerencias de finalización de código contextual que ahorran toneladas de tiempo. También encontrará ejemplos de sugerencias irrelevantes, demasiado complejas o completamente incorrectas generadas de forma masiva.

No hay duda de que estamos presenciando un gran avance en la tecnología que permitirá una generación de código automatizada mucho mejor que cualquier cosa que hayamos visto antes. Sin embargo, la tecnología es solo una pieza del rompecabezas de la remediación, y el proceso y las personas juegan un papel importante.

Nueva tecnología, viejos desafíos

Cada cambio en una aplicación es un acto de equilibrio entre la introducción de mejoras y la protección de la funcionalidad existente. Los cambios urgentes, incluidas las correcciones de seguridad, exacerban este problema al traer plazos ajustados y una intensa presión para hacer las cosas bien. se aplica Los parches pueden tener consecuencias inesperadasque, en el peor de los casos, puede significar el fracaso.

Pregúntele a cualquier administrador de TI que se encargue de la aplicación de parches y escuchará una lista interminable de historias de terror en las que un problema impidió que los usuarios realizaran su trabajo diario. mancha aparentemente inofensiva. Pero No se pudo aplicar el parchesolo para tener eso Vulnerabilidad explotada como parte de una brecha de seguridadtambién puede tener consecuencias devastadoras para toda la organización, como bien saben los lectores de esta columna.

Una buena ingeniería de software se centra en encontrar un equilibrio que mantenga la capacidad de realizar cambios rápidamente en la aplicación. Protección de la aplicación y sus cuidadores de los malos cambios. Hay muchos desafíos para lograr este objetivo, incluido el software obsoleto que no se puede cambiar fácilmente y los requisitos del sistema en constante cambio, por nombrar algunos.

De hecho, mantener la capacidad de cambiar el software es un objetivo difícil que no siempre se puede lograr, y los equipos deben aceptar el riesgo de que algunos cambios puedan tener consecuencias inesperadas que requieran más remediación. El mayor desafío para los ingenieros es asegurarse de que el cambio propuesto produzca los resultados esperados, no escribir el cambio de código real, que la IA generativa ahora puede hacer por nosotros. Las correcciones de seguridad no son diferentes.

Superposición de responsabilidades para la seguridad de las aplicaciones

Otro gran desafío que se agudiza en las grandes empresas es la división de responsabilidades. No se puede esperar que un equipo central de AppSec responsable de mitigar el riesgo en toda la empresa comprenda las posibles consecuencias de aplicar una solución específica a una aplicación específica. Algunas soluciones, como la aplicación de parches virtuales y los controles de red, permiten que los equipos de seguridad solucionen problemas sin tener que depender de los equipos de desarrollo, lo que podría simplificar la mitigación, reducir los recursos técnicos necesarios o evitar adquisiciones.

Dejando a un lado la política, soluciones como estas son herramientas contundentes que inevitablemente crean tensión. Los controles de red, como los firewalls y los firewalls de aplicaciones web (WAF), son un área en la que TI y la seguridad tradicionalmente han tenido mucha autonomía y los desarrolladores solo tienen que lidiar con ellos. Representan una decisión clara de poner el control sobre la productividad y aceptar la fricción adicional para los desarrolladores.

Para las vulnerabilidades de la aplicación, las correcciones requieren un cambio en el código de la aplicación o en el Solicitud Alrededores. Si bien cambiar el código de la aplicación es responsabilidad de un equipo de desarrollo, cambiar el entorno siempre ha sido una forma de intervención de los equipos de seguridad y podría proporcionar una mejor vía para aplicar las mitigaciones generadas por IA.

En el mundo local, esto generalmente significaba que los agentes de seguridad administraban las cargas de trabajo y la infraestructura. En entornos administrados, como un proveedor de nube pública o una plataforma de código bajo/sin código, los equipos de seguridad pudieron comprender e investigar completamente los cambios en el entorno, lo que permitió una intrusión más profunda en el comportamiento de la aplicación.

Por ejemplo, la configuración puede cambiar el comportamiento de una aplicación sin cambiar su código, lo que proporciona una mitigación de la seguridad y limita las consecuencias. Un buen ejemplo de esto es habilitar el cifrado integrado en reposo para las bases de datos. Prevención de acceso a datos públicoso enmascarar datos confidenciales procesados ​​​​por una aplicación de código bajo.

Encuentra el equilibrio adecuado

Es importante tener en cuenta que los cambios ambientales pueden tener efectos negativos en la aplicación. El cifrado viene con un impacto en el rendimiento y el enmascaramiento dificulta la depuración. Sin embargo, estos son riesgos que cada vez más empresas están dispuestas a asumir para mejorar las defensas de seguridad a menores costos de ingeniería.

En última instancia, incluso si se dispone de una medida correctiva, las organizaciones deben equilibrar el riesgo de infracciones de seguridad con el riesgo de aplicar medidas correctivas. Está claro que las medidas correctivas generadas por IA reducen los costos de remediación, pero el riesgo de su aplicación siempre existirá. Sin embargo, si no tomamos medidas correctivas por miedo a las consecuencias, nos encontramos en un extremo del espectro entre estos dos riesgos, lejos de un equilibrio perfecto. En el otro extremo del espectro estaría la aplicación automática de una acción correctiva generada automáticamente.

En lugar de elegir uno de los dos extremos, debemos reconocer tanto los riesgos de vulnerabilidad como los riesgos de mitigación y encontrar un equilibrio entre los dos. Las acciones correctivas a veces hacen que las aplicaciones se rompan. Pero elegir no aceptar ese riesgo significa, por defecto, elegir aceptar el riesgo de una brecha de seguridad debido a la falta de contramedidas.