fbpx
Wikipedia

Los criterios comunes

Los (CC) tienen su origen en 1990 y surgen como resultado de la armonización de los criterios sobre seguridad de productos software ya utilizados por diferentes países con el fin de que el resultado del proceso de evaluación pudiese ser aceptado en múltiples países. Los CC permiten comparar los resultados entre evaluaciones de productos independientes. Para ello, se proporcionan un conjunto común de requisitos funcionales para los productos de TI (Tecnologías de la Información). Estos productos pueden ser hardware, software o firmware. El proceso de evaluación establece un nivel de confianza en el grado en el que el producto TI satisface la funcionalidad de seguridad de estos productos y ha superado las medidas de evaluación aplicadas. Los CC son útiles como guía para el desarrollo, evaluación o adquisición de productos TI que incluyan alguna función de seguridad. La lista de productos certificados según los CC se encuentra disponible en la .

Historia

El origen de los Criterios Comunes podemos encontrarlo en los criterios usados por diferentes países para la evaluación de la seguridad de los productos software desarrollados. Los CC combinan criterios de los: - TCSEC (del inglés Trusted Computer System Evaluation Criteria) frecuentemente conocido como “Libro Naranja” y usados por el Departamento de Defensa de EE. UU. - ITSEC (del inglés Information Technology Security Evaluation Criteria) comúnmente conocido como “Libro Blanco” y utilizados en Europa, y; - CTCPEC (del inglés Canadian Trusted Computer Product Evaluation Criteria) utilizados en Canadá. En 1999 los Criterios Comunes en su versión 2.0 fueron adoptados por la International Organization for Standardization (ISO) como estándar internacional. En la actualidad los CC se encuentran estandarizados bajo la serie de normas ISO/IEC 15408 (ISO/IEC 15408-1,2009), (ISO/IEC 15408-2,2008) y (ISO/IEC 15408-3,2008) aunque la última versión se encuentra disponible en la .

Funcionamiento

Con el fin de poder certificar un producto según los Criterios Comunes se deben comprobar, por parte de uno de los laboratorios independientes aprobados, numerosos parámetros de seguridad que han sido consensuados y aceptados por 22 países de todo el mundo. El proceso de evaluación incluye la certificación de que un producto software específico verifica los siguientes aspectos:

  • Los requisitos del producto están definidos correctamente.
  • Los requisitos están implementados correctamente.
  • El proceso de desarrollo y documentación del producto cumple con ciertos requisitos previamente establecidos.

Los Criterios Comunes establecen entonces un conjunto de requisitos para definir las funciones de seguridad de los productos y sistemas de Tecnologías de la Información y de los criterios para evaluar su seguridad. El proceso de evaluación, realizado según lo prescrito en los Criterios Comunes, garantiza que las funciones de seguridad de tales productos y sistemas reúnen los requisitos declarados. Así, los clientes pueden especificar la funcionalidad de seguridad de un producto en términos de perfiles de protección estándares y de forma independiente seleccionar el nivel de confianza en la evaluación de un conjunto definido desde el EAL1 al EAL7.

Perfiles de Protección

Un perfil de protección (Protection Profile) define un conjunto de objetivos y requisitos de seguridad, independiente de la implantación, para un dominio o categoría de productos que cubre las necesidades de seguridad comunes a varios usuarios. Los perfiles de protección son reutilizables y normalmente públicos y están compuestos de:

  • Requisitos funcionales (SFR, Security Funcional Requirement) proporcionan mecanismos para hacer cumplir la política de seguridad. Como ejemplos de requisitos funcionales mencionar la protección de datos de usuario, el soporte criptográfico, la autenticación, la privacidad o el control de acceso.
  • Requisitos de confianza o aseguramiento (SAR, Security Assurance Requirement) proporcionan la base para la confianza en que un producto verifica sus objetivos de seguridad.

Los requisitos de confianza se han agrupado en niveles de confianza en la evaluación (EAL, Evaluation Assurance Levels) que contienen requisitos de confianza construidos específicamente en cada nivel. Los EALs proporcionan una escala incremental que equilibra el nivel de confianza obtenido con el coste y la viabilidad de adquisición de ese grado de confianza. El incremento de confianza de un EAL a otro se obtiene incrementando rigor, alcance y/o profundidad en el componente y añadiendo componentes de confianza de otras familias de confianza (por ejemplo, añadiendo nuevos requisitos funcionales). Una lista de los perfiles de protección validados se puede encontrar en

Niveles de confianza

Los niveles de confianza en la evaluación definidos en el ISO/IEC 15408-3 [ISO 15408-3 2005] van desde EAL1 (el menor) a EAL 7 (el mayor) y se definen de forma acumulativa (verificaciones de nivel n+1 implican realizar las de nivel n, 1 ≤ n ≤ 7):

  • EAL1 (funcionalidad probada): es aplicable donde se requiere tener cierta confianza de la operación correcta, y donde además, las amenazas a la seguridad no son vistas como serias. Una evaluación en este nivel debe proporcionar evidencia de que las funciones del objeto de evaluación son consistentes con su documentación, y que proporcionan protección útil contra amenazas identificadas.
  • EAL2 (estructuralmente probado): requiere la cooperación del desarrollador en términos de la distribución de la información del diseño, y los resultados de las pruebas y proporciona confianza a través de un análisis de las funciones de seguridad, usando una especificación funcional y de interfaz, manuales y diseño de alto nivel del producto para entender el comportamiento de seguridad. Además, en este nivel se verifica que el desarrollador realizó un análisis de vulnerabilidades a través de la ejecución de pruebas de caja negra (black-box).
  • EAL3 (probado y verificado metódicamente): permite a un desarrollador alcanzar una máxima garantía de ingeniería de seguridad positiva en el estado de diseño sin la alteración substancial de prácticas de desarrollo válidas existentes. El análisis en este nivel se apoya en las pruebas de caja gris (grey box), la confirmación selectiva independiente de los resultados de las pruebas del desarrollador, y la evidencia de búsqueda de vulnerabilidades obvias del desarrollador. Además, se realizan controles del entorno de desarrollo y de gestión de configuración del producto.
  • EAL4 (diseñado, probado y revisado metódicamente): este nivel le permite a un desarrollador alcanzar máxima garantía de ingeniería de seguridad positiva basada en buenas prácticas de desarrollo comercial, las cuales, aunque rigurosas, no requieren del conocimiento especializado substancial, destreza, ni otros recursos. En este caso, el análisis se apoya en el diseño de bajo nivel de los módulos del producto y se realiza búsqueda de vulnerabilidades independiente de las pruebas realizadas por el desarrollador. Los controles de desarrollo se apoyan en un modelo de ciclo de vida de desarrollo, identificación de las herramientas utilizadas y gestión de configuración automatizada.
  • EAL5 (diseñado y probado semiformalmente): permite a un desarrollador alcanzar máxima garantía de ingeniería de seguridad positiva mediante la aplicación moderada de técnicas de ingeniería de seguridad. La confianza se apoya, en este caso, en un modelo formal y una presentación semiformal de la especificación funcional y el diseño de alto nivel. La búsqueda de vulnerabilidades debe asegurar la resistencia relativa a los ataques de penetración.
  • EAL6 (diseño verificado y probado semiformalmente): permite a los desarrolladores alcanzar una alta garantía en la aplicación de técnicas de ingeniería de seguridad para un entorno de desarrollo riguroso y donde el objeto de evaluación es considerado de gran valor para la protección del alto costo o estimación de esos bienes contra riesgos significativos. Además, es aplicable para el desarrollo de objetos de evaluación, destinados a salvaguardar la seguridad informática en situaciones de alto riesgo donde el valor de los bienes protegidos justifica los costos adicionales. El análisis en este nivel se apoya en un diseño modular y en una presentación estructurada de la implementación del producto. La búsqueda de vulnerabilidades debe mostrar una alta resistencia a los ataques de penetración.
  • EAL7 (diseño verificado y probado formalmente): es aplicable al desarrollo de objetos de evaluación de seguridad, para su aplicación en situaciones de muy alto riesgo o donde el alto valor de los bienes justifica los más altos costos. La aplicación práctica del nivel EAL7 está limitada actualmente a objetos de evaluación con seguridad estrechamente enfocada a la funcionalidad, y que es sensible al análisis formal y extenso. Este EAL representa un incremento significativo respecto a la garantía de nivel EAL6 a través del requisito de análisis de gran amplitud, mediante representaciones formales y correspondencia formal y pruebas de gran amplitud. Además, el evaluador confirmará de forma independiente y completa los resultados de las pruebas de caja blanca (White-box) realizadas por el desarrollador.

Los niveles EAL 5 al 7 incluyen modelos y demostraciones semi-formales y formales por tanto, se aplican a productos con objetivos de seguridad muy específicos (entorno militar, por ejemplo). Por otra parte, estos niveles requieren de la generación de una gran cantidad de documentación durante el proceso de desarrollo que debe entregarse al evaluador para que éste pueda confirmar la información. Finalmente, para la aplicación de los Criterios Comunes, existe una metodología con los criterios a evaluar para cada uno de los niveles de confianza estandarizada por la Norma ISO/IEC 18045 (ISO 18045, 2008) y denominada CEM (Common Methodology for IT Security Evaluation) disponible en la

Enlaces externos

  • Organismo de Certificación. Esquema Nacional de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información. España

Referencias

  • ISO/IEC 15408-1: 2005. Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model.
  • ISO/IEC 15408-2: 2008. Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional requirements.
  • ISO/IEC 15408-3: 2008. Information technology - Security techniques - Evaluation criteria for IT security -- Part 3: Security assurance requirements.
  • ISO/IEC 18045: 2008. Information technology -- Security techniques - Methodology for Information Technology Security Evaluation.
  •   Datos: Q1116124

criterios, comunes, criterios, comunes, tienen, origen, 1990, surgen, como, resultado, armonización, criterios, sobre, seguridad, productos, software, utilizados, diferentes, países, resultado, proceso, evaluación, pudiese, aceptado, múltiples, países, permite. Los Criterios Comunes CC tienen su origen en 1990 y surgen como resultado de la armonizacion de los criterios sobre seguridad de productos software ya utilizados por diferentes paises con el fin de que el resultado del proceso de evaluacion pudiese ser aceptado en multiples paises Los CC permiten comparar los resultados entre evaluaciones de productos independientes Para ello se proporcionan un conjunto comun de requisitos funcionales para los productos de TI Tecnologias de la Informacion Estos productos pueden ser hardware software o firmware El proceso de evaluacion establece un nivel de confianza en el grado en el que el producto TI satisface la funcionalidad de seguridad de estos productos y ha superado las medidas de evaluacion aplicadas Los CC son utiles como guia para el desarrollo evaluacion o adquisicion de productos TI que incluyan alguna funcion de seguridad La lista de productos certificados segun los CC se encuentra disponible en la web de Common Criteria Indice 1 Historia 2 Funcionamiento 3 Perfiles de Proteccion 4 Niveles de confianza 5 Enlaces externos 6 ReferenciasHistoria EditarEl origen de los Criterios Comunes podemos encontrarlo en los criterios usados por diferentes paises para la evaluacion de la seguridad de los productos software desarrollados Los CC combinan criterios de los TCSEC del ingles Trusted Computer System Evaluation Criteria frecuentemente conocido como Libro Naranja y usados por el Departamento de Defensa de EE UU ITSEC del ingles Information Technology Security Evaluation Criteria comunmente conocido como Libro Blanco y utilizados en Europa y CTCPEC del ingles Canadian Trusted Computer Product Evaluation Criteria utilizados en Canada En 1999 los Criterios Comunes en su version 2 0 fueron adoptados por la International Organization for Standardization ISO como estandar internacional En la actualidad los CC se encuentran estandarizados bajo la serie de normas ISO IEC 15408 ISO IEC 15408 1 2009 ISO IEC 15408 2 2008 y ISO IEC 15408 3 2008 aunque la ultima version se encuentra disponible en la web del Common Criteria Funcionamiento EditarCon el fin de poder certificar un producto segun los Criterios Comunes se deben comprobar por parte de uno de los laboratorios independientes aprobados numerosos parametros de seguridad que han sido consensuados y aceptados por 22 paises de todo el mundo El proceso de evaluacion incluye la certificacion de que un producto software especifico verifica los siguientes aspectos Los requisitos del producto estan definidos correctamente Los requisitos estan implementados correctamente El proceso de desarrollo y documentacion del producto cumple con ciertos requisitos previamente establecidos Los Criterios Comunes establecen entonces un conjunto de requisitos para definir las funciones de seguridad de los productos y sistemas de Tecnologias de la Informacion y de los criterios para evaluar su seguridad El proceso de evaluacion realizado segun lo prescrito en los Criterios Comunes garantiza que las funciones de seguridad de tales productos y sistemas reunen los requisitos declarados Asi los clientes pueden especificar la funcionalidad de seguridad de un producto en terminos de perfiles de proteccion estandares y de forma independiente seleccionar el nivel de confianza en la evaluacion de un conjunto definido desde el EAL1 al EAL7 Perfiles de Proteccion EditarUn perfil de proteccion Protection Profile define un conjunto de objetivos y requisitos de seguridad independiente de la implantacion para un dominio o categoria de productos que cubre las necesidades de seguridad comunes a varios usuarios Los perfiles de proteccion son reutilizables y normalmente publicos y estan compuestos de Requisitos funcionales SFR Security Funcional Requirement proporcionan mecanismos para hacer cumplir la politica de seguridad Como ejemplos de requisitos funcionales mencionar la proteccion de datos de usuario el soporte criptografico la autenticacion la privacidad o el control de acceso Requisitos de confianza o aseguramiento SAR Security Assurance Requirement proporcionan la base para la confianza en que un producto verifica sus objetivos de seguridad Los requisitos de confianza se han agrupado en niveles de confianza en la evaluacion EAL Evaluation Assurance Levels que contienen requisitos de confianza construidos especificamente en cada nivel Los EALs proporcionan una escala incremental que equilibra el nivel de confianza obtenido con el coste y la viabilidad de adquisicion de ese grado de confianza El incremento de confianza de un EAL a otro se obtiene incrementando rigor alcance y o profundidad en el componente y anadiendo componentes de confianza de otras familias de confianza por ejemplo anadiendo nuevos requisitos funcionales Una lista de los perfiles de proteccion validados se puede encontrar en 1 Niveles de confianza EditarLos niveles de confianza en la evaluacion definidos en el ISO IEC 15408 3 ISO 15408 3 2005 van desde EAL1 el menor a EAL 7 el mayor y se definen de forma acumulativa verificaciones de nivel n 1 implican realizar las de nivel n 1 n 7 EAL1 funcionalidad probada es aplicable donde se requiere tener cierta confianza de la operacion correcta y donde ademas las amenazas a la seguridad no son vistas como serias Una evaluacion en este nivel debe proporcionar evidencia de que las funciones del objeto de evaluacion son consistentes con su documentacion y que proporcionan proteccion util contra amenazas identificadas EAL2 estructuralmente probado requiere la cooperacion del desarrollador en terminos de la distribucion de la informacion del diseno y los resultados de las pruebas y proporciona confianza a traves de un analisis de las funciones de seguridad usando una especificacion funcional y de interfaz manuales y diseno de alto nivel del producto para entender el comportamiento de seguridad Ademas en este nivel se verifica que el desarrollador realizo un analisis de vulnerabilidades a traves de la ejecucion de pruebas de caja negra black box EAL3 probado y verificado metodicamente permite a un desarrollador alcanzar una maxima garantia de ingenieria de seguridad positiva en el estado de diseno sin la alteracion substancial de practicas de desarrollo validas existentes El analisis en este nivel se apoya en las pruebas de caja gris grey box la confirmacion selectiva independiente de los resultados de las pruebas del desarrollador y la evidencia de busqueda de vulnerabilidades obvias del desarrollador Ademas se realizan controles del entorno de desarrollo y de gestion de configuracion del producto EAL4 disenado probado y revisado metodicamente este nivel le permite a un desarrollador alcanzar maxima garantia de ingenieria de seguridad positiva basada en buenas practicas de desarrollo comercial las cuales aunque rigurosas no requieren del conocimiento especializado substancial destreza ni otros recursos En este caso el analisis se apoya en el diseno de bajo nivel de los modulos del producto y se realiza busqueda de vulnerabilidades independiente de las pruebas realizadas por el desarrollador Los controles de desarrollo se apoyan en un modelo de ciclo de vida de desarrollo identificacion de las herramientas utilizadas y gestion de configuracion automatizada EAL5 disenado y probado semiformalmente permite a un desarrollador alcanzar maxima garantia de ingenieria de seguridad positiva mediante la aplicacion moderada de tecnicas de ingenieria de seguridad La confianza se apoya en este caso en un modelo formal y una presentacion semiformal de la especificacion funcional y el diseno de alto nivel La busqueda de vulnerabilidades debe asegurar la resistencia relativa a los ataques de penetracion EAL6 diseno verificado y probado semiformalmente permite a los desarrolladores alcanzar una alta garantia en la aplicacion de tecnicas de ingenieria de seguridad para un entorno de desarrollo riguroso y donde el objeto de evaluacion es considerado de gran valor para la proteccion del alto costo o estimacion de esos bienes contra riesgos significativos Ademas es aplicable para el desarrollo de objetos de evaluacion destinados a salvaguardar la seguridad informatica en situaciones de alto riesgo donde el valor de los bienes protegidos justifica los costos adicionales El analisis en este nivel se apoya en un diseno modular y en una presentacion estructurada de la implementacion del producto La busqueda de vulnerabilidades debe mostrar una alta resistencia a los ataques de penetracion EAL7 diseno verificado y probado formalmente es aplicable al desarrollo de objetos de evaluacion de seguridad para su aplicacion en situaciones de muy alto riesgo o donde el alto valor de los bienes justifica los mas altos costos La aplicacion practica del nivel EAL7 esta limitada actualmente a objetos de evaluacion con seguridad estrechamente enfocada a la funcionalidad y que es sensible al analisis formal y extenso Este EAL representa un incremento significativo respecto a la garantia de nivel EAL6 a traves del requisito de analisis de gran amplitud mediante representaciones formales y correspondencia formal y pruebas de gran amplitud Ademas el evaluador confirmara de forma independiente y completa los resultados de las pruebas de caja blanca White box realizadas por el desarrollador Los niveles EAL 5 al 7 incluyen modelos y demostraciones semi formales y formales por tanto se aplican a productos con objetivos de seguridad muy especificos entorno militar por ejemplo Por otra parte estos niveles requieren de la generacion de una gran cantidad de documentacion durante el proceso de desarrollo que debe entregarse al evaluador para que este pueda confirmar la informacion Finalmente para la aplicacion de los Criterios Comunes existe una metodologia con los criterios a evaluar para cada uno de los niveles de confianza estandarizada por la Norma ISO IEC 18045 ISO 18045 2008 y denominada CEM Common Methodology for IT Security Evaluation disponible en la web de Common CriteriaEnlaces externos EditarSitio web oficial de Common Criteria Organismo de Certificacion Esquema Nacional de Evaluacion y Certificacion de la Seguridad de las Tecnologias de la Informacion EspanaReferencias EditarISO IEC 15408 1 2005 Information technology Security techniques Evaluation criteria for IT security Part 1 Introduction and general model ISO IEC 15408 2 2008 Information technology Security techniques Evaluation criteria for IT security Part 2 Security functional requirements ISO IEC 15408 3 2008 Information technology Security techniques Evaluation criteria for IT security Part 3 Security assurance requirements ISO IEC 18045 2008 Information technology Security techniques Methodology for Information Technology Security Evaluation Datos Q1116124Obtenido de https es wikipedia org w index php title Los criterios comunes amp oldid 133454554, wikipedia, wiki, leyendo, leer, libro, biblioteca,

español

, española, descargar, gratis, descargar gratis, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, imagen, música, canción, película, libro, juego, juegos