Información sobre pruebas de software a partir del incidente de CrowdStrike

La catástrofe de CrowdStrike pasará a la historia como un ejemplo de cómo un enfoque insuficiente en la calidad y las pruebas de software daña la imagen de un proveedor y la multitud de usuarios. Cualesquiera que sean las causas fundamentales, es justo darle tiempo a CrowdStrike para analizar sus problemas y compartir los resultados. Sin embargo, tomemos esta situación para ofrecer algunas observaciones generales sobre la calidad del software.

El equilibrio entre el riesgo empresarial y el coste de la calidad del software

Dada la frecuencia de las actualizaciones que CrowdStrike lanza en su difícil negocio de seguridad, es obvio que la automatización de su proceso de desarrollo es excelente. Los flujos de trabajo basados ​​en CI/CD altamente automatizados son absolutamente esenciales en el desarrollo de software moderno. La integración y entrega continuas mejoran la eficiencia de los equipos de software y permiten el desarrollo de software a escala.

Cuando tenga todo el proceso automatizado e instrumentado, podrá ver números y estadísticas y comprender mejor los costos. Cuando puedes medir, te sientes tentado a optimizar. Especialmente en una industria que enfrenta una presión constante para ser eficiente, ágil y de respuesta rápida. Equilibrar el riesgo empresarial y el coste de la calidad del software es un problema bien conocido en la industria.

Los procesos de prueba y calidad son objetivos simples de optimización. La optimización a menudo significa reducir las pruebas. No queremos decir que esto sea lo que ocurrió en el caso CrowdStrike, pero este espíritu es visible entre las organizaciones de software. Implementar múltiples técnicas de prueba requiere tiempo y esfuerzo. También hay un costo de mantenimiento.

Tiempo y costo de las pruebas

Incluso si miramos un sistema moderadamente complejo que consta de un frontend y un backend con microservicios y todo implementado usando C++, Java y tal vez Python, es probable que un proceso de calidad sólido deba incluir:

• Análisis estático para todos los lenguajes de programación.
• Prueba unitaria
• Pruebas de API
• Virtualización de servicios
• Pruebas de carga y rendimiento.

También, cobertura de código deben recopilarse de todos los tipos de pruebas de tiempo de ejecución. Es un esfuerzo considerable de implementar y mantener.

Incluso si se implementan con éxito, las técnicas de prueba que tienen un mantenimiento más costoso tienden a decaer con el tiempo y se abandonan. Los equipos verifican periódicamente las estadísticas con errores detectados por cualquier práctica de prueba determinada y preguntan: ¿Vale la pena nuestro esfuerzo?

Con el tiempo, los equipos tienden a centrarse en uno o dos tipos de pruebas que son fáciles de automatizar y mantener. Las marcas verdes junto a las solicitudes de extracción generan una confianza falsa con el tiempo y eliminan la idea de si el riesgo está lo suficientemente mitigado.

No hay nada innovador en la conclusión anterior. Siempre fue así. Sin embargo, según nuestras observaciones, paradójicamente, a medida que aumentan los niveles de automatización, la tolerancia de los equipos a los gastos y retrasos relacionados con las pruebas disminuye.

Un enfoque integral y de giro a la izquierda para las pruebas

La verdad sobre las pruebas de software es que no existe una solución milagrosa. No se puede probar la calidad del software. Más bien, requiere un enfoque holístico para todo el SDLC que incluya:

1. Crear software de calidad desde el principio con un enfoque de prueba de desplazamiento a la izquierda.
2. Cultivar una estrategia de prueba sólida y rica para aumentar la confianza del código.

Existen muchas técnicas de prueba, cada una de las cuales es buena para detectar una clase específica de problemas. La alta calidad y confiabilidad del software requieren combinando varias metodologías de prueba. La llamada optimización de todo el proceso de prueba para incluir solo una o dos metodologías es un camino ciego.

La tentación de reducir las pruebas es aún más fuerte cuando no existe un mandato para ciertas prácticas. Para los sistemas críticos para la seguridad, existen estándares específicos que exigen análisis de riesgos y recomiendan emplear una colección de técnicas de prueba de software. Si se quiere introducir un producto en el mercado, se debe demostrar que cumple con la norma.

Los estándares de seguridad funcional generalmente clasifican las funcionalidades según su nivel de criticidad y brindan varios niveles de recomendaciones para técnicas de prueba específicas. A continuación, puede ver un ejemplo de ISO 26262, un estándar popular en automoción.

Los detalles de esta tabla no son importantes para nuestra discusión. La conclusión relevante es que las normas de seguridad distinguen diferentes niveles de criticidad para los sistemas (AD) y vienen con varias recomendaciones sobre cómo probar los sistemas. Cuando desee omitir una práctica de prueba específica que el estándar considera apropiada para un nivel de riesgo determinado, necesita una historia realmente sólida para su evaluador.

El proceso de seguridad incluye análisis de peligros y evaluación de riesgos. Esta es una base para definir objetivos de seguridad, implementar características y pruebas adecuadas de acuerdo con un nivel de riesgo definido. Sin entrar en la jerga específica de la industria, se trata de definir escenarios críticos y asegurarse de prevenirlos o probarlos lo suficiente.

Conclusión

En el caso de Falcon, parecería que cualquier escenario que impida que el ordenador arranque es crítico. Debería haber algunas medidas de seguridad contra esto. Como mínimo, deberían realizarse pruebas exhaustivas para detectarlo. Y esas pruebas deberían tener prioridad.

Desarrollar software crítico para la seguridad es tremendamente caro. No, no sugerimos que todos los productos se desarrollen con las mismas limitaciones que en el mundo crítico para la seguridad. Esto sería poco práctico y difícil de justificar desde el punto de vista empresarial.

Sin embargo, es interesante observar cómo sistemas aparentemente no críticos, como el Falcon de CrowdStrike, afectan nuestras vidas. La interrupción de las operaciones de la línea 911 ciertamente pone en riesgo la salud y tal vez incluso la vida de varias personas desafortunadas.

Entonces, ¿cuáles son las lecciones para los equipos de desarrollo?

• Sea consciente y resista la dinámica que los empuja constantemente a tomar atajos y comprometer la calidad en favor de ganancias comerciales a corto plazo.
• Comprender el verdadero nivel de criticidad de los sistemas que construyen, incluido el riesgo comercial para la organización.
• Obtener una mejor comprensión de las mejores prácticas y procesos implementados por sectores verticales de la industria donde los productos afectan directamente a las vidas humanas puede ser un ejercicio útil y una fuente de inspiración valiosa.

Mediante el aprovechamiento Soluciones Parasoft C y C++ para análisis estático, pruebas unitarias, integración continua y monitoreo, CrowdStrike podría haber detectado y resuelto sus problemas de actualización de software en tiempo real, manteniendo la integridad de sus versiones de software.

Nuestro equipo de expertos cree que las pruebas de software son una disciplina de ingeniería y que prevenir catástrofes originadas en el software requiere tiempo y esfuerzo. Nuestras soluciones ayudan a los equipos a minimizar costos y recuperar el control sobre el riesgo comercial. Cualquier tipo de negocio con mucho en juego puede beneficiarse de nuestra experiencia en analizadores de código estático, cobertura de código, marcos de pruebas unitarias, pruebas de API, virtualización de servicios y más.