_ Víctor Del Olmo
“El criminal que se beneficie de la ausencia de seguridad no te va a dar feedback, no va a estar en el Daily Scrum, ni te va a avisar sobre qué falta para que tu producto esté completo. Va a preferir darte una sorpresa”.
Los que nos dedicamos a la Ingeniería de Software, sabemos lo poco regularizado que está el proceso para el desarrollo de software, reflejo mismo del propio sector en el que trabajamos, el cual a veces tiene más en común con una jungla que con un estándar normalizado.
Muy poco a poco, a lo largo de los años, hemos ido adquiriendo conciencia de que el tiempo invertido en controlar la calidad es una inversión y no un gasto, especialmente en el desarrollo de software. Es muy común que no exista una persona concreta que se responsabilice de asegurar la calidad del proyecto, por lo que es habitual que este sea el talón de Aquiles y fuente inagotable de problemas.
Más olvidado incluso que el control de calidad, está el control de seguridad en los productos software. En este artículo hablaremos sobre este tema, su importancia y cómo prestarle atención.
Control de seguridad y control de calidad: Nos interesa hablar de mínimos
La calidad y la seguridad de un producto tienen mucho que ver, son conceptos que miden la validez de éste y a veces se confunden. Un producto que funciona muy bien, pero permite que nos roben datos críticos de la empresa, no puede decirse que posea calidad suficiente, ni tendrá al cliente satisfecho cuando éste repare en ello.
Esta es una diferencia básica entre calidad y seguridad. Para la calidad puedes guiarte por la opinión del usuario o cliente, buscar su feedback y trabajar por su satisfacción con el producto. Sin embargo, esto no funciona de igual manera con la seguridad. La seguridad no le ofrece al cliente un beneficio directo y visible, por lo que no es habitual que las personas reparen en su importancia y reclamen sobre la misma.
Cuando pensamos en el control de seguridad de un producto, ver este aspecto como algo complejo en su medición y gestión es un error que nos llevará al olvido e inacción. Como cualquier otro aspecto del desarrollo de software, debe de verse de manera ágil y su aplicación de manera gradual.
¿Cómo empezamos?
Como en el caso de la calidad, la seguridad es una característica básica del producto, invertir tiempo y recursos en ella es muy beneficioso, sobre todo en la fase inicial de cumplimiento de unas normas mínimas. Afrontar el control de seguridad de un producto software de forma dinámica y empezando por unas normas mínimas, nos servirá para entrar en contacto con este importante aspecto.
La seguridad afecta a todo el ciclo de vida del desarrollo de software, en cada etapa de una manera diferente. Tener un responsable designado presente durante el proceso, dará al equipo de desarrollo el apoyo y el punto de vista necesario sobre la prevención y reacción ante incidentes de seguridad. Que este punto de vista seguro este presente desde etapas tempranas, nos facilitará y ahorrará mucho trabajo posterior.
El ciclo de vida y las herramientas disponibles
Ahora veremos un resumen de la forma óptima y completa de afrontar la seguridad en el desarrollo de software. Dependiendo de los recursos disponibles, estas medidas se aplicarán en mayor o menor grado, en todo caso, no aplicar ninguna de ellas es la peor respuesta posible.
Para tener visibilidad de las diferentes herramientas a usar y fases implicadas, se muestran tareas relacionadas con la seguridad que deberán llevarse a cabo, usando como división las etapas del ciclo de vida tradicional del modelo en cascada, aunque estas tareas son aplicables a cualquier otra metodología:
- Durante la definición de requisitos se especifican aquellos requisitos funcionales que se deberán cumplir en el desarrollo. En esta fase se revisa que todos los requisitos cumplen las normas y también se añaden los propios requisitos de seguridad que debe garantizar el sistema (por ejemplo: los que garantizan concretamente la protección de datos).
- Durante la fase de análisis y diseño, es importante contemplar la seguridad tanto en el análisis funcional, como en el análisis orgánico y su arquitectura propuesta. En esta fase estimaremos la envergadura del proyecto, además realizaremos la identificación, definición y priorización de riesgos. Como resultado, la seguridad debe formar parte del propio diseño del proyecto.
Múltiples normativas recogen este principio de seguridad desde el diseño y por defecto, además de una evaluación de riesgos. Por ejemplo, en lo relativo a protección de datos personales, el nuevo Reglamento General de Protección de Datos (GDPR) hace mención expresa sobre la seguridad en el artículo 25 “Data protection by design and by default”.
En la fase de desarrollo se realizarán los siguientes tipos de auditorías de código:
- Estáticas: serán las primeras en realizarse, ya que pueden realizarse en cualquier momento e irán indicando al equipo de desarrollo las normas y buenas prácticas que deberán cumplir. Realizando estas auditorías con cierta frecuencia detectaremos posibles desviaciones.
- Dinámicas: son una herramienta básica que nos arrojarán valiosos resultados, aunque para este tipo de auditoría se requerirá tener disponible una versión del sistema ejecutándose. Adicionalmente, detectaremos vulnerabilidades y podremos simular posibles ataques que comprometan la integridad, disponibilidad o confidencialidad del sistema.
Ambos tipos de auditoría son complementarias y necesarias, arrojando resultados independientes una de otra.
- La fase de pruebas continuará siendo buen momento para auditorías de código, ya que éste seguirá cambiando como mínimo con desarrollo correctivos, siendo en esta fase más fácil realizar las auditorias de tipo dinámico al disponer de entornos de ejecución del sistema en versiones cercanas a la final. Será especialmente importante validar las versiones candidatas de paso a producción.
En este punto final de la producción software, el análisis de riesgos debe estar contrastado y terminado, en cuanto a la valoración y planificación completa de estos. Es importante trasladar a la dirección del proyecto aquellos riesgos que no hubieran sido completamente eliminados, a fin de que puedan tomarse medidas ajenas al propio desarrollo, o estos riesgos se acepten.
- La fase de “mantenimiento“ requerirá de monitorización continua y definición de protocolos preventivos y reactivos ante incidentes de seguridad. Hay una clara distinción entre las fases previas en las que se produce el software y esta fase final en la que se mantiene, en la que se requieren los servicios de un centro de operaciones de seguridad que controle los riesgos.
La seguridad de la información cada vez tiene más repercusión y más importancia en la toma de decisiones, el mundo del desarrollo de software se adapta con agilidad a los nuevos requisitos del mercado y no debe dejar atrás este aspecto.
Espero que este artículo sirva como punto de partida para profundizar en esta interesante y agradecida característica del software.
Víctor del Olmo
