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?
