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

En el último artículo hacíamos un enfoque general del modelo de evaluación de la madurez de la seguridad (SAMM) para el desarrollo de aplicaciones, su conveniencia como modelo de gobierno y atacábamos la seguridad desde la base, la autenticación, la autorización y el “accountability” o responsabilidad sobre lo que se hace, lo que se suele conocer como AAA en el entorno de seguridad de aplicaciones.

Para continuar describiendo el ciclo de seguridad, necesitamos explicar cuáles son los mecanismos que hacen una aplicación segura desde la parte más conceptual hasta la más específica, desde la arquitectura general hasta el detalle del diseño. Para ello nos apoyaremos en los principios fundamentales de arquitectura y diseño:

¿Cuánta seguridad es suficiente? – La pregunta que representa al nudo gordiano de la seguridad es precisamente ésta. Nunca hay suficiente seguridad desde un punto de vista objetivo. Siempre habrá algún elemento, proceso o implementación que pueda considerarse menos seguro. Siempre la respuesta vendrá de la mano de aquello que se pretende proteger para dotar al sistema de la seguridad aceptable.

Defensa en profundidad – Las medidas de seguridad deben aplicarse en la medida de lo posible para que actúen como si fueran las capas de una cebolla y no repetir las defensas en capas diferentes. El ejemplo es claro: si protegemos un sistema con cuatro cortafuegos en sucesivas capas y no aplicamos diferentes configuraciones en cada uno de ellos, diferente fabricante, diferentes reglas de filtrado, diferentes monitorizaciones, … cualquier atacante que supere el primero podrá superar fácilmente los otros tres.

Tolerancia a fallos – Los sistemas deben ser diseñados para que fallen de manera segura. Esto quiere decir que el sistema no puede procesar un fallo de manera que pueda provocar daño, afectar a la integridad de los datos, divulgar datos sensibles del sistema, como información personal, contraseñas, etc.

Economía de mecanismos (Principio KISS) – Nombrar el conocido principio: Keep it Simple, Stupid. Sería suficiente para alertar de los nidos de fallos que suponen las sofisticaciones de procesos simples. A mayor complejidad, mayor posibilidad de fallo y con una mayor posibilidad de fallo aumenta también la posibilidad de que algún atacante aproveche el fallo para vulnerar el sistema.

Completitud del diseño – El diseño no debe hacerse únicamente teniendo en cuenta el problema que soluciona, deben considerarse los usuarios que interactúan, otros sistemas que se comunican, los elementos que lo componen y el propio entorno de operación para entender la seguridad adecuada que ha de aplicarse.

Least common mechanism – Reducir la cantidad de mecanismos comunes para realizar tareas que se repiten en distintos puntos del sistema. Si existe una acción que precisa una rutina, lo mejor es implementar una función común o incluso desarrollar una librería o framework que permita evitar la reinvención de la rueda para rutinas comunes cada vez que se implementan.

Open design – Diseño abierto. Ocultar el diseño no hace un sistema más seguro, pero sí lo hace más difícil de mantener, de mejorar o implementar medidas de seguridad sobre él. También oculta fallos y predispone a soluciones parciales que no abarcan la seguridad del sistema en su totalidad.

Considerar el eslabón más débil – Siempre se ha dicho que la cadena es tan fuerte como el más débil de sus eslabones. Siempre que por alguna razón sea necesario incluir un elemento que pueda debilitar la seguridad del sistema, hacerlo de manera que pueda tenerse en cuenta para la aplicación de controles compensatorios.

Redundancia – La redundancia permite que los procesos no se paren. Un sistema redundante permite que, en caso de fallo, el sistema siga funcionando. Los procesos redundantes pueden canalizarse a través de diversos procedimientos, pero el objetivo final es la continuidad de la operación.

Aceptabilidad psicológica –  Las medidas de seguridad deben ser aceptables. El ejemplo más utilizado aquí es el uso de una contraseña compleja de muchos caracteres con mayúsculas, minúsculas, signos y números. Nadie se la va a aprender y terminarán anotándolas en ficheros de testo para hacer copia/pega o incluso en un post-ít para no defraudar a los maniáticos de la seguridad. Un login automático con token, Yubikey, biometría o certificados digitales puede ser una buena forma de fortalecer la seguridad en la medida que las posibilidades económicas lo permitan.

Separación de funciones – Es necesario conocer la matriz de roles y accesos para evitar conflictos en el uso del sistema. Deben estar claramente separados los roles de usuario, administrador y auditor del sistema. De la misma manera, los roles del ciclo de desarrollo deben estar claramente identificados, los desarrolladores no pueden interactuar con la plataforma de producción y las operaciones en producción deben ser cuidadosamente planificadas y documentadas.

Vacaciones obligatorias – Los componentes del equipo de desarrollo deben tomar vacaciones de manera obligatoria. A menudo una ausencia descubre una vulnerabilidad o un defecto que voluntaria o involuntariamente pudiera quedar oculta.

Rotación de puestos – Los puestos en el equipo de desarrollo son complementarios y una única visión puede esconder vulnerabilidades y fallos. Las rotaciones tienen la capacidad de renovar al equipo y plantear nuevas visiones desde otros roles. Por otro lado, rotando puestos resulta más difícil que el equipo se alíe para tapar fallos o comportamientos inadecuados que podrían perjudicar la seguridad del conjunto.

Mínimo privilegio – Los permisos o privilegios que se otorgan a los usuarios deben establecerse al mínimo. De hecho, resulta muy útil disponer de una matriz de accesos que facilite la creación de grupos de usuarios relacionados con los roles resultantes de la matriz.

Necesidad de conocer – Los permisos deben establecerse a través de la manifestación de la “necesidad de conocer”, es decir: la persona que otorga los permisos lo debe hacer en base a la sensibilidad de la información. De esta manera, la información sensible siempre estará reservada a aquellos usuarios autorizados.

Control dual – El control dual es un procedimiento que requiere la intervención de al menos dos personas. La separación de funciones es un concepto que enlaza con éste y permite evitar problemas de seguridad ligados a la intervención de una única persona, que podrían generarse por error o por falta de revisión.

A partir de aquí, la seguridad en el desarrollo puede ir articulándose y adaptándose al proceso de desarrollo, según los recursos disponibles y las características del negocio, pero estos principios son indiscutibles para comenzar.

Querido lector: si has llegado hasta aquí creo que verdaderamente estás interesado en conocer cómo hacer tu ciclo de desarrollo más seguro. Síguenos en la próxima entrada de esta serie porque seguiremos contando todo lo que se puede hacer para tener aplicaciones seguras. El camino es largo, pero cada jalón merece la pena y no es fácil de olvidar.

Firma: M4ky4 01001010 01001011

 

Autor: QAnewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s