Los Criterios Comunes (CC) son un conjunto de normas reconocidas internacionalmente ( ISO 15408) cuyo objetivo es evaluar de manera imparcial la seguridad de los sistemas y software informáticos. También llamado Common Criteria , este repositorio nació de una asociación entre Canadá, Estados Unidos y Europa. Gracias al marco ofrecido, los usuarios de tecnologías de la información podrán utilizar perfiles de protección para especificar los requisitos de seguridad funcional esperados y los evaluadores podrán verificar que los productos cumplen con el nivel de garantía requerido.
La implementación de los Criterios Comunes decididos por los signatarios de un acuerdo de reconocimiento mutuo facilita enormemente la aceptación de certificados de seguridad de tecnología de la información emitidos por uno de los países signatarios. El producto, certificado imparcialmente por una autoridad competente, se puede utilizar sin necesidad de una evaluación adicional.
Aunque tiene muchas ventajas, la aplicación de este estándar es costosa, difícil de entender para un no experto y, a menudo, complicada de implementar. Ésta es la razón por la que han surgido varios métodos de uso.
En 1983, luego en 1985, el NIST y la NSA publicaron el Libro Naranja . El propósito de este documento fue evaluar la capacidad de un sistema para defenderse de los ataques.
Al mismo tiempo, Europa se inspira en el TCSEC para definir en 1991 sus propios criterios de evaluación para el ITSEC . Completarán los vacíos en el análisis de riesgos.
En 1993, Canadá definió su propio estándar CTCPEC.
El certificado obtenido en un país es reconocido solo por los países signatarios del acuerdo de reconocimiento mutuo. En Europa, el acuerdo SOG-IS es válido.
En 1999, la ISO está en el origen de los Criterios Comunes. Esta organización reunirá a los diferentes estados para definir una norma (ISO 15408) reconocida por todos los estados que firmaron el acuerdo CC-MRA en mayo de 2000. Además de los 17 países signatarios, 9 países no signatarios reconocen estos certificados.
Los Criterios Comunes (CC) son una guía que sirve como referencia para el desarrollo y control de productos y sistemas de información que manejan información. El objetivo es la protección contra la divulgación, modificación y pérdida de uso no autorizadas. Las categorías de estos tres tipos de fallas se conocen comúnmente como confidencialidad, integridad y disponibilidad. Los CC tienen en cuenta los riesgos que emanan de actividades humanas (maliciosas o no) o no humanas.
Los productos controlados son los que recopilan, transportan y manipulan dicha información, a saber, las redes informáticas , los sistemas operativos , para sistemas distribuidos y aplicaciones. Se evaluará un sistema de acuerdo con el uso al que se dedica. Tendrá que cumplir con dos categorías de requisitos de seguridad: requisitos funcionales y de garantía.
Las necesidades de seguridad de los usuarios son requisitos para la disponibilidad , confidencialidad y autenticidad de la información personal. Los criterios comunes se aplican a tres categorías de usuarios:
Usuarios finales Los usuarios finales podrán determinar si un producto satisface sus necesidades al ver el resultado de la evaluación. Desarrolladores Los desarrolladores utilizan CC para identificar los requisitos de seguridad de su producto. Los evaluadores Los revisores encontrarán los criterios a utilizar para evaluar que un producto cumple con su objetivo de evaluación. El estándar describe las acciones a tomar, pero no los procedimientos a seguir.Los criterios comunes son objeto de tres documentos interrelacionados:
Introducción y modelo general Este documento define conceptos generales y presenta un modelo de evaluación general. También ofrece un glosario de términos y palabras clave utilizadas. Como tal, los siguientes tres acrónimos se utilizan regularmente: ESO TI significa "Tecnología de la información". También es conocido por el acrónimo IT, " Tecnología de la Información " en la literatura anglosajona. DEDO DEL PIE TOE es el acrónimo de " Target Of Evaluation ". El TOE es el objetivo de la evaluación. Es un producto o una TI evaluada con la documentación asociada destinada al administrador por un lado y al usuario por otro. TSF TSF es el acrónimo de " TOE Security Functions ". Designa todas las funciones de seguridad del TOE. Requisitos de seguridad funcional Es un catálogo de componentes de seguridad funcional clasificados en familias y clases. Requisitos de garantía de seguridad Este documento enumera los requisitos para el desarrollador y las tareas que debe realizar el evaluador.Los requisitos funcionales de seguridad se refieren únicamente a las especificaciones de la función de seguridad. Están agrupados en once clases, cada una de las cuales cubre un dominio. Cada clase se divide en familias. Cada familia contiene un conjunto de componentes que constituye un requisito de seguridad. Cada clase está designada por un nombre único cuya abreviatura consta de tres caracteres Fxx: F para la clase de requisito funcional y xx para identificar el nombre de la funcionalidad cubierta.
Clase de auditoría de seguridad FAU Divididos en 6 familias, cada una de las cuales agrupa de 1 a 4 componentes de seguridad:" La auditoría de seguridad implica el reconocimiento, registro, almacenamiento y análisis de información asociada con actividades relacionadas con la seguridad " .
Comunicaciones de clase C FCO Esta clase se ocupa del no repudio de las transmisiones y la recepción. En consecuencia, se divide en 2 familias; el primero se refiere a la transmisión, mientras que el segundo se refiere a la recepción. Clase de soporte criptográfico FCS Se relaciona con la seguridad de alto nivel que requiere el uso de funciones criptográficas . También está formado por 2 familias; uno relacionado con la gestión de claves, el otro relacionado con la generación de estas claves. Clase de protección de datos de usuario FDP Dividido en 8 familias divididas en cuatro grupos, se trata de la manipulación de los datos del usuario. Clase de identificación y autenticación FIA Esta clase está formada por 6 familias para identificar al usuario, autenticarlo y gestionar estos derechos de acceso. Clase de administración de seguridad FMT Permite, entre otras cosas, definir roles de seguridad. También se divide en 6 familias que tienen de 1 a 3 componentes. Clase de protección de la privacidad FPR Los requisitos de esta clase cubren la protección del individuo contra el descubrimiento o uso fraudulento de su identidad por otros. Clase de protección TOE FPT Su propósito es describir los requisitos de protección de las funciones de seguridad del TOE y ya no del usuario. Las familias que lo componen pueden aparecer como una duplicación de la clase FDP. Clase de uso de recursos de FRU Tres familias de requisitos relacionados con la disponibilidad de recursos componen esta clase: tolerancia a fallas, asignación de recursos y prioridad de servicios. Clase de acceso al objetivo de evaluación FTA Especifica los requisitos funcionales necesarios para controlar el establecimiento de una conexión de usuario. Por ejemplo, controle el número de sesiones, modifique los parámetros de acceso, muestre un historial de conexiones. Clase de ruta FTP y canales confiables se refiere a los caminos utilizados para establecer una comunicación segura entre el usuario y la tecnología de la información, pero también entre TI.El desarrollador podrá definir un paquete de componentes de esta lista de acuerdo con las funcionalidades de su producto. Como esta lista no es exhaustiva, se puede complementar según sea necesario. Así, para la certificación de su dispositivo biométrico para la detección de dedos falsos, SAFRAN ha incorporado la familia SPOD a la clase FPT. Para la certificación de este producto, SAFRAN también seleccionó componentes de las siguientes familias:
La lista de requisitos de seguro es la segunda lista de los Criterios Comunes. Identifica los puntos a verificar para que un producto alcance un cierto nivel de confianza en términos de vulnerabilidad . Cubre la validez de la documentación y el producto o sistema. Para el desarrollador, esta es una lista de pruebas que deberá proporcionar como parte de la evaluación. En cuanto al evaluador, podrá identificar las tareas a realizar para llevar a la certificación según los Criterios Comunes.
Esta lista también se compone de clases que cubren un tema. Estas clases se dividen en familias que agrupan componentes. Cada componente representa un nivel de evaluación más o menos avanzado de un punto específico. Se dividen en elementos de seguro. La denominación de las clases se realiza con tres caracteres Axx: Un seguro que denota seguido de dos letras para identificar el área cubierta.
Lista de clases;
Clase | Área cubierta |
---|---|
ADV | Desarrollo |
CO | Composición |
AGD | Documentación |
ALC | Ciclo de vida |
MONO | Evaluación del perfil de protección |
Plaza bursátil norteamericana | Evaluación de objetivos de seguridad |
COMIÓ | Pruebas |
AVA | Estimación de vulnerabilidad |
Cualquier certificado emitido tras la evaluación de acuerdo con los criterios comunes garantiza que el Sistema de Información evaluado cumple con un cierto nivel de seguridad. Esto equivale a una puntuación que va desde EAL 1 a EAL7 (nivel de garantía de la evaluación). Estos niveles están asociados con un paquete mínimo de requisitos de garantía. Hay siete niveles jerárquicos que determinarán el grado de confianza otorgado al producto evaluado.
Cada nivel contiene los requisitos del nivel anterior. Reflejan un equilibrio entre el nivel de seguridad obtenido y el costo de alcanzar ese nivel.
Nivel 1 el menos costoso y no requiere la participación del desarrollador. Afirma que el objetivo de la evaluación está funcionando de acuerdo con lo descrito en la documentación. Solo se cubren las amenazas identificadas en el dominio público. Nivel 2 requiere la participación del desarrollador para comunicar la información de las especificaciones y los resultados de las pruebas realizadas. Nivel 3 da fe de la búsqueda de vulnerabilidades obvias. Nivel 4 representa un buen compromiso entre seguridad y costes. No requiere ningún conocimiento o experiencia especializada. Responde a una vulnerabilidad relacionada con ataques elementales. Nivel 5 da fe de un análisis de las funciones de seguridad. Este análisis se basa en las especificaciones funcionales, las especificaciones completas de las interfaces, las guías y el diseño del TOE. Nivel 6 destinado a desarrollos TOE en entornos de alto riesgo. Nivel 7 nivel máximo hasta la fecha. Requiere una presentación formal de las especificaciones funcionales y un alto nivel de especificaciones. Perfiles de protecciónUn perfil de protección define un conjunto de requisitos de seguridad para una categoría de producto independientemente de la implementación. Por tanto, un cliente debe poder utilizar un perfil de protección para expresar su política de seguridad. La ventaja de un documento de este tipo es que es reutilizable. Es por ello que debe ser genérico y estructurado con los siguientes capítulos:
Solo los países signatarios del acuerdo de reconocimiento mutuo de acuerdo con los criterios comunes están autorizados a emitir certificados. También son ellos los que aceptarán que se les una un nuevo miembro. Por lo tanto la India se convirtió en el 17 º signatario en 2013.
Para ser imparcial, la evaluación de un producto de TI debe ser realizada por una entidad independiente. Los laboratorios responsables de las evaluaciones están acreditados por los organismos gubernamentales que representan a los países signatarios del acuerdo CCMRA.
En los Estados Unidos La NSA impulsa el programa gubernamental NIAP responsable de las necesidades de seguridad de los clientes y diseñadores de TI. Acredita los laboratorios de especialización denominados CCTL y valida los resultados de la evaluación emitiendo o no el certificado final. En Francia Por decreto, la Agencia Nacional de Seguridad de los Sistemas de Información (ANSSI) es nombrada la autoridad de certificación. Esta agencia tiene dos roles:País | Organización gubernamental |
---|---|
Australia | Dirección australiana de señales ASD |
Canadá | Esquema Canadiense de Evaluación y Certificación de Criterios Comunes CECS |
Francia | Agencia Nacional de Seguridad de los Sistemas de Información ANSSI |
Alemania | Bundesamt für Sicherheit in der Informationstechnik BSDI |
India | Esquema de certificación de criterios comunes de la India IC3S |
Italia | Organismo di Certificazione della Sicurezza Informatica OCSI |
Japón | Esquema de certificación y evaluación de seguridad de TI de Japón JISEC |
Malasia | CyberSecurity Malasia |
Países Bajos | NSCIB operado por |
Nueva Zelanda | Dirección de Señales de Defensa |
Noruega | SERTIT |
República de Corea | Centro de certificación de seguridad de TI (ITSCC) |
España | Organismo de Certificación de la Seguridad de las Tecnologías de la Información |
Suecia | Organismo sueco de certificación de seguridad de TI FMV / CSEC |
pavo | Sistema de certificación de criterios comunes de la institución de normalización turca TSE |
Inglaterra | Esquema de certificación y evaluación de seguridad de TI del Reino Unido |
Estados Unidos | Asociación Nacional de Aseguramiento de la Información NIAP |
La certificación se realiza en 3 etapas:
Solicitud de evaluaciónEl patrocinador solicita una evaluación de su agencia gubernamental responsable de las certificaciones. Es responsabilidad de la empresa:
El evaluador puede intervenir durante todo el diseño del producto. Deberá comprobar la pertinencia del libro de pruebas y el resultado de estas pruebas que realiza el patrocinador. Luego emite un informe de evaluación técnica de RTE que valida el nivel de garantía alcanzado.
CertificaciónLa autoridad de certificación se apoyará en el informe de evaluación técnica para emitir o no el certificado de evaluación de acuerdo con los criterios comunes.
Según Mellado y Taguchi, la implementación de la estrategia de seguridad en las primeras etapas del proceso de desarrollo vale la pena. Esto crea un sistema más robusto al reducir las vulnerabilidades de seguridad que se pueden encontrar en etapas posteriores de desarrollo. Lloyd dice que para la fabricación y comercialización de COTS , los costos crecientes y las limitaciones de tiempo están obligando a muchas organizaciones y al gobierno de los EE. UU. A integrar preocupaciones de seguridad en el desarrollo de sus aplicaciones. Kallberg dice que el reconocimiento mutuo de la norma teóricamente ahorra tiempo y dinero al eliminar las garantías redundantes.
Confianza del usuarioPara Mellado, muchos usuarios de SI no cuentan con los conocimientos y recursos para calificar el nivel de seguridad de los sistemas. El uso de CC como base para la evaluación de la seguridad brinda confianza a los usuarios. Según Sauveron, la certificación permite a los clientes comparar diferentes productos en el mercado de manera objetiva.
Ventaja competitiva de los fabricantesSauveron indica que la certificación es obligatoria en ciertos mercados (por ejemplo, bancos). Por tanto, el fabricante tiene acceso a mercados cerrados o especializados. Los fabricantes pueden utilizar la certificación como argumento de marketing para expandir su mercado.
Control de los riesgos de ataques nacionalesPara Sauveron, la certificación permite a los organismos de certificación gubernamentales garantizar que los productos utilizados en sus países estén controlados. Y que, por tanto, no existe mayor riesgo de ataques contra sus sistemas informáticos.
Según Mellado y Razzazi, en la mayoría de los proyectos de software, la seguridad se aborda cuando los sistemas ya están diseñados y puestos en marcha. Muy a menudo, la especificación de los requisitos de seguridad es demasiado sucinta. Los consumidores no pueden establecer de forma clara e inequívoca los requisitos de seguridad del producto. Los requisitos de seguridad a menudo se malinterpretan. La gestión de los requisitos de seguridad es un tema complejo para los desarrolladores. Muchos desarrolladores tienden a describir soluciones de diseño con respecto a los mecanismos de protección, en lugar de hacer proposiciones declarativas sobre el nivel de protección requerido.
Difícil y caroPara Razzazi, los CC dejan demasiado espacio para las ambigüedades y, a menudo, es difícil comprender con precisión el significado de los requisitos de seguridad. Shoichi indica que los criterios de CC son muy abstractos, es imposible tener una visión global. Es difícil definir completamente los requisitos desde cero. Según Keblawi, la experiencia muestra que los estándares prescritos son inflexibles e ignoran las consideraciones del mundo real. Para Taguchi, los métodos son muy complejos semánticamente y, por lo tanto, el costo de aprendizaje es muy alto. Para Preschern, la certificación impone rigor en los procesos de desarrollo y mantenimiento. En estos días, la certificación representa una gran parte del costo del desarrollo del producto. Hearn indica que para los sistemas que utilizan COTS, la integración del sistema y la composición de la seguridad son cuestiones difíciles. Porque dependen de los principios de ingeniería de seguridad de los COTS utilizados y su funcionamiento con otros elementos. Este trabajo incrementa así los costes y los tiempos de entrega.
Complejo, para expertosSegún Ware, los CC son difíciles de entender para las personas que no son de seguridad. Keblawi afirma que, aunque el campo de la seguridad tiene métodos analíticos, como la planificación de la seguridad y el análisis de riesgos, nunca se han conceptualizado en un proceso de desarrollo. Para Taguchi, otro punto crucial que falta en las metodologías existentes es que no existe un estándar sobre cómo documentar, de manera concisa y sistemática, las propiedades de seguridad de los sistemas de información, en el proceso de desarrollo del sistema. Según Shoichi, sin un mecanismo de evaluación, el proceso es largo y costoso, porque no es de fácil acceso para los verificadores que no son matemáticos o no están familiarizados con los métodos formales. Según Lloyd, especificar los requisitos de seguridad es difícil porque los requisitos abarcan aspectos tanto funcionales como no funcionales y es posible que muchos desarrolladores no estén familiarizados con todos los problemas de seguridad que deben abordarse.
No siempre solo se aplicaSegún Razzazi, los sistemas actuales carecen de la base tecnológica para satisfacer las nuevas necesidades de seguridad de TI. Keblawi indica que algunos sistemas no se ajustan fácilmente a los conceptos de seguridad de los Criterios Comunes. Para Lloyd, no todos los requisitos de CC pueden aplicarse directamente a los componentes COTS individuales debido a su menor alcance funcional en comparación con los sistemas de TI.
Visión de la industria y del consumidorSegún Ware, los niveles de protección CC rara vez se utilizan en la práctica. Para Taguchi, los CC no son fácilmente aplicables en la industria debido a la falta de coincidencia entre un proceso de desarrollo de software existente y las metodologías de CC. Hearn dice que los vendedores no ven los CC como un proceso de mejora del producto. Es imposible evaluar la relación costo-beneficio que puede tener el uso de CC en un sistema informático. Para Isa, muchos investigadores y representantes de la industria indican que la práctica de CC, en un mundo que cambia rápidamente, solo puede existir en el contexto “utópico” de CC. Según Kallberg, con el crecimiento de la guerra industrial, es poco probable que los CC alcancen una masa crítica como plataforma de certificación global. Según Hearn, los compradores ven las certificaciones como un criterio menor en el abastecimiento. Rara vez leen el objetivo de seguridad o certificación y lo que se evaluó. El consumidor no se preocupa por los procesos de CC, en los que el concepto de seguridad y el modelo de amenaza es demasiado vago para ser útil.
Confianza del gobiernoAlgunos obstáculos, dijo Hearn, se relacionan con las preocupaciones sobre la armonización de las evaluaciones entre países. Los conflictos entre la armonización internacional y las inversiones nacionales podrían ser particularmente importantes si los principales países europeos y Estados Unidos continúan por caminos cada vez más divergentes en la búsqueda de los intereses nacionales. Incluso si los países miembros fundadores pudieron trabajar hacia la armonización, la experiencia muestra que la implementación de los detalles diverge. Para Isa, existe una falta de interés por parte de compradores y vendedores, ya que los CC provienen de los gobiernos y aumentan los precios de implementación. Hearn dice que el interés comercial es bajo, ya que las certificaciones son el resultado de regulaciones gubernamentales o compras gubernamentales.
El método propuesto por Taguchi se basa en un diagrama de casos de uso según varios principios. El primero de estos principios es el uso de un diagrama que detalla los conceptos de seguridad, para mostrar las necesidades de seguridad. Luego, todos los conceptos del diagrama son elementos de un metamodelo CC. Finalmente, los modelos de seguridad se agregan de acuerdo con las restricciones de seguridad de cada etapa de la construcción del producto.
Este método utiliza un metamodelo derivado del CC, que forma parte de la funcionalidad de seguridad del TOE. Se mantienen los siguientes conceptos de CC:
El autor elige eliminar de su metamodelo los siguientes conceptos de CC:
Se propone un diagrama prototipo en 3 fases. La primera fase ( Requisitos básicos de seguridad ) analiza las funciones de seguridad y las amenazas a la seguridad de forma abstracta. El segundo ( Requisitos y objetivo de seguridad ), analiza en detalle los requisitos de seguridad con el fin de definir los objetivos de seguridad. Este trabajo se realiza a partir del resultado de la fase 1. Y finalmente, la fase 3 ( Selección de requisitos de seguridad funcional ), se utiliza para la selección de requisitos de seguridad funcional, que cumplen con los objetivos de seguridad identificados en la fase anterior. Esta tarea se lleva a cabo utilizando los perfiles estándar y de protección CC parte 2. Luego, los requisitos de seguridad se alinean con los requisitos de seguro bajo la metodología CC.
El método propuesto por Ware consiste en utilizar los perfiles de los actores para dibujar las amenazas a la seguridad. Luego, realice el mapeo de amenazas y objetivos de seguridad. Y finalmente, realizar el mapeo de objetivos de seguridad y requisitos de seguridad. El mapeo se realiza mediante una caja de herramientas que contiene una lista de amenazas, objetivos y requisitos funcionales de los CC. Para implementar este enfoque, se propone una herramienta de modelado gráfico UML de código abierto.
La herramienta muestra claramente, en su “Tabla de amenazas”, los objetivos necesarios para contrarrestar una amenaza específica y los requisitos necesarios para cumplir con un objetivo específico.
Luego, la herramienta ofrece al usuario generar un archivo de salida en formato HTML. La herramienta ofrece dos posibles estilos de informe:
El informe "Principio CC" tiene como objetivo producir la parte de la justificación para un objetivo de seguridad TOE. Además, los partidos muestran claramente los objetivos necesarios para contrarrestar una amenaza específica y los requisitos necesarios para satisfacer un objetivo específico.
El método propuesto por Vetterling, es un proceso que combina el desarrollo de software 'orientado por fases' con las actividades requeridas por los CC. El principio es integrar las actividades de los CC en las fases de desarrollo del proyecto. Este método se basa en un proceso iterativo en cada fase del proyecto. Al final de cada iteración, se puede evaluar el resultado. La siguiente iteración comienza de nuevo con el resultado de la fase anterior, con la adición de nuevos requisitos.
En la fase de planificación, se escribe el plan de gestión de la configuración (clase ACM). El manual del ciclo de vida (clase ALC) también se redacta según el nivel de EAL seleccionado. Es en esta fase que se debe decidir el nivel de EAL y qué parte del sistema o producto debe desarrollarse de acuerdo con los CC.
En la fase de análisis, se redacta el objetivo de seguridad (clase ASE). También es en esta fase que comenzamos a escribir las primeras versiones del documento de prueba (clase ATE) y guías de usuario (clase AGD).
En la fase de diseño comienza la redacción del diseño y la representación (clase ADV). Su nivel de detalle depende del nivel de EAL seleccionado. La Evaluación de Vulnerabilidad (clase AVA) también se inicia en esta fase. Esta fase proporciona información a los manuales de usuario (clase AGD).
Hay, en la fase de desarrollo, elementos del análisis del resultado de la prueba que serán importantes para la documentación de la prueba (clase ATE). Para los niveles EAL más altos, el documento de diseño y representación (clase ADV) debe completarse con una representación de la implementación. La evaluación de vulnerabilidades (clase AVA) y las guías de usuario se finalizan en esta fase de desarrollo. La documentación para entregas y operación (clase ADO) también se elabora en la fase de desarrollo.
Los documentos para las entregas (clase ADO) se finalizan en la fase de despliegue y puesta en servicio.
Se realizó un estudio de caso sobre el desarrollo de una aplicación de billetera electrónica. El proyecto duró 3 meses con un equipo de 18 personas con una carga de trabajo de 630 días-hombre.
La primera retroalimentación es que los CC dejan demasiado espacio para ambigüedades, a menudo es difícil encontrar el significado correcto de los requisitos de seguridad. A menudo, son posibles diferentes interpretaciones de los requisitos de CC, lo que desperdicia un tiempo valioso durante el proyecto.
Los CC hacen que los documentos sean interdependientes, lo que aumenta la carga de documentos. Esta carga documental también aumenta por el hecho de que el requisito de CC coloca las especificaciones en diferentes niveles de abstracción. El alcance de los requisitos funcionales de CC se encuentra principalmente en el área de redes de comunicación y comercio electrónico. No cubre adecuadamente los requisitos de seguridad de la privacidad del usuario o los requisitos de comercio justo.
José Romero-Mariona, propone un enfoque que hace coincidir los requisitos de seguridad de los CC con los elementos arquitectónicos y sus conexiones. El método proporciona una guía, que se basa principalmente en observaciones del proceso CC: desarrollo de requisitos de seguridad. Con la ayuda de esta guía, los usuarios deberían poder mapear estos requisitos de elementos arquitectónicos y sus conexiones.
Luego, a partir de este mapeo, una herramienta automatizará la construcción de un archivo XML luego de haber realizado una verificación del mapeo. Los principales módulos de la herramienta son:
Los componentes de los CC y sus conexiones se definen en XML mediante 4 parámetros:
El segundo módulo realiza una verificación de definición definida por el usuario y produce un dígrafo en un formato XDR no estándar. Si hay un error, la herramienta lo indica y proporciona al usuario información sobre lo que debe hacerse para resolver el problema. El tercer módulo genera automáticamente un archivo de salida en formato XML. Luego, el usuario puede agregar nuevos componentes. La herramienta crea un nuevo archivo XML que se puede volver a colocar como entrada en el segundo módulo para su verificación.
Shanai Ardi propone un método que consiste en complementar el objetivo de seguridad, agregando vulnerabilidades de software. El objetivo de seguridad aborda lo siguiente: