Fundamentos de la Inseguridadde las Tecnologías de la

Información

ResumenA lo largo de años de evaluación y análisis de la seguridad de losmejores productos de seguridad de las tecnologías de lainformación, en Epoche and Espri han identificado patrones ytipologías de problemas de diseño y construcción de tecnología,así como de ataques realizables a los sistemas informáticos. Estacharla realiza una pesimista presentación de los mismos, eintenta proyectar el previsible futuro en este campo.

Sobre Miguel BañónMiguel Bañón, Licenciado en Informática, UPM 1990. Directorde Epoche and Espri, laboratorio de evaluación de la seguridad delos sistemas de información, acreditado por los esquemas decertificación de España para la norma “Common Criteria”, y porlos de Estados Unidos, Canadá, Turquía y Japón para la validaciónde módulos criptográficos. Epoche tiene amplia experiencia en laparticipación de Proyectos de I+D en Europa, Estados Unidos yJapón, siendo una referencia mundial en la aplicación de la norma“Common Criteria”.

Propuesta de desarrolloPresentación de E&E

Evaluación de la seguridadRazón de las vulnerabilidades.

Previsión profesional.

Presentación deE&E

Epoche and Espri, S.L.U. (E&E) es un laboratorio de evaluación yensayos de seguridad de las tecnologías de la información.

Trabajamos bajo las normas internacionales más exigentes, ypara organismos de certificación de diferentes administracionesy países.

Para la certificación de la seguridad conforme a la norma ISO/IEC15408, “Common Criteria”, somos laboratorio acreditado delCentro Criptológico Nacional, adscrito al Ministerio dePresidencia, www.oc.ccn.cni.es, y del Organismo deNormalización de Turquía, http://bilisim.tse.org.tr

Para la certificación de la seguridad de módulos criptográficosconforme a la norma FIPS 140-2, somos uno de los dos únicoslaboratorios europeos acreditados por National Institute ofStandards and Technology, National Voluntary LaboratoryAccreditation Program, EE.UU.

Adicionalmente, somos laboratorio acreditado por el esquema decertificación de módulos criptográficos de Japón, bajo la normaISO 19790.

Somos entidad certificadora de seguridad de los sistemas de lainformación y de software de juego reconocida por la DirecciónGeneral de Ordenación del Juego de Ministerio de Hacienda yAdministraciones Públicas, http://www.minhap.gob.es

Tanto en número y tipo de acreditaciones, como en productos ysistemas certificados, lideramos el mercado español.

Nuestra cartera de clientes representa a las mejores empresasfabricantes de tecnología.

Estamos en expansión, con una creciente presencia en losmercados asiáticos y EE.UU.

Contamos con los mejores profesionales, por ejemplo, formadosy titulados de la UCM/FI.

Evaluación de laseguridad

¿Sistemas seguros?La necesidad de conocer la seguridad de los productos y sistemasde las TI es tan legítima como la propia necesidad de seguridad.

¿Se puede determinar laseguridad de un producto?

No. En términos generales, y con el grado de complejidad actual,sólo se puede demostrar la inseguridad de los mismos, medianteejemplos concretos de explotación de vulnerabilidades.

¿Entonces?Podemos ofrecer grados de confianza en la seguridad de unproducto.

¿Cómo obtener esa confianza?Hipótesis: hay un método de desarrollo que genera productos seguros.

¿Cómo determinar la seguridad de un producto?

Determinar si se ha seguido el método de desarrollo para elproducto a evaluar.Dedicar cierto esfuerzo a la búsqueda del contraejemplo de laseguridad del producto.

Si se cumple el método, y no se encuentran vulnerabilidades,afirmaremos que es seguro.

¿Con qué convicción?

Con la que tengamos en el método de desarrollo, y en relación alesfuerzo que hayamos aplicado a la búsqueda del contraejemplo.

¿Qué método genera productosseguros?

Una metodología de desarrollo (de software, generalmente) debegarantizar el cumplimiento de los requisitos funcionales y nofuncionales de un producto.

Hay metodologías, métricas sobre las metodologías, e inclusoniveles de madurez de estas metodologías.

La seguridad es, en realidad, un atributo más del producto, comola fiabilidad o la facilidad de uso. Cualquier método de desarrollo“genérico” debería ser capaz de obtener productos seguros, si laseguridad es un atributo deseable.

Cuando un atributo del producto impera sobre los demás, suelecondicionar el método de desarrollo. Hay ciertas técnicas yprácticas de desarrollo que han demostrado una influenciadirecta en la seguridad del producto resultante.

Modelo implícito1. Analizar y diseñar la seguridad que se requiere al caso.2. Implementar esa seguridad con funciones y mecanismos

adecuados.3. Probar las propiedades de seguridad resultantes.4. Documentar todo lo relevante al uso seguro del producto para

su administrador y usuarios.5. Controlar la seguridad del entorno de desarrollo y cada cambio

realizado en el producto.6. Establecer procedimientos de distribución del producto que

permitan identificar/corregir modificaciones del mismo.7. Establecer procedimientos de resolución de los fallos o no

conformidades de la seguridad del producto.8. Buscar las vulnerabilidades que puedan haberse introducido

en el producto, a pesar de los esfuerzos anteriores.

Cada fase o actividad de las anteriores se puede escalar condistintos grados de esfuerzo. Por ejemplo, se pueden probar:

Las especificaciones globales del producto;El diseño interno del mismo;Cada uno de sus componentes.

¿Hay otras aproximaciones a laevaluación de la seguridad?

autodeclaraciones del fabricante;dejar el producto en el dominio público y reaccionar a lasvulnerabilidades, etc

No son objeto de consenso internacional en el campo de lacertificación.

¿Qué es la norma ISO15408?Un acuerdo internacional sobre el método de desarrollo seguro, ysobre 7 niveles discretos de la gama de esfuerzo, incluyendo laespecificación del trabajo de los evaluadores en cada nivel.

Un paradigma de arquitectura de seguridad sobre el que se aplicaun catálogo coherente y relacionado de funciones de seguridadque permiten establecer un lenguaje común para la expresión dela seguridad de los productos y sistemas de las TI.

¿Cuál es su origen?

¿Qué otros elementos tiene ensu entorno?

¿Cómo es la norma ISO15408?Voluminosa

Parte 1 – Introducción y modelo generalParte 2 – Requisitos funcionales de seguridadParte 3 – Requisitos de garantía de seguridad

Estructurada

En evolución

El llamado “Common Criteria Management Board”, formado porAUS, CAN, FR, GE, NL, SP, UK y USA mantiene y avanza el CC aresultas de la evolución de la tecnología, las peticiones de losinteresados y de los esquemas de certificación nacionales.http://www.commoncriteriaportal.org

¿Cuál es el resultado de suaplicación?

Un informe técnico del laboratorio de evaluación, donde sedetermina si la evaluación de la declaración de seguridad y delproducto han sido satisfactorias, y el nivel de garantía deseguridad obtenido en la evaluación.

¿Qué es la declaración deseguridad?

El documento, de contenido normalizado, que refleja el análisis ypropiedades de seguridad del objeto a evaluar.

La norma supone que se aplica desde la concepción del producto,asumiendo idealmente un desarrollo top-down, que comenzaríacon los análisis requeridos en la declaración de seguridad, y quevan a conformar el producto.

¿Qué es el nivel de garantía deseguridad?

El nivel de metodología de desarrollo aplicado al producto, que vaparejo a un esfuerzo y detalle de evaluación determinado.

¿Qué significa un certificadoCC?

¿Qué significa un certificadoCC?

Que la declaración de seguridad es cierta.El grado de confianza que se puede poner en dichaaseveración.

Este documento debe estar a nuestra disposición, ya quedetermina la verdadera utilidad del producto.

Paradigma funcionalNecesitamos especificar las propiedades de seguridad de unproducto como fase previa a su evaluación. CC establece en suparte 2 un catálogo de requisitos funcionales de seguridad quepermiten esta especificación. Los requisitos funcionales sederivan de un modelo general de producto de seguridad, elparadigma funcional.

Con este paradigma de IT y su seguridad, se establece uncatálogo de requisitos funcionales de seguridad

Con estos requisitos funcionales de la parte 2, expresamos lafuncionalidad de seguridad del producto

ResumiendoLa seguridad se puede diseñar como cualquier otro atributo deun producto.El diseño de un producto seguro es caro y requiere de unproceso de ingeniería explícito.La medida de la seguridad es un problema complejo, requiereesfuerzo y competencia técnica, y únicamente puede ofrecergrados de garantía.

Razón de lasvulnerabilidades.

NotaComplejidad, capacidad de comprensión, determinismo yaleatoriedad.

VulnerabilidadesVulnerabilities can arise through failures in:

requirements -- that is, an IT product or system may possess allthe functions and features required of it and still containvulnerabilities that render it unsuitable or ineffective withrespect to security;construction -- that is, an IT product or system does not meetits specifications and/or vulnerabilities have been introducedas a result of poor constructional standards or incorrect designchoices;operation -- that is, an IT product or system has beenconstructed correctly to a correct specification butvulnerabilities have been introduced as a result of inadequatecontrols upon the operation.

Vulnerabilidades en la especificaciónSon las más habituales, no se considera la seguridad hastaterminado el desarrollo.

Por lo general, un producto destinado al mercado de la seguridadno ofrece ninguna seguridad.

Casos de uso frente a casos de abuso.

Vulnerabilidades en la construcciónDe nivel más técnico, para evitarlas se requiere de la práctica detécnicas de diseño y programación seguras.

Algunos dramas en la construcción

Las hipótesis y el mundo realSea r un número aleatorio ...

Sea C un cálculo realizado a espaldas del enemigo, ...

Sea S un sistema aislado ...

Platón y el mito de la cavernaObservabilidadRealidad, virtualidad

El acceso y posesión física del producto en manos del atacantepermite vulnerar la práctica totalidad de las hipótesis tenidas encuenta durante su construcción.

Linearidad del impacto de un cambio en laseguridad

Modularidad, reusabilidadEconomía de construcción vs. calidad y conocimiento de loscomponentes.

Modelos económicos de desarrollo

Casos de éxito en la industria vs economía de la seguridad

Vulnerabilidades en laoperación

FormaciónConfianzaEl enemigo en casa

Previsiónprofesional.

El sector de la seguridad de las TIC tiene un futuro muyprometedor ...... inversamente proporcional a la previsible experiencia en lageneralización absoluta de nuestra dependencia en las mismasTIC.

Q&A

Thanks!