ISO 25000 y el software seguro

Todo el mundo que trabaja en temas de normativas y seguridad conoce, o al menos les suena, la ISO 27000. Pero esa ISO no es la única que existe en materia de seguridad.

La ISO 25000 es la normativa para medir y asegurar la calidad en productos de software, hasta hace poco podía pasar desapercibida para seguridad, dado que su modelo se basaba en seis métricas, como podemos ver en la imagen:

En ese modelo la seguridad era solo uno de los parámetros dentro de la funcionalidad propia del aplicativo.

Todo esto cambió el año pasado con la actualización de ISO 25000:2014 donde se agregaron dos métricas al modelo anterior: Compatibilidad y Seguridad. Ahora el diagrama cambia quedando de este modo:

En esta actualización la seguridad dentro de la aplicación pasa  a ser una métrica con valor propio y que ha de cumplir varias subcaracterísticas (Resumen de iso25000.org):

“Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

• Confidencialidad. Capacidad de protección contra el acceso de datos e información no autorizados, ya sea accidental o deliberadamente.
• Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no autorizados a datos o programas de ordenador.
• No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera que dichas acciones o eventos no puedan ser repudiados posteriormente.
• Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.
• Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.”

Se otorga un peso muy importante a la seguridad dentro de la calidad de software, cumplir con estas características no es trivial y las metodologías habituales de desarrollo de las empresas no lo cubren. Hace ya varios años que empezaron a surgir estudios para metodologías de inclusión de la seguridad en el desarrollo de software, esta actualización tan reciente en la ISO hará que muchas empresas comiencen a moverse buscando expertos para incluir este punto en sus desarrollos dado que muchos grandes proyectos piden que estén certificados.

No todos los proyectos necesitan el mismo grado de seguridad, no es lo mismo realizar un servicio web de gestión de historias clínicas para la seguridad social online, el cual necesitará un alto grado de seguridad para que la información de los ciudadanos este lo más segura posible. Que hacer una aplicación móvil sobre un Tetris en el cual no se guardan más datos que el Nick del jugador con más puntos del mundo.

Hay que analizar cada caso, no voy a entrar en eso ahora lo que sí quiero es dejar una reflexión y abrir los ojos a esta realidad para ver porque los S-SLDC son importantes.

Conseguir que una aplicación sea considerada como segura (ya hemos dicho en otros posts que nunca será segura) ha de cumplir con esas características

¿Pensáis que con hacerle unos tests de hacking ético ya se puede garantizar?  

¿Y con unos tests de caja blanca sobre código automatizados se puede?

¿Creéis que sin un correcto seguimiento de las correcciones, después de esos test, se puede garantizar?

No, no se puede. Hay que incluir la seguridad como un valor más del desarrollo desde la misma toma de requisitos para poder ir viendo todos los problemas, correcciones, medidas y planes de contingencia.

En próximos posts vamos a ver algunas de las opciones que existen ya, como son la solución S-SDLC de Microsoft u OpenSamm por hoy vale con dejar la reflexión ¿mis aplicaciones son suficientemente seguras?