¿Pugnan la academia y la empresa en la seguridad por diseño? (Una historia de Star Wars)

En un universo infinito, donde puede que exista una serie infinita de universos paralelos, que a su vez quizás existen dentro de un multiverso a su vez infinito, podemos afirmar que la probabilidad de que un desarrollo software que pasa al departamento de Q&A esté libre de vulnerabilidades es prácticamente cero. Y, por si fuera poco, la probabilidad de que esos universos estén masivamente poblados de usuarios maliciosos dispuestos a aprovechar esa vulnerabilidad es prácticamente del cien por cien. Que se lo pregunten a Galen Erso que tuvo que inventarse una historia apoteósica para que nadie se diese cuenta de su error de diseño.

Aunque en la entrada anterior sobre la Seguridad y Privacidad por diseño (SPD) vimos el ciclo de vida del desarrollo software seguro y los objetivos perseguidos,
la manera de abordar este proceso genera una infinidad de enfoques. La
ingeniería de seguridad es un constante campo de batalla y las mayores
diferencias podemos notarlas en la divergencia entre cómo aborda la SPD la empresa y cómo lo hace el sector académico. Dos grupos con ciertas diferencias pero que con esfuerzo pueden complementarse satisfactoriamente.

Ni los esfuerzos científicos desde la universidad están guiados por un consejo de sabios que se reúnen en cónclaves definiendo nuevos niveles de abstracción del diseño, ni en la empresa un directivo con traje arroja billetes a un servidor de red hasta que se securiza solo. Ojalá fuese así, ya que la divergencia Academia-Empresa sería fácilmente resoluble. Pero en la práctica, los enfoques de ambos mundos se han aproximado, han aprendido unos de otros y han logrado establecer unos procesos de ingeniería de seguridad adecuados, aunque aún queda un largo camino por recorrer.

Que universidades y empresas tienen que trabajar conjuntamente no es nada nuevo, es un discurso repetido hasta la saciedad. Múltiples organismos internacionales ponen su máximo empeño en que exista una colaboración constante en el plano no solo de la investigación y la innovación, sino también en el desarrollo. Llegando a invertir grandes sumas para la realización de ambiciosos proyectos de investigación que tengan continuidad y sean convertidos en productos. Un flujo natural del plano científico de la academia, al comercial de la industria. Este impulso a nivel internacional, europeo y nacional supone un motor indudable del que han surgido tres tipos diferentes de resultados:

• Un reducido número de proyectos de indudable valor y calado.
• Una gran cantidad de proyectos lamentablemente invisibles, fracasados u olvidados.
• Una cantidad moderada de proyectos que quizás debieron ser detenidos en su momento, antes de otorgarles viabilidad comercial. 

Por tanto, en vez de trazar una línea divisoria inexpugnable, repasemos algunos de los enfoques más extendidos de la SPD que afectan a todo el ciclo de vida del desarrollo software ya que establecen las estrategias de diseño necesarios. Estos métodos que tanto Academia e Industria han interiorizado en mayor o menor medida facilitan el diseño y desarrollo de sistemas seguros.

Diseño dirigido por Requisitos de Seguridad y Privacidad
Este enfoque quizás sea el más intuitivo. Surge en tiempo de diseño cuando se recogen todos los requisitos funcionales y no funcionales del sistema, entre los que se encuentran los requisitos de seguridad y privacidad. Incluso en los primeros bocetos de los componentes que formarán parte del sistema, numerosas consideraciones deben ser tenidas en cuenta porque afectarán no solo al hardware y al software, sino también definirán qué aspectos preventivos o «remediativos» deben poseer el sistema. Además de verificar las posibles interdependencias y conflictos que los mecanismos de seguridad y privacidad incorporan al sistema.

De esta fase de pre-diseño, cada vez más automatizada, se recolectan requisitos de seguridad de estándares como el Common Criteria. También se introducen aquellos derivados de taxonomías específicas de riesgos de seguridad y privacidad, como pueden ser las propuestas por el NIST. Además, incorporan los niveles de evaluación, como ITSEC, cuyo cumplimiento puede ser exigido desde esta fase inicial. En definitiva, el sistema no superará esta fase sin que todo el conjunto de requisitos de seguridad y privacidad hayan sido satisfechos. La fase de diseño puede continuar con la resolución funcional del problema, pero integrará de manera efectiva todos los elementos de diseño necesarios.

Supongamos que estamos en la fase de diseño de la infraestructura de red de una gigantesca estación espacial flotante, como la Ciudad de las Nubes (Cloud City) en el Imperio Contraataca de Star Wars. Un requisito de seguridad podría perfectamente no dejar paneles y puertos de conexión desprotegidos, a la vista de cualquiera y sin control de acceso. Así es como R2-D2 pudo detener el proceso de compactación de basura. Pero un flagrante riesgo de seguridad y privacidad adicional, es que los archivos con información confidencial sobre las acciones del Imperio Galáctico fuesen accesibles desde el mismo segmento de red en el que estaba el compactador, y eso lo utilizase el androide para recuperarlos. Ambos requisitos eran conocidos con bastante antelación y por tanto debieron ser previstos en una fase bien temprana del diseño.

Ingeniería de Seguridad basada en Modelos
La búsqueda de procesos de diseño optimizados y automáticos derivó en la reutilización de arquitecturas y componentes que sistemáticamente reaprovechan estructuras y funcionalidades. Para ello la segregación y empaquetado de dichos componentes en modelos, se ha convertido en una práctica útil a la hora de resolver requisitos funcionales y no funcionales. Gracias a este enfoque, los subsistemas son mejorados, certificados y pueden ser validados con independencia al entorno o al dominio de uso, permitiendo la mejora continua de las partes aisladas y poseer un alto control sobre las dependencias e interfaces que se establecen con el resto del sistema.

Este tipo de diseño modular ha permitido ofrecer soluciones muy variadas, desde utilizar el lenguaje de modelado UML, a otros más específicos como SysML o UMLSec donde gráficamente se traza el diseño del sistema. Estos enfoques pueden incluir desde modelos de vectores de ataque, hasta modelos de las circunstancias erróneas que el sistema debe evitar a toda costa. En otros casos, el enfoque establece un proceso de varias fases que parten de metamodelos que son instanciados con las características adecuadas al entorno donde será integrado. Por último, existe una completa vertiente en este enfoque que es el diseño mediante patrones de seguridad, que son artefactos que autocontienen los mecanismos para resolver requisitos o dotar al sistema de propiedades de seguridad y privacidad, además establecen los mecanismos para integrar en el ciclo de vida del desarrollo software.

La Estrella de la Muerte disponía de suficientes turbo láseres, blásteres, cañones láser, iónicos y magnéticos en superficie como para detener cualquier ofensiva. Y su construcción fue optimizada gracias a modelos de diseño que fueron replicados con éxito por toda la esfera de la estación basados en predicciones de los vectores de ataque probables. Obviamente estos modelos no tuvieron en cuenta la movilidad y velocidad de acción necesaria en las defensas instaladas en la trinchera meridiana que conducía a los conductos de ventilación, no tuvieron en cuenta los requisitos diferenciales del entorno donde eran desplegados. El Imperio, que no reparaba en gastos, corrigió el diseño, mejorando los modelos, aunque esto supuso la introducción de otras vulnerabilidades del diseño que se incorporaron a la segunda Estrella de la Muerte.

En la siguiente entrada de esta serie seguiremos repasando otros enfoques de diseño seguro, que demuestran los esfuerzos realizados para descubrir los mejores procedimientos a seguir para obtener software y sistemas más seguros y resilientes.