Puntos Clave
Incorpore criterios de seguridad desde el diseño en las evaluaciones de riesgos de proveedores. Exija informes SOC 2 Tipo 2 y respuestas sobre la frecuencia de las pruebas de penetración, los tipos de pruebas y el análisis de código estático y dinámico. Exija a los proveedores que demuestren prácticas de codificación modernas, como organizar el desarrollo en pods centrados en la seguridad con arquitectos de seguridad dedicados para detectar debilidades de forma temprana. Exija objetivos transparentes de seguridad desde el diseño e informes periódicos de métricas para realizar un seguimiento del progreso en todos los módulos de software y responsabilizar a los proveedores.Republicado con permiso de CIO.com
No es ningún secreto que las ciberamenazas van en aumento. El coste de la ciberdelincuencia notificada en EE. UU. aumentó un 22 % durante 2023, hasta superar los 12.500 millones de dólares, según el Internet Crime Complaint Center del FBI. Uno de los problemas son las debilidades que los enfoques tradicionales de codificación y seguridad han perpetuado en el software. Para combatir estos riesgos, ahora existe un esfuerzo coordinado por crear software que sea seguro desde el diseño. Por ejemplo, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) ha definido un conjunto de medidas que los proveedores pueden adoptar para demostrar que están aplicando principios de seguridad desde el diseño.
Sin embargo, sin estándares y métricas exigibles, a los responsables de TI y seguridad les resulta difícil evaluar si los proveedores están aplicando este enfoque seguro desde el diseño y cómo lo hacen. Estas son algunas medidas que pueden adoptar.
Incorporar prácticas de seguridad desde el diseño en las evaluaciones de riesgos de seguridad
La evaluación de riesgos de proveedores es un proceso estándar mediante el cual las empresas identifican y evalúan los posibles peligros asociados a los productos y operaciones de un proveedor. Los responsables de TI y seguridad pueden utilizar este proceso para centrarse en los principios y las prácticas de seguridad desde el diseño, afirma Michael Riemer, Field Chief Information Security Officer de Ivanti.
«Para nosotros, como proveedor de software, significa asumir plena responsabilidad sobre nuestros propios productos», afirma Riemer. «Hay que examinar toda la arquitectura de la solución y tener en cuenta la seguridad en todos los ámbitos, como el diseño de la arquitectura, el almacenamiento, la conectividad, el uso, etc.»
Como parte de la evaluación de riesgos de seguridad, las empresas también deberían considerar exigir un informe SOC 2 Tipo 2. Este tipo de evaluación ofrece más garantías sobre cómo protege un proveedor los datos y la información de los clientes. Implica una auditoría de ciberseguridad realizada por un tercero que evalúa cómo funcionan los controles y las prácticas de seguridad internos del proveedor durante un periodo prolongado.
Estas son algunas preguntas clave que todo proveedor debería poder responder:
- ¿Con qué frecuencia realizan pruebas de penetración?
- ¿Qué tipos de pruebas de penetración se realizan?
- ¿Realizan análisis de código tanto estático como dinámico?
Evaluar las prácticas de codificación
Las prácticas de codificación tradicionales son secuenciales: un equipo trabaja en un módulo, luego lo pasa al siguiente equipo, y así sucesivamente. Pero esto mantiene las debilidades que se introducen en la base de código, señala Riemer. Al reestructurar los equipos en «pods» o grupos, cada uno con un arquitecto de seguridad dedicado, las debilidades pueden eliminarse desde el principio. Este fue un cambio importante para Ivanti, afirma Riemer. Los proveedores deberían poder demostrar estos cambios organizativos y las nuevas prácticas.
Evaluar la transparencia de la seguridad desde el diseño
Los proveedores deben poder hacer públicos sus objetivos de seguridad desde el diseño, y demostrar que informan o informarán sobre las métricas de forma periódica. Los clientes también deben poder realizar un seguimiento del progreso del proveedor en todos sus módulos de software.
«Hemos creado objetivos específicos y establecido una línea de referencia y métricas», afirma Riemer. «Nos estamos responsabilizando de nuestro avance en seguridad desde el diseño. Estas métricas mostrarán qué módulos de software hemos analizado y hasta qué punto han profundizado los análisis para identificar y corregir prácticas de codificación débiles.»
Conclusión
Los responsables de negocio y de TI pueden utilizar los principios de seguridad desde el diseño para evaluar los avances logrados por sus proveedores de software en la creación de código que sea intrínsecamente más seguro. La seguridad desde el diseño permite a estos responsables minimizar los riesgos empresariales.