Diseño de Sistemas Seguros Arquitectura y Modelos Modelos de Seguridad
1
Temario
2
Introducción Requerimi Req uerimien entos tos de protección protección de Info Información rmación Entorn Entornos os de prote protección cción de la IInfo nformación rmación Modelos de Seguridad Evaluación Evaluación y Certificación Certificación Certificacio Certificaciones nes de organizaciones organizaciones Certificació Certificación n de productos productos
Temario
2
Introducción Requerimi Req uerimien entos tos de protección protección de Info Información rmación Entorn Entornos os de prote protección cción de la IInfo nformación rmación Modelos de Seguridad Evaluación Evaluación y Certificación Certificación Certificacio Certificaciones nes de organizaciones organizaciones Certificació Certificación n de productos productos
¿Qué se espera de un sistema de información?
3
En el Mundo Ideal…
4
En to tod do proy oye ect cto, o, la segu gurrid idad ad es co con nside siderrada un pu pun nto fundamental desde el inicio. Los de desa sarr rroll ollos os de deben ben cu cumpl mplir ir con la pol polít ític ica a de segu seguri ridad dad existente en la organización. “Modelos de Amenazas” son utilizados a la hora de descubrir fallos y/o vul vuln nerabilidades. Los de desa sarr rroll ollad adore oress se en encu cuen entran tran ca capa pacitad citados os en as aspect pectos os relaciona relacionados dos con la seguridad seguridad en las las aplicaciones. aplicaciones. Se utilizan tilizan prácticas prácticas de programación programación segura. segura. El grupo de desarrollo incluye especialistas en seguridad de la información. Se real aliz izan an eval valua uaci cion one es y revisi vision one es de có códi digo go en forma forma periódica.
En el Mundo Real…
5
Las aplicaciones son inseguras. La seguridad no se encuentra integrada sino que “es integrada”. Vulnerabilidades triviales presuponen un gran riesgo. La mayoría de las veces el atacante solo requiere de un browser para vulnerar la seguridad de las aplicaciones. No se realizan evaluaciones ni revisiones de código en forma periódica.
Problemática General
6
Un atacante solo necesita conocer una vulnerabilidad. El defensor debe proteger todos los puntos de entrada. Los atacantes tienen tiempo ilimitado. El defensor trabaja con limitaciones de tiempo y dinero. Los sistemas seguros son por lo general, mas difíciles de utilizar. Las contraseñas complejas y seguras son difíciles de recordar. Los usuarios prefieren emplear contraseñas sencillas (Y si el administrador las piensa por ellos mucho mejor…) El equipo de desarrollo y los responsables de proyectos creen que la seguridad no aporta ningún valor. Resolver vulnerabilidades antes del lanzamiento de un producto es un proceso muy costoso.
Problemática General Desarrollador “No hace falta agregar estos chequeos aquí, de todos modos se ha configurado seguridad a nivel de base de datos”
DBA “Menos mal que el desarrollador pensó en la seguridad, de no ser así… tendría que haber lidiado con estos extraños permisos a nivel filas y columnas, además… de todos modos el server esta seguro pues el administrador lo ha asegurado”
Administrador
7
“Mmm… aquí no incluiré ACLs de todos modos, la aplicación y la base de datos seguramente están configurados para evitar este tipo de accesos”
Problemática General
8
¿Cuanto le cuesta la inseguridad informática a nuestro negocio? ¿Qué impacto tiene la falta de seguridad en la productividad? ¿Qué impacto tendría una interrupción de seguridad catastrófica? ¿Cuál es la solución más costo-efectiva? ¿Qué impacto tendría la solución sobre la productividad?
Requerimientos de protección de Información
9
Arquitectura de seguridad
10
Vista total de la arquitectura del sistema desde un punto de vista de seguridad. Da a conocer recomendaciones de donde, dentro del contexto general de la arquitectura del sistema, se deben colocar los mecanismos de seguridad. Proporciona una percepción de los servicios de seguridad, mecanismos, tecnologías y características que pueden ser usados para satisfacer requerimientos de seguridad del sistema.
Puntos a tomar en cuenta
La seguridad es un requerimiento desde un principio. Es otra característica que necesita ser incluida. Se enfoca en los servicios de seguridad del sistema
11
Mecanismos de alto nivel. Ubicación de funcionalidades relacionadas con seguridad Identificar interdependencias entre componentes relacionados con seguridad, servicios, mecanismos y tecnologías, y al mismo tiempo arreglar cualquier conflicto entre ellos.
La Triada de Seguridad
12
La Arquitectura de seguridad se diseña de manera tal que las metas de C-I-D de la seguridad de información puedan converger las necesidades de la seguridad y el negocio de la organización.
INFORMACION
Entornos de protección de la Información
13
Entornos de protección de la Información
La Arquitectura de seguridad incluye varias arquitecturas subsidiarias:
14
Arquitectura de la plataforma (SW y HW) Arquitectura de la Red Arquitectura de la Empresa Etc.
Arquitectura de la plataforma: Accesos a Memoria
15
Las Aplicaciones y los procesos que ellas utilizan, solo acceden a sus propios segmentos de memoria.
Separación de procesos en anillos de confianza
16
Ring 0: Kernel del SO Ring 1: Partes restantes del SO Ring 2: Drivers I/O Ring 3: Aplicaciones y programas
Arquitectura de Sistema 3.
1.
17
La protección puede suceder en el lado del Usuario.
La protección puede controlar las operaciones entre el Usuario y la Data.
2.
La protección puede suceder en el lado de los Datos.
Arquitectura de Sistema
A medida que la funcionalidad aumenta, se incrementa la complejidad y la garantía de seguridad decrece. Funcionalidad
Seguridad 18
Usabilidad
a l y n a e t a n t . e n d m e a u m d j a u i e l a d p a d d a m i l d o i a r c n u o g i c e n s u F
Aplicaciones Servicios Sistema Operativo
Kernel
F u s n e c i g o u n r i a c d l i o a d m d a p d d l s i d e j i i d m s m a i n d u i . y n e u y e e n y l a
Capa de Hardware
Garantía de los mecanismos de seguridad disminuyen a medida que la complejidad
Arquitectura de la Plataforma
19
Arquitectura de la Empresa
20
Modelos de Seguridad
21
¿Qué es un Modelo de Seguridad?
22
Un Modelo de Seguridad es una descripción formal de una Política de Seguridad. Las políticas son descripciones de cómo implementar la seguridad.
Política de Seguridad
Especifica las características de seguridad que un sistema debe observar y proveer
23
conjunto de reglas que deben respetarse para mantener la seguridad de la información.
Especifica las amenazas contra las que la organización debe protegerse y cómo debe protegerse Depende de los objetivos y metas de la organización. Generalmente es expresada en un lenguaje no técnico. Típicamente establecida en términos de sujetos y objetos.
Paradigmas
Paranoico: Nada está permitido.
Prudente: Lo que no está expresamente
permitido, está prohibido.
Permisivo: Lo que no está expresamente
prohibido, está permitido.
24
Promiscuo: Todo está permitido.
Tipos políticas de seguridad
Políticas administrativas.
Políticas de control de acceso.
Procedimientos administrativos. Privilegios de acceso del usuario o programa. Política de menor privilegio.
Políticas de flujo de información.
Normas bajo las cuales se comunican los sujetos dentro del sistema. La información a la que se accede, se envía y recibe por:
¿Qué es lo que hay que potenciar?
25
¿Canales claros o canales ocultos? ¿Seguros o no? ¿La confidencialidad o la integridad? ¿La disponibilidad?
Principios de escritura de una Política
26
Basado en riesgos Propósito claro del enunciado Nivel de detalle consistente Neutralidad tecnológica Describir el qué, no el cómo Apoyarse en políticas existentes
Ejemplo de Política (en lenguaje natural)
27
Sólo se permitirá el intercambio de correo electrónico con redes de confianza. Toda adquisición de software a través de la red debe ser autorizada por el administrador de seguridad. Debe impedirse la inicialización de los equipos mediante disco.
¿Qué es un Modelo de Seguridad?
28
Un Modelo de Seguridad es una descripción formal de una Política de Seguridad.
Modelos de Seguridad
29
Bell-LaPadula Biba Clark & W ilson No-interferencia Máquinas de estados Matriz de accesos Flujo de información Brewer & Nash (Muralla China)
Modelo Bell-LaPadula
30
Modelo basado en máquinas de estado. Fue desarrollado para formalizar la Política de Múltiples Niveles del Departamento de Defensa (DoD) de los Estados Unidos. Permite capturar los conceptos de confidencialidad en el Control de Acceso. Una persona que recibe CLEARANCE a Secreto puede obtener acceso a información de ese nivel o inferior. Este modelo sólo Confidencialidad.
ve
los
aspectos
de
Modelo Bell-LaPadula
Este modelo define un estado seguro a través de tres propiedades de múltiples niveles. Las dos primeras reglas definen Acceso Mandatorio, la tercera permite Acceso Discreto. Las tres reglas son:
31
Simple Security Property (ss Property): esta regla define que ningún nivel inferior puede acceder a un nivel superior. Esto se conoce como la regla “no read up” La regla * ( star) establece que un sujeto de un nivel más alto no puede escribir a un nivel más bajo “no write down” Discretionary Security Property: esta permite el uso de una matriz de acceso para especificar control de acceso discreto.
Modelo Bell-LaPadula
32
Modelo Bell-LaPadula
33
Modelo Bell-LaPadula
Esta sola falencias
34
aproximación
presenta
algunas
No están considerados los Canales ocultos. Este modelo no es válido en sistemas de redes donde se comparten archivos. El modelo no especifica claramente qué se considera una transición segura. Solo se considera la política de múltiples niveles, pero no considera otras políticas que podrían ser exigidas por la empresa o institución.
Modelo Biba
35
Modelo centrado en la Integridad de la Información. Ocupa control de acceso mandatorio. Al igual que Bell-LaPadula, fue creado por el Gobierno Norteamericano para ser usado en sus sistemas. Esta basado en el modelo de las máquinas de estado. Se debe tener en cuenta que este modelo solo se preocupa de la Integridad de la Información. Se definen niveles de Integridad análogos a los de confidencialidad. El criterio es asignar niveles de credibilidad a los sujetos.
Modelo Biba
36
Modelo Biba
37
Modelo Clark-Wilson
Fue publicado en 1987 por David Clark y David Wilson. Se enfoca en las actividades autorizadas de los usuarios autorizados y de las amenazas internas a la integridad. Este modelo hace la pregunta ¿el Software hace lo que debería hacer? Cumple con las tres metas de la integridad:
38
Previene que usuarios no autorizados modificaciones a objetos. Previene que usuarios autorizados modificaciones impropias a objetos. Mantiene la consistencia interna y externa.
efectúen efectúen
Modelo Clark-Wilson
Define transacciones bien definidas:
Separación de Tareas:
39
Preserva/asegura la consistencia interna Los usuarios pueden manipular la data solo de forma que se asegure la consistencia interna Las operaciones están divididas en sub-partes Cada parte es ejecutada por una entidad distinta Se asegura la consistencia externa
Modelo Clark-Wilson
40
Modelo Matriz de Acceso
41
Se definen Sujetos, Objetos y permisos. Las interacciones se implementan a través de una Matriz.
Modelo Flujo de Información
42
Este modelo ilustra la dirección del flujo de los datos entre los objetos. Basado en niveles de seguridad de los objetos El flujo de información Objeto-Objeto esta contenido en concordancia con los atributos de seguridad del objeto
Modelo Brewer & Nash (Gran Muralla China)
43
Los modelos anteriores habían sido desarrollados para ser implementados en ambientes militares. Chinese Wall es creada en 1989 como una política para ser ocupada por el ambiente comercial. Los principios que la guían se basan en la definición de acceso a datos por sujetos u objetos que no tengan conflictos de intereses.
Modelo Brewer & Nash (Gran Muralla China)
Se definen tres niveles para catalogar los datos:
44
Nivel Bajo: Aquí se consideran partidas individuales de información, cada una concerniente a una sola corporación. Nivel Intermedio: Se agrupan todos los objetos pertenecientes a la misma corporación en algo que se llama conjunto de datos de la Compañía. Nivel Alto: Aquí se agrupan todos los conjuntos de datos de las compañías cuyas corporaciones están en competencia; a dichas agrupaciones se les llama clases de Conflicto de Interés .
Modelo Brewer & Nash (Gran Muralla China)
45
El modelo se basa en la libertad de un sujeto de acceder a un tipo de información. Su decisión le auto limita los datos en base a los conflictos de intereses que este grupo tiene. El sujeto puede tener acceso a más de un conjunto de datos de la Compañía en la medida que no hayan conflictos de intereses.
Modelo Brewer & Nash (Gran Muralla China)
46
Para asegurar la consistencia del modelo, se deben analizar los datos, indicándose sus conflictos de intereses. Mientras esto no ocurra, los datos “no revisados” son confinados a su propio conjunto de datos. Una vez que ha sido revisada y los conflictos especificados, entonces la información puede fluir libremente por el sistema.
Modelo Brewer & Nash (Gran Muralla China)
Ejemplo: Si un asesor económico de una empresa tiene acceso a la cuenta de la radio FM “Infinita”, no puede tener acceso a información de otras radios, pero si podría tener acceso a la cuenta del Banco BCI.
47
Modelo Brewer & Nash (Gran Muralla China)
48
Modelo Brewer & Nash (Gran Muralla China)
49
Este tipo de modelos no es fácilmente comparable con modelos como Biba o Bell-LaPadula. Lo interesante es que en ambientes militares se limita el acceso a niveles bien definidos, pero no se ven los conflictos de intereses ya que comúnmente estos no existen. Es por lo anterior que este tipo de modelos son importantes en ambientes más competitivos donde las empresas si presentan conflictos de intereses.
Algunas críticas a los modelos
50
Los modelos permiten una aproximación formal a las políticas de seguridad. Los modelos permiten formarnos sólidos conceptos de la forma de asegurar el “control de acceso”. Las principales criticas se fundamentan en que están basados en estructuras estáticas. Lo que significa que no están hechos para sistemas dinámicos como las actuales empresas e instituciones. Por otro lado, no consideran aspectos tan importantes como las comunicaciones entre redes.
Algunas críticas a los modelos
Ninguno de los modelos consideran aspectos como:
51
Virus Troyanos Cortafuegos Detectores de intrusos Filtros de contenidos Etc.
Evaluación y Certificación
52
Evaluación y Certificación
53
Tan importante como es diseñar una arquitectura segura, lo es poder verificar si esa arquitectura es segura. Para el usuario es importante poder estar seguro que el producto que utiliza provee los requerimientos de seguridad necesarios. Para verificar lo anterior, se han desarrollado métodos que provean esta seguridad al usuario.
Certificaciones de organizaciones ISO 17799 / BS 7799 / UNE 71502 / NCH-ISO 27001 y 27002
54
Norma ISO 17799 / BS 7799 / UNE 71502 / NCH-ISO 27001 y 27002
Un conjunto de controles basados en las “ buenas prácticas” en seguridad de la información; Estándar internacional que cubre todos los aspectos de la seguridad informática:
55
Equipos Políticas de gestión Recursos humanos Aspectos jurídicos
ISO 17799
Una organización puede optar a implantar y "certificar" su sistema de gerencia en la gestión de integridad y seguridad en el manejo de información y datos.
La precursora de ISO 17799 es la adopción de la normativa británica BS 7799.
56
comprende de elementos y cláusulas enfocados a prácticas y métodos fundamentales de seguridad
La BS 7799 se publicó en febrero del 1995 y se revisó en mayo del 1999. Esta normativa aplica invariablemente a organizaciones pequeñas, medianas y multinacionales. Desde finales de 2005 estas normas se están revisando y cambiando de numeración a partir del número 27001.
Áreas control ISO 17799
57
Política de Seguridad Organización de Seguridad Clasificación y Control de Activos Aspectos humanos de la seguridad Seguridad Física y Ambiental Gestión de Comunicaciones y Operaciones Sistema de Control de Accesos Desarrollo y Mantenimiento de Sistemas Plan de Continuidad del Negocio Cumplimiento
La Serie 27000
La seguridad de la información tiene asignada la serie 27000 dentro de los estándares ISO/IEC: ISO 27000: Publicada en mayo de 2009. Contiene la descripción general y vocabulario a ser empleado en toda la serie 27000. Se puede utilizar para tener un entendimiento más claro de la serie y la relación entre los diferentes documentos que la conforman. ISO 27001:2007 “Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos”. Fecha de la de la versión española 29 noviembre de 2007. Es la norma principal de requisitos de un Sistema de Gestión de Seguridad de la Información. Los SGSIs deberán ser certificados por auditores externos a las organizaciones. En su Anexo A, contempla una lista con los objetivos de control y controles que desarrolla la ISO 27002 (anteriormente denominada ISO17799). ISO 27002: (anteriormente denominada ISO17799).Guía de buenas prácticas que describe los objetivos de control y controles recomendables en cuanto a seguridad de la información con 11 dominios, 39 objetivos de control y 133 controles. ISO 27003: En fase de desarrollo. Contendrá una guía de implementación de SGSI e información acerca del uso del modelo PDCA y de los requisitos de sus diferentes fases. Tiene su origen en el anexo B de la norma BS 7799-2 y en la serie de documentos publicados por BSI a lo largo de los años con recomendaciones y guías de implantación. ISO 27004: Publicada en diciembre de 2009. Especifica las métricas y las técnicas de medida aplicables para determinar la eficiencia y eficacia de la implantación de un SGSI y de los controles relacionados. ISO 27005: Publicada en junio de 2008. Consiste en una guía para la gestión del riesgo de la seguridad de la información y sirve, por tanto, de apoyo a la ISO 27001 y a la implantación de un SGSI. Incluye partes de la ISO 13335. ISO 27006: Publicada en febrero de 2007. Especifica los requisitos para acreditación de entidades de auditoría y certificación de sistemas de gestión de seguridad de la información
58
La ISO 27001
Anunciada como el reemplazo del BS7799 Aprobada y publicada como estándar internacional en octubre de 2005. Publicación hermana del ISO 17799 ISO 17799 es un código de prácticas
individuales para posibles
BS7799-2 es la parte del estándar contra la cual se otorga la certificación
59
describe controles implementaciones
esto se pasó a la ISO 27001
Norma chilena 2777
60
Esta basada y es equivalente a la norma ISO 17799, la que a su vez es equivalente a la BS 7799.
Nch 2777
61
Capítulo Capítulo Capítulo Capítulo Capítulo Capítulo
3 4 5 6 7 8
: Políticas de Seguridad : Seguridad Organizacional : Clasificación y Control de un bien : Seguridad del Personal : Seguridad Física y del Ambiente : Gestión de las Operaciones y de las Comunicaciones Capítulo 9 : Control de Acceso Capítulo 10 : Desarrollos de Sistemas y Mantenimiento Capítulo 11 : Gestión de la Continuidad Comercial Capítulo 12 : Cumplimiento
Normas Chilenas
Norma Chilena Oficial NCH-ISO 27002.Of2009:
ISO/IEC
Norma Chilena Oficial NCH-ISO 27001.Of2009:
62
Listado de Mejores Practicas Internacionalmente homologada de 27002:2005 Antes Norma Chilena NCh2777.Of2003
Sistema de gestión de la seguridad de la Información / SGSI Information Security management system / ISMS Internacionalmente homologada de ISO/IEC 27001:2005
Legislación Chilena
Leyes :
19.628: 1999, sobre protección de la vida privada.
19.799: 2002, sobre documentos electrónicos, firma electrónica y servicios de
DS:
63
certificación de dicha firma. 20.453: 2010, consagra el principio de neutralidad en la red para los consumidores y usuarios de internet. 20.478:2010, sobre recuperación y continuidad en condiciones críticas y de emergencia del sistema público de telecomunicaciones. 20.500:2011,sobre asociaciones y participación ciudadana en la gestión pública.
77:2004, aprueba norma técnica sobre eficiencia de las comunicaciones electrónicas
entre órganos de la administración del estado y entre estos y los ciudadanos. 81:2004, aprueba norma técnica para los órganos de la administración del estado sobre interoperabilidadde documentos electrónicos. 83:2004, aprueba norma técnica para los órganos de la administración del estado sobre seguridad y confidencialidad de los documentos electrónicos.
La certificación de productos TCSEC, ITSEC, CTCPEC, CC
64
Trusted Computer System Evaluation Criteria (TCSEC)
65
Documento publicado por el Departamento de Defensa de los Estados Unidos en 1983 (DOD 5200.28-STD) conocido también como el “Orange Book.” Actualizado en 1985. Página (Rainbow Series Library) http://www.radium.ncsc.mil/tpe p/library/rainbow/
Objetivos TCSEC
66
Proporcionar una guía a los fabricantes de productos comerciales en relación a las características de seguridad que deben cumplir sus productos.
Dotar al DoD de los Estados Unidos con una métrica para evaluar el grado de confiabilidad de los sistemas orientados a manejar información clasificada. Proporcionar una base a los usuarios finales para establecer requerimientos de seguridad en sus adquisiciones de productos.
Trusted Computer System Evaluation Criteria (TCSEC)
67
Se preocupa fundamentalmente del mantenimiento de la confidencialidad de la información clasificada a nivel nacional. Definen siete conjuntos de criterios de evaluación denominados clases (D, C1, C2, B1, B2, B3 y A1). Cada clase de criterios cubre cuatro aspectos de la evaluación: política de seguridad, imputabilidad, aseguramiento y documentación.
Criterios y niveles
68
Los niveles Nivel
D C1
Protección mínima. Sin seguridad. Limitaciones de accesos a datos.
C2
Acceso controlado al SI. Archivos de log y de auditoría del sistema.
B1
Equivalente al nivel C2 pero con una mayor protección individual para cada archivo. Los sistemas deben estar diseñados para ser resistentes al acceso de personas no autorizadas. Dominios de seguridad. Los sistemas deben estar diseñados para ser altamente resistentes a la entrada de personas no autorizadas. Protección verificada. En la práctica, es lo mismo que el nivel B3, pero la seguridad debe estar definida en la fase de análisis del sistema.
B2 B3 A1
69
Descripción
Estándares creados a partir del TCSEC
ITSEC
CTCPEC
70
Information Technology Security Evaluation Criteria http://www.cordis.lu/infosec/src/crit.htm la versión europea
Canadian Trusted Computer Product Evaluation Criteria ftp://ftp.cse.dnd.ca/pub/criteria/CTCPEC.ascii la versión canadiense
Information Technology Security Evaluation Criteria (ITSEC)
71
Surge de la armonización de varios sistemas europeos de criterios de seguridad en TI. Tiene un enfoque más amplio que TCSEC. Los criterios establecidos en ITSEC permiten seleccionar funciones de seguridad arbitrarias (objetivos de seguridad que el sistema bajo estudio debe cumplir teniendo presentes las leyes y reglamentaciones).
Information Technology Security Evaluation Criteria (ITSEC)
72
Se definen siete niveles de evaluación, denominados E0 a E6, que representan una confianza para alcanzar la meta u objetivo de seguridad. E0 representa una confianza inadecuada. E1, el punto de entrada por debajo del cual no cabe la confianza útil, y E6 el nivel de confianza más elevado. Por ello, los presentes criterios pueden aplicarse a una gama de posibles sistemas y productos más amplia que los del TCSEC. El objetivo del proceso de evaluación es permitir al evaluador la preparación de un informe imparcial en el que se indique si el sistema bajo estudio satisface o no su meta de seguridad al nivel de confianza precisado por el nivel de evaluación indicado.
Evolución de la Norma
73
Common Criteria (CC) (ISO/IEC 15408)
Iniciativa de varios países Flexible
Parte de las necesidades de cada usuario/fabricante
74
No cuenta con perfiles predeterminados. Permite la adición de nuevos criterios. No de las necesidades del DoD.
Cada nueva evaluación implica la creación de un modelo o marco de referencia (Security Target o ST). Al igual que en el Orange Book la evaluación se enfoca a los componentes relevantes desde el punto de vista Seguridad (Target of Evaluation o TOE).
Common Criteria (CC)
75
Tiene como finalidad el ser usado como base para la evaluación de las propiedades de seguridad de los productos y sistemas de Tecnologías de la Información (TI). Estableciendo esta base de criterios comunes, los resultados de una evaluación de seguridad de TI será significativa para una mayor audiencia. Los CC permitirán la comparación entre los resultados de evaluaciones de seguridad independientes, al proporcionar un conjunto común de requisitos para las funciones de seguridad de los productos y sistemas de TI y para las medidas de garantía aplicadas a éstos durante la evaluación de seguridad.
Common Criteria (CC)
76
El proceso de evaluación establece un nivel de confianza del grado en que las funciones de seguridad de tales productos y sistemas y las medidas de garantía aplicadas coinciden con aquellos requisitos. Los resultados de la evaluación pueden ayudar a los consumidores a determinar si el producto o sistema de TI es suficientemente seguro para la aplicación pretendida y si los riesgos de seguridad implícitos en su uso son aceptables.
Objetivos CC
77
Permitir a los usuarios el especificar sus requerimientos de seguridad. Permitir a los desarrolladores especificar los atributos de sus productos. Permitir que los evaluadores determinen si los productos cumple con lo que estipulan.
Tipos de Documentos CC
El CC define un conjunto de requerimientos de seguridad
dividido en requerimientos funcionales y de seguridad
•Dos tipos de documentos
Protection Profiles (PPs): documento creado por un usuario o comunidad de usuarios que identifica requerimientos de seguridad por parte del usuario. Security Targets (STs): documento creado por un desarrollador de sistema, que identifica las capacidades de un producto en particular
78
Un ST puede indicar la implementación de cero o más PPs
Los niveles del CC (EAL)
Usuario puede contar con una evaluación independiente que compruebe que el producto cumple con lo estipulado en el ST
EAL: Evaluation Assurance Level
79
evaluación conocida como TOE -Target of Evaluation numeradas del 1 al 7 EALs superiores requieren de un mayor esfuerzo de evaluación los EAL de mayor valor garantizan más “seguridad”, pero su evaluación requiere de mayor tiempo y cuesta más dinero EAL valor grande no significa “mejor seguridad”, solo estipula que seguridad proclamada fue extensamente validada
Niveles CC Common Criteria
Referencia TCSEC
EAL1
Probado funcionalmente
EAL2
Estructuralmente probado
C1
EAL3
Metodológicamente probado
C2
EAL4
Metodológicamente diseñado, probado, y revisado Semiformalmente diseñado y probado Semiformalmente verificado (diseño) y probado Formalmente verificado (diseño) y probado
EAL5 EAL6 EAL7 80
Descripción
--
B1 B2 B3 A1
Certificaciones CC
81
Certificacioness CC Certificacione
82
http://www.commoncriteriaportal.org/products/
FIPS 140-2
Estándar de Seguridad de computadores del gobie ierrno de lo loss Estados Unidos para la acre acredit dita ación de mó módu dulo loss cript criptog ográf ráfiico coss (Security Requ Require ireme ment nts s for for Crypto Cryptogra graph phic ic Modu Modules) les)
83
La primera versión es del 2001 y la última actualizació actua lización n es de 2003. 2003. Defin De fine e cu cuat atrro niv ivel eles es de se segu gurrid idad ad,, lo loss cu cua ale less especifican el nivel de seguridad al que se ajusta el producto producto bajo pruebas. pruebas.
FIPS 140-2: Niveles
84
Nivel 1: normalmente se utiliza en produ pro ductos ctos de cifrado de software software
exclusivamente e impone requisitos de seguridad muy limitados. Nivel 2: requier requiere e au a ute ten ntica ticación ción basada basada en el cargo del usuario. usuario. (No se requiere la autenticación individual de los usuarios). También requiere la capacidad para detectar la intrusión física mediante sistemas de bloqueo físico. Nivel 3: aña ñade de resi resist sten enci cia a a la in intru trusi sión ón fís físic ica a con fin fine es de desmontaje o modificación, de manera que dificulta al máximo los ataques. ataques. Si se detecta d etecta la intrusión, intrusión, el dispositivo debe ser capaz de borrar los parámetros de seguridad críticos. El Nivel 3 también incluye protección criptográfica eficaz y administración de claves, autenticación basada en la identidad y separación física o lógica entre en tre las l as interfaces a través través de las las qu q ue se accede a los parámetros parámetros de segu seguridad ridad crítica y se sale sale de ellos. ellos. Nivel 4: incluye protección avanzada contra intrusiones y está diseñado para productos que operan en entornos desprotegidos físicamente.
FIPS 140-2: Niveles
85
FIPS 140-2
86
