La práctica que tienen los fabricantes de software de autoexcluirse de cualquier responsabilidad derivada, directa o indirectamente, del uso de su producto es algo que cada día será menos tolerado. ¿Qué pasa con el software que no incluye contramedidas frente a todos los ataques públicamente conocidos que le afectan? ¿Qué ocurre cuando un sistema web deja expuestos datos privados de sus usuarios por un error de diseño o de implementación? ¿No deben el fabricante, el administrador y todos los demás agentes relacionados con ese servicio repartirse las responsabilidades?

Diseño seguro
Si buscamos el origen del interés por la seguridad en los sistemas computacionales e informáticos nos tendremos que remontar hasta mediados de los años sesenta cuando se puso en marcha el proyecto Multiplexed information and Computing Service, Multics¹, que es el precursor de lo que hoy conocemos como sistema operativo de tiempo compartido. Esa aventura pionera duró hasta el 30 de octubre de 2000, fecha en la que se apagó el último sistema que ejecutaba Multics.
Parte de la gente que trabajaba en ese proyecto pasó a desarrollar lo que dieron en llamar Unix² en 1969. El diseño de Unix es muy diferente al de Multics, ya que aquél buscaba el modo de conseguir un sistema operativo pequeño y sencillo. Sin embargo, en el caso de Multics, el énfasis principal se puso en la seguridad del sistema. Multics fue el primer sistema operativo diseñado para ser seguro desde el principio; sin embargo, nunca llegó a conseguirlo del todo. Para que un sistema informático pueda ser seguro es necesario diseñarlo desde el principio de forma tal que pueda llegar a serlo. Esta previsión supone tomar medidas específicas para minimizar el impacto que tendrán las vulnerabilidades que pueda haber, cuando éstas sean descubiertas. Los diseños que funcionan bien no suelen, ni cuentan con ser secretos, sino que aplican la doctrina de Kerckhoffs³ que, ya en 1883, venía a decir que si quieres estar seguro, entrégale tu software a tu enemigo y comprueba que no puede hacer nada grave con él.
No es obligatorio pero la seguridad de verdad es aquella en la que cualquiera está autorizado a conocer y entender el diseño precisamente “porque es seguro”. La publicidad tiene la gran ventaja de que cuanta más gente esté mirando el código, antes se descubrirán sus fallos⁴; es cierto que con ello también los atacantes los consiguen, pero al menos resultan conocidos y se puede reaccionar ante ellos. En un diseño seguro se debe desconfiar de muchas cosas, especialmente de los argumentos de entrada, pero un programa tolerante a fallos debe incluso desconfiar de su propio código.
La seguridad de los sistemas informáticos ha acompañado a estos desde su mismo origen dentro de las actividades militares y de inteligencia que les vieron nacer. De hecho, su estandarización ha sido siempre requisito impuesto por los gobiernos y administraciones para que los fabricantes y proveedores pudiesen vender sus equipos a las distintas administraciones.

Estándares
ITSEC era en 1990 el estándar europeo, desarrollado por Francia, Alemania, Holanda y Reino Unido, y fue una unificación de trabajos anteriores tales como el UK Evaluation Scheme del CESG⁵ británico para el mercado de la defensa e inteligencia, y el Green Book del DTI⁶ dirigido al uso comercial. Por otra parte, el CTCPEC⁷ era en 1993 el estándar canadiense de seguridad informática y estaba inspirado en el estándar del Departamento de defensa de EE.UU., el TCSEC⁸. Este estándar, también llamado el Orange Book dentro de la Serie del Arcoiris⁹, establecía los requisitos básicos para evaluar la efectividad de los sistemas de control incluidos en los sistemas de información dedicados al procesado, almacenamiento y recuperación de información sensible o clasificada del gobierno de EE.UU.
La tesis central del libro naranja deriva de los trabajos de Dave Bell y Len Lapadula¹⁰, que proponen un modelo para asegurar el control de acceso a datos confidenciales en aplicaciones militares y gubernamentales. El estándar TCSEC fue actualizado en 1985, y estuvo activo hasta que en el año 2005 fue reemplazado por el estándar internacional conocido como Common Criteria y que reunió en uno a los tres estándares mencionados.

El que un producto esté certificado frente a Common Criteria, no necesariamente significa que sea completamente seguro. Ejemplos bien conocidos de ello son varios sistemas operativos de Microsoft y algunos Linux, que han sido certificados con nivel EAL4+ y, sin embargo, todos sabemos que regularmente tienen que ser parcheados por el descubrimiento continuo de nuevas vulnerabilidades.

MILS
La filosofía del estándar TCSEC ha evolucionado hacia lo que se conoce como Multiple Independent Levels of Security/Safety, o simplemente MILS. Se trata de una arquitectura de alta seguridad basada en los conceptos de separación y en el control de los flujos de información¹¹. MILS utiliza la separación entre componentes de confianza y los que no los son, y consigue que la seguridad global no sea evitable, que sea evaluable, siempre accesible y a prueba de manipulaciones¹².
Las soluciones MILS permiten la evaluación independiente de los componentes de seguridad y la conexión confiable entre todos ellos. El planteamiento MILS vino a sustituir al modelo anterior del libro naranja del Departamento de Defensa de EE.UU.
Un sistema MILS emplea uno o más mecanismos de separación (separación en el kernel, en el sistema de comunicaciones, separación física) para mantener los datos seguros y los procesos separados. Un sistema MILS acepta la aplicación de una o más políticas de seguridad autorizando el flujo de información sólo si éste se produce entre componentes en el mismo dominio de seguridad o a través de monitores de seguridad confiable.

A pesar de todas las limitaciones y dificultades actuales, es necesario que el software y los sistemas de información se diseñen y se produzcan listos para operar a un nivel de seguridad consistente, con el riesgo que se afronta en el caso de pérdida, imprecisión, alteración, indisponibilidad, o uso inadecuado de los datos y recursos que el sistema utiliza, controla o protege.

Common Criteria
Los Common Criteria¹³ unificaron los estándares existentes hasta el año 2005 y, en principio, permitió su evaluación frente a una única norma a las compañías que venden material informático al gobierno para su uso en defensa e inteligencia. Los Common Criteria fueron desarrollados por los gobiernos de Canadá, Francia, Alemania, Holanda, Reino Unido y EE.UU.
En los Common Criteria los usuarios de los sistemas informáticos especifican sus necesidades de seguridad, y los vendedores pueden entonces desarrollar y/o “reivindicar” acerca de los atributos de seguridad de sus productos, mientras que los laboratorios de evaluación determinan si eso es cierto. Los Common Criteria proporcionan pruebas de que los procesos de especificación, implementación y evaluación de los productos de seguridad informática han sido llevados a cabo de una manera rigurosa y estandarizada.
Los laboratorios encargados de evaluar el cumplimiento de este estándar deben, a su vez, seguir el ISO 17025, originalmente conocido como la ISO/IEC Guide 25, y publicado por la ISO en 1999. Esta norma tiene puntos en común con la ISO 9000, pero implica en la evaluación a las organizaciones especializadas de ensayo y calibración¹⁴. Su segunda publicación, en el año 2005, está más alineada con el ISO 9001 y pone más énfasis en la importancia de una gestión experimentada, y en hacer explícita la necesidad de una mejora continua del sistema.
El proceso de evaluación en Common Criteria intenta establecer el nivel de confianza que puede depositarse en las características de seguridad del producto a través de procesos específicos de control de calidad y en las medidas tronadas durante el desarrollo del producto, y que están encaminadas a forzar el cumplimiento de los requisitos de seguridad declarados.
Common Criteria incluye una calificación numérica que describe la profundidad y el rigor con el que se realiza la evaluación. Cada nivel se corresponde con un paquete de requisitos de seguridad que cubren totalmente el desarrollo de un producto, con un determinado nivel de exigencia. Common Criteria tiene siete niveles de creciente coste en la implementación y en la evaluación; sin embargo, el aumento de nivel no necesariamente significa más seguridad, tan sólo significa que las propiedades declaradas han sido evaluadas con más detalle.
El atractivo de los Common Criteria está en su acuerdo adjunto conocido Common Criteria Mutual Recognition Arrangement, por el cual cada parte reconoce las evaluaciones respecto a ese estándar hechas por los demás miembros¹⁵. Este acuerdo ha sido rebautizado como Common Criteria Recognition Arrangement (CCRA) y dentro de él sólo se reconocen evaluaciones hasta nivel EAL 4. Las evaluaciones con niveles EAL5 y superiores tienden a incluir los requisitos específicos de seguridad impuestos por el gobierno anfitrión de que se trate.
El que un producto esté certificado frente a Common Criteria, no necesariamente significa que sea completamente seguro. Ejemplos bien conocidos de ello son varios sistemas operativos de Microsoft Windows –como Windows Server 2003 y Windows XP–, y algunos Linux, que han sido certificados con nivel EAL4+ y, sin embargo, todos sabemos que regularmente tienen que ser parcheados por el descubrimiento continuo de nuevas vulnerabilidades.
Esta aparente contradicción de que sean inseguros productos que están certificados como seguros es posible porque, en el proceso de certificación Common Criteria, se permite al vendedor restringir el análisis a ciertas características de seguridad y hacer ciertas suposiciones acerca del entorno de operación y sobre la intensidad de las amenazas afrontadas por el producto en ese entorno. Varios productos Windows han sido evaluados basándose en la suposición de que siempre operarían con componentes del mismo nivel de seguridad que ellos proporcionan, lo cual no es realista en la mayoría de los sistemas de propósito general y de uso común. Por lo tanto, el certificado Common Criteria realmente dice que esos sistemas son seguros si todos los demás lo son. Estas condiciones en letra pequeña están incluidas en el documento que se conoce como Evaluated Configuration, y son dictadas por el propio Microsoft.
En todo proceso de certificación, la evaluación es costosa, en el rango de los cientos de miles de euros, y lo que se consigue realmente no es necesariamente un producto más seguro, por lo que muchas veces es difícil la justificación de ese gasto.

Los evaluadores Common Criteria en el mercado libre sólo llegan a evaluar a niveles EAL5, mientras que la evaluación a niveles superiores siempre está hecha por expertos de las correspondientes agencias de seguridad nacional que podrían adquirir el producto. Esta realidad matiza bastante el principio de reconocimiento mutuo de este estándar.

La evaluación Common Criteria se centra, principalmente, en la documentación de evaluación, y no tanto en la seguridad, en la corrección técnica o en los méritos del producto en sí. De hecho, los evaluadores en el mercado libre sólo llegan a evaluar a niveles EAL5, mientras que la evaluación a niveles superiores siempre está hecha por expertos de las correspondientes agencias de seguridad nacional que podrían adquirir el producto. Esta realidad matiza bastante el principio de reconocimiento mutuo de este estándar.
El esfuerzo y tiempo necesarios para preparar la evaluación y sus documentaciones relacionadas es muy grande, e incluso llega a darse el caso de que el producto resulta ya obsoleto cuando se ha completado el proceso de certificación.
En cierta manera, el proceso que representan los Common Criteria quizás discrimina un poco a organizaciones y modelos de desarrollo de productos que sigan el paradigma Free and Open Source Software¹⁶. Los requisitos de la evaluación Common Criteria están inspirados en la metodología tradicional de desarrollo de software “en cascada”¹⁷; sin embargo, mucho software libre se produce siguiendo paradigmas menos secuenciales, más descentralizados y más modernos¹⁸, y también ellos requieren de su seguridad.
A pesar de todas las limitaciones y dificultades actuales, es necesario que el software y los sistemas de información se diseñen y se produzcan listos para operar a un nivel de seguridad consistente, con el riesgo que se afronta en el caso de pérdida, imprecisión, alteración, indisponibilidad, o uso inadecuado de los datos y recursos que el sistema utiliza, controla o protege.
Antes de poder exigir seguridad al software es necesario identificar y categorizar la información que se va a tratar, de acuerdo con su sensibilidad, y medir el impacto que puede tener sobre la vida humana, la imagen, la reputación; o si puede conducir a la pérdida de otros valores o recursos. Pero, una vez hecho esto, los requisitos de seguridad mínima deberían ser parte del contrato de compra o de prestación de servicios y deberán ser garantizados por laboratorios especializados profesionales y realmente independientes.
La arquitectura y el diseño del software o de los sistemas de información debe ser el resultado de un cuidadoso análisis lógico del código y de los datos, del análisis de la interface y de las restricciones impuestas por tener que operar en el mundo real. La certificación puede ayudar, ser necesaria incluso, pero, sin duda, no es suficiente.

¹ http://www.multicians.org/history.html
² Brian Kernighan propuso el nombre de Unics por contraposición al de Multics; posteriormente el nombre evoluciono a Unix que es marca comercial.
³ Ver http://en.wikipedia.org/wiki/Kerckhoffs
⁴ Ver http://en.wikipedia.org/wiki/Linus’s law
⁵ CESG (Communications-Electronics Security Group) es una sección del Servicio de inteligencia británico (GCHQ) encargada de la seguridad en las comunicaciones y en los sistemas de información del gobierno británico y de las infraestructuras críticas del Reino Unido.
⁶ DIT (Department of Trade and Industry) fue el ministerio británico de comercio e industria hasta que fue reemplazado por el Department for Business, Enterprise and Regulatory Reform y el Department for Innovation, Universities and Skills en junio de 2007.(1)
⁷ CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) es un estándar publicado en 1993 por el Communications Security Establishment canadiense para establecer criterios de evaluación en productos IT.
⁸ TCSEC (Trusted Computer System Evaluation Criteria) es un estándar del departamento de Defensa de EE.UU. que establece los requisitos básicos para medir la efectividad de los controles de seguridad en un sistema informático.
⁹ La Rainbow Series (o Rainbow Books) es una serie de estándares sobre seguridad en ordenadores publicados por el gobierno americano en las décadas de los ochenta y noventa. Originalmente los publicaba el departamento de Defensa, y luego los paso a publicar el National Computer Security Center.
¹⁰ Ver http://en.wikipedia.org/wiki/Bell_La_Padula
¹¹ John Rushby: “ Design and Verification of Secure Systems”. Proc. 8th ACM Symposium on Operating System Principles: 12–21. 1981
¹² NEAT = Non-bypassable, Evaluable, Always-invoked & Tamperproof
¹³ ISO/IEC 15408: Los Common Criteria for Information Technology Security Evaluation (CC) y su documento anejo Common Methodology for Information Technology Security Evaluation (CEM) son las bases técnicas del acuerdo internacional conocido como Common Criteria Recognition Agreement (CCRA) para la certificación de productos IT.
¹⁴ Ver http://www.commoncriteriaportal.org/labs.html
¹⁵ http://www.commoncriteriaportal.org/members.html
¹⁶ Ver http://en.wikipedia.org/wiki/FOSS
¹⁷ El modelo “ en cascada“ es un proceso secuencial de desarrollo de software, que contempla las fases de: concepción, iniciación, análisis, diseño (validación), construcción, testeo y mantenimiento.
¹⁸ http://en.wikipedia.org/wiki/Agile_software_development