El largo camino hacia la seguridad el ciclo de vida del desarrollo (I)

Durante los últimos años se ha puesto de manifiesto la necesidad de disponer de una serie de estrategias, procesos y actividades que, acompañando a las tradicionales fases de desarrollo de aplicaciones, aporten un resultado de seguridad global en las aplicaciones. La tarea, vista en su más amplio aspecto, no es fácil. A la complejidad de conseguir que una aplicación funcione para el propósito que se ha concebido se unen las corrientes metodológicas que están surgiendo desde hace unos años y que han revolucionado el mundo del desarrollo.

Para conseguir que el desarrollo de aplicaciones en una organización sea seguro es necesario establecer una serie de estrategias, procesos y actividades en cada fase del desarrollo y conseguir que los desarrollos pasen por los procesos que proporcionan seguridad al software. Esto hoy no es posible lograrlo sin un director de orquesta puesto que las prioridades de los equipos de desarrollo no siempre están alineados con la seguridad y por eso es necesario gobernarla desde el comienzo.

Los diversos enfoques para la seguridad en el ciclo de vida tratan de simplificar el concepto pero claro, los diferentes casos que afectan a cada organización no empatizan con esta intención de simplificar. En un momento de cambio en el que las metodologías ágiles y las filosofías DevOps ya provocan conmociones en los procesos de desarrollo de aplicaciones en las organizaciones (esto debería haberlo escrito en verso), la complejidad añadida de gobernar la seguridad en el desarrollo agrega un nivel de dificultad en coordinar los esfuerzos para conseguir un producto de calidad y seguro, y que el proceso sea eficiente en coste y esfuerzos.

Estar de acuerdo en apreciar el panorama como una revolución compleja que provoca crisis en el desarrollo no es inconveniente para opinar que el momento presenta la oportunidad perfecta para integrar la seguridad en el desarrollo. Terminar esta revolución e iniciar la revolución de la seguridad no sería razonable y aunque a corto plazo la tarea sea ardua, el resultado se presenta muy tentador: seguridad, calidad y eficiencia. ¿Quién no quiere eso para sus desarrollos?

Los cimientos en el gobierno de la seguridad de las aplicaciones los pone SAMM (Software Assurance Maturity Model), un modelo de madurez recientemente incorporado al proyecto OWASP. El modelo propone cuatro funciones de negocio: Gobierno, construcción, verificación y despliegue, y establece varios procesos de la seguridad dentro de los que se ubican las actividades clave. La adopción de SAMM permite conocer el estado de madurez desde una perspectiva amplia, pero no deja de ser un modelo para entender a alto nivel el grado de madurez de la seguridad de los procesos involucrados en el ciclo de vida del software y obviamente es preciso ir más al detalle y proponer prácticas más concretas para lograr un buen nivel de seguridad.

La lectura de SAMM nos proporcionará una manera de enfocar la seguridad desde un punto de vista amplio y será el momento de concretar las prácticas de seguridad en el desarrollo mediante un enfoque holístico basado en personas herramientas y procesos.

El primer paso será conocer y comprender las bases de la seguridad de la información, siempre girando en torno a los tres conocidos aspectos de Confidencialidad, Integridad y Disponibilidad o, dicho de otro modo, en qué medida nos afectaría el acceso de personas no autorizadas a la información, en qué medida nos afectaría el deterioro o pérdida de la información y en qué medida nos afectaría la pérdida de acceso a la información. Estas tres preguntas ayudan a poner el foco y priorizar. A continuación, definir las “Tres A”, es decir “Autenticación” o el proceso para determinar la identidad de un usuario, “Autorización” o proceso para determinar los recursos a los que un usuario tiene acceso y el tipo de acceso permitido y “Accounting”, un concepto de responsabilidad que permite auditar la actividad de los usuarios en el sistema.

Básicamente, las comprobaciones en este aspecto vienen a ser:

¿Tiene la aplicación un mecanismo que permita a cada usuario identificarse ante el sistema de manera única y sin posibilidad de ser suplantado? En este sentido, existen numerosas soluciones con una gama de precisión que suele ir acorde con el precio que cuestan y que aportan garantías de autenticación adaptables a la criticidad de la información a proteger.

¿Cuenta la aplicación con un sistema de autorización que permita salvaguardar la información de elementos no autorizados? Aquí conviene remarcar dos cosas. Primera: no es conveniente realizar la autorización al mismo tiempo que la autenticación, pues son dos aspectos diferenciados que deben ir separados. Y Segunda: las opciones para proteger la información van desde simples rutinas de acceso hasta el uso de criptografía para proteger la información. Hay una amplia gama de soluciones en el mercado, tanto en código abierto como en soluciones propietarias, de gran eficacia para proteger la información dependiendo del grado de protección que se precise.

¿Existe un registro que permita conocer la actividad de los usuarios en el sistema? Cuando se produce una incidencia o se manifiesta un problema es muy útil conocer qué estaba pasando en el sistema en un momento dado, quiénes lo estaban utilizando, qué módulos estaba siendo usados y en qué condiciones se produjo el fallo. Es necesario que los registros de auditoría no revelen información crítica del sistema a usuarios maliciosos o atacantes, por eso resulta de especial importancia que cualquier registro de auditoría esté convenientemente protegido y su información restringida a usuarios caracterizados como auditores o forenses.

Hasta aquí llegamos hoy. Tenemos previsto hacer una serie de artículos alineados con la seguridad en el ciclo de vida del desarrollo que cubrirán ampliamente el ciclo de vida y que esperamos sean del agrado de los lectores.

Firma: M4ky4 01001010 01001011