No hay software sin errores, ¿verdad? Si bien este es un sentimiento común, hacemos suposiciones que se basan en la premisa de que el software no tiene errores en nuestra vida digital cotidiana. Confiamos en los proveedores de identidad (IDP) para obtener la autenticación correcta, los sistemas operativos para cumplir perfectamente con sus especificaciones y las transacciones financieras para realizar siempre según lo previsto. Aún más vívidamente, confiamos en el software con nuestra seguridad física al ir en aviones, conducir un automóvil que corrige activamente nuestra adherencia a los carriles de tráfico o nuestra distancia del automóvil que tenemos delante, o someternos a ciertas cirugías. ¿Qué hace esto posible? O dicho de otro modo, ¿por qué los aviones no caen del cielo debido a un mal software?

El aseguramiento de la calidad del software se basa en herramientas científicas y de ingeniería. Una forma de asegurar y mejorar la calidad del software es publicitarlo y dar un incentivo a tantas personas como sea posible para intentar romperlo.

Otro es el uso de patrones de diseño o marcos de arquitectura de pozos arraigados en la ingeniería. Por ejemplo, aunque no todos los proyectos de software pueden someterse al mismo nivel de escrutinio que el kernel de Linux, que ha estado bajo escrutinio durante décadas, los proyectos de software pueden abrir el código fuente para invitar al escrutinio o enviar el código para auditorías con la esperanza de obtener algo de las garantías de seguridad.

Y por supuesto, hay pruebas. Ya sea estática, dinámica o en tiempo real, realizada por el desarrollador o por un equipo dedicado, la prueba es una parte importante del desarrollo de software. Con el software crítico, las pruebas suelen ser un proyecto completamente separado manejado por un equipo separado con experiencia específica.

Las pruebas son buenas, pero no pretenden ser exhaustivas. No hay garantías de que hayamos encontrado todos los errores porque no sabemos qué errores desconocemos. ¿Ya encontramos el 99% de los errores del kernel de Linux? 50%? 10%?

La afirmación 'absoluta'

El campo de investigación de los métodos formales está buscando formas de asegurarle que no hay errores en una determinada pieza de software, como su corredor de bolsa o autoridad certificadora. La idea básica es traducir el software a las matemáticas, donde todo está bien definido, y luego crear una prueba real de que el software funciona sin errores. De esa manera, puede estar seguro de que su software está libre de errores de la misma manera que puede estar seguro de que cada número se puede descomponer en una multiplicación de números primos. (Tenga en cuenta que no defino qué es un error. Esto demostrará ser un problema, como veremos más adelante).

Las técnicas de métodos formales se han utilizado durante mucho tiempo para el software crítico, pero requerían mucho esfuerzo y cómputo y, por lo tanto, se aplicaban solo a pequeñas piezas de software, como una parte limitada del firmware del chip o un protocolo de autenticación. En los últimos años, probadores de teoremas avanzados como Z3 y gallo han hecho posible aplicar esta tecnología en un contexto más amplio. Ahora están formalmente verificados lenguajes de programación, sistemas operativosy compiladores que están 100% garantizados para funcionar de acuerdo con sus especificaciones. La aplicación de estas tecnologías aún requiere experiencia avanzada y una tonelada de poder de cómputo, lo que las hace prohibitivamente costosas para la mayoría de las organizaciones.

Los principales proveedores de la nube están realizando una verificación formal de sus pilas fundamentales para alcanzar altos niveles de garantía de seguridad. Amazon y Microsoft tienen grupos de investigación dedicados que trabajan con equipos de ingeniería para incorporar métodos de verificación formal en infraestructura crítica, como almacenamiento o redes. Ejemplos incluyen AWS S3 y EBS y cadena de bloques azul. Pero el hecho realmente interesante es que en los últimos años, los proveedores de nube han sido intentando mercantilizar verificación formal para vender a sus clientes.

¿Resolviendo decisivamente la mala configuración?

El año pasado, AWS lanzó dos funciones que aprovechan la verificación formal para abordar los problemas que han afectado a sus clientes durante mucho tiempo, a saber, la red y Configuración incorrecta de la gestión de identidades y accesos (IAM)s. El acceso a la red y las configuraciones de IAM son complejas, incluso para una sola cuenta, y esa complejidad crece drásticamente en una organización grande con toma de decisiones y gobierno distribuidos. AWS lo aborda brindando a sus clientes controles simples, como "los cubos S3 no deben estar expuestos a Internet" o "el tráfico de Internet a las instancias EC2 debe pasar por un firewall", y garantiza aplicarlos en todos los escenarios de configuración posibles.

AWS no es el primero en abordar el problema de configuración incorrecta, incluso para problemas específicos de AWS, como cubos S3 abiertos. Los proveedores de gestión de la postura de seguridad en la nube (CSPM) han estado abordando este problema desde hace un tiempo, analizando la configuración del canal de puerto virtual (VPC) y los roles de IAM e identificando casos en los que los privilegios son demasiado laxos, las funciones de seguridad no se usan correctamente y los datos pueden estar expuestos. a la Internet. ¿Qué hay de nuevo?

Bueno, aquí es donde entra la garantía absoluta. solución CSPM funciona mediante la creación de una lista de configuraciones incorrectas conocidas como malas o buenas, a veces agregando contexto de su entorno y produciendo resultados en consecuencia. Los analizadores de red e IAM funcionan examinando cada posible IAM o solicitud de red y garantizando que no darán como resultado un acceso no deseado de acuerdo con sus especificaciones (como "sin acceso a Internet"). La diferencia está en las garantías sobre los falsos negativos.

Si bien AWS afirma que no hay forma de que se haya perdido nada, los proveedores de CSPM dicen que siempre están buscando nuevas configuraciones incorrectas para catalogar y detectar, lo que es una admisión de que no detectaron estas configuraciones incorrectas anteriormente.

Algunas fallas de la verificación formal

La verificación formal es excelente para encontrar problemas bien definidos, como problemas de seguridad de la memoria. Sin embargo, las cosas se vuelven difíciles cuando se trata de encontrar errores lógicos porque requieren especificar qué se supone que debe hacer el código, que es exactamente lo que hace el código en sí.

Por un lado, la verificación formal requiere especificar objetivos bien definidos. Si bien algunos objetivos, como impedir el acceso a Internet, parecen bastante simples, en realidad no lo son. La documentación del analizador AWS IAM tiene una sección entera define lo que significa "público", y está lleno de advertencias. Las garantías que proporciona son tan buenas como las afirmaciones matemáticas que ha codificado.

También está la cuestión de la cobertura. Los analizadores de AWS cubren solo algunos de los principales servicios de AWS. Si enruta el tráfico a su red a través de un canal de conexión saliente, el analizador no lo sabrá. Si algún servicio tiene acceso a dos roles de IAM y puede combinarlos para leer de un depósito público confidencial y escribir en uno público, el analizador no lo sabrá. Sin embargo, en algún subconjunto bien definido del problema de configuración incorrecta, la verificación formal proporciona garantías más sólidas que nunca.

Volviendo a la pregunta de la ventaja relativa planteada anteriormente, la diferencia es que el IAM y el analizador de red afirman que su lista de problemas detectados es completa, mientras que CSPM afirma que su lista cubre todas las configuraciones erróneas conocidas en la actualidad. Aquí está la pregunta clave: ¿Debería importarte?

¿Debemos preocuparnos por las garantías absolutas?

Considere el siguiente escenario. Tiene un CSPM y observa la red de AWS y el analizador de IAM. Al comparar los resultados de los dos, se da cuenta de que han identificado exactamente los mismos problemas. Después de un poco de esfuerzo, soluciona todos los problemas de esa lista. Confiando solo en su CSPM, sentiría que está en un buen lugar ahora y podría dedicar recursos de seguridad a otra parte. Al agregar analizadores de AWS a la combinación, ahora sabe, con la garantía de AWS, que se encuentra en un buen lugar. ¿Son estos los mismos resultados?

Incluso si descuidamos la advertencia de la verificación formal y asumimos que detecta el 100 % de los problemas, medir los beneficios sobre los servicios basados ​​en la detección como CSPM sería un ejercicio para cada organización individual con su propio apetito por los riesgos de seguridad. Algunos encontrarían estas garantías absolutas innovadoras, mientras que otros probablemente se apegarían a los controles existentes.

Estas preguntas no son exclusivas de CSPM. Se podrían hacer las mismas comparaciones para las herramientas de prueba de seguridad de aplicaciones web SAST/DAST/IAST y el software formalmente verificado, por nombrar un ejemplo.

Independientemente de las opciones de la organización individual, un efecto secundario emocionante de esta nueva tecnología sería una forma independiente de comenzar a medir las tasas de falsos negativos de las soluciones de seguridad, empujando a los proveedores a ser mejores y brindándoles evidencia clara donde necesitan mejorar. Esto en sí mismo es una gran contribución a la industria de la ciberseguridad.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.darkreading.com/edge-articles/are-100-security-guarantees-possible-