Une-Iso - Iec TR 19791 - 2010

informee UNE-ISO/IEC TR
T 19791 IN
UNE
Abril 2013
TÍTULO Tecnoologías de la información
Técnicas de seguridad
uación de la seguridad de sistemas operaccionales

Evalu
Informatioon technology. Security techniques. Security assessment of operationaal systems.
Technologgies de l'information. Techniques de sécurité. Évaluation de la sécuritté des systèmes opérationnels.
CORRESPONDENCIA Este infforme es idéntico al Informe Técnico ISO/IEC TR 197911:2010.
OBSERVACIONES
ANTECEDENTES Este infforme ha sido elaborado por el comité técnico AEN/CT

TN 71 Tecnología de la
informaación cuya Secretaría desempeña AMETIC.
Editada e impresa por AENOR LAS OBSE

ERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:
Depósito legal: M 13222:2013
243 Páginas
© AENOR 2013 Génova, 6 info@aenor.es Tel.: 902 102 201

Reproducción prohibida 28004 MADRID-Españña www.aenor.es Fax: 913 104 032
Este documento ha sido adquirido por UNIVERSIDAD INTERNACIONAL DE LA RIOJA a través de la suscripción a AENORmás.
Para uso en red interna se requiere de autorización previa de AENOR.
S
-3- ISO/IEC TR 19791:2010
ÍNDICE
Página
PRÓLOGO .............................................................................................................................................. 5
INTRODUCCIÓN ................................................................................................................................... 6
1 OBJETO Y CAMPO DE APLICACIÓN ............................................................................. 6
2 NORMAS PARA CONSULTA ............................................................................................. 7
3 TÉRMINOS Y DEFINICIONES .......................................................................................... 7
4 ABREVIATURAS .................................................................................................................. 9
5 ESTRUCTURA DE ESTE INFORME TÉCNICO ............................................................. 9
6 APROXIMACIÓN TÉCNICA ............................................................................................ 10

6.1 La naturaleza de los sistemas operacionales ...................................................................... 10
6.2 Estableciendo la seguridad del sistema operacional .......................................................... 10
6.3 Seguridad en el ciclo de vida del sistema operacional ....................................................... 12
6.4 Relación con otros sistemas ................................................................................................. 15
7 EXTENDIENDO LOS CONCEPTOS DE EVALUACIÓN BAJO

LA NORMA ISO/IEC 15408 A LOS SISTEMAS OPERACIONALES ......................... 15
7.1 Visión general ....................................................................................................................... 15
7.2 Filosofía general.................................................................................................................... 16
7.3 Aseguramiento del sistema operacional ............................................................................. 17
7.4 Sistemas operacionales compuestos .................................................................................... 20
7.5 Aseguramiento de dominios ................................................................................................ 22
7.6 Tipos de controles de seguridad .......................................................................................... 24
7.7 Funcionalidad de seguridad del sistema ............................................................................. 26
7.8 Plazos de evaluación ............................................................................................................. 28
7.9 Uso de productos evaluados................................................................................................. 28
7.10 Requisitos de documentación .............................................................................................. 29
7.11 Actividades de prueba .......................................................................................................... 30
7.12 Gestión de configuración ..................................................................................................... 31
8 RELACIÓN CON LAS NORMAS DE SEGURIDAD EXISTENTES ............................ 32

8.1 Visión general ....................................................................................................................... 32
8.2 Relación con la Norma ISO/IEC 15408 .............................................................................. 33
8.3 Relación con normas que no son de evaluación ................................................................. 33
8.4 Relación con el desarrollo de Common Criteria ................................................................ 34
9 EVALUACIÓN DE SISTEMAS OPERACIONALES ..................................................... 34

9.1 Introducción .......................................................................................................................... 34
9.2 Roles y responsabilidades de la evaluación ........................................................................ 34
9.3 Evaluación del riesgo y determinación de riesgos inaceptables ....................................... 36
9.4 Definición del problema de seguridad ................................................................................ 36
9.5 Objetivos de seguridad ......................................................................................................... 37
9.6 Requisitos de seguridad ....................................................................................................... 37
9.7 El Objetivo de Seguridad del Sistema (SST) ...................................................................... 40
9.8 Reevaluación periódica ........................................................................................................ 41
ISO/IEC TR 19791:2010 -4-
ANEXO A (Normativo) PERFILES DE PROTECCIÓN Y OBJETIVOS

DE SEGURIDAD DEL SISTEMA OPERACIONAL .......................... 42
A.1 Especificación de Objetivos de Seguridad del Sistema ..................................................... 42
A.2 Especificación de Perfiles de Protección del Sistema ........................................................ 49
ANEXO B (Normativo) REQUISITOS DE CONTROL FUNCIONAL

DEL SISTEMA OPERACIONAL .......................................................... 56
B.1 Introducción .......................................................................................................................... 56
B.2 Clase FOD: Administración ................................................................................................ 58
B.3 Clase FOS: Sistemas de TI .................................................................................................. 66
B.4 Clase FOA: Activos del usuario .......................................................................................... 76
B.5 Clase FOB: Negocio ............................................................................................................. 78
B.6 Clase FOP: Instalaciones y equipos .................................................................................... 80
B.7 Clase FOT: Terceros ............................................................................................................ 85
B.8 Clase FOM: Gestión ............................................................................................................. 86
ANEXO C (Normativo) REQUISITOS DE GARANTÍA

DEL SISTEMA OPERACIONAL .......................................................... 91
C.1 Introducción .......................................................................................................................... 91
C.2 Clase ASP: Evaluación del Perfil de Protección del Sistema ............................................ 97
C.3 Clase ASS: Evaluación del Objetivo de Seguridad del Sistema ..................................... 109
C.4 Clase AOD: Documento guía del sistema operacional .................................................... 123
C.5 Clase ASD: Documento de arquitectura, diseño y
configuración del sistema operacional .............................................................................. 128
C.6 Clase AOC: Gestión de la configuración del sistema operacional ................................. 139
C.7 Clase AOT: Prueba del sistema operacional .................................................................... 144
C.8 Clase AOV: Evaluación de vulnerabilidades del sistema operacional ........................... 154
C.9 Clase APR: Preparación para la operación el tiempo real ............................................. 161
C.10 Clase ASO: Registros del sistema operacional................................................................. 165
ANEXO D (Normativo) METODOLOGÍA DE EVALUACIÓN

DEL SISTEMA OPERACIONAL ........................................................ 169
D.1 Aproximación técnica......................................................................................................... 169
D.2 Clase ASP: Evaluación del Perfil de Protección del Sistema .......................................... 170
D.3 Clase ASS: Evaluación del Objetivo de Seguridad del Sistema ..................................... 185
D.4 Clase AOD: Documento de guía del sistema operacional ............................................... 203
D.5 Clase ASD: Documentación de arquitectura,
diseño y configuración del sistema operacional ............................................................... 207
D.6 Clase AOC: Gestión de la configuración del sistema operacional ................................. 215
D.7 Clase AOT: Pruebas del sistema operacional .................................................................. 218
D.8 Clase AOV: Evaluación de vulnerabilidades del sistema operacional ........................... 226
D.9 Clase APR: Preparación para la operación en producción ............................................ 237
D.10 Clase ASO: Registros del sistema operacional................................................................. 239
BIBLIOGRAFÍA ................................................................................................................................. 243
-5- ISO/IEC TR 19791:2010
PRÓLOGO
ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica Internacional)

constituyen el sistema especializado para la normalización a nivel mundial. Los organismos nacionales
que son miembros de ISO o IEC participan en el desarrollo de normas internacionales a través de comités
técnicos establecidos por las organizaciones respectivas para realizar acuerdos en los campos específicos
de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en campos de interés mutuo. Otras
organizaciones internacionales, públicas y privadas, en coordinación con ISO e IEC, también participan
en el trabajo. En el campo de tecnologías de la información, ISO e IEC han establecido un comité técnico
conjunto, el denominado ISO/IEC JTC 1.
Las normas internacionales se redactan de acuerdo con las reglas establecidas en la Parte 2 de las
Directivas ISO/IEC.
La tarea principal de los comités técnicos es preparar normas internacionales. Los proyectos de normas
internacionales adoptados por los comités técnicos se envían a los organismos miembros para votación.
La publicación como norma internacional requiere la aprobación por al menos el 75% de los organismos
miembros que emiten voto.
En circunstancias excepcionales, el comité técnico conjunto puede proponer la publicación de un informe

técnico de uno de los siguientes tipos:
– tipo 1, cuando no se puede obtener el consenso requerido para la publicación de una norma interna-
cional después de repetidos intentos;
– tipo 2, cuando el objeto está todavía bajo desarrollo técnico o cuando por cualquier otra razón, en un
futuro, aunque no inmediato, existe la posibilidad de acuerdo para la publicación de una norma inter-
nacional;
– tipo 3, cuando el comité técnico conjunto ha recogido datos, por ejemplo de normas internacionales
publicadas (por ejemplo, estados del arte).
Los informes técnicos del tipo 1 y 2, están sujetos a revisión dentro de los tres años siguientes a su publi-
cación, con objeto de decidir si se transforman en norma internacional. Los informes técnicos del tipo 3
no necesitan ser revisados hasta que se considere que los datos que proporcionan dejan de ser válidos o
quedan obsoletos.
Se llama la atención sobre la posibilidad de que algunos de los elementos de este documento puedan estar
sujetos a derechos de patente. ISO no asume la responsabilidad por la identificación de cualquiera o todos
los derechos de patente.
El informe técnico ISO/IEC TR 19791, que es in informe técnico del tipo 3, ha sido preparado por el
Subcomité 27 Técnicas de seguridad que forma parte del Comité Técnico Conjunto ISO/IEC JTC 1
“Tecnologías de la Información”.
Esta segunda edición anula y sustituye a la primera edición (Informe Técnico ISO/IEC TR 19791:2006),
que ha sido revisado técnicamente.
ISO/IEC TR 19791:2010 -6-
INTRODUCCIÓN
Este informe técnico es un documento de soporte que define las extensiones a la Norma ISO/IEC 15408 para permitir la
evaluación de los sistemas operacionales. La Norma ISO/IEC 15408, tal y como se define actualmente, ofrece soporte
para especificar la funcionalidad de seguridad de TI que existe en los productos y sistemas. Sin embargo no cubre
ciertos aspectos críticos asociados a los sistemas operacionales, los cuales deben especificarse con precisión con el fin
de evaluar efectivamente dicho sistema.
Este informe técnico ofrece criterios extendidos de evaluación y directrices para evaluar tanto las tecnologías de la
información como los aspectos operacionales de dicho sistema. Se dirige principalmente a quienes estén implicados en
el desarrollo, integración, despliegue y gestión de la seguridad de los sistemas operacionales, así como a evaluadores
que busquen aplicar la Norma ISO/IEC 15408 a dichos sistemas. Asimismo, será importante para las autoridades de
evaluación responsables de aprobar y confirmar las acciones del evaluador. Los patrocinadores de la evaluación u otras
partes interesadas en la seguridad de los sistemas operacionales actuarían como audiencia secundaria, por la
información de trasfondo que pudieran aportar.
Considerando la complejidad de este proyecto y la necesidad de trabajo adicional, el objetivo se ha definido como un
informe técnico Tipo 2. En el futuro, una vez se haya obtenido experiencia adicional en esta área, se espera que pueda
ser posible convertir este informe técnico en una norma internacional para soportar evaluaciones de sistemas
operacionales. Hasta que se haya realizado alguna formalización de una aproximación, se considera poco probable que
muchas evaluaciones de sistemas operacionales de esta naturaleza se lleven a cabo debido a la falta de guías específicas
disponibles, un hueco que este informe técnico pretende rellenar.
Hay asuntos fundamentales en relación con la definición y uso del término sistema. La Norma ISO/IEC 15408, con su
foco en la evaluación del producto, utiliza el término sistema para incluir solo los aspectos de tecnologías de la
información (TI) del sistema. El término sistema operacional, tal como se usa en este informe técnico, comprende la
combinación de personal, procedimientos y procesos integrados con funciones y mecanismos basados en tecnología y
aplicados de forma conjunta para establecer un nivel aceptable de riesgo residual en un entorno operativo definido.
Ésta es una edición revisada, actualizada para ser compatible con la tercera edición de la Norma ISO/IEC 15408.
1 OBJETO Y CAMPO DE APLICACIÓN

Este informe técnico ofrece directrices y criterios para la evaluación de la seguridad de los sistemas operacionales.
Ofrece una extensión del ámbito de la Norma ISO/IEC 15408 al tener en cuenta una serie de aspectos críticos de los
sistemas operacionales de los que no se ocupa la evaluación bajo la Norma ISO/IEC 15408. Las principales extensiones
que se requieren se ocupan de la evaluación del entorno operativo que rodea el objetivo de evaluación y a la descom-
posición de sistemas operacionales complejos en dominios de seguridad que pueden evaluarse separadamente.
Este informe técnico ofrece:
a) una definición y modelo para sistemas operacionales;
b) una descripción de las extensiones de los conceptos de evaluación bajo la Norma ISO/IEC 15408 necesarios para
evaluar dichos sistemas operacionales;
c) una metodología y proceso para realizar la evaluación de seguridad de los sistemas operacionales;
d) criterios adicionales de evaluación de la seguridad para ocuparse de aquellos aspectos de los sistemas operacionales
no cubiertos por los criterios de evaluación bajo la Norma ISO/IEC 15408.
Este informe técnico permite la incorporación de productos de seguridad evaluados frente a la Norma ISO/IEC 15408
dentro de sistemas operacionales evaluados como un todo usando este informe técnico.
Este informe técnico se limita a la evaluación de seguridad de sistemas operacionales y no considera otras formas de
evaluación del sistema. No define técnicas para la identificación, evaluación y aceptación del riesgo operacional.
-7- ISO/IEC TR 19791:2010
2 NORMAS PARA CONSULTA

Las normas que a continuación se indican son indispensables para la aplicación de esta norma. Para las referencias con
fecha, sólo se aplica la edición citada. Para las referencias sin fecha se aplica la última edición de la norma (incluyendo
cualquier modificación de ésta).
ISO/IEC 15408-1 Tecnología de la información. Técnicos de seguridad. Criterios de evaluación para la seguridad de
TI. Parte 1: Introducción y modelo general.
TI. Parte 2: Componentes de la seguridad funcional.
TI. Parte 3: Componentes de la evaluación de la seguridad.
ISO/IEC 18045 Tecnología de la información. Técnicas de seguridad. Metodología para la evaluación de la seguridad
de TI.
3 TÉRMINOS Y DEFINICIONES
Para los fines de este documento, se aplican los términos y definiciones incluidos en las Normas ISO/IEC 15408-1,
ISO/IEC 18045 y además de los siguientes:
3.1 componente:
Porción identificable y distinta de un sistema operacional que implementa parte de la funcionalidad de ese sistema.
3.2 sistema operacional externo:

Sistema operacional distinto con interfaces con el sistema operacional que es objeto de evaluación.
3.3 controles de gestión:

Controles de seguridad (es decir, salvaguardas y contramedidas) para un sistema de información que se centre en la ges-
tión del riesgo y la gestión de la seguridad del sistema de información.
[NIST SP 800-53]
3.4 controles operacionales:

Controles de seguridad (es decir, salvaguardas y contramedidas) para un sistema de información que se implementan y
ejecutan principalmente por personas (en oposición a los sistemas).
[NIST SP 800-53]
3.5 sistema operacional:

Sistema de información, incluyendo sus aspectos no TI, considerado en el contexto de su entorno operativo.
3.6 riesgo residual:

Riesgo remanente tras el tratamiento del riesgo.
[Guía ISO/IEC 73:2002]
3.7 riesgo:
Potencial de que una amenaza concreta explote las vulnerabilidades de un activo o grupo de activos y cause así daños a
la organización.
NOTA Esta definición es idéntica a la de riesgo de seguridad de la información en la Norma ISO/IEC 27005:2008.
ISO/IEC TR 19791:2010 -8-
3.8 análisis de riesgos:

Uso sistemático de información para identificar peligros y estimar el riesgo.
3.9 evaluación del riesgo:

Proceso general de análisis y valoración del riesgo.
3.10 gestión del riesgo:

Actividades coordinadas para dirigir y controlar una organización en relación con el riesgo.
3.11 tratamiento del riesgo:

Proceso de selección e implantación de opciones para modificar el riesgo.
3.12 controles de seguridad:

Controles de gestión, operacionales y técnicos (es decir, salvaguardas y contramedidas) prescritos para un sistema de in-
formación para proteger la confidencialidad, integridad y disponibilidad del sistema y su información.
[NIST SP 800-53]
NOTA Esta definición pretende incluir controles que ofrezcan trazabilidad, autenticidad, no repudio, privacidad y fiabilidad, que a veces se consi-
deran como distintos de la confidencialidad, la integridad y la disponibilidad.
3.13 dominio de seguridad:

Porción de un sistema operacional que implementa el mismo conjunto de políticas de seguridad.
3.14 subsistema:
Uno o más componentes del sistema operacional que son capaces de ejecutarse separadamente del resto del sistema.
3.15 sistema objeto de evaluación:

Sistema operacional que está siendo operado de acuerdo con su guía operacional, incluyendo tanto los controles
técnicos como los operacionales.
NOTA Los controles operacionales forman parte del entorno operacional. No se evalúan en la evaluación bajo la Norma ISO/IEC 15408.
3.16 controles técnicos:

Controles de seguridad (es decir, salvaguardas y contramedidas) para un sistema de información que se implementan y
ejecutan principalmente por el sistema de información a través de mecanismos contenidos en los componentes
hardware, software y firmware del sistema.
[NIST SP 800-53]
3.17 verificación:
Procesos de evaluación usados para confirmar que los controles de seguridad de un sistema operacional están implan-
tados correctamente y son efectivos en su aplicación.
-9- ISO/IEC TR 19791:2010
4 ABREVIATURAS
Para los fines de este documento, se aplican los términos y definiciones dados en las Normas ISO/IEC 15408-1,
ISO/IEC 18045 y los que aparecen a continuación.
COTS Commercial Off The Shelf (Producto comercial)
OSF Operational Security Functionality (Funcionalidad de seguridad operacional)
SP Special Publication (Publicación especial)
SPP System Protection Profile (Perfil de protección del sistema)
SSA System Security Assurance (Nivel deAseguramiento de seguridad del sistema)
SSF System Security Functionality (Funcionalidad de seguridad del sistema)
SST System Security Target (Objetivo de seguridad del sistema)
STOE System Target of Evaluation (Objetivo de evaluación del sistema)
5 ESTRUCTURA DE ESTE INFORME TÉCNICO

Los capítulos 1 a 4 contienen material introductorio y de referencia y les sigue esta visión general de los contenidos del
Informe (capítulo 5).
El capítulo 6, Aproximación técnica, describe la aproximación técnica a la evaluación de sistemas operacionales utili-
zada en este informe técnico.
El capítulo 7, Extendiendo los conceptos de la evaluación bajo la Norma ISO/IEC 15408 los sistemas operacionales,
describe cómo se han extendido los conceptos de evaluación bajo la Norma ISO/IEC 15408 para su uso en la evaluación
del sistema operacional.
El capítulo 8, Relación con las normas de seguridad existentes, describe la relación entre este informe técnico y otros
estándares de seguridad que han sido usados en su desarrollo.
El capítulo 9, Evaluación de sistemas operacionales, contiene requisitos para la especificación de problemas de segu-
ridad, objetivos de seguridad, requisitos de seguridad, contenidos del SST y reevaluaciones periódicas que se necesiten
para evaluar sistemas operacionales.
El anexo A, Perfiles de protección y objetivos de seguridad del sistema operacional, define la especificaciones de los
requisitos de seguridad necesarias para sistemas operacionales.
El anexo B, Requisitos de control funcional del sistema operacional, define los requisitos funcionales adicionales de
seguridad necesarios para los sistemas operacionales.
El anexo C, Requisitos de garantía del sistema operacional, define los requisitos de garantía adicionales de seguridad
necesarios para los sistemas operacionales.
El anexo D, Metodología de evaluación del sistema operacional, define acciones adicionales a realizar por un evaluador
que lleve a cabo la evaluación de un sistema operacional.
ISO/IEC TR 19791:2010 - 10 -
6 APROXIMACIÓN TÉCNICA
6.1 La naturaleza de los sistemas operacionales

Para los fines de este informe técnico, un sistema operacional se define como un sistema de información, incluyendo
sus aspectos no TI, considerado en el contexto de su entorno operativo.
Muchos sistemas operacionales son de naturaleza compleja, y están compuestos por una combinación de subsistemas
que son parcialmente propietarios y de carácter únicoy parcialmente construidos utilizando productos comerciales. Inte-
ractúan y tienen dependencias con otros sistemas. Un sistema operacional normalmente se construye utilizando
componentes de distintos vendedores. Estos componentes pueden estar integrados para conformar el sistema operacio-
nal por un integrador que no realiza ninguna función de desarrollo, sino exclusivamente de configuración e inter-
conexión.
Sin embargo los sistemas operacionales normalmente:
− están bajo el control de una sola entidad, la propietaria del sistema operacional;
− se construyen a partir de necesidades concretas, para un tipo de operación concreto;
− cambian frecuentemente, ya sea en aspectos técnicos o en requisitos operacionales;
− contienen un número considerable (o incluso elevado) de componentes;
− contiene componentes adquiridos que poseen una gran cantidad de posibles configuraciones alternativas;
− permite al propietario del sistema operacional equilibrar medidas de seguridad técnicas (en concreto de TI) y no
técnicas;
− contiene componentes con distintos grados y tipos de garantía de seguridad.
6.2 Estableciendo la seguridad del sistema operacional

Los productos seguros ofrecen una contribución importante a la seguridad del sistema operacional y de hecho el uso de
productos evaluados con la Norma ISO/IEC 15408 pueden ser preferibles para la construcción de un sistema opera-
cional seguro. Sin embargo, los problemas de seguridad en sistemas operacionales son causados no solo por problemas
en los productos sino también por problemas en el entorno operacional real de los propios sistemas operacionales, como
por ejemplo mala práctica en reparaciones de defectos, mala parametrización de controles de acceso o de reglas de
filtrado de un firewall, mal enlace de directorios de ficheros, etc. Además, el nivel de seguridad de un sistema
operacional conectado a una red podría afectar a otros sistemas operacionales que tengan que comunicarse con él.
Este informe técnico se basa en una aproximación en tres pasos para establecer el nivel de seguridad necesario para un
sistema operacional:
a) valoración del riesgo, para determinar los riesgos de seguridad aplicables a un sistema;
b) reducción del riesgo, para compensar o eliminar los riesgos de seguridad por la selección, aplicación y evaluación de
los controles de seguridad;
c) acreditación, para confirmar que el riesgo residual remanente en el sistema tras la aplicación de losresulta aceptable
para la operación real del sistema.
Conceptualmente este proceso, de tres pasos se muestra a continuación en la figura 1.
- 11 - ISO/IEC
C TR 19791:2010
Figura 1 – Proceso parra establecer la seguridad en un sistema operacional
Este informe técnico solo se ocupa del pasoo intermedio del proceso en tres pasos, es decir de la reeducción del riesgo a
través de la selección, aplicación y valoracióón de los controles de seguridad. Para hacerlo, utiliza una
u aproximación de
evaluación de la seguridad, basada en el modelo
m de evaluación de la seguridad para controles de seguridad de TI
definido en la Norma ISO/IEC 15408, pero extendido
e para ocuparse de todos los tipos de controles de
d seguridad.
Las técnicas y métodos de valoración del rieesgo están fuera del ámbito de este informe. Para más innformación acerca de
la valoración de riesgos, véase la Norma ISSO/IEC 27005 [1]. Las técnicas y modelos de acreditacción son responsabi-
lidad de la Dirección, fuera asimismo del ámmbito de este informe. Para más información acerca dee una posible aproxi-
mación, ver NIST SP 800-37 [2].
El modelo de evaluación de la seguridad de la Norma ISO/IEC 15408 excluye la consideración dell entorno operacional
que rodea a la parte de TI del sistema de infformación. El entorno operacional se trata como suposiiciones en la evalua-
ción bajo la Norma ISO/IEC 15408, pero noo puede ser obviado para sistemas operacionales. Norm malmente los sistemas
operacionales dependen de medidas de segguridad no TI, por ejemplo, medidas de naturaleza adm ministrativa o física.
mas de expresar y evaluar dichos requisitos y controles como una extensión
Existe por tanto la necesidad de definir form
de los criterios de especificación de la Norm
ma ISO/IEC 15408. Este informe técnico extiende la Noorma ISO/IEC 15408
para llevarlo a cabo. Las extensiones incluyeen, aunque no están limitadas a éstas:
a) posicionar la evaluación de seguridad deentro de una metodología general para la valoración dee la seguridad de los
sistemas operacionales, incluyendo su enntorno operacional;
ISO/IEC TR 19791:2010 - 12 -
b) una metodología para especificar la estructura interna de los sistemas operacionales, incluyendo detalles de las inter-
faces internas y externas, hasta el grado necesario para entender cómo interoperan las distintas partes de un sistema
operacional;
c) un catálogo de criterios de garantía para expresar las extensiones del ámbito de evaluación (véase el anexo A);
d) un catálogo de criterios funcionales para expresar los controles de seguridad operacional adicionales (véase el anexo B);
e) un catálogo de criterios de garantía para expresar las tareas adicionales de valoración adicional necesarias para
evaluar sistemas operacionales (véase el anexo C);
f) un catálogo de acciones del evaluador para expresar las actividades adicionales requeridas para evaluar sistemas
operacionales (véase el anexo D).
Extender la aproximación de la Norma ISO/IEC 15408 a la evaluación de sistemas operacionales completos tiene la
ventaja de utilizar una métrica definida existente de forma que sea posible la compresión común y mutua de los
resultados de la evaluación. Para un sistema operacional concreto, publicar el resultado de la evaluación de una forma
que sea compatible con la Norma ISO/IEC 15408 podría proporcionar una ventaja de negocio a los clientes, no solo en
sistemas de provisión de servicios como sistemas de banca por Internet, sino también desde el punto de vista de la
responsabilidad social.
La evaluación del sistema operacional requiere que en una valoración anterior del riesgo se hayan identificado los
riesgos de seguridad aplicables a un sistema operacional y se hayan determinado aquellos riesgos que son inaceptables y
deben reducirse o eliminarse mediante controles técnicos y operacionales. Por tanto consiste en los siguientes pasos:
a) establecer objetivos de seguridad para el sistema operacional que reducirían los riesgos inaceptables a un nivel que
sea tolerable;
b) seleccionar y especificar controles técnicos y operacionales de seguridad que satisfagan los objetivos de seguridad
para el sistema operacional, teniendo en cuenta los controles que ya existan;
c) definir requisitos de garantía concretos y medibles tanto para controles técnicos como operacionales para obtener el
nivel de confianza requerido para que el sistema operacional cumpla con sus objetivos de seguridad;
d) registrar las decisiones tomadas en un Objetivo de Seguridad del Sistema (SST);
e) evaluar el sistema operacional real para juzgar el cumplimiento del SST;
f) revalorar periódicamente tanto los riesgos de seguridad para el sistema operacional como la capacidad del mismo
para ocuparse de estos riesgos.
Aunque este modelo es una extensión del modelo de la Norma ISO/IEC 15408, resulta consistente con dicho modelo,
por lo que pueden reutilizarse los resultados obtenidos de la evaluación bajo la Norma ISO/IEC 15408.
6.3 Seguridad en el ciclo de vida del sistema operacional
6.3.1 Visión general

Se considera que el ciclo de vida de un sistema operacional tiene cuatro fases, que son desarrollo/integración, instala-
ción, operación del sistema y modificación. Los controles de seguridad de un sistema operacional deben valorarse a lo
largo del ciclo de vida del sistema. Esto se muestra en la siguiente figura 2.
- 13 - ISO/IEC
C TR 19791:2010
Figura 2 – Seguridaad dentro del ciclo de vida del sistema operacional
6.3.2 Fase de desarrollo/integración

Durante la fase de desarrollo/integración, laa primera actividad de seguridad es identificar los riesgos para el sistema
operacional. Aquellos riesgos que se considderen inaceptables deben reducirse o eliminarse mediannte medidas de segu-
ridad implementadas en el sistema. Tras la evaluación
e del riesgo y la identificación de los riesgos a eliminar, un respon-
sable autorizado de la organización, el acredditador, debe considerar los riesgos residuales esperados así como la suma de
todos ellos y confirmar que serían aceptabless.
Luego se diseñará el sistema operacional, inncluyendo el uso de productos de hardware y software, las l instalaciones físi-
cas requeridas, los programas de aplicación del negocio necesarios y los controles técnicos de seguuridad requeridos. El
diseño del sistema operacional debe registtrarse en el SST. El SST contendrá una descripción de los requisitos de
seguridad del sistema, incluyendo los riesgoos a contrarrestar y los objetivos de seguridad a alcanzaar mediante controles
técnicos y operacionales. La lista de controoles técnicos y operacionales documentada en el SST representará
r la deter-
minación de los objetivos de seguridad del sistema.
ISO/IEC TR 19791:2010 - 14 -
Con el objetivo de alcanzar el nivel de corrección deseado, los objetivos de seguridad deberían ser especificados en el
SST de manera relacionada frente a los riesgos identificados como inaceptables El SST debería especificar requisitos
concretos de seguridad que satisfagan completamente los objetivos de seguridad sin añadidos ni omisiones. La
documentación de diseño del sistema operacional debería identificar contramedidas precisas de seguridad dentro del
sistema operacional que cumplan todos los requisitos de seguridad especificados en el SST. Las contramedidas podrían
ser funciones de seguridad, instalaciones, procedimientos o normas. Las contramedidas deberían estar adecuadamente
controladas, gestionadas y aplicadas al sistema. Las contramedidas de seguridad deberían implementarse sin ningún
añadido, eliminación o modificación no autorizados. La implantación debería ser verificada teteando el sistema o
comprobando los documentos, según aplique. La operación de las contramedidas de seguridad debería quedar descrita
describirse adecuadamente en los documentos de guía.
Para conseguir la eficacia pretendida, los requisitos de seguridad seleccionados deberían reducir todos los riesgos de
seguridad identificados por la evaluación de riesgos como inaceptables a un nivel que puedan tolerarse como riesgos
residuales. Cada contramedida de seguridad debería trabajar efectivamente en combinación con otras contramedidas
para satisfacer los requisitos generales de seguridad para el sistema operacional. La fortaleza de los mecanismos de
seguridad debería ser la suficiente como para contrarrestar el potencial ataque esperado. Un estudio o análisis de
vulnerabilidades y un test de penetración podrían ser necesarios en función del potencial de ataque esperado.
Los evaluadores deberían estar implicados en la fase de desarrollo/integración, desde el inicio del ciclo de vida del
sistema, para facilitar su comprensión del sistema y el entorno pretendido, así como para ofrecer ideas mediante la
revisión de la documentación de diseño y guías de evaluación y documentación guía a usar como parte de la evidencia
de garantía. Idealmente debería valorarse todo el SST mediante una evaluación preliminar para confirmar que no hay
inconsistencias u omisiones en los requisitos de seguridad y los controles propuestos.
Las aplicaciones de negocio y el software de sistemas, incluyendo los controles técnicos de seguridad, se desarrollan o
adquieren posteriormente y el sistema se integra, configura y prueba por parte del desarrollador. Al mismo tiempo, se
establece la organización de seguridad operacional y se desarrollan e integran en el sistema las políticas, reglas y proce-
dimientos de seguridad. Deberían identificarse e implantarse los parámetros adecuados de configuración de seguridad.
Tras los test de integración, la seguridad del sistema operacional debería ser puesta a prueba por los desarrolladores
como parte de la verificación de requisitos. Por lo general, determinados controles de seguridad tales como los controles
de acceso pueden ser verificados por el desarrollador antes de su despliegue en el sitio de operación. Sin embargo, las
pruebas de los controles de seguridad (tanto técnicos como operativos) específicos del sitio de operación se deberían
aplazar hasta que el sistema esté instalado en el entorno operacional previsto. Las pruebas de verificación confirmarán
la solidez de los mecanismos de seguridad, así como el correcto funcionamiento de los controles de seguridad
Posteriormente se evaluará el sistema operacional. La evaluación debería confirmar que todos los riesgos que deben ser
contrarrestados por los controles de seguridad del sistema, tal y como se encuentran detallados en el SST, son reducidos
a un nivel aceptable. El resultado de la evaluación es en sí mismo una confirmación independiente al propietario del
sistema de que así es.
El Informe de Certificación listará las vulnerabilidades encontradas en la evaluación e identificará cualquier acción
correctiva recomendada. Posteriormente el propietario del sistema preparará un plan de acción correctivo para reducir o
eliminar las vulnerabilidades identificadas tal y como estime apropiado. El resultado de la certificación del sistema se
presentará al acreditador para determinar si resulta aceptable el actual riesgo residual sobre los activos y operaciones del
sistema. Los riesgos residuales reales en operaciones y sistemas. Como resultado de esta fase se obtendrá la
autorización para la operación del sistema.
6.3.3 Fase de instalación

Durante la fase de instalación, se implantarán y prepararán los controles técnicos y operacionales para su uso en el en-
torno operacional. Se probarán los controles específicos del sitio y se volverán a probar otros controles para confirmar
que funcionan correctamente en el entorno operacional real.
Para alcanzar el nivel de corrección deseado, los controles deberían cumplir con los requisitos de seguridad documenta-
dos en el SST y ser autorizados para su uso por una persona competente. Para que dichos controles resulten efectivos,
todas las personas deberían estar formadas en el uso de los controles y procedimientos de seguridad.
- 15 - ISO/IEC TR 19791:2010
6.3.4 Fase de operación del sistema

En la fase de operación del sistema, deberían ser recogidos y evaluados los registros de operación de controles técnicos
y operacionales. Deberían registrarse las pistas de auditoría y los datos de monitorización de todos los accesos a los
activos. Debería confirmarse que las contramedidas de seguridad operan como se pretendía. Debería verificarse que no
se ha incurrido en operaciones no autorizadas ni se han originado riesgos inaceptables. La recuperación de estados
seguros a partir de estados inseguros debería llevarse a cabo dentro de los márgenes de tiempo requeridos. Los cambios
debidos a mantenimientos rutinarios deberían ser monitorizados y evaluados para detectar problemas de seguridad.
Deberían inspeccionarse los registros reales de acceso y la utilización de activos. Los problemas de seguridad deberían
ser reportados, revisados y analizados.
El propósito de estas actividades es ofrecer retroalimentación al acreditador cuando se produzcan cambios que puedan
tener un impacto en la seguridad del sistema operacional. Normalmente durante la operación de los sistemas debería
identificarse un subgrupo crítico de controles de seguridad del sistema operacional para realizar una monitorización
regular de los mismos para determinar la continuidad de su eficacia. Además, el propietario del sistema debería tener
implantado un sistema de gestión, control y reporte de la configuración que documente los activos actuales del sistema
operacional, su configuración y permita presentar esa información a los responsables.
6.3.5 Fase de modificación

Durante la fase de modificación del sistema cualquier cambio propuesto o real del sistema operacional más allá del
ámbito del mantenimiento rutinario debería revisarse, analizarse y, si es necesario, probarse para determinar su impacto
en la seguridad del sistema operacional antes de implementarlo en producción. Esto incluye cambios en procedimientos
y políticas. Deberían realizarse pruebas de penetración los controles modificados para verificar efectividad.
Los resultados del análisis de impacto y pruebas deberían ser presentados al acreditador para determinar la necesidad de
una reevaluación de la seguridad. Cuando se considere que las modificaciones no han aumentado significativamente los
riesgos residuales, tal vez porque ya hayan sido evaluados como parte de un proceso de mantenimiento de garantía de
producto, puede darse la reautorización sin reevaluación. Sin embargo, si los resultados de la evaluación han resultado
invalidados, puede ser necesaria una reevaluación.
El acto final de la modificación del sistema es su terminación, en el que un sistema se cierra y sus datos se retienen,
destruyen o transfieren a otros sistemas. Se pedirá al acreditador que confirme que el sistema se ha cerrado con éxito.
El acreditador deberá confirmar que el sistema ha sido cerrado con éxito.
6.4 Relación con otros sistemas

Un sistema operacional puede interactuar con otros sistemas relacionados y puede formando así parte de un todo mayor.
El STOE del sistema operacional objeto de evaluación se define como esa porción del grupo de sistemas evaluado,
incluyendo tanto los sistemas de TI como su entorno operacional. Los restantes son considerados sistemas operacio-
nales externos. Un sistema operacional puede tener objetivos de seguridad que cumplan los sistemas operacionales
externos, pero éstos no son analizados o evaluados.
7 EXTENDIENDO LOS CONCEPTOS DE EVALUACIÓN BAJO LA NORMA ISO/IEC 15408 A LOS

SISTEMAS OPERACIONALES
7.1 Visión general

El propósito de este capítulo es documentar la filosofía que sostiene la aproximación de la Norma ISO/IEC 15408 a la
evaluación del riesgo y para posteriormente extenderla a los sistemas operacionales. La Norma ISO/IEC 15408 consi-
dera solo controles de carácter técnico aquellos de gestión relacionados; en los sistemas operacionales, los controles
técnicos y operacionales se combinan para proteger la información manejada y otros activos de la organización.
ISO/IEC TR 19791:2010 - 16 -
7.2 Filosofía general

Para muchas organizaciones la información es el activo principal y requiere protección contra las amenazas de divulga-
ción, modificación o destrucción no autorizadas. Estos activos se protegen utilizando una combinación de controles
técnicos e infraestructuras de apoyo de control operacional de personal, políticas, procedimientos y medidas de protec-
ción física. La filosofía general de la Norma ISO/IEC 15408 es que las amenazas a las que se encuentran expuestos los
activos de las organizaciones deberían estar claramente definidas y deberían ser contrarrestadas mediante una com-
binación de infraestructuras de control técnico y operacional. Los requisitos de control técnico para hacer frente a las
amenazas están incluidos en la Norma ISO/IEC 15408-2. Bajo la Norma ISO/IEC 15408, los requisitos relativos a los
controles operacionales son considerados de forma separada como parte de un proceso de acreditación externo y por
tanto la evaluación de seguridad no se ocupa directamente de ellos. Este documento busca formalizar esos requisitos de
forma que puedan evaluarse como parte de la evaluación del sistema operacional.
Conceptualmente, la Norma ISO/IEC 15408 diferencia las medidas de seguridad entre los servicios relacionados con la
seguridad que deben proveerse y las medidas tomadas para garantizar que esas medidas están implantadas correcta y
eficazmente. En el ámbito de una evaluación de producto, los servicios relacionados con la seguridad son aquellas
funciones implantada en la TI para alcanzar los objetivos específicos. En el contexto de sistemas operacionales, se
pueden evaluar asimismo las contribuciones procedimentales y físicas a la seguridad. Son similares a la funcionalidad
de TI porque son capacidades de seguridad del sistema de seguridad que juntas cumplen los objetivos de seguridad. Sin
embargo generalmente no están basadas en tecnología y están más ajustadas a la evaluación en el ámbito del control
operacional del ciclo de vida del sistema operacional que en el ámbito de desarrollo. Por tanto se considera parte
segregada de los requisitos funcionales.
Las medidas adoptadas para asegurar que las capacidades de seguridad operan según lo esperado se denominan
“garantías” en la Norma ISO/IEC 15408 y consisten en la generación de evidencias y la valoración independiente de la
corrección de dichas capacidades. Esto pude hacerse extensible con objeto de cubrir la parte de controles operacionales
del sistema operacional a través de documentación que describa como se implementaron los controles operacionales.
El proceso utilizado para desarrollar, implantar y mantener tanto el propio sistema operacional como más en concreto
los servicios de seguridad relacionados tiene una influencia considerable en la corrección y eficacia del servicio relacio-
nado con la seguridad y su contribución general a la seguridad total de sistema operacional. Esta influencia también
contribuye a la confianza en el rendimiento del servicio relacionado con la seguridad. De esta forma el proceso contri-
buye a la garantía general del sistema operacional complejo. Más en concreto, cuanto mayor sea en nivel de capacidad
del proceso, mayor será la confianza que pueda tenerse en la corrección y eficacia del servicio relacionado con la
seguridad y por tanto en la garantía general ofrecida.
En resumen, los requisitos funcionales de seguridad operacional son aquellos controles de seguridad no técnicos im-
plantados en los sistemas operaciones que contribuyen a los objetivos de seguridad generales, mientras que los requi-
sitos de garantía de seguridad reflejan la evidencia de que dichos requisitos han sido satisfechos.
La evaluación de la seguridad en un sistema operacional puede por tanto descomponerse en una serie de pasos:
a) el problema de seguridad se articula como una serie de riesgos a reducir o mitigar y una serie de políticas de seguri-
dad organizativa a aplicar. Esto requiere un análisis previo para determinar el propósito del sistema operacional y un
análisis de riesgos para determinar aquellos riesgos que deben contrarrestarse mediante controles técnicos y opera-
cionales. Los resultados del análisis se registran en el SST;
b) el problema de la seguridad se descompone en una solución de seguridad de alto nivel, representada por una serie de
objetivos de seguridad. Estos objetivos se registran en el SST;
c) los objetivos de seguridad se refinan aún más en requisitos de seguridad que puedan ser valorados por un evaluador
independiente. Algunos objetivos de seguridad se asignarán a los controles técnicos y otros a los operacionales.
Algunos pueden requerir tanto controles técnicos como operacionales. Por ejemplo, controlar el acceso no autori-
zado a un activo de información se logrará a menudo tanto dotando de seguridad física a la instalación que contenga
el activo (por ejemplo, con cerrojos, guardias) como por funcionalidades de TI (por ejemplo, autenticación de
usuario y mecanismos de control de acceso). Los requisitos de seguridad se registran en el SST;
- 17 - ISO/IEC TR 19791:2010
d) se define una serie de actividades para que el evaluador las siga durante la valoración, basadas en los objetivos gene-
rales y el aseguramiento general en la protección de las medidas requeridas. Estos requisitos de garantía se registran
en el SST;
e) la valoración de un evaluador independiente determina que el sistema operacional cumple con sus requisitos de
seguridad, basándose en los requisitos documentados en el SST;
f) pueden realizarse asimismo valoraciones continuas para obtener la garantía de que el sistema operacional cumpla
con sus requisitos durante la operación. Estas se centrarán principalmente en los aspectos de control operacional del
sistema operacional dado estos controles dependen de comportamiento humano, que es menos controlable y consis-
tente que el comportamiento de las TI;
g) la reevaluación periódica del sistema operacional puede evaluar que éste continúa cumpliendo los requisitos a pesar
de los cambios sufridos en el sistema operacional o su entorno. Esto consiste en determinar qué cambios han tenido
lugar, valorando su impacto sobre la seguridad, actualizando el SST cuando sea preciso y confirmando que se ha
mantenido la seguridad durante dicho proceso.
Este proceso es muy similar al proceso de evaluación bajo la Norma ISO/IEC 15408. La diferencia fundamental entre la
evaluación de un sistema operacional y una evaluación de producto bajo la Norma ISO/IEC 15408 es que en una eva-
luación de un sistema operacional se considera el sistema operacional real al completo, mientras que en una evaluación
de producto no se define en detalle el sistema operacional, sino que es descrito como meras suposiciones que no se veri-
fican durante la evaluación.
El objetivo principal de la evaluación de un sistema operacional es asegurarse de que se han implantado correcta y efec-
tivamente los objetivos de seguridad para el sistema operacional. Sin embargo la evaluación de los controles de seguridad,
ya sean técnicos u operacionales, nunca pueden ofrecer una garantía absoluta de que esos controles siempre funcionarán
como se pretende, en todo momento y bajo cualquier circunstancia. La evaluación proporciona un veredicto de aprobación
o suspenso. Incluso si la evaluación no identifica vulnerabilidades inaceptables, siempre existirá un riesgo residual de que
los controles no funcionen como se pretende. Este riesgo puede reducirse añadiendo controles aseguramiento adicionales o
usando distintas medidas aseguramiento que generen una mayor confianza. El riesgo residual de un rendimiento incorrecto
o inefectivo de los controles solo puede identificarse a través de una monitorización y evaluación continuas.
Debe tenerse en cuenta este riesgo residual cuando se decida si puede acreditarse un sistema operacional para su opera-
ción en producción.
Los factores del entorno pueden generar distintos entornos de criticidad/amenaza para distintos componentes de los
sistemas operacionales. Es posible que algunas partes del sistema operacional puedan requerir mayor nivel de asegu-
ramiento mientras que otras, por contra requieran menos. Dado que la evaluación del riesgo puede establecer distintos
niveles de aceptabilidad del riesgo para distintas partes del sistema operacional, un sistema operacional puede dividirse
en dominios de seguridad con distintos requisitos de garantía. La evaluación del riesgo determinará la aceptabilidad del
riesgo para las distintas partes del sistema operacional y ayudará a determinar las medidas apropiadas de aseguramiento
para cada parte del sistema operacional.
7.3 Aseguramiento del sistema operacional

El paradigma de aseguramiento de la Norma ISO/IEC 15408 se centra en la provisión de evidencias de que existen las fun-
ciones de seguridad y están implantadas de forma correcta y efectiva. Mayores niveles de aseguramiento implican requisi-
tos más detallados en el contenido y el estilo de presentación de las evidencias. Además, un mayor nivel de aseguramiento
requiere a veces aumentar el rigor en el análisis de la evidencia, tanto por parte del desarrollador como del evaluador.
Una evaluación de producto bajo la Norma ISO/IEC 15408 se realiza de una forma que suponga un entorno operacional
genérico en que podría usarse el producto. La evaluación del producto se centra en verificar las capacidades de segu-
ridad implantadas por el producto, de forma independiente de cualquier contexto operacional específico. La evaluación
de producto reuiere distinta documentación de especificación, diseño y prueba para llegar al veredicto de cumplimiento.
En la evaluación del producto, los requisitos de garantía normalmente no se deducen del problema de seguridad. En su
lugar, se seleccionan axiomáticamente o por decisión política.
ISO/IEC TR 19791:2010 - 18 -
El objetivo principal de una evaluación de producto es obtener la garantía de que las capacidades de seguridad del
producto se implementan correctamente. La base de la corrección se establece en los requisitos de seguridad contenidos
en el Objetivo de Seguridad (ST) del producto. El ST incluye cierta trazabilidad sobre el problema de seguridad que se
resuelve por el grupo de requisitos de seguridad resultante. El problema de seguridad indicado en el ST se supone
basado en una evaluación de amenazas para los tipos de entorno apropiados para el despliegue del producto. El ámbito
de la evaluación del producto se limita a los requisitos de seguridad de TI asignados al producto a partir de esta
evaluación de amenazas. Además la evaluación del producto establece límites para “valores seguros” para aspectos
configurables del mismo: la llamada “configuración evaluada”. Sin embargo estas configuraciones no tienen en cuenta
ningún entorno concreto ya que éste es desconocido en el momento de la evaluación. Al completarse la evaluación del
producto, sigue siendo necesario integrar adecuadamente el producto evaluado con otros productos para componer un
sistema operacional y finalmente verificar que el sistema operacional ofrece las propiedades y comportamiento de
seguridad apropiados en su entorno y configuración operacionales.
Las evaluaciones de productos generalmente tienen las mismas medidas de aseguramiento aplicadas a lo largo de toda
la funcionalidad de seguridad definida. Aunque es técnicamente posible tener diferentes dominios de seguridad en los
productos, no se aplica usualmente a las evaluaciones de productos genéricos.
Las evidencias e informes de evaluación generados tras una evaluación de producto pueden utilizarse para apoyar el
trabajo de integración y verificación del sistema operacional.
En principio existe poca diferencia entre las propiedades de un producto de TI y un sistema operacional para los fines
de una evaluación de seguridad. Sin embargo la evaluación del sistema operacional puede ser significativamente más
compleja que la evaluación de un producto bajo la Norma ISO/IEC 15408 por diversas razones:
a) un sistema operacional puede comprender muchos productos adquiridos y desarrollos de TI a medida agrupados en
dominios de seguridad. La composición de cada dominio de seguridad del sistema puede basarse en varios factores,
como la tecnología empleada, la funcionalidad ofrecida y la criticidad de los activos protegidos;
b) un sistema operacional puede contener múltiples instancias del mismo producto (por ejemplo, múltiples copias de un
sistema operativo provistas por el mismo vendedor) o múltiples instancias de diferentes productos del mismo tipo
(por ejemplo, múltiples firewalls provistos por varios vendedores diferentes);
c) un sistema operacional puede tener políticas de seguridad que aplicable a determinados dominios de seguridad sin
ser de aplicación a otros;
d) distintos riesgos residuales pueden ser aceptables dentro de distintos dominios de un sistema operacional, mientras
que un producto contrarresta determinados tipos de amenaza a activos específicos sin consideración del riesgo.
Todos estos factores impactan en los requisitos de garantía para un sistema operacional. En particular, pueden reque-
rirse distintas formas de controles de aseguramiento para distintos dominios de seguridad, dependiendo de la informa-
ción de desarrollo disponible o de los distintos tipos de controles funcionales seleccionados. Esto significa que los
objetivos de seguridad han de definirse y explicarse como parte de la solución al problema de seguridad.
Además, una evaluación de un sistema operacional debe cubrir todos los controles de seguridad, incluyendo los implan-
tados en el entorno operacional, que se tratan como suposiciones en una evaluación de producto. En general, el tipo de
requisitos de garantía para controles técnicos documentados en la Norma ISO/IEC 15408-3 pueden extenderse para ser
aplicados a controles operacionales. Por ejemplo, el concepto de evaluación de documentación de diseño para controles
técnicos se convierte en evaluación de la descripción de procedimientos operacionales para controles operacionales. Las
acciones de los encargados de implantar controles operacionales pueden probarse de una forma similar a la forma en
que se prueban las acciones de programas que implementan controles técnicos.
Algunos requisitos de garantía de la Norma ISO/IEC 15408-3 relativos al desarrollo de sistemas pueden no ser directa-
mente aplicables a los sistemas operacionales, o sus evaluaciones deben retrasarse hasta la fase de instalación del siste-
ma del ciclo de vida. Igualmente el aseguramiento de controles operacionales a menudo solo puede alcanzarse en el
entorno operacional real, mientras que los controles técnicos frecuentemente se examinan y prueban en su entorno de
desarrollo.
- 19 - ISO/IEC TR 19791:2010
Por tanto, para evaluar los controles de seguridad de los sistemas operacionales, es necesario generalizar y modificar las
clases de aseguramiento para funcionalidad técnica en la Norma ISO/IEC 15408-3. Se ha hecho y el anexo C contiene
las definiciones de clases de aseguramiento disponibles.
Un asunto concreto afecta a la garantía de efectividad de los controles implementando la SSF. El aseguramiento de los
controles técnicos en este aspecto se logra por técnicas de diseño de arquitectura como separación de dominios, no
interferencia y no superación de controles. Para controles operacionales, se utilizan técnicas análogas pero algo diferen-
tes, como separación de tareas, inspección y monitorización.
Áreas en las que se necesitan componentes de aseguramiento adicionales para manejar sistemas operacionales son:
a) la arquitectura de seguridad general y el emplazamiento de componentes dentro de la arquitectura;
b) la configuración de los componentes que comprenden el sistema operacional;
c) la gestión de políticas, reglas y procedimientos que gobiernan la operación del sistema operacional;
d) los requisitos y reglas de interacción con otros sistemas operacionales de confianza o no;
e) la monitorización de los controles no TI durante la fase operacional del ciclo de vida del sistema.
A causa de su enfoque en el producto, la Norma ISO/IEC 15408 supone que un TOE se desarrollará en un solo entorno
de desarrollo que es distinto del entorno operacional pretendido. Esta suposición es improbable que sea cierta para la
mayoría de los sistemas operacionales. Incluso si el sistema operacional se desarrolla es un entorno de prueba separado,
la etapa final del desarrollo del sistema operacional será la integración en el entorno operacional, cuando se añadan la
medidas de control operacional en el sistema operacional. Algunas partes del sistema operacional, especialmente los
productos adquiridos, pueden haber sido desarrolladas en entornos de desarrollo distintos y diferentes del entorno de
desarrollo principal.
Algunos componentes del sistema operacional pueden ya haber sido evaluados contra la Norma ISO/IEC 15408, basán-
dose en suposiciones acerca del pretendido entorno operacional. Si estas suposiciones se demuestran ciertas en el con-
texto del sistema operacional, los resultados de dichas evaluaciones seguirán aplicándose para el uso de esos compo-
nentes como parte del sistema operacional y pueden volverse a usar.
En resumen, hay cinco formas principales de poder obtener el aseguramiento de los controles del sistema operacional:
a) de un análisis del diseño del sistema operacional (la clase ASD del anexo C, que se basa en la clase ADV de la
Norma ISO/IEC 15408-3);
b) por prueba del sistema operacional (la clase AOT del anexo C, que se basa en la clase ATE de la Norma
ISO/IEC 15408-3);
c) por verificación de que el sistema operacional ha sido instalado y configurado correctamente (la clase APR del ane-
xo C, que no tiene equivalente en la Norma ISO/IEC 15408-3);
d) por verificación de que el sistema operacional está funcionando de forma segura durante la operación de producción
(la clase ASO del anexo C, que no tiene equivalente en la Norma ISO/IEC 15408-3);
e) por reutilización de los resultados de evaluación existentes (miembros de la clase AOC).
Además, puede obtenerse el aseguramiento mediante el examen de la especificación de requisitos (las clases ASP y
ASS, basadas en las clases APE y ASE de la Norma ISO/IEC 15408-3), la documentación operacional (AOD, basada en
AGD) y la evaluación de vulnerabilidades (AOV, basada en AVA).
La mayoría de las evaluaciones de sistemas operacionales requerirán el uso de todas estas técnicas.
ISO/IEC TR 19791:2010 - 20 -
Puede haber varias formas diferentes de conseguir es nivel de aseguramiento requerido en un sistema operacional. Al
contrario que en la evaluación del producto, no hay Niveles de Aseguramiento de Evaluación predefinidos. Los
requisitos de garantía deberían elegirse para cumplir con los objetivos de aseguramiento establecidos a partir del análi-
sis de los riesgos para el sistema operacional y la disponibilidad de documentación, los resultados de las pruebas y las
herramientas de prueba de desarrollo y operacionales.
7.4 Sistemas operacionales compuestos

Muchos sistemas operacionales son grandes y complejos, ofreciendo múltiples funciones y una estructura interna com-
plicada. Por tanto este informe técnico define una metodología normalizada para la descripción de la arquitectura de sis-
temas operacionales basada en dos niveles de descomposición: subsistemas y componentes.
Un componente es una porción de un sistema operacional identificable y distinta que implementa parte de la funciona-
lidad de dicho sistema (relacionada o no con la seguridad). Un componente puede comprender una sola función ofrecida
por un solo producto, un solo producto con múltiples funciones o un grupo integrado de funciones implementadas por la
combinación de software adaptado y procedimientos operacionales. Un subsistema es un grupo de uno o más com-
ponentes del sistema operacional que pueden ejecutarse independientemente del resto del sistema operacional. Por
ejemplo, un subsistema podría comprender un solo cliente o servidor constituido por múltiples productos, múltiples ser-
vidores o clientes y redes o un grupo de clientes o servidores homogéneos. Algunos componentes y subsistemas pueden
ya haber sido evaluados en seguridad, otros no.
En sistemas operacionales simples, todo subsistema podría componerse exactamente de un componente; de hecho po-
dría haber solo un subsistema identificable. Sin embargo la mayoría de los sistemas operacionales probablemente estén
compuestos de múltiples subsistemas, cada uno a su vez compuesto de múltiples componentes distintos.
En la evaluación bajo la Norma ISO/IEC 15408, el diseño del sistema del Objetivo de Evaluación debe descomponerse
en subsistemas y módulos. De acuerdo con la Norma ISO/IEC 15408, un subsistema es una descripción de alto nivel de
qué y cómo hace una parte del TOE; un módulo es una descripción de una funcionalidad del sistema al nivel más deta-
llado de descomposición ofrecida por el diseño del sistema.
En la práctica, los subsistemas definidos en este informe técnico corresponderán a menudo a subsistemas tal y como se
definen en la Norma ISO/IEC 15408. Sin embargo un componente tal y como se define en este informe técnico tiene un
ámbito más amplio que un módulo de la Norma ISO/IEC 15408, por ejemplo, puede incluir funcionalidades provistas
por medios no TI. Para funcionalidades implementadas por software, un componente puede corresponder a múltiples
documentos de diseño de módulo de la Norma ISO/IEC 15408 de bajo nivel, correspondiendo cada uno de ellos a un
módulo de código.
Normalmente los sistemas operacionales compuestos:
a) contienen varios subsistemas, cada uno compuesto por múltiples componentes, con diferentes grados y tipos de ase-
guramiento;
b) tienen una estructura de control bien definida. Puede existir un “propietario” único del sistema operacional o grupo
definido de relaciones de gestión sobre las distintas partes del sistema operacional;
c) se construyen a partir de necesidades concretas de operación específica;
d) los componentes individuales poseen gran cantidad de opciones de configuración posibles, algunas de las cuales son
incompatibles con las políticas de seguridad del sistema operacional;
e) permiten al propietario del sistema operacional implantar un equilibrio distinto de controles técnicos y operacionales
en distintas partes del sistema operacional.
- 21 - ISO/IEC
C TR 19791:2010
La política de seguridad puede ser distinta para

p las combinaciones anteriores, excepto en el raro caaso en que el sistema
operacional tenga una única función. Lógiccamente, todas las partes del sistema operacional bajoo el mismo grupo de
políticas de seguridad pueden calificarse commo un dominio de seguridad. Esta descomposición dell sistema operacional
en subsistemas y componentes gobernados por p la(s) misma(s) política(s) de seguridad se caracterizaa así en la política de
seguridad de acuerdo con los riesgos apropiaados para ese dominio. Pueden identificarse los requisittos de seguridad fun-
cionales y de aseguramiento para cada dom minio de seguridad. Como tal, cada dominio de seguriddad tendrá su propia
política de seguridad, definición del problem
ma de seguridad, objetivos de seguridad, requisitos de seeguridad y documen-
tación de seguridad. Sin embargo cada uno de d estos dominios de seguridad opera dentro de mayor grupo a nivel de sis-
tema operacional de políticas, problemas, obbjetivos, requisitos y documentación de seguridad. Cadaa dominio de seguri-
dad puede tener sus propios requisitos de gaarantía basados en el grado de confianza necesario en ese dominio de seguri-
dad y su contribución general al sistema opeeracional. El Objetivo de Seguridad del Sistema operaciional especificará los
requisitos de seguridad del sistema operacioonal, que serán una recopilación representativa de los doominios de seguridad
que comprenda el sistema operacional en unn contexto del sistema operacional. El concepto de dom minio de seguridad se
muestra en la figura 3.
F
Figura 3 – Ejemplo de dominios
Es importante apreciar que la estructura de dominios de seguridad de un sistema operacional com mpuesto no tiene por
qué ser la misma que la estructura de su arqquitectura. Un subsistema puede abarcar varios dominios de seguridad (por
ejemplo, un solo subsistema cliente-servidorr puede tener distintas políticas de seguridad para clienttes y servidores). De
igual forma, varios productos de distintos vendedores
v pueden tener que ser tratados como compponentes separados a
efectos de construcción pero implementar poolíticas de seguridad idénticas y por tanto caer dentro dee un solo dominio de
seguridad.
ISO/IEC TR 19791:2010 - 22 -
Al definir un sistema operacional compuesto hay una necesidad de describir la estructura de arquitectura del sistema, en
concreto para definir y describir los límites del sistema, describir las interfaces y dependencias entre componentes del
sistema y describir las interfaces y dependencias entre componentes del sistema y su entorno (por ejemplo, usuarios,
sistemas operacionales externos). Han de definirse todas las interfaces entre componentes y entre el sistema operacional
y el entorno que le rodea. Las especificaciones de interfaz tienen que cubrir cualquier requisito de seguridad para la
interfaz o los enlaces de comunicación que implementan la interfaz. Además, las especificaciones deben identificar
cualquier relación de confianza o propiedades de seguridad invariables para la interfaz.
7.5 Aseguramiento de dominios

Un beneficio del concepto de dominio de seguridad es que permite distintos requisitos de garantía a aplicar en distintas
partes del sistema operacional. Consideremos un sistema servidor típico. Se construirá con una variedad de
componentes, como programas de aplicación, productos middleware y software base, como un sistema operativo. El
middleware y el software base pueden haber sido objeto de evaluación de productos, pero igualmente pueden no haber
sido evaluados. Para productos no evaluados, el vendedor puede cooperar ofreciendo la evidencia necesaria para la
evaluación, pero también puede negarse a facilitar evidencia necesaria. Para productos evaluados, puede haber
disponible un informe técnico de Evaluación (Evaluation Technical Report, ETR) para ayudar a la reutilización de los
resultados de la evaluación, pero el acceso al ETR puede denegarse.
Consideremos el sistema mostrado más abajo en la figura 4. Para un dominio de seguridad A, que está construido por
software propietario, probablemente puede estar disponible toda la evidencia de evaluación requerida para la evaluación
bajo la Norma ISO/IEC 15408. Para el dominio de seguridad B, podría obtenerse evidencia para satisfacer algunos
criterios de la Norma ISO/IEC 15408 (por ejemplo, las clases ADO y AGD y ATE_FUN), pero algunos otros criterios
(por ejemplo, las clases ADV y AVA y ATE_COV/DPT) es poco probable que sean alcanzables ya que la evidencia
necesaria no será obtenible y de hecho puede que nunca haya existido. Deben obtenerse garantías alternativas (como un
certificado de evaluación de producto) o aceptarse los riesgos residuales.
- 23 - ISO/IEC
C TR 19791:2010
Figura 4 – Composición de sistema heterogéneo
Por otro lado, el sistema mostrado en la figgura 5 está construido completamente con componentess para los que puede
obtenerse la evidencia requerida para la evaaluación bajo la Norma ISO/IEC 15408. Por tanto pueede tratarse como un
solo dominio de seguridad, el dominio X, coon requisitos de aseguramiento homogéneos.
ISO/IEC TR 19791:2010 - 24 -
Figura 5 – Composición de sistema homogéneo
Con el fin de cumplir sus requisitos de seguuridad, un dominio dentro de un sistema operacional com mpuesto puede tener
dependencias de las propiedades de seguridaad de otros dominios. Un dominio puede ofrecer servicios de seguridad que
pueden usarse por otros dominios a través de comunicaciones o interfaces de programación de aplicaciones
a o puede
aplicar propiedades de seguridad en otros dominios.
d Esto tiene que reflejarse dentro del SST paara el sistema opera-
cional.
Los servicios y propiedades de seguridad quue se aplican o se hacen disponibles a otros dominios debben ser identificados
como tales en la declaración de objetivos de
d seguridad para el dominio. Igualmente, si un dominiio de seguridad tiene
objetivos de seguridad que cumplen otross dominios, deben identificarse como tales dentro dee su declaración de
objetivos de seguridad.
7.6 Tipos de controles de seguridad

La Norma ISO/IEC 15408 especifica princippalmente controles técnicos, es decir, controles de segurridad que implemen-
tan los componentes TI de un sistema. Sin embargo,
e también se necesita especificar aquellos controoles y actividades de
gestión que necesarios para controlar y moniitorizar los controles técnicos.
Los sistemas operacionales también necesitaan especificar controles operacionales. Como los controlles técnicos, los con-
troles operacionales tienen controles y activvidades de gestión asociados esenciales para garantizar la implantación tal y
como como fueron especificados, no caen enn desuso y son eficaces en la práctica.
- 25 - ISO/IEC
C TR 19791:2010
Dado que la mayoría de los controles operaacionales dependen de una acción humana que no es neecesariamente prede-
cible o repetible, la gestión y monitorizacióón es incluso más importante que la necesaria para los controles técnicos.
Además, hay controles implantados por sisttema y directrices corporativas diseñados para asegurarr la operación segura
del sistema. Estos controles podrían categorrizarse como controles operacionales (ya que son partee de la operación del
sistema) o como controles de gestión independientes (ya que están puramente relacionados con la geestión).
Este informe técnico usa la misma aproximaación a los controles de gestión que la Norma ISO/IEC 15408, en la que, los
controles de gestión son considerados siempre como parte de los controles técnicos u operacionales a los que apoyan.
Un ejemplo de esto es el mostrado en la figgura 6. En este ejemplo, las funciones de control de accceso implementadas
por el servidor son los controles técnicos. Ell registro de los atributos del usuario es un control de geestión que soporta las
funciones de control de acceso. Sin embarggo las reglas para la asignación de los roles de usuarioo (por ejemplo, para
aplicar la separación de tareas) son un contrrol operacional. Los procedimientos de gestión de estos roles de usuario son
un control de gestión, pero que soporta este control
c operacional.
Figura 6 – Ejemplo de controles de seguridad
Los controles operacionales pueden incluir reglas

r y procedimientos, así como protección física. Unn ejemplo de control
operacional que implicaría actividades puram
mente de gestión es el reporte de incidentes de seguridadd.
ISO/IEC TR 19791:2010 - 26 -
Para que un sistema operacional sea seguro, los controles técnicos y operacionales (incluyendo los controles de gestión
relacionados) deben integrarse y funcionar juntos para proporcionar cobertura a todas las amenazas. En la práctica, la
contribución a la seguridad de los controles técnicos del sistema se ve influida y depende de los controles operacionales
que ofrece el entorno operacional. Como ejemplo, el valor de los “activos TI” del sistema para la organización deter-
minará el tipo de controles operacionales que permite, como la protección física, a qué personal se le dará acceso a él y
bajo qué condiciones se respaldará para apoyar la operación continuada. Además, puede haber integración de controles
técnicos y operacionales como la protección física. Por ejemplo, los controles operacionales de acceso físico pueden
confiar en controles técnicos para servicios de autenticación y los controles operacionales pueden ofrecer a los controles
técnicos información acerca de la presencia o ausencia física de personal en una instalación.
Muchos controles técnicos para sistemas operacionales pueden expresarse directamente usando los componentes fun-
cionales de la Norma ISO/IEC 15408-2. Sin embargo la complejidad de los sistemas operacionales puede requerir un
refinado adicional de componentes, no necesario normalmente en la evaluación bajo la Norma ISO/IEC 15408. Algunos
ejemplos de esto son:
a) el administrador podría necesitar la capacidad de determinar que la configuración del sistema operacional es la
esperada. El requisito para esta capacidad sería un refinado del auto-test TSF (FPT_TST) a incluir en la definición
de “operación correcta del TOE”;
b) el SST puede querer asignar específicamente partes de la funcionalidad de seguridad a componentes concretos
dentro de los dominios de seguridad. Esto significaría refinar “el TSF” en partes concretas del TSF, por ejemplo “El
dominio de seguridad del firewall debe ofrecer un mecanismo para…”;
c) puede ser necesario definir funciones de control técnico referidas a la interoperabilidad con otros sistemas o
referidas a la interoperabilidad entre distintos componentes o subsistemas del sistema operacional.
Donde ya exista un ST para los controles técnicos de un sistema operacional, por ejemplo si los controles los provee un
producto adquirido y evaluado, el ST puede usarse como plantilla para la construcción de los requisitos de seguridad del
sistema operacional. Sin embargo como la evaluación del sistema operacional está basada en el riesgo, las amenazas y
suposiciones del ST del producto y las justificaciones del ST asociado tendrán que ser reevaluadas y posiblemente
modificadas.
La mayoría de los controles operacionales de un sistema operacional se ocupan de procesos de gestión y operacionales
y procedimientos y que están más allá de ámbito de la Norma ISO/IEC 15408 y que por tanto no pueden expresarse fá-
cilmente utilizando los componentes funcionales de la Norma ISO/IEC 15408-2. Se necesitan componentes funcionales
adicionales para manejar estos requerimientos y en este informe técnico se definen posibles componentes.
7.7 Funcionalidad de seguridad del sistema

El paradigma de la Norma ISO/IEC 15408 para la funcionalidad de seguridad se centra en torno a la provisión de un
TOE que se ocupe solamente de la funciones de seguridad de TI. En un sistema operacional, el TOE se generaliza en un
STOE que incluye tanto las funciones de control técnico como operacional.
La funcionalidad de seguridad del sistema (SSF) comprende esas partes del STOE (y por tanto del sistema operacional)
en las que se confía para mantener las políticas de seguridad para ese sistema. La SSF contiene controles de seguridad
tanto técnicos como operacionales.
Cuando se definen los requisitos de seguridad, el propietario del sistema puede elegir asignar los requisitos para satis-
facer un objetivo funcional de seguridad ya sea a controles técnicos de seguridad, controles operacionales de seguridad
o una combinación de ambos.
Por tanto se usan tres términos al definir los requisitos de seguridad operacional. Cuando hace falta un control técnico
de seguridad, el requisito debería expresarse en la forma “La TSF debe…”. Se usa esta forma porque la Norma
ISO/IEC 15408 ya usa el término TSF para controles técnicos de seguridad. Si se requiere un control operacional de
seguridad, el requisito debería expresarse en la forma “La OSF debe…”, indicando que el control debe ser físico o
basado en personal o procedimientos. Si la implantación puede ser técnica u operacional o una combinación de ambas,
el requisito debería expresarse en la forma “La SSF debe…”.
- 27 - ISO/IEC
C TR 19791:2010
Es importante advertir que solo las partes reelevantes del STOE serían incluidas en la SSF evaluadda y que el STOE no
necesita representar todo el sistema operacioonal. La siguiente figura 7 ofrece una representación grááfica de estas ideas.
Figura 7 – Controles de seguridad del sistema
En una evaluación bajo la Norma ISO/IEC 15408, las funciones técnicas de seguridad tienen dependeencias de aspectos de
la seguridad operacional. Un ejemplo es el eleemento de control de accesos FDP_ACC.1.1 de la Normaa ISO/IEC 15408-2:
FDP_ACC.1.1. La TSF debe aplicar el [assignación: SFP de control de acceso] sobre [asignaciión: lista de sujetos,
objetos y operaciones entre sujetos y objetoss cubiertos por el SFP].
En una evaluación bajo la Norma ISO/IEC 15408,1 la política de control de acceso y la lista de sujeetos, objetos y opera-
ciones estarían documentadas, pero por lo demás,
d se supondrían correctas. En una evaluación de un u sistema operacio-
mo parte de la evaluación de la protección de datos y los roles y responsabi-
nal, esta política y lista serían evaluadas com
lidades del personal. (Véase B.4.2.4, FOA_IINF.1.8 y B.2.2.4, FOD_PSN.1.18). En general, las regllas y procedimientos
requeridos los una TSF que deben suponerrse correctos aplicables en una evaluación bajo la Norrma ISO/IEC 15408
serán evaluados como parte de una evaluacióón de sistema operacional.
ISO/IEC TR 19791:2010 - 28 -
Es importante que en cualquier sistema operacional haya un buen equilibrio entre TSF y OSF. La TSF requiere la
adquisición de productos de seguridad o el diseño e implantación de funcionalidades concretas de seguridad del sistema
dentro del hardware y el software. Por tanto la TSF tiene un coste de desarrollo inicial del sistema en tiempo y dinero.
Por el contrario, la OSF es flexible pero puede convertirse en ineficaz con el tiempo si no se vigila. Normalmente tiene
un coste inicial bajo establecerla, pero un coste alto durante la operación debido a las actividades extra de realización y
verificación de controles de OSF por parte del personal. Explicar el equilibrio buscado entre TSF y OSF dentro del SST
o SPP puede ayudar a comprender la elección de la funcionalidad seleccionada.
7.8 Plazos de evaluación

La evaluación supone una determinación en un momento dado de tiempo de si los controles cumplen los requisitos que
se les imponen. Esto puede tener lugar en cualquier momento del ciclo de vida de un producto y sistema, pero en el caso
de una evaluación del producto bajo la Norma ISO/IEC 15408 normalmente tiene lugar una vez terminado el desarrollo,
pero antes de que el producto se ponga en producción.
Es muy probable que un control técnico que ha sido probado con éxito en un entorno de desarrollo también funcione en
el entorno operacional. Esto es mucho menos seguro para controles operacionales. Durante la operación ordinaria, el
equipo en el entorno operacional podría inspirar menor confianza, ser menos experimentado, menos competente o estar
menos motivado que durante las pruebas en el entorno de desarrollo. Así que el nivel de aseguramiento de la fase de
desarrollo en controles operacionales es mucho menos transferible al entorno operacional que el nivel de aseguramiento
de controles técnicos. Es más probable por tanto que la evaluación inicial se extienda a la fase operacional o tenga lugar
en un sistema que ya esté en operación.
Idealmente, un sistema operacional debería ser reevaluado tras cambios importantes en capacidades o riesgos del
sistema. Sin embargo es asimismo necesario reevaluar periódicamente un sistema operacional para confirmar que sigue
cumpliendo sus objetivos eficazmente y determinar si son necesarios ajustes para permanecer en el umbral de tolerancia
de riesgo requerido.
En el primer caso, respecto de la evaluación del desarrollo, la evaluación ofrecerá una buena evidencia de que el sistema
operacional es capaz de cumplir sus nuevos objetivos, pero poca de que esto ocurra en la operación real. Queda para la
dirección asegurarse de que se utilizan eficazmente controles de seguridad del sistema operacional. En el segundo caso,
el evaluador puede confirmar, mediante el examen de los registros de operación de controles y de incidentes de
seguridad que los controles cumplen con sus requerimientos y por tanto funcionan eficazmente.
7.9 Uso de productos evaluados

Cuando se ha evaluado un producto, puede existir evidencia disponible de dicha evaluación que pueda ser reutilizada en
la evaluación del sistema operacional. Sin embargo, la evidencia detallada puede no estar públicamente disponible. En
algunos casos, esta evidencia puede obtenerse directamente a través de un acuerdo con el desarrollador del producto o
de la autoridad que controle el plan de evaluación. En otros, puede no ser posible obtener el detalle necesario a nivel
relevante para determinar la aplicabilidad a su rol en el sistema operacional y el propietario del sistema debe determinar
entonces si es permisible aceptar los resultados sin disponer de acceso a la evidencia que contribuyó a esos resultados.
Igualmente, los resultados de una evaluación de producto no necesariamente han de ser aplicables a la evaluación de un
sistema operacional. Algunas razones podrían ser:
a) la configuración del producto durante la evaluación del producto y la configuración del producto cuando se integra
en el sistema operacional pueden ser distintas;
b) el nivel de aseguramiento con que se ha evaluado el producto es inadecuado comparado con el nivel de asegura-
miento que requiere el producto al integrarse como componente en el sistema operacional. En este caso, puede haber
evidencias que pueden ser reutilizadas pero también habrá que generar nuevas evidencias.
En estos ejemplos, la evaluación del sistema operacional necesita determinar el grado en que pueden usarse los resulta-
dos disponibles y qué medidas adicionales de aseguramiento pueden necesitarse. En el peor de los casos, estos compo-
nentes tendrían que tratarse como componentes no evaluados.
- 29 - ISO/IEC TR 19791:2010
Cuando un producto no tiene una evaluación completa, se desconoce cuánta información podría estar disponible para
apoyar la evaluación del sistema operacional y se desconoce también si cualquier información existente del producto
será confirmada por la evaluación del producto. Cuando un producto no se ha evaluado, la información normalmente
requerida para la evaluación del producto puede no estar disponible para apoyar la evaluación del sistema operacional.
Habría que considerar esas realidades en la evaluación del sistema operacional.
Es esencial que exista información disponible acerca de las características de seguridad de las interfaces entre
productos, es decir, qué funciones de seguridad de un producto dependen de funciones de seguridad de otro producto.
Es necesario confirmar durante la evaluación del sistema que todos los productos que dependen de funciones de
seguridad dentro de otros productos los utilizan de una forma segura. A menudo la información necesaria estará
documentada en el ETR del otro producto, pero dicha información puede no presentarse en una forma compatible. En
este caso, será necesario recurrir a otros documentos, como las especificaciones de interfaz y la documentación del
diseño de arquitectura, y confirmar que están presentes las propiedades de seguridad requeridas. Lo mismo aplica
cuando se usan productos no evaluados.
La variedad y madurez de productos COTS evaluados que están disponibles para integración en un sistema operacional
limita el nivel máximo de aseguramiento que puede alcanzarse puramente al usar productos evaluados. En general no
sería práctico reevaluar productos ya evaluados con un nivel de aseguramiento superior, ya que la evidencia adicional y
el apoyo del desarrollador probablemente no estén disponibles. Si el nivel de aseguramiento de producto no es
suficiente, será necesario obtener aseguramiento adicional de controles alternativos o por medios de arquitectura, como
añadir firewalls u otros componentes de arquitectura propios de seguridad.
Alternativamente, una evaluación de un sistema operacional tiene la capacidad de asignar distintos niveles de asegura-
miento a lo largo de distintos dominios del sistema operacional. Cuando el aseguramiento de un dominio concreto se
restringe por el uso de productos evaluados, puede solicitarse al acreditador que acepte el consecuente riesgo residual
incrementado para ese único dominio.
7.10 Requisitos de documentación

En la evaluación de producto bajo la Norma ISO/IEC 15408, la mayoría de los requisitos de documentación son utiliza-
dos por los evaluadores para confirmar que las actividades de desarrollo han sido realidasas de forma correcta y
asegurarse de que los usuario tienen la información necesaria para configurar y operar el TOE de una forma segura.
En un sistema operacional, debe proveerse asimismo la documentación que defina los controles operacionales, de forma que:
a) los evaluadores puedan confirmar que estos controles, si se implantan adecuadamente, satisfarán realmente los
objetivos de seguridad que les corresponden;
b) puedan realizarse, durante la fase operacional del ciclo de vida del sistema, verificaciones de que se están siguiendo
los procedimientos relevantes y que tanto los controles procedimentales como los físicos son eficaces.
También debe proveerse documentación respecto de las propiedades de seguridad de las interfaces entre distintos
componentes del sistema operacional y entre componentes del sistema operacional y otros sistemas dentro del entorno
que le rodea, de forma que cuando un componente tenga dependencia de las propiedades de seguridad de otro
componente o sistema, puede ser confirmado por los evaluadores que estas propiedades son válidas de acuerdo con la
especificación de ese componente o sistema.
Los requisitos de documentación para el diseño de sistemas operacionales deben ser más flexibles de los permitidos en
la evaluación de productos. Para algunos subsistemas y componentes se puede disponer de buena documentación de
seguridad acorde con el estándar de evaluación de productos a altos niveles de aseguramiento. Sin embargo para otros
sistemas y componentes, especialmente los que no pretendan tener características de seguridad, puede haber disponible
poca o ninguna documentación propia de seguridad y generalmente muy poca documentación de diseño en general.
Esto significa que cualquier documentación necesaria para la evaluación del sistema operacional puede tener que
crearse especialmente para la evaluación. En algunos casos, las propiedades de seguridad de un subsistema o
componente pueden definirse bien, pero puede desconocerse cómo se implementan. En esos casos, la creación de
documentación detallada de diseño interno puede ser imposible.
ISO/IEC TR 19791:2010 - 30 -
El requisito básico para la evaluación del diseño de un sistema operacional es que se ofrezca una descripción de la
arquitectura. Ésta debe identificar el sistema operacional en términos de sus subsistemas e interconexiones entre
subsistemas y sus interfaces externas a otros sistemas. La descripción de la arquitectura no tiene por qué ser un
documento de seguridad específico. Permite al evaluador conseguir una comprensión de la arquitectura general del
sistema operacional, pero no de cómo alcanza sus objetivos de seguridad.
El segundo nivel de descripción de la arquitectura ofrece a los evaluadores un concepto de seguridad del documento de
operaciones. Éste describe las propiedades de seguridad del sistema operacional a un nivel de detalle consistente con la
descripción de la arquitectura. Debe cubrir todos los modos de operación del sistema operacional, describir cómo las
funciones de seguridad del sistema operacional funcionan juntas para aplicar las propiedades de seguridad del sistema
operacional y cómo está protegido el sistema operacional ante vulneraciones de su funcionalidad de seguridad. Este
documento permite que la arquitectura de seguridad del sistema sea evaluada, independientemente de cómo se
implemente internamente el sistema operacional.
Al igual que la evaluación de la arquitectura de seguridad, la evaluación del sistema operacional puede fijarse en cómo
se han implantado las características de seguridad del sistema. El primer nivel de evaluación requiere ofrecer una
especificación funcional de la interfaz que especifique todas las funciones y propiedades de seguridad del sistema
operacional visibles en sus interfaces, pero sin ningún detalle interno de la implantación. Esto permite la evaluación de
“cajas negras” del sistema operacional, en las que se conocen las propiedades declaradas pero no hay detalles de cómo
se alcanzan.
Finalmente, la evaluación del sistema operacional puede tener en cuenta la documentación interna de diseño para el
sistema operacional. Esto puede hacerse a tres niveles:
a) cuando todas las interfaces y propiedades de los subsistemas están documentadas;
b) cuando las interfaces y propiedades están documentadas al nivel de componentes individuales;
c) cuando un diseño a nivel de componente se ve suplementado por representaciones de implantación (código fuente,
scripts de configuración) para componentes clave de seguridad.
Aunque no existirán controles operacionales hasta que el sistema operacional entre en operación, pueden diseñarse
durante el desarrollo del sistema operacional y que su diseño sea evaluado en ese momento.
7.11 Actividades de prueba

Las actividades de prueba realizadas como parte de la evaluación del sistema operacional tienen requisitos que normal-
mente no se encuentran en la evaluación de producto bajo la Norma ISO/IEC 15408.
La prueba del sistema operacional evalúa la efectividad de las funciones de control técnico y operacional que contra-
rrestan riesgos inaceptables conocidos y aplican las políticas de seguridad definidas. La efectividad se determina en
parte a través de la prueba de la funcionalidad de seguridad del sistema operacional y en parte realizando pruebas de
penetración. La prueba solo tiene sentido después de que se ha aplicado una configuración segura verificada al sistema
operacional y en el caso de controles operacionales, solo puede simularse en un entorno de pruebas. Hay dos tipos de
configuraciones: la configuración de los productos para interoperar como componentes del sistema operacional y la
configuración de los productos para ofrecer el comportamiento de seguridad requerido para permitir operaciones diarias
seguras al negocio o a la misión soportada por el sistema operacional. Los controles técnicos del sistema operacional
pueden y deben ser probados por parte del desarrollador/integrador antes del despliegue. Esta prueba ofrecerá confianza
en que las funciones de control técnico del sistema están funcionando adecuadamente y contrarrestan efectivamente el
riesgo al nivel indicado por la evaluación del riesgo. Deberían asimismo identificar cualquier defecto no pretendido y
ofrecer al desarrollador una ventana para resolver dichos defectos antes de la evaluación. Así que los controles
operacionales estarán integrados con las funciones de control técnico en los sitios operacionales, donde la efectividad de
los controles de seguridad integrados del sistema operacional pueda ser evaluada.
- 31 - ISO/IEC TR 19791:2010
Como la prueba operacional no es parte de la evaluación del producto y la Norma ISO/IEC 15408 no requiere configu-
ración del producto para aplicar un grupo concreto de políticas operacionales en el “mundo real”, todos los productos
tendrán que ser probados, y más concretamente la configuración del sistema operacional, como parte de la prueba
general del sistema operacional.
También puede ocurrir que productos o subsistemas dentro de un sistema operacional no interoperen adecuadamente.
Esto significa que en la prueba general del sistema operacional se debe investigar y confirmar la interacción segura
entre los distintos componentes y subsistemas.
La estrategia de prueba interna puede asimismo ser distinta para distintos dominios de seguridad que comprenda el sis-
tema operacional, dependiendo de características como:
a) nivel de aseguramiento requerido en el subsistema;
b) nivel de aseguramiento ya establecido (o no establecido) en productos que comprenden el subsistema;
c) arquitectura elegida y productos que comprende la arquitectura;
d) tecnología empleada;
e) ubicación de componentes en el entorno físico.
7.12 Gestión de configuración

La evaluación de un sistema operacional tiene requisitos de gestión de configuración que normalmente no se encuentran
en la evaluación de productosbajo la Norma ISO/IEC 15408. La Norma ISO/IEC 15408 trata el ciclo de vida de los pro-
ductos de TI desde la perspectiva de un desarrollador. El ciclo de vida empieza con los requisitos para el producto y
luego continúa con el diseño, desarrollo, evaluación y producción. El ciclo de vida solo considera aspectos operacio-
nales si estos impactan en la siguiente versión del producto.
Debido a esto, la gestión de configuración se trata principalmente como una medida de aseguramiento de forma que el
evaluador pueda estar seguro de que el TOE a evaluar sea la versión correcta y pueda estar seguro de que el desarrolla-
dor sabe qué debería incorporarse al TOE evaluado para su distribución. El proceso de gestión de configuración no es
parte del TOE sino más bien una herramienta para generar el TOE.
En los sistemas operacionales no solo es importante saber que se incorporan los componentes correctos dentro del
sistema operacional sino también que la configuración del sistema continúa siendo conocida y entendida durante la
operación del sistema operacional. Por tanto puede haber dos sistemas de gestión de configuración diferentes: uno para
el entorno de desarrollo en el que se produce el sistema operacional y otro para el entorno operacional en el que opera.
El primero de ellos se trata como una garantía de evaluación y el segundo es una capacidad de control operacional.
El sistema de gestión de configuración operacional existe principalmente para que administradores y gestores de
seguridad del sistema operacional sean capaces de establecer que el sistema operacional continúa operando con una
configuración segura y también para conocer el impacto de actualizaciones, eliminaciones e inserciones de compo-
nentes del sistema operacional. Por tanto el sistema operacional tiene que tener la capacidad (bien a través de medios
procedimentales o tecnológicos) de gestionar la configuración e informar de su configuración actual. La capacidad de
informar puede usarse para comparar la configuración real del sistema operacional con la configuración pretendida para
facilitar la verificación de que los controles de seguridad del sistema están configurados correctamente y que los
controles de seguridad no se han cambiado, debido a acciones de mantenimiento u otras y no se han documentado
adecuadamente. La información también servirá para apoyar la el nivel de aseguramiento de cualquier análisis de
impacto de los cambios como consecuencia de las actividades de monitorización continua. La gestión de configuración
se convierte por tanto en una capacidad de seguridad del sistema operacional. Puede usarse para proporcionar
evidencias de aseguramiento de que los controles operacionales están implantados correcta y efectivamente.
ISO/IEC TR 19791:2010 - 32 -
Una función adicional de la gestión de configuración es asegurar que los productos independientees que se incorporen
como componentes dentro de un sistema opperacional se configuran de forma segura, de acuerdo con c su guía de docu-
mentación y cualquier requisito de evaluacióón del producto. La gestión de configuración del sistemma operacional puede
realizar esta comprobación, comparando la configuración
c real con las restricciones registradas en laa documentación del
producto.
8 RELACIÓN CON LAS NORMAS DE

E SEGURIDAD EXISTENTES
8.1 Visión general

Este informe técnico ofrece una extensión dee la Norma ISO/IEC 15408 que permita la evaluación de los sistemas opera-
cionales. Tal y como se describía en capítuloos anteriores, esto requiere extensiones al modelo de evvaluación encontrado
en la Norma ISO/IEC 15408 y la definición de criterios de evaluación adicionales.
En su mayor parte, los procesos, documentaación y tareas adicionales requeridos para la evaluacióón del sistema opera-
cional se han definido extendiendo conceptoos análogos dentro de la Norma ISO/IEC 15408. Los criiterios adicionales de
evaluación requeridos se ocupan principalmente de los aspectos operacionales y de integración del sistema de la
seguridad de la información y se han deduccido de normas existentes de seguridad de la informacióón no orientadas a la
evaluación. En particular, este informe téccnico se basa de forma consistente en dos normas concretas
c de buenas
prácticas de seguridad, la Norma ISO/IEC 27002
2 [3] y la Norma NIST SP 800-53 Recommended Security
S Controls for
Federal Systems [4]. Dada la existencia y am mplia aceptación de estos documentos, se consideró inaapropiado desarrollar
nuevos criterios y estructuras de criterios.
Esta relación se muestra en la figura 8. El SSST, el modelo de política de seguridad del sistema, la evvaluación del riesgo,
la evaluación de las vulnerabilidades, los doocumentos de guía, procedimientos y documentos de diseño d de desarrollo,
formarán todos parte de la documentación prrovista para la evaluación del sistema y han sido generaalizados a partir de la
Norma ISO/IEC 15408. Los criterios para evaluar
e el entorno operacional y en particular los controoles operacionales se
han tomado de estándares y líneas generales no orientados a la evaluación.
Figura 8 – Relación entre

e entorno operacional y criterios de evaluación
- 33 - ISO/IEC TR 19791:2010
Al igual que las Normas ISO/IEC 27002 y NIST SP 800-53, hay otra serie de normas SC 27, como la Norma
ISO/IEC 21827 [5], que se han utilizado como fuente. La Norma ISO/IEC TR 15443 [6] ofrece aproximaciones poten-
ciales alternativas con respecto a los requisitos de seguridad. La Norma ISO/IEC TR 15446 [7] sugiere líneas de guía
para el diseño de perfiles de protección y objetivos de seguridad.
Otros documentos relevantes son la norma NIST SP 800-53A Guide for Verifying the Efectiveness of Security Controls
in Federal Information Systems [8] y el manual alemán IT Baseline Protection Manual alemán [9].
Se han adaptado conceptos y controles concretos de todos estos documentos cuando se ha considerado apropiado. Sin
embargo no se pretende que los criterios de evaluación definan cómo diseñar y gestionar un sistema operacional de
forma segura. El propósito de los criterios de evaluación es definir cómo evaluar sistemas operacionales seguros
utilizando las evidencias ofrecidas a los evaluadores por parte de propietarios del sistema, desarrolladores, integradores,
operadores y administradores del sistema operacional. Por tanto los criterios de evaluación cubrirán distintos aspectos y
enfatizarán en otros aspectos que el material fuente de estas otras normas y documentos guía.
Como los procesos, documentos y tareas definidos dentro de este informe técnico se basan en equivalentes existentes a
la Norma ISO/IEC 15408, las contribuciones de otros estándares y guías se han reestructurado en un formato que es una
extensión de los ya utilizados en la Norma ISO/IEC 15408.
8.2 Relación con la Norma ISO/IEC 15408

La primera edición de la Norma ISO/IEC 15408 se uso como base para el desarrollo de este informe técnico. Esta edi-
ción revisada se ha actualizado para ser compatible con la tercera edición de la Norma ISO/IEC 15408.
Se ha usado la Norma ISO/IEC 15408 como base y marco para la evaluación del sistema operacional. Ofrece los me-
dios para especificar los requisitos para controles técnicos. Por ejemplo, contiene criterios para la especificación de po-
líticas de control de accesos. La Norma ISO/IEC 15408 no ofrece los medios para especificar controles operacionales,
sino que dichos controles pueden encontrarse dentro de un marco similar a la Norma ISO/IEC 15408. Esto permite de
esta forma evaluar el sistema operacional utilizando criterios de aseguramiento similares a los de la Norma
ISO/IEC 15408 verificados durante la evaluación.
La Parte 1 de la Norma ISO/IEC 15408 define los conceptos de objetivos de seguridad y perfiles de protección. Estos
marcos de especificación de requisitos sirven como base para objetivos y perfiles mejorados, los Perfiles de Protección
del Sistema (SPP) y Objetivos de Seguridad del Sistema (SST) que también cubren los controles operacionales.
La Parte 2 de la Norma ISO/IEC 15408 define los criterios de evaluación para los requisitos funcionales. Estos criterios
son directamente aplicables a los controles técnicos requeridos para sistemas operacionales y se usan como base para
definir nuevas clases, familias y componentes centrándose en los controles operacionales del sistema operacional dentro
de este informe técnico. Este informe técnico también incluye el aspecto “como está configurado” de las funciones y
mecanismos dentro del sistema operacional y requisitos para las políticas y procedimientos que deben implantarse en el
entorno operacional por parte de los controles operacionales.
La Parte 3 de la Norma ISO/IEC 15408 define los criterios de evaluación para los requisitos de garantía. Estos criterios
de aseguramiento se usan como base para nuevas clases, familias y componentes de aseguramiento centrándose en las
actividades de evaluación que deben realizarse para evaluar los aspectos de los controles de seguridad del sistema
operacional como una sola unidad integrada. Esto incluye los requisitos para evidencias de las políticas y procedi-
mientos que serán implantados en el entorno operacional por parte de los controles operacionales.
8.3 Relación con normas que no son de evaluación

La Norma ISO/IEC 27002 es un Código de Prácticas que recomienda controles de seguridad que deberían considerarse por
parte de una organización con el fin de gestionar la seguridad de los activos de información. La Norma ISO/IEC 27002
ofrece recomendaciones relativas a la gestión de seguridad de la información para iniciar, implantar y mantener la seguri-
dad de la información dentro de una organización.
ISO/IEC TR 19791:2010 - 34 -
La Norma ISO/IEC 27002 ofrece un marco de gestión generalmente aceptado para el control de la seguridad opera-
cional. Se ha utilizado como la fuente principal para identificar y especificar aspectos de seguridad operacional cuando
se requieran controles y para formular requisitos concretos de control operacional.
NIST SP 800-53 ofrece directrices para seleccionar y especificar controles de seguridad para sistemas de información a
utilizar en sistemas del Gobierno Federal de EEUU. También se anima a los gobiernos estatales y locales de EEUU, así
como a las organizaciones del sector privado que comprendan la infraestructura crítica de los Estados Unidos a
considerar el uso de sus guías. Su uso es obligatorio a través Estándar Federal de EEUU, la Publicación 200 del FIPS,
Minimum Security Controls for Federal Information Systems [10]. Cuando resulta apropiado, NIST SP 800-53 se dirige
a la Norma ISO/IEC 27002 en la definición de sus controles de seguridad, pero también cubre otras áreas no relaciona-
das directamente con la gestión de la seguridad de la información.
NIST SP 800-53 se ha usado por tanto como la segunda fuente principal de controles operacionales, particularmente en
las áreas de seguridad operacional que quedan fuera del ámbito del Norma ISO/IEC 27002.
Hay otras normas y estándares internacionales que se ocupan de requisitos para controles de seguridad. Sin embargo,
generalmente se ocupan de controles a un nivel demasiado alto como para ser una fuente de requisitos concreta de con-
troles operacionales.
8.4 Relación con el desarrollo de Common Criteria

Los Common Criteria son un estándar técnicamente idéntico a la Norma ISO/IEC 15408, publicados por el Common
Criteria Development Board, una asociación de planes nacionales para la evaluación y la certificación. La versión 3.1,
revisión 2 [11] de los Common Criteria es equivalente a la tercera edición de la Norma ISO/IEC 15408, que se usó
como base para esta edición de este informe técnico.
Actualmente el Common Criteria Development Board está solicitando ideas para cambios importantes en los Common
Criteria. De ser adoptadas, probablemente se reflejarán en futuras revisiones de la Norma ISO/IEC 15408.
9 EVALUACIÓN DE SISTEMAS OPERACIONALES
9.1 Introducción
Los sistemas operacionales deben ser evaluados utilizando el modelo general de evaluación definido en la Norma
ISO/IEC 15408-1, con las extensiones definidas en este capítulo.
9.2 Roles y responsabilidades de la evaluación

Hay tres tipos de actividad necesarios para la evaluación del sistema operacional. Estos son:
– producción de evidencias para la evaluación (que incluye la evaluación del riesgo, la especificación, desarrollo e
integración, operación, modificación de SST);
– evaluación (incluyendo la certificación de los resultados de la evaluación);
– acreditación.
Para cada una de estas actividades debe asignarse personal adecuado, acordar sus términos de referencia y realizarse las
tareas necesarias. Estas actividades y sus roles y responsabilidades asociados se listan en la tabla 1. Cada una de las
distintas acciones requeridas por este informe técnico debería mapearse con los roles y responsabilidades identificados
en la tabla 1. Cada una de las distintas acciones debería asimismo mapearse con las secciones SST identificadas en la
tabla.
- 35 - ISO/IEC TR 19791:2010
Tabla 1 – Roles y responsabilidades en la evaluación del sistema operacional
Actividad Rol Responsabilidad Secciones SST

Producción de Gestor Senior Responsabilidad general de seguridad. N/A
la evidencia Define riesgos aceptables.
de evaluación
Aprueba acciones de oficiales autorizados.
Oficiales de la organiza- Evalúa y acepta riesgos residuales. Definición del problema de
ción autorizados seguridad
Agencia de seguridad Establece políticas de seguridad en toda la orga- Definición del problema de
nización. seguridad
Define controles obligatorios a implantar en todos los
sistemas de la organización.
Propietario del sistema Conduce la evaluación del riesgo. Definición del problema de
Define los problemas de seguridad de los que ha de seguridad
ocuparse el sistema (incluyendo objetivos, requi- Objetivos de seguridad
sitos). Requisitos de seguridad
Prepara cualquier SSP (tal vez como parte de un Descripción del STOE
consorcio de propietarios de sistemas similares).
Autoriza la reevaluación basada en cambios al siste-
ma o su entorno.
Revisa el estado del sistema a partir de informes
continuos de monitorización.
Desarrollador / Integra- Producción o apoyo a la producción del SST basado Descripción del STOE
dor /Diseñador del sis- en el problema de seguridad definido por el pro- Controles técnicos
tema pietario del sistema.
Requisitos de garantía
Producción de evidencias de desarrollo. relativos al desarrollo
Asistencia al propietario del sistema para reducir o Arquitectura y
eliminar vulnerabilidades encontradas durante la eva- especificaciones resumen
luación.
Operador / Apoyo a la producción del SST. Controles operacionales
Administrador / Producción de evidencias operacionales. Requisitos de garantía
Mantenedor relativos a la operación
Asistencia al propietario del sistema para reducir o
eliminar vulnerabilidades encontradas durante la Arquitectura y
operación del sistema. especificaciones resumen
Evaluación Evaluador / agente de Evalúa el sistema basándose en los requisitos de Todas
certificación seguridad articulados en el SST para determinar la
capacidad del sistema de cumplir con sus requisitos
de seguridad en ese momento.
Ofrece una evaluación independiente de las
operaciones del sistema de seguridad a lo largo de
toda la operación del sistema.
Realiza la reevaluación, es requerida, para soportar
cambios al sistema o su entorno.
Certifica los resultados de la evaluación.
Ofrece informes de evaluación y certificación al
propietario del sistema, con recomendaciones, según
sean requeridos, para soportar la acreditación/auto-
rización del sistema.
Acreditación Acreditador Autoriza el sistema para su uso o confirma al oficial Definición del problema de
autorizado que los riesgos residuales previstos son seguridad
aceptables.
ISO/IEC TR 19791:2010 - 36 -
9.3 Evaluación del riesgo y determinación de riesgos inaceptables

Antes de la evaluación del sistema operacional, el propietario del sistema debe evaluar el ámbito del sistema opera-
cional, determinar los activos que necesitan protección y, de acuerdo con el oficial autorizado o representante designado
por la alta dirección, determinar el nivel de riesgo que la organización está dispuesta a aceptar si cada activo del sistema
operacional se pierde, daña o compromete.
El propietario del sistema debe después realizar una evaluación del riesgo que cubra todos los activos del sistema
operacional, incluyendo esos riesgos que se ven contrarrestados o eliminados por los controles de seguridad existentes.
Estos controles existentes deben documentarse como parte de la evaluación del riesgo, de forma que puedan ser
incluidos en la descripción del SST de los objetivos de seguridad.
NOTA Este informe técnico no prescribe ningún modelo o forma concreta para la evaluación del riesgo. Puede encontrarse más información acerca
de la evaluación del riesgo de sistemas ICT en la Norma ISO/IEC 27005.
Cuando existan riesgos para los activos que estén por encima del nivel de riesgo que la organización está dispuesta a
tolerar, el propietario del sistema debe identificar un curso de acción propuesto para reducir el riesgo a un nivel
aceptable. Esto puede tomar la forma de:
– aceptación del riesgo, aceptando el riesgo incrementado y reconociendo la responsabilidad por las consecuencias si
el riesgo se materializa;
– transferencia del riesgo, transfiriendo a otro el riesgo o responsabilidad por sus consecuencias;
– evitar el riesgo, por ejemplo abandonando la actividad que causa el riesgo;
– reducción o eliminación del riesgo, reduciendo el riesgo a un nivel tolerable a través de la implantación de contra-
medidas evaluadas dentro del sistema operacional para reducir la probabilidad o el impacto del riesgo.
Tras este análisis todos los riesgos deben ser categorizados como aceptables o no aceptables desde el punto de vista del
sistema operacional. Los riesgos aceptables son aquéllos que tolerados, aceptados, transferidos o evitados. Los riesgos
inaceptables son los que hay que reducir o eliminar.
Cuando los riesgos sean inaceptables, el propietario del sistema en conjunción con el desarrollador del mismo debe
identificar y especificar controles de seguridad técnicos y operacionales a implantar como contramedidas. El propietario
del sistema en conjunción con el desarrollador del mismo debe asimismo identificar y especificar controles de
aseguramiento para confirmar que el riesgo de que los controles de seguridad técnicos y operacionales no cumplan con
sus objetivos de seguridad como contramedidas se reduce a un nivel que la organización está dispuesta a tolerar.
Como parte de la fase de operación del ciclo de vida del sistema, el propietario del sistema debe revisar periódicamente
la evaluación del riesgo para determinar si:
– hay cambios en los activos de negocio;
– hay nuevos riesgos o cambios en los riesgos de los activos;
– las contramedidas existentes siguen siendo apropiadas.
Luego el propietario debe determinar si hay una necesidad de que el sistema sea reevaluado para confirmar la ade-
cuación y efectividad continuada de los controles de seguridad del sistema operacional ante la evaluación del riesgo
revisada.
9.4 Definición del problema de seguridad

El propietario del sistema debe definir el problema se seguridad del que ha de ocuparse el sistema operacional y evaluar
la evaluación. La descripción del problema de seguridad debe incluir:
- 37 - ISO/IEC TR 19791:2010
– los resultados de la evaluación del riesgo;
– cualesquiera políticas de seguridad organizativa que sean de aplicación al sistema.
9.5 Objetivos de seguridad

El propietario del sistema debe preparar una declaración de objetivos de seguridad para el sistema operacional. Los
objetivos de seguridad deben ofrecer una declaración concisa de la respuesta buscada a los problemas de seguridad
afrontados por el sistema operacional.
Para la evaluación del sistema operacional, deben distinguirse dos tipos de objetivo de seguridad:
a) objetivos funcionales de seguridad, que se satisfarían con controles técnicos y operacionales implantados dentro del
sistema operacional;
b) objetivos de garantía de seguridad que se verán satisfechos por controles de aseguramiento (por ejemplo, actividades
de verificación).
En la evaluación bajo la Norma ISO/IEC 15408, los objetivos de seguridad funcional normalmente se implantan exclu-
sivamente mediante controles técnicos, ya que el entorno operacional no se evalúa, sino que se define mediante supo-
siciones dentro de la definición del problema de seguridad. Dentro de la evaluación de un sistema operacional, se inclu-
ye el entorno operacional dentro del ámbito de evaluación y los objetivos funcionales pueden implantarse como contro-
les técnicos, controles operacionales o una combinación de ambos. Por supuesto ambos controles técnicos y operacio-
nales pueden implicar controles o acciones de gestión asociados.
La declaración de objetivos de seguridad debe cubrir todos los objetivos de seguridad, incluyendo tanto los objetivos
que ya estén satisfechos con los controles existentes así como los objetivos que deben satisfacerse con controles
adicionales implantados como parte del sistema operacional.
Distintos dominios de seguridad podrían tener distintos objetivos de nivel de aseguramiento de seguridad así como
distintos objetivos funcionales de seguridad. Esto podría pasar porque se aceptaran distintos niveles de riesgo residual
en distintos dominios.
Algunos objetivos de seguridad podrían aplicarse a todo el STOE pero deben ser implantados utilizando distintos
requisitos funcionales o de garantía de seguridad en distintos dominios. Esto podría pasar porque los mismos tipos de
controles no son posibles en todos los dominios o porque se requiere un nivel de aseguramiento equivalente en todos los
dominios, pero debe obtenerse por distintos medios.
9.6 Requisitos de seguridad
9.6.1 Introducción
El propietario del sistema debe preparar una serie de requisitos de seguridad para el sistema operacional. Los requisitos
de seguridad deben definir una serie de controles de seguridad a implantar dentro del sistema operacional para satisfacer
los objetivos funcionales de seguridad y debe definir los requisitos de garantía para confirmar que esos controles
satisfacen los objetivos de garantía de seguridad.
9.6.2 Requisitos funcionales de seguridad

Deben seleccionarse controles técnicos de seguridad de las clases funcionales definidas en la Norma ISO/IEC 15408-2.
Deben seleccionarse controles operacionales de seguridad de las clases funcionales definidas en el anexo B.
Cuando puedan implantarse controles mediante una combinación de medidas de seguridad técnicas y operacionales,
deben seleccionarse de las clases funcionales definidas en el anexo B. Los controles apropiados se indican por el uso de
la abreviatura SSF para indicar que podrían usarse medidas ya sean técnicas u operacionales.
ISO/IEC TR 19791:2010 - 38 -
Los controles que deban implantarse como una combinación concreta de medidas técnicas y operacionales deben subdi-
vidirse primero en requisitos técnicos y operacionales separados y especificarse luego como se ha definido con anterio-
ridad.
Si no existen componentes apropiados ni en la Norma ISO/IEC 15408-2 ni en el anexo B de este documento para satis-
facer algún objetivo concreto funcional de seguridad, deben crearse y definirse componentes adicionales a medida de
acuerdo con el procedimiento definido en la Norma ISO/IEC 15408-1, anexo B.
La tabla 2 muestra una comparación entre las clases funcionales definidas en la Norma ISO/IEC 15408 y este informe
técnico y su aplicabilidad a la evaluación del sistema operacional.
Tabla 2 – Comparación de clases funcionales
ISO/IEC 15408 Sistema operacional Aplicabilidad y cobertura

Auditoría de seguridad (FAU) Aplicable a sistema Igual que 15408
Comunicación (FCO) operacionales
Soporte criptográfico (FCS)
Protección de datos de usuarios
(FDP)
Identificación y autenticación (FIA)
Gestión de seguridad (FMT)
Privacidad (FPR)
Protección del TSF (FPT)
Utilización de recursos (FRU)
Acceso al TOE (FTA)
Canales de confianza (FTP)
Control administrativo Políticas, Personal, Gestión del riesgo, Gestión
(FOD) de incidentes, Organización de seguridad,
Acuerdos de servicio
Control de sistema TI (FOS) Políticas, Configuración, Seguridad de red,
Monitorización, Control de personal, Activos
del sistema operacional, Registros
Control de activos del Protección de datos privados, Activos del
usuario (FOA) usuario
Control de negocio (FOB) Políticas, Continuidad
Control de instalaciones y Móviles, Equipos removibles, Equipos
equipos (FOP) remotos, Sistema, Instalaciones
Control de terceros (FOT) Gestión
Gestión (FOM) Parámetros de seguridad, Clasificación de
activos, Responsabilidad del personal,
Organización de seguridad, Informes de
seguridad
9.6.3 Requisitos de garantía de seguridad

Los requisitos de garantía deben seleccionarse de las clases de aseguramiento definidas en el anexo C. las clases de
aseguramiento del anexo C se basan en su mayor parte en clases de aseguramiento de la Norma ISO/IEC 15408-3, pero
generalizadas para ser aplicadas tanto para medidas de seguridad técnicas como operacionales.
- 39 - ISO/IEC TR 19791:2010
Si no existen componentes de aseguramiento apropiados en el anexo C para satisfacer algún objetivo concreto de
garantía de seguridad, puede ser posible utilizar componentes de aseguramiento de la Norma ISO/IEC 15408-3. Si no
existen componentes de aseguramiento apropiados ni en el anexo C ni en la Norma ISO/IEC 15408-3, deben crearse y
definirse componentes adicionales a medida de acuerdo con el procedimiento definido en la Norma ISO/IEC 15408-1,
anexo B.
La tabla 3 muestra una comparación entre las clases de aseguramiento definidas en la Norma ISO/IEC 15408 y este
informe técnico y su aplicabilidad a la evaluación de un sistema operacional.
Tabla 3 – Comparación de clases de aseguramiento
ISO/IEC 15408 Sistema operacional Aplicabilidad

APE: Evaluación del Perfil de Evaluación del Perfil de Especificación del SPP
Protección Protección del Sistema (ASP)
ASE: Evaluación del Objetivos Evaluación del Objetivos de Especificación del SST
de Seguridad Seguridad del Sistema (ASS)
ADV: Desarrollo Documento de arquitectura, Interfaces y configuración de componentes
diseño y configuración del Interfaces externas
sistema operacional (ASD) Arquitectura, flujo de información, acceso al
STOE
Modo de condición de operación/transición
AGD: Documentos guía Documento guía del sistema Reglas y procedimientos para guía de Usuario
operacional (AOD) y Administrador
Conformación y verificación (tiempo de
operación)
ALC: Soporte de ciclo de vida Gestión de configuración del Gestión de configuración (plan, sistema CM)
sistema operacional (AOC) Configuración segura de productos
componentes
Reutilización de resultados de evaluación de
productos
ATE: Pruebas Pruebas del sistema operacional Pruebas funcionales, de cobertura y
(AOT) profundidad de las SSF
Pruebas independientes de las SSF
Pruebas de regresión en el momento del
mantenimiento/modificación
AVA: Evaluación de vulnera- Evaluación de vulnerabilidades Detección de estados inseguros y su
bilidades del sistema operacional (AOV) recuperación
Pruebas de penetración (tanto en tiempo de
operación como tras mantenimiento/modifi-
cación
ACO: Composición Ninguna No aplicable a sistemas operacionales
– Preparación para operación en Formación en concienciación y comunicación
tiempo real (APR) de las SSF
Confirmación y verificación (tiempo real)
– Registros sobre el sistema Registros del log de las SSF
operacional Revisión de gestión sobre las SSF
Verificación independiente de las SSF
Confirmación y verificación de registros
ISO/IEC TR 19791:2010 - 40 -
9.7 El Objetivo de Seguridad del Sistema (SST)

El propietario del sistema debe registrar la definición del problema de seguridad, los objetivos de seguridad y los
requisitos de seguridad para un sistema operacional en un Objetivo de Seguridad del Sistema (SST). El propietario debe
además obtener y documentar la otra información requerida para completa el SST como se identifica en el anexo A.
NOTA Un Objetivo de Seguridad del Sistema es distinto de un Objetivo de Seguridad del Sitio, una forma de documentación utilizada en algunos
planes de certificación para permitir la reutilización de resultados de evaluación de entornos de desarrollo de productos. El Objetivo de
Seguridad del Sitio también se abrevia habitualmente como SST.
Cuando el propietario de un sistema operacional quiere definir los requisitos para un sistema operacional con indepen-
dencia de la implantación, puede producir o adoptar primero un Perfil de Protección del Sistema (SPP). Los contenidos
obligatorios y opcionales de un SPP se definen en el anexo A.
El SST sirve como base tanto para la documentación de las capacidades de seguridad del sistema operacional como para
la evaluación de esas capacidades dentro del STOE. Como tal, ofrece la evidencia e información necesarias para realizar
una evaluación.
Un SST difiere de un ST debido a su foco tanto en los controles técnicos como operacionales del sistema operacional.
Un SST puede dividirse en varios dominios distintos de seguridad con distintos controles funcionales y de asegura-
miento. Sin embargo, igual que en un ST, un SST puede evaluarse en su consistencia independientemente del STOE.
En consecuencia, la evaluación del STOE puede identificar inconsistencias entre el SST y el STOE. Los tipos de
discrepancias pueden incluir:
a) aspectos del entorno del sistema operacional que así implantados estén en desacuerdo con el entorno operacional
especificado en el SST;
b) aspectos de la funcionalidad de seguridad del sistema operacional que así implantada sea distinta de la especificada
en el SST;
c) aspectos de las interfaces e interconexiones del sistema operacional y su comportamiento que así implantados estén
en desacuerdo con las interfaces del sistema operacional especificadas en el SST.
El propietario del sistema debe determinar si el entorno, funcionalidad o interfaz/interconexión implantados son los
requeridos y si la descripción en el SST es errónea o si el entorno, funcionalidad o interfaz/interconexión deberían ser
como se especificaron en el SST. Tras completar la evaluación, deben realizarse los cambios apropiados. Estos cambios
pueden generar cambios en el SST y/o el sistema operacional. Por estas razones, es imposible que la evaluación del SST
ofrezca un veredicto final respecto de si el SST es una representación correcta del sistema operacional deseado. Solo
cuando se complete la evaluación del STOE se hayan resuelto las inconsistencias puede confirmarse el SST como una
representación correcta.
La tabla 4 muestra una comparación entre el ST definido en la Norma ISO/IEC 15408 y el SST definido en este informe
técnico y su aplicabilidad a la evaluación del sistema operacional.
- 41 - ISO/IEC TR 19791:2010
Tabla 4 – Comparación de elementos del objetivo de seguridad
ISO/IEC 15408 Sistema operacional Aplicabilidad a sistemas operacionales

Introducción Introducción Deberían definirse las partes TI / operacionales del STOE e
interfaces con sistemas operacionales externos.
Podría definirse la organización del dominio.
Declaraciones de Declaraciones de Podrían definirse declaraciones de cumplimiento de SPP, PP o
conformidad conformidad ST.
Definición del Definición del problema Deberían definirse riesgos en lugar de amenazas.
problema de seguridad de seguridad No deben definirse suposiciones, porque los entornos son reales.
Objetivos de seguridad Objetivos de seguridad Deberían definirse objetivos de seguridad de TI y partes
operacionales del STOE y sistemas operacionales externos.
Requisitos de seguridad Requisitos de seguridad Requisitos funcionales para las partes TI del STOE
Requisitos operacionales para las partes operacionales del STOE
Deberían definirse requisitos de garantía
Especificación resumen Especificación resumen Deberían describirse especificaciones funcionales, operacio-
del TOE del STOE nales y de aseguramiento.
Introducción al dominio Deberían definirse partes TI / operacionales del dominio.
Definición del problema Deberían definirse riesgos y OSP.
de seguridad del
dominio
Objetivos de seguridad Deberían definirse objetivos de seguridad para partes TI y
del dominio operacionales del dominio.
Requisitos de seguridad Deberían definirse requisitos funcionales para partes TI y ope-
del dominio racionales del dominio.
Deberían definirse requisitos de garantía para el dominio.
Especificación resumen Deberían describirse especificaciones funcionales, operacio-
del dominio nales y de aseguramiento para el dominio.
Declaración de Podría definirse una declaración de cumplimiento de SPP, PP o
cumplimiento del ST para el dominio.
dominio
9.8 Reevaluación periódica

El propietario del sistema debe especificar controles para garantizar que los resultados de la evaluación siguen siendo
válidos durante la operación del sistema.
Esto puede hacerse de dos maneras:
– pueden especificarse controles de gestión para verificar periódicamente que la configuración de los controles
técnicos se ha mantenido y las medidas de control operacional se están implantando fielmente. Para hacer esto,
deben crearse una serie de procesos y procedimientos para gestionar el impacto de seguridad de los cambios ocurrirá
a medida que se llevan a cabo en el entorno operacional. Debe incluirse una prueba de regresión de todos los
cambios del sistema para garantizar que los controles del sistema no se modifican o desactivan;
– un evaluador puede reevaluar periódicamente el STOE del sistema operacional, concentrándose en si la combina-
ción de medidas de control técnico y operacional necesitan ajustes para cumplir con los requisitos cambiantes de se-
guridad de la organización y confirmar que los procesos y procedimientos operacionales se aplican eficientemente.
ISO/IEC TR 19791:2010 - 42 -
ANEXO A (Normativo)
PERFILES DE PROTECCIÓN Y OBJETIVOS DE SEGURIDAD DEL SISTEMA OPERACIONAL
A.1 Especificación de Objetivos de Seguridad del Sistema
A.1.1 Visión general

Esta sección define el concepto y contenido de un Objetivo de Seguridad del Sistema (SST).
Tabla A.1 – Resumen de diferencias entre ST y SST
“Producto” ST SST
Marco de Centrado en una “caja”. Amplia el foco para ocuparse de agrupaciones mayores y
especificación más complejas de componentes del sistema, que pueden
descomponerse en dominio de seguridad.
Objetivos de Específico de TI y sin mapeo Objetivos concretos que se remontan a requisitos de garantía
seguridad directo de objetivos de segu- concretos. Relaciones de controles operacionales (físicas,
ridad con requisitos de ga- procedimentales y políticas) y su contribución a la seguridad
rantía. documentada del sistema y las medidas de aseguramiento
seleccionadas.
Documentación del Se ocupa mínimamente fuera Debería definirse y documentarse con claridad. No hay
entorno del área de evaluación del ries- suposiciones.
go y se considera suposi-
ciones.
Evaluación del Cita no TI, especialmente pro- Identifica los riesgos como “conocidos” y los controles
riesgo cedimientos, como suposicio- operacionales pueden requerir la evaluación respecto de su
nes y relacionados con el cum- adecuación a un entorno integrado del sistema.
plimiento del producto.
Descripción del Centrado en TI Define el entorno de los controles técnicos y operacionales,
TOE sus interfaces y sus interrelaciones.
Declaraciones de Estrictamente para funcionali- Puede reasignar funcionalidades entre componentes del
cumplimiento dades de TI sistema (por ejemplo, controles técnicos y operacionales).
Arquitectura del Basada en productos “stand Normalmente dividida en distintos dominios de seguridad
sistema alone” con controles diferentes. Indica interacciones entre dominios
y entre dominios y el entorno que les rodea.
El SST ofrece una especificación para las capacidades de seguridad implantadas de un sistema operacional como se
emplea en un contexto operacional concreto para responder a riesgos evaluados o aplicar políticas de seguridad
organizativa indicadas para alcanzar un nivel aceptable de riesgo residual. El sistema operacional está compuesto por
una combinación integrada de funciones de control técnicas y operacionales. El SST describe los requisitos y
comportamientos de las funciones que implantan los objetivos de seguridad a través de una combinación de mecanismo
basados en tecnología y operaciones. Además, el SST describe las medidas que ofrecen aseguramiento en términos de
capacidad del sistema operacional de cumplir con sus objetivos funcionales mientras operan a un nivel aceptable de
riesgo residual.
- 43 - ISO/IEC TR 19791:2010
El SST sirve como base apropiada para realizar la evaluación del sistema operacional. El SST debe por tanto ofrecer
una descripción del sistema operacional que sea:
a) suficientemente completa. Cada riesgo es suficientemente compensado y cada política de seguridad organizativa
está suficientemente aplicada por la combinación de funciones de control técnicas y operacionales;
b) una solución apropiada y necesaria para el problema planteado. La combinación de funciones de control técnicas y
operacionales es eficaz en compensar los riesgos no aceptables y aplicar las políticas de seguridad organizativas y
las medidas de aseguramiento ofrecen la suficiente garantía de que las funciones de seguridad están implantadas
correcta y eficazmente;
c) una instanciación precisa de cualquier SPP, PP o ST con el que declare cumplimiento, ya sea en todo o en parte.
El concepto y estructura de un SST se basa en la expansión del concepto y estructura de la Norma ISO/IEC 15408 para
Objetivos de Seguridad (ST). La tabla A.1 anterior ofrece un resumen de las diferencias conceptuales entre un ST y un
SST.
A.1.2 Contenidos del SST

Un SST debe ser conforme con los requisitos de contenido descritos en este anexo. Un SST debería presentarse como
un documento orientado al usuario que minimice las referencias a otro material que pueda no estar disponible fácil-
mente para el usuario del SST. La justificación puede proporcionarse por separado, si resulta apropiado.
Un SST debe incluir lo siguiente:
a) una parte común aplicable a todo el STOE;
b) partes de dominios, una para cada dominio de seguridad definido dentro del STOE describiendo los aspectos únicos
de ese dominio.
La parte común debe contener:
a) introducción del SST;
b) declaraciones de conformidad;
c) definición del problema de seguridad;
d) objetivos de seguridad;
e) definición de componentes extendidos;
f) requisitos de seguridad;
g) resumen de especificaciones del STOE.
Para cada dominio de seguridad que forma parte del sistema operacional, debe incluirse lo siguiente:
a) introducción del dominio de seguridad;
b) declaraciones de conformidad del dominio de seguridad;
c) definición del problema de seguridad del dominio de seguridad;
d) objetivos de seguridad del dominio de seguridad;
ISO/IEC TR 19791:2010 - 44 -
e) requisitos de seguridad del dominio de seguridad;
f) resumen de especificaciones del dominio de seguridad.
Ciertas secciones del SST pueden quedar vacías si no hay que ofrecer ninguna información relevante. Las declaraciones
de conformidad solo aparecen si el SST afirma cumplir con uno o más SSP, PP o ST. Ciertas subsecciones de infor-
mación del dominio de seguridad son opcionales. Solo hay que especificar si los dominios de seguridad tienen proble-
mas, objetivos o requisitos únicos de seguridad que no aplican al STOE como un todo.
Las especificaciones presentadas en esta sección derivan en parte de las especificaciones del ST contenidas en la Norma
ISO/IEC 15408-1, anexo A y en parte de requisitos adicionales del SST definidos en este informe técnico.
A.1.3 Introducción del SST

La introducción del SST debe identificar el SST y el STOE y ofrecer una visión general del STOE, una descripción del
STOE y la organización de los dominios. Debe contener gestión del documento e información general como la siguiente:
a) la identificación del SST/STOE debe ofrecer los nombres e información descriptiva necesarios para controlar e
identificar tanto el SST como el STOE a los que se refiere;
b) la visión general del STOE debe resumir los objetivos del STOE de forma narrativa. La visión general debería ser
lo suficientemente detallada como para que un usuario potencial del SST determine si el SST resulta de interés;
c) la descripción del STOE debe bosquejar las funciones y límites del STOE en forma narrativa;
d) la especificación de la organización de dominios debe describir la división del STOE en dominios con requisitos
únicos de seguridad.
No hay contenido prescrito o plantilla para la visión general del STOE, pero debería especificar el propósito o misión
del sistema operacional, una visión general del sistema en el contexto de su entorno operacional y descripciones del
sistema desde el punto de vista del negocio, la dirección y la arquitectura técnica. Debería definir la relación entre el
STOE y los sistemas operacionales externos y las interfaces entre el STOE y esos sistemas.
No hay contenido prescrito o plantilla para la descripción del STOE, pero debería describir el ámbito y límites del
STOE tanto desde el punto de vista lógico como físico. Debería asimismo describir la organización y localización en la
que se desarrolló el STOE, incluyendo cualquier característica única para dominios individuales, por ejemplo, dominios
basados en productos comerciales.
Los sistemas operacionales están compuestos por uno o más dominios de seguridad. Cada dominio de seguridad incluye
algunos componentes y puede tener sus propios requisitos de garantía de seguridad. La especificación de la organización
de dominios debe documentar la organización de los dominios de seguridad, sus límites y sus interfaces con detalle.
En el mejor de los casos, el STOE estará compuesto de componentes que definan completamente el sistema operacional
como una entidad cerrada en la que no haya interfaces con sistemas operacionales externos que no estén incluidos en la
evaluación. Desde un punto de vista práctico, este caso más óptimo a veces no es posible y es necesario definir una
clara partición entre aquellas partes del sistema operacional que serán evaluadas como una unidad integrada y aquellas
partes que estén fuera del ámbito de la evaluación. Los componentes que estén fuera del ámbito de evaluación se tratan
como parte de sistemas operacionales externos.
El concepto de sistema operacional se basa en las interfaces que existen entre los componentes del sistema operacional. Sin
interfaces no hay sistema operacional. Por tanto las interfaces resultan críticas para la definición del sistema operacional e
igualmente críticas para la capacidad del sistema operacional de aplicar una política de seguridad a través de sus interfaces.
La especificación de la organización de dominios ofrecerá una visión general de los distintos componentes del sistema
operacional, incluyendo como interactúan. Los detalles de las interfaces se dejan a la especificación de interfaces para el
diseño e integración del sistema operacional. Sin embargo la especificación de la organización de dominios debería
identificar todas las propiedades de seguridad de los dominios individuales que se aplican en otros dominios y también
todos los servicios de seguridad ofrecidos por dominios individuales que estén disponibles para otros dominios.
- 45 - ISO/IEC TR 19791:2010
A.1.4 Declaraciones de conformidad

Esta sección solo es aplicable si el SST afirma cumplir con uno o más SPP, PP, ST o paquetes de requisitos de segu-
ridad. La sección de declaraciones de conformidad ofrece evidencias de que el SST es una instanciación aceptable de
cualquier SPP, PP, ST o paquete de requisitos del que se haya afirmado su cumplimiento. Una justificación de
declaraciones de conformidad debe demostrar coherencia entre los objetivos y requisitos del SST y los de cualquier
SPP, PP, ST o paquete de requisitos cuya conformidad se afirme.
El enfoque de la declaración de conformidad se centra en la “equivalencia” en términos de cumplir el grupo base de cri-
terios establecidos en los SPP, PP, ST o los paquetes de requisitos. El SST puede ser un supergrupo funcional de un
paquete o perfil, pero no debe ser un subgrupo.
Una diferencia principal entre las declaraciones de conformidad del sistema operacional y las de productos es que para
el sistema operacional puede ser apropiado reasignar la funcionalidad entre las partes de control técnico y operacional
del sistema operacional, porque se considere a todo como parte del STOE. En una evaluación de producto, la asignación
de la funcionalidad de TI al entorno no TI cambia todo el concepto del producto y acaba con el propósito de la actividad
de evaluación del producto.
A.1.5 Definición del problema de seguridad
A.1.5.1 Visión general

La definición del problema de seguridad del SST debe ofrecer una definición coherente, consistente y suficientemente
completa de los problemas de seguridad que el sistema operacional pretende resolver. Los problemas de seguridad se
indican en términos de los riesgos que combatirá el sistema operacional y las políticas de seguridad organizativas que
apoyan y gobiernan el uso del sistema operacional para reducir el riesgo del sistema operacional a un nivel aceptable.
La definición del problema de seguridad debe definir:
a) todos los riesgos que son aplicables al STOE;
b) todas las políticas organizativas que aplican al STOE.
En esta sección, deberían definirse los problemas de seguridad que afecten a todo el STOE. Es posible que distintos
dominios de seguridad del STOE se ejecuten en distintos entornos operacionales y como consecuencia puede haber
riesgos o políticas distintos o únicos de los que deban ocuparse independientemente distintos dominios de seguridad del
sistema operacional. Para cada dominio de seguridad deberían definirse problemas de seguridad adicionales que afecten
solo a ese dominio.
Reconociendo que esta sección viene precedida de la introducción del STOE, es importante que cualquier material
incluido en esta sección del SST sea consistente con la información ofrecida en la introducción del STOE.
A.1.5.2 Identificación del riesgo

En esta sección deben describirse todos los riesgos que sean aplicables al STOE en base a una evaluación del riesgo del
sistema operacional. Cada riesgo debe categorizarse como aceptable o inaceptable, es decir, requiriendo su reducción o
eliminación a través de controles técnicos y operacionales dentro del STOE. Aquellos riesgos que se acepten deben aún
así ser identificados, ya que la aceptabilidad de los riesgos puede cambiar con el tiempo.
La lista de riesgos debe incluir riesgos relacionados con el desarrollo del sistema operacional. La descripción de cada
riesgo debe estar suficientemente detallada como para identificar los activos que puedan ser dañados o comprometidos,
las amenazas y vulnerabilidades aplicables a cada activo y el impacto de ataques con éxito. Las amenazas deberían
cualificarse en términos de los agentes de amenazas asociados y sus acciones potencialmente adversas sobre los activos.
La evaluación de riesgos debería identificar todos los riesgos posibles para el sistema operacional, incluyendo aquellos
riesgos que se ven compensados o eliminados por los controles de seguridad existentes.
ISO/IEC TR 19791:2010 - 46 -
NOTA Los agentes de amenazas pueden incluir acontecimientos naturales como accidentes, así como seres humanos y procesos informáticos
actuando por sí mismos.
Con el tiempo pueden identificarse riesgos adicionales o cambiar las consecuencias de una violación de seguridad. La
evaluación del riesgo debe repetirse a través del ciclo de vida del sistema y, si es necesario, actualizar el SST y reeva-
luar el sistema operacional.
En esta sección, deberían identificarse y categorizarse aquellos riesgos relacionados con la operación del sistema en su
conjunto, por ejemplo, los riesgos relacionados con empleados o activos de negocio. Algunos riesgos, por ejemplo los
riesgos relacionados con el procesamiento de aplicaciones, pueden aplicarse solo a un dominio de seguridad concreto y
deberían por tanto identificarse y analizarse solo para dicho dominio.
A.1.5.3 Políticas de seguridad organizativa (OSP)

En sistemas operacionales, el ámbito de la OSP se extiende para incluir la gestión del ciclo de vida y asuntos de
operaciones de las que no se ocupa la evaluación bajo la Norma ISO/IEC 15408. Estas políticas incluyen:
a) leyes, mandatos y directivas gubernamentales;
b) continuidad de negocio;
c) acuerdos de uso interorganizacionales (por ejemplo, Acuerdo entre servicios (ISA, Inter-Service Agreement) o
Memorándum de comprensión (MOU, Memorandum of Understanding)).
A.1.6 Objetivos de seguridad

Los objetivos de seguridad contenidos en la sección de objetivos de seguridad del SST deben ofrecer una descripción de
alto nivel coherente, consistente y suficientemente completa de la solución de seguridad basada en la definición de los
riesgos inaceptables y las políticas de seguridad organizativa en la sección de definición del problema de seguridad. La
descripción de alto nivel se hace en términos de objetivos de seguridad funcional que son posteriormente asignados a
los controles técnicos y operacionales del sistema operacional o a otros sistemas operacionales que interactúan con el
sistema operacional. Una justificación de los objetivos de seguridad debe demostrar que los objetivos de seguridad
indicados son trazables para todos los aspectos identificados en la definición del problema de seguridad del SST y son
apropiados para cubrirlos. Deberían ofrecer una trazabilidad completa entre los objetivos de seguridad indicados y todos
los aspectos de la declaración del problema de seguridad y deberían ofrecer suficiente información para determinar si
los objetivos de seguridad contrarrestan de forma suficiente los riesgos inaceptables indicados y aplican las políticas de
seguridad organizativa indicadas.
Hay otro tipo de objetivo de seguridad que gobierna las actividades de verificación para generar y analizar las
evidencias y observar o probar la implantación para determinar que se implementa de acuerdo con los requisitos. Este
tipo de objetivos de seguridad normalmente no se justifican en la evaluación bajo la Norma ISO/IEC 15408 (es decir,
los objetivos concretos no se remontan a requisitos de garantía concretos). En consecuencia hay poca sustancia, si es
que hay alguna, en los documentos PP/ST de productos que justifique las medidas de aseguramiento seleccionadas. Sin
embargo, para un sistema operacional, se necesita una declaración clara de objetivos de aseguramiento, deducida de
aspectos de aseguramiento del problema de seguridad, con el fin de justificar medidas de aseguramiento que se
aplicarán al conjunto del sistema operacional. Estas medidas pueden aplicarse bien en entorno de desarrollo del TOE o a
su operación.
La declaración de objetivos de seguridad debe cubrir todos los controles requeridos, incluyendo ambos controles que ya
existan y aquellos que deban crearse como parte de la implantación del sistema operacional.
Los objetivos de seguridad seleccionados para implantar un aspecto del problema de seguridad pueden asimismo
ofrecer soluciones o soluciones parciales en otras áreas. En particular, los objetivos de seguridad pueden ocuparse de
riesgos que hayan sido aceptados siguiendo la evaluación del riesgo, es decir, categorizados como tolerables, acepta-
bles, transferibles o a evitar. Estos enlaces siguen teniendo que ser identificados y registrados, ya que la aceptabilidad
de los riesgos puede cambiar con el tiempo.
- 47 - ISO/IEC TR 19791:2010
Los objetivos de seguridad ofrecen la declaración de máximo nivel de la estrategia y la filosofía para contrarrestar los
riesgos definidos y para aplicar las políticas de seguridad organizativa definidas. En los sistemas operacionales, es
crítico que los objetivos de seguridad sean precisos. La precisión se requiere tanto en términos de cómo los objetivos se
alcanzan y cubren las declaraciones hechas en la definición del problema de seguridad y también en términos de cómo
los objetivos de seguridad asignan la solución a los componentes y procesos físicos del sistema operacional.
Deben considerarse los objetivos de seguridad frente a los riesgos indicados y las políticas de seguridad organizativa
con mayor detalle cuando se comparan con cómo se consideran en el sentido del producto. Debido al impacto que tiene
el entorno con respecto a la evaluación del sistema operacional, el conocimiento detallado acerca del entorno debe
reflejarse en los objetivos de seguridad.
Además, los objetivos de seguridad del sistema operacional deben asegurar que se alcanza un equilibrio en la gestión
del riesgo residual general.
Es posible que distintos dominios de seguridad del sistema operacional soporten y se ejecuten en distintos entornos
operacionales. Por ejemplo, la capacidad del sistema operacional de monitorizar tráfico en la red interna podría
configurarse como “desactivada”, mientras que la capacidad del sistema operacional de monitorizar tráfico entrante
hacia la red interna se configura como “activada”. Como consecuencia, puede haber objetivos de seguridad distintos o
únicos para dominios de seguridad distintos. Puede asimismo haber objetivos adicionales de aseguramiento para
dominio de seguridad concretos para cumplir con requisitos de garantía únicos que apliquen solo a esos dominios.
A.1.7 Definición de componentes extendidos

En algunos casos, no existirán componentes apropiados para describir los requisitos de seguridad dentro de la Norma
ISO/IEC 15408 o este informe técnico. En esos casos, deben definirse nuevos componentes dentro de esta sección del
SST. Estos componentes extendidos pueden usarse posteriormente para definir requisitos funcionales y de asegura-
miento adicionales.
A.1.8 Requisitos de seguridad

La sección de requisitos de seguridad debe ofrecer un grupo completo y coherente de requisitos de seguridad para el
STOE. Esto incluye tanto los requisitos funcionales de seguridad del sistema operacional como los requisitos de
aseguramiento de del sistema operacional. Aplica tanto a las medidas de control técnicas como a las operacionales que
deben facilitarse para cumplir con los objetivos de seguridad del sistema operacional.
Estos requisitos deben ofrecer una base adecuada para el desarrollo de los procesos, procedimientos y servicios de
seguridad que puedan ser configurados para aplicar políticas definidas y contrarrestar riesgos identificados. Una
justificación de los requisitos de seguridad debe demostrar que el conjunto de requisitos de seguridad es capaz de
cumplir y resulta trazable para con todos los objetivos de seguridad del SST.
En algunos casos, los requisitos de seguridad para un sistema operacional pueden ser declarados sin justificación algu-
na, es decir, no derivan de objetivos de seguridad que a su vez derivaban de definiciones de problemas de seguridad. En
estos casos, las secciones de objetivos y definición del problema de seguridad del SST pueden omitirse.
La sección de requisitos de seguridad debe describir todas las funciones de seguridad del sistema y las garantías de
seguridad del sistema requeridas por el sistema operacional en términos de componentes de seguridad completos.
Es posible que distintos dominios de seguridad del sistema operacional apoyen y se ejecuten en distintos entornos
operacionales. Como consecuencia, puede haber requisitos de seguridad distintos o únicos para cada dominio de
seguridad necesarios para cumplir los objetivos de seguridad únicos para ese dominio. De forma similar, puede no
necesitarse aplicar requisitos de garantía con la misma profundidad y amplitud a lo largo de todos los componentes del
sistema operacional. Es necesario asignar el nivel y tipo de aseguramiento apropiado a los distintos dominios de
seguridad definidos en el SST.
ISO/IEC TR 19791:2010 - 48 -
A.1.9 Especificación resumen del STOE

La especificación resumen del STOE debe ofrecer un descripción de alto nivel, coherente, consistente y suficientemente
completa de los mecanismo, servicios, interfaces, controles operacionales y medidas de aseguramiento y demostrar que
éstos satisfacen los requisitos de seguridad especificados del sistema operacional. Una justificación de la especificación
resumen del STOE debe mostrar que las funciones y medidas de aseguramiento del STOE son apropiadas para cumplir
con los requisitos de seguridad del STOE.
Es necesario que se defina suficientemente el sistema operacional en el SST como para que un lector entienda la
solución ofrecida para cumplir los requisitos. Los detalles de la definición de subsistemas, interfaces y conexiones y la
asignación de requisitos funcionales a los distintos subsistemas que comprenden el sistema operacional deberían dejarse
para la posterior documentación de diseño. La arquitectura y la especificación resumen deberían ocuparse de las
interacciones entre dominios de seguridad y las interacciones entre dominios y su entorno.
A.1.10 Información del dominio de seguridad

La sección de información del dominio de seguridad del SST debe ofrecer información respecto de cada dominio de
seguridad que forme parte del sistema operacional completo. Debe ofrecer la identificación precisa y correcta de cada
dominio de seguridad y cada información de seguridad específica del dominio que se requiera.
Si hay solo un dominio de seguridad dentro del STOE, no tiene que nombrarse o especificarse explícitamente y esta
sección debería omitirse.
La información del dominio de seguridad para cada dominio de seguridad debe contener lo siguiente:
a) la introducción del dominio de seguridad debe ofrecer el nombre y la información descriptiva necesaria para
controlar e identificar el dominio de seguridad y el STOE al que se refiere y resumir el dominio en forma narrativa.
La visión general debería ser suficientemente detallada como para entender las funciones de negocio del dominio de
seguridad y sus requisitos de seguridad;
b) las declaraciones de conformidad del dominio de seguridad deben definir cualquier declaración de conformidad
que sea única para el dominio. Si el dominio de seguridad no tiene declaraciones de conformidad que sean únicas,
puede omitirse esta sección;
c) la definición del problema de seguridad del dominio de seguridad debe definir cualquier problema de seguridad
que sea único para el dominio. Esto debe incluir políticas y riesgos que sean únicos para el dominio. Si el dominio
de seguridad no tiene problemas de seguridad que sean únicos, puede omitirse esta sección;
d) los objetivos de seguridad del dominio de seguridad deben definir cualquier objetivo de seguridad que sea único
para el dominio. Esto debe incluir cualquier objetivo de seguridad que esté disponible para otros dominios o que se
implanten en otros dominios. Si el dominio de seguridad no tiene objetivos de seguridad que sean únicos, puede
omitirse esta sección;
e) los requisitos de seguridad del dominio de seguridad deben definir cualquier requisito de seguridad que sea único
para el dominio. Si el dominio de seguridad no tiene requisitos de seguridad que sean únicos, puede omitirse esta
sección;
f) la especificación resumen del dominio de seguridad debe definir cualquier mecanismo, servicio, interfaz, control
operacional y medida de aseguramiento único para el dominio. Si el dominio de seguridad no tiene mecanismos,
servicios, interfaces, controles operacionales o medidas de aseguramiento únicos, puede omitirse esta sección.
- 49 - ISO/IEC TR 19791:2010
A.2 Especificación de Perfiles de Protección del Sistema
A.2.1 Visión general

Esta sección define el concepto y contenido de un Perfil de Protección del Sistema (SPP).
Tabla A.2 – Resumen de diferencias entre PP y SPP
Producto PP Sistema PP
Marco de Centrado en una “caja”. Amplia el foco para ocuparse de agrupaciones de productos
especificación mayores y más complejas, que comprenden el sistema
operacional, con distribución físicamente dispersa y los
controles de seguridad integrados.
Foco Más estrecho y específico de TI Más amplio y flexible e incorpora aspectos de los controles de
seguridad – flexible para contar para distintos casos de
negocios.
Controles Se ocupa mínimamente fuera Se ocupa como participante completo con los controles
operacionales del área de evaluación del riesgo técnicos como contribuyente a la seguridad del sistema para
(físicos, OSP, – supone contribuciones del cumplir con las necesidades operacionales.
personal…) entorno.
Evaluación del Cita no TI, especialmente Identifica los riesgos como “conocidos” y los controles
riesgo procedimientos, como operacionales pueden pedir la evaluación respecto de su
suposiciones y relacionados con adecuación a un entorno integrado del sistema.
el cumplimiento del producto.
Descripción del Estrecha y centrada en TI Incorpora con más amplitud interfaces externas, así como
TOE interfaces a sistemas, subsistemas y componentes “exter-
nos/remotos”.
El SPP conceptualmente sirve a la misma función que un Perfil de Protección de la Norma ISO/IEC 15408: el SPP
presenta una personalización de una solución aceptable para un problema de seguridad. Sin embargo el SPP tiene que
ocuparse de la integración de controles de seguridad técnicos y operacionales y puede tener que integrar componentes o
subsistemas múltiples con diferentes políticas de seguridad o entornos operacionales.
Un SPP debe ser capaz de presentar opciones y soluciones condicionales. Un ejemplo sería en la definición de los
objetivos de seguridad. Puede haber tanto controles técnicos como operacionales que se ocupen de un riesgo concreto
que serían igualmente aceptables desde los puntos de vista de la operación y el coste. Un SPP podría ofrecer varias
soluciones aplicables y razonables para que un autor de SST elija una de ellas.
Igualmente, un SPP debe ser capaz de obligar a ciertos controles comunes de seguridad. Por ejemplo, puede haber una
política dentro de una organización en la que ciertos controles operacionales se apliquen a todos los sistemas de
información dentro de esa organización.
Finalmente, el marco de especificación debe tener la suficiente flexibilidad como para permitir que un sistema
operacional evaluado basado en un SPP sea reutilizado como componente evaluado de un sistema mayor.
Un SSP puede también usarse como parte de la obtención de especificaciones para adquirir un sistema operacional. Para
ser apropiado para este propósito, el SPP ofrecer una descripción de las capacidades de seguridad del sistema
operacional que sea:
a) suficientemente completa. Cada riesgo es suficientemente compensado y cada política de seguridad organizativa
está suficientemente aplicada por la combinación obligatoria de funciones de control técnicas y operacionales (o una
opción elegida cuando el SPP permita alternativas);
ISO/IEC TR 19791:2010 - 50 -
b) una solución apropiada y necesaria para el problema de seguridad planteado. La combinación de funciones de
control técnicas y operacionales es eficaz en compensar los riesgos no aceptables y aplicar las políticas de seguridad
organizativas y las medidas de aseguramiento ofrecen la suficiente garantía de que las funciones de seguridad están
implantadas correcta y eficazmente;
c) una instanciación apropiada de cualquier SPP o PP con el que declare cumplimiento, ya sea en todo o en parte.
El concepto y estructura de un SPP se basa en la expansión del concepto y estructura de la Norma ISO/IEC 15408 para
Perfiles de Protección (PP). La tabla A.2 anterior ofrece un resumen de las diferencias entre un PP y un SPP.
A.2.2 Contenidos del SPP

Un SPP debe ser conforme con los requisitos de contenido descritos en este anexo. Un SST debería presentarse como
un documento orientado al usuario que minimice las referencias a otro material que pueda no estar disponible
fácilmente para el usuario del SPP. La justificación puede proporcionarse por separado, si resulta apropiado.
Un SPP debe incluir lo siguiente:
a) una parte común aplicable a todo el STOE;
b) partes de dominios, una para cada dominio de seguridad definido dentro del STOE y describiendo los aspectos
únicos de ese dominio.
La parte común debe contener:
a) introducción del SPP;
b) declaraciones de conformidad;
c) definición del problema de seguridad;
d) objetivos de seguridad;
e) definición de componentes extendidos;
f) requisitos de seguridad.
Para cada dominio de seguridad que forme parte de los sistemas operacionales que cumplan el SPP, debe incluirse lo
siguiente:
a) introducción del dominio de seguridad;
b) declaraciones de conformidad del dominio de seguridad;
c) definición del problema de seguridad del dominio de seguridad;
d) objetivos de seguridad del dominio de seguridad;
e) requisitos de seguridad del dominio de seguridad.
Ciertas secciones del SPP pueden quedar vacías si no hay que ofrecer ninguna información relevante. Ciertas subsec-
ciones de información del dominio de seguridad son opcionales. Solo hay que especificarlas si los dominios de
seguridad tienen problemas, objetivos o requisitos únicos de seguridad que no aplican al STOE como un todo.
Las especificaciones presentadas en esta sección derivan en parte de las especificaciones del PP contenidas en la Norma
ISO/IEC 15408-1, anexo B y en parte de requisitos adicionales del SPP definidos en este informe técnico.
- 51 - ISO/IEC TR 19791:2010
A.2.3 Introducción del SPP

La introducción del SPP debe identificar el SPP y ofrecer una visión general del STOE, y la organización de los
dominios. Debe contener gestión del documento e información general como la siguiente:
a) la identificación del SPP debe ofrecer los nombres e información descriptiva necesarios para controlar e identificar
el SPP;
b) la visión general del STOE debe resumir el STOE representado por el SPP de forma narrativa. La visión general
debería ser lo suficientemente detallada como para que un usuario potencial del SPP determine si el SPP es de
interés. La visión general debería asimismo ser utilizable como abstracto por sí solo para su uso en catálogos y regis-
tros de SPP;
c) la especificación de la organización de dominios debe describir la división del STOE en dominios con requisitos
únicos de seguridad.
No hay contenido prescrito o plantilla para la visión general del STOE, pero debería especificar el propósito o misión
del sistema operacional, una visión general del sistema en el contexto de su entorno operacional y descripciones del
sistema desde el punto de vista del negocio, la dirección y la arquitectura técnica. Debería definir la relación entre el
STOE y los sistemas operacionales externos y las interfaces entre el STOE y esos sistemas.
Los sistemas operacionales están compuestos por uno o más dominios de seguridad. Cada dominio de seguridad incluye
algunos componentes y puede tener sus propios requisitos de garantía. La especificación de la organización de dominios
debe documentar con detalle la organización de los dominios de seguridad, sus límites y sus interfaces.
En el mejor de los casos, el STOE estará compuesto de componentes que definan completamente el sistema operacional
como una entidad cerrada en la que no haya interfaces con sistemas operacionales externos que no estén incluidos en la
evaluación. Desde un punto de vista práctico, este mejor caso a veces no es posible y es necesario definir una clara
partición entre aquellas partes del sistema operacional que serán evaluadas como una unidad integrada y aquellas partes
que estén fuera del ámbito de la evaluación. Los componentes que estén fuera del ámbito de evaluación se tratan como
parte de sistemas operacionales externos.
El concepto de sistema operacional se basa en las interfaces que existen entre los componentes del sistema operacional. Sin
interfaces no hay sistema operacional. Por tanto las interfaces son críticas para la definición del sistema operacional e
igualmente críticas para la capacidad del sistema operacional de aplicar una política de seguridad a través de sus interfaces.
La especificación de la organización de dominios ofrecerá una visión general de los distintos componentes del sistema
operacional, incluyendo como interactúan. Los detalles de las interfaces se dejan a la especificación de interfaces para el
diseño e integración del sistema operacional. Sin embargo la especificación de la organización de dominios debería
identificar todas las propiedades de seguridad de los dominios individuales que se aplican en otros dominios y también
todos los servicios de seguridad ofrecidos por dominios individuales que estén disponibles para otros dominios.
A.2.4 Declaraciones de conformidad

Esta sección solo es aplicable si el SPP afirma cumplir con uno o más SPP, PP o paquetes de requisitos de seguridad. La
sección de declaraciones de conformidad ofrece evidencias de que el SPP es una instanciación aceptable de cualquier
SPP, PP o paquete de requisitos del que se haya afirmado su cumplimiento. Una justificación de declaraciones de
conformidad debe demostrar coherencia entre los objetivos y requisitos del SPP y los de cualquier SPP, PP o paquete de
requisitos cuya conformidad se afirme.
El foco de la declaración de conformidad está en la “equivalencia” en términos de cumplir el grupo base de criterios esta-
blecidos en los SPP o PP. El SPP puede ser un supergrupo funcional de un paquete o perfil, pero no debe ser un subgrupo.
Una diferencia principal entre las declaraciones de conformidad del sistema operacional y de los productos es que para
el sistema operacional puede ser apropiado reasignar la funcionalidad entre las partes de control técnico y operacional
del sistema operacional, porque se considere a todo como parte del STOE. En una evaluación de producto, la asignación
de la funcionalidad de TI al entorno no TI cambia todo el concepto del producto y acaba con el propósito de la actividad
de evaluación del producto.
ISO/IEC TR 19791:2010 - 52 -
A.2.5 Definición del problema de seguridad
A.2.5.1 Visión general

La definición del problema de seguridad del SPP debe ofrecer una definición coherente, consistente y suficientemente
completa de los problemas de seguridad que el sistema operacional pretende resolver. Los problemas de seguridad se
indican en términos de los riesgos que combatirá el sistema operacional y las políticas de seguridad organizativas que
apoyan y gobiernan el uso del sistema operacional para cumplir los requisitos del SPP para reducir el riesgo del sistema
operacional a un nivel aceptable.
La definición del problema de seguridad debe definir:
a) todos los riesgos que son aplicables al STOE;
b) todas las políticas organizativas que aplican al STOE.
En esta sección, deberían definirse los problemas de seguridad que afecten a todos los sistemas operacionales que
cumplan los requisitos del SPP. Es posible que distintos dominios de seguridad de sistemas operacionales que cumplan
los requisitos del SPP se ejecuten en distintos entornos operacionales y como consecuencia puede haber riesgos o
políticas distintos o únicos de los que deban ocuparse independientemente distintos dominios de seguridad del sistema
operacional. Para cada dominio de seguridad deberían definirse problemas de seguridad adicionales que afecten solo a
ese dominio.
Si el riesgo operacional de un sistema operacional concreto indica que hay riesgos no identificados en el SPP, será
necesario modificar los límites del sistema para eliminar esos riesgos o introducir los riesgos adicionales en la sección
de identificación del riesgo del SST.
Reconociendo que esta sección viene precedida de la introducción del STOE, es importante que cualquier material
incluido en esta sección del SPP sea consistente con la información ofrecida en la introducción del STOE.
A.2.5.2 Identificación del riesgo

En esta sección deben describirse todos los riesgos que sean aplicables al STOE basándose en una evaluación del riesgo
del sistema operacional o de los tipos de sistema operacional cubiertos por el SPP. Cada riesgo debe categorizarse como
aceptable o inaceptable, es decir, requiriendo su reducción o eliminación a través de controles técnicos y operacionales
dentro del STOE. Aquellos riesgos que se acepten deben aún así ser identificados, ya que la aceptabilidad de los riesgos
puede cambiar con el tiempo.
La lista de riesgos debe incluir riesgos relacionados con el desarrollo del sistema operacional. La descripción de cada
riesgo debe estar suficientemente detallada como para identificar los activos o tipos de activos que puedan ser dañados
o comprometidos, las amenazas y vulnerabilidades aplicables a cada activo o tipo de activo y el impacto de ataques con
éxito. Las amenazas deberían cualificarse en términos de los agentes de amenazas asociados y sus acciones poten-
cialmente adversas sobre los activos. La evaluación de riesgos debería identificar todos los riesgos posibles para el
sistema operacional que cumplan con los requisitos del SPP.
NOTA Los agentes de amenazas pueden incluir acontecimientos naturales como accidentes, así como seres humanos y procesos informáticos
actuando por sí mismos.
Con el tiempo pueden identificarse riesgos adicionales o cambiar las consecuencias de una violación de seguridad. La
evaluación del riesgo debe repetirse a través del ciclo de vida del sistema y, si es necesario, actualizarse el SPP y reeva-
luarse el sistema operacional.
En esta sección, deberían identificarse y categorizarse aquellos riesgos relacionados con la operación de sistemas que
cumplan los requisitos del SPP en su conjunto, por ejemplo riesgos relacionados con empleados o activos de negocio.
Algunos riesgos, por ejemplo los riesgos relacionados con el procesamiento de aplicaciones, pueden aplicarse solo a un
dominio de seguridad concreto y deberían por tanto identificarse y analizarse solo para dicho dominio.
- 53 - ISO/IEC TR 19791:2010
A.2.5.3 Políticas de seguridad organizativa (OSP)

En sistemas operacionales, el ámbito de la OSP se extiende para incluir la gestión del ciclo de vida y asuntos de
operaciones de las que no se ocupa la evaluación bajo la Norma ISO/IEC 15408. Estas políticas incluyen:
a) leyes, mandatos y directivas de gobierno;
b) continuidad de negocio;
c) acuerdos de uso interorganizacionales (por ejemplo, Acuerdo entre servicios (ISA, Inter-Service Agreement) o
Memorándum de comprensión (MOU, Memorandum of Understanding)).
A.2.6 Objetivos de seguridad

Los objetivos de seguridad contenidos en la sección de objetivos de seguridad del SPP deben ofrecer una descripción de
alto nivel coherente, consistente y suficientemente completa de la solución de seguridad basada en la definición de los
riesgos inaceptables y las políticas de seguridad organizativa en la sección de definición del problema de seguridad. La
descripción de alto nivel se hace en términos de objetivos de seguridad funcional que son posteriormente asignados a
los controles técnicos y operacionales de los sistemas operacionales que cumplan los requisitos del SPP o a otros
sistemas operacionales que interactúan con dicho sistema operacional. Una justificación de los objetivos de seguridad
debe demostrar que los objetivos de seguridad indicados son trazables para todos los aspectos identificados en la
definición del problema de seguridad del SPP y son apropiados para cubrirlos. Deberían ofrecer una trazabilidad
completa entre los objetivos de seguridad indicados y todos los aspectos de la declaración del problema de seguridad y
deberían ofrecer suficiente información para determinar si los objetivos de seguridad contrarrestan de forma suficiente
los riesgos inaceptables indicados y aplican las políticas de seguridad organizativa indicadas.
Hay otro tipo de objetivo de seguridad que gobierna las actividades de verificación para generar y analizar las
evidencias y observar o probar la implantación para determinar que se implementa de acuerdo con los requisitos. Este
tipo de objetivos de seguridad normalmente no se justifica en la evaluación bajo la Norma ISO/IEC 15408 (es decir, los
objetivos concretos no se remontan a requisitos de aseguramiento concretos). En consecuencia hay poca sustancia, si es
que hay alguna, en los documentos PP/ST de productos que justifique las medidas de aseguramiento seleccionadas. Sin
embargo, para un sistema operacional, se necesita una declaración clara de objetivos de aseguramiento, deducida de
aspectos de garantía del problema de seguridad, con el fin de justificar medidas de aseguramiento que se aplicarán al
conjunto del sistema operacional. Estas medidas pueden aplicarse bien en entorno de desarrollo del TOE o a su
operación.
La declaración de objetivos de seguridad debe cubrir todos los controles requeridos, incluyendo ambos controles que ya
existan y aquéllos que deban crearse como parte de la implantación del sistema operacional.
Los objetivos de seguridad seleccionados para implantar un aspecto del problema de seguridad pueden asimismo
ofrecer soluciones o soluciones parciales en otras áreas. En particular, los objetivos de seguridad pueden ocuparse de
riesgos que hayan sido aceptados siguiendo la evaluación del riesgo, es decir, categorizados como tolerables, acep-
tables, transferibles o a evitar. Estos enlaces siguen teniendo que identificarse y registrarse, ya que la aceptabilidad de
los riesgos puede cambiar con el tiempo.
Los objetivos de seguridad ofrecen la declaración de máximo nivel de la estrategia y filosofía para contrarrestar los
riesgos definidos y para aplicar las políticas de seguridad organizativa definidas. En los sistemas operacionales, es
crítico que los objetivos de seguridad sean precisos. La precisión se requiere tanto en términos de cómo los objetivos se
remontan y cubren declaraciones hechas en la definición del problema de seguridad y también en términos de cómo los
objetivos de seguridad asignan la solución a los componentes y procesos físicos del sistema operacional.
Deben considerarse los objetivos de seguridad frente a los riesgos indicados y las políticas de seguridad organizativa
con mayor detalle cuando se comparan con cómo se consideran en el sentido del producto. Es a causa del impacto que
tiene el entorno en relación con la evaluación del sistema operacional y el conocimiento detallado acerca del entorno
que debe reflejarse en los objetivos de seguridad.
ISO/IEC TR 19791:2010 - 54 -
Además, los objetivos de seguridad del sistema operacional deben asegurar que se alcanza un equilibrio en la gestión
del riesgo residual general.
Es posible que distintos dominios de seguridad de los sistemas operacionales que cumplan los requisitos del SPP
apoyen y se ejecuten en distintos entornos operacionales. Por ejemplo, la capacidad del sistema operacional de
monitorizar tráfico en la red interna podría configurarse como “desactivada”, mientras que la capacidad del sistema
operacional de monitorizar tráfico hacia la red interna se configura como “activada”. Como consecuencia, puede haber
objetivos de seguridad distintos o únicos para dominios de seguridad distintos. Puede asimismo haber objetivos
adicionales de aseguramiento para dominio de seguridad concretos para cumplir con requisitos de garantía únicos que
apliquen solo a esos dominios.
A.2.7 Definición de componentes extendidos

En algunos casos, no existirán componentes apropiados para describir los requisitos de seguridad dentro de la Norma
ISO/IEC 15408 o este informe técnico. En esos casos, deben definirse nuevos componentes dentro de esta sección del
SPP. Estos componentes extendidos pueden luego usarse para definir requisitos funcionales y de aseguramiento
adicionales.
A.2.8 Requisitos de seguridad

La sección de requisitos de seguridad debe ofrecer un grupo completo y coherente de requisitos de seguridad para el
STOE. Esto incluye tanto los requisitos funcionales de seguridad del sistema operacional como los requisitos de
aseguramiento del sistema operacional. Aplica tanto a las medidas de control técnicas como a las operacionales a
ofrecer para cumplir con los objetivos de seguridad del sistema operacional. Estos requisitos deben ofrecer una base
adecuada para el desarrollo de procesos, procedimientos, mecanismos y servicios de seguridad que puedan configurarse
para aplicar políticas definidas y contrarrestar riesgos identificados. Una justificación de los requisitos de seguridad
debe demostrar que la serie de requisitos de seguridad es capaz de cumplir y es trazable para todos los objetivos de
seguridad del SPP.
En algunos casos, los requisitos de seguridad en un SPP pueden escribirse sin justificación, es decir, no derivan de
objetivos de seguridad que ellos mismos derivaban de definiciones de problemas de seguridad. En estos casos, las
secciones de objetivos y definición del problema de seguridad del SPP pueden omitirse.
La sección de requisitos de seguridad debe describir todas las funciones de seguridad del sistema y las garantías de
seguridad del sistema requeridas por los sistemas operacionales que cumplan los requisitos del SPP en términos de
componentes completos de seguridad.
Es posible que distintos dominios de seguridad de sistemas operacionales que cumplan el SPP apoyen y se ejecuten en
distintos entornos operacionales. Como consecuencia, puede haber requisitos funcionales de seguridad distintos o
únicos para cada dominio de seguridad necesarios para cumplir los objetivos de seguridad únicos para ese dominio. De
forma similar, puede no necesitarse aplicar requisitos de garantía con la misma profundidad y amplitud a lo largo de
todos los componentes del sistema operacional. Es necesario asignar el nivel y tipo de aseguramiento apropiado a los
distintos dominios de seguridad definidos en el SPP.
A.2.9 Información del dominio de seguridad

La sección de información del dominio de seguridad del SPP debe ofrecer información respecto de cada dominio de
seguridad obligatorio en el SPP. Debe ofrecer la identificación ajustada y correcta de cada dominio de seguridad y cada
información de seguridad específica del dominio que se requiera.
Si el SPP no ordena más que un dominio de seguridad dentro del STOE, no tiene que nombrarse o especificarse
explícitamente y esta sección debería omitirse. Tengamos en cuenta que las consideraciones de arquitectura pueden
significar que un SST basado en un SPP introduzca dominios adicionales de seguridad con el fin de permitir una
solución a los problemas de seguridad efectiva en costes.
- 55 - ISO/IEC TR 19791:2010
La información del dominio de seguridad para cada dominio de seguridad debe contener lo siguiente:
a) la introducción del dominio de seguridad debe ofrecer el nombre y la información descriptiva necesaria para
controlar e identificar el dominio de seguridad y el STOE al que se refiere y resumir el dominio en forma narrativa.
La visión general debería ser suficientemente detallada como para entender las funciones de negocio del dominio de
seguridad y sus requisitos de seguridad;
b) las declaraciones de conformidad del dominio de seguridad deben definir cualquier declaración de conformidad
que sea única para el dominio. Si el dominio de seguridad no tiene declaraciones de conformidad que sean únicas,
puede omitirse esta sección;
c) la definición del problema de seguridad del dominio de seguridad debe definir cualquier problema de seguridad
que sea único para el dominio. Esto debe incluir políticas y riesgos que sean únicos para el dominio. Si el dominio
de seguridad no tiene problemas de seguridad que sean únicos, puede omitirse esta sección;
d) los objetivos de seguridad del dominio de seguridad deben definir cualquier objetivo de seguridad que sea único
para el dominio. Esto debe incluir cualquier objetivo de seguridad que esté disponible para otros dominios o que se
implanten en otros dominios. Si el dominio de seguridad no tiene objetivos de seguridad que sean únicos, puede
omitirse esta sección;
e) los requisitos de seguridad del dominio de seguridad deben definir cualquier requisito de seguridad que sea único
para el dominio. Si el dominio de seguridad no tiene requisitos de seguridad que sean únicos, puede omitirse esta
sección.
ISO/IEC TR 19791:2010 - 56 -
ANEXO B (Normativo)
REQUISITOS DE CONTROL FUNCIONAL DEL SISTEMA OPERACIONAL
B.1 Introducción
Este anexo define los componentes funcionales de control del sistema operacional que cubren los aspectos de gestión y
de procedimiento de un STOE. Los componentes aquí descritos actúan en conjunción con los componentes funcionales
técnicos tomados de la Norma ISO/IEC 15408-2 para cumplir con los objetivos de seguridad de un STOE. La Norma
ISO/IEC 15408-2 se utiliza como base para la estructura de estos componentes.
Los componentes funcionales de control operacional se categorizan de acuerdo con los sujetos, áreas funcionales y
acciones. El sujeto es el objetivo directo de los controles, como los datos de negocio, las instalaciones de proceso de
información o los sistemas de TI. El área funcional es el objetivo de las operaciones definidas, como la política, la ges-
tión del riesgo o el registro. Cada área funcional constituye una familia dentro de una clase. La acción es una operación
en un área funcional definida y constituye un componente dentro de esa familia. Los elementos son la definición con-
creta de reglas y procedimientos para controles.
Se definen siete nuevas clases de controles operacionales en este anexo. Son:
a) administración (FOD), que especifica ofrece requisitos de control operacional relacionados con la administración del
sistema;
b) sistemas de TI (FOS), que especifica requisitos de control operacional que soportan el uso de sistemas y equipos de
TI;
c) activos del usuario (FOA), que especifica requisitos de control operacional relacionados con el control de los activos
del usuario;
d) negocio (FOB), que especifica requisitos de control operacional relacionados con procesos y funciones de negocio;
e) instalaciones y equipos (FOP), que especifica medidas de control operacional relacionadas con equipos e instala-
ciones de negocio;
f) terceros (FOT), que especifica las medidas de control operacional para relaciones con terceros;
g) gestión (FOM), que especifica las medidas de control operacional relacionadas con actividades de gestión.
Las familias dentro de estas clases se muestran más abajo en la tabla B.1.
Las dependencias entre componentes de estas familias se muestran en la tabla B.2. Cada uno de los componentes que es
una dependencia de algún componente funcional se ubica en una columna. Cada componente funcional con depen-
dencias se ubica en una fila. El valor en la tabla de casillas indica si el componente de la columna se requiere direc-
tamente (indicado por una cruz ‘X’) o indirectamente (indicado por un guión ‘–’) por el componente de la fila.
Algunos requisitos de controles operacionales se implantarán siempre como requisitos operacionales y por tanto se
definirían como OSF. Otros podrían ser o bien operacionales o bien técnicos y por tanto se describen como SSF.
Hay cuatro diferencias de presentación con respecto a la Norma ISO/IEC 15408-2. No hay componentes jerárquicos de
control operacional, así que se omite ese subencabezamiento. Todas las actividades de gestión se manejan con compo-
nentes explícitos y por tanto no se necesitan subencabezamientos de actividades de gestión. El subencabezamiento de
auditoría se ha cambiado por el de registros, que expresa mejor el proceso necesario de recogida de evidencias de
controles operacionales. La operación permitida de asignación se ha usado de forma más flexible que en la Norma
ISO/IEC 15408-2. La identificación de documento que describen políticas procedimientos reglas, requisitos de seguri-
dad y otros controles asociados puede especificarse como una asignación.
- 57 - ISO/IEC TR 19791:2010
Tabla B.1 – Familias funcionales de control operacional
Clase Familia
Administración (FOD) Administración de políticas (FOD_POL)
Administración de personal (FOD_PSN)
Administración de gestión de riesgos (FOD_RSM)
Administración de gestión de incidentes (FOD_INC)
Administración de organización de seguridad (FOD_ORG)
Administración de acuerdos de servicio (FOD_SER)
Sistemas de TI (FOS) Política para sistemas de TI (FOS_POL)
Configuración de sistemas de TI (FOS_CNF)
Seguridad de red de sistemas de TI (FOS_NET)
Monitorización de sistemas de TI (FOS_MON)
Control de personal de sistemas de TI (FOS_PSN)
Activos del sistema operacional de sistemas de TI (FOS_OAS)
Registros para sistemas de TI (FOS_RCD)
Activos del usuario (FOA) Protección de datos de privacidad (FOA_PRO)
Protección de información de activos del usuario (FOA_INF)
Negocio (FOB) Políticas de negocio (FOB_POL)
Continuidad de negocio (FOB_BCN)
Instalaciones y equipos (FOP) Equipamiento móvil (FOP_MOB)
Equipamiento removible (FOB_RMM)
Equipamiento remoto (FOP_RMT)
Equipamiento del sistema (FOP_SYS)
Gestión de las instalaciones (FOP_MNG)
Terceros (FOT) Acuerdos con terceros (FOT_COM)
Gestión de terceros (FOT_MNG)
Gestión (FOM) Gestión de los parámetros de seguridad (FOM_PRM)
Gestión de la clasificación de activos (FOM_CLS)
Gestión de las responsabilidades de seguridad del personal (FOM_PSN)
Gestión de la organización de seguridad (FOM_ORG)
Gestión de los informes de seguridad (FOM_INC)
ISO/IEC TR 19791:2010 - 58 -
Tabla B.2 – Dependencias de control operacional
FOM_PRM.2
FOD_ORG.1
FOD_ORG.2
FOD_RSM.1
FOA_POL.3
FOM_INC.1
FOD_PSN.1
FOD_PSN.3
FOD_PSN.5
FOS_POL.1
FOS_POL.4
FOS_NET.1
FOD_INC.1 X X
FOS_SER.1 X
FOS_POL.1 X
FOS_PSN.1 X X X
FOS_OAS.1 X –
FOA_INF.1 X –
FOB_POL.1 X –
FOB_BCN.1 X
FOP.MNG.1 X
FOT.MNG.1 X
FOM_PRM.1 X
FOM_PSN.1 X
FOM_ORG.1 X
FOM_ORG.1 X
B.2 Clase FOD: Administración

Esta clase ofrece requisitos de control operacional para la administración de un sistema operacional.
B.2.1 Administración de políticas (FOD_POL)
B.2.1.1 Familia Comportamiento

Esta familia define las políticas de seguridad del sistema operacional para su administración. Incluye la especificación
de la política de seguridad, foro de gestión, revisión de gestión y controles de gestión para violaciones de seguridad.
B.2.1.2 Descripción de componentes
FOD_POL.1 Política de seguridad. Están definidos los controles de gestión, objetivos y objetos de la política de
seguridad, revisión de gestión y controles de gestión para violaciones de seguridad.
FOD_POL.2 Política de protección de datos y privacidad. Está definida la política de protección de datos y privacidad.
B.2.1.3 Registros
El sistema operacional debe mantener y tener disponibles para inspección las siguientes evidencias.
- 59 - ISO/IEC TR 19791:2010
a) para FOD_POL.1: Descripción del compromiso de gestión, política de seguridad, revisión de gestión y controles de
gestión para violaciones de seguridad con acciones y especificaciones concretas;
b) para FOD_POL.2: Descripción de la política de protección de datos y privacidad.
B.2.1.4 FOD_POL.1 Política de seguridad

Dependencias: no hay dependencias.
FOD_POL.1.1 La OSF debe definir [asignación: compromiso de gestión] por el que la dirección apoya
activamente la seguridad dentro de la organización a través de una dirección clara, un compromiso demostrado,
una asignación explícita y un reconocimiento de las responsabilidades en la seguridad de la información.
FOD_POL.1.2 La OSF debe definir [asignación: política de seguridad de la información] incluyendo objetivos,
ámbito, cumplimiento legal, requisitos contractuales y estándares, evaluación y gestión del riesgo, requisitos de
formación y concienciación en seguridad, gestión de la continuidad de negocio, consecuencias de las violaciones
de la política de seguridad de la información y responsabilidades de la organización y su aproximación a la
gestión de la información de seguridad.
FOD_POL.1.3 La OSF debe definir [asignación: procedimientos formales] para revisiones de gestión que
incluyan la información sobre resultados de revisiones independientes, resultados de revisiones de gestión
previas, cambios que pudieran afectar a la aproximación de la organización a la gestión de la seguridad de la
información, recomendaciones ofrecidas por las autoridades relevantes, tendencias relacionadas con amenazas y
vulnerabilidades e incidentes de seguridad reportados como entrada.
FOD_POL.1.4 La OSF debe definir [asignación: política de personal] ofreciendo medios al personal para recibir
reentrenamiento de violación de controles de seguridad.
FOD_POL.1.5 La OSF debe definir [asignación: requisitos de seguridad] para medios de comunicar la acción tras
la violación de controles operacionales, que tendrán lugar antes de que se dé acceso al personal a activos del
sistema.
FOD_POL.1.6 La OSF debe definir [asignación: política de personal] ofreciendo un medio para imponer
sanciones como multas monetarias, eliminación de privilegios, suspensión u otra sanción por la violación de
controles operacionales.
FOD_POL.1.7 La OSF debe definir [asignación: requisitos de seguridad] de eliminación, limitación u otras
acciones al violador a acceder a activos de sistema bajo criterios de reincorporación.
FOD_POL.1.8 La OSF debe definir [asignación: política de personal] ofreciendo un medio para despedir al
personal por violación de reglas y procedimientos, de acuerdo con lo que disponga la ley.
FOD_POL.1.9 La OSF debe definir [asignación: requisitos de seguridad] para todos los requisitos legales,
regulatorios y contractuales relevantes y la aproximación de la organización para cumplir estos requisitos y
mantenerlos al día para cada sistema de información y organización.
FOD_POL.1.10 La OSF debe definir [asignación: política de seguridad de la información] en la que se desarrollen
una serie apropiada de procedimientos para la clasificación y manejo de información y se implanten de acuerdo
con el esquema de clasificación adoptado por la organización.
FOD_POL.1.11 La OSF debe definir [asignación: política de seguridad de la información] en la que se revise
independientemente la aproximación de la organización a la gestión de la seguridad de la información y su
implantación (es decir, controles, política, proceso y procedimientos de objetivos de control para la seguridad de
la información), en intervalos planificados o cuando se produzcan cambios significativos en la implantación de la
seguridad.
ISO/IEC TR 19791:2010 - 60 -
FOD_POL.1.12 La OSF debe definir [asignación: política de seguridad de la información] en la que se atienda a
todos los requisitos de seguridad identificados antes de dar a los usuarios acceso a la información o activos de la
organización.
FOD_POL.1.12 La OSF debe definir [asignación: política de seguridad de la información] en la que la dirección
apruebe un documento de política de seguridad de la información y ésta se comunique a todos los empleados y
externos relevantes.
B.2.1.5 FOD_POL.2 Política de protección de datos y privacidad

FOD_POL.2.1 La OSF debe desarrollar e implantar [asignación: política de protección de datos y privacidad].
B.2.2 Administración de personal (FOD_PSN)

Esta familia define la administración de seguridad del personal en el sistema operacional. Incluye la especificación de
roles y responsabilidades del personal, la acción disciplinaria, los contenidos de los acuerdos de personal, la gestión de
la identificación de usuarios, el control de los activos y la concienciación y formación en seguridad de la información.
FOD_PSN.1 Roles y responsabilidades del personal. Están definidas las responsabilidades de gestión, responsa-
bilidades en la realización de proceso de bajas, responsabilidades legales y controles de seguridad para el personal que
trabaje en el área segura. Están definidos los términos y condiciones del contrato de asignación y reglas de asignación
para firmar un acuerdo de confidencialidad o no divulgación. Están definidas las reglas para supervisar o evacuar
visitantes. Están definidas las reglas para ser conscientes del ámbito preciso del acceso permitido. Están definidas las
reglas respecto del uso aceptable y devolución de activos organizativos.
FOD_PSN.2 Concienciación y formación en seguridad de la información. Están definidos los requisitos para la
concienciación y formación en seguridad de la información.
B.2.2.3 Registros
a) para FOD_PSN.1: Descripción de las responsabilidades de gestión, responsabilidades en la realización de proceso

de bajas, responsabilidades legales y controles de seguridad para el personal que trabaje en el área segura, un pro-
ceso disciplinario formal con acciones, especificaciones y registros concretos de realización de la acción discipli-
naria, términos y condiciones del contrato de asignación, reglas de asignación para firmar un acuerdo de confiden-
cialidad o no divulgación, reglas para realizar la identificación del usuario, reglas para ser conscientes del ámbito
preciso del acceso permitido y reglas respecto del uso aceptable y devolución de activos organizativos, con acciones
y especificaciones concretas y registros de realización del control;
b) para FOD_PSN.2: Registros de realizar concienciación y formación en seguridad de la información.
B.2.2.4 FOD_PSN.1 Roles y responsabilidades del personal
Dependencias: FOD_POL.1 Política de seguridad
FOD_RSM.1 Gestión de riesgos dentro de la organización
FOD_PSN.1.1 La OSF debe definir y documentar [asignación: roles y responsabilidades] de empleados, subcon-
tratados y terceros usuarios de acuerdo con la política de seguridad de la información de la organización.
- 61 - ISO/IEC TR 19791:2010
FOD_PSN.1.2 La OSF debe definir [asignación: responsabilidades] para realizar las bajas o cambios de puestos
de trabajo.
FOD_PSN.1.3 La OSF debe definir [asignación: requisitos de seguridad] para posteriores requisitos de seguridad,
responsabilidades legales, acuerdos de confidencialidad y los términos y condiciones para un periodo definido
después de la baja de la asignación del usuario empleado, subcontratado o tercero para la comunicación de
responsabilidades tras la baja.
FOD_PSN.1.4 La OSF debe definir [asignación: requisitos de seguridad] para personal trabajando en áreas
seguras.
FOD_PSN.1.5 La OSF debe definir [asignación: requisitos de seguridad] en los que los derechos de acceso de
todos los empleados y subcontratados y terceros usuarios a la información e instalaciones de proceso de la
información deben eliminarse tras su baja en el empleo, contrato o acuerdo o ajustados a sus cambios.
FOD_PSN.1.6 La OSF debe definir [asignación: requisitos de seguridad] sobre los candidatos de personal,
subcontratados y terceros usuarios de acuerdo con leyes y regulaciones relevantes.
FOD_PSN.1.7 La OSF debe definir [asignación: procedimientos] desarrollados y seguidos al recoger y presentar
evidencias para el fin de llevar a cabo acciones disciplinarias dentro de una organización.
FOD_PSN.1.8 La OSF debe definir [asignación: requisitos de seguridad] sobre un proceso disciplinario formal
para empleados, subcontratados y terceros usuarios que hayan producido una violación de seguridad.
FOD_PSN.1.9 La OSF debe definir [asignación: requisitos de seguridad] sobre términos y condiciones del
contrato de asignación que incluyan: las responsabilidades y derechos legales de empleados, subcontratados y
terceros usuarios, responsabilidades para la clasificación y gestión de datos organizativos manejados por
empleados, subcontratados y terceros usuarios, responsabilidades del empresario en el manejo de información
personal, incluyendo información personal creada como resultado, o en el curso, de asignaciones con la
organización, responsabilidades que se extiendan fuera de las instalaciones de la organización y de horas de
trabajo normales y acciones a tomar si el empleado, subcontratado o tercero usuario incumple los requisitos del
empresario, para toda la gente empleada por la organización, nuevos empleados, subcontratados y terceros
usuarios. Las responsabilidades contenidas dentro de los términos y condiciones de empleo deben continuar por
un periodo definido tras el fin de la asignación.
FOD_PSN.1.10 La OSF debe definir [asignación: reglas] en las que, como parte de su obligación contractual,
empleados, subcontratados y terceros usuarios aceptan y firman sus responsabilidad y las de la organización
respecto de la seguridad de la información.
FOD_PSN.1.11 La OSF debe definir [asignación: reglas] para firmar un acuerdo de confidencialidad o no divul-
gación como parte de sus términos y condiciones iniciales de empleo antes de dar acceso a las instalaciones de pro-
ceso de información y en el que se identifiquen y se revisen regularmente los requisitos para los acuerdos de confi-
dencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información.
FOD_PSN.1.12 La OSF debe definir [asignación: requisitos de seguridad] para acuerdos de confidencialidad
cuando haya cambios en los términos de asignación o contratos, particularmente cuando los empleados vayan a
abandonar la organizan o los contratos vayan a vencer.
FOD_PSN.1.13 La OSF debe definir [asignación: reglas] por las que todo el personal ha de llevar algún tipo de
identificación visible.
FOD_PSN.1.14 La OSF debe definir [asignación: reglas] para no acceder a instalaciones de la organización
excepto las autorizadas.
FOD_PSN.1.15 La OSF debe definir [asignación: reglas] respecto del uso aceptable de información y activos
organizativos.
ISO/IEC TR 19791:2010 - 62 -
NOTA Los activos organizacionales incluyen software previamente emitido, documentos corporativos, dispositivos informáticos móviles, tarjetas de
crédito, tarjetas de acceso, software, manuales e información almacenados en medios electrónicos.
FOD_PSN.1.16 La OSF debe definir [asignación: reglas] por las que todos los empleados, subcontratados y
terceros usuarios devuelvan todos los activos de la organización en su posesión al acabar su trabajo, contrato o
acuerdo.
FOD_PSN.1.17 La OSF debe definir [asignación: reglas] por las que todos los empleados y subcontratados y
terceros usuarios no se lleven activos de la organización fuera del lugar de trabajo sin autorización.
FOD_PSN.1.18 La OSF debe definir [asignación: reglas] por las que tareas y áreas de responsabilidad están
segregadas para reducir la posibilidad de modificaciones o usos incorrectos de activos de la organización no
autorizados o no intencionados.
FOD_PSN.1.19 La OSF debe definir [asignación: requisitos de seguridad] en un proceso disciplinario formal para
empleados que hayan cometido una violación de seguridad.
B.2.2.5 FOD_PSN.2 Concienciación y formación en seguridad de la información

FOD_PSN.2.1 La OSF debe definir y documentar [asignación: requisitos de seguridad] por los que todos los
empleados de la organización, subcontratados y terceros usuarios reciban formación de concienciación adecuada
y actualizaciones regulares de políticas y procedimientos organizativos relevantes para su trabajo.
FOD_PSN.2.2 La OSF debe definir y documentar [asignación: requisitos de seguridad] por los que la formación
de concienciación debería comenzar con un proceso de inducción formal pensado para presentar las políticas y
expectativas de seguridad de la organización antes de conceder acceso a la información o servicios.
FOD_PSN.2.3 La OSF debe definir y documentar [asignación: requisitos de seguridad] por los que la formación
continua deberían incluir requisitos de seguridad, responsabilidades legales y controles de negocio, así como
formación en el uso correcto de instalaciones de proceso de información, de paquetes de software e información
sobre el proceso disciplinario.
B.2.3 Administración de gestión de riesgos (FOD_RSM)

Esta familia define la gestión de riesgos para la administración. Incluye la gestión de riesgos para la organización y para
terceros relacionados.
FOD_RSM.1 Gestión de riesgos dentro de la organización. Están definidos los procedimientos de gestión de riesgos
para la organización.
FOD_RSM.2 Gestión de riesgos relacionada con accesos de terceros. Están definidos los procedimientos de gestión de
riesgos de accesos de terceros.
B.2.3.3 Registros
a) para FOD_RSM.1: Descripción de la gestión de riesgos para la organización con acciones y especificaciones con-
cretas para llevar a cabo la gestión de riesgos;
b) para FOD_RSM.2: Descripción de la gestión de riesgos de accesos de terceros con acciones y especificaciones
concretas para llevar a cabo la gestión de riesgos.
- 63 - ISO/IEC TR 19791:2010
B.2.3.4 FOD_RSM.1 Gestión de riesgos dentro de la organización

FOD_RSM.1.1 La OSF debe definir [asignación: procedimientos] para la gestión de riesgos para listas de
información e instalaciones de proceso de información de la organización, incluyendo trabajadores en casa y
otros usuarios remotos o móviles.
FOD_RSM.1.2 La OSF debe definir [asignación: requisitos de seguridad] para llevar a cabo la gestión de riesgos
al sistema operacional con procesos de negocio.
FOD_RSM.1.3 La OSF debe definir [asignación: requisitos de seguridad] en los que se obtenga información
puntual acerca de las vulnerabilidades técnicas en los sistemas de información, se evalúe la exposición de la
organización a dichas vulnerabilidades y se tomen medidas apropiadas para ocuparse del riesgo asociado.
B.2.3.5 FOD_RSM.2 Gestión de riesgos relacionada con accesos de terceros

FOD_RSM.1.1 La OSF debe definir [asignación: procedimientos] para la gestión de riesgos para listas de
información e instalaciones de proceso de información a las que accederán terceros con la consideración de listas
de control empleadas por los terceros, requisitos legales y regulatorios que debería tener en cuenta el tercero y
obligaciones contractuales que la organización y el tercero tienen que tener en cuenta.
FOD_RSM.1.2 La OSF debe definir [asignación: procedimientos] por los que se identifiquen en los procesos de
negocio que impliquen a terceros los riesgos a la información e instalaciones de proceso de información de la
organización y se implanten los controles apropiados antes de otorgar acceso.
B.2.4 Administración de gestión de incidentes (FOD_INC)

Esta familia define gestión de incidentes para la administración. Incluye la especificación de la gestión de incidentes.
FOD_INC.1 Incidentes de seguridad. Está definido un procedimiento formal de reporte de incidentes de seguridad,
procedimientos de gestión de incidentes y acciones de recuperación.
B.2.4.3 Registros
a) para FOD_INC.1: Descripción de un procedimiento formal de reporte de incidentes de seguridad, procedimientos

de gestión de incidentes y acciones de recuperación con acciones y especificaciones concretas y registros sobre
informes de incidentes de seguridad y su gestión.
B.2.4.4 FOD_INC.1 Incidentes de seguridad
Dependencias: FOM_INC.1 Reporte de problemas de seguridad detectados
FOD_ORG.2 Responsabilidades del foro de dirección
FOD_INC.1.1 La OSF debe definir [asignación: procedimientos] para un reporte formal de incidentes de
seguridad junto con un procedimiento de respuesta ante incidentes, estableciendo la acción a realizar a la
recepción de un informe de incidente.
ISO/IEC TR 19791:2010 - 64 -
FOD_INC.1.2 La OSF debe definir [asignación: requisitos de seguridad] para un punto de contacto al que todos
los que quieran reportar un incidente puedan dirigirse.
FOD_INC.1.3 La OSF debe definir [asignación: procedimientos] para gestión de incidentes para manejar tipos
potenciales de incidente de seguridad, incluyendo fallos del sistema y pérdidas del servicio, virus y otras formas
de código malicioso, denegaciones de servicio, errores generados por datos de negocio incompletos o inexactos,
violaciones de confidencialidad, integridad, contabilidad, autenticidad, confiabilidad o privacidad y mal uso de
sistemas de información.
FOD_INC.1.4 La OSF debe definir [asignación: requisitos de seguridad] sobre acciones de recuperación de
violaciones de seguridad y corrección de fallos del sistema.
FOD_INC.1.5 La OSF debe definir [asignación: requisitos de seguridad] sobre registro de fallos reportados por
usuarios respecto de problemas con el proceso de información o sistemas de comunicación.
FOD_INC.1.6 La OSF debe definir [asignación: procedimientos] por los que los incidentes de seguridad deberían
reportarse a través de canales de gestión apropiados tan rápido como sea posible.
FOD_INC.1.7 La OSF debe definir [asignación: reglas] para garantizar que se requiere a todos los empleados,
subcontratados y terceros usuarios de sistemas y servicios de información que adviertan e informen de cualquier
debilidad observada o sospechada en los sistemas o servicios.
FOD_INC.1.8 La OSF debe definir [asignación: reglas] por las que todos los empleados, subcontratados y
terceros usuarios de sistemas y servicios de información sean conscientes del procedimiento para informar de
incidentes de seguridad y del punto de contacto para ello.
FOD_INC.1.9 La OSF debe definir [asignación: responsabilidades y procedimientos] para la gestión que aseguren
una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.
FOD_INC.1.10 La OSF debe definir [asignación: mecanismos] implantados para cuantificar y monitorizar los
tipos, volúmenes y costes de los incidentes de seguridad de la información.
FOD_INC.1.11 La OSF debe definir [asignación: requisitos de seguridad] en los que en caso de que una acción de
monitorización contra una persona u organización tras un incidente de seguridad de la información implique
acción legal (civil o criminal) se recojan, retengan y presenten evidencias para cumplir con las reglas de
evidencias establecidas por la jurisdicción o las jurisdicciones relevantes.
B.2.5 Administración de organización de seguridad (FOD_ORG)

Esta familia define la administración de la organización de seguridad. Incluye la especificación de un foro de dirección.
FOD_ORG.1 Responsabilidades de coordinación de seguridad. Están definidas las responsabilidades en la

coordinación de la seguridad.
FOD_ORG.2 Responsabilidades del foro de dirección. Están definidas las responsabilidades de un foro de dirección.
B.2.5.3 Registros
a) para FOD_ORG.1: Descripción de las responsabilidades en la coordinación de la seguridad con acciones y especi-
ficaciones concretas;
- 65 - ISO/IEC TR 19791:2010
b) para FOD_ORG.2: Descripción de las responsabilidades del foro de dirección con acciones y especificaciones
concretas.
B.2.5.4 FOD_ORG.1 Responsabilidades de coordinación de seguridad

FOD_ORG.1.1 La OSF debe definir [asignación: responsabilidades] por las que las actividades de seguridad de la
información sean coordinadas por representantes de distintas partes de la organización con roles y funciones de
trabajo relevantes.
FOD_ORG.1.2 La OSF debe definir [asignación: requisitos de seguridad] por los que se mantengan contactos
apropiados con las autoridades relevantes.
FOD_ORG.1.3 La OSF debe definir [asignación: requisitos de seguridad] por los que se mantengan contactos
apropiados con grupos especiales de interés u otros foros y asociaciones profesionales especiales de seguridad.
B.2.5.5 FOD_ORG.2 Responsabilidades del foro de dirección

FOD_ORG.2.1 La OSF debe definir [asignación: responsabilidades] para un foro de dirección que se ocupe de
asuntos de seguridad.
FOD_ORG.2.2 La OSF debe definir [asignación: requisitos] para que el foro de dirección se asegure de que se
ejecutan las actividades de seguridad cumpliendo con las política de seguridad de información, aprobar
metodologías y procesos para seguridad de la información, evaluación de riesgos, clasificación de información,
identificar cambios de amenazas y exposición de información e instalaciones del proceso de información a
amenazas y evaluar la adecuación y coordinar las implantación de controles de seguridad de la información.
B.2.6 Administración de acuerdos de servicio (FOD_SER)

Esta familia define los acuerdos de servicio sobre administración de seguridad. Incluye la especificación de requisitos
de seguridad de servicios de red.
FOD_SER.1 Acuerdos de servicios de red. Están definidos características de seguridad, niveles de servicio y requisitos
de gestión de servicios de red.
B.2.6.3 Registros
a) para FOD_SER.1: Descripción de características de seguridad, niveles de servicio y requisitos de gestión de

servicios de red, con acciones y especificaciones concretas.
B.2.6.4 FOD_SER.1 Acuerdos de servicios de red

Dependencia: FOS_NET.1 Servicios de red.
FOD_SER.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre identificación de características de
seguridad, niveles de servicio y requisitos de gestión de servicios de red de todos los servicios de red e inclusión
de los mismos en un acuerdo de servicios de red.
ISO/IEC TR 19791:2010 - 66 -
FOD_SER.1.2 La OSF debe definir [asignación: requisitos de seguridad] sobre la capacidad del proveedor del
servicio de red para gestionar los servicios acordados de una forma segura y un acuerdo sobre el derecho a
auditar.
FOD_SER.1.3 La OSF debe establecer [asignación: acuerdos] para el intercambio de información y software
entre la organización y las partes externas.
B.3 Clase FOS: Sistemas de TI

Esta clase ofrece requisitos de control operacional para sistema de TI en el sistema operacional.
B.3.1 Política para sistemas de TI (FOS_POL)

Esta familia define las políticas de seguridad para sistemas de TI en el sistema operacional. Incluye la especificación de
requisitos de seguridad, control de cambios, control del código malicioso y criptografía.
FOS_POL.1 Requisitos de seguridad. Están definidos procedimientos de gestión de actualizaciones e identificación de

cambios, control de cambios y presentación del sistema cambiado.
FOS_POL.2 Política de código malicioso. Están definidos procedimientos de gestión para ocuparse del código
malicioso.
FOS_POL.3 Política de código móvil. Están definidos procedimientos de gestión para ocuparse del código móvil.
FOS_POL.4 Política de criptografía. Están definidos procedimientos para el uso de técnicas criptográficas y
procedimientos de gestión de claves criptográficas.
FOS_POL.5 Sistemas públicos. Están definidos procedimientos para sistemas disponibles públicamente.
B.3.1.3 Registros
a) para FOD_POL.1: Descripción de los requisitos de seguridad y controles de cambios, con acciones y especifi-
caciones concretas y registros de realización del control;
b) para FOD_POL.2: Descripción de los procedimientos de gestión para ocuparse del código malicioso con acciones y
especificaciones concretas y registros de realización del control del código malicioso;
c) para FOD_POL.3: Descripción de los procedimientos de gestión para ocuparse del código móvil con acciones y
especificaciones concretas y registros de realización del control del código móvil;
d) para FOD_POL.4: Descripción de la política de uso de técnicas criptográficas y registros de realización del control
criptográfico;
e) para FOD_POL.5: Descripción de los procedimientos de protección para sistemas disponibles públicamente con
acciones y especificaciones concretas y registros de realización del control.
B.3.1.4 FOS_POL.1 Requisitos de seguridad

Dependencias: FOM_PRM.2 Segregación de privilegios.
- 67 - ISO/IEC TR 19791:2010
FOS_POL.1.1 La OSF debe definir [asignación: procedimientos] sobre un proceso de gestión de actualización del
software para asegurar que se instalan las actualizaciones de aplicaciones y los parches aprobados más
actualizados en todo el software autorizado.
FOS_POL.1.2 La OSF debe definir [asignación: procedimientos] sobre la identificación de cambios en

instalaciones y sistemas de proceso de información y evaluación sobre impactos potenciales.
FOS_POL.1.3 La OSF debe definir [asignación: procedimientos] para un control formal de cambios para
controlar la implementación de cambios en instalaciones y sistemas de proceso de información.
FOS_POL.1.4 La OSF debe definir [asignación: procedimientos] para el mantenimiento y copia de librerías de
programas fuente de acuerdo con el control de cambios.
FOS_POL.1.5 La OSF debe definir [asignación: procedimientos] para que se verifique periódicamente el
cumplimiento de los estándares de implantación de seguridad en los sistemas de información.
FOS_POL.1.6 La OSF debe definir [asignación: controles de seguridad] en las declaraciones de requisitos de
negocio para nuevos sistemas de información o mejoras en los sistemas de información existentes.
FOS_POL.1.7 La OSF debe definir [asignación: procedimientos] para controlar la instalación de software en
sistemas operacionales.
FOS_POL.1.8 La OSF debe definir [asignación: procedimientos] por los que cuando se cambien los sistemas
operativos, se revisen y prueben las aplicaciones crítica de negocio para asegurarse de que no hay un impacto
adverso en las operaciones o seguridad de la organización.
FOS_POL.1.9 La OSF debe definir [asignación: reglas] por las que se desaconsejan las modificaciones de
paquetes de software, limitándolas a los cambios necesarios, y todos los cambios están controlados estrictamente.
FOS_POL.1.10 La OSF debe documentar, mantener y hacer disponibles [asignación: procedimientos] para todos
los usuarios que los necesiten.
B.3.1.5 FOS_POL.2 Política de código malicioso

Dependencias: sin dependencias.
FOS_POL.2.1 La OSF debe definir [asignación: procedimientos] para que la dirección se ocupe de la protección
ante código malicioso en sistemas, reportando y recuperando los ataques de código malicioso.
FOS_POL.2.2 La OSF debe definir [asignación: procedimientos] para la detección y protección ante código
malicioso que pueda transmitirse a través del uso de instalaciones de comunicación.
FOS_POL.2.3 La OSF debe definir [asignación: responsabilidades] para ocuparse de la protección ante código
malicioso en sistemas, de la formación en su uso, reporte y recuperación ante ataques de código malicioso.
FOS_POL.2.4 La OSF debe definir [asignación: procedimientos] para implantar controles de detección,
prevención y recuperación para protegerse ante código malicioso y una concienciación apropiada del usuario.
B.3.1.6 FOS_POL.3 Política de código móvil

FOS_POL.3.1 La OSF debe definir [asignación: procedimientos] para que la dirección autorice el uso de código
móvil.
ISO/IEC TR 19791:2010 - 68 -
FOS_POL.3.2 La SSF debe definir [asignación: requisitos de seguridad] sobre la configuración del código móvil
para asegurar que el código móvil autorizado opera de acuerdo con una política de seguridad claramente
definida y que se impide que se ejecute código móvil no autorizado.
B.3.1.7 FOS_POL.4 Política de criptografía

FOS_POL.4.1 La OSF debe definir [asignación: una política criptográfica] sobre el uso de controles
criptográficos para la protección de la información en cumplimiento de todos los acuerdos, leyes y regulaciones
relevantes.
FOS_POL.4.2 La OSF debe definir [asignación: una política criptográfica] sobre el uso de controles de
criptografía para la protección de información.
FOS_POL.4.3 La OSF debe definir [asignación: procedimientos] para que la gestión de claves soporte el uso de
técnicas criptográficas de la organización.
FOS_POL.4.4 La OSF debe definir [asignación: requisitos de seguridad] sobre consejo legal antes de que se
envíen información encriptada o controles criptográficos a otros países.
FOS_POL.4.5 La SSF debe ofrecer [asignación: controles] por los que cualesquiera claves criptográficas
asociadas con archivos encriptadas o firmas digitales se mantengan de forma segura y estén disponibles para
personas autorizadas cuando se necesiten.
B.3.1.8 FOS_POL.5 Sistemas públicos

FOS_POL.5.1 La SSF debe ofrecer [asignación: controles] para la protección de software, datos y otra
información que requiere un alto nivel de integridad y que esté disponible en un sistema disponible
públicamente.
FOS_POL.5.2 La OSF debe ofrecer [asignación: requisitos de seguridad] para que el sistema accesible
públicamente sea probado ante amenazas y fallos antes de hacer disponible la información.
FOS_POL.5.3 La SSF debe ofrecer [asignación: requisitos de seguridad] por los que haya un proceso formal de
aprobación antes de que la información esté disponible públicamente.
FOS_POL.5.4 La SSF debe ofrecer [asignación: requisitos de seguridad] por los que todas las entradas
provenientes de fuera del sistema se verifiquen y aprueben.
B.3.2 Configuración de sistemas de TI (FOS_CNF)

Esta familia define la configuración del sistema de TI. Incluye la separación del entorno de desarrollo del operacional y
la configuración del sistema.
FOS_CNF.1 Separación del entorno de desarrollo del operacional. Está definida la separación del entorno de desarrollo
del operacional.
FOS_CNF.2 Configuración del sistema. Están definidas la gestión de recursos compartidos y la configuración del
sistema.
- 69 - ISO/IEC TR 19791:2010
B.3.2.3 Registros
a) para FOS_CNF.1: Descripción de la separación del entorno de desarrollo del operacional, con acciones y especifi-
caciones concretas y registros de realización del control;
b) para FOS_CNF.2: Descripción de la gestión de recursos compartidos y la configuración del sistema, con acciones y
especificaciones concretas y registros de realización del control.
B.3.2.4 FOS_CNF.1 Separación del entorno de desarrollo del operacional

FOS_CNF.1.1 La OSF debe definir [asignación: reglas] sobre el nivel de separación que sea necesario entre
entornos de operación, prueba y desarrollo, para evitar problemas operacionales.
FOS_CNF.1.2 La OSF debe definir [asignación: reglas] para la transferencia de software del estado de
desarrollo al de operación.
FOS_CNF.1.3 La SSF debe ofrecer [asignación: medidas] de control de acceso que se apliquen a sistemas de
aplicación operacional, para probar sistemas de aplicación para la protección de datos operacionales.
FOS_CNF.1.4 La SSF debe ofrecer [asignación: controles] de restricciones al personal de soporte de TI al acceso
a librerías de programas fuente.
FOS_CNF.1.5 La OSF debe definir [asignación: reglas] del software de desarrollo y operacional sobre distintos
sistemas o procesadores.
FOS_CNF.1.5 La OSF debe definir [asignación: reglas] cuando la información operacional se copie en un
sistema de aplicación de pruebas.
B.3.2.5 FOS_CNF.2 Configuración del sistema

FOS_CNF.2.1 La OSF debe definir [asignación: reglas] de segregación de grupos de servicios de información,
usuarios y sistemas de información, en redes.
FOS_CNF.2.2 Cuando se ejecute una aplicación sensible en un entorno compartido, la OSF debe definir
[asignación: reglas] de identificación de los sistemas de aplicación con los que compartirá recursos con el
propietario de la aplicación sensible.
FOS_CNF.2.3 La OSF debe definir [asignación: reglas] por las que los sistemas sensibles tengan un entorno
informático dedicado (aislado).
B.3.3 Seguridad de red de sistemas de TI (FOS_NET)

Esta familia define la seguridad de red de los sistemas de TI. Incluye la especificación de la seguridad y los servicios de
red.
FOS_NET.1 Servicios de red. Están definidos los servicios de red y sus accesos.
ISO/IEC TR 19791:2010 - 70 -
FOS_NET.2 Seguridad de red. Están definidos protección de redes, seguridad de la información en redes, confiden-
cialidad e integridad de los datos de transmisión.
B.3.3.3 Registros
a) para FOS_NET.1: Descripción de los servicios de red, con acciones y especificaciones concretas y registros de
realización del control;
b) para FOS_NET.2: Descripción de la protección de redes, seguridad de la información en redes, con acciones y
B.3.3.4 FOS_NET.1 Servicios de red

FOS_NET.1.1 La OSF debe definir [asignación: reglas] para las redes y servicios de red a los que se permita
acceder, procedimientos de autorización para determinar a quién se le permite acceder a qué redes y servicios de
red.
B.3.3.5 FOS_NET.2 Seguridad de red

FOS_NET.2.1 La SSF debe ofrecer [asignación: controles] para cerrar sesiones inactivas en ubicación de alto
riesgo tras un periodo de inactividad definido.
FOS_NET.2.2 La SSF debe ofrecer [asignación: controles] para borrar la pantalla del terminal y cerrar tanto la
aplicación como las sesiones de red después de un periodo definido de inactividad en una instalación con
desconexión por tiempo.
FOS_NET.2.3 La SSF debe ofrecer [asignación: controles] para hacer restricciones en los horarios de conexión
para ofrecer seguridad adicional para aplicaciones de alto riesgo.
FOS_NET.2.4 La SSF debe ofrecer [asignación: medidas] para enlazar derechos de acceso a red con ciertas horas
del día o fechas.
FOS_NET.2.5 La SSF debe ofrecer [asignación: controles] para segregar grupos de servicios de información,
usuarios y sistemas de información en redes.
FOS_NET.2.6 La SSF debe ofrecer [asignación: controles] para restringir la capacidad de los usuarios para
conectarse a la red para redes compartidas, especialmente aquéllas que se extienden cruzando los límites de la
organización, en línea con la política y requisitos de control de acceso de las aplicaciones de negocio.
FOS_NET.2.6 La SSF debe ofrecer [asignación: controles] de enrutado para redes para asegurarse de que las
conexiones informáticas y flujos de información no violan la política de control de accesos de las aplicaciones de
negocio.
B.3.4 Monitorización de sistemas de TI (FOS_MON)

Esta familia define la monitorización de los sistemas de TI. Incluye la especificación de registros de auditoría, asesoría
legal, alarmas y requisitos de monitorización.
- 71 - ISO/IEC TR 19791:2010
FOS_MON.1 Registros de auditoría. Están definidos registros de auditoría, gestión de auditoría, producción de
auditoría, información registrada en el log y el logging del administrador del sistema.
FOS_MON.2 Asesoría legal. Está definida la asesoría legal antes de implantar procedimientos de monitorización.
FOS_MON.3 Requisitos de alarma. Están definidos el marco de parámetros de la alarma y la respuesta ante una alarma.
FOS_MON.4 Uso del sistema de monitorización. Está definido el uso del sistema de monitorización.
B.3.4.3 Registros
a) para FOS_MON.1: Descripción del proceso de producción de los registros de auditoría, con acciones y especifica-
ciones concretas y registros detallados de auditoría;
b) para FOS_MON.2: Descripción de la asesoría legal, con acciones y especificaciones concretas;
c) para FOS_MON.3: Descripción del marco de los parámetros de la alarma y registros de respuesta ante una alarma,
con acciones y especificaciones concretas y registros de realización del control;
d) para FOS_MON.4: Descripción de procedimientos para revisar las actividades de monitorización, con acciones y
especificaciones concretas y registros de realización de las revisiones.
B.3.4.4 FOS_MON.1 Registros de auditoría

FOS_MON.1.1 La OSF debe planificar [asignación: requisitos de seguridad] para auditorías y actividades que
impliquen verificaciones de los sistemas operacionales y acordar minimizar los riesgos de interrupción de los
procesos de negocio.
FOS_MON.1.2 La OSF debe definir [asignación: requisitos de seguridad] sobre auditoría con dirección apropiada.
FOS_MON.1.3 La SSF debe producir [asignación: logging] del administrador del sistema y actividades del
operador del sistema. El registro debe incluir el momento en que se produjo un evento o fallo, información
acerca del evento o fallo, qué cuenta y qué administrador u operador se vieron afectados, todos los cambios a
equipamiento, software o procedimientos.
FOS_MON.1.4 La OSF debe definir [asignación: reglas] para registro del equipamiento desconectado y
reconectado tras ser devuelto.
FOS_MON.1.5 La OSF debe definir [asignación: requisitos de seguridad] sobre logging de copiado y uso de
información operacional para ofrecer una traza de auditoría.
FOS_MON.1.6 La OSF debe definir [asignación: procedimientos] sobre recogida de trazas de auditoría y
evidencias similares.
FOS_MON.1.7 La OSF debe definir [asignación: requisitos de seguridad] sobre guardar un registro de todas la
remociones de dispositivos removibles en la organización para mantener una traza de auditoría.
FOS_MON.1.8 La OSF debe establecer [asignación: procedimientos] para monitorizar el uso de instalaciones de
proceso de información y revisar regularmente los resultados de las actividades de monitorización.
FOS_MON.1.9 La SSF debe ofrecer [asignación: medidas de seguridad] para proteger instalaciones de logging e
información de los registros contra alteración y acceso no autorizado.
ISO/IEC TR 19791:2010 - 72 -
FOS_MON.1.10 La SSF debe producir [asignación: procedimientos] para registrar fallos, análisis y acciones
apropiadas tomadas.
B.3.4.5 FOS_MON.2 Asesoría legal

FOS_MON.2.1 La OSF debe definir [asignación: reglas] para realizar una asesoría legal antes de implantar
procedimientos de monitorización.
B.3.4.6 FOS_MON.3 Requisitos de alarma

FOS_MON.3.1 La SSF debe ofrecer [asignación: medidas] para alarma para el sistema operacional.
FOS_MON.3.2 La SSF debe ofrecer [asignación: capacidades] para establecer parámetros de alarma, eventos de
alarma predefinidos y cambios de alarma en los parámetros de alarma del sistema operacional.
FOS_MON.3.3 La OSF debe definir [asignación: reglas y procedimientos] que estén definidos para su ejecución
tras las recepción de alarmas y las acciones requeridas, incluyendo cualquier limitación temporal, personas
responsables y reporte.
B.3.4.7 FOS_MON.4 Uso del sistema de monitorización

FOS_MON.4.1 La OSF debe ofrecer [asignación: procedimientos] para monitorizar el uso de las instalaciones de
proceso de información y revisar los resultados de las actividades de monitorización.
FOS_MON.4.2 La OSF debe definir [asignación: requisitos de seguridad] por los que el nivel de monitorización
requerido para instalaciones individuales se determine por medio de una evaluación del riesgo.
B.3.5 Control de personal de sistemas de TI (FOS_PSN)

Esta familia define el control de personal para los sistemas de TI. Incluye la especificación de autorización del usuario,
código malicioso, uso del sistema e instalaciones.
FOS_PSN.1 Autorización del usuario. Están definidos registro del usuario, autenticación del usuario y reglas para
mantener confidencial información de autenticación, como las contraseñas.
FOS_PSN.2 Uso del sistema. Están definidos procedimientos para cerrar sesiones activas.
B.3.5.3 Registros
a) para FOS_PSN.1: Descripción del registro del usuario, autenticación del usuario y reglas para mantener confiden-
cial la información de autenticación, con acciones y especificaciones concretas y registros de realización del control;
b) para FOS_PSN.2: Descripción de procedimientos para cerrar sesiones activas, con acciones y especificaciones con-
cretas y registros de realización del control.
- 73 - ISO/IEC TR 19791:2010
B.3.5.4 FOS_PSN.1 Autorización del usuario
Dependencias: FOM_PRM.2 Segregación de privilegios

FOD_PSN.1 Roles y responsabilidades del personal
POD_PSN.3 Acuerdo con el personal
FOS_PSN.1.1 La OSF debe definir [asignación: procedimientos] para un registro y borrado formal de usuarios
para otorgar y revocar acceso a todos los sistemas y servicios de información.
FOS_PSN.1.2 La OSF debe definir [asignación: procedimientos] que incluyan el uso de identificadores únicos de
usuario de forma que los usuarios puedan enlazarse con sus acciones y hacerse responsables de ellas (el uso de
identificadores de grupo solo debería permitirse cuando sean apropiados para el trabajo a desarrollar),
verificando que el usuario tiene autorización del propietario del sistema para usar el sistema o servicio solicitado
en el procedimiento de control de acceso dentro del proceso de registro y borrado de usuario.
FOS_PSN.1.3 La OSF debe definir [asignación: procedimientos] para la emisión de información temporal de
autenticación tras una identificación positiva del usuario cuando los usuarios olviden o pierdan su información
de autenticación. La información temporal de autenticación debe enviarse a los usuarios de forma segura.
FOS_PSN.1.4 La OSF debe definir [asignación: reglas] para impedir la pérdida o compromiso de información de
autenticación, por ejemplo evitar mantener un registro de contraseñas salvo que pueda almacenarse de forma
segura, seleccionar contraseñas de calidad con suficiente longitud mínima, no basadas en nada que nadie más
pueda adivinar fácilmente u obtenerse utilizando información relacionada con la persona, cambiar las contra-
señas a intervalos regulares o basándose en el número de accesos y evitar el reuso o reciclaje de contraseñas
antiguas, cambiar las contraseñas temporales tras el primer log-on, no incluir contraseñas en ningún proceso
automatizado de log-on y no compartir contraseñas individuales de usuarios.
FOS_PSN.1.5 La OSF debe definir [asignación: reglas] para firmar una declaración para impedir la pérdida,
compromiso o mal uso de información de autenticación, por ejemplo, mantener confidenciales las contraseñas
personales y las contraseñas de grupo de trabajo solamente dentro del grupo.
FOS_PSN.1.6 La SSF debe ofrecer [asignación: medidas] para ofrecer a los usuarios inicialmente información de
autenticación temporal segura que se vean obligados a cambiar o confirmar inmediatamente.
FOS_PSN.1.7 La OSF debe definir [asignación: reglas] por las que la información de autenticación nunca se
almacena en un sistema informático de una forma no protegida.
FOS_PSN.1.8 La OSF debe definir [asignación: un proceso formal de gestión] para controlar la asignación de
datos de autenticación a los usuarios.
B.3.5.5 FOS_PSN.2 Uso del sistema

FOS_PSN.2.1 La OSF debe definir [asignación: procedimientos] para cerrar sesiones activas al terminar, salvo
que puedan asegurarse con un mecanismo de cierre apropiado.
FOS_PSN.2.2 La OSF debe definir [asignación: procedimientos] para el log-off en ordenadores centrales,
servidores y ordenadores de oficina cuando se finalice la sesión.
FOS_PSN.2.3 La OSF debe definir [asignación: reglas] para usar distintos perfiles de usuario para sistemas y
menús operacionales y de prueba.
FOS_PSN.2.4 La OSF debe definir [asignación: reglas] de no dejar ordenadores personales y terminales infor-
máticos e impresoras logados cuando no estén atendidos y protegerlos con llaves, contraseñas u otros controles
cuando no se usen.
ISO/IEC TR 19791:2010 - 74 -
B.3.6 Activos del sistema operacional de sistemas de TI (FOS_OAS)

Esta familia define la seguridad de los activos operacionales de los sistemas de TI. Incluye la especificación de protec-
ción de activos operacionales, programa del sistema, backup e información de autenticación.
FOS_OAS.1 Protección de activos operacionales. Están definidos el borrado de la información operacional, el control
de acceso y el mantenimiento seguro de las documentaciones del sistema. Están definidos criterios para la aceptación de
nuevos sistemas, reglas de uso de los programas de utilidad, procedimientos de autenticación de utilidades del sistema,
procedimientos de actualización del software operacional, reglas para no usar software no autorizado y responsabili-
dades para el seguimiento de la emisión de parches de los vendedores.
FOS_OAS.2 Procedimientos de backup. Están definidos procedimientos de backup de información y software.
B.3.6.3 Registros
a) para FOS_OAS.1: Descripción del registro del borrado de la información operacional, el control de acceso y el man-
tenimiento seguro de la documentación del sistema, con acciones y especificaciones concretas y registros de realización
del control. Descripción de los criterios para la aceptación de nuevos sistemas, reglas de uso de los programas de
utilidad, procedimientos de autenticación de utilidades del sistema, procedimientos de actualización del software
operacional, reglas para no usar software no autorizado y responsabilidades para el seguimiento de la emisión de
parches de los vendedores, con acciones y especificaciones concretas y registros de realización del control;
b) para FOS_OAS.2: Descripción de procedimientos de backup de información y software, con acciones y especifi-
caciones concretas y registros de realización del control.
B.3.6.4 FOS_OAS.1 Protección de activos operacionales

Dependencias: FOS_POL.1 Requisitos de seguridad.
FOS_OAS.1.1 La OSF debe definir [asignación: reglas] para el borrado de información operacional de un
sistema de aplicación de prueba inmediatamente después de completar la prueba.
FOS_OAS.1.2 La OSF debe definir [asignación: requisitos de seguridad] para el control de las listas de
programas en un entorno seguro.
FOS_OAS.1.3 La SSF debe ofrecer [asignación: controles] para la protección y mantenimiento seguro de
documentación del sistema frente a accesos no autorizados.
FOS_OAS.1.4 La SSF debe ofrecer [asignación: controles] para no hacer accesibles compiladores, editores y
otras herramientas de desarrollo o utilidades del sistema para sistemas operacionales.
FOS_OAS.1.5 La OSF debe definir [asignación: criterios de aceptación] para nuevos sistemas informáticos y
actualizaciones y para nuevas versiones a establecer y pruebas apropiadas desarrolladas durante el desarrollo
antes de la aceptación.
FOS_OAS.1.6 La OSF debe definir [asignación: requisitos de seguridad] para la detección, prevención y
recuperación para protegerse contra el código malicioso y concienciación del usuario.
FOS_OAS.1.7 La OSF debe definir [asignación: reglas] para restringir y controlar el uso de programas de
utilidad que podrían ser capaces de eludir controles de sistemas y aplicaciones.
- 75 - ISO/IEC TR 19791:2010
FOS_OAS.1.8 La SSF debe ofrecer [asignación: controles] para autenticación de utilidades del sistema,
segregación de utilidades del sistema de software de aplicaciones, limitación del uso de utilidades del sistema al
número práctico mínimo de usuarios de confianza autorizados.
FOS_OAS.1.9 La OSF debe definir [asignación: procedimientos] para la actualización de las aplicaciones de
software operacional, bibliotecas de aplicaciones y programas por parte de administradores con formación bajo
una autorización de gestión apropiada.
FOS_OAS.1.10 La OSF debe definir [asignación: reglas] por las que solo haya código ejecutable en el sistema
operacional.
FOS_OAS.1.11 La OSF debe definir [asignación: reglas] por las que las aplicaciones y el software del sistema
operativo se implantan después de pruebas extensivas con éxito.
FOS_OAS.1.12 La OSF debe definir [asignación: reglas] por las que el acceso físico o lógico se otorga solo a
proveedores para fines de soporte cuando sea necesario y con aprobación de la dirección.
FOS_OAS.1.13 La OSF debe definir [asignación: reglas] para que no se use software no autorizado.
FOS_OAS.1.14 La OSF debe definir [asignación: responsabilidades] para el seguimiento de las publicaciones de
parches y reparaciones de los vendedores para programas de aplicación.
FOS_OAS.1.15 La OSF debe definir [asignación: procedimientos] para actualizar a nuevas versiones teniendo en
cuenta la seguridad de la versión, la introducción de nuevas funcionalidades de seguridad y la severidad de las
problemas de seguridad que afecten a la versión actual.
FOS_OAS.1.16 La OSF debe definir [asignación: reglas] para el uso aceptable de información y activos
asociados con las instalaciones de proceso de información a identificar, documentar e implantar.
B.3.6.5 FOS_OAS.2 Procedimientos de backup

FOS_OAS.2.1 La SSF debe ofrecer [asignación: procedimientos] para tomar y probar copias de backup de
información y software periódicamente de acuerdo con una política acordada de backups.
FOS_OAS.2.2 La OSF debe definir [asignación: procedimientos] para producir el nivel necesario de información
de backup, junto con registros exactos y completos de las copias de backup y los procedimientos de restauración
documentados.
FOS_OAS.2.3 La OSF debe definir [asignación: procedimientos] para los medios de backup para garantizar que
puede confiarse en ellos para un uso de emergencia cuando sea necesario.
FOS_OAS.2.4 La OSF debe definir [asignación: procedimientos] para asegurar que los procedimientos
operacionales de recuperación son eficaces y pueden completarse en el tiempo asignado.
FOS_OAS.2.5 La OSF debe definir [asignación: requisitos de seguridad] sobre acuerdos de backup para sistemas
individuales con el fin de asegurar que cumplen con los requisitos de las planes de continuidad de negocio.
B.3.7 Registros para sistemas de TI (FOS_RCD)

Esta familia define los registros a mantener para sistemas de TI. Incluye la especificación de los registros.
ISO/IEC TR 19791:2010 - 76 -
FOS_RCD.1 Registros. Está definido el registro de todos los supuestos fallos.
B.3.7.3 Registros
a) para FOS_RCD.1: Descripción todos los supuestos fallos, con acciones y especificaciones concretas y registros de
realización del control.
B.3.7.4 FOS_RCD.1 Registros

FOS_RCD.1.1 La SSF debe ofrecer [asignación: medidas] para registrar todos los fallos supuestos o reales y el
mantenimiento correctivo de los equipos.
B.4 Clase FOA: Activos del usuario

Esta clase ofrece requisitos de control operacional para activos del usuario del sistema operacional.
B.4.1 Protección de datos de privacidad (FOA_PRO)

Esta familia define la política para los activos del usuario. Incluye la especificación de datos de privacidad, criptografía,
gestión de activos del usuario y roles y responsabilidades.
FOA_PRO.1 Datos de privacidad. Están definidas reglas para que no se usen las bases de datos operacionales que
contengan información personal para pruebas, reglas para obtener información disponible públicamente cumpliendo con
la legislación de protección de datos y responsabilidades del propietario de los datos de informar a la persona
responsable de la organización para la protección de datos.
B.4.1.3 Registro
a) para FOA_PRO.1: Descripción de las reglas para que no se usen las bases de datos operacionales que contengan
información personal para pruebas, reglas para obtener información disponible públicamente cumpliendo con la
legislación de protección de datos, responsabilidades del propietario de los datos de informar a la persona
responsable de la organización para la protección de datos, con acciones y especificaciones concretas y registros de
realización del control.
B.4.1.4 FOA_PRO.1 Datos de privacidad

FOA_PRO.1.1 La OSF debe definir [asignación: reglas] para que no se usen bases de datos que contengan
información personal para fines de prueba.
FOA_PRO.1.2 La OSF debe definir [asignación: reglas] para obtener la información disponible públicamente
cumpliendo con la legislación de protección de datos, para procesarla de forma completa, adecuada y puntual y
para protegerla durante el proceso de recogida y al almacenarla.
- 77 - ISO/IEC TR 19791:2010
FOA_PRO.1.3 La OSF debe definir [asignación: responsabilidades y reglas] del propietario de los datos de
informar a la persona autorizada de la organización responsable de la protección de datos acerca de cualquier
propuesta para guardar información personal y asegurar la concienciación sobre los principios de protección de
datos definidos en la legislación relevante.
B.4.2 Protección de información de activos del usuario (FOA_INF)

Esta familia define la protección de información de activos del usuario. Incluye protección de datos, procedimientos y
reglas.
FOA_INF.1 Protección de datos. Están definidas directrices sobre retención de registros en tránsito, procedimientos
para permitir la destrucción apropiada de registros y seguridad para comunicaciones electrónicas. Están definidos proce-
dimientos de clasificación y manejo de información.
B.4.2.3 Registro
a) para FOA_INF.1: Directrices sobre retención de registros en tránsito, procedimientos para permitir la destrucción
apropiada de registros y seguridad para comunicaciones electrónicas, con acciones y especificaciones concretas.
Descripción de procedimientos de clasificación y manejo de información, con acciones y especificaciones concretas
y registros de realización del control.
B.4.2.4 FOA_INF.1 Protección de datos

FOA_INF.1.1 La OSF debe definir [asignación: directrices] sobre retención, almacenamiento, manejo y
eliminación de registros e información.
FOA_INF.1.2 La OSF debe definir [asignación: reglas] para una planificación de retención que identifique los
tipos esenciales de registros y el periodo de tiempo que deberían retenerse.
FOA_INF.1.3 La OSF debe definir [asignación: procedimientos] para permitir una destrucción apropiada de
registros tras ese periodo si no son necesarios para la organización.
FOA_INF.1.4 La SSF debe ofrecer [asignación: medidas] por las que la información deba destruirse, borrarse o
sobrescribirse utilizando técnicas apropiadas para dispositivos que contengan información sensible.
FOA_INF.1.5 La SSF debe ofrecer [asignación: medidas] para las comunicaciones electrónicas protegiendo los
mensajes ante acceso, modificación o denegación de servicios no autorizados, asegurando un correcto
direccionamiento y transporte del mensaje, confiabilidad y disponibilidad del servicio, consideraciones legales.
FOA_INF.1.6 La OSF debe definir [asignación: procedimientos] para clasificación y manejo de información
incluyendo tanto formatos físicos como electrónicos de acuerdo con un plan de clasificación adoptado por la
organización.
FOA_INF.1.7 La OSF debe definir [asignación: reglas] para la identificación de privilegios asociada con cada
producto del sistema y cada aplicación y las categorías de personal a las que tienen que asignarse.
FOA_INF.1.8 La OSF debe definir [asignación: reglas] para la asignación de privilegios a usuarios basándose en
la necesidad de uso y caso por caso, en línea con la política de control de accesos.
ISO/IEC TR 19791:2010 - 78 -
FOA_INF.1.9 La OSF debe definir [asignación: requisitos de seguridad] para proteger la información
relacionada con el comercio electrónico que pase por redes públicas ante actividades fraudulentas, disputas
contractuales y divulgación y modificación no autorizada.
B.5 Clase FOB: Negocio

Esta clase ofrece requisitos de control operacional para negocios del sistema operacional.
B.5.1 Políticas de negocio (FOB_POL)

Esta familia define las políticas de negocio. Incluye la especificación de requisitos de seguridad y propiedad intelectual.
FOB_POL.1 Requisitos de seguridad. Están definidos el valor de los activos de información afectados, requisitos de
seguridad de aplicaciones individuales de negocio, identificación de toda la información relacionada con las aplica-
ciones de negocio y roles y responsabilidades de seguridad para implantar y mantener políticas de seguridad. Están
definidos procedimientos apropiados para asegurar el cumplimiento de las restricciones legales en el uso del material.
B.5.1.3 Registro
a) para FOB_POL.1: Descripción del valor de los activos de información afectados, requisitos de seguridad de
aplicaciones individuales de negocio, identificación de toda la información relacionada con las aplicaciones de
negocio y roles y responsabilidades de seguridad para implantar y mantener políticas de seguridad, procedimientos
apropiados para asegurar el cumplimiento de las restricciones legales en el uso del material, con acciones y
B.5.1.4 FOB_POL.1 Requisitos de seguridad
Dependencias: FOS_POL.1 Requisitos de seguridad.
FOB_POL.1.1 La OSF debe especificar [asignación: política de seguridad] para determinar el valor de negocio
del sistema y los activos de información que forman parte del sistema general.
FOB_POL.1.2 La OSF debe definir [asignación: requisitos de seguridad] de aplicaciones individuales de negocio,
identificación de toda la información relacionada con aplicaciones de negocio y riesgos que afronta la
información, políticas para la divulgación y autorización de información, consistencia entre las políticas de
control de acceso y la clasificación de la información de distintos sistemas y redes, legislación relevante y
cualesquiera obligaciones contractuales respecto de la protección del acceso a datos o servicios, gestión de los
derechos de acceso en un entorno distribuido y en red que reconozca todos los tipos de conexiones disponibles.
FOB_POL.1.3 La OSF debe definir [asignación: roles y responsabilidades] para implantar y mantener políticas
de seguridad para la protección del activo.
FOB_POL.1.4 La OSF debe definir [asignación: roles y responsabilidades] y comunicación a los candidatos
laborales durante el proceso de preasignación.
FOB_POL.1.5 La OSF debe definir [asignación: procedimientos] para asegurar el cumplimiento de los requisitos
legislativos, regulatorios y contractuales sobre el uso del material con respecto a los cuales pueda haber derechos
de propiedad intelectual y sobre el uso de productos de software propietario.
- 79 - ISO/IEC TR 19791:2010
FOB_POL.1.6 La OSF debe desarrollar e implantar [asignación: políticas y procedimientos] para proteger
información asociada con la interconexión de sistemas de información de negocio.
B.5.2 Continuidad de negocio (FOB_BCN)

Esta familia define las actividades de continuidad de negocio. Incluye la especificación de análisis de impacto de
negocio, aislamiento de defectos y planes de continuidad de negocio.
FOB_BCN.1 Análisis de impacto. Están definidos análisis de impacto para la continuidad de negocio, planes de
continuidad de negocio para mantener o restaurar las operaciones de negocio, aislamiento de defectos de seguridad y
otorgamiento de accesos especiales en el momento de fallos de seguridad.
B.5.2.3 Registro
a) para FOB_BCN.1: Descripción del análisis de impacto para la continuidad de negocio, planes de continuidad de
negocio para mantener o restaurar las operaciones de negocio, planes de aislamiento de defectos y otorgamiento de
accesos especiales en el momento de fallos de seguridad, con acciones y especificaciones concretas.
B.5.2.4 FOB_BCN.1 Análisis de impacto
Dependencias: FOD_RSM.1 Gestión de riesgos dentro de la organización.
FOB_BCN.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre la realización de un análisis de
impacto en el negocio para identificar eventos que puedan causar interrupciones de procesos de negocio junto
con la probabilidad e impacto de dichas interrupciones y sus consecuencias para la información de seguridad.
FOB_BCN.1.2 La OSF debe definir [asignación: requisitos de seguridad] sobre realización de análisis de impacto
en la continuidad del negocio que implicación completa de propietarios de recursos y procesos de negocio.
FOB_BCN.1.3 La OSF debe definir [asignación: requisitos de seguridad] sobre planes de la continuidad de
negocio para recuperación ante ataques de código malicioso, incluyendo todos los backups de datos y software
necesarios y disposiciones de recuperación.
FOB_BCN.1.4 La OSF debe definir [asignación: requisitos de seguridad] para entender los riesgos que afronta la
organización en términos de su probabilidad e impacto, entendiendo el impacto que las interrupciones
probablemente produzcan en el negocio, formulando y documentando una estrategia de continuidad de negocio
coherente con los objetivos y las prioridades de negocio acordados, formulando y documentando planes de
continuidad del negocio en línea con la estrategia acordada, probando periódicamente y actualizando los planes
y procesos implantados y garantizando que la gestión de la continuidad de negocio está incorporada en los
procesos y estructura de la organización para la continuidad del negocio.
FOB_BCN.1.5 La OSF debe definir [asignación: requisitos de seguridad] para el desarrollo e implantación de
planes de continuidad de negocio para mantener o restaurar operaciones y garantizar la disponibilidad de la
información al nivel requerido y el plazos requeridos tras la interrupción o fallo de procesos críticos de negocio.
FOB_BCN.1.6 La OSF debe definir [asignación: procedimientos] por los que se guarda en una ubicación remota
una copia de los planes de continuidad de negocio, a una distancia suficiente como para escapar a cualquier daño
por desastre en la ubicación principal. Debe asegurarse que estas copias están actualizadas y protegidas con el
mismo nivel de seguridad que en la ubicación principal.
ISO/IEC TR 19791:2010 - 80 -
FOB_BCN.1.7 La OSF debe especificar [asignación: requisitos de seguridad] para las condiciones de su
activación, así como los individuos responsables de ejecutar cada componente del plan para cada plan de
continuidad de negocio.
FOB_BCN.1.8 La OSF debe definir [asignación: requisitos de seguridad] sobre prueba y actualización de planes
de continuidad de negocio para garantizar que están actualizados y son eficaces.
FOB_BCN.1.9 La OSF debe definir [asignación: requisitos de seguridad] sobre planes de aislamiento de fallos de
seguridad de forma que el impacto de un fallo sea mínimo en la continuidad del negocio sobre la ocurrencia de
incidentes de seguridad.
FOB_BCN.1.10 La OSF debe definir [asignación: reglas] para accesos especiales a los activos del sistema
operacional en el momento de fallos de seguridad.
FOB_BCN.1.11 La OSF debe definir [asignación: requisitos de seguridad] por los que se desarrolla y mantiene un
proceso gestionado para continuidad de negocio a lo largo de toda la organización que se ocupe de los requisitos
de seguridad de la información necesarios para la continuidad de negocio de la organización.
FOB_BCN.1.11 La OSF debe definir [asignación: requisitos de seguridad] para un marco único de planes de
continuidad para asegurarse de que todos los planes son consistentes, se ocupan de forma coherente de los
requisitos de seguridad de la información e identifican prioridades para pruebas y mantenimiento.
B.6 Clase FOP: Instalaciones y equipos

Esta clase ofrece requisitos de control operacional para equipos e instalaciones dentro del sistema operacional.
B.6.1 Equipamiento móvil (FOP_MOB)

Esta familia define requisitos de seguridad del equipamiento móvil. Incluye la especificación de requisitos de seguridad
y roles y responsabilidades.
FOP_MOB.1 Requisitos de seguridad para equipamiento móvil. Están definidos requisitos para la protección física y
procedimientos para ocuparse de las medidas de seguridad al usar instalaciones informáticas para móviles en lugares
públicos. Están definidas reglas para el uso de instalaciones de proceso de información de propiedad personal o privada
y reglas para equipos desatendidos.
B.6.1.3 Registro
a) para FOP_MOB.1: Descripción de requisitos para protección física y procedimientos para ocuparse de las medidas
de seguridad al usar instalaciones informáticas para móviles en lugares públicos, con acciones y especificaciones
concretas. Descripción de las reglas para el uso de instalaciones de proceso de información de propiedad personal o
privada y reglas para equipos desatendidos, con acciones y especificaciones concretas y registros de realización del
control.
B.6.1.4 FOP_MOB.1 Requisitos de seguridad para equipamiento móvil

FOP_MOB.1.1 La OSF debe definir [asignación: requisitos de seguridad] para riesgos de trabajar con equipos
informáticos móviles en entornos no protegidos en la política de informática móvil.
- 81 - ISO/IEC TR 19791:2010
FOP_MOB.1.2 La OSF debe definir [asignación: requisitos de seguridad] para protección física, controles de
acceso, técnicas criptográficas, backups y protección ante virus en la política de informática móvil.
FOP_MOB.1.3 La SSF debe definir [asignación: medidas] para protegerse contra riesgos de usar instalaciones
informáticas para móviles.
FOP_MOB.1.4 La OSF debe definir [asignación: procedimientos] para ocuparse de las medidas de seguridad
cuando se utilicen instalaciones informáticas para móviles en lugares públicos, salas de reuniones y otras áreas
no protegidas fuera de las instalaciones de la organización. La OSF debe dar protección apropiada para el uso de
instalaciones para móviles conectadas a redes.
FOP_MOB.1.5 La SSF debe definir [asignación: medidas] para la protección de instalaciones informáticas para
móviles por protección física ante robos especialmente cuando están desatendidas.
FOP_MOB.1.6 La OSF debe definir [asignación: reglas] para el uso de instalaciones de proceso de información
de propiedad personal o privada para el proceso de información de negocio.
FOP_MOB.1.7 La OSF debe definir [asignación: reglas] por las que no deberían dejarse equipamientos y medios
desatendidos en las instalaciones en lugares públicos y por las que los ordenadores portátiles deban
transportarse como equipaje de mano y ocultos cuando sea posible al viajar.
B.6.2 Equipamiento removible (FOB_RMM)

Esta familia define procedimientos de seguridad para equipamiento removible. Incluye la especificación de gestión de
los medios removibles.
FOP_RMM.1 Gestión de medios removibles. Están definidos procedimientos para la gestión de medios informáticos
removibles, procedimientos sobre autorización para medios fuera de la organización y procedimientos para el borrado
de contenidos de cualquier medio reutilizable.
B.6.2.3 Registro
a) para FOP_RMM.1: Descripción de procedimientos para la gestión de medios informáticos removibles, procedi-
mientos sobre autorización para medios fuera de la organización y procedimientos para el borrado de contenidos de
cualquier medio reutilizable, con acciones y especificaciones concretas y registros de realización del control.
B.6.2.4 FOP_RMM.1 Gestión de medios removibles

FOP_RMM.1.1 La OSF debe definir [asignación: procedimientos] para la gestión de medios informáticos
removibles.
FOP_RMM.1.2 La OSF debe definir [asignación: procedimientos] sobre autorización para medios fuera de la
organización.
FOP_RMM.1.3 La OSF debe definir [asignación: procedimientos] para la minimización de riesgos relativos al
filtrado de información sensible a personas no autorizadas para el establecimiento de procedimientos formales
para la eliminación segura de medios.
ISO/IEC TR 19791:2010 - 82 -
FOP_RMM.1.4 La OSF debe definir [asignación: procedimientos] para el borrado de contenidos, incluyendo
cualquier dato sensible y software licenciado de cualquier medio y equipamiento reutilizable que contenga
medios de almacenamiento que haya que eliminar de la organización cuando ya no sean necesarios y verificar
que se realiza completamente.
B.6.3 Equipamiento remoto (FOP_RMT)

Esta familia define procedimientos de seguridad para equipamiento remoto. Incluye la especificación de gestión de
equipamiento remoto.
FOP_RMT.1 Gestión de equipamiento remoto. Están definidas responsabilidades y procedimientos para la gestión y
uso de equipamiento remoto y los procedimientos para acceso remoto a información del negocio.
B.6.3.3 Registro
a) para FOP_RMT.1: Descripción de responsabilidades y procedimientos para la gestión y uso de equipamiento

remoto y los procedimientos para acceso remoto a información del negocio, con acciones y especificaciones
concretas y registros de realización del control.
B.6.3.4 FOP_RMT.1 Gestión de equipamiento remoto

FOP_RMT.1.1 La OSF debe definir [asignación: responsabilidades y procedimientos] para la gestión y uso de
equipamiento remoto incluyendo equipamiento en áreas de usuarios.
FOP_RMT.1.2 La OSF debe definir [asignación: procedimientos] para acceso remoto a información del negocio a
través de redes públicas utilizando instalaciones informáticas para móviles solo después de una identificación y
autenticación con éxito y con mecanismos apropiados de control de acceso.
FOP_RMT.1.3 La SSF debe ofrecer [asignación: medidas] para uso de candados o controles equivalentes para
prevenir el uso no autorizado de PC o terminales.
FOP_RMT.1.4 La SSF debe ofrecer [asignación: medidas] para la identificación automática de equipamiento
como medio de autenticar conexiones desde ubicaciones y equipos concretos.
FOP_RMT.1.5 La SSF debe ofrecer [asignación: controles] para el acceso físico y lógico a puertos de diagnóstico
y configuración.
B.6.4 Equipamiento del sistema (FOP_SYS)

Esta familia define procedimientos de seguridad para equipamiento del sistema. Incluye la especificación de gestión de
equipamiento del sistema.
FOP_SYS.1 Gestión de equipamiento del sistema. Están definidos equipamientos y medios de backup alternativos del
sitio, reglas para el mantenimiento de materiales peligrosos o combustibles, procedimientos para inspeccionar material
entrante y protección de cableado de redes.
- 83 - ISO/IEC TR 19791:2010
B.6.4.3 Registro
a) para FOP_SYS.1: Descripción de equipamientos y medios de backup alternativos del sitio, reglas para el manteni-
miento de materiales peligrosos o combustibles, procedimientos para inspeccionar material entrante y protección de
cableado de redes, con acciones y especificaciones concretas.
B.6.4.4 FOP_SYS.1 Gestión de equipamiento del sistema

FOP_SYS.1.1 La OSF debe definir [asignación: reglas] para equipamientos y medios de backup alternativos del
sitio a una distancia segura para evitar daños por un desastre en el sitio principal.
FOP_SYS.1.2 La OSF debe definir [asignación: reglas] para mantener materiales peligrosos o combustibles a
una distancia apropiada de un área segura.
FOP_SYS.1.3 La OSF debe definir [asignación: reglas] para mantener directorios y listines telefónicos internos
identificando ubicaciones de instalaciones de proceso de información sensible no accesibles por el público.
FOP_SYS.1.4 La OSF debe definir [asignación: procedimientos] para inspeccionar material entrante ante
posibles amenazas antes de que se traslade de las áreas de recepción y carga al punto de uso.
FOP_SYS.1.5 La SSF debe ofrecer [asignación: medidas] para la protección del cableado de red en áreas
públicas ante intercepción no autorizada o daños.
FOP_SYS.1.6 La OSF debe definir [asignación: reglas] para mantener el equipo de acuerdo con los intervalos y
especificaciones de servicio recomendados por el proveedor.
FOP_SYS.1.7 La OSF debe definir [asignación: reglas] por las que solo el personal autorizado de mantenimiento
debería realizar reparaciones de equipamiento de servicio.
FOP_SYS.1.8 La OSF debe definir [asignación: controles] para un nivel apropiado de protección física y
ambiental coherente con los estándares aplicados al sitio principal para información de backup. Los controles
aplicados a los medios en el sitio principal deben extenderse para cubrir el sitio de backup.
FOP_SYS.1.9 La OSF debe definir [asignación: reglas] para el mantenimiento de todos los medios en un entorno
seguro de acuerdo con las especificaciones del fabricante.
FOP_SYS.1.10 La OSF debe definir [asignación: responsabilidades] para la protección de equipamiento

desatendido para todos los empleados, subcontratados y terceros usuarios de los requisitos y procedimientos de
seguridad.
FOP_SYS.1.11 La OSF debe definir [asignación: procedimientos] para garantizar que toda la información
relevante se transfiere a la organización y se borra de forma segura del equipamiento, en caso de que un
empleado o subcontratado o tercero usuario compre el equipamiento de la organización o utilice su propio
equipamiento personal.
FOP_SYS.1.12 La OSF debe ofrecer [asignación: controles] para que medios que contengan información sean
protegidos contra acceso no autorizado, mal uso o corrupción durante su transporte fuera de los límites físicos de
la organización.
ISO/IEC TR 19791:2010 - 84 -
B.6.5 Gestión de las instalaciones (FOP_MNG)

Esta familia define la gestión de las instalaciones. Incluye especificaciones de seguridad física, suministros y enlaces de
comunicaciones.
FOP_MNG.1 Seguridad física. Está definida la seguridad física de oficinas, salas e instalaciones. Está definida la
separación de instalaciones de desarrollo, prueba y producción. Están definidos los requisitos para adecuar las
instalaciones de backup y la protección de las instalaciones de proceso de información.
FOP_MNG.2 Suministro de energía. Está definido el control de los suministros y el uso de generadores de respaldo.
FOP_MNG.3 Enlaces de comunicaciones. Está definido el control de los enlaces de comunicaciones externas.
B.6.5.3 Registro
a) para FOP_MNG.1: Descripción de seguridad física de oficinas, salas e instalaciones, separación de instalaciones de
desarrollo, prueba y producción, instalaciones adecuadas de backup y protección de las instalaciones de proceso de
información, con acciones y especificaciones concretas;
b) para FOP_MNG.2: Descripción del control de los suministros y el uso de generadores de respaldo, con acciones y
especificaciones concretas;
c) para FOP_MNG.3: Descripción del control de los enlaces de comunicaciones y disposiciones en caso de fallo, con
acciones y especificaciones concretas.
B.6.5.4 FOP_MNG.1 Seguridad física
Dependencias: FOD_PSN.5 Acceso a instalaciones y equipamiento.
FOP_MNG.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre seguridad física de oficinas, salas
e instalaciones contra daños por fuego, inundación, terremotos, explosiones, desórdenes civiles y otras formas de
desastre natural o de origen humano.
FOP_MNG.1.2 La OSF debe definir [asignación: requisitos de seguridad] para la separación de instalaciones de
desarrollo, prueba y producción para reducir riesgos de accesos no autorizados o cambios en el sistema
operacional.
FOP_MNG.1.3 La OSF debe definir [asignación: requisitos de seguridad] para adecuar instalaciones de backup
para garantizar que toda la información y software esenciales puedan recuperarse tras un desastre o fallo en los
medios.
FOP_MNG.1.4 La OSF debe definir [asignación: requisitos de seguridad] para la protección de instalaciones de
proceso de datos para evitar el acceso o divulgación no autorizada de información almacenada y procesada en
estas instalaciones.
B.6.5.5 FOP_MNG.2 Suministro de energía

FOP_MNG.2.1 La SSF debe ofrecer [asignación: controles] para la protección de equipamiento ante fallos de
energía y otras interrupciones causadas por fallos en las instalaciones de suministro.
- 85 - ISO/IEC TR 19791:2010
FOP_MNG.2.2 La OSF debe definir [asignación: requisitos de seguridad] para el uso de equipos UPS
(Uninterruptible Power Supply –Suministro de energía ininterrumpible).
FOP_MNG.2.3 La OSF debe definir [asignación: requisitos de seguridad] para el uso de un generador de
respaldo si ha de continuarse con el proceso en caso de un fallo de energía prolongado.
B.6.5.6 FOP_MNG.3 Enlaces de comunicaciones

FOP_MNG.3.1 La SSF debe ofrecer [asignación: controles] para la protección de cableado de energía y
telecomunicaciones que lleven datos o soporten comunicaciones frente a intercepción o daño.
FOP_MNG.3.2 La SSF debe definir [asignación: requisitos de seguridad] para garantizar que la conectividad de
las comunicaciones puede mantenerse en caso de fallo o interrupción del equipamiento de comunicaciones.
B.7 Clase FOT: Terceros

Esta clase ofrece requisitos de control operacional para terceros.
B.7.1 Gestión de terceros (FOT_MNG)

Esta familia define la gestión y compromisos para terceros. Incluye la especificación de outsourcing y requisitos de
seguridad de terceros.
FOT_MNG.1 Outsourcing. Está definido un plan para las transiciones necesarias de información, acuerdos de
licencias, propiedad del código y derechos de propiedad intelectual.
FOT_MNG.2 Requisitos de seguridad de terceros. Están definidos todos los requisitos de seguridad resultantes de
trabajar con terceros. Están definidos suficientes controles y reglas generales para no ofrecer acceso a la información de
la organización. Está definida la gestión del riesgo aplicable a las relaciones con terceros.
B.7.1.3 Registro
a) para FOT_MNG.1: Descripción de un plan para las transiciones necesarias de información, acuerdos de licencias,
propiedad del código y derechos de propiedad intelectual, con acciones y especificaciones concretas;
b) para FOT_MNG.2: Descripción de todos los requisitos de seguridad resultantes de trabajar con terceros, suficientes
controles y reglas generales para no ofrecer acceso a la información de la organización y gestión del riesgo, con
acciones y especificaciones concretas.
B.7.1.4 FOT_MNG.1 Outsourcing
Dependencias: FOD_PSN.3 Acuerdo personal.
FOT_MNG.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre un plan para las transiciones de
información necesarias, instalaciones de proceso de información y cualquier otra cosa que necesite trasladarse y
el mantenimiento de seguridad en el periodo de transición para la realización del outsourcing.
ISO/IEC TR 19791:2010 - 86 -
FOT_MNG.1.2 La OSF debe definir [asignación: requisitos de seguridad] para acuerdo de licenciamiento,
propiedad de código y derechos de propiedad intelectual, certificación de la calidad y precisión del trabajo
realizado, acuerdos de escrow en caso de fallo del tercero, derechos de acceso para auditoría de la calidad y
precisión del trabajo realizado, requisitos contractuales para la calidad del código y la prueba antes de la
instalación para detectar código de troyanos cuando se subcontrate desarrollo de software.
B.7.1.5 FOT_MNG.2 Requisitos de seguridad de terceros

FOT_MNG.2.1 La OSF debe definir [asignación: requisitos de seguridad] resultantes del trabajo con terceros o
controles internos en el acuerdo con los terceros.
FOT_MNG.2.2 La OSF debe definir [asignación: requisitos de seguridad] para garantizar el cumplimiento de las
políticas y estándares de seguridad de la organización en los acuerdos con terceros que impliquen acceder,
procesar, comunicar o gestionar información de la organización o instalaciones de proceso de información.
FOT_MNG.2.3 La OSF debe definir [asignación: requisitos de seguridad] para un control general y aspectos de
seguridad suficientes para información crítica o sensible o instalaciones de proceso de información accedidos
procesados o gestionados por terceros.
FOT_MNG.2.4 La OSF debe definir [asignación: reglas] para no ofrecer acceso a la información de la
organización a terceros hasta que estén implantados los controles y se haya firmado un acuerdo que defina los
términos y condiciones para la conexión o acceso y el plan de trabajo.
FOT_MNG.2.5 La OSF debe definir [asignación: requisitos de seguridad] para la realización de la gestión del
riesgo de los procesos de negocio con terceros y personal de terceros.
FOT_MNG.2.6 La OSF debe definir [asignación: requisitos de seguridad] para la realización de la gestión del
riesgo de los diferentes medios de almacenamiento y proceso de información que utilizarán los terceros.
FOT_MNG.2.7 La OSF debe definir [asignación: procedimientos] para que el desarrollo de software
subcontratado sea supervisado y monitorizado por las organizaciones.
FOT_MNG.2.8 La OSF debe definir [asignación: requisitos de seguridad] para confirmar que los controles de
seguridad, definiciones de servicio y niveles de entrega incluidos en el acuerdo de entrega de servicio de terceros
se implantan, operan y mantienen por parte del tercero.
FOT_MNG.2.9 La OSF debe definir [asignación: requisitos de seguridad] por los que los servicios, informes y
registros ofrecidos por los terceros sean monitorizados y revisados regularmente y se realicen periódicamente
auditorías.
FOT_MNG.2.10 La OSF debe definir [asignación: requisitos de seguridad] por los que los cambios a la provisión
de servicios, incluyendo el mantenimiento y la mejora de las políticas, procedimientos y controles existentes de
seguridad de la información se gestionen, teniendo en cuenta la criticidad de los sistemas del negocio y los
procesos implicados y la reevaluación de los riesgos.
FOT_MNG.2.11 La OSF debe definir [asignación: requisitos de seguridad] a cubrir en los acuerdos con terceros
que impliquen acceder, procesar, comunicar o gestionar información o instalaciones de proceso de información
de la organización o añadir productos o servicios a las instalaciones de proceso de información.
B.8 Clase FOM: Gestión

Esta clase ofrece requisitos para la gestión de los controles operacionales.
- 87 - ISO/IEC TR 19791:2010
B.8.1 Gestión de los parámetros de seguridad (FOM_PRM)

Esta familia define la gestión de los parámetros de seguridad. Incluye la especificación del uso de criptografía y
privilegios.
FOM_PRM.1 Uso de criptografía. Está definida la aproximación a la gestión de claves, incluyendo métodos para
ocuparse de la protección de claves criptográficas y recuperación de la información cifrada.
FOM_PRM.2 Segregación de privilegios. Está definida la segregación de privilegios.
B.8.1.3 Registro
a) para FOM_PRM.1: Descripción de la aproximación a la gestión de claves, incluyendo métodos para ocuparse de la
protección de claves criptográficas y recuperación de la información cifrada, con acciones y especificaciones
concretas;
b) para FOM_PRM.2: Descripción de la segregación de privilegios, con acciones y especificaciones concretas.
B.8.1.4 FOM_PRM.1 Uso de criptografía
Dependencias: FOS_POL.4 Política de criptografía.
FOM_PRM.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre la aproximación de gestión
respecto del uso de controles criptográficos en toda la organización, la aproximación a la gestión de claves,
incluyendo métodos para ocuparse de la protección de claves criptográficas y recuperación de información
cifrada en caso de pérdida, compromiso o daño en claves, roles y responsabilidades, quién es responsable de la
implantación de la política y regulaciones y restricciones nacionales que podrían aplicarse para el uso de técnicas
criptográficas en distintas partes del mundo y a los asuntos de flujo transfronterizo de información cifrada para
la política criptográfica de la organización.
B.8.1.5 FOM_PRM.2 Segregación de privilegios
FOM_PRM.2.1 La OSF debe definir [asignación: reglas] para la segregación de privilegios para reducir
oportunidades para una modificación o mal uso no autorizado de activos y la separación del inicio de un evento
de su autorización.
FOM_PRM.2.2 La OSF debe definir [asignación: requisitos de seguridad] sobre la asignación de privilegios a una
identidad de usuarios diferente de las utilizadas para los usos normales de negocio.
B.8.2 Gestión de la clasificación de activos (FOM_CLS)

Esta familia define la clasificación de los activos. Incluye la categorización.
ISO/IEC TR 19791:2010 - 88 -
FOM_CLS.1 Categorización. Está definida la categorización de los registros.
FOM_CLS.2 Identificación de activos. Está definida la identificación de activos.
B.8.2.3 Registro
a) para FOM_CLS.1: Descripción de la categorización de los registros, con especificaciones concretas.
b) Para FOM_CLS.2: Descripción de la identificación de activos, con especificaciones concretas.
B.8.2.4 FOM_CLS.1 Categorización
FOM_CLS.1.1 La OSF debe definir [asignación: requisitos de seguridad] sobre categorización de registros en
tipos de registro, registros de bases de datos, logs de transacciones, logs de auditoría y procedimientos
operativos, cada uno con detalles de periodos de retención y tipo de medio de almacenamiento.
B.8.2.5 FOM_CLS.2 Identificación de activos
FOM_CLS.2.1 La OSF debe definir [asignación: requisitos de seguridad] sobre especificación de identificación,
especificación del tipo de activo, la función del activo, requisitos de gestión, ofrecer niveles de protección
proporcionales a la importancia de los activos, acordar la propiedad y clasificación de la seguridad y registro de
la ubicación actual en un inventario para cada activo.
FOM_CLS.2.2 La OSF debe definir [asignación: requisitos de seguridad] sobre preparación y mantenimiento de
un inventario de todos los activos importantes.
FOM_CLS.2.3 La OSF debe definir [asignación: requisitos de seguridad] sobre el periodo de retención para
información esencial para el negocio y asimismo de cualesquiera requerimientos para copias de archivo a retener
permanentemente.
B.8.3 Gestión de las responsabilidades de seguridad del personal (FOM_PSN)

Esta familia define las responsabilidades de seguridad del personal. Incluye propietarios de activos y gestores de seguridad.
FOM_PSN.1 Propiedad de activos. Está definida la propiedad de activos.
FOM_PSN.2 Gestores de seguridad. Está definida la asignación de gestores de seguridad.
B.8.3.3 Registro
a) para FOM_PSN.1: Descripción de la propiedad de activos, con especificaciones concretas;
b) para FOM_PSN.2: Descripción de la asignación de gestores de seguridad, con especificaciones concretas.
- 89 - ISO/IEC TR 19791:2010
B.8.3.4 FOM_PSN.1 Propiedad de activos
Dependencias: FOA_POL.3 Gestión de activos del usuario.
FOM_PSN.1.1 La OSF debe definir [asignación: requisitos de seguridad] por los que toda información y activos
relacionados con instalaciones de proceso de información sea propiedad de una parte designada de la
organización.
B.8.3.5 FOM_PSN.2 Gestores de seguridad
FOM_PSN.2.1 La OSF debe definir [asignación: requisitos de seguridad] sobre asignación de un gestor concreto
responsable para cada control de seguridad.
FOM_PSN.2.2 La OSF debe definir [asignación: requisitos de seguridad] por los que la dirección requiere a
empleados, subcontratados y terceros usuarios que apliquen la seguridad de acuerdo con las política y
procedimiento establecidos por la organización.
B.8.4 Gestión de la organización de seguridad (FOM_ORG)

Esta familia define la organización de la gestión de seguridad. Incluye responsabilidades de gestión de seguridad y
participación en el foro de gestión.
FOM_ORG.1 Responsabilidades de gestión. Están definidas las responsabilidades de gestión de seguridad.
FOM_ORG.2 Participación en el foro de gestión. Está definida la participación en el foro de gestión.
B.8.4.3 Registro
a) para FOM_ORG.1: Descripción de responsabilidades de gestión, con acciones y especificaciones concretas;
b) para FOM_ORG.2: Descripción de la participación en el foro de gestión, con especificaciones concretas.
B.8.4.4 FOM_ORG.1 Responsabilidades de gestión
Dependencias: FOD_ORG.1 Responsabilidades de coordinación de seguridad.
FOM_ORG.1.1 La OSF debe definir [asignación: responsabilidades] de la dirección para garantizar que la activi-
dades de seguridad cumplen con la política de seguridad, aprueban metodologías y procesos concretos para
seguridad de la información, monitorizan los cambios significativos en las amenazas y la exposición de los activos
de información ante amenazas, evalúan al adecuación y coordinan la implantación de controles concretos de
seguridad de la información para nuevos sistemas o servicios, promueven la visibilidad del apoyo a la seguridad
de la información a través de la organización.
FOM_ORG.1.2 La OSF debe definir [asignación: responsabilidades] para que los gestores se aseguren de que
todos los procedimientos dentro de su área de responsabilidad se realizan correctamente cumpliendo con las
políticas y estándares de seguridad.
ISO/IEC TR 19791:2010 - 90 -
FOM_ORG.1.3 La OSF debe definir [asignación: responsabilidades] para que los gestores revisen la política de
seguridad de información a intervalos planificados o si se producen cambios significativos para asegurar su
continua aplicabilidad, adecuación y eficacia.
B.8.4.5 FOM_ORG.2 Participación en el foro de gestión
Dependencias: FOD_ORG.2 Responsabilidades del foro de dirección.
FOM_ORG.2.1 La OSF debe definir [asignación: nombramiento de representantes de la dirección y de distintas

partes del grupo de la organización con papeles relevantes y funciones de trabajo] para el foro de gestión para
garantizar que están coordinadas las actividades de seguridad de la información.
B.8.5 Gestión de los informes de seguridad (FOM_INC)

Esta familia define la organización de la gestión de reporte de incidentes de seguridad. Incluye la gestión de os
problemas de seguridad reportados.
FOM_INC.1 Reporte de problemas de seguridad detectados. Está definida la gestión de los problemas de seguridad
reportados.
B.8.5.3 Registro
a) para FOM_INC.1: Descripción de procedimientos de reporte de seguridad, con acciones y especificaciones

concretas y registros de realización del control.
B.8.5.4 FOM_INC.1 Reporte de problemas de seguridad detectados
FOM_INC.1.1 La OSF debe definir [asignación: procedimientos] para anotar y reportar cualquier debilidad de
seguridad observada o sospechada en sistemas o servicios, o amenazas a ellos, a su dirección o directamente al
proveedor del servicio tan pronto como sea posible con el fin de prevenir incidentes de seguridad.
FOM_INC.1.2 La OSF debe definir [asignación: reglas] para prohibir intentar probar que existe una presunta
vulnerabilidad a través de un intento de explotarla.
- 91 - ISO/IEC TR 19791:2010
ANEXO C (Normativo)
REQUISITOS DE GARANTÍA DEL SISTEMA OPERACIONAL
C.1 Introducción
Este anexo define los componentes adicionales de garantía para sistemas operacionales además de los definidos en la
Norma ISO/IEC 15408-3. La Norma ISO/IEC 15408-3 se usa como base para la estructura de estos componentes.
La garantía de seguridad puede considerarse desde dos aspectos: corrección y efectividad. La corrección significa que
los mecanismos de seguridad se han implantado correctamente: que funcionan de acuerdo con las especificaciones de
seguridad y que se mantiene la disponibilidad de los servicios de seguridad. La efectividad significa que los mecanis-
mos de seguridad funcionan contra amenazas y vulnerabilidades de seguridad e impiden procesos no autorizados, como
la elusión de mecanismos de seguridad o la interferencia no autorizada con los mecanismos de seguridad. La garantía
puede obtenerse de actividades de todas las fases del ciclo de vida del sistema. Este concepto se ilustra en la tabla C.1 a
continuación.
Tanto la corrección como la efectividad pueden evaluarse mediante una evaluación de seguridad. Además, pueden tener
que tenerse en cuenta otras formas de garantía, como la asociada con la reputación del desarrollador del sistema y la
derivada de la madurez de los procesos usados para el desarrollo del sistema. Se puede encontrar más información sobre
este tema en la Norma ISO/IEC TR 15443 [6].
Muchos aspectos de la garantía de los sistemas operacionales están cubiertos por los criterios de evaluación bajo la
Norma ISO/IEC 15408-3. Sin embargo hay algunos aspectos de la garantía de los sistemas operacionales para los cuales
se requieren criterios adicionales.
Tabla C.1 – Garantía para sistemas operacionales
Etapa del
Factores Objetivos de garantía Clase/familia de garantía Actividades de evaluación
ciclo de vida
Los objetivos de seguridad deben
ocuparse de todos los riesgos iden-
Compensación del riesgo tificados como inaceptables.
Los requisitos de seguridad Los requisitos de seguridad deben
especificados en el SST son SST/SPP evaluación
corresponderse con los objetivos de
eficaces en reducir los riesgos (AST/ASP)
seguridad.
inaceptables a un nivel
tolerable. Las contramedidas de seguridad de-
ben cumplir el Especificación Resu-
men del STOE.
Desarrollo/
Integración Descripción de la arquitec-
Arquitectura del sistema tura del sistema operacional
Efectividad
operacional (ASD_SAD).
Las contramedidas de Concepto de seguridad de
seguridad de subsistemas, las operaciones Las contramedidas de seguridad de-
componentes, etc. funcionan (ASD_CON). ben funcionar eficazmente en com-
juntas para crear binación con otras contramedidas.
Interfaces de seguridad
propiedades seguras
(ASD_IFS).
requeridas para el sistema en
general. Diseño del STOE
(ASD_STD).
Deben realizarse análisis de vulnera-
Fortaleza de los mecanismos
bilidades y éstas no deben ser explota-
de seguridad Evaluación de bles por el supuesto ataque potencial.
Instalación La fortaleza de los vulnerabilidades
(AOV_VAN). Deben realizarse pruebas de pene-
mecanismos de seguridad es
tración y no debe haber problemas
eficaz para el sistema.
de seguridad.
ISO/IEC TR 19791:2010 - 92 -
Etapa del
ciclo de vida
Comunicación y formación en
concienciación Confirmación de
Debe confirmarse la comunicación
Las reglas y procedimientos comunicación y
y concienciación por registros y en-
se comunican y se da concienciación
trevistas.
formación eficazmente al (APR_CMM, APR_AWA).
personal apropiado.
Monitorización de
contramedidas de seguridad
Se recogen logs de auditoría Monitorización de la SSF Debe confirmarse que las contrame-
y registros de monitorización (ASO_MON). didas operan como se espera.
para demostrar que las
Operación funcionan como se espera.
Verificación
Se confirma que no se ha Verificación de la operación
detectado ningún riesgo que de la SSF (AOD_OGD, Debe confirmarse que no se detecta
debería contrarrestarse y los APR_AWA, APR_CMM, ningún riesgo inaceptable.
controles de seguridad ASO_RCD, ASO_VER).
funcionan como se espera.
Pruebas de regresión
Deben investigarse los problemas
Los controles de seguridad Pruebas de regresión
de seguridad detectados y comuni-
continúan funcionando como (AOT_REG).
carse los resultados.
se espera.
Modificación Pruebas de penetración
Pruebas de penetración
Los cambios en el sistema no Deben investigarse los problemas
(AOV_VAN) Verificación
crean agujeros en la de seguridad detectados y comuni-
de configuración correcta
cobertura de los controles de carse los resultados.
(AOD_OCD).
seguridad.
Correspondencia entre riesgo Los objetivos de seguridad deben
y requisitos de seguridad y ocuparse de todos los riesgos iden-
entre requisitos y tificados como inaceptables.
Los requisitos de seguridad deben
Los requisitos de seguridad se Evaluación de SST/SPP
corresponderse con los objetivos de
ocupan de todos los riesgos (AST/ASP)
seguridad.
inaceptables. Las
contramedidas de seguridad Las contramedidas de seguridad de-
cumplen todos los requisitos ben cumplir con la especificación
de seguridad. resumen del STOE.
Descripción de la
Corrección
arquitectura del sistema

Desarrollo/ operacional (ASD_SAD).
Integración Correspondencia con tareas Interfaces de seguridad
de desarrollo Deben implantarse las contramedi-
(ASD_IFS). das de seguridad sin modificacio-
Las contramedidas de Concepto de seguridad de nes, añadidos o borrados no autori-
seguridad están implantadas operaciones (ASD_CON), zados.
correctamente.
Diseño de STOE
(ASD_STD).
Pruebas (AOT).
Descripción de documentos
guía Deben describirse de forma sufi-
Descripción (AOD_OCD,
Las operaciones seguras ciente la configuración y operación
AOD_OGD).
están descritas correctamente de las contramedidas de seguridad.
en los documentos de guía.
- 93 - ISO/IEC TR 19791:2010
Etapa del
ciclo de vida
Configuración
Configuración (AOD_OCD, Deben verificarse las configuracio-
Los componentes y AOC). nes de componentes y subsistemas
subsistemas están y la operación de los controles.
Pruebas (AOT).
Instalación configurados correctamente.
Iniciación
Instalación e iniciación Deben confirmarse la instalación e
La iniciación del STOE se (APR_SIC). iniciación correctas.
ejecuta correctamente.
Monitorización de
contramedidas de seguridad Deben inspeccionarse las pistas de
Monitorización auditoría y los registros de monito-
Las contramedidas de (ASO_MON) rización de accesos y de utilización
seguridad se operan de activos.
correctamente.
Operación Verificación Verificación de instalación
Se confirma que no se han segura (APR_SIC).
detectado riesgos que Verificación de registros Deben verificarse los controles de
deberían contrarrestarse y los (ASO_RCD). seguridad.
controles de seguridad Verificación independiente
funcionan como se espera. (ASO_VER).
Verificación de requisitos
Se confirma que las Verificación de requisitos Deben analizarse los cambios en re-
modificaciones no han (ASD_RVR). quisitos.
invalidado los requisitos del
SST.
Verificación del diseño
Modificación Se confirma que las Verificación del diseño Deben analizarse los cambios en
modificaciones no han (AOD_GVR, ASD_DVR) diseño.
invalidado parte del diseño.
Pruebas de regresión
Deben investigarse los problemas
Se confirma que los controles Pruebas de regresión
de seguridad detectados y comuni-
de seguridad cambiados (AOT_REG).
carse los resultados.
funcionan como se espera.
Se definen en este anexo nueve clases nuevas de requisitos de garantía. Son:
a) evaluación del SPP (ASP);
b) evaluación del SST (ASS);
c) documento guía del sistema operacional (AOD);
d) documentación de arquitectura, diseño y configuración del sistema operacional (ASD);
e) gestión de la configuración del sistema operacional (AOC);
f) prueba del sistema operacional (AOT);
g) evaluación de las vulnerabilidades del sistema operacional (AOV);
h) preparación para la operación en real (APR);
i) registros del sistema operacional (ASO).
ISO/IEC TR 19791:2010 - 94 -
Hay nuevas clases de garantía para la evaluación de Perfiles de Protección del Sistema (SPP, System Protection
Profiles) y Objetivos de Seguridad del Sistema (SST, System Security Targets), ya que los contenidos de un SPP o un
SST se expanden respecto de los de un PP o ST de producto. Las otras nuevas clases se ocupan de los requisitos
adicionales de garantía para la evaluación del sistema operacional. La relación entre los requisitos adicionales de
garantía definidos en este anexo y las cuatro etapas del ciclo de desarrollo se muestran en la tabla C.2.
Tabla C.2 – Requisitos de garantía y ciclo de vida del sistema operacional

Ciclo vida Requisito de garantía
AOD_OCD.1 Descripción de la especificación de configuración
AOD_OGD.1 Descripción de los SSF relacionados con el usuario en la guía del usuario
ASD_SAD.1 Descripción de la arquitectura
ASD_CON.1 Concepto de seguridad de operaciones
ASD_IFS.1 Descripción de las interfaces externas
Desarrollo/ ASD_STD.1-3 Descripción del diseño del STOE
Integración AOT_COV.1 Cobertura de prueba para SSF
AOT_COV.2 Integridad de la cobertura de pruebas para SSF
AOT_DPT.1 Profundidad de pruebas para diseño de subsistemas
AOT_DPT.2 Profundidad de pruebas para diseño de componentes
AOT_DPT.3 Profundidad de pruebas para representación de implantación
AOT_FUN.1 Prueba funcional para SSF
AOD_OCD.2 Verificación de especificación de configuración
AOC_OBM.1-2 Gestión de configuración operacional
AOC_ECP.1-2 Configuración de los productos de componentes evaluados
AOC_UCP.1-2 Configuración de los productos de componentes no evaluados
AOT_COV.1 Cobertura de pruebas para SSF
AOT_COV.2 Integridad de la cobertura de pruebas para SSF
AOT_DPT.1 Profundidad de pruebas para diseño de subsistemas
Instalación AOT_DPT.2 Profundidad de pruebas para diseño de componentes
AOT_DPT.3 Profundidad de pruebas para representación de implantación
AOT_FUN.1 Prueba funcional para SSF
AOT_IND.1-3 Pruebas independientes
AOV_VAN.1-7 Evaluación de vulnerabilidades
APR_AWA.1 Formación en concienciación
APR_CMM.1 Comunicaciones sobre SSF al personal apropiado
APR_SIC.1 Instalación segura e iniciación del STOE
AOD_OGD.2 Verificación del uso de SSF en la guía del usuario
APR_AWA.2 Verificación de la formación en concienciación
APR_CMM.2 Verificación de la comunicación sobre SSF al personal
Operación APR_SIC.2 Verificación de la instalación e iniciación seguras
ASO_RCD.1-2 Verificación de registros operacionales
ASO_VER.1-2 Verificación de controles operacionales
ASO_MON.1-2 Monitorización de la gestión para SSF
AOD_GVR.1 Verificación del documento de guía
ASD_RVR.1 Verificación de requisitos
Modificación ASD_DVR.1 Verificación de diseño
AOT_REG.1 Prueba de regresión
AOV_VAN.1-7 Prueba de penetración
- 95 - ISO/IEC TR 19791:2010
Hay dos diferencias de presentación en este anexo respecto de la Norma ISO/IEC 15408-3. Se han renombrado los ele-
mentos de acción del desarrollador como elementos de acción del desarrollador/integrador, con el fin de reconocer que
un sistema operacional puede componerse por un integrador de sistema que sea distinto del desarrollador de compo-
nentes y productos utilizados dentro del sistema y ambos pueden colaborar en la producción y envío de la evidencia
necesaria. En algunos casos es la gestión del sistema operacional la responsable de la producción de evidencias y por
tanto en estas familias los elementos de acción para ofrecer evidencias se identifican como acciones de gestión.
Las dependencias entre los componentes de garantía se muestran en las siguientes tablas C.3 a C.5. Se han usado tres ta-
blas ya que las evaluaciones de SPP, SST y STOE se realizan independientemente y no hay interdependencias entre ca-
da grupo. Cada uno de los componentes que sea una dependencia de algún componente de garantía se asigna en una co-
lumna. Cada componente de garantía con dependencias se asigna en una fila. El valor en la tabla indica si el
componente de la columna se requiere directa (indicado por un cruz “X”) o indirectamente (indicado por un guión “-”)
por parte del componente de la fila.
Tabla C.3 – Dependencias de garantía de SPP
ASP_DMP.1
ASP_ECD.1
ASP_REQ.1
ASP_SPD.1
ASP_DMO.
ASP_OBJ.1
ASP_DMR.
ASP_INT.1
ASP_CCL.1 X X X X X
ASP_OBJ.1 X
ASP_REQ.1 X
ASP_REQ.2 X – X
ASP_DMI.1 X
ASP_DMC.1 – – X X X
ASP_DMO.1 X X
ASP_DMR.1 X
ASP_DMR.2 – X – X
ISO/IEC TR 19791:2010 - 96 -
Tabla C.4 – Dependencias de garantía de SST
ASP_DML.1.
ASP_DMP.1
ASS_ECD.1
ASS_REQ.1
ASS_SPD.1
ASP_DMO.
ASS_OBJ.1
ASP_DMR.
ASS_INT.1
ASS_CCL.1 X X X X X
ASS_OBJ.1 X
ASS_REQ.1 X
ASS_REQ.2 X – X
ASS_TSS.1 X – X
ASS_DMI.1 X
ASS_DMC.1 – – X X X
ASS_DMO.1 X X
ASS_DMR.1 X
ASS_DMR.2 – X – X
ASS_DMS.1 – – X X
Tabla C.5 – Dependencias de garantía de STOE
AOT_FUN.1
ASD_SAD.1
ASD_STD.1
ASD_STD.2
ASD_STD.3
AOD_OGD.
AOD_OCD.
ASD_CON.
ASD_IFS.1
AOCOBM.
AOD_OCD.1/2 – X – X
AOD_OGD.1/2 X
AOD_GVR.1 X X – – – –
ASD_CON.1 X
ASD_IFS.1 X
ASD_STD.1-3 X X
ASD_DVR.1 X X X X
AOC_ECP.1/2 X
AOC_UCP.1/2 X
AOT_COV.1/2 – X X
AOT_DPT.1 – – X X
AOT_IND.1 X – X
AOT_IND.2/3 X – X X
AOV_VAN.1 X X
AOV_VAN.2 X X X
AOV_VAN.3 X X X X
AOV_VAN.4-7 X X X X X
- 97 - ISO/IEC TR 19791:2010
C.2 Clase ASP: Evaluación del Perfil de Protección del Sistema
C.2.1 Introducción
Este capítulo ofrece criterios de garantía para la evaluación de Perfiles de Protección del Sistema (SPP). Se requiere la
evaluación del SPP para demostrar que un SPP es sólido y coherente internamente y, si el SPP deriva de uno o más SPP
o paquetes, que el SPP es una instanciación correcta de dichos SPP y paquetes. Estas propiedades son necesarias para
que el SPP sea apropiado para el uso como base para la posterior evaluación del STOE.
Las familias dentro de esta clase son las siguientes:
a) ASP_INT: Introducción del SPP;
b) ASP_CCL: Declaraciones de conformidad;
c) ASP_SPD: Definición del problema de seguridad;
d) ASP_OBJ: Objetivos de seguridad;
e) ASP_ECD: Definición de componentes extendidos;
f) ASP_REQ: Requisitos de seguridad;
g) ASP_DMI: Introducción del dominio de seguridad;
h) ASP_DMC: Declaraciones de conformidad del dominio de seguridad;
i) ASP_DMP: Definición del problema de seguridad del dominio de seguridad;
j) ASP_DMO: Objetivos de seguridad del dominio de seguridad;
k) ASP_DMR: Requisitos de seguridad del dominio de seguridad.
C.2.2 Parte común de SPP

Las siguientes especificaciones aplican a todo el SPP. La especificaciones para dominios concretos debería describirse
utilizando las familias de dominios (véase C.2.9).
C.2.3 Introducción del SPP (ASP_INT)
C.2.3.1 Objetivos
El objetivo de esta familia es describir el STOE de una forma narrativa.
Se requiere la evaluación de la introducción del SPP para demostrar que el SPP está identificado correctamente y que la
visión general y la especificación de la organización del dominio del STOE son consistentes entre sí. Las introducciones
para los dominios de seguridad concretos se definen en C.2.10 introducción del dominio de seguridad.
C.2.3.2 ASP_INT.1 Introducción del SPP
C.2.3.2.1 Elementos de acción del desarrollador/integrador
ASP_INT.1.1D El desarrollador/integrador debe proveer una introducción del SPP.
ISO/IEC TR 19791:2010 - 98 -
C.2.3.2.2 Contenido y presentación de elementos de evidencia
ASP_INT.1.1C La introducción del SPP debe contener una referencia del SPP, una visión general del STOE y
una especificación de la organización del dominio.
ASP_INT.1.2C La referencia del SPP debe identificar de forma única al SPP.
ASP_INT.1.3C La visión general del STOE debe resumir el uso y las principales características del STOE.
ASP_INT.1.4C La visión general del STOE debe identificar el tipo de STOE.
ASP_INT.1.5C La visión general del STOE debe identificar las relaciones e interfaces con cualquier sistema
operacional requeridas por el STOE.
ASP_INT.1.6C La especificación de la organización del dominio debe describir la organización de dominios de

seguridad obligatorios y su identificación.
ASP_INT.1.7C Para cada dominio, la especificación de la organización del dominio debe describir cualquier
servicio de seguridad ofrecido por ese dominio que esté disponible para otros dominios y cualquier propiedad de
seguridad del dominio que haya de aplicarse a otros dominios.
C.2.3.2.3 Elementos de acción del evaluador
ASP_INT.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
contenido y presentación de las evidencias.
ASP_INT.1.2E El evaluador debe confirmar que la visión general del STOE y la especificación de la organi-
zación del dominio son consistentes entre sí.
C.2.4 Declaraciones de conformidad (ASP_CCL)
C.2.4.1 Objetivos
El objetivo de esta familia es determinar la validez de distintas declaraciones de conformidad: la declaración de
conformidad de la Norma ISO/IEC 15408, la declaración de conformidad del SPP, la declaración de conformidad de los
PP y la declaración del paquete de requisitos. La declaración de conformidad de la Norma ISO/IEC 15408 describe la
versión de la Norma ISO/IEC 15408 a la que el SPP y el STOE declaran conformidad, la declaración de conformidad de
los PP (si existe) describe cómo los PP identificados, la declaración del paquete (si existe) describe cómo el SPP declara
conformidad con el paquete indicado, mientras que la declaración del SPP identifica los SPP (si existen) con los que el
SPP declara conformidad. Determinar la validez de la declaración del SPP, la declaración de los PP y la declaración del
paquete conlleva determinar si todos los SPP, PP y paquetes declarados están claramente identificados, si el SPP
contiene íntegramente estos SPP, PP y paquetes y si todos los requisitos de seguridad derivados de estos SPP, PP y
paquetes se han completado correctamente. Las declaraciones de conformidad para un dominio concreto de seguridad
se definen en C.2.11 declaración de conformidad del dominio de seguridad.
C.2.4.2 Notas de aplicación

Si un SPP declara conformidad con un PP, debe demostrar como parte de los requisitos de consistencia de seguridad
que define OSF que satisfacen las suposiciones acerca del entorno operacional en la sección de definición del problema
de seguridad del PP.
C.2.4.3 ASP_CCL.1 Declaraciones de conformidad
Dependencias: ASP_INT.1 Introducción del SPP
ASP_SPD.1 Definición del problema de seguridad
- 99 - ISO/IEC TR 19791:2010
ASP_OBJ.1 Objetivos de seguridad
ASP_ECD.1 Definición de componentes extendidos
ASP_REQ.1 Requisitos de seguridad declarados
ASP_CCL1.1D El desarrollador/integrador debe proveer una declaración de conformidad.
ASP_CCL1.2D El desarrollador/integrador debe proveer una justificación de las declaraciones de conformidad.
ASP_CCL1.1C La declaración de conformidad debe contener una declaración de conformidad con los criterios
que identifique la versión de la Norma ISO/IEC 19791 con la que declare conformidad el SPP.
ASP_CCL1.2C La declaración de conformidad de criterios debe describir la conformidad funcional del SPP con
la Norma ISO/IEC 19791 ya sea con la Norma ISO/IEC 19791 funcionalmente conforme o con la Norma
ISO/IEC 19791 funcionalmente extendida.
ASP_CCL1.3C La declaración de conformidad de criterios debe describir la conformidad de garantía del SPP
con la Norma ISO/IEC 19791 ya sea con la Norma ISO/IEC 19791 conforme en garantía o con la Norma
ISO/IEC 19791 extendida en garantía.
ASP_CCL1.4C La declaración de conformidad de criterios debe ser coherente con la definición de los
componentes extendidos.
ASP_CCL1.5C La declaración de conformidad debe identificar todos los SPP, PP y paquetes de requisitos de
seguridad a los cuales declara conformidad el SPP.
ASP_CCL1.6C La declaración de conformidad debe describir cualquier conformidad del SPP con un paquete ya
sea como paquete-conforme o paquete-aumentado.
ASP_CCL1.7C La justificación de la declaración de conformidad debe demostrar que el tipo de STOE es

consistente con el tipo de STOE en los SPP y PP para los que se ha declarado conformidad.
ASP_CCL1.8C La justificación de la declaración de conformidad debe demostrar que la declaración de la

definición del problema de seguridad sea consistente con las declaraciones de la definición del problema de
seguridad en los SPP y PP para los que se ha declarado conformidad.
ASP_CCL1.9C La justificación de la declaración de conformidad debe demostrar que la declaración de objetivos

sea consistente con las declaraciones de objetivos en los SPP y PP para los que se ha declarado conformidad.
ASP_CCL1.10C La justificación de la declaración de conformidad debe demostrar que la declaración de

requisitos de seguridad sea consistente con las declaraciones de requisitos de seguridad en los SPP y PP para los
que se ha declarado conformidad.
ASP_CCL.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ISO/IEC TR 19791:2010 - 100 -
C.2.5 Definición del problema de seguridad (ASP_SPD)
C.2.5.1 Objetivos
Está parte del SPP define los problemas de seguridad de los que debe ocuparse el STOE. Estos problemas de seguridad
son aplicables al STOE en general. Los problemas de seguridad de un dominio de seguridad concreto están definidos en
C.2.12 definición del problema del dominio de seguridad. Se requiere la evaluación de la definición del problema de
seguridad para demostrar que están claramente definidos los problemas de seguridad de los que el STOE pretende
ocuparse.
C.2.5.2 ASP_SPD.1 Definición del problema de seguridad
ASP_SPD.1.1D El desarrollador/integrador debe proveer una definición del problema de seguridad.
ASP_SPD.1.1C La definición del problema de seguridad debe describir todos los riesgos aplicables al STOE.
Cada riesgo debe ser categorizado como aceptable o inaceptable.
ASP_SPD.1.2 Deben describirse todos los riesgos inaceptables en términos de amenazas y vulnerabilidades. Debe
escribirse cada amenaza en términos de un agente de amenaza, un activo y una acción adversa.
ASP_SPD.1.3C La definición del problema de seguridad debe describir las OSP.
C.2.5.3 Elementos de acción del evaluador
ASP_SPD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.6 Objetivos de seguridad (ASP_OBJ)
C.2.6.1 Objetivos
Los objetivos de seguridad son una declaración concisa de la respuesta prevista al problema de seguridad definido
mediante la familia ASP_SPD. Los objetivos de seguridad definidos en esta parte son aplicables al STOE en general.
Los objetivos de seguridad para un dominio concreto de seguridad se definen en C.2.13 objetivos de seguridad del
dominio de seguridad. Se requiere la evaluación de los objetivos de seguridad para demostrar que los objetivos de
seguridad funcional se ocupan adecuada y completamente de la definición del problema de seguridad, que la división de
este problema entre el STOE y los sistemas operacionales externos está claramente definida y que los objetivos de
seguridad de garantía están documentados y explicados.

La justificación de los objetivos de seguridad debe explicar por qué se han elegido los objetivos de seguridad de ga-
rantía. Puede ser como resultado de un análisis de riesgos, pero puede asimismo depender de la practicidad y alcanzabi-
lidad e incluso puede ser arbitraria. Las razones deberían declararse, pero estas razones no necesitan estar justificadas.
C.2.6.3 ASP_OBJ.1 Objetivos de seguridad

Dependencias: ASP_SPD.1 Definición del problema de seguridad.
- 101 - ISO/IEC TR 19791:2010
ASP_OBJ.1.1D El desarrollador/integrador debe proveer una declaración de los objetivos de seguridad.
ASP_OBJ.1.2D El desarrollador/integrador debe proveer una justificación de los objetivos de seguridad.
ASP_OBJ.1.1C La declaración de objetivos de seguridad debe describir los objetivos de seguridad funcional
para el STOE.
ASP_OBJ.1.2C La declaración de objetivos de seguridad debe describir cualesquiera objetivos de seguridad

funcional que cumplan los sistemas operacionales externos.
ASP_OBJ.1.3C La declaración de objetivos de seguridad debe describir los objetivos de seguridad de garantía
para el STOE.
ASP_OBJ.1.4C La justificación de la declaración de objetivos de seguridad debe trazar cada objetivo de

seguridad funcional para el STOE remontándose a los riesgos contrarrestados por ese objetivo de seguridad y las
OSP aplicadas por ese objetivo de seguridad.
ASP_OBJ.1.5C La justificación de la declaración de objetivos de seguridad debe trazar cada objetivo de

seguridad funcional para sistemas operacionales externos remontándose a los riesgos contrarrestados por ese
objetivo de seguridad y las OSP aplicadas por ese objetivo de seguridad.
ASP_OBJ.1.6C La justificación de la declaración de objetivos de seguridad debe demostrar que los objetivos de
seguridad funcional contrarrestan todos los riesgos inaceptables.
ASP_OBJ.1.7C La justificación de la declaración de objetivos de seguridad debe demostrar que los objetivos de
seguridad funcional obligan a todas las OSP.
ASP_OBJ.1.8C La justificación de la declaración de objetivos de seguridad debe explicar por qué se escogieron
los objetivos de seguridad de garantía para el STOE.
ASP_OBJ.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.7 Definición de componentes extendidos (ASP_ECD)
C.2.7.1 Objetivos
Los requisitos de seguridad extendidos son requisitos que no se basan en componente de la Norma ISO/IEC 15408 o
este informe técnico, sino que se basan en componentes extendidos: componentes definidos por el autor del SPP. La
evaluación de los componentes extendidos es necesaria para determinar que son claros y no son ambiguos y que son
necesarios, es decir, que no podrían expresarse claramente utilizando los componentes existentes en la Norma
ISO/IEC 15408 o este informe técnico.
C.2.7.2 ASP_ECD.1 Definición de componentes extendidos
ASP_ECD.1.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ISO/IEC TR 19791:2010 - 102 -
ASP_ECD.1.2D El desarrollador/integrador debe proveer una definición de los componentes extendidos.
ASP_ECD.1.1C La declaración de requisitos de seguridad debe identificar todos los requisitos extendidos de
seguridad.
ASP_ECD.1.2C La definición de los componentes extendidos debe definir un componente extendido para cada
requisito extendido de seguridad.
ASP_ECD.1.3C La definición de los componentes extendidos debe describir cómo se relaciona cada componente
extendido con los componentes, familias y clases existentes en la Norma ISO/IEC 15408 o este informe técnico.
ASP_ECD.1.4C La definición de los componentes extendidos debe utilizar los componentes, familias, clases y
metodología existentes en la Norma ISO/IEC 15408 o este informe técnico como modelo para su presentación.
ASP_ECD.1.5C Los componentes extendidos deben consistir en elementos medibles y objetivos cuyo
cumplimiento o incumplimiento puede demostrarse.
ASP_ECD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASP_ECD.1.2E El evaluador debe confirmar que ningún componente extendido puede expresarse claramente
utilizando los componentes existentes.
C.2.8 Requisitos de seguridad (ASP_REQ)
C.2.8.1 Objetivos
Las SSF forman una descripción clara y no ambigua del comportamiento de seguridad esperado del STOE. Las SSA
forman una descripción clara y no ambigua de las actividades esperadas que serán asumidas para obtener garantías en el
STOE. Los requisitos de seguridad definidos en esta parte son aplicables al STOE en su conjunto. Los requisitos de
seguridad para un dominio concreto de seguridad están definidos en C.2.14 requisitos de seguridad del dominio de
seguridad. Se requiere la evaluación de los requisitos de seguridad para asegurarse de que están claros y no son
ambiguos.
C.2.8.2 Descripción de componentes

Esta familia tiene dos componentes. Los componentes en esta familia se clasifican por si se declaran como tales o si
derivan de objetivos de seguridad para el STOE.
C.2.8.3 ASP_REQ.1 Requisitos de seguridad declarados
Dependencias: ASP_ECD.1 Definición de componentes extendidos.
ASP_REQ.1.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ASP_REQ.1.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad.
ASP_REQ.1.1C La declaración de requisitos de seguridad debe describir las SSF y las SSA.
- 103 - ISO/IEC TR 19791:2010
ASP_REQ.1.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades
externas y otros términos que se usen en las SSF y las SSA.
ASP_REQ.1.3C La declaración de requisitos de seguridad debe identificar todas las operaciones sobre los
requisitos de seguridad.
ASP_REQ.1.4C Todas las operaciones deben llevarse a cabo correctamente.
ASP_REQ.1.5C Cada dependencia entre requisitos de seguridad debe o bien satisfacerse o la justificación de
requisitos de seguridad debe justificar que la dependencia no sea satisfecha.
ASP_REQ.1.6C La declaración de requisitos de seguridad debe ser coherente internamente.
ASP_REQ.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.8.4 ASP_REQ.2 Requisitos de seguridad derivados
Jerárquica a: ASP-REQ.1 Requisitos de seguridad declarados
Dependencias: ASP_OBJ.1 Objetivos de seguridad
ASP_REQ.2.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ASP_REQ.2.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad.
ASP_REQ.2.1C La declaración de requisitos de seguridad debe describir las SSF y las SSA.
ASP_REQ.2.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades externas y
otros términos que se usen en las SSF y las SSA.
ASP_REQ.2.3C La declaración de requisitos de seguridad debe identificar todas las operaciones sobre los requisitos de
seguridad.
ASP_REQ.2.4C Todas las operaciones deben llevarse a cabo correctamente.
ASP_REQ.2.5C Cada dependencia entre requisitos de seguridad debe o bien satisfacerse o la justificación de requisitos
de seguridad debe justificar que la dependencia no sea satisfecha.
ASP_REQ.2.6C La justificación de requisitos de seguridad debe trazar cada SSF remontándose a los objetivos
de seguridad del STOE.
ASP_REQ.2.7C La justificación de requisitos de seguridad debe demostrar que las SSF cumplen con todos los
objetivos de seguridad funcional para el STOE que no cumplan los sistemas externos o los dominios individuales.
ASP_REQ.2.8C La justificación de requisitos de seguridad debe trazar cada SSA remontándose a los objetivos
ISO/IEC TR 19791:2010 - 104 -
ASP_REQ.2.9C La justificación de requisitos de seguridad debe demostrar que las SSA cumplen con todos los
objetivos de seguridad de garantía para el STOE que no cumplan los dominios individuales.
ASP_REQ.2.10C La declaración de requisitos de seguridad debe ser coherente internamente.
ASP_REQ.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
y presentación de las evidencias.
C.2.9 Dominios de seguridad del SPP

Cada dominio de seguridad del SPP define los problemas, objetivos y requisitos de seguridad para el contenido y
presentación de evidencias.
Las siguientes secciones definen las familias que se usan para definir los dominios de seguridad dentro del SPP.
C.2.10 Introducción del dominio de seguridad (ASP_DMI)
C.2.10.1 Objetivos
El objetivo de esta familia es describir un dominio de seguridad de una manera narrativa con tres niveles de abstracción:
referencia del dominio de seguridad, visión general del dominio de seguridad y descripción del dominio de seguridad.
C.2.10.2 ASP_DMI.1 Introducción del dominio de seguridad
Dependencias: ASP_INT.1 Introducción del SPP.
ASP_DMI.1.1D El desarrollador/integrador debe proveer una introducción del dominio de seguridad.
ASP_DMI.1.1C La introducción del dominio de seguridad debe contener un referencia del dominio de
seguridad, una visión general del dominio de seguridad y una descripción del dominio de seguridad.
ASP_DMI.1.2C La referencia del dominio de seguridad debe identificar unívocamente al dominio de seguridad.
ASP_DMI.1.3C La visión general del dominio de seguridad debe resumir el uso y principales características de
seguridad del dominio de seguridad.
ASP_DMI.1.4C La descripción del dominio de seguridad debe describir los subsistemas o componentes incluidos.
ASP_DMI.1.5C La descripción del dominio de seguridad debe describir las relaciones e interfaces con otros
dominios.
ASP_DMI.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASP_DMI.1.2E El evaluador debe confirmar que la referencia del dominio de seguridad, la visión general del
dominio de seguridad y la descripción del dominio de seguridad son consistentes entre sí y con la introducción
del SPP.
- 105 - ISO/IEC TR 19791:2010
C.2.11 Declaraciones de conformidad del dominio de seguridad (ASP_DMC)
C.2.11.1 Objetivos
Esta parte del SPP define las declaraciones de conformidad únicas para un dominio de seguridad.
C.2.11.2 ASP_DMC.1 Declaraciones de conformidad del dominio de seguridad
Dependencias: ASP_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASP_DMO.1 Objetivos de seguridad del dominio de seguridad
ASP_DMR.1 Requisitos de seguridad del dominio declarado
ASP_DMC.1.1D El desarrollador/integrador debe proveer una declaración de conformidad del dominio.
ASP_DMC.1.2D El desarrollador/integrador debe proveer una justificación de la declaración de conformidad

del dominio.
ASP_DMC.1.1C La declaración de conformidad del dominio debe identificar todos los SPP, PP y paquetes de
requisitos de seguridad a los que el dominio declare conformidad.
ASP_DMC.1.2C La declaración de conformidad del dominio debe describir cualquier conformidad del dominio
con un paquete ya sea como paquete-conforme o paquete-aumentado.
ASP_DMC.1.3C La justificación de las declaraciones de conformidad del dominio debe demostrar que el tipo de
STOE es consistente con el tipo de STOE en los SPP y PP cuya conformidad se declara.
ASP_DMC.1.4C La justificación de las declaraciones de conformidad del dominio debe demostrar que la
declaración de la definición del problema de seguridad del dominio es consistente con la declaración de la
definición del problema de seguridad en los SPP y PP cuya conformidad se declara.
declaración de objetivos de seguridad del dominio es consistente con la declaración objetivos en los SPP y PP
cuya conformidad se declara.
declaración de requisitos de seguridad del dominio es consistente con la declaración requisitos de seguridad en
los SPP, PP y paquetes cuya conformidad se declara.
ASP_DMC.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.12 Definición del problema de seguridad del dominio de seguridad (ASP_DMP)
C.2.12.1 Objetivos
Esta parte del SPP define los problemas de seguridad únicos para un dominio de seguridad.
ISO/IEC TR 19791:2010 - 106 -
C.2.12.2 ASP_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASP_DMP.1.1D El desarrollador/integrador debe proveer una definición del problema de seguridad del
dominio.
ASP_DMP.1.1C La definición del problema de seguridad del dominio debe describir todos los riesgos únicos
aplicables al dominio. Cada riesgo debe categorizarse como aceptable o inaceptable.
ASP_DMP.1.2C Todos los riesgos inaceptables deben describirse en términos de amenazas y vulnerabilidades.
Cada amenaza debe describirse en términos de una agente de amenaza, un activo y una acción adversa.
ASP_DMP.1.3C La definición del problema de seguridad del dominio debe describir las OSP aplicables al
dominio.
ASP_DMP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.13 Objetivos de seguridad del dominio de seguridad (ASP_DMO)
C.2.13.1 Objetivos
Esta parte del SPP especifica una declaración concisa de la respuesta propuesta a los problemas de seguridad únicos
definidos a través de la familia ASP_DMP.
C.2.13.2 ASP_DMO.1 Objetivos de seguridad del dominio de seguridad
Dependencias: ASP_INT.1 Introducción del SPP
ASP_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASP_DMO.1.1D El desarrollador/integrador debe proveer una declaración de objetivos de seguridad del

dominio.
ASP_DMO.1.2D El desarrollador/integrador debe proveer una justificación de los objetivos de seguridad del
dominio.
ASP_DMO.1.1C La declaración de objetivos de seguridad del dominio debe describir los objetivos de seguridad
funcional únicos para el dominio.
ASP_DMO.1.2C La declaración de objetivos de seguridad del dominio debe describir cualesquiera objetivos de
seguridad funcional para el dominio que cumplan otros dominios o sistemas operacionales externos.
ASP_DMO.1.3C La declaración de objetivos de seguridad del dominio debe describir los objetivos de seguridad
de garantía únicos para el dominio.
- 107 - ISO/IEC TR 19791:2010
ASP_DMO.1.4C La declaración de objetivos de seguridad del dominio debe describir cualesquiera objetivos de
seguridad funcional para el dominio que se apliquen o estén disponibles para otros dominios.
ASP_DMO.1.5C La justificación de los objetivos de seguridad del dominio debe trazar cualquier objetivo de
seguridad funcional único para el dominio remontándose a los riesgos contrarrestados por ese objetivo de
seguridad y OSP aplicadas por ese objetivo de seguridad.
ASP_DMO.1.6C La justificación de los objetivos de seguridad del dominio debe trazar cualquier objetivo de
seguridad funcional único para otros dominios remontándose a los riesgos contrarrestados por ese objetivo de
ASP_DMO.1.7C La justificación de los objetivos de seguridad del dominio debe demostrar que los objetivos de
seguridad funcional contrarrestan todos los riesgos únicos inaceptables para el dominio.
ASP_DMO.1.8C La justificación de los objetivos de seguridad del dominio debe demostrar que los objetivos de
seguridad funcional aplican todas las OSP únicas para el dominio.
ASP_DMO.1.9C La justificación de los objetivos de seguridad del dominio debe explicar por qué se han elegido
los objetivos de seguridad de garantía único para el dominio.
ASP_DMO.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASP_DMO.1.2E El evaluador debe confirmar que la declaración de los objetivos de seguridad del dominio sea
consistente con la especificación de la organización del dominio.
C.2.14 Requisitos de seguridad del dominio de seguridad (ASP_DMR)
C.2.14.1 Objetivos
Esta parte del SPP ofrece una descripción clara y no ambigua del comportamiento de seguridad único esperado del
dominio de seguridad.

derivan de objetivos de seguridad para el dominio.
C.2.14.3 ASP_DMR.1 Requisitos de seguridad del dominio declarado
Dependencias: ASP_ECD.1 Definición de componentes extendidos.
ASP_DMR.1.1D El desarrollador/integrador debe proveer una declaración de los requisitos de seguridad del
dominio.
ASP_DMR.1.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad del
dominio.
ASP_DMR.1.1C La declaración de requisitos de seguridad del dominio debe describir las SSF y SSA únicas
aplicables al dominio.
ISO/IEC TR 19791:2010 - 108 -
ASP_DMR.1.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades
externas y otros términos que se usen en la SSF única y las SSA aplicables al dominio.
ASP_DMR.1.3C La declaración de requisitos de seguridad del dominio debe identificar todas las operaciones en
los requisitos de seguridad.
ASP_DMR.1.4C Todas las operaciones deben llevarse a cabo correctamente.
ASP_DMR.1.5C Cada dependencia entre requisitos de seguridad del dominio debe o bien ser satisfecha o bien la
justificación de los requisitos de seguridad del dominio debe justificar la dependencia no satisfecha.
ASP_DMR.1.6C La declaración de requisitos de seguridad del dominio debe ser consistente internamente.
ASP_DMP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.2.14.4 ASP_DMR.2 Requisitos de seguridad del dominio derivado
Jerárquica a: ASP_DMR.1 Requisitos de seguridad del dominio declarado
Dependencias: ASP_REQ.2 Requisitos de seguridad derivados
ASP_DMO.1 Objetivos de seguridad del dominio de seguridad
ASP_DMR.2.1D El desarrollador/integrador debe proveer una declaración de los requisitos de seguridad del dominio.
ASP_DMR.2.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad del dominio.
ASP_DMR.2.1C La declaración de requisitos de seguridad del dominio debe describir las SSF y SSA únicas aplicables
al dominio.
ASP_DMR.2.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades externas y
otros términos que se usen en la SSF única y las SSA aplicables al dominio.
ASP_DMR.2.3C La declaración de requisitos de seguridad del dominio debe identificar todas las operaciones en los
ASP_DMR.2.4C Todas las operaciones deben llevarse a cabo correctamente.
ASP_DMR.2.5C Cada dependencia entre requisitos de seguridad del dominio debe o bien ser satisfecha o bien la
ASP_DMR.2.6C La justificación de los requisitos de seguridad del dominio debe trazar cada SSF del dominio
remontándose a los objetivos de seguridad funcional del dominio.
ASP_DMR.2.7C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSF del
dominio cumplen con todos los objetivos únicos de seguridad funcional para el dominio no cumplidos por otros
dominios o sistemas externos.
- 109 - ISO/IEC TR 19791:2010
ASP_DMR.2.8C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSF del
dominio cumplen con todos los objetivos de seguridad funcional para el STOE que están identificados en la
justificación de los requisitos de seguridad para todo el STOE como cumplidos por los dominios individuales.
ASP_DMR.2.9C La justificación de los requisitos de seguridad del dominio debe trazar cada SSF del dominio
remontándose a los objetivos de seguridad de garantía del dominio.
ASP_DMR.2.10C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSA del
dominio cumplen con todos los objetivos únicos de seguridad de garantía para el dominio.
ASP_DMR.2.11C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSA del
dominio cumplen con todos los objetivos de seguridad de garantía para el STOE que están identificados en la
ASP_DMR.2.12C La declaración de requisitos de seguridad del dominio debe ser consistente internamente.
ASP_DMR.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3 Clase ASS: Evaluación del Objetivo de Seguridad del Sistema
C.3.1 Introducción
Este capítulo ofrece criterios de garantía para la evaluación de Objetivos de Seguridad del Sistema (SST). Se requiere la
evaluación del SST para demostrar que un SST es sólido y coherente internamente y, si el SST deriva de uno o más SPP
o paquetes, que el SST es una instanciación correcta de dichos SPP y paquetes. Estas propiedades son necesarias para
que el SST sea apropiado para el uso como base para la posterior evaluación del STOE.
Las familias dentro de esta clase son las siguientes:
a) ASS_INT: Introducción del SST;
b) ASS_CCL: Declaraciones de conformidad;
c) ASS_SPD: Definición del problema de seguridad;
d) ASS_OBJ: Objetivos de seguridad;
e) ASS_ECD: Definición de componentes extendidos;
f) ASS_REQ: Requisitos de seguridad;
g) ASS_TSS: Especificación resumen del STOE;
h) ASS_DMI: Introducción del dominio de seguridad;
i) ASS_DMC: Declaraciones de conformidad del dominio de seguridad;
j) ASS_DMP: Definición del problema de seguridad del dominio de seguridad;
k) ASS_DMO: Objetivos de seguridad del dominio de seguridad;
l) ASS_DMR: Requisitos de seguridad del dominio de seguridad;
m) ASS_DMS: Especificación resumen del dominio de seguridad.
ISO/IEC TR 19791:2010 - 110 -
C.3.2 Parte común de SST

Las siguientes especificaciones aplican a todo el SST. La especificaciones para dominios concretos debería describirse
utilizando las familias de dominios (ver C.3.10).
C.3.3 Introducción del SST (ASS_INT)
C.3.3.1 Objetivos
El objetivo de esta familia es describir el STOE de una forma narrativa en cuatro niveles de abstracción: referencia del
SST/STOE, visión general del STOE, descripción del STOE y organización del dominio.
Se requiere la evaluación de la introducción del SST para demostrar que el SST y el STOE están identificados correc-
tamente, que el STOE está descrito correctamente en cuatro niveles de abstracción y que estas cuatro descripciones son
consistentes entre sí. Las introducciones para los dominios de seguridad concretos se definen en C.3.11 introducción del
dominio de seguridad.
C.3.3.2 ASS_INT.1 Introducción del SST
ASS_INT.1.1D El desarrollador/integrador debe proveer una introducción del SST.
ASS_INT.1.1C La introducción del SST debe contener una referencia del SST, una visión general del STOE y
una especificación de la organización del dominio.
ASS_INT.1.2C La referencia del SST debe identificar de forma única al SST.
ASS_INT.1.3C La referencia del STOE debe identificar al STOE.
ASS_INT.1.4C La visión general del STOE debe resumir el uso y las principales características de seguridad del
STOE.
ASS_INT.1.5C La visión general del STOE debe identificar el tipo de STOE.
ASS_INT.1.6C La visión general del STOE debe identificar las relaciones e interfaces con cualquier sistema
operacional requeridas por el STOE.
ASS_INT.1.7C La descripción del STOE debe describir el ámbito físico del STOE.
ASS_INT.1.8C La descripción del STOE debe describir el ámbito lógico del STOE.
ASS_INT.1.9C La descripción del STOE debe identificar los entornos de desarrollo para el STOE, incluyendo
cualesquiera características únicas de los entornos de desarrollo de cada dominio de seguridad.
ASS_INT.1.10C La especificación de la organización del dominio debe describir la organización de dominios de

seguridad construidos y la identificación y ámbito físico de cada dominio de seguridad.
ASS_INT.1.11C Para cada dominio, la especificación de la organización del dominio debe identificar cualquier
servicio de seguridad ofrecido por ese dominio que esté disponible para otros dominios y cualquier propiedad de
seguridad del dominio que haya de aplicarse a otros dominios.
- 111 - ISO/IEC TR 19791:2010
ASS_INT.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASS_INT.1.2E El evaluador debe confirmar que la referencia del STOE, la visión general del STOE, la
descripción del STOE y la especificación de la organización del dominio son consistentes entre sí.
C.3.4 Declaraciones de conformidad (ASP_CCL)
C.3.4.1 Objetivos
El objetivo de esta familia es determinar la validez de distintas declaraciones de conformidad: la declaración de confor-
midad de la Norma ISO/IEC 15408, la declaración del SPP, la declaración de conformidad de los PP, la declaración de
conformidad de los ST y la declaración del paquete de requisitos. La declaración de conformidad de la Norma
ISO/IEC 15408 describe la versión de la Norma ISO/IEC 15408 a la que el SPP y el STOE declaran conformidad, la
declaración de conformidad de los PP, ST o el paquete (si existen) describen cómo el SST declara conformidad con los
PP ST o paquete declarados, mientras que la declaración del SPP identifica los SPP (si existen) con los que el SST
declara conformidad. Determinar la validez de la declaración del SPP, la declaración de los PP, la declaración de los ST
y la declaración del paquete conlleva determinar si todos los SPP, PP, ST y paquetes declarados están claramente
identificados, si el SST contiene íntegramente estos SPP, PP, ST y paquetes y si todos los requisitos de seguridad
derivados de estos SPP, PP, ST y paquetes se han completado correctamente. Las declaraciones de conformidad para un
dominio concreto de seguridad se definen en C.3.12 declaración de conformidad del dominio de seguridad.

Si un SST declara conformidad con un PP o ST, debe demostrar que parte de los requisitos de consistencia de seguridad
que define OSF que satisfacen las suposiciones acerca del entorno operacional en la sección de definición del problema
de seguridad del PP/ST.
C.3.4.3 ASS_CCL.1 Declaraciones de conformidad
Dependencias: ASS_INT.1 Introducción del SST
ASS_SPD.1 Definición del problema de seguridad
ASS_OBJ.1 Objetivos de seguridad
ASS_ECD.1 Definición de componentes extendidos
ASS_REQ.1 Requisitos de seguridad declarados
ASS_CCL1.1D El desarrollador/integrador debe proveer una declaración de conformidad.
ASS_CCL1.2D El desarrollador/integrador debe proveer una justificación de las declaraciones de conformidad.
ASS_CCL1.1C La declaración de conformidad debe contener una declaración de conformidad con los criterios
que identifique la versión de la Norma ISO/IEC 19791 con la que declare conformidad el SST y el STOE.
ASS_CCL1.2C La declaración de conformidad de criterios debe describir la conformidad funcional del SST con
la Norma ISO/IEC 19791 ya sea con la Norma ISO/IEC 19791 funcionalmente conforme o con la Norma
ISO/IEC 19791 funcionalmente extendida.
ISO/IEC TR 19791:2010 - 112 -
ASS_CCL1.3C La declaración de conformidad de criterios debe describir la conformidad de garantía del SST
con la Norma ISO/IEC 19791 ya sea con la Norma ISO/IEC 19791 conforme en garantía o con la Norma
ISO/IEC 19791 extendida en garantía.
ASS_CCL1.4C La declaración de conformidad de criterios debe ser coherente con la definición de los
componentes extendidos.
ASS_CCL1.5C La declaración de conformidad debe identificar todos los SPP, PP, ST y paquetes de requisitos de
seguridad a los cuales declara conformidad el SST.
ASS_CCL1.6C La declaración de conformidad debe describir cualquier conformidad del SST con un paquete ya
sea como paquete-conforme o paquete-aumentado.
ASS_CCL1.7C La justificación de la declaración de conformidad debe demostrar que el tipo de STOE es

consistente con el tipo de STOE en los SPP, PP y ST para los que se ha declarado conformidad.
ASS_CCL1.8C La justificación de la declaración de conformidad debe demostrar que la declaración de la

definición del problema de seguridad sea consistente con las declaraciones de la definición del problema de
seguridad en los SPP, PP y ST para los que se ha declarado conformidad.
ASS_CCL1.9C La justificación de la declaración de conformidad debe demostrar que la declaración de objetivos

sea consistente con las declaraciones de objetivos en los SPP, PP y ST para los que se ha declarado conformidad.
ASS_CCL1.10C La justificación de la declaración de conformidad debe demostrar que la declaración de

requisitos de seguridad sea consistente con las declaraciones de requisitos de seguridad en los SPP, PP y ST para
los que se ha declarado conformidad.
ASS_CCL.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.5 Definición del problema de seguridad (ASS_SPD)
C.3.5.1 Objetivos
Está parte del SST define los problemas de seguridad de los que debe ocuparse el STOE. Estos problemas de seguridad
son aplicables al STOE en general. Los problemas de seguridad de un dominio de seguridad concreto están definidos en
C.3.13 definición del problema de seguridad del dominio de seguridad. Se requiere la evaluación de la definición del
problema de seguridad para demostrar que están claramente definidos los problemas de seguridad de los que el STOE
pretende ocuparse.
C.3.5.2 ASS_SPD.1 Definición del problema de seguridad
ASS_SPD.1.1D El desarrollador/integrador debe proveer una definición del problema de seguridad.
ASS_SPD.1.1C La definición del problema de seguridad debe describir todos los riesgos aplicables al STOE.
Cada riesgo debe ser categorizado como aceptable o inaceptable.
- 113 - ISO/IEC TR 19791:2010
ASS_SPD.1.2 Deben describirse todos los riesgos inaceptables en términos de amenazas y vulnerabilidades. Debe
describirse cada amenaza en términos de un agente de amenaza, un activo y una acción adversa.
ASS_SPD.1.3C La definición del problema de seguridad debe describir las OSP.
B.3.5.2.3 Elementos de acción del evaluador
ASS_SPD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.6 Objetivos de seguridad (ASS_OBJ)
C.3.6.1 Objetivos
Los objetivos de seguridad son una declaración concisa de la respuesta prevista al problema de seguridad definido
mediante la familia ASS_SPD. Los objetivos de seguridad definidos en esta parte son aplicables al STOE en general.
Los objetivos de seguridad para un dominio concreto de seguridad se definen en C.3.14 objetivos de seguridad del
dominio de seguridad. Se requiere la evaluación de los objetivos de seguridad para demostrar que los objetivos de
seguridad funcional se ocupan adecuada y completamente de la definición del problema de seguridad, que la división de
este problema entre el STOE y los sistemas operacionales externos está claramente definida y que los objetivos de
seguridad de garantía están documentados y explicados.

La justificación de los objetivos de seguridad debe explicar por qué se han elegido los objetivos de seguridad de
garantía. Puede ser como resultado de un análisis de riesgos, pero puede asimismo depender de la practicidad y alcanza-
bilidad e incluso puede ser arbitraria. Las razones deberían declararse, pero estas razones no necesitan estar justificadas.
C.3.6.3 ASP_OBJ.1 Objetivos de seguridad
Dependencias: ASS_SPD.1 Definición del problema de seguridad
ASS_OBJ.1.1D El desarrollador/integrador debe proveer una declaración de los objetivos de seguridad.
ASS_OBJ.1.2D El desarrollador/integrador debe proveer una justificación de los objetivos de seguridad.
ASS_OBJ.1.1C La declaración de objetivos de seguridad debe describir los objetivos de seguridad funcional
para el STOE.
ASS_OBJ.1.2C La declaración de objetivos de seguridad debe describir cualesquiera objetivos de seguridad

funcional que cumplan los sistemas operacionales externos.
ASS_OBJ.1.3C La declaración de objetivos de seguridad debe describir los objetivos de seguridad de garantía
para el STOE.
ASS_OBJ.1.4C La justificación de la declaración de objetivos de seguridad debe trazar cada objetivo de

seguridad funcional para el STOE remontándose a los riesgos contrarrestados por ese objetivo de seguridad y las
OSP aplicadas por ese objetivo de seguridad.
ASS_OBJ.1.5C La justificación de la declaración de objetivos de seguridad debe trazar cada objetivo de

seguridad funcional para sistemas operacionales externos remontándose a los riesgos contrarrestados por ese
objetivo de seguridad y las OSP aplicadas por ese objetivo de seguridad.
ISO/IEC TR 19791:2010 - 114 -
ASS_OBJ.1.6C La justificación de la declaración de objetivos de seguridad debe demostrar que los objetivos de
seguridad funcional contrarrestan todos los riesgos inaceptables.
ASS_OBJ.1.7C La justificación de la declaración de objetivos de seguridad debe demostrar que los objetivos de
seguridad funcional obligan a todas las OSP.
ASS_OBJ.1.8C La justificación de la declaración de objetivos de seguridad debe explicar por qué se escogieron
los objetivos de seguridad de garantía para el STOE.
ASS_OBJ.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.7 Definición de componentes extendidos (ASS_ECD)
C.3.7.1 Objetivos
Los requisitos de seguridad extendidos son requisitos que no se basan en componente de la Norma ISO/IEC 15408 o
este informe técnico, sino que se basan en componentes extendidos: componentes definidos por el autor del SST. La
evaluación de los componentes extendidos es necesaria para determinar que son claros y no son ambiguos y que son
necesarios, es decir, que no podrían expresarse claramente utilizando los componentes existentes en la Norma
C.3.7.2 ASS_ECD.1 Definición de componentes extendidos
ASS_ECD.1.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ASS_ECD.1.2D El desarrollador/integrador debe proveer una definición de los componentes extendidos.
ASS_ECD.1.1C La declaración de requisitos de seguridad debe identificar todos los requisitos extendidos de
seguridad.
ASS_ECD.1.2C La definición de los componentes extendidos debe definir un componente extendido para cada
requisito extendido de seguridad.
ASS_ECD.1.3C La definición de los componentes extendidos debe describir cómo se relaciona cada componente
extendido con los componentes, familias y clases existentes en la Norma ISO/IEC 15408 o este informe técnico.
ASS_ECD.1.4C La definición de los componentes extendidos debe utilizar los componentes, familias, clases y
metodología existentes en la Norma ISO/IEC 15408 o este informe técnico como modelo para su presentación.
ASS_ECD.1.5C Los componentes extendidos deben consistir en elementos medibles y objetivos cuyo
cumplimiento o incumplimiento puede demostrarse.
ASS_ECD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
- 115 - ISO/IEC TR 19791:2010
ASS_ECD.1.2E El evaluador debe confirmar que ningún componente extendido puede expresarse claramente
C.3.8 Requisitos de seguridad (ASS_REQ)
C.3.8.1 Objetivos
Las SSF forman una descripción clara y no ambigua del comportamiento de seguridad esperado del STOE. Las SSA
forman una descripción clara y no ambigua de las actividades esperadas que serán asumidas para obtener garantías en el
STOE. Los requisitos de seguridad definidos en esta parte son aplicables al STOE en su conjunto. Los requisitos de se-
guridad para un dominio concreto de seguridad están definidos en C.3.15 requisitos de seguridad del dominio de segu-
ridad. Se requiere la evaluación de los requisitos de seguridad para asegurarse de que están claros y no son ambiguos.

derivan de objetivos de seguridad para el STOE.
C.3.8.3 ASS_REQ.1 Requisitos de seguridad declarados
Dependencias: ASS_ECD.1 Definición de componentes extendidos.
ASS_REQ.1.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ASS_REQ.1.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad.
ASS_REQ.1.1C La declaración de requisitos de seguridad debe describir las SSF y las SSA.
ASS_REQ.1.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades
externas y otros términos que se usen en las SSF y las SSA.
ASS_REQ.1.3C La declaración de requisitos de seguridad debe identificar todas las operaciones sobre los
ASS_REQ.1.4C Todas las operaciones deben llevarse a cabo correctamente.
ASS_REQ.1.5C Cada dependencia entre requisitos de seguridad debe o bien satisfacerse o la justificación de
requisitos de seguridad debe justificar que la dependencia no sea satisfecha.
ASS_REQ.1.6C La declaración de requisitos de seguridad debe ser coherente internamente.
ASS_REQ.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.8.4 ASP_REQ.2 Requisitos de seguridad derivados
Jerárquica a: ASS_REQ.1 Requisitos de seguridad declarados
Dependencias: ASS_OBJ.1 Objetivos de seguridad
ISO/IEC TR 19791:2010 - 116 -
ASS_REQ.2.1D El desarrollador/integrador debe proveer una declaración de requisitos de seguridad.
ASS_REQ.2.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad.
ASS_REQ.2.1C La declaración de requisitos de seguridad debe describir las SSF y las SSA.
ASS_REQ.2.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades externas y
otros términos que se usen en las SSF y las SSA.
ASS_REQ.2.3C La declaración de requisitos de seguridad debe identificar todas las operaciones sobre los requisitos de
seguridad.
ASS_REQ.2.4C Todas las operaciones deben llevarse a cabo correctamente.
ASS_REQ.2.5C Cada dependencia entre requisitos de seguridad debe o bien satisfacerse o la justificación de requisitos
de seguridad debe justificar que la dependencia no sea satisfecha.
ASS_REQ.2.6C La justificación de requisitos de seguridad debe trazar cada SSF remontándose a los objetivos
ASS_REQ.2.7C La justificación de requisitos de seguridad debe demostrar que las SSF cumplen con todos los
objetivos de seguridad funcional para el STOE que no cumplan los sistemas externos o los dominios individuales.
ASS_REQ.2.8C La justificación de requisitos de seguridad debe trazar cada SSA remontándose a los objetivos
ASS_REQ.2.9C La justificación de requisitos de seguridad debe demostrar que las SSA cumplen con todos los
objetivos de seguridad de garantía para el STOE que no cumplan los dominios individuales.
ASS_REQ.2.10C La declaración de requisitos de seguridad debe ser coherente internamente.
ASS_REQ.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
C.3.9 Especificación resumen del STOE (ASS_TSS)
C.3.9.1 Objetivos
El objetivo de la especificación resumen del STOE es ofrecer a los potenciales consumidores del STOE una descripción
de alto nivel de cómo pretende el desarrollador/integrador satisfacer sus SSF y SSA. La especificación resumen del
STOE debería permitir a los evaluadores y consumidores potenciales entender cómo el STOE cumple con sus SSF y
SSA. La especificación resumen del STOE definida en este lugar es aplicable al STOE en su conjunto. La espe-
cificación resumen de seguridad para un dominio concreto de seguridad se define en C.3.16 especificación resumen de
dominio de seguridad del STOE. Es necesaria la evaluación de la especificación resumen del STOE para determinar si
se ha ocupado adecuadamente de todos los SSF y si la especificación resumen del STOE es coherente con otras descrip-
ciones narrativas del STOE.
- 117 - ISO/IEC TR 19791:2010
C.3.9.2 ASS_TSS.1 Especificación resumen del STOE
ASS_REQ.1 Requisitos de seguridad declarados
ASS_TSS.1.1D El desarrollador/integrador debe proveer una especificación resumen del STOE.
ASS_TSS.1.1C La especificación resumen del STOE debe describir cómo cumple el STOE cada SSF.
ASS_TSS.1.2C La especificación resumen del STOE debe describir cómo cumple el STOE cada SSA.
ASS_TSS.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASS_TSS.1.2E El evaluador debe confirmar que la especificación resumen del STOE es coherente con la visión
general del STOE y la descripción del STOE.
C.3.10 Dominios de seguridad del STOE

Cada dominio de seguridad del STOE define los problemas, objetivos y requisitos de seguridad que son únicos para ese
dominio concreto de seguridad.
Las siguientes secciones definen las familias que se usan para definir los dominios de seguridad dentro del STOE.
C.3.11 Introducción del dominio de seguridad (ASS_DMI)
C.3.11.1 Objetivos
El objetivo de esta familia es describir un dominio de seguridad de una manera narrativa con tres niveles de abstracción:
referencia del dominio de seguridad, visión general del dominio de seguridad y descripción del dominio de seguridad.
C.3.11.2 ASS_DMI.1 Introducción del dominio de seguridad
Dependencias: ASS_INT.1 Introducción del SST.
ASS_DMI.1.1D El desarrollador/integrador debe proveer una introducción del dominio de seguridad.
ASS_DMI.1.1C La introducción del dominio de seguridad debe contener un referencia del dominio de seguridad,
una visión general del dominio de seguridad y una descripción del dominio de seguridad.
ASS_DMI.1.2C La referencia del dominio de seguridad debe identificar unívocamente al dominio de seguridad.
ASS_DMI.1.3C La visión general del dominio de seguridad debe resumir el uso y principales características de
seguridad del dominio de seguridad.
ISO/IEC TR 19791:2010 - 118 -
ASS_DMI.1.4C La descripción del dominio de seguridad debe describir los subsistemas o componentes incluidos.
ASS_DMI.1.5C La descripción del dominio de seguridad debe describir las relaciones e interfaces con otros dominios.
ASS_DMI.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASS_DMI.1.2E El evaluador debe confirmar que la referencia del dominio de seguridad, la visión general del
dominio de seguridad y la descripción del dominio de seguridad son consistentes entre sí y con la introducción
del SST.
C.3.12 Declaraciones de conformidad del dominio de seguridad (ASS_DMC)
C.3.12.1 Objetivos
Esta parte del SST define las declaraciones de conformidad únicas para un dominio de seguridad.
C.3.12.2 ASS_DMC.1 Declaraciones de conformidad del dominio de seguridad
Dependencias: ASS_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASS_DMO.1 Objetivos de seguridad del dominio de seguridad
ASS_DMR.1 Requisitos de seguridad del dominio declarado
ASS_DMC.1.1D El desarrollador/integrador debe proveer una declaración de conformidad del dominio.
ASS_DMC.1.2D El desarrollador/integrador debe proveer una justificación de la declaración de conformidad

del dominio.
ASS_DMC.1.1C La declaración de conformidad del dominio debe identificar todos los SPP, PP, ST y paquetes
de requisitos de seguridad a los que el dominio declare conformidad.
ASP_DMC.1.2C La declaración de conformidad del dominio debe describir cualquier conformidad del dominio
con un paquete ya sea como paquete-conforme o paquete-aumentado.
ASS_DMC.1.3C La justificación de las declaraciones de conformidad del dominio debe demostrar que el tipo de
STOE es consistente con el tipo de STOE en los SPP, PP y ST cuya conformidad se declara.
ASS_DMC.1.4C La justificación de las declaraciones de conformidad del dominio debe demostrar que la
declaración de la definición del problema de seguridad del dominio es consistente con la declaración de la
definición del problema de seguridad en los SPP, PP y ST cuya conformidad se declara.
declaración de objetivos de seguridad del dominio es consistente con la declaración objetivos en los SPP PP y ST
cuya conformidad se declara.
declaración de requisitos de seguridad del dominio es consistente con la declaración requisitos de seguridad en
los SPP, PP, ST y paquetes cuya conformidad se declara.
- 119 - ISO/IEC TR 19791:2010
ASS_DMC.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.13 Definición del problema de seguridad del dominio de seguridad (ASS_DMP)
C.3.13.1 Objetivos
Esta parte del SST define los problemas de seguridad únicos para un dominio de seguridad.
C.3.13.2 ASS_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASS_DMP.1.1D El desarrollador/integrador debe proveer una definición del problema de seguridad del
dominio.
ASS_DMP.1.1C La definición del problema de seguridad del dominio debe describir todos los riesgos únicos
aplicables al dominio. Cada riesgo debe categorizarse como aceptable o inaceptable.
ASS_DMP.1.2C Todos los riesgos inaceptables deben describirse en términos de amenazas y vulnerabilidades.
Cada amenaza debe describirse en términos de una agente de amenaza, un activo y una acción adversa.
ASS_DMP.1.3C La definición del problema de seguridad del dominio debe describir las OSP aplicables al
dominio.
ASS_DMP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.14 Objetivos de seguridad del dominio de seguridad (ASS_DMO)
C.3.14.1 Objetivos
Esta parte del SST especifica una declaración concisa de la respuesta propuesta a los problemas de seguridad únicos
definidos a través de la familia ASS_DMP.
C.3.14.2 ASS_DMO.1 Objetivos de seguridad del dominio de seguridad
ASS_DMP.1 Definición del problema de seguridad del dominio de seguridad
ASS_DMO.1.1D El desarrollador/integrador debe proveer una declaración de objetivos de seguridad del

dominio.
ASS_DMO.1.2D El desarrollador/integrador debe proveer una justificación de los objetivos de seguridad del
dominio.
ISO/IEC TR 19791:2010 - 120 -
ASS_DMO.1.1C La declaración de objetivos de seguridad del dominio debe describir los objetivos de seguridad
funcional únicos para el dominio.
ASS_DMO.1.2C La declaración de objetivos de seguridad del dominio debe describir cualesquiera objetivos de
seguridad funcional para el dominio que cumplan otros dominios o sistemas operacionales externos.
ASS_DMO.1.3C La declaración de objetivos de seguridad del dominio debe describir los objetivos de seguridad
de garantía únicos para el dominio.
ASS_DMO.1.4C La declaración de objetivos de seguridad del dominio debe describir cualesquiera objetivos de
seguridad funcional para el dominio que se apliquen o estén disponibles para otros dominios.
ASS_DMO.1.5C La justificación de los objetivos de seguridad del dominio debe trazar cualquier objetivo de
seguridad funcional único para el dominio remontándose a los riesgos contrarrestados por ese objetivo de
ASS_DMO.1.6C La justificación de los objetivos de seguridad del dominio debe trazar cualquier objetivo de
seguridad funcional único para otros dominios remontándose a los riesgos contrarrestados por ese objetivo de
ASS_DMO.1.7C La justificación de los objetivos de seguridad del dominio debe demostrar que los objetivos de
seguridad funcional contrarrestan todos los riesgos únicos inaceptables para el dominio.
ASS_DMO.1.8C La justificación de los objetivos de seguridad del dominio debe demostrar que los objetivos de
seguridad funcional aplican todas las OSP únicas para el dominio.
ASS_DMO.1.9C La justificación de los objetivos de seguridad del dominio debe explicar por qué se han elegido
los objetivos de seguridad de garantía único para el dominio.
ASS_DMO.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASS_DMO.1.2E El evaluador debe confirmar que la declaración de los objetivos de seguridad del dominio sea
consistente con la especificación de la organización del dominio.
C.3.15 Requisitos de seguridad del dominio de seguridad (ASS_DMR)
C.3.15.1 Objetivos
Esta parte del SST ofrece una descripción clara y no ambigua del comportamiento de seguridad único esperado del do-
minio de seguridad.

derivan de objetivos de seguridad para el dominio.
C.3.15.3 ASS_DMR.1 Requisitos de seguridad del dominio declarado
Dependencias: ASS_ECD.1 Definición de componentes extendidos.
- 121 - ISO/IEC TR 19791:2010
ASS_DMR.1.1D El desarrollador/integrador debe proveer una declaración de los requisitos de seguridad del
dominio.
ASS_DMR.1.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad del
dominio.
ASS_DMR.1.1C La declaración de requisitos de seguridad del dominio debe describir las SSF y SSA únicas aplicables
al dominio.
ASS_DMR.1.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades externas y
ASS_DMR.1.3C La declaración de requisitos de seguridad del dominio debe identificar todas las operaciones en los
ASS_DMR.1.4C Todas las operaciones deben llevarse a cabo correctamente.
ASS_DMR.1.5C Cada dependencia entre requisitos de seguridad del dominio debe o bien ser satisfecha o bien la
ASS_DMR.1.6C La declaración de requisitos de seguridad del dominio debe ser consistente internamente.
ASS_DMR.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.3.15.4 ASS_DMR.2 Requisitos de seguridad del dominio derivado
Jerárquica a: ASS_DMR.1 Requisitos de seguridad del dominio declarado
Dependencias: ASS_REQ.2 Requisitos de seguridad derivados
ASS_DMO.1 Objetivos de seguridad del dominio de seguridad
ASS_DMR.2.1D El desarrollador/integrador debe proveer una declaración de los requisitos de seguridad del dominio.
ASS_DMR.2.2D El desarrollador/integrador debe proveer una justificación de los requisitos de seguridad del dominio.
ASS_DMR.2.1C La declaración de requisitos de seguridad del dominio debe describir las SSF y SSA únicas aplicables
al dominio.
ASS_DMR.2.2C Deben definirse todos los sujetos, objetos, operaciones, atributos de seguridad, entidades externas y
ASS_DMR.2.3C La declaración de requisitos de seguridad del dominio debe identificar todas las operaciones en los
ISO/IEC TR 19791:2010 - 122 -
ASS_DMR.2.4C Todas las operaciones deben llevarse a cabo correctamente.
ASS_DMR.2.5C Cada dependencia entre requisitos de seguridad del dominio debe o bien ser satisfecha o bien la
ASS_DMR.2.6C La justificación de los requisitos de seguridad del dominio debe trazar cada SSF del dominio
remontándose a los objetivos de seguridad funcional del dominio.
ASS_DMR.2.7C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSF del
dominio cumplen con todos los objetivos únicos de seguridad funcional para el dominio no cumplidos por otros
dominios o sistemas externos.
ASS_DMR.2.8C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSF del
dominio cumplen con todos los objetivos de seguridad funcional para el STOE que están identificados en la
ASS_DMR.2.9C La justificación de los requisitos de seguridad del dominio debe trazar cada SSA del dominio
remontándose a los objetivos de seguridad de garantía del dominio.
ASS_DMR.2.10C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSA del
dominio cumplen con todos los objetivos únicos de seguridad de garantía para el dominio.
ASS_DMR.2.11C La justificación de los requisitos de seguridad del dominio debe demostrar que las SSA del
dominio cumplen con todos los objetivos de seguridad de garantía para el STOE que están identificados en la
ASS_DMR.2.12C La declaración de requisitos de seguridad del dominio debe ser consistente internamente.
ASS_DMR.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
C.3.16 Especificación resumen del dominio de seguridad (ASS_DMS)
C.3.16.1 Objetivos
Esta parte del SST especifica la especificación resumen del dominio de seguridad.
C.3.16.2 ASS_DMS.1 Especificación resumen del dominio de seguridad
Dependencias: ASS_DMI.1 Introducción del dominio de seguridad
ASS_DMR.1 Requisitos de seguridad del dominio declarado
ASS_DMS.1.1D El desarrollador/integrador debe proveer una especificación resumen del dominio.
ASS_DMS.1.1C La especificación resumen del dominio debe describir cómo el STOE cumple con cada SSF del
dominio.
ASS_DMS.1.2C La especificación resumen del dominio debe describir cómo el STOE cumple con cada SSA del
dominio.
- 123 - ISO/IEC TR 19791:2010
ASS_DMS.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASS_DMS.1.2E El evaluador debe confirmar que la especificación resumen del dominio sea consistente con la
visión general y la descripción del dominio.
C.4 Clase AOD: Documento guía del sistema operacional
C.4.1 Introducción
El propósito de esta clase de documento guía del sistema operacional es juzgar la adecuación de la documentación que
describe la integración y el uso operacional del sistema operacional. Dicha documentación incluye la dirigida a
integradores de sistemas operacionales, administradores de confianza y usuarios no administradores cuyas acciones
incorrectas puedan afectar de forma adversa al comportamiento y características de seguridad del sistema operacional,
así como la dirigida a usuarios normales cuyas acciones incorrectas puedan afectar de forma adversa a la capacidad del
sistema operacional de ofrecer las capacidades de protección requeridas para sus propios datos.
Por tanto, la actividad AOD está muy relacionada con los procesos y procedimientos definidos por los requisitos
operacionales de seguridad. La guía de usuario incluye información respecto de los aspectos tecnológicos del sistema
operacional así como de los procesos operacionales y humanos del sistema operacional.
C.4.2 Notas de aplicación

Todos los requisitos de OSF definidos en el SST que apliquen a comportamiento requerido por el personal deberían
describirse en el documento guía del sistema operacional apropiado.
Deberían identificarse el modo de mantenimiento, el modo de usuario único y cualquier modo especial de operación
tras un error o excepción y considerarse sus consecuencias e implicaciones para mantener segura la operación.
La guía del administrador debería identificar la siguiente información:
– las funciones y privilegios que deben controlarse;
– los tipos de controles que se requieren para ellas;
– las razones para dichos controles.
Las advertencias deberían cubrir efectos esperados, posibles efectos colaterales y posibles interacciones con otras fun-
ciones y privilegios.
La guía debería describir la administración del sistema operacional en su conjunto, además de los productos y subsis-
temas individuales. La guía del administrador que no sea solo para programas de administración sino asimismo para
todo el sistema operacional debería documentarse.
C.4.3 Especificación de la configuración del sistema operacional (AOD_OCD)
C.4.3.1 Objetivos
El propósito de la especificación de la configuración del sistema operacional es especificar los parámetros de configu-
ración relevantes de seguridad que soporten la integración de los componentes del sistema operacional y que permitan a
las funciones de seguridad del sistema operacional implantar y aplicar el concepto de operación y políticas asociadas de
seguridad del sistema operacional.
ISO/IEC TR 19791:2010 - 124 -

Esta familia tiene dos componentes. Los componentes en esta familia se clasifican sobre la base de la confirmación de
la descripción en la documentación y la verificación en el sistema operacional.
C.4.3.3 AOD_OCD.1 Especificación de la configuración del sistema operacional
Dependencias: ASD_CON.1 Concepto de seguridad de operaciones
ASD_STD.2 Diseño del componente
AOD_OCD.1.1D El desarrollador/integrador debe proveer una especificación de configuración que defina los
parámetros de configuración relevantes de seguridad que soporten la integración de los componentes de
seguridad y que permitan a las funciones de seguridad del sistema operacional implantar y aplicar el concepto de
operaciones y políticas asociadas.
AOD_OCD.1.1C La especificación de configuración debe describir los parámetros de configuración de seguridad

relativos al STOE incluyendo su entorno operacional.

disponibles para el integrador del sistema o administradores/usuarios equivalentes del STOE con ese rol y
responsabilidad.
AOD_OCD.1.3C La especificación de configuración debe identificar todos los modos de operación posibles del
STOE (incluyendo la operación tras fallo o error operacional), sus consecuencias e implicaciones para mantener
segura la operación.
AOD_OCD.1.4C La especificación de configuración debe contener advertencias acerca de las funciones

accesibles y privilegios de configuración que deberían controlarse en un entorno de procesamiento seguro.
AOD_OCD.1.5C La especificación de configuración debe presentar claramente todas las responsabilidades

relacionadas con la configuración necesarias para garantizar la operación del STOE, incluyendo dependencias
de sistemas operacionales externos.
AOD_OCD.1.6C La especificación de configuración debe ser coherente con el concepto de seguridad de

operaciones.
AOD_OCD.1.7C La especificación de configuración debe demostrar que todos los parámetros de seguridad de
componentes requeridos por el concepto de seguridad de operaciones están implantados por el diseño del
componente.
AOD_OCD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.4.3.4 AOD_OCD.2Verificación de la especificación de la configuración del sistema operacional
Jerárquico a: AOD_OCD.1 Especificación de la configuración del sistema operacional
ASD_STD.2 Diseño del componente
- 125 - ISO/IEC TR 19791:2010
AOD_OCD.2.1D El desarrollador/integrador debe proveer una especificación de configuración que defina los
parámetros de configuración relevantes de seguridad que soporten la integración de los componentes de seguridad y que
permitan a las funciones de seguridad del sistema operacional implantar y aplicar el concepto de operaciones y políticas
asociadas.

relativos al STOE incluyendo su entorno operacional.
AOD_OCD.2.2C La especificación de configuración debe describir los parámetros de configuración de seguridad dis-
ponibles para el integrador del sistema o administradores/usuarios equivalentes del STOE con ese rol y responsabilidad.
AOD_OCD.2.3C La especificación de configuración debe identificar todos los modos de operación posibles del STOE
(incluyendo la operación tras fallo o error operacional), sus consecuencias e implicaciones para mantener segura la ope-
ración.
AOD_OCD.2.4C La especificación de configuración debe contener advertencias acerca de las funciones accesibles y
privilegios de configuración que deberían controlarse en un entorno de procesamiento seguro.
AOD_OCD.2.5C La especificación de configuración debe presentar claramente todas las responsabilidades relaciona-
das con la configuración necesarias para garantizar la operación del STOE, incluyendo dependencias de sistemas
operacionales externos.
AOD_OCD.2.6C La especificación de configuración debe ser coherente con el concepto de seguridad de operaciones.
AOD_OCD.2.7C La especificación de configuración debe demostrar que todos los parámetros de seguridad de
componentes requeridos por el concepto de seguridad de operaciones están implantados por el diseño del componente.
AOD_OCD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
AOD_OCD.2.2E El evaluador debe repetir todos los procedimientos de configuración e instalación para confir-
mar que el STOE puede configurarse y utilizarse con seguridad utilizando solo la especificación de configuración
suministrada.
AOD_OCD.2.3E El evaluador debe realizar pruebas independientes para determinar que un usuario, con una
comprensión de la especificación de configuración, sería razonablemente capaz de determinar si el STOE está
configurado y operando de una forma que sea insegura.
C.4.4 Documentación de guía del usuario del sistema operacional (AOD_OGD)
C.4.4.1 Objetivos
La documentación de guía del usuario del sistema operacional se dirige a su uso por todos los usuarios del STOE, inclu-
yendo usuarios privilegiados como los administradores de sistemas. Políticas de seguridad, procedimientos, reglas, res-
ponsabilidades y otros requisitos de seguridad que estén definidos por requisitos operacionales y se dirijan a su utili-
zación por usuarios deberían describirse en la documentación de guía del usuario. La documentación de guía del usuario
debería describir los controles de seguridad ofrecidos por la SSF y ofrece instrucciones y guías, incluyendo advertencias
para su uso seguro.
ISO/IEC TR 19791:2010 - 126 -
La guía para los usuarios ordinarios ofrece una base para comprender la operación del STOE y una medida de confianza
en que los usuarios no maliciosos, los proveedores de aplicaciones y otros que ejecuten las interfaces externas del STOE
obedecerán a los requerimientos de seguridad y lo usarán como está indicado. La guía del administrador se dirige a
ayudar a los administradores a entender los controles de seguridad que ofrece el STOE, incluyendo tanto controles
técnicos como operacionales que requieran que el administrador realice acciones críticas para la seguridad y aquellas
funciones que ofrezcan información crítica para la seguridad.

Esta familia tiene dos componentes. Los componentes en esta familia se clasifican sobre la base de la confirmación de
la descripción en la documentación y la verificación en el sistema operacional.

El contenido de la documentación de guía del usuario del sistema operacional se reflejará directamente en las políticas,
reglas, responsabilidades, procedimientos y medidas de seguridad operacional que se relacionan con el usuario y se
definen en los controles operacionales. El requisito AOD_OGD.1.4C asegura que cualquier advertencia a los usuarios
de un STOE con respecto al entorno de seguridad del STOE y los objetivos de seguridad descritos en el SPP/SST están
cubiertos apropiadamente en la guía del usuario.
C.4.4.4 AOD_OGD.1 Guía del usuario
Dependencias: ASD_CON.1 Concepto de seguridad de operaciones.
C.4.4.4.1 Elementos de acción de dirección
AOD_OGD.1.1M La dirección debe proveer un guía al usuario.
AOD_OGD.1.1C La guía de usuario debe describir, para cada rol de usuario, las funciones e interfaces dispo-
nibles para ese tipo de usuario del STOE.
AOD_OGD.1.2C La guía de usuario debe describir, para cada rol de usuario, los controles operacionales relacio-
nados con ese tipo de usuario.
AOD_OGD.1.3C La guía de usuario debe describir el uso de funciones de seguridad accesibles al usuario
ofrecidas por el STOE.
AOD_OGD.1.4C La guía de usuario debe describir, para cada rol de usuario, todos los parámetros de seguridad
bajo el control de ese tipo de usuario, indicando valores seguros cuando proceda.
AOD_OGD.1.5C La guía de usuario debe contener advertencias acerca de funciones y privilegios accesibles al
usuario que deberían controlarse en un entorno seguro de procesamiento.
AOD_OGD.1.6C La guía de usuario debe presentar todas las responsabilidades de usuario necesarias para
asegurar la operación del STOE, incluyendo las relacionadas con el comportamiento del usuario durante la
operación del sistema.
AOD_OGD.1.7C La guía de usuario debe ser coherente con el concepto de seguridad de operaciones.
AOD_OGD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
- 127 - ISO/IEC TR 19791:2010
C.4.4.5 AOD_OGD.2 Verificación de la guía del usuario
Jerárquico a: AOD_OGD.1 Guía del usuario
C.4.4.5.1 Elementos de acción de dirección
AOD_OGD.2.1M La dirección debe proveer un guía al usuario.
AOD_OGD.2.1C La guía de usuario debe describir, para cada rol de usuario, las funciones e interfaces disponibles para
ese tipo de usuario del STOE.
AOD_OGD.2.2C La guía de usuario debe describir, para cada rol de usuario, los controles operacionales relacionados
con ese tipo de usuario.
AOD_OGD.2.3C La guía de usuario debe describir el uso de funciones de seguridad accesibles al usuario ofrecidas por
el STOE.
AOD_OGD.2.4C La guía de usuario debe describir, para cada rol de usuario, todos los parámetros de seguridad bajo el
control de ese tipo de usuario, indicando valores seguros cuando proceda.
AOD_OGD.2.5C La guía de usuario debe contener advertencias acerca de funciones y privilegios accesibles al usuario
que deberían controlarse en un entorno seguro de procesamiento.
AOD_OGD.2.6C La guía de usuario debe presentar todas las responsabilidades de usuario necesarias para asegurar la
operación del STOE, incluyendo las relacionadas con el comportamiento del usuario durante la operación del sistema.
AOD_OGD.2.7C La guía de usuario debe ser coherente con el concepto de seguridad de operaciones.
AOD_OGD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
AOD_OGD.2.2E El evaluador debe verificar independientemente la usabilidad de la guía del usuario.
C.4.5 Verificación del documento de guía (AOD_GVR)
C.4.5.1 Objetivos
El objetivo es demostrar que la documentación de guía sigue siendo correcta tras cambios o modificaciones de compo-
nentes del sistema, configuración del sistema o entorno operacional.

Esta familia contiene un componente.
C.4.5.3 AOD_GVR.1 Verificación de la guía
Dependencias: AOD_OCD.1 Especificación de la configuración del sistema operacional
AOD_OGD.1 Guía del usuario
ISO/IEC TR 19791:2010 - 128 -
C.4.5.3.1 Objetivos
En este componente, el objetivo es demostrar que la documentación de guía sigue siendo correcta tras cambios o modi-
ficaciones de componentes del sistema, configuración del sistema o entorno operacional.
C.4.5.3.2 Notas de aplicación

Este componente no solo se ocupa de partes cambiadas o modificadas del la documentación de guía el sistema operacio-
nal, sino asimismo de otras parte que puedan haberse convertido en inválidas.
AOD_GVR.1.1D Después de cambios o modificaciones a los componentes del sistema, la configuración del sistema o
el entorno operacional, el desarrollador/integrador debe realizar un análisis de la verificación de la guía para veri-
ficar que toda la documentación de configuración y guía del sistema operacional sigue siendo correcta y coherente.
AOD_GVR.1.1C El análisis de verificación de guía debe mostrar que la especificación de la configuración no se

ve afectada por los cambios o modificaciones o que se ha actualizado correctamente para reflejar los cambios o
modificaciones.
AOD_GVR.1.2C El análisis de verificación de guía debe mostrar que la guía del usuario no se ve afectada por los
cambios o modificaciones o que se ha actualizado correctamente para reflejar los cambios o modificaciones.
AOD_GVR.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.5 Clase ASD: Documento de arquitectura, diseño y configuración del sistema operacional
C.5.1 Introducción
La clase de garantía ASD es equivalente a la clase ADV en la Norma ISO/IEC 15408-3. Sin embargo, la información de
desarrollo e integración necesaria y apropiada para los sistemas operacionales es suficientemente distinta de la definida
en la clase ADV como para requerir que se defina una nueva clase.
El propósito de esta clase es evaluar las decisiones de arquitectura, diseño y configuración que se hayan realizado para
garantizar que son suficientes y completas en términos de cumplir los requisitos funcionales indicados para el sistema
operacional. Es a través de la documentación de arquitectura, diseño y configuración como se ofrece esa visión de estas
decisiones. El propósito secundario de esta sección es verificar que la arquitectura, diseño y configuración del sistema
operacional refleja los requisitos de seguridad asignados a los distintos subsistemas y componentes del sistema
operacional. Para hacerlo, deben definirse las propiedades de seguridad de todas las interfaces internas, junto con
aquellas propiedades de seguridad (como la separación de los espacios de direcciones) que se aplican mediante un
elemento de la arquitectura en otros.
C.5.2 Descripción de la arquitectura (ASD_SAD)
C.5.2.1 Objetivos
El propósito de la descripción de la arquitectura del sistema operacional es presentar una visión general del sistema ope-
racional en términos de estructura (subsistemas, interfaces con sistemas operacionales externos), interacciones (interfa-
ces, interconexiones, flujos de datos y control) y propósito. Esta información soporta entender y llevar a cabo varios
aspectos de la evaluación del sistema operacional: la asignación de garantías a porciones del sistema operacional, el
concepto de seguridad de operaciones del sistema operacional, la estrategia, planes y procedimientos de pruebas del
sistema operacional. Debería definir:
- 129 - ISO/IEC TR 19791:2010
a) los subsistemas que comprende el sistema operacional;
b) las interfaces internas y externas a los subsistemas y la funcionalidad ofrecida a través de las interfaces identifi-
cadas;
c) las interconexiones entre los subsistemas y el flujo de información entre subsistemas a través de las interconexiones;
d) los sistemas operacionales externos con los que interactúa el sistema operacional y las relaciones entre el sistema
operacional y estos sistemas operacionales externos;
e) las interconexiones a sistemas operacionales externos y el flujo de información entre el sistema operacional y los
sistemas operacionales externos a través de las interconexiones.

La descripción de la arquitectura es un documento general que describe la arquitectura del sistema, no un documento
específico de seguridad. De los aspectos de seguridad del diseño de la arquitectura se ocupa ASD_CON.

C.5.2.4 ASD_SAD.1 Descripción de la arquitectura
ASD_SAD.1.1D El desarrollador/integrador debe proveer una descripción de la arquitectura del sistema.
ASD_SAD.1.1C La descripción de la arquitectura debe identificar el STOE en términos de sus subsistemas y las
interfaces e interconexiones entre los subsistemas.
ASD_SAD.1.2C La descripción de la arquitectura debe identificar los sistemas operacionales externos que
interactúan con el STOE y las interfaces e interconexiones entre el STOE y los sistemas operacionales externos.
ASD_SAD.1.3C La descripción de la arquitectura debe describir el propósito y funciones de los subsistemas

identificados, interconexiones e interfaces del STOE.
ASD_SAD.1.4C La descripción de la arquitectura debe describir el propósito de las interconexiones e interfaces

identificadas del STOE a los sistemas operacionales externos y debe describir los servicios que ofrecen y son
ofrecidos por los sistemas operacionales externos.
ASD_SAD.1.5C La descripción de la arquitectura debe ser coherente internamente.
ASD_SAD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ISO/IEC TR 19791:2010 - 130 -
C.5.3 Concepto de seguridad de las operaciones (ASD_CON)
C.5.3.1 Objetivos
El propósito del concepto de seguridad de las operaciones es describir la políticas, propiedades y características de
seguridad del sistema operacional tal y como se ofrecen y aplican en apoyo del la descripción del negocio o la misión
operacional. Esto permitirá el análisis de las evidencias de arquitectura y diseño para confirmar que el STOE aplica las
políticas y propiedades necesarias.

Generalmente se usan distintas técnicas para robustecer la efectividad de los controles técnicos y operacionales
implementando la SSF. En el caso de controles técnicos, los mecanismos dominantes necesarios se implantan a menudo
a nivel de hardware (por ejemplo, mecanismos de gestión de la memoria). En el caso de controles operacionales, se
usan a menudo mecanismos procedimentales en toda la organización (por ejemplo, separación de tareas).

C.5.3.4 ASD_CON.1 Concepto de seguridad de las operaciones
Dependencias: ASD_SAD.1 Descripción de la arquitectura.
ASD_CON.1.1D El desarrollador/integrador debe proveer una documentación del concepto de seguridad de las
operaciones que cubra toda la SSF.
ASD_CON.1.1C La documentación del concepto de seguridad de las operaciones debe tener un nivel de detalle
coherente con la descripción de interfaces e interconexiones ofrecidas en la descripción de la arquitectura.
ASD_CON.1.2C La documentación del concepto de seguridad de las operaciones debe describir todas las
políticas, propiedades y características de seguridad del STOE.
ASD_CON.1.3C La documentación del concepto de seguridad de las operaciones debe cubrir todos los modos de
operación del STOE (por ejemplo, incluyendo modos de respaldo o degradados de operación).
ASD_CON.1.4C La documentación del concepto de seguridad de las operaciones debe describir cualesquiera
opciones obligatorias de configuración de seguridad para productos componentes.
ASD_CON.1.5C La documentación del concepto de seguridad de las operaciones debe describir los dominios de
seguridad del STOE.
ASD_CON.1.6C La documentación del concepto de seguridad de las operaciones debe describir las propiedades
que los dominios de seguridad aplican a otros dominios, incluyendo medidas para garantizar el funcionamiento
correcto de la SSF.
ASD_CON.1.7C La documentación del concepto de seguridad de las operaciones debe demostrar que el proceso
de inicialización de la SSF impide eludir o interferir en el establecimiento de la funcionalidad de aplicación del
SFR.
ASD_CON.1.8C La documentación del concepto de seguridad de las operaciones debe demostrar que la SSF está
protegida frente a interferencias.
- 131 - ISO/IEC TR 19791:2010
ASD_CON.1.9C La documentación del concepto de seguridad de las operaciones debe demostrar que la SSF
impide eludir la funcionalidad de aplicación del SFR.
ASD_CON.1.10C La documentación del concepto de seguridad de las operaciones debe demostrar que la
información fluye entre dominios del STOE y entre el STOE y los sistemas operacionales externos, no eludiendo
o interfiriendo con la funcionalidad de aplicación del SFR.
ASD_CON.1.11C La documentación del concepto de seguridad de las operaciones debe ser coherente
internamente.
ASD_CON.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASD_CON.1.2E El evaluador debe determinar que la documentación del concepto de seguridad de las
operaciones es coherente con la descripción de la arquitectura.
C.5.4 Especificación funcional de la interfaz (ASD_IFS)
C.5.4.1 Objetivos
El propósito de la especificación funcional de la interfaz es ofrecer una descripción de las funciones de seguridad del
sistema operacional accesibles a las interfaces visibles, y sus propiedades de seguridad.

C.5.4.3 ASD_IFS.1 Especificación funcional de la interfase
Dependencias: ASD_SAD.1 Descripción de la arquitectura.
ASD_IFS.1.1D El desarrollador/integrador debe proveer una especificación funcional de la interfase.
ASD_IFS.1.1C La especificación funcional de la interfaz debe tener identificar y describir todas las interfaces
visibles del STOE, las propiedades de seguridad de dichas interfaces y las funciones de seguridad accesibles a
través de dichas interfaces.
ASD_IFS.1.2C La especificación funcional de la interfaz debe ser coherente internamente.
ASD_IFS.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASD_IFS.1.2E El evaluador debe determinar que la especificación funcional de la interfaz es coherente con la
descripción de la arquitectura.
ISO/IEC TR 19791:2010 - 132 -
C.5.5 Diseño del STOE (ASD_STD)
C.5.5.1 Objetivos
El propósito de la familia de diseño del STOE es ofrecer una descripción del diseño del sistema y su SSF, indicando
cómo se asigna esa funcionalidad a distintas partes del sistema.

Esta familia contiene tres componentes. Los componentes se descomponen basándose en el creciente detalle ofrecido en
las representaciones de la SSF, del diseño del subsistema a la representación de la implantación.
C.5.5.3 ASD_STD.1 Diseño del subsistema
Dependencias: ASD_SAD.1 Descripción de la arquitectura
ASD_IFS.1 Especificación funcional de la interfaz
C.5.5.3.1 Objetivos
En este componente, el sistema TOE se describe a nivel de subsistemas. El objetivo de este componente es asegurar que
el diseño del sistema especifica:
a) los subsistemas;
b) la asignación de funcionalidad de seguridad a los subsistemas;
c) las propiedades de seguridad de cada subsistema;
d) las interfaces con cada subsistema y la funcionalidad ofrecida a través de cada interfaz;
e) los componentes con los que se construye cada subsistema.

A este nivel del análisis del STOE, el evaluador solo examinará la asignación de la SFF a nivel de subsistema mediante
el examen del diseño del subsistema. No es necesario que el diseño del subsistema sea un solo documento: solo es
necesario que la información de diseño ofrecida cumpla con todos los requisitos de contenidos y presentación
identificados más adelante y que la información relevante pueda identificarse inmediatamente por parte del evaluador
dentro de la documentación ofrecida.
ASD_STD.1.1D El desarrollador/integrador debe proveer un diseño del subsistema.
ASD_STD.1.2D El desarrollador/integrador debe proveer un mapa del diseño del subsistema a la descripción de
la arquitectura.
ASD_STD.1.1C El diseño del subsistema debe describir la funcionalidad de seguridad ofrecida por cada
subsistema.
ASD_STD.1.2C El diseño del subsistema debe identificar todo el hardware, firmware y software requeridos por
la funcionalidad de seguridad asignada al subsistema.
ASD_STD.1.3C El diseño del subsistema debe identificar las interfaces de cada subsistema.
- 133 - ISO/IEC TR 19791:2010
ASD_STD.1.4C El diseño del subsistema debe identificar las propiedades de seguridad de cada subsistema.
ASD_STD.1.5C El diseño del subsistema debe describir las interfaces de cada subsistema en términos de su
propósito y método de uso de los efectos, excepciones y mensajes de error.
ASD_STD.1.6C El diseño del subsistema debe identificar los componentes que componen cada subsistema.
ASD_STD.1.7C El diseño del subsistema debe ser coherente internamente.
ASD_STD.1.8C El diseño del subsistema debe ser una instanciación completa de la funcionalidad de seguridad
del STOE, incluyendo la funcionalidad específica del dominio.
ASD_STD.1.9C El mapeo del diseño del subsistema a la descripción de la arquitectura debe demostrar que todos
los elementos de la descripción de la arquitectura están presentes en el diseño del subsistema.
ASD_STD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
ASD_STD.1.2E El evaluador debe determinar que el diseño del subsistema es coherente con la descripción de la
arquitectura y la especificación funcional de la interfaz.
C.5.5.4 ASD_STD.2 Diseño del componente
C.5.5.4.1 Objetivos
En este componente, el STOE se describe tanto a nivel de subsistemas como de componentes. El nivel de diseño de
componente adicional especifica:
a) propósito y funciones de cada componente del sistema operacional;
b) la asignación de funcionalidad de seguridad a cada componente;
c) las propiedades de seguridad de cada componente;
d) las interfaces de subsistema ofrecidas para cada componente;
e) la funcionalidad ofrecida a través de las interfaces identificadas con el componente;
f) cómo se proveen la funcionalidad y propiedades de seguridad de cada componente.
A este nivel del análisis del STOE, el evaluador examina la asignación de la SFF tanto a nivel de subsistema como de
componente. No es necesario que el diseño del subsistema o los diseños de los componentes sean un solo documento:
solo es necesario que la información de diseño ofrecida cumpla con todos los requisitos de contenidos y presentación
identificados más adelante y que la información relevante pueda identificarse inmediatamente por parte del evaluador
dentro de la documentación ofrecida. De hecho, cuando un sistema esté compuesto por un solo componente, el mismo
documento podría satisfacer ambos requisitos de diseño de subsistema y componente.
ISO/IEC TR 19791:2010 - 134 -
El diseño del componente ofrece una descripción detallada del funcionamiento interno de la SSF y todos los compo-
nentes identificados en el diseño del componente deberían por tanto contener funcionalidades de aplicación de la SSF.
Para los componentes software, el diseño del componente puede tener un nivel de detalle más alto que los módulos de
código individual. Si se requiere la verificación del diseño al nivel de módulos de código, los componentes apropiados
están definidos en la Norma ISO/IEC 15408.
ASD_STD.2.2D El desarrollador/integrador debe proveer un mapa del diseño del subsistema a la descripción de la
arquitectura.
ASD_STD.2.3D El desarrollador/integrador debe proveer un mapa del diseño del componente al diseño del
subsistema.
ASD_STD.2.4D El desarrollador/integrador debe proveer un análisis de coherencia del la especificación resumen

del STOE.
ASD_STD.2.1C El diseño del subsistema debe describir la funcionalidad de seguridad ofrecida por cada subsistema.
ASD_STD.2.2C El diseño del subsistema debe identificar todo el hardware, firmware y software requeridos por la
funcionalidad de seguridad asignada al subsistema.
ASD_STD.2.5C El diseño del subsistema debe describir las interfaces de cada subsistema en términos de su propósito y
método de uso de los efectos, excepciones y mensajes de error.
ASD_STD.2.8C El diseño del subsistema debe ser una instanciación completa de la funcionalidad de seguridad del
STOE, incluyendo la funcionalidad específica del dominio.
ASD_STD.2.9C El mapeo del diseño del subsistema a la descripción de la arquitectura debe demostrar que todos los
elementos de la descripción de la arquitectura están presentes en el diseño del subsistema.
ASD_STD.2.10C El diseño del componente debe describir el propósito y funciones de los componentes de cada
subsistema.
ASD_STD.2.11C El diseño del componente debe definir las interrelaciones entre los componentes de cada
subsistema.
ASD_STD.2.12C El diseño del componente debe identificar las interfaces con el subsistema del STOE que
cumple cada componente.
ASD_STD.2.13C El diseño del componente debe describir las interfaces con el subsistema del STOE que cumple
cada componente en términos de su propósito y método de uso.
- 135 - ISO/IEC TR 19791:2010
ASD_STD.2.14C El diseño del componente debe describir la funcionalidad de seguridad ofrecida por cada
componente.
ASD_STD.2.15C El diseño del componente debe identificar las propiedades de seguridad de cada componente.
ASD_STD.2.16C El diseño del componente debe describir cómo se ofrecen la funcionalidad y propiedades de
seguridad de cada componente.
ASD_STD.2.17C El diseño del componente para cada subsistema debe ser coherente internamente.
ASD_STD.2.18C El diseño del componente para cada subsistema debe ofrecer una instanciación completa de la
funcionalidad de seguridad de cada subsistema, incluyendo la funcionalidad específica del dominio.
ASD_STD.2.19C El mapeo diseño del componente al diseño del subsistema debe demostrar que todos los
elementos del diseño del subsistema están presentes en el diseño del componente.
ASD_STD.2.20C El análisis de coherencia de la especificación resumen del STOE debe demostrar que el diseño
del componente es coherente con la descripción de la implantación de la SSF en la especificación resumen del
STOE en el SST y en cualesquiera especificaciones resumen del dominio del STOE.
ASD_STD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASD_STD.2.3E El evaluador debe determinar que el diseño del componente es coherente con el diseño del
subsistema y la especificación funcional de la interfase.
C.5.5.5 ASD_STD.3 Representación del diseño más implantación
C.5.5.5.1 Objetivos
En este componente, la información de diseño del STOE se suplementa con el examen de la representación de la
implantación de los componentes críticos, especialmente aquéllos en los que se implanta la SSF por configuración del
componente, en lugar de cómo una propiedad inherente del componente.

No se contempla que se ofrezca la representación de la implantación (por ejemplo, el código fuente) para todos los
componentes del sistema operacional, sólo de aquéllos que configuren otras porciones del sistema operacional o
implanten funcionalidades críticas de seguridad que soporten otros componentes. Los programas de integración o de
rutinas de salida desarrollados solamente para el sistema operacional pueden ser el objetivo para esta familia.
ASD_STD.3.2D El desarrollador/integrador debe proveer una representación de la implantación del diseño del
componente para [asignación: lista de componentes].
ISO/IEC TR 19791:2010 - 136 -
ASD_STD.3.3D El desarrollador/integrador debe proveer un mapa del diseño del subsistema a la descripción de la
arquitectura.
ASD_STD.3.4D El desarrollador/integrador debe proveer un mapa del diseño del componente al diseño del subsistema.
ASD_STD.3.5D El desarrollador/integrador debe proveer un análisis de coherencia del la especificación resumen del
STOE.
ASD_STD.3.1C El diseño del subsistema debe describir la funcionalidad de seguridad ofrecida por cada subsistema.
ASD_STD.3.2C El diseño del subsistema debe identificar todo el hardware, firmware y software requeridos por la
funcionalidad de seguridad asignada al subsistema.
ASD_STD.3.5C El diseño del subsistema debe describir las interfaces de cada subsistema en términos de su propósito y
método de uso de los efectos, excepciones y mensajes de error.
ASD_STD.3.8C El diseño del subsistema debe ser una instanciación completa de la funcionalidad de seguridad del
STOE, incluyendo la funcionalidad específica del dominio.
ASD_STD.3.9C El mapeo del diseño del subsistema a la descripción de la arquitectura debe demostrar que todos los
elementos de la descripción de la arquitectura están presentes en el diseño del subsistema.
ASD_STD.3.10C El diseño del componente debe describir el propósito y funciones de los componentes de cada
subsistema.
ASD_STD.3.11C El diseño del componente debe definir las interrelaciones entre los componentes de cada subsistema.
ASD_STD.3.12C El diseño del componente debe identificar las interfaces con el subsistema del STOE que cumple cada
componente.
ASD_STD.3.13C El diseño del componente debe describir las interfaces con el subsistema del STOE que cumple cada
componente en términos de su propósito y método de uso.
ASD_STD.3.14C El diseño del componente debe describir la funcionalidad de seguridad ofrecida por cada componente.
ASD_STD.3.15C El diseño del componente debe identificar las propiedades de seguridad de cada componente.
ASD_STD.3.16C El diseño del componente debe describir cómo se ofrecen la funcionalidad y propiedades de
seguridad de cada componente.
ASD_STD.3.17C El diseño del componente para cada subsistema debe ser coherente internamente.
ASD_STD.3.18C El diseño del componente para cada subsistema debe ofrecer una instanciación completa de la
funcionalidad de seguridad de cada subsistema, incluyendo la funcionalidad específica del dominio.
- 137 - ISO/IEC TR 19791:2010
ASD_STD.3.19C El mapeo diseño del componente al diseño del subsistema debe demostrar que todos los elementos
del diseño del subsistema están presentes en el diseño del componente.
ASD_STD.3.20C El análisis de coherencia de la especificación resumen del STOE debe demostrar que el diseño del
componente es coherente con la descripción de la implantación de la SSF en la especificación resumen del STOE en el
SST y en cualesquiera especificaciones resumen del dominio del STOE.
ASD_STD.3.21C La representación de implantación debe ser una implantación completa del diseño del
componente para los componentes identificados, incluyendo toda funcionalidad y propiedades de seguridad
asignadas a esos componentes.
ASD_STD.3.22C La representación de implantación debe establecer la funcionalidad de seguridad ofrecida por

los componentes identificados en términos de sus requisitos concretos de configuración.
ASD_STD.3.23C La representación de implantación debe ser coherente internamente.
ASD_STD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASD_STD.2.3E El evaluador debe determinar que el diseño del componente es coherente con el diseño del subsistema
y la especificación funcional de la interfase.
C.5.6 Verificación de requisitos (ASD_RVR)
C.5.6.1 Objetivos
El objetivo es demostrar que los requisitos de seguridad definidos en el SST siguen siendo válidos tras cambios o modi-
ficaciones en los riesgos o el entorno del sistema.

C.5.6.3 ASD_RVR.1 Verificación de requisitos
Dependencias: Sin dependencias.
C.5.6.3.1 Objetivos
En este componente, el objetivo es demostrar que el SST sigue siendo válido tras cambios o modificaciones en los
riesgos de los que se ocupa el sistema operacional u otras limitaciones en su evaluación.

Este componente requiere que se realice una nueva evaluación del riesgo por parte del propietario del sistema o que se
revise la evaluación existente. El modelo o forma de esta evaluación del riesgo queda fuera del ámbito de este informe
técnico.
Este componente también es aplicable cuando se requieran cambios en las SSF o SSA por otras razones (por ejemplo,
porque se ha descubierto que determinados controles o garantías son ineficaces o irrealizables en la práctica).
ISO/IEC TR 19791:2010 - 138 -
ASD_RVR.1.1D El desarrollador/integrador debe realizar un análisis de verificación de requisitos para

confirmar que las SSF y SSA en el SST siguen siendo aplicables y apropiadas.
ASD_RVR.1.1C El análisis de verificación de requisitos debe mostrar que la definición del problema de
seguridad dentro del SST no se ve afectada por cambios o modificaciones a los riesgos o que ha sido
correctamente actualizada para reflejar los cambios o modificaciones.
ASD_RVR.1.2C El análisis de verificación de requisitos debe mostrar que los objetivos de seguridad funcional
dentro del SST no se vean afectados por cambios o modificaciones a la definición del problema de seguridad o
que han sido correctamente actualizados para reflejar los cambios o modificaciones.
ASD_RVR.1.3C El análisis de verificación de requisitos debe mostrar que los objetivos de seguridad de garantía
declarados dentro del SST siguen siendo válidos o que han sido correctamente actualizados para reflejar los
cambios o modificaciones requeridos.
ASD_RVR.1.4C El análisis de verificación de requisitos debe mostrar que las SSF y SSA reflejan correctamente
los objetivos actuales de seguridad establecidos dentro del SST.
ASD_RVR.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.5.7 Verificación del documento de diseño (ASD_DVR)
C.5.7.1 Objetivos
El objetivo es demostrar que la documentación del diseño de seguridad sigue siendo válida tras cambios o modifica-
ciones de los componentes del sistema.

C.5.7.3 ASD_DVR.1 Verificación del diseño
ASD_STD.1 Diseño del subsistema
C.5.7.3.1 Objetivos
En este componente, el objetivo es demostrar que la documentación de seguridad sigue siendo correcta tras cambios o
modificaciones en los componentes del sistema.

Este componente no solo se ocupa de las partes cambiadas o modificadas de la documentación del diseño del sistema
operacional, sino asimismo a otras partes que pueden haberse convertido en inválidas.
- 139 - ISO/IEC TR 19791:2010
La verificación del diseño utilizando ASD_DVR puede realizarse cuando solo estén disponibles la documentación de la
descripción de la arquitectura, la especificación funcional de la interfaz, el diseño del subsistema y el concepto de
seguridad de operaciones. Sin embargo “toda la documentación del diseño del STOE” incluye el diseño del componente
y la representación de la implantación si se incluyen componentes de nivel más alto de la ASD_STD dentro del SST.
ASD_DVR.1.1D Después de cambios o modificaciones a los componentes del sistema, la configuración del
sistema o el entorno operacional, el desarrollador/integrador debe realizar un análisis de verificación del diseño
para verificar que toda la documentación de diseño del STOE sigue siendo correcta y coherente.
ASD_DVR.1.1C Para cada documento de diseño, el análisis de verificación del diseño debe mostrar que el
documento no se ve afectado por los cambios o modificaciones o que ha sido correctamente actualizado para
reflejar los cambios o modificaciones.
ASD_DVR.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.6 Clase AOC: Gestión de la configuración del sistema operacional
C.6.1 Introducción
El objetivo de la clase de Gestión de la configuración (CM, Configuration Management) es ofrecer garantías de que el
sistema instalado en el entorno operacional está configurado correctamente, y de que si el sistema se modifica poste-
riormente, los cambios relevantes están bajo en control de la CM.
Cuando se incorporen productos COTS dentro del sistema operacional, puede usarse esta clase para determinar si los
productos cumplen con sus requisitos de garantía de seguridad y están correctamente configurados de acuerdo con las
instrucciones del vendedor del producto.
C.6.2 Configuración del sistema operacional (AOC_OBM)
C.6.2.1 Objetivos
Esta familia define las opciones de configuración del sistema operacional que deben establecerse durante la instalación
y requiere un sistema de gestión de la configuración para informar sobre el sistema operacional creado utilizando esas
opciones. La familia también requiere que las modificaciones al sistema operacional después de la instalación sean
seguidas y controladas, de forma que el sistema pueda reinstalarse correctamente.

Esta familia contiene dos componentes. Los componentes en esta familia se descomponen basándose en la confirmación
de la descripción en la documentación y la verificación independiente del evaluador.
C.6.2.3 AOC_OBM.1 Configuración del sistema operacional
AOC_OBM.1.1D El desarrollador/integrador debe ofrecer un plan de CM.
ISO/IEC TR 19791:2010 - 140 -
AOC_OBM.1.2D El desarrollador/integrador debe usar un sistema de CM para generar un STOE instalado de

acuerdo con el plan de CM.
AOC_OBM.1.1C El plan de CM debe describir cómo se configura el STOE durante la instalación.
AOC_OBM.1.2C El plan de CM debe describir cómo se monitorizan y controlan los cambios al STOE instalado.
AOC_OBM.1.3C El sistema de CM debe informar de las opciones de configuración del STOE instalado.
AOC_OBM.1.4C El sistema de CM debe identificar de forma única el STOE instalado, cada cambio asociado y
su estado de evaluación.
ASD_OBM.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.6.2.4 AOC_OBM.2 Verificación de la configuración del sistema operacional
Jerárquico a: AOC_OBM.1 Configuración del sistema operacional
AOC_OBM.1.1D El desarrollador/integrador debe ofrecer un plan de CM.
AOC_OBM.1.2D El desarrollador/integrador debe usar un sistema de CM para generar un STOE instalado de acuerdo
con el plan de CM.
AOC_OBM.1.1C El plan de CM debe describir cómo se configura el STOE durante la instalación.
AOC_OBM.1.2C El plan de CM debe describir cómo se monitorizan y controlan los cambios al STOE instalado.
AOC_OBM.1.3C El sistema de CM debe informar de las opciones de configuración del STOE instalado.
AOC_OBM.1.4C El sistema de CM debe identificar de forma única el STOE instalado, cada cambio asociado y su
estado de evaluación.
ASD_OBM.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASD_OBM.1.1E El evaluador debe verificar de forma independiente el STOE instalado frente al plan y sistema
de CM.
- 141 - ISO/IEC TR 19791:2010
C.6.3 Productos del componente evaluados (AOC_ECP)
C.6.3.1 Objetivos
Esta familia define los requisitos de garantía y configuración para componentes del sistema operacional que se constru-
yen a partir de productos evaluados. Al crear un sistema operacional a partir de componentes de producto, hay una
necesidad de especificar la garantía requerida a aspectos de las actividades de desarrollo e integración. Cuando se usan
productos COTS evaluados, normalmente no habrá actividades de desarrollo realizadas específicamente para el sistema
operacional. Por tanto la garantía de obtenerse de la evaluación y certificación del producto, como una disponibilidad de
un certificado formal que declare que se ha certificado un producto, por ejemplo, a EAL4, tal y como se define en la
Norma ISO/IEC 15408.
Los requisitos de garantía pueden especificarse como paquetes de garantía, como un EAL, como parte de un PP o SPP o
definirse explícitamente.
Cuando los componentes de producto tienen parámetros específicos para una operación segura, estos parámetros deben
establecerse correctamente.

C.6.3.3 AOC_ECP.1 Productos del componente evaluados
Dependencias: AOC_OBM.1 Configuración del sistema operacional.
AOC_ECP.1.1D El desarrollador/integrador debe definir los paquetes de garantía requeridos para productos
componentes o dominios de seguridad que contengan dichos productos.
AOC_ECP.1.2D El desarrollador/integrador debe ofrecer procedimientos preparatorios para cada producto

evaluado.
AOC_ECP.1.3D El desarrollador/integrador debe ofrecer un informe independiente de certificación o Informe

Técnico de Evaluación para cada producto evaluado.
AOC_ECP.1.1C El plan de CM debe demostrar que los parámetros operacionales para cada producto evaluado
están configurados de acuerdo con sus procedimientos preparatorios.
AOC_ECP.1.2C Para cada producto evaluado, el informe independiente de certificación o Informe Técnico de
Evaluación debe demostrar que se satisfacen los paquetes de garantía requeridos.
ASD_ECP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.6.3.4 AOC_ECP.2 Verificación de los productos del componente evaluado
Jerárquico a: AOC_ECP.1 Productos del componente evaluado
Dependencias: AOC_OBM.1 Configuración del sistema operacional
ISO/IEC TR 19791:2010 - 142 -
AOC_ECP.1.1D El desarrollador/integrador debe definir los paquetes de garantía requeridos para productos
AOC_ECP.1.2D El desarrollador/integrador debe ofrecer procedimientos preparatorios para cada producto evaluado.
AOC_ECP.1.3D El desarrollador/integrador debe ofrecer un informe independiente de certificación o Informe Técnico

de Evaluación para cada producto evaluado.
AOC_ECP.1.1C El plan de CM debe demostrar que los parámetros operacionales para cada producto evaluado están
configurados de acuerdo con sus procedimientos preparatorios.
AOC_ECP.1.2C Para cada producto evaluado, el informe independiente de certificación o Informe Técnico de
Evaluación debe demostrar que se satisfacen los paquetes de garantía requeridos.
ASD_ECP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASD_ECP.1.2E El evaluador debe confirmar que las suposiciones acerca del entorno operacional descritos en los
informes de certificación independientes o Informes Técnicos de Evaluación de los productos evaluados cumplen
con los requisitos del entorno operacional del STOE.
C.6.4 Productos del componente no evaluados (AOC_UCP)
C.6.4.1 Objetivos
Esta familia define los requisitos de garantía y configuración para componentes del sistema operacional que se cons-
truyen a partir de productos no evaluados. Al crear un sistema operacional a partir de componentes de producto no
evaluados, hay una necesidad de especificar la garantía requerida a aspectos de las actividades de desarrollo e inte-
gración. Para productos como programas de aplicación de negocio que se desarrollan específicamente para el sistema
operacional, durante las actividades de desarrollo puede producirse la misma evidencia de garantía que se requiera para
la evaluación del producto por parte del desarrollador del producto.
Se puede fiarse de las declaraciones de garantía del desarrollador del producto. Alternativamente, para alcanzar una
mayor garantía, las declaraciones pueden verificarse por parte del evaluador que realiza una evaluación del producto.
Los requisitos de garantía pueden especificarse como paquetes de garantía, como un EAL, como parte de un PP o SPP o
definirse explícitamente.
Cuando los componentes de producto tienen parámetros específicos para una operación segura, estos parámetros deben
establecerse correctamente.

C.6.4.3 AOC_UCP.1 Productos del componente no evaluados

Dependencias: AOC_OBM.1 Configuración del sistema operacional.
- 143 - ISO/IEC TR 19791:2010
AOC_UCP.1.1D El desarrollador/integrador debe definir los paquetes de garantía requeridos para productos
AOC_UCP.1.2D El desarrollador/integrador debe ofrecer documentación de configuración para cada producto

del componente no evaluado.
AOC_UCP.1.3D El desarrollador/integrador debe ofrecer declaraciones de seguridad para cada producto del
componente no evaluado.
AOC_UCP.1.1C El plan de CM debe demostrar que los parámetros operacionales para cada producto no
evaluado están configurados de acuerdo con su documentación de configuración.
AOC_UCP.1.2C Para cada producto no evaluado, la declaración de seguridad debe demostrar que se satisfacen
los paquetes de garantía requeridos.
ASD_UCP.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.6.4.4 AOC_UCP.2 Verificación de los productos del componente no evaluados
Jerárquico a: AOC_UCP.1 Productos del componente no evaluados
Dependencias: AOC_OBM.1 Configuración del sistema operacional
AOC_UCP.2.1D El desarrollador/integrador debe definir los paquetes de garantía requeridos para productos
AOC_UCP.2.2D El desarrollador/integrador debe ofrecer documentación de configuración para cada producto del
AOC_UCP.2.3D El desarrollador/integrador debe ofrecer declaraciones de seguridad para cada producto del
AOC_UCP.2.1C El plan de CM debe demostrar que los parámetros operacionales para cada producto no evaluado están
configurados de acuerdo con su documentación de configuración.
AOC_UCP.2.2C Para cada producto no evaluado, la declaración de seguridad debe demostrar que se satisfacen los
paquetes de garantía requeridos.
ASD_UCP.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASD_UCP.2.2E El evaluador debe realizar una evaluación del producto y confirmar que los productos no
evaluados cumplen con los paquetes de garantía requeridos bajo el entorno operacional del STOE.
ISO/IEC TR 19791:2010 - 144 -
C.7 Clase AOT: Prueba del sistema operacional
C.7.1 Introducción
El propósito de esta clase es verificar que los componentes del sistema operacional, una vez instalados y configurados
de acuerdo con la arquitectura del sistema operacional y la evidencia de configuración del mismo, cumplen con los
requisitos funcionales de seguridad especificados en el SST y son eficaces en aplicar el concepto de operaciones de
seguridad del sistema operacional. La documentación de arquitectura, integración y diseño del sistema operacional
ayuda a probar el plan y la ejecución. Esto se consigue determinando que la SSF se ha configurado como especifica la
especificación de configuración, probada frente a la evidencia relevante de arquitectura y diseño, realizando una
muestra de las pruebas del desarrollador/integrador y probando independientemente una parte de la SSF.
Esta clase está compuesta por cinco familias. Cuatro familias, Cobertura de las pruebas del sistema operacional
(AOT_COV), Profundidad de las pruebas del sistema operacional (AOT_DPT), Pruebas funcionales del sistema opera-
cional (AOT_FUN) y Pruebas independientes del sistema operacional (AOT_IND) se basan muy íntimamente en fami-
lias equivalentes en la Norma ISO/IEC 15408 para las pruebas de productos. La última familia, Pruebas de regresión del
sistema operacional (AOT_REG) se usa para probar modificaciones a un sistema operacional ya funcionando.
Las pruebas utilizando la clase AOT siempre se realizan en un entorno de pruebas. Es por tanto posible que los contro-
les operacionales en el entorno operacional actúen de forma distinta al comportamiento observado en el entorno de
pruebas. Los resultados de las pruebas deben por tanto ser complementados generalmente por el examen y verificación
durante la operación del sistema de registros y controles operacionales.
C.7.2 Cobertura de las pruebas del sistema operacional (AOT_COV)
C.7.2.1 Objetivos
Esta familia se ocupa de aquellos aspectos de la prueba que se ocupan de que sea completa la cobertura de las pruebas.
Es decir, se ocupa del grado en que se prueba la SSF y de si la prueba es suficientemente extensa o no como para de-
mostrar que la SSF opera como está especificada.

Esta familia tiene dos componentes. Los componentes en esta familia se descomponen basándose en la prueba de todas
las interfaces definidas en la especificación funcional de interfaces y la prueba de todos los parámetros de esas
interfaces.
C.7.2.3 AOT_COV.1 Evidencia de cobertura
Dependencias: ASD_IFS Especificación funcional de la interfaz
AOT_FUN.1 Pruebas funcionales
C.7.2.3.1 Objetivos
El objetivo de este componente es establecer que se han probado todas las interfaces de la SSF. Esto se logra mediante
un examen de un análisis de la cobertura de las pruebas de la AOT_FUN.

En este componente se requiere que el desarrollador/integrador demuestre que las pruebas que hayan sido identificadas
prueben todas las funciones visibles de seguridad tal y como están descritas en la especificación funcional de la interfaz.
El análisis no debería mostrar solo la correspondencia entre pruebas y funciones de seguridad, sino que debería ofrecer
asimismo información suficiente al evaluador para determinar cómo se han ejercitado las funciones. Esta información
puede usarse para planificar pruebas adicionales del evaluador. Aunque a este nivel el desarrollador/integrador tiene que
demostrar que ha sido probada cada una de las funciones dentro de la especificación funcional de la interfaz, el volumen
de pruebas que necesita cada función no necesita ser exhaustivo.
- 145 - ISO/IEC TR 19791:2010
AOT_COV.1.1D El desarrollador/integrador debe ofrecer un análisis de la cobertura de las pruebas.
AOT_COV.1.1C El análisis de la cobertura de las pruebas debe demostrar la correspondencia entre las pruebas
identificadas en la documentación de pruebas y la SSF accesible a través de interfaces visibles del sistema
operacional descritas en la especificación funcional de la interfaz.
AOT_COV.1.2C El análisis de la cobertura de las pruebas debe demostrar que han sido probadas todas las SSF
accesible a través de interfaces visibles del sistema operacional descritas en la especificación funcional de la
interfaz.
AOT_COV.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.7.2.4 AOT_COV.2 Análisis riguroso de la cobertura
Jeráquico a: AOT_COV.1 Evidencia de cobertura
Dependencias: ASD_IFS Especificación funcional de la interfaz
C.7.2.4.1 Objetivos
El objetivo de este componente es establecer que se han probado todos los parámetros de todas las interfaces de la SSF
a través de una prueba exhaustiva. Esto se logra mediante un examen de un análisis de la cobertura de las pruebas de la
AOT_FUN.

En este componente se requiere que el desarrollador/integrador demuestre que las pruebas que hayan sido identificadas
prueben todos los parámetros de todas las funciones visibles de seguridad tal y como están descritas en la especificación
funcional de la interfaz. Este requisito adicional incluye pruebas de límites (es decir, verificar que se generan errores
cuando se exceden los límites establecidos) y pruebas negativas (por ejemplo, cuando se da acceso al Usuario A,
verificando que el Usuario B no obtiene acceso repentinamente). Este tipo de pruebas no es exhaustivo porque no se
espera que se verifique todo posible valor de los parámetros o toda posible acción del usuario.
AOT_COV.2.1D El desarrollador/integrador debe ofrecer un análisis de la cobertura de las pruebas.
AOT_COV.2.1C El análisis de la cobertura de las pruebas debe demostrar la correspondencia entre las pruebas
identificadas en la documentación de pruebas y la SSF accesible a través de interfaces visibles del sistema operacional
descritas en la especificación funcional de la interfaz.
AOT_COV.2.2C El análisis de la cobertura de las pruebas debe demostrar que han sido probadas todas las SSF
accesible a través de interfaces visibles del sistema operacional descritas en la especificación funcional de la interfaz.
ISO/IEC TR 19791:2010 - 146 -
AOT_COV.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
C.7.3 Profundidad de las pruebas del sistema operacional (AOT_DPT)
C.7.3.1 Objetivos
Los componentes en esta familia se ocupan del nivel de detalle al que se prueba la SSF por parte del desarrollador o
integrador, basándose en el conocimiento del diseño del sistema. La especificación se basa en aumentar la profundidad
de la información derivada del análisis de las representaciones adicionales del diseño.
El objetivo es compensar el riesgo de olvidar un error en el desarrollo e integración del STOE. Además, probar que las
interfaces concretas internas de los ejercicios pueden ofrecer garantía no solo de que la SSF muestra el comportamiento
externo de seguridad deseado, sino asimismo que su comportamiento deriva de mecanismos internos que funcionan
correctamente.

Esta familia tiene tres componentes. Los componentes en esta familia se descomponen basándose en el creciente detalle
ofrecido en las representaciones de la SSF, desde el diseño de subsistemas a la representación de implantación. Esta
descomposición refleja las representaciones de la SSF presentadas en la clase ASD.

La cantidad y tipo concretos de documentación y evidencias, en general, estarán determinados por componentes elegi-
dos de la AOT_FUN. Hay que advertir que de las pruebas básicas el nivel de la especificación funcional de la interfaz
se ocupa la AOT_COV.
El principio adoptado dentro de esta familia es que el nivel de prueba sea apropiado al nivel de garantía observado.
Cuando se apliquen componentes superiores, los resultados de la prueba tendrán que demostrar que la implantación de
la SSF es coherente con su diseño. Por ejemplo, el diseño del subsistema debería describir cada uno de los subsistemas
y asimismo describir las interfaces entre estos subsistemas con detalle suficiente para que el propósito, efectos y errores
de cada interfaz sean definidos con claridad. La evidencia de las pruebas al nivel de diseño del subsistema debe mostrar
que se han ejercitado las interfaces internas entre subsistemas. Esto puede lograrse mediante pruebas a través de las
interfaces externas de la SSF o probando las interfaces del sistema aisladamente, quizá empleando un arnés o sistema de
prueba.. Los componentes superiores en esta familia se dirigen a verificar la correcta operación de las interfaces internas
que se hagan visibles a medida que el diseño se haga menos abstracto. Cuando se apliquen estos componentes será más
difícil ofrecer una evidencia adecuada de la profundidad de las pruebas utilizando solo las interfaces externas de la SSF.
C.7.3.4 AOT_DPT.1 Pruebas: diseño del subsistema
Dependencias: ASD_STD.1 Diseño del subsistema
C.7.3.4.1 Objetivos
El diseño del subsistema ofrece una descripción del funcionamiento interno de la SSF. Las pruebas a nivel de
subsistemas ofrecen garantía de que los subsistemas de la SSF se han realizado correctamente.
AOT_DPT.1.1D El desarrollador/integrador debe ofrecer un análisis de la profundidad de las pruebas.
- 147 - ISO/IEC TR 19791:2010
AOT_DPT.1.1C El análisis de la profundidad de las pruebas debe demostrar la correspondencia entre las
pruebas identificadas en la documentación de pruebas y los subsistemas del STOE identificados en el diseño del
subsistema.
AOT_DPT.1.2C El análisis de la profundidad de las pruebas debe demostrar que se han probado todos los
subsistemas del STOE identificados en el diseño del subsistema.
AOT_DPT.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.7.3.5 AOT_DPT.2 Pruebas: diseño del componente
Jerárquico a: AOT_DPT.1 Pruebas: diseño del subsistema
Dependencias: ASD_STD.2 Diseño del componente
C.7.3.5.1 Objetivos
El diseño del componente ofrece una descripción del funcionamiento interno de la SSF. Las pruebas a nivel de compo-
nentes ofrecen garantía de que los subsistemas de la SSF se han realizado correctamente.

Todos los componentes identificados en el diseño del componente deberían normalmente contener funcionalidades de
aplicación de la SSF y por tanto necesitan haber sido probados. Para los componentes software, el diseño del
componente normalmente será a un nivel más alto de detalle que los módulos de código individual.
AOT_DPT.2.1C El análisis de la profundidad de las pruebas debe demostrar la correspondencia entre las pruebas
identificadas en la documentación de pruebas y los subsistemas del STOE identificados en el diseño del subsistema.
AOT_DPT.2.2C El análisis de la profundidad de las pruebas debe demostrar que se han probado todos los subsistemas
del STOE identificados en el diseño del subsistema.
AOT_DPT.2.3C El análisis de la profundidad de las pruebas debe demostrar que se han probado todos los
componentes del STOE identificados en el diseño del componente.
AOT_DPT.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
C.7.3.6 AOT_DPT.3 Pruebas: representación de la implantación
Jerárquico a: AOT_DPT.2 Pruebas: diseño del componente
ISO/IEC TR 19791:2010 - 148 -
Dependencias: ASD_STD.3 Diseño más representación de la implantación
C.7.3.6.1 Objetivos
La representación de la implantación de una SSF determina su comportamiento real. Las pruebas a nivel de represen-
tación de la implantación ofrecen garantía de que las SSF relevantes se han realizado correctamente de todas las formas.

No se contempla que se ofrezca o prueba la representación de la implantación (por ejemplo, el código fuente) para todos
los componentes del sistema operacional, solo para aquéllos que configuren otras partes del sistema operacional o
implanten funcionalidades críticas de seguridad que soporten otros componentes. Los programas de integración o de
rutina de salida desarrollados solamente para el el sistema operacional pueden ser el objetivo de esta familia.
AOT_DPT.3.1C El análisis de la profundidad de las pruebas debe demostrar la correspondencia entre las pruebas
identificadas en la documentación de pruebas y los subsistemas del STOE identificados en el diseño del subsistema.
AOT_DPT.3.2C El análisis de la profundidad de las pruebas debe demostrar que se han probado todos los subsistemas
del STOE identificados en el diseño del subsistema.
AOT_DPT.3.3C El análisis de la profundidad de las pruebas debe demostrar que se han probado todos los componentes
del STOE identificados en el diseño del componente.
AOT_DPT.3.4C El análisis de la profundidad de las pruebas debe demostrar que la SSF de la que se ofrece la
representación de la implantación opera de acuerdo con esa representación.
AOT_DPT.3.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
C.7.4 Pruebas funcionales del sistema operacional (AOT_FUN)
C.7.4.1 Objetivos
El objetivo de este componente es que el desarrollador/integrador demuestre que todas las funciones de seguridad fun-
cionan como están especificadas. Se requiere que el desarrollador realice pruebas y ofrezca documentación de dichas
pruebas.
Las pruebas funcionales realizadas por el desarrollador o el integrador establecen si la SSF muestra las propiedades
necesarias para satisfacer los requisitos funcionales de su PP/ST. Dichas pruebas funcionales ofrecen garantía de que la
SSF satisface al menos los requisitos funcionales de seguridad, aunque no puede establecer que la SSF haga más de lo
que se especificó. La familia “pruebas funcionales” se centra en el tipo y cantidad de documentación o herramientas de
apoyo requeridos y a qué es lo que hay que demostrar a través de las pruebas del desarrollador. Las pruebas funcionales
no se limitan a la confirmación positiva de que se ofrecen las funciones de seguridad requeridas, sino que pueden
asimismo incluir pruebas negativas a verificar por la ausencia de un comportamiento indeseado concreto (a menudo
basado en la inversión de los requisitos funcionales).
- 149 - ISO/IEC TR 19791:2010
Esta familia contribuye a ofrecer garantía de que la probabilidad de fallos no descubiertos sea relativamente baja.
Las familias AOT_COV, AOT_DPT y AOT_FUN se usan en combinación para definir la evidencia de las pruebas a
suministrar por un desarrollador o un integrador. Las pruebas funcionales independientes por parte del evaluador se
especifican en AOT_IND.


Se espera que los procedimientos para realizar pruebas ofrezcan instrucciones para el uso de programas y suites de
pruebas, incluyendo el entorno de prueba, las condiciones de prueba, los parámetros de los datos de prueba y los
valores. Los procedimientos de pruebas debería también mostrar cómo se deducen los resultados de las pruebas de las
entradas de las mismas.
Esta familia especifica los requisitos para la presentación de todos los planes, procedimientos y resultados de las
pruebas. Así que la cantidad de información que debe presentarse variará de acuerdo con el uso de AOT_COV y
AOT_DPT.
Ordenar las dependencias es importante cuando la ejecución con éxito de una prueba concreta depende de la existencia
de un estado concreto. Por ejemplo, podría requerir que la prueba A sea ejecutada inmediatamente antes que la prueba
B, ya que el estado resultante de la ejecución con éxito de la prueba A es un prerrequisito para la ejecución con éxito de
la prueba B. Así que el fallo en la prueba B podría relacionarse con un problema al ordenar las dependencias. En el
ejemplo anterior, la prueba B podría fallar porque la prueba C (en lugar de la prueba A) se ejecutó inmediatamente antes
o podría relacionarse con un fallo en la prueba A. Es esencial un análisis de las dependencias entre pruebas funcionales
en los sistemas operacionales porque no puede suponerse que los usuarios realicen las acciones en cualquier orden
concreto.
C.7.4.4 AOT_FUN.1 Pruebas funcionales
AOT_FUN.1.1D El desarrollador/integrador debe probar la SSF y documentar los resultados.
AOT_FUN.1.2D El desarrollador/integrador debe ofrecer documentación de las pruebas.
AOT_FUN.1.1C La documentación de pruebas debe consistir en planes de pruebas, resultados esperados de las
pruebas y resultados reales de las pruebas.
AOT_FUN.1.2C Los planes de pruebas deben identificar las pruebas a realizar y describir los escenarios para
realizar cada prueba. Estos escenarios deben incluir cualquier ordenación de dependencias en elos resultados de
otras pruebas.
AOT_FUN.1.3C Los resultados esperados de las pruebas deben mostrar los resultados anticipados para una
ejecución con éxito de las pruebas.
AOT_FUN.1.4C Los resultados reales de las pruebas deben ser coherentes con los resultados esperados de las
pruebas.
AOT_FUN.1.5C La documentación de pruebas debe incluir un análisis de cualquier dependencia de ordenación

del procedimiento de pruebas.
ISO/IEC TR 19791:2010 - 150 -
AOT_FUN.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.7.5 Pruebas independientes del sistema operacional (AOT_IND)
C.7.5.1 Objetivos
El objetivo de esta familia es ofrecer evidencia independiente de que las funciones de seguridad funcionan como está
especificado.

Esta familia tiene tres componentes. La descomposición se basa en si hay acceso a los documentación de pruebas del
desarrollador/integrador y en la integridad de las pruebas.

Las pruebas especificadas en esta familia pueden ser soportadas por una parte con conocimiento especializado distinta
del evaluador (por ejemplo, un laboratorio independiente, una organización objetiva de consumidores). Las pruebas re-
quieren una comprensión del STOE coherente con el rendimiento de otras actividades de garantía y el evaluador retiene
la responsabilidad de asegurarse de que se ocupan de los requisitos de esta familia cuando se emplee dicho soporte.
Las pruebas funcionales independientes pueden adoptar la forma de repetir las pruebas funcionales del desarrollador, en
todo o en parte. Pueden asimismo tomar la forma de pruebas funcionales ideadas por el evaluador, ya sea para extender
el ámbito o la profundidad de las pruebas del desarrollador o porque los resultados del desarrollador no estén dispo-
nibles. Estas actividades son complementarias y debe planificarse una mezcla adecuada para cada STOE, que tenga en
cuenta la disponibilidad y cobertura de los resultados de prueba y la complejidad funcional de la SSF.
Los muestreos de pruebas del desarrollador pretenden ofrecer confirmación de que el desarrollador ha realizado su
programa de pruebas planificado en la SSF y ha registrado correctamente los resultados. El tamaño de la muestra
seleccionada se verá influenciado por el detalle y cualidad de los resultados de las pruebas funcionales del
desarrollador. El evaluador tendrá que considerar también el ámbito para la creación de pruebas adicionales y el
beneficio relativo que puede obtenerse por trabajar es estas dos áreas. Se reconoce que la repetición de todas las pruebas
del desarrollador puede ser viable y deseable en algunos casos, pero puede ser muy ardua y menos productiva en otros.
El componente superior de esta familia debería por tanto utilizarse con precaución. El muestreo se ocupará de todo el
rango de resultados de pruebas disponibles, incluyendo las proporcionadas para cumplir con los requisitos tanto de
AOT_COV como de AOT_DPT.
También hay que considerar las distintas configuraciones del STOE que están incluidas dentro de la evaluación. El
evaluador necesitará evaluar la aplicabilidad de los resultados ofrecidos y planificar sus propias pruebas
consecuentemente.
Las pruebas funcionales independientes son distintas de las pruebas de penetración, basándose estas últimas en una
investigación informada y sistemática de vulnerabilidades en el diseño o la implantación. Las pruebas de penetración se
especifican utilizando la familia AOV_VAN.
La disponibilidad para pruebas del STOE se basa en el acceso al STOE y la documentación e información de soporte
requeridos (incluyendo cualquier software o herramienta de pruebas) para realizar las pruebas. De la necesidad de dicho
soporte se ocupan las dependencias de otras familias de garantía.
Además, la disponibilidad del STOE para las pruebas puede basarse en otras consideraciones. Por ejemplo, la versión
del STOE probada por el desarrollador puede no ser la versión final.
Las referencias a un subgrupo de la SSF pretenden permitir al evaluador diseñar una serie apropiada de pruebas que sea
coherente con los objetivos de la evaluación a realizar.
- 151 - ISO/IEC TR 19791:2010
C.7.5.4 AOT_IND.1 Pruebas independientes - conformidad
Dependencias: ASD_IFS.1 Especificación funcional de la interfaz
C.7.5.4.1 Objetivos
En este componente, el objetivo es demostrar que la SSF opera de acuerdo con la documentación de la especificación de
la interfaz y la guía del usuario para el STOE, sin acceso a los resultados de las pruebas del desarrollador.

Este componente no se ocupa del uso de los resultados de las pruebas del desarrollador. Es aplicable cuando dichos
resultados no están disponibles y también en casos en que las pruebas del desarrollador se acepten sin validación. Se re-
quiere que el evaluador idee y realice pruebas con el objetivo de confirmar que el STOE opera de acuerdo con la docu-
mentación de la especificación de la interfaz y la guía del usuario. La postura es obtener confianza en una operación
correcta a través de pruebas representativas, en lugar de realizar todas las pruebas posibles. La extensión de las pruebas
a planificar para este fin es un asunto metodológico y tiene que ser considerado en el contexto de un STOE concreto y
su equilibrio con otras actividades de evaluación.
AOT_IND.1.1D El desarrollador/integrador debe proveer el STOE y un entorno de prueba para realizar dicha
prueba.
AOT_IND.1.1C La documentación del STOE y de la guía del usuario debe permitir al evaluador preparar y
llevar a cabo las pruebas.
AOT_IND.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
AOT_IND.1.2E El evaluador debe probar un subgrupo de las interfaces del STOE para confirmar que la SSF
opera como está previsto.
C.7.5.5 AOT_IND.1 Pruebas independientes - muestreo
Jerárquico a: AOT_IND.1 Pruebas independientes - conformidad
C.7.5.5.1 Objetivos
la interfaz y la guía del usuario para el STOE. Las pruebas del evaluador confirman los resultados de las pruebas del
desarrollador/integrador repitiendo una muestra de las pruebas del desarrollador y también realizan algunas pruebas
adicionales.
ISO/IEC TR 19791:2010 - 152 -

La idea es que el desarrollador debería proveer al evaluador los materiales necesarios para una reproducción eficiente de
las pruebas de desarrollo. Esto puede incluir como documentación de prueba legible por las máquinas, programas de
prueba, etc.
Este componente contiene un requisito de que el evaluador tenga disponibles resultados de pruebas del desarrollador
para complementar el programa de pruebas. El evaluador repetirá una muestra de las pruebas del desarrollador para
tener confianza en los resultados obtenidos. Una vez establecida esa confianza el evaluador trabajará a partir de las
pruebas del desarrollador realizando pruebas adicionales que ejerciten el STOE de una forma distinta. Utilizando una
plataforma validada de pruebas del desarrollador, el valuador es capaz de tener confianza en que el STOE opera
correctamente en un rango más amplio de condiciones de las que sería posible utilizando los propios esfuerzos del
desarrollador, dado un nivel fijo de recursos. Una vez obtenida la confianza en que el desarrollador ha probado el
STOE, el evaluador tendrá también más libertad, cuando corresponda, para concentrar las pruebas en áreas en que el
examen de la documentación o el conocimiento del especialista haya generado preocupaciones concretas.
AOT_IND.2.1D El desarrollador/integrador debe proveer el STOE y un entorno de prueba para realizar dicha prueba.
AOT_IND.2.1C La documentación del STOE y de la guía del usuario debe permitir al evaluador preparar y llevar a
cabo las pruebas.
AOT_IND.2.2C El desarrollador/integrador debe proveer un grupo de recursos equivalente a los usados en las
pruebas funcionales del desarrollador de la SSF.
AOT_IND.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
AOT_IND.2.2E El evaluador debe ejecutar una muestra de pruebas en la documentación de prueba para
verificar los resultados de prueba del desarrollador.
AOT_IND.2.3E El evaluador debe probar un subgrupo de las interfaces del STOE para confirmar que la SSF opera
como está previsto.
C.7.5.6 AOT_IND.1 Pruebas independientes - completas
Jerárquico a: AOT_IND.2 Pruebas independientes - muestreo
C.7.5.6.1 Objetivos
la interfaz y la guía del usuario para el STOE. Las pruebas del evaluador confirman los resultados de las pruebas del
desarrollador/integrador repitiendo todas las pruebas del desarrollador y también realizan pruebas adicionales a todo el
STOE.
- 153 - ISO/IEC TR 19791:2010

La idea es que el desarrollador debería proveer al evaluador los materiales necesarios para una reproducción eficiente de
las pruebas del desarrollador/integrador. Esto puede incluir como documentación de prueba legible por las máquinas,
programas de prueba, etc.
En este componente, el evaluador debe repetir todas las pruebas del desarrollador como parte del programa de pruebas.
Igual que en los componentes anteriores, el evaluador realizará asimismo pruebas que se dirijan a ejercitar el STOE de
una manera distinta de la establecida por el desarrollador. En los casos en que las pruebas del desarrollador sean
exhaustivas, puede haber poco espacio para esto.
AOT_IND.3.1D El desarrollador/integrador debe proveer el STOE y un entorno de prueba para realizar dicha prueba.
AOT_IND.3.1C La documentación del STOE y de la guía del usuario debe permitir al evaluador preparar y llevar a
cabo las pruebas.
AOT_IND.3.2C El desarrollador/integrador debe proveer un grupo de recursos equivalente a los usados en las pruebas
funcionales del desarrollador de la SSF.
AOT_IND.3.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
AOT_IND.3.2E El evaluador debe ejecutar una muestra de pruebas en la documentación de prueba para verificar los
resultados de prueba del desarrollador.
AOT_IND.3.3E El evaluador debe probar un subgrupo de las interfaces del STOE para confirmar que la SSF opera
como está previsto.
C.7.6 Pruebas de regresión del sistema operacional (AOT_REG)
C.7.6.1 Objetivos
El objetivo de este componente es demostrar que las funciones de seguridad actúan como está especificado después de
cambios o modificaciones de los componentes del sistema, la configuración del sistema o el entorno operacional.

C.7.6.3 AOT_REG.1 Pruebas de regresión
C.7.6.3.1 Objetivos
En este componente, el objetivo de es demostrar que las funciones de seguridad actúan como está especificado después
de cambios o modificaciones de los componentes del sistema, la configuración del sistema o el entorno operacional.

Este componente no solo se ocupa de la prueba de cambios o partes modificadas del sistema operacional, sino también
de otras partes.
ISO/IEC TR 19791:2010 - 154 -
AOT_REG.1.1D El desarrollador/integrador debe probar la SSF implantada por áreas cambiadas o modificadas
del STOE y documentar los resultados.
AOT_REG.1.1C El análisis de las pruebas de regresión debe identificar aquellas SSF que sean implantadas por
áreas cambiadas o modificadas del STOE y los cambios esperados, o su ausencia, en el comportamiento de
dichas SSF.
AOT_REG.1.2C La documentación de las pruebas de regresión debe cubrir aquellas SSF que se implanten por
áreas cambiadas o modificadas del STOE.
AOT_REG.1.3C La documentación de las pruebas de regresión debe consistir en planes de pruebas, resultados
esperados de las pruebas y resultados reales de las pruebas.
AOT_REG.1.4C Los planes de prueba deben identificar las pruebas a realizar y describir los escenarios para
cada prueba. Estos escenarios deben incluir cualquier dependencia ordenada de los resultados de otras pruebas.
AOT_REG.1.5C Los resultados esperados de las pruebas deben mostrar los resultados anticipados en caso de
una ejecución con éxito de las pruebas.
AOT_REG.1.6C Los resultados reales de las pruebas deben ser coherentes con los resultados esperados de las
pruebas.
AOT_REG.1.7C Los resultados reales de las pruebas deben demostrar que cada SSF probada se comportó como
estaba especificado en el análisis de las pruebas de regresión.
AOT_REG.1.8C La documentación de las pruebas debe incluir un análisis de cualquier dependencia ordenada
del procedimiento de pruebas.
AOT_REG.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.8 Clase AOV: Evaluación de vulnerabilidades del sistema operacional
C.8.1 Introducción
El propósito de la actividad de evaluación de vulnerabilidades es determinar si las potenciales vulnerabilidades dentro
del STOE representan vulnerabilidades reales que podrían ser explotadas por un atacante. La determinación se basa en
el análisis del evaluador, verificando vulnerabilidades comunes que puedan encontrarse en sistemas similares y, a un
nivel superior, investigar potenciales vulnerabilidades identificadas durante otras tareas de evaluación.
La evaluación de vulnerabilidades considera tanto los controles técnicos como operacionales. Sin embargo, cualquier
prueba para determinar si potenciales vulnerabilidades son realmente explotables se realiza en un entorno de desarrollo.
Es por tanto posible que existan vulnerabilidades reales adicionales, porque los controles operacionales en el entorno
operacional funcionen de forma distinta de su comportamiento observado en el entorno de prueba. La evaluación de
vulnerabilidades debe por tanto suplementarse por lo general con el examen y verificación durante la operación de
registros y controles operacionales del sistema.
Esta clase realiza una única función de evaluación y por tanto contiene una familia de componentes de garantía.
- 155 - ISO/IEC TR 19791:2010
C.8.2 Análisis de vulnerabilidades (AOV_VAN)
C.8.2.1 Objetivos
El objetivo del análisis de vulnerabilidades es determinar si las vulnerabilidades potenciales identificadas durante la
evaluación de la construcción y operación anticipada del STOE podrían en realidad permitir a atacantes violar los SFR.

Esta familia contiene siete componentes. Los componentes en esta familia se descomponen inicialmente en forma de
análisis de potenciales vulnerabilidades asumidas y luego a niveles más altos sobre el nivel de sofisticación considerado
para montar un ataque real.
C.8.2.3 AOV_VAN.1 Encuesta de vulnerabilidades de la arquitectura
C.8.2.3.1 Objetivos
Una encuesta de vulnerabilidades de la información disponible en el dominio público es realizada por el evaluador para
identificar potenciales vulnerabilidades que pueda encontrar fácilmente un atacante.
El evaluador realiza luego las pruebas de penetración, para confirmar que las potenciales vulnerabilidades no pueden
explotarse en el entorno operacional propuesto para el STOE. Las pruebas de penetración son realizadas por el
evaluador suponiendo un ataque potencial básico.

Este componente no requiere que la documentación de seguridad esté disponible cuando se planifiquen las pruebas de
penetración. Es por tanto más apropiado para dominios dentro de un STOE en que no haya funcionalidad de seguridad,
como forma de asegurar que estos dominios no pueden usarse para subvertir otros.
AOV_VAN.1.1D El desarrollador/integrador debe ofrecer el STOE y un entorno de pruebas para hacer dichas
pruebas.
AOV_VAN.1.1C La documentación del STOE y de guía del usuario debe permitir al evaluador preparar y llevar
a cabo pruebas.
AOV_VAN.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
AOV_VAN.1.2E El evaluador debe realizar una búsqueda de fuentes de dominio público para identificar
potenciales vulnerabilidades en el STOE, basándose en la descripción de la arquitectura.
AOV_VAN.1.3E El evaluador debe realizar pruebas de penetración, basadas en las vulnerabilidades potenciales
detectadas, para determinar que el STOE es resistente a ataques realizados por un atacante que posea un
potencial básico de ataque.
ISO/IEC TR 19791:2010 - 156 -
C.8.2.4 AOV_VAN.2 Encuesta de vulnerabilidades avanzada
Jerárquico a: AOV_VAN.1 Encuesta de vulnerabilidades de la arquitectura
C.8.2.4.1 Objetivos
Una encuesta de vulnerabilidades de la información disponible en el dominio público es realizada por el evaluador para
identificar potenciales vulnerabilidades que pueda encontrar fácilmente un atacante. La encuesta tiene en cuenta las
propiedades de seguridad pretendidas del STOE o el dominio del STOE.

Este componente requiere que la documentación del concepto de seguridad de operaciones esté disponible cuando se
identifique las potenciales vulnerabilidades. Por tanto las pruebas de penetración pueden dirigirse hacia las propiedades
de seguridad pretendidas del STOE o el dominio del STOE al que se apliquen.
AOV_VAN.2.1D El desarrollador/integrador debe ofrecer el STOE y un entorno de pruebas para hacer dichas pruebas.
AOV_VAN.2.1C La documentación del STOE y de guía del usuario debe permitir al evaluador preparar y llevar a cabo
pruebas.
AOV_VAN.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
AOV_VAN.2.2E El evaluador debe realizar una búsqueda de fuentes de dominio público para identificar potenciales
vulnerabilidades en el STOE, basándose en la descripción de la arquitectura y la documentación del concepto de
seguridad de operaciones.
detectadas, para determinar que el STOE es resistente a ataques realizados por un atacante que posea un potencial
básico de ataque.
C.8.2.5 AOV_VAN.3 Análisis de vulnerabilidades de la interfaz
Jerárquico a: AOV_VAN.2 Encuesta de vulnerabilidades de la arquitectura
ASD_IFS.1 Especificación funcional de la interfase
- 157 - ISO/IEC TR 19791:2010
C.8.2.5.1 Objetivos
Además de una encuesta de vulnerabilidades de la información disponible en el dominio público, el evaluador realiza
un análisis de vulnerabilidad de las interfaces dentro del STOE para identificar potenciales vulnerabilidades.
explotarse en el entorno operacional propuesto para el STOE. Las pruebas de penetración son realizadas por el evalua-
dor suponiendo un ataque potencial básico.

Este componente requiere que esté disponible la documentación del concepto de seguridad de operaciones y la especifi-
cación funcional de la interfaz. Sin embargo, no requiere ninguna documentación del diseño. Por tanto el análisis de
vulnerabilidades solo puede identificar discrepancias funcionales.
pruebas.
AOV_VAN.3.3E El evaluador debe realizar un análisis independiente de vulnerabilidades del STOE para
identificar potenciales vulnerabilidades en el STOE, utilizando la descripción de la arquitectura, la
documentación del concepto de seguridad de operaciones y la documentación de guía del usuario.
básico de ataque.
C.8.2.6 AOV_VAN.4 Análisis de vulnerabilidades del diseño
Jerárquico a: AOV_VAN.3 Análisis de vulnerabilidades de la interfase
ASD_IFS.1 Especificación funcional de la interfase
ISO/IEC TR 19791:2010 - 158 -
C.8.2.6.1 Objetivos
un análisis de vulnerabilidades de la especificación y diseño del STOE para identificar potenciales vulnerabilidades.

El análisis de vulnerabilidades del diseño del STOE puede realizarse cuando solo hay disponible un diseño del subsiste-
ma. Sin embargo “toda la documentación disponible de diseño” incluye el diseño del componente y la representación de
la implantación si se incluyen componentes superiores del ASD_STD dentro del SST.
pruebas.
AOV_VAN.4.3E El evaluador debe realizar un análisis independiente de vulnerabilidades del STOE para identificar
potenciales vulnerabilidades en el STOE, utilizando la descripción de la arquitectura, la documentación del concepto de
seguridad de operaciones, toda la documentación disponible de diseño y la documentación de guía del usuario.
básico de ataque.
C.8.2.7 AOV_VAN.5 Análisis enfocado de vulnerabilidades
Jerárquico a: AOV_VAN.4 Análisis de vulnerabilidades del diseño
- 159 - ISO/IEC TR 19791:2010
C.8.2.7.1 Objetivos
un análisis enfocado de vulnerabilidades de la especificación y diseño del STOE para identificar potenciales vulnerabi-
lidades.
evaluador suponiendo un ataque potencial básico superior.

El análisis de vulnerabilidades del diseño del STOE puede realizarse cuando solo hay disponible un diseño del
subsistema. Sin embargo “toda la documentación disponible de diseño” incluye el diseño del componente y la
representación de la implantación si se incluyen componentes superiores del ASD_STD dentro del SST.
pruebas.
AOV_VAN.5.3E El evaluador debe realizar un análisis enfocado independiente de vulnerabilidades del STOE para
identificar potenciales vulnerabilidades en el STOE, utilizando la descripción de la arquitectura, la documentación del
concepto de seguridad de operaciones, toda la documentación disponible de diseño y la documentación de guía del
usuario.
básico superior de ataque.
C.8.2.8 AOV_VAN.6 Análisis metódico de vulnerabilidades
Jerárquico a: AOV_VAN.5 Análisis enfocado de vulnerabilidades
ISO/IEC TR 19791:2010 - 160 -
C.8.2.8.1 Objetivos
dor suponiendo un ataque potencial moderado.

El análisis de vulnerabilidades del diseño del STOE puede realizarse cuando solo hay disponible un diseño del subsis-
tema. Sin embargo “toda la documentación disponible de diseño” incluye el diseño del componente y la representación
de la implantación si se incluyen componentes superiores del ASD_STD dentro del SST.
pruebas.
AOV_VAN.6.3E El evaluador debe realizar un análisis metódico independiente de vulnerabilidades del STOE para
usuario.
moderado de ataque.
C.8.2.9 AOV_VAN.7 Análisis metódico avanzado de vulnerabilidades
Jerárquico a: AOV_VAN.6 Análisis metódico de vulnerabilidades
- 161 - ISO/IEC TR 19791:2010
C.8.2.9.1 Objetivos
dor suponiendo un ataque potencial alto.

El análisis de vulnerabilidades del diseño del STOE puede realizarse cuando solo hay disponible un diseño del subsiste-
ma. Sin embargo “toda la documentación disponible de diseño” incluye el diseño del componente y la representación de
la implantación si se incluyen componentes superiores del ASD_STD dentro del SST.
pruebas.
AOV_VAN.7.3E El evaluador debe realizar un análisis metódico independiente de vulnerabilidades del STOE para
usuario.
detectadas, para determinar que el STOE es resistente a ataques realizados por un atacante que posea un potencial alto
de ataque.
C.9 Clase APR: Preparación para la operación el tiempo real
C.9.1 Introducción
Antes de la operación en tiempo real es necesario establecer y definir una estructura de gestión de la seguridad cuyo
propósito sea promulgar e inculcar política y concienciación de seguridad dentro de la organización. La dirección
debería promover y apoyar de forma visible la seguridad en la organización a través de una participación activa en la
implantación de seguridad a lo largo de la organización. La actividad de dirección incluye articular objetivos de
seguridad para cumplir con los requisitos organizativos y se integra con los procesos relevantes de negocio. Las
actividades incluyen formular, revisar y aprobar políticas de seguridad, asegurarse de que hay un soporte de dirección
claro y visible y ofrecer programas de formación y concienciación en seguridad en apoyo a la política organizativa de
seguridad. También designar a un director como autoridad de seguridad de la información.
ISO/IEC TR 19791:2010 - 162 -
También es necesario confirmar la adecuación de los procedimientos utilizados para configurar el sistema operacional,
tanto en la instalación como en la rutina de puesta en marcha.
C.9.2 Formación en concienciación (APR_AWA)
C.9.2.1 Objetivos
Esta familia requiere que la dirección ofrezca formación como medio para que el personal conozca sus roles y responsa-
bilidades de seguridad al realizar sus funciones dentro del sistema operacional.

de la descripción en la documentación y la verificación en el sistema operacional.
C.9.2.3 APR_AWA.1 Formación en concienciación
C.9.2.3.1 Elementos de acción de la dirección
APR_AWA.1.1M La dirección debe realizar formación en concienciación con un proceso formal de presentación
diseñado para presentar [selección: todos los controles operacionales, [asignación: controles operacionales]] y sus
expectativas [selección: antes, dentro [asignación: plazo], periódicamente [asignación: periodo de tiempo]] dando
acceso al personal a los activos del sistema operacional.
APR_AWA.1.1C La formación en concienciación debe registrarse.
APR_AWA.1.2C Los registros deben contener día y hora, personal autorizado, personal al que se dirige,
contenidos y resultado de la formación.
APR_AWA.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.9.2.4 APR_AWA.2 Verificación de la formación en concienciación
Jerárquico a: APR_AWA.1 Formación en concienciación
APR_AWA.2.1M La dirección debe realizar formación en concienciación con un proceso formal de presentación
diseñado para presentar [selección: todos los controles operacionales, [asignación: controles operacionales]] y sus
expectativas [selección: antes, dentro [asignación: plazo], periódicamente [asignación: periodo de tiempo]] dando
acceso al personal a los activos del sistema operacional.
APR_AWA.2.1C La formación en concienciación debe registrarse.
APR_AWA.2.2C Los registros deben contener día y hora, personal autorizado, personal al que se dirige, contenidos y
resultado de la formación.
- 163 - ISO/IEC TR 19791:2010
APR_AWA.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
APR_AWA.2.2E El evaluador debe verificar independientemente la veracidad de la realización de la formación

en concienciación.
C.9.3 Comunicación (APR_CMM)
C.9.3.1 Objetivos
Esta familia requiere que la dirección tenga algunos medios de comunicar las documentaciones de guía operacional que
definen y especifican las SSF al personal apropiado.

C.9.3.3 APR_CMM.1 Información sobre controles
APR_CMM.1.1M La dirección debe comunicar [selección: todas las SSF, [asignación: SSF]] a todo el personal
asociado con los controles operacionales antes de darles acceso a los activos del sistema operacional.
APR_CMM.1.1C La información debe registrarse.
APR_CMM.1.2C Los registros deben contener día y hora, personal autorizado, personal al que se dirige y
contenidos de la información.
APR_CMM.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.9.3.4 APR_CMM.2 Verificación de la información sobre controles
Jerárquico a: APR_CMM.1 Información sobre controles
APR_CMM.2.1M La dirección debe comunicar [selección: todas las SSF, [asignación: SSF]] a todo el personal asocia-
do con los controles operacionales antes de darles acceso a los activos del sistema operacional.
APR_CMM.2.1C La información debe registrarse.
ISO/IEC TR 19791:2010 - 164 -
APR_CMM.2.2C Los registros deben contener día y hora, personal autorizado, personal al que se dirige y contenidos de
la información.
APR_CMM.2.2E El evaluador debe verificar independientemente la veracidad de la comunicación de los

C.9.4 Verificación de la instalación segura (APR_SIC)
C.9.4.1 Objetivos
Esta familia ofrece un medio de verificar la instalación y puesta en marcha del STOE. La instalación y puesta en marcha
del STOE deberían implantarse y operarse correctamente de acuerdo con la política de seguridad del sistema
operacional.

C.9.4.3 APR_SIC.1 Verificación de la instalación segura
APR_SIC.1.1M El desarrollador/integrador debe documentar procedimientos de instalación segura necesarios

para garantizar que las componentes e interfaces que comprenden el STOE, especialmente las que tienen
controles e interfaces de seguridad heredados, pueden instalarse, ponerse en marcha e interoperar de una forma
segura.
APR_SIC.1.1C La documentación de procedimientos de instalación segura debe describir los pasos necesarios
para la verificación de la instalación, puesta en marcha e interoperación seguras del STOE en su entorno.
C.9.4.4 APR_SIC.2 Verificación de la verificación de la instalación segura
Jerárquico a: APR_SIC.1 Verificación de la instalación segura

APR_SIC.2.1M El desarrollador/integrador debe documentar procedimientos de instalación segura necesarios para
garantizar que las componentes e interfaces que comprenden el STOE, especialmente las que tienen controles e
interfaces de seguridad heredados, pueden instalarse, ponerse en marcha e interoperar de una forma segura.
- 165 - ISO/IEC TR 19791:2010
APR_SIC.2.1C La documentación de procedimientos de instalación segura debe describir los pasos necesarios par la
verificación de la instalación, puesta en marcha e interoperación seguras del STOE en su entorno.
APR_SIC.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido y
presentación de las evidencias.
APR_SIC.2.2E El evaluador debe verificar que los procedimientos de instalación segura generan una
configuración segura.
C.10 Clase ASO: Registros del sistema operacional
C.10.1 Introducción
La mayoría de las actividades de garantía se realizan en un entorno de desarrollo o pruebas. Por tanto es posible que los
controles operacionales en el entorno operacional actúen de forma distinta al comportamiento observado en el entorno
de pruebas. Las actividades de garantía del desarrollo deben por tanto suplementarse por lo general por el examen y
verificación durante la operación del sistema de los registros y controles operacionales.
Esta clase contiene familias que se ocupan de si la SSF están actuando correcta y eficientemente durante la operación
del sistema operacional. El propósito principal de la operación del sistema de seguridad es permitir una determinación e
que el sistema operación está operando de una forma segura sin violar las políticas de seguridad del sistema
operacional. También define acciones que tendrán lugar si ocurren eventos relevantes de seguridad y cuando éstos
ocurran. Esta clase garantiza que se realizan las acciones apropiadas para detectar, registrar y responder a eventos que
puedan ser posibles violaciones de las políticas de seguridad del sistema operacional.
Las familias en esta clase definen medios para la dirección para monitorizar y verificar los controles operacionales.
C.10.2 Registros de operación de los controles operacionales (ASO_RCD)
C.10.2.1 Objetivos
Esta familia ofrece registros de operación para las SSF durante la operación. Los controles operacionales deberían
implantarse y operarse correcta y eficazmente de acuerdo con la política de seguridad del sistema operacional.

C.10.2.3 ASO_RCD.1 Registros de los controles operacionales
ASO_RCD.1.1M La dirección debe registrar la evidencia operacional definida por [selección: todos los controles
operacionales o [asignación: controles operacionales]].
ASO_RCD.1.1C Debe registrarse la información asociada con la evidencia operacional.
ISO/IEC TR 19791:2010 - 166 -
ASO_RCD.1.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que
se dirige y resultados de la operación.
ASO_RCD.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.10.2.4 ASO_RCD.2 Verificación de los registros operacionales
Jerárquico a: ASO_RCD.1 Registros de los controles operacionales
ASO_RCD.2.1M La dirección debe registrar la evidencia operacional definida por [selección: todos los controles
operacionales o [asignación: controles operacionales]].
ASO_RCD.2.1C Debe registrarse la información asociada con la evidencia operacional.
ASO_RCD.2.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que se
dirige y resultados de la operación.
ASO_RCD.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASO_RCD.2.2E El evaluador debe verificar independientemente que la información respecto de la operación de

los controles operacionales se registre correctamente.
C.10.3 Verificación de los controles operacionales (ASO_VER)
C.10.3.1 Objetivos
Esta familia ofrece medios para verificar los controles operacionales durante la operación. Los controles operacionales
deberían implantarse y operarse correcta y eficazmente de acuerdo con la política de seguridad del sistema operacional.

C.10.3.3 ASO_VER.1 Verificación de los controles operacionales
ASO_VER.1.1M La dirección debe verificar que [selección: todos los controles operacionales o [asignación:
controles operacionales]] están instalados y operan correcta y eficazmente.
- 167 - ISO/IEC TR 19791:2010
ASO_VER.1.1C Debe registrarse la información asociada con la verificación.
ASO_VER.1.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que
se dirige y resultados de la verificación.
ASO_VER.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.10.3.4 ASO_VER.2 Verificación independiente de los controles operacionales
Jerárquico a: ASO_VER.1 Verificación de los controles operacionales
ASO_VER.2.1M La dirección debe verificar que [selección: todos los controles operacionales o [asignación: controles
operacionales]] están instalados y operan correcta y eficazmente.
ASO_VER.2.1C Debe registrarse la información asociada con la verificación.
ASO_VER.2.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que se
dirige y resultados de la verificación.
ASO_VER.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASO_VER.2.2E El evaluador debe verificar independientemente que los controles operacionales están instalados
y operan correcta y eficazmente.
C.10.4 Monitorización de los controles operacionales (ASO_MON)
C.10.4.1 Objetivos
Esta familia ofrece medios para verificar los controles operacionales durante la operación. El propósito principal de la
monitorización del control operacional es permitir una determinación de que los controles operacionales están operando
de una forma segura, sin violación de las políticas de seguridad del sistema operacional. Los controles operacionales
deberían implantarse y operarse correcta y eficazmente de acuerdo con la política de seguridad del sistema operacional.
También define acciones que tendrán lugar cuando se produzcan cambios en los sistemas operacionales.

C.10.4.3 ASO_MON.1 Monitorización de los controles operacionales por parte de la dirección
ISO/IEC TR 19791:2010 - 168 -
ASO_MON.1.1M La dirección debe monitorizar las provisiones y niveles de rendimiento de [selección: todos los
controles operacionales o [asignación: controles operacionales]] periódicamente.
ASO_MON.1.2M La dirección debe monitorizar los cambios en las provisiones de servicios, incluyendo el
mantenimiento y mejora de las políticas, procedimientos y controles de seguridad, teniendo en cuenta la
criticidad de los sistemas y procesos de negocio implicados y la reevaluación de los riesgos.
ASO_MON.1.1C Debe registrarse la información asociada con la monitorización.
ASO_MON.1.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que
se dirige y resultados de la monitorización.
ASO_MON.1.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de
C.10.4.4 ASO_MON.2 Verificación de la monitorización de los controles operacionales
Jerárquico a: ASO_MON.1 Monitorización de los controles operacionales por parte de la dirección
ASO_MON.2.1M La dirección debe monitorizar las provisiones y niveles de rendimiento de [selección: todos los
controles operacionales o [asignación: controles operacionales]] periódicamente.
ASO_MON.2.2M La dirección debe monitorizar los cambios en las provisiones de servicios, incluyendo el
mantenimiento y mejora de las políticas, procedimientos y controles de seguridad, teniendo en cuenta la criticidad de
los sistemas y procesos de negocio implicados y la reevaluación de los riesgos.
ASO_MON.2.1C Debe registrarse la información asociada con la monitorización.
ASO_MON.2.2C Los registros deben contener día y hora, persona responsable, controles operacionales a los que se
dirige y resultados de la monitorización.
ASO_MON.2.1E El evaluador debe confirmar que la información ofrecida cumple con todos los requisitos de contenido
ASO_MON.2.2E El evaluador debe verificar independientemente que la monitorización se realiza de acuerdo

con la política de seguridad.
- 169 - ISO/IEC TR 19791:2010
ANEXO D (Normativo)
METODOLOGÍA DE EVALUACIÓN DEL SISTEMA OPERACIONAL
D.1 Aproximación técnica
D.1.1 Introducción
Este anexo está diseñado para usarse junto con la Norma ISO/IEC 18045. Define las subactividades y unidades de
trabajo concretas de evaluación requeridas para realizar la evaluación de un sistema operacional. Se aplican dentro de
un proceso de evaluación tal y como se describen en la Norma ISO/IEC 18045. Las demás tareas de evaluación
requeridas para realizar una evaluación de un sistema operacional son idénticas a las descritas en el capítulo del proceso
de evaluación bajo la Norma ISO/IEC 18045.
D.1.2 Aproximación a la documentación

La Norma ISO/IEC 18045 es un documento autónomo que repite y explica la estructura de los componentes de garantía
de la Norma ISO/IEC 15408-3, su ámbito y aplicabilidad. Este anexo usa una aproximación ligeramente distinta: ha de
leerse junto con el anexo C y la Norma ISO/IEC 18045. La información no se repite aquí, salvo que la relación con la
sección relevante de este anexo no sea evidente. Por ejemplo, el texto de los elementos de criterio no se repite, pero se
referencia cuando resulta pertinente. Cuando los métodos y aproximaciones de la Norma ISO/IEC 18045 sean
aplicables a esta metodología, se referencian, en lugar de repetirse.
Cada clase de garantía definida en el anexo C está soportada por un subcapítulo de metodología en este anexo. Cada
componente de cada familia dentro de esa clase se trata como una subactividad de evaluación distinta, con su propia
sección dentro del subcapítulo, detallando las unidades relacionadas de trabajo del evaluador. Cuando haya una relación
jerárquica entre componentes, las unidades de trabajo anteriores sin cambiar se referencian por componentes superiores
en lugar de repetirse. Para simplificar la estructura del documento, no se dan subencabezamientos individuales a las
unidades de trabajo.
D.1.3 Tipos de evidencia

La evidencia para apoyar la evaluación de las evidencias de los sistemas operacionales puede tomar formas adicionales
a las permitidas en la evaluación bajo la Norma ISO/IEC 15408. La mejor evidencia se obtiene por la observación
directa del evaluador; esto se aplica particularmente a funcionalidades de seguridad operacional, en las que una medida
podría documentarse, pero no usarse realmente en la práctica. Sin embargo, puede que no siempre sea factible verificar
medidas por observación directa.
También pueden establecerse evidencias viendo los resultados del rendimiento de medidas (registros de visitas, pistas
de auditoría, etc.). Finalmente, pueden obtenerse evidencias de la documentación del diseño de medidas y su enlace con
las políticas de seguridad. El examen de la documentación es particularmente útil para medidas técnicas de seguridad,
en las que si se diseña, prueba y luego instala correctamente una medida, probablemente sea eficaz en la práctica.
Todos los verbos de la unidad de trabajo que representan acciones obligatorias del evaluador vienes precedidos por el
verbo auxiliar debe y presentan tanto el verbo como el debe en tipo negrita cursiva. En algunos casos, el texto de guía
que acompaña a las unidades de trabajo recomienda un método o mecanismo para cómo realizar el trabajo. Se usa el
verbo auxiliar debería cuando se prefiere con mucho el método descrito. Todos los demás verbos auxiliares, incluyendo
puede, se usan cuando el método o métodos descritos se permiten pero ni se recomiendan ni se prefieren: es una mera
sugerencia.
En algunos casos, se pide al evaluador que verifique independientemente algún aspecto de la SSF, sin definir un meca-
nismo concreto de verificación. En estos casos, corresponde al evaluador seleccionar la forma de realizar la verifi-
cación. El valuador debería seleccionar un método que sea eficiente y eficaz, pero confía en que la SSF en cuestión se
aplique adecuadamente. El método elegido debería registrarse en el ETR.
ISO/IEC TR 19791:2010 - 170 -
D.2 Clase ASP: Evaluación del Perfil de Protección del Sistema
D.2.1 Introducción
El propósito de la evolución del Perfil de Protección del Sistema es confirmar que un SPP es una especificación com-
pleta y consistente de un tipo de STOE, y si referencia a otros SPP, PP o paquetes, que es una instanciación correcta de
esas especificaciones.
Hay once familias dentro de esta clase, ocupándose de distintos aspectos de la especificación del SPP. Las cinco últimas
se emplean para especificar aspectos concretos del dominio de los STOE consistentes con el SPP.
D.2.2 Introducción del SPP (ASP_INT)
D.2.2.1 Estructura de la familia

Esta familia contiene un componente, ASP_INT.1 Introducción del SPP.
D.2.2.2 Evaluación de la subactividad ASP_INT.1
D.2.2.2.1 Acción ASP_INT.1.1E

Esta acción requiere que el evaluador examine en la introducción del SPP su contenido y presentación y está compuesta
por siete unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito
relevante.
ASP_INT.1-1 El evaluador debe verificar que la introducción del SPP contiene una referencia al SPP, una visión
general del STOE y una especificación de la organización del dominio.
ASP_INT.1-2 El evaluador debe examinar la referencia del SPP para confirmar que identifica exclusivamente al
SPP.
ASP_INT.1-3 El evaluador debe examinar la visión general del STOE para confirmar que resume el uso y las
principales características de seguridad del STOE.
ASP_INT.1-4 El evaluador debe examinar la visión general del STOE para confirmar que identifica el tipo de
STOE.
El tipo de STOE puede ser “sistema operacional” o alguna definición más precisa.
ASP_INT.1-5 El evaluador debe examinar la visión general del STOE para confirmar que identifica las relaciones e
interfaces con cualesquiera sistemas operacionales externos del STOE.
La identificación debería permitir a cualquier lector de la introducción del SPP establecer qué sistemas operacionales
externos tienen interfaz con el STOE y por qué.
ASP_INT.1-6 El evaluador debe examinar la especificación de la organización del dominio para confirmar que
describe la organización de los dominios obligatorios de seguridad y su identificación.
Si el sistema operacional consta de un solo dominio, esta unidad de trabajo se satisface con una declaración de que hay
un solo dominio.
ASP_INT.1-7 El evaluador debe examinar la especificación de la organización del dominio para confirmar que, para
cada dominio, identifica cualquier servicio de seguridad ofrecido por el mismo que ha de estar disponible para otros y
cualquier propiedad de seguridad del dominio que ha de aplicarse a otros dominios.
un solo dominio.
- 171 - ISO/IEC TR 19791:2010
D.2.2.2.2 Acción ASP_INT.1.2E

Esta acción requiere que el evaluador busque inconsistencias en la introducción del SPP y está compuesta por una
unidad de trabajo. La acción fracasa si la unidad de trabajo no confirma el requisito relevante.
ASP_INT.1-8 El evaluador debe confirmar que la visión general del STOE y la especificación de la organización
del dominio son coherentes entre sí.
El evaluador debería buscar información en la especificación de la organización del dominio que sea inconsistente con
declaraciones de hecho en la visión general del STOE. Por ejemplo, si la visión general del STOE dice que el SPP
especifica sistemas con funciones contables, pero la especificación de la organización del dominio define solo dominios
que se ocupan de las instalaciones de automatización de oficinas, esto sería inconsistente.
D.2.3 Declaraciones de conformidad (ASP_CCL)

Esta familia contiene un componente, ASP_CCL.1 Declaraciones de conformidad.
D.2.3.2 Evaluación de la subactividad ASP_CCL.1
D.2.3.2.1 Acción ASP_CCL.1.1E

Esta acción requiere que el evaluador examine en la declaración de conformidad y la justificación de dicha declaración
de conformidad su contenido y presentación y está compuesta por diez unidades de trabajo. La acción fracasa si
cualquiera de las unidades de trabajo no confirma el requisito relevante.
ASP_CCL.1-1 El evaluador debe examinar la declaración de conformidad para confirmar que contiene una
declaración de conformidad con los criterios que identifica la versión de este informe técnico al que el SPP declara
conformidad.
ASP_CCL.1-2 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que describe la
conformidad funcional del SPP con este informe técnico, ya sea como TR 19791 funcionalmente conforme o como TR
19791 funcionalmente extendido.
ASP_CCL.1-3 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que describe la
conformidad de garantía del SPP con este informe técnico, ya sea como TR 19791 funcionalmente conforme o como
TR 19791 funcionalmente extendido.
ASP_CCL.1-4 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que es
coherente con la definición de componentes extendidos.
Si se definen componentes extendidos, entonces la declaración de conformidad de criterios debe ser extendida
funcionalmente o de garantía o ambas cosas.
ASP_CCL.1-5 El evaluador debe examinar la declaración de conformidad para confirmar que identifica todos los
SPP, PP y paquetes de requisitos de seguridad a los que el SPP declara conformidad.
El evaluador debería confirmar que cualesquiera SPP, PP y paquetes de requisitos de seguridad referenciados se
identifican de forma no ambigua y que no hay referencias no descriptivas a SPP, PP y paquetes de requisitos de
seguridad en la introducción de SPP que no estén listados aquí.
ASP_CCL.1-6 El evaluador debe examinar la declaración de conformidad para confirmar que describe cualquier
conformidad del SPP con un paquete ya sea como paquete conforme o como paquete aumentado.
ISO/IEC TR 19791:2010 - 172 -
Si el SPP no declara conformidad con ningún paquete, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha. En caso contrario, el evaluador debería verificar que las SSF y SSA definidas en el SPP son consistentes con
el tipo de conformidad declarada para cada paquete identificado.
ASP_CCL.1-7 El evaluador debe examinar la justificación de la declaración de conformidad para confirmar que
demuestra que el tipo de STOE es consistente con el tipo de STOE en los SPP y PP para los que se está declarando
conformidad.
Si el SPP no declara conformidad con ningún SPP o PP, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha. Para demostrar la consistencia, no es necesaria una relación directa entre los tipos de STOE, solo que no hay
contradicciones en la información suministrada.
demuestra que la declaración de la definición del problema de seguridad es consistente con la declaración de la
definición del problema de seguridad en los SPP y PP para los que se está declarando conformidad.
satisfecha. Si un SPP o PP que se ha referenciado no tiene ninguna definición de política de seguridad, se considera
consistente sin más exámenes.
demuestra que la declaración de objetivos es consistente con la declaración de objetivos en los SPP y PP para los que se
está declarando conformidad.
satisfecha. Si un SPP o PP que se ha referenciado no tiene ninguna declaración de objetivos de seguridad, se considera
demuestra que la declaración de requisitos de seguridad es consistente con la declaración de requisitos de seguridad en
los SPP y PP para los que se está declarando conformidad.
Si el SPP no declara conformidad con ningún SPP, PP o paquete, esta unidad de trabajo no es aplicable y por tanto se
considera satisfecha.
Si un SPP declara conformidad con un PP, la justificación de mostrar que las OSF están definidas para satisfacer las
suposiciones acerca del entorno operacional en la sección de la definición del problema de seguridad del PP.
D.2.4 Definición del problema de seguridad (ASP_SPD)

Esta familia contiene un componente, ASP_SPD.1 Definición del problema de seguridad.
D.2.4.2 Evaluación de la subactividad ASP_SPD.1
D.2.4.2.1 Acción ASP_SPD.1.1E

Esta acción requiere que el evaluador examine en la declaración de la definición del problema de seguridad su
contenido y presentación y está compuesta por tres unidades de trabajo. La acción fracasa si cualquiera de las unidades
de trabajo no confirma el requisito relevante.
ASP_SPD.1-1 El evaluador debe examinar la definición del problema de seguridad para confirmar que describe
todos los riesgos aplicables al STOE y que cada riesgo está categorizado como aceptable o inaceptable.
- 173 - ISO/IEC TR 19791:2010
Si todos los objetivos de seguridad derivan de políticas, no tendría que haber ninguna descripción de riesgos en el SPD.
En este caso, esta unidad de trabajo no es aplicable y por tanto se considera satisfecha.
Deberían identificarse los riesgos en una evaluación del riesgo y luego analizarse cada riesgo y categorizarse como
aceptable o inaceptable.
ASP_SPD.1-2 El evaluador debe examinar la definición del problema de seguridad para confirmar que todos los
riesgos inaceptables se describen en términos de amenazas y vulnerabilidades y que todas las amenazas se describen en
términos de agente de amenaza, activo y acción adversa.
Si todos los objetivos de seguridad derivan de políticas, o todos los riesgos se califican como aceptables, esta unidad de
trabajo no es aplicable y por tanto se considera satisfecha.
Los agentes de amenazas pueden describirse más, con detalles como experiencia, recursos, oportunidades y motivación.
ASP_SPD.1-3 El evaluador debe examinar la definición del problema de seguridad para confirmar que describe las
OSP.
Si todos los objetivos de seguridad derivan de amenazas, no tiene que haber ninguna descripción de las OSP en la SPD.
D.2.5 Objetivos de seguridad (ASP_OBJ)

Esta familia contiene un componente, ASP_OBJ.1 Objetivos de seguridad.
D.2.5.2 Evaluación de la subactividad ASP_OBJ.1
D.2.5.2.1 Acción ASP_OBJ.1.1E

Esta acción requiere que el evaluador examine en la declaración de objetivos de seguridad y en la justificación de
objetivos de seguridad su contenido y presentación y está compuesta por ocho unidades de trabajo. La acción fracasa si
ASP_OBJ.1-1 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe los
objetivos funcionales de seguridad del STOE.
ASP_OBJ.1-2 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe
cualquier objetivo funcional de seguridad que cumplan los sistemas operacionales externos.
Si los sistemas operacionales externos no cumplen ningún objetivo funcional de seguridad, esta unidad de trabajo no es
aplicable y por tanto se considera satisfecha.
Los objetivos de seguridad cumplidos por sistemas operacionales externos dejan de considerarse en la evaluación del
SPP, pero se validarán en cualquier evaluación del STOE.
ASP_OBJ.1-3 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe los
objetivos de garantía de seguridad del STOE.
ASP_OBJ.1-4 El evaluador debe examinar la justificación de los objetivos de seguridad para el STOE remontándose
a los riesgos afrontados por ese objetivo de seguridad u OSP aplicados para ese objetivo de seguridad.
Cada objetivo funcional de seguridad para el STOE puede remontarse a amenazas u OSP o a una combinación de
ambas, pero debe remontarse al menos a una amenaza u OSP.
ISO/IEC TR 19791:2010 - 174 -
ASP_OBJ.1-5 El evaluador debe examinar la justificación de los objetivos de seguridad para sistemas operacionales
externos remontándose a los riesgos afrontados por ese objetivo de seguridad u OSP aplicados para ese objetivo de
seguridad.
Cada objetivo funcional de seguridad para sistemas operacionales externos puede remontarse a amenazas u OSP o a una
combinación de ambas, pero debe remontarse al menos a una amenaza u OSP.
ASP_OBJ.1-6 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que
demuestra que los objetivos funcionales de seguridad contrarrestan todos los riesgos inaceptables.
Para cada riesgo inaceptable, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales de segu-
ridad que se remontan a ese riesgo, éste se elimina o mitiga hasta un nivel aceptable.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a un riesgo
inaceptable: si se alcanza el objetivo de seguridad, contribuye realmente a la eliminación o mitigación de ese riesgo.
Si hay algún riesgo inaceptable al que no se remonte un objetivo funcional de seguridad, se incumple esta unidad de
trabajo.
ASP_OBJ.1-7 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que
demuestra que los objetivos funcionales de seguridad aplican todas las OSP.
Para cada OSP, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales de seguridad que se
remontan a esa OSP, se está aplicando la OSP.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a una OSP: si se
alcanza el objetivo de seguridad, contribuye realmente a la aplicación de esa OSP.
Si hay alguna OSP a la que no se remonte un objetivo funcional de seguridad, se incumple esta unidad de trabajo.
ASP_OBJ.1-8 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que explica
por qué se han elegido los objetivos de garantía de seguridad.
El evaluador confirma que las razones por las que se eligieron los objetivos están incluidas. Sin embargo, no hace falta
justifica estas razones e incluso pueden indicarse como una elección arbitraria.
D.2.6 Definición de componentes extendidos (ASP_ECD)

Esta familia contiene un componente, ASP_ECD.1 Definición de componentes extendidos.
D.2.6.2 Evaluación de la subactividad ASP_ECD.1
D.2.6.2.1 Acción ASP_ECD.1.1E

Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad y en la definición de
componentes extendidos su contenido y presentación y está compuesta por cinco unidades de trabajo. La acción fracasa
si cualquiera de las unidades de trabajo no confirma el requisito relevante.
ASP_ECD.1-1 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que identifica
todos los requisitos extendidos de seguridad.
- 175 - ISO/IEC TR 19791:2010
El evaluador debería verificar que todos los requisitos de seguridad no identificados como requisitos extendidos de
seguridad se basan en componentes de la Norma ISO/IEC 15408 o de este informe técnico.
ASP_ECD.1-2 El evaluador debe examinar la definición de componentes extendidos para confirmar que define un
componente extendido por cada requisito extendido de seguridad.
El evaluador debería verificar que todos los requisitos de seguridad identificados como requisitos extendidos de
seguridad se basan en componentes definidos en la definición de componentes extendidos.
Si el SPP no contiene requisitos extendidos de seguridad, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha.
ASP_ECD.1-3 El evaluador debe examinar la definición de componentes extendidos para confirmar que describe
cómo cada componente extendido se relaciona con los componentes, familias y clases existentes en la Norma
satisfecha.
ASP_ECD.1-4 El evaluador debe examinar la definición de componentes extendidos para confirmar que cada
definición utiliza los componentes, familias y clases existentes en la Norma ISO/IEC 15408 o este informe técnico
como modelo de presentación.
satisfecha.
Si una definición de un componente extendido no sigue el modelo de presentación de la Norma ISO/IEC 15408 de una
forma que impida que se aplique esta metodología a su uso, se incumple esta unidad de trabajo. También se incumple
esta unidad de trabajo si se define un componente extendido de una forma que sea incoherente con la relación declarada
con los componentes, familias y clases existentes.
ASP_ECD.1-5 El evaluador debe examinar la definición de componentes extendidos para confirmar que cada
componente extendido consiste en elementos medibles y objetivos de forma que pueda demostrarse el cumplimiento o
incumplimiento de estos elementos.
satisfecha.
El evaluador debería determinar si los requisitos basados en cada definición de un componente extendido pueden
evaluarse sin juicios subjetivos del evaluador.
D.2.6.2.2 Acción ASP_ECD.1.2E

Esta acción requiere que el evaluador demuestre que ningún componente extendido en la definición de componentes
extendidos duplica los componentes existentes y está compuesta por una unidad de trabajo. La acción fracasa si la
unidad de trabajo no confirma el requisito relevante.
ASP_ECD.1-6 El evaluador debe confirmar que ningún componente extendido pueda expresarse claramente
satisfecha.
Al llevar a cabo esta verificación, el evaluador debería tener en cuenta componentes de la Norma ISO/IEC 15408, este
informe técnico y otros componentes extendidos definidos en el SPP, incluyendo refinados, sustituciones y combina-
ciones de componentes. Esta verificación no debería ser exhaustiva, bastando con detectar y excluir complicaciones
innecesarias, si los requisitos pueden expresarse claramente utilizando otros componentes.
ISO/IEC TR 19791:2010 - 176 -
D.2.7 Requisitos de seguridad (ASP_REQ)

Esta familia contiene dos componentes, ASP_REQ.1 Requisitos de seguridad declarados y ASP_REQ.1 Requisitos de
seguridad derivados.
D.2.7.2 Evaluación de la subactividad ASP_REQ.1
D.2.7.2.1 Acción ASP_REQ.1.1E

Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad y en la justificación de
requisitos de seguridad su contenido y presentación y está compuesta por seis unidades de trabajo. La acción fracasa si
ASP_REQ.1-1 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que describe las
SSF y las SSA.
Las SSF y SSA pueden incluirse en el SPP por referencia a un SPP, PP o paquete, así como declararse explícitamente.
ASP_REQ.1-2 El evaluador debe examinar el SPP para confirmar que define todos los sujetos, objetos, operaciones,
atributos de seguridad, entidades externas y otros términos que se usen en las SSF y las SSA.
El objetivo de esta unidad de trabajo es asegurar que los SFR y SAR están bien definidos y que no puede producirse
ningún error de comprensión debido al uso de términos vagos. Esta unidad de trabajo no debería llevarse a su extremo,
obligando al escritor del SPP a definir todas las palabras. Los términos pueden definirse dentro de la declaración de
requisitos de seguridad, pero también puede definirse en otro lugar del SPP.
ASP_REQ.1-3 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que identifica
todas las operaciones en los requisitos de seguridad.
La identificación puede hacerse mediante distinciones tipográficas o por identificación explícita en el texto que la rodea
o por cualquier otro medio distintivo.
ASP_REQ.1-4 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que identifica
que todas las operaciones se realizan correctamente.
Esto se aplica a las operaciones de asignación, selección, iteración y refinado especificadas en la Norma
ISO/IEC 15408.
ASP_REQ.1-5 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que cada
dependencia entre requisitos de seguridad se satisface o se justifica como no satisfecha.
Una dependencia se satisface por la inclusión del componente relevante (o uno que sea jerárquico a él) dentro de la
declaración de requisitos de seguridad. El componente utilizado para satisfacer la dependencia debería, si es necesario,
ser modificado por operaciones para garantizar que realmente satisface esa dependencia.
Ésta es la única función para la justificación de los requisitos de seguridad para este miembro de la familia de requisitos
de seguridad. Una simple lista que muestre cómo se satisface cada dependencia o la identifica explícitamente como “no
satisfecha” es suficiente para satisfacer esta unidad de trabajo: no hace falta mayor justificación.
ASP_REQ.1-6 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que es coherente
internamente.
El evaluador debería determinar si en todas las ocasiones en que se aplican distintos requisitos de seguridad a los
mismos tipos de evidencias del desarrollador, eventos, operaciones, datos, pruebas a realizar, etc. o a “todos los obje-
tos”, “todos los sujetos”, etc., que estos requisitos no entran en conflicto.
- 177 - ISO/IEC TR 19791:2010
D.2.7.3 Evaluación de la subactividad ASP_REQ.2
D.2.7.3.1 Acción ASP_REQ.1.2E

requisitos de seguridad su contenido y presentación y está compuesta por diez unidades de trabajo, de la ASP_REQ.2-1
a la ASP_REQ.2-10. Las unidades ASP_REQ.2-1 a ASP_REQ.2-4 son idénticas a ASP_REQ.1-1 a ASP_REQ.1-4
respectivamente. La unidad de trabajo ASP_REQ.2-10 es idéntica la unidad de trabajo ASP_REQ.1-6.
La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito relevante.
ASP_REQ.2-5 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que cada
Esta unidad de trabajo es idéntica en su especificación a la ASP_REQ.1-5. Sin embargo, si no se satisface una
dependencia, la justificación debería explicar, refiriéndose a los objetivos de seguridad o a otra cosa, por qué dicha
dependencia no es necesaria o útil.
ASP_REQ.2-6 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que remonta
cada SSF a los objetivos funcionales de seguridad del STOE.
El evaluador debería determinar que cada SSF se remonta al menos a un objetivo funcional de seguridad del STOE. No
poder remontar implica que, o la justificación de requisitos de seguridad está incompleta, los objetivos de seguridad del
STOE son incompletos o la SSF no tiene ningún fin útil.
ASP_REQ.2-7 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra
que las SSF cumplen con todos los objetivos funcionales de seguridad del STOE que no cumplan los sistemas externos
o dominios individuales.
Si hay un objetivo funcional de seguridad del STOE al que no se remonta ninguna SSF y no se identifica como
cumplido por sistemas externos o dominios individuales, se incumple esta unidad de trabajo.
El evaluador debería determinar que las SSF son suficientes: si se satisfacen todas las SSF que se remonten a cada
objetivo, entonces se cumple ese objetivo funcional de seguridad del STOE.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad del STOE
es necesaria: cuando se satisface la SSF, contribuye realmente a alcanzar el objetivo de seguridad.
ASP_REQ.2-8 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que remonta
cada SSA a los objetivos de garantía de seguridad del STOE.
El evaluador debería determinar que cada SSA se remonta al menos a un objetivo de garantía de seguridad del STOE.
No poder remontar implica que, o la justificación de requisitos de seguridad está incompleta, los objetivos de seguridad
del STOE son incompletos o la SSA no tiene ningún fin útil.
ASP_REQ.2-9 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra
que las SSA cumplen con todos los objetivos de garantía de seguridad del STOE que no cumplan los dominios
individuales.
Si hay un objetivo de garantía de seguridad del STOE al que no se remonta ninguna SSA y no se identifica como
cumplido por dominios individuales, se incumple esta unidad de trabajo.
El evaluador debería determinar que las SSA son suficientes: si se satisfacen todas las SSA que se remonten a cada
objetivo, entonces se cumple ese objetivo de garantía de seguridad del STOE.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad del
STOE es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
ISO/IEC TR 19791:2010 - 178 -
D.2.8 Introducción del dominio de seguridad (ASP_DMI)

Esta familia contiene un componente, ASP_DMI.1 Introducción al dominio de seguridad.
D.2.8.2 Evaluación de la subactividad ASP_DMI.1
D.2.8.2.1 Acción ASP_DMI.1.1E

Esta acción requiere que el evaluador examine en cada introducción del dominio de seguridad su contenido y presen-
tación y está compuesta por cinco unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
confirma el requisito relevante.
ASP_DMI.1-1 El evaluador debe verificar que la introducción del dominio de seguridad contiene una referencia, una
visión general y una descripción del dominio de seguridad.
ASP_DMI.1-2 El evaluador debe examinar la referencia del dominio de seguridad para confirmar que identifica de
forma única el dominio de seguridad.
ASP_DMI.1-3 El evaluador debe examinar la visión general del dominio de seguridad para confirmar que resume el
uso y las principales características de seguridad del dominio de seguridad.
ASP_DMI.1-4 El evaluador debe examinar la descripción del dominio de seguridad para confirmar que identifica los
subsistemas incluidos o los componentes.
La identificación debería permitir a cualquier lector de la introducción del dominio de seguridad establecer la relación
entre este dominio de seguridad y los subsistemas/componentes desde los que deben construirse los sistemas
operaciones que se correspondan con el SPP.
ASP_DMI.1-5 El evaluador debe examinar la descripción del dominio de seguridad para confirmar que identifica las
relaciones e interfaces con otros dominios.
entre este dominio de seguridad y otros.
D.2.8.2.2 Acción ASP_DMI.1.2E

Esta acción requiere que el evaluador busque inconsistencias dentro de la introducción del dominio de seguridad y está
compuesta por una unidad de trabajo.
ASP_DMI.1-6 El evaluador debe confirmar que la referencia, la visión general y la descripción del dominio de
seguridad son consistentes entre sí y con la introducción del SPP.
El evaluador debería mirar una por una cada especificación para identificar información que sea inconsistente con
declaraciones de hechos en las demás especificaciones. Por ejemplo, si la especificación de la organización del dominio
en la introducción del SPP dice que este dominio tiene dos interfaces con otros dominios, pero la descripción del
dominio de seguridad define tres, esto sería inconsistente.
D.2.9 Declaraciones de conformidad del dominio de seguridad (ASP_DMC)

Esta familia contiene un componente, ASP_DMC.1 Declaraciones de conformidad del dominio de seguridad.
- 179 - ISO/IEC TR 19791:2010
D.2.9.2 Evaluación de la subactividad ASP_DMC.1
D.2.9.2.1 Acción ASP_DMC.1.1E

Esta acción requiere que el evaluador examine en cada declaración de conformidad del dominio y justificación de las
declaraciones de conformidad del dominio su contenido y presentación y está compuesta por seis unidades de trabajo.
ASP_DMC.1-1 El evaluador debe examinar la declaración de conformidad del dominio para confirmar que identifica
todos los SPP, PP y paquetes de requisitos de seguridad a los que el dominio declara conformidad.
El evaluador debería confirmar que cualquier SPP, PP y paquete de requisitos de seguridad referenciado se identifica
sin ambigüedades y que no hay referencias descriptivas a SPP, PP y paquetes de requisitos de seguridad en la introduc-
ción del dominio que no estén aquí listados.
ASP_DMC.1-2 El evaluador debe examinar la declaración de conformidad del dominio para confirmar que describe
cualquier conformidad del dominio con un paquete ya sea como paquete conforme o como paquete aumentado.
Si el dominio no declara conformidad con ningún paquete, esta unidad de trabajo no es aplicable y por tanto se con-
sidera satisfecha. En caso contrario, el evaluador debería verificar que las SSF y SSA definidas en el SPP son consis-
tentes con el tipo de conformidad declarada para cada paquete identificado.
ASP_DMC.1-3 El evaluador debe examinar la justificación de las declaraciones de conformidad del dominio para
confirmar que demuestra que el tipo de STOE es consistente con el tipo de STOE en los SPP y PP para los que se está
declarando conformidad.
Si el dominio no declara conformidad con ningún SPP o PP, esta unidad de trabajo no es aplicable y por tanto se
considera satisfecha. Para demostrar la consistencia, no es necesaria una relación directa entre los tipos de STOE, solo
que no hay contradicciones en la información suministrada.
confirmar que demuestra que la declaración de la definición del problema de seguridad del dominio es consistente con
la declaración de la definición del problema de seguridad en los SPP y PP para los que se está declarando conformidad.
Si el dominio no declara conformidad con ningún SPP o PP, esta unidad de trabajo no es aplicable y por tanto se
considera satisfecha. Si un SPP o PP que se ha referenciado no tiene ninguna definición de política de seguridad, se
considera consistente sin más exámenes.
confirmar que demuestra que la declaración de objetivos de seguridad del dominio es consistente con la declaración de
objetivos en los SPP y PP para los que se está declarando conformidad.
satisfecha. Si un SPP o PP que se ha referenciado no tiene ninguna declaración de objetivos de seguridad, se considera
confirmar que demuestra que la declaración de requisitos de seguridad del dominio es consistente con la declaración de
requisitos de seguridad en los SPP, PP y paquetes para los que se está declarando conformidad.
Si el dominio no declara conformidad con ningún SPP, PP o paquete, esta unidad de trabajo no es aplicable y por tanto
se considera satisfecha.
ISO/IEC TR 19791:2010 - 180 -
D.2.10 Definición del problema de seguridad del dominio de seguridad (ASP_DMP)

Esta familia contiene un componente, ASP_DMP.1 Definición del problema de seguridad del dominio de seguridad.
D.2.10.2 Evaluación de la subactividad ASP_DMP.1
D.2.10.2.1 Acción ASP_DMP.1.1E

Esta acción requiere que el evaluador examine en cada definición del problema de seguridad del dominio su contenido y
presentación y está compuesta por tres unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
ASP_DMP.1-1 El evaluador debe examinar la definición del problema de seguridad del dominio para confirmar que
describe todos los riesgos únicos aplicables al dominio y que cada riesgo está categorizado como aceptable o inaceptable.
Si todos los objetivos de seguridad derivan de políticas, no tendría que haber ninguna descripción de riesgos en el SPD
del dominio. En este caso, esta unidad de trabajo no es aplicable y por tanto se considera satisfecha.
todos los riesgos inaceptables se describen en términos de amenazas y vulnerabilidades y que todas las amenazas se
describen en términos de agente de amenaza, activo y acción adversa.
describe las OSP únicas aplicables al dominio.
Si todos los objetivos de seguridad derivan de amenazas, no tiene que haber ninguna descripción de las OSP en la SPD
D.2.11 Objetivos de seguridad del dominio de seguridad (ASP_DMO)

Esta familia contiene un componente, ASP_DMO.1 Objetivos de seguridad del dominio de seguridad.
D.2.11.2 Evaluación de la subactividad ASP_DMO.1
D.2.11.2.1 Acción ASP_DMO.1.1E
Esta acción requiere que el evaluador examine en cada declaración de objetivos de seguridad del dominio y en la
justificación de objetivos de seguridad del dominio su contenido y presentación y está compuesta por nueve unidades de
trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito relevante.
ASP_DMO.1-1 El evaluador debe examinar la declaración de objetivos de seguridad del dominio para confirmar que
describe los objetivos de seguridad funcional únicos para el dominio.
Si no hay objetivos funcionales de seguridad para el dominio, esta unidad de trabajo no es aplicable y por tanto se
- 181 - ISO/IEC TR 19791:2010
describe cualquier objetivo funcional de seguridad que cumplan otros dominios o sistemas operacionales externos.
Si no hay objetivos funcionales de seguridad para el dominio o sistemas operacionales externos, esta unidad de trabajo
no es aplicable y por tanto se considera satisfecha.
El evaluador debería verificar que los objetivos funcionales de seguridad cumplidos por otros dominios se describen en
las declaraciones de objetivos de seguridad del dominio para otros dominios como aplicados o disponibles en otros
dominios.
Los objetivos de seguridad cumplidos por sistemas operacionales externos no se consideran más en la evaluación del
STOE, pero se validarán en la evaluación del SST.
describe los objetivos de garantía de seguridad únicos del dominio.
Si no hay objetivos de garantía de seguridad para el dominio, esta unidad de trabajo no es aplicable y por tanto se
describe todos los objetivos de seguridad del dominio que son aplicables o están disponibles en otros dominios.
Es aceptable para objetivos ser aplicados o estar disponibles para otros dominios sin que otros dominios hagan uso de
esos objetivos.
ASP_DMO.1-5 El evaluador debe examinar la justificación de los objetivos de seguridad del dominio para conformar
que traza cada objetivo único funcional de seguridad para el dominio remontándose a los riesgos afrontados por ese
objetivo de seguridad u OSP aplicados para ese objetivo de seguridad.
Cada objetivo funcional de seguridad para el dominio puede remontarse a amenazas u OSP o a una combinación de
ASP_DMO.1-6 El evaluador debe examinar la justificación de los objetivos de seguridad del dominio para confirmar
Si no hay objetivos funcionales de seguridad para otros dominios, esta unidad de trabajo no es aplicable y por tanto se
Cada objetivo funcional de seguridad para otros dominios puede remontarse a amenazas u OSP o a una combinación de
ASP_DMO.1-7 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que
demuestra que los objetivos funcionales de seguridad contrarrestan todos los riesgos inaceptables únicos del dominio.
Si no hay objetivos funcionales de seguridad ni riesgos inaceptables únicos para el dominio, esta unidad de trabajo no es
Para cada riesgo inaceptable único del dominio, el evaluador debería confirmar que si se alcanzan todos los objetivos
funcionales de seguridad que se remontan a ese riesgo, éste se elimina o mitiga hasta un nivel aceptable.
ISO/IEC TR 19791:2010 - 182 -
inaceptable único del dominio: si se alcanza el objetivo de seguridad, contribuye realmente a la eliminación o mitiga-
ción de ese riesgo.
Si hay algún riesgo inaceptable único del dominio al que no se remonte un objetivo funcional de seguridad, se incumple
esta unidad de trabajo.
que demuestra que los objetivos funcionales de seguridad aplican todas las OSP únicas del dominio.
Si no hay objetivos funcionales de seguridad ni OSP únicas para el dominio, esta unidad de trabajo no es aplicable y por
tanto se considera satisfecha.
Para cada OSP única para el dominio, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales
de seguridad que se remontan a esa OSP, se está aplicando la OSP.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a una OSP única
para el dominio: si se alcanza el objetivo de seguridad, contribuye realmente a la aplicación de esa OSP.
Si hay alguna OSP única para el dominio a la que no se remonte un objetivo funcional de seguridad, se incumple esta
unidad de trabajo.
que explica por qué se han elegido los objetivos de garantía de seguridad para el dominio.
Si no hay objetivos de garantía de seguridad únicos para el dominio, esta unidad de trabajo no es aplicable y por tanto se
justificar estas razones e incluso pueden indicarse como una elección arbitraria.
D.2.11.2.2 Acción ASP_DMO.1.2E

Esta acción requiere que el evaluador busque inconsistencias entre cada declaración de objetivos de seguridad del
dominio y la introducción del SPP y está compuesta por una unidad de trabajo.
ASP_DMO.1-10 El evaluador debe confirmar que la declaración de objetivos de seguridad del dominio es consistente
con la especificación de la organización del dominio.
El evaluador debería mirar una por una cada especificación para identificar información que sea inconsistente con de-
claraciones de hechos en las demás especificaciones. Por ejemplo, si la especificación de la organización del dominio
dice todos los dominios son independientes, pero la declaración de objetivos de seguridad del dominio muestra que
algunos objetivos se cumplen mediante otros dominios, esto sería inconsistente.
D.2.12 Requisitos de seguridad del dominio de seguridad (ASP_DMR)

Esta familia contiene dos componentes, ASP_DMR.1 Requisitos de seguridad del dominio declarados y ASP_DMR.2
Requisitos de seguridad del dominio derivados.
D.2.12.2 Evaluación de la subactividad ASP_DMR.1
D.2.12.2.1 Acción ASP_DMR.1.1E

Esta acción requiere que el evaluador examine en cada declaración de requisitos de seguridad del dominio y justifi-
cación de requisitos de seguridad del dominio su contenido y presentación y está compuesta por seis unidades de
- 183 - ISO/IEC TR 19791:2010
ASP_DMR.1-1 El evaluador debe examinar la declaración de requisitos de seguridad del dominio para confirmar que
describe las SSF y las SSA únicas aplicables al dominio.
Las SSF y SSA pueden incluirse en la especificación del dominio por referencia a un SPP, PP o paquete, así como
declararse explícitamente.
ASP_DMR.1-2 El evaluador debe examinar el SPP para confirmar que define todos los sujetos, objetos, operaciones,
atributos de seguridad, entidades externas y otros términos que se usen en las SSF y las SSA aplicables al dominio.
El objetivo de esta unidad de trabajo es asegurar que los SFR y SAR del dominio están bien definidos y que no puede
producirse ningún error de comprensión debido al uso de términos vagos. Esta unidad de trabajo no debería llevarse a
su extremo, obligando al escritor del SPP a definir todas las palabras. Los términos pueden definirse dentro de la
declaración de requisitos de seguridad, pero también pueden definirse en otro lugar del SPP.
identifica todas las operaciones en los requisitos de seguridad.
todas las operaciones se realizan correctamente.
ISO/IEC 15408.
ASP_DMR.1-5 El evaluador debe examinar la justificación de requisitos de seguridad del dominio para confirmar
que cada dependencia entre requisitos de seguridad se satisface o se justifica como no satisfecha.
declaración de requisitos de seguridad del dominio. El componente utilizado para satisfacer la dependencia debería, si
es necesario, ser modificado por operaciones para garantizar que realmente satisface esa dependencia.
Ésta es la única función para la justificación de los requisitos de seguridad del dominio para este miembro de la familia
de requisitos de seguridad. Una simple lista que muestre cómo se satisface cada dependencia o la identifica explícita-
mente como “no satisfecha” es suficiente para satisfacer esta unidad de trabajo: no hace falta mayor justificación.
es coherente internamente.
El evaluador debería determinar si en todas las ocasiones en que se aplican distintos requisitos de seguridad a los mis-
mos tipos de evidencias del desarrollador, eventos, operaciones, datos, pruebas a realizar, etc. o a “todos los objetos”,
“todos los sujetos”, etc., que estos requisitos no entran en conflicto.
D.2.12.3 Evaluación de la subactividad ASP_DMR.2
D.2.12.3.1 Acción ASP_DMR.2.1E
Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad del dominio y en la
justificación de requisitos de seguridad del dominio su contenido y presentación y está compuesta por doce unidades de
trabajo, de la ASP_DMR.2-1 a la ASP_DMR.2-12. Las unidades de trabajo ASP_DMR.2-1 a ASP_DMR.2-4 son
idénticas a ASP_DMR.1-1 a ASP_DMR.1-4 respectivamente. La unidad de trabajo ASP_DMR.2-12 es idéntica la
unidad de trabajo ASP_DMR.1-6.
ISO/IEC TR 19791:2010 - 184 -
Esta unidad de trabajo es idéntica en su especificación a la ASP_DMR.1-5. Sin embargo, si no se satisface una
que remonta cada SSF a los objetivos funcionales de seguridad del dominio.
Si no hay requisitos funcionales de seguridad para el dominio, esta unidad de trabajo no es aplicable y por tanto se
El evaluador debería determinar que cada SSF se remonta al menos a un objetivo funcional de seguridad del dominio.
No poder remontar implica que, o la justificación de requisitos de seguridad del dominio está incompleta, los objetivos
de seguridad del dominio son incompletos o la SSF no tiene ningún fin útil.
que demuestra que las SSF del dominio cumplen con todos los objetivos funcionales de seguridad del dominio que no
cumplan otros dominios o sistemas externos.
Si no hay requisitos funcionales de seguridad únicos ni objetivos funcionales de seguridad del dominio, esta unidad de
Si hay un objetivo funcional de seguridad del dominio al que no se remonta ninguna SSF y no se cumple por otros
dominios o sistemas externos, se incumple esta unidad de trabajo.
objetivo, entonces se cumple ese objetivo funcional de seguridad del dominio.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad del
dominio es necesaria: cuando se satisface la SSF, contribuye realmente a alcanzar el objetivo de seguridad.
que demuestra que las SSF del dominio cumplen todos los objetivos funcionales de seguridad del STOE que estén
identificados en la justificación de requisitos de seguridad para el STOE completo que cumplan los dominios
individuales.
Si no hay requisitos funcionales de seguridad únicos para el dominio ni objetivos funcionales de seguridad para la
totalidad del STOE que hayan de cumplir dominios individuales, esta unidad de trabajo no es aplicable y por tanto se
Si hay un objetivo funcional de seguridad para todo el STOE que hayan de cumplir dominios individuales a los que no
se remonte ninguna SSF del dominio, se incumple esta unidad de trabajo.
objetivo del STOE que hayan de cumplir dominios individuales, entonces se cumple ese objetivo funcional de seguridad
para todo el STOE.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad para todo
el STOE que hayan de cumplir dominios individuales es necesaria: cuando se satisface la SSF, contribuye realmente a
alcanzar el objetivo de seguridad.
que remonta cada SSA a los objetivos de garantía de seguridad del dominio.
- 185 - ISO/IEC TR 19791:2010
Si no hay requisitos de garantía de seguridad únicos para el dominio, esta unidad de trabajo no es aplicable y por tanto
El evaluador debería determinar que cada SSA se remonta al menos a un objetivo de garantía de seguridad del dominio.
del dominio son incompletos o la SSA no tiene ningún fin útil.
que demuestra que las SSA cumplen todos los objetivos de garantía de seguridad únicos del dominio.
Si no hay requisitos de garantía de seguridad únicos ni objetivos de garantía de seguridad para el dominio, esta unidad
de trabajo no es aplicable y por tanto se considera satisfecha.
Si hay algún objetivo de garantía de seguridad para el dominio al que no pueda remontarse ninguna SSA, se incumple
objetivo, entonces se cumple ese objetivo de garantía de seguridad para el dominio.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad para el
dominio es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
ASP_DMR.2-11 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra
que las SSA del dominio cumplen con todos los objetivos de garantía de seguridad del STOE se identifican en la
justificación de requisitos de seguridad para todo el STOE que hayan de cumplir dominios individuales.
Si no hay requisitos de garantía de seguridad únicos ni objetivos de garantía de seguridad para todo el STOE que hayan
de cumplir dominios individuales, esta unidad de trabajo no es aplicable y por tanto se considera satisfecha.
Si hay algún objetivo de garantía de seguridad para todo el STOE que hayan de cumplir dominios individuales al que no
pueda remontarse ninguna SSA, se incumple esta unidad de trabajo.
objetivo para todo el STOE que hayan de cumplir dominios individuales, entonces se cumple ese objetivo de garantía de
seguridad para todo el STOE.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad para
todo el STOE es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
D.3 Clase ASS: Evaluación del Objetivo de Seguridad del Sistema
D.3.1 Introducción
El propósito de la evolución del Objetivo de Seguridad del Sistema es confirmar que un SST es una especificación com-
pleta y consistente de las propiedades de seguridad del STOE al que representa, y si referencia a otros SPP, PP o paque-
tes, que es una instanciación correcta de esas especificaciones.
Hay trece familias dentro de esta clase, ocupándose de distintos aspectos de la especificación del SST. Las seis últimas
se emplean para evaluar aspectos concretos del dominio de los STOE consistentes para cada dominio dentro del STOE.
D.3.2 Introducción del SST (ASS_INT)

Esta familia contiene un componente, ASS_INT.1 Introducción del SST.
ISO/IEC TR 19791:2010 - 186 -
D.3.2.2 Evaluación de la subactividad ASS_INT.1
D.3.2.2.1 Acción ASS_INT.1.1E

Esta acción requiere que el evaluador examine en la introducción del SST su contenido y presentación y está compuesta
por once unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito
relevante.
ASS_INT.1-1 El evaluador debe verificar que la introducción del SST contiene una referencia al SST, una referencia
al STOE, una visión general del STOE, una decripción del STOE y una especificación de la organización del dominio.
ASS_INT.1-2 El evaluador debe examinar la referencia del SST para confirmar que identifica exclusivamente al
SST.
ASS_INT.1-3 El evaluador debe examinar la referencia del STOE para confirmar que identifica exclusivamente al
STOE.
Esto incluye identificar la versión del STOE que corresponde a esta versión del SST, si puede existir más de una versión
ASS_INT.1-4 El evaluador debe examinar la visión general del STOE para confirmar que resume el uso y las
principales características de seguridad del STOE.
ASS_INT.1-5 El evaluador debe examinar la visión general del STOE para confirmar que identifica el tipo de
STOE.
El tipo de STOE puede ser “sistema operacional” o alguna definición más precisa.
ASS_INT.1-6 El evaluador debe examinar la visión general del STOE para confirmar que identifica las relaciones e
interfaces con cualesquiera sistemas operacionales externos requeridos por el STOE.
La identificación debería permitir a cualquier lector de la introducción del SST establecer qué sistemas operacionales
externos tienen interfaz con el STOE y por qué.
ASS_INT.1-7 El evaluador debe examinar la descripción del STOE para confirmar que describe el ámbito físico del
STOE.
La descripción debería establecer los límites físicos del STOE de forma que quede claro si activos físicos concretos
forman parte del STOE o no.
ASS_INT.1-8 El evaluador debe examinar la descripción del STOE para confirmar que describe el ámbito lógico
del STOE.
La descripción debería establecer los límites lógicos del STOE de forma que quede claro si funciones o procedimientos
concretos forman parte del STOE o no.
ASS_INT.1-9 El evaluador debe examinar la descripción del STOE para confirmar que identifica los entornos de
desarrollo para el STOE, incluyendo cualesquiera características únicas de los entornos de desarrollo de cada dominio
individual.
La descripción debería identificar aquellas partes del desarrollo del STOE que tengan lugar fuera del sistema operacio-
nal. Normalmente los sistemas operacionales incluyen productos y aplicaciones producidos por partes externas y éstos
pueden integrarse juntos en un entorno de desarrollo distinto del entorno del sistema operacional.
ASS_INT.1-10 El evaluador debe examinar la especificación de la organización del dominio para confirmar que
describe la organización de los dominios de seguridad construidos y la identificación y ámbito físico de cada dominio
de seguridad.
- 187 - ISO/IEC TR 19791:2010
un solo dominio.
ASS_INT.1-11 El evaluador debe examinar la especificación de la organización del dominio para confirmar que, para
cada dominio, identifica cualquier servicio de seguridad ofrecido por el mismo que ha de estar disponible para otros y
cualquier propiedad de seguridad del dominio que ha de aplicarse a otros dominios.
un solo dominio.
D.3.2.2.2 Acción ASS_INT.1.2E

Esta acción requiere que el evaluador busque inconsistencias en la introducción del SST y está compuesta por una
unidad de trabajo. La acción fracasa si la unidad de trabajo no confirma el requisito relevante.
ASS_INT.1-12 El evaluador debe confirmar que la referencia del STOE, la visión general del STOE y la especifi-
cación de la organización del dominio son coherentes entre sí.
El evaluador debería buscar información en cada ítem que sea inconsistente con declaraciones de hecho en otras partes.
Por ejemplo, si la visión general del STOE dice que el SPP especifica que el sistema tiene funciones contables, pero la
especificación de la organización del dominio define solo dominios que se ocupan de las instalaciones de automatiza-
ción de oficinas, esto sería inconsistente.
D.3.3 Declaraciones de conformidad (ASS_CCL)

Esta familia contiene un componente, ASS_CCL.1 Declaraciones de conformidad.
D.3.3.2 Evaluación de la subactividad ASS_CCL.1
D.3.3.2.1 Acción ASS_CCL.1.1E

Esta acción requiere que el evaluador examine en la declaración de conformidad y la justificación de declaraciones de
conformidad su contenido y presentación y está compuesta por diez unidades de trabajo. La acción fracasa si cualquiera
de las unidades de trabajo no confirma el requisito relevante.
ASS_CCL.1-1 El evaluador debe examinar la declaración de conformidad para confirmar que contiene una
declaración de conformidad con los criterios que identifica la versión de este informe técnico al que el SST y el STOE
declaran conformidad.
ASS_CCL.1-2 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que describe la
conformidad funcional del SST con este informe técnico, ya sea como TR 19791 funcionalmente conforme o como TR
19791 funcionalmente extendido.
ASS_CCL.1-3 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que describe la
conformidad de garantía del SST con este informe técnico, ya sea como TR 19791 funcionalmente conforme o como
TR 19791 funcionalmente extendido.
ASS_CCL.1-4 El evaluador debe examinar la declaración de conformidad de criterios para confirmar que es
coherente con la definición de componentes extendidos.
Si se definen componentes extendidos, entonces la declaración de conformidad de criterios debe ser extendida
funcionalmente o de garantía o ambas cosas.
ASS_CCL.1-5 El evaluador debe examinar la declaración de conformidad para confirmar que identifica todos los
SPP, PP, ST y paquetes de requisitos de seguridad a los que el SST declara conformidad.
ISO/IEC TR 19791:2010 - 188 -
El evaluador debería confirmar que cualesquiera SPP, PP, ST y paquetes de requisitos de seguridad referenciados se
identifican de forma no ambigua y que no hay referencias no descriptivas a SPP, PP, ST y paquetes de requisitos de
seguridad en la introducción del SST que no estén listados aquí.
ASS_CCL.1-6 El evaluador debe examinar la declaración de conformidad para confirmar que describe cualquier
conformidad del SST con un paquete ya sea como paquete conforme o como paquete aumentado.
Si el SST no declara conformidad con ningún paquete, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha. En caso contrario, el evaluador debería verificar que las SSF y SSA definidas en el SST son consistentes con
el tipo de conformidad declarada para cada paquete identificado.
ASS_CCL.1-7 El evaluador debe examinar la justificación de la declaración de conformidad para confirmar que demues-
tra que el tipo de STOE es consistente con el tipo de STOE en los SPP, PP y ST para los que se está declarando conformidad.
Si el SST no declara conformidad con ningún SPP, PP o ST, esta unidad de trabajo no es aplicable y por tanto se
ASS_CCL.1-8 El evaluador debe examinar la justificación de la declaración de conformidad para confirmar que
demuestra que la declaración de la definición del problema de seguridad es consistente con la declaración de la
definición del problema de seguridad en los SPP, PP y ST para los que se está declarando conformidad.
Si el SST no declara conformidad con ningún SPP, PP o ST, esta unidad de trabajo no es aplicable y por tanto se
considera satisfecha. Si un SPP, PP o ST que se ha referenciado no tiene ninguna definición de política de seguridad, se
demuestra que la declaración de objetivos es consistente con la declaración de objetivos en los SPP, PP y ST para los
que se está declarando conformidad.
Si el SST no declara conformidad con ningún SPP o PP, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha. Si un SPP, PP o ST que se ha referenciado no tiene ninguna declaración de objetivos de seguridad, se
demuestra que la declaración de requisitos de seguridad es consistente con la declaración de requisitos de seguridad en
los SPP, PP, ST y paquetes para los que se está declarando conformidad.
Si el SST no declara conformidad con ningún SPP, PP, ST o paquete, esta unidad de trabajo no es aplicable y por tanto
Si un SST declara conformidad con un PP o ST, la justificación debe mostrar que las OSF están definidas para satisfa-
cer las suposiciones acerca del entorno operacional en la sección de la definición del problema de seguridad del PP/ST.
D.3.4 Definición del problema de seguridad (ASS_SPD)

Esta familia contiene un componente, ASS_SPD.1 Definición del problema de seguridad.
D.3.4.2 Evaluación de la subactividad ASS_SPD.1
D.3.4.2.1 Acción ASS_SPD.1.1E

Esta acción requiere que el evaluador examine en la declaración de la definición del problema de seguridad su conte-
nido y presentación y está compuesta por tres unidades de trabajo. La acción fracasa si cualquiera de las unidades de
trabajo no confirma el requisito relevante.
- 189 - ISO/IEC TR 19791:2010
ASS_SPD.1-1 El evaluador debe examinar la definición del problema de seguridad para confirmar que describe
todos los riesgos aplicables al STOE y que cada riesgo está categorizado como aceptable o inaceptable.
Si todos los objetivos de seguridad derivan de políticas, no tendría que haber ninguna descripción de riesgos en el SPD.
ASS_SPD.1-2 El evaluador debe examinar la definición del problema de seguridad para confirmar que todos los
riesgos inaceptables se describen en términos de amenazas y vulnerabilidades y que todas las amenazas se describen en
términos de agente de amenaza, activo y acción adversa.
ASP_SPD.1-3 El evaluador debe examinar la definición del problema de seguridad para confirmar que describe las
OSP.
Si todos los objetivos de seguridad derivan de amenazas, no tiene que haber ninguna descripción de las OSP en la SPD.
D.3.5 Objetivos de seguridad (ASS_OBJ)

Esta familia contiene un componente, ASS_OBJ.1 Objetivos de seguridad.
D.3.5.2 Evaluación de la subactividad ASS_OBJ.1
D.3.5.2.1 Acción ASS_OBJ.1.1E

Esta acción requiere que el evaluador examine en la declaración de objetivos de seguridad y en la justificación de
objetivos de seguridad su contenido y presentación y está compuesta por ocho unidades de trabajo. La acción fracasa si
ASS_OBJ.1-1 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe los
objetivos funcionales de seguridad del STOE.
ASS_OBJ.1-2 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe
cualquier objetivo funcional de seguridad que cumplan los sistemas operacionales externos.
Los objetivos de seguridad cumplidos por sistemas operacionales externos dejan de considerarse en la evaluación del
SST, pero se validarán en cualquier evaluación del STOE.
ASS_OBJ.1-3 El evaluador debe examinar la declaración de objetivos de seguridad para confirmar que describe los
objetivos de garantía de seguridad del STOE.
ASS_OBJ.1-4 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que remonta
cada objetivo funcional de seguridad para el STOE a los riesgos afrontados por ese objetivo de seguridad u OSP
aplicados para ese objetivo de seguridad.
ISO/IEC TR 19791:2010 - 190 -
Cada objetivo funcional de seguridad para el STOE puede remontarse a amenazas u OSP o a una combinación de
ASS_OBJ.1-5 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que remonta
cada objetivo funcional de seguridad para sistemas operacionales externos a los riesgos afrontados por ese objetivo de
seguridad u OSP aplicados para ese objetivo de seguridad.
Cada objetivo funcional de seguridad para sistemas operacionales externos puede remontarse a amenazas u OSP o a una
combinación de ambas, pero debe remontarse al menos a una amenaza u OSP.
ASS_OBJ.1-6 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que
demuestra que los objetivos funcionales de seguridad contrarrestan todos los riesgos inaceptables.
Para cada riesgo inaceptable, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales de segu-
ridad que se remontan a ese riesgo, éste se elimina o mitiga hasta un nivel aceptable.
inaceptable: si se alcanza el objetivo de seguridad, contribuye realmente a la eliminación o mitigación de ese riesgo.
Si hay algún riesgo inaceptable al que no se remonte un objetivo funcional de seguridad, se incumple esta unidad de
trabajo.
ASS_OBJ.1-7 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que
demuestra que los objetivos funcionales de seguridad aplican todas las OSP.
Para cada OSP, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales de seguridad que se
remontan a esa OSP, se está aplicando la OSP.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a una OSP: si se
alcanza el objetivo de seguridad, contribuye realmente a la aplicación de esa OSP.
Si hay alguna OSP a la que no se remonte un objetivo funcional de seguridad, se incumple esta unidad de trabajo.
ASS_OBJ.1-8 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que explica
por qué se han elegido los objetivos de garantía de seguridad.
justifica estas razones e incluso pueden indicarse como una elección arbitraria.
D.3.6 Definición de componentes extendidos (ASS_ECD)

Esta familia contiene un componente, ASS_ECD.1 Definición de componentes extendidos.
D.3.6.2 Evaluación de la subactividad ASS_ECD.1
D.3.6.2.1 Acción ASS_ECD.1.1E

Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad y en la definición de
componentes extendidos su contenido y presentación y está compuesta por cinco unidades de trabajo. La acción fracasa
- 191 - ISO/IEC TR 19791:2010
ASS_ECD.1-1 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que identifica
todos los requisitos extendidos de seguridad.
El evaluador debería verificar que todos los requisitos de seguridad no identificados como requisitos extendidos de
seguridad se basan en componentes de la Norma ISO/IEC 15408 o de este informe técnico.
ASS_ECD.1-2 El evaluador debe examinar la definición de componentes extendidos para confirmar que define un
componente extendido por cada requisito extendido de seguridad.
El evaluador debería verificar que todos los requisitos de seguridad identificados como requisitos extendidos de
seguridad se basan en componentes definidos en la definición de componentes extendidos.
Si el SST no contiene requisitos extendidos de seguridad, esta unidad de trabajo no es aplicable y por tanto se considera
satisfecha.
ASS_ECD.1-3 El evaluador debe examinar la definición de componentes extendidos para confirmar que describe
cómo cada componente extendido se relaciona con los componentes, familias y clases existentes en la Norma
satisfecha.
ASS_ECD.1-4 El evaluador debe examinar la definición de componentes extendidos para confirmar que cada
definición utiliza los componentes, familias y clases existentes en la Norma ISO/IEC 15408 o este informe técnico
como modelo de presentación.
satisfecha.
Si una definición de un componente extendido no sigue el modelo de presentación de la Norma ISO/IEC 15408 de una
forma que impida que se aplique esta metodología a su uso, se incumple esta unidad de trabajo. También se incumple
esta unidad de trabajo si se define un componente extendido de una forma que sea incoherente con la relación declarada
con los componentes, familias y clases existentes.
ASS_ECD.1-5 El evaluador debe examinar la definición de componentes extendidos para confirmar que cada
componente extendido consiste en elementos medibles y objetivos de forma que pueda demostrarse el cumplimiento o
incumplimiento de estos elementos.
satisfecha.
El evaluador debería determinar si los requisitos basados en cada definición de un componente extendido pueden
evaluarse sin juicios subjetivos del evaluador.
D.3.6.2.2 Acción ASS_ECD.1.2E

Esta acción requiere que el evaluador demuestre que ningún componente extendido en la definición de componentes
extendidos duplica los componentes existentes y está compuesta por una unidad de trabajo. La acción fracasa si la
ASP_ECD.1-6 El evaluador debe confirmar que ningún componente extendido pueda expresarse claramente
satisfecha.
ISO/IEC TR 19791:2010 - 192 -
Al llevar a cabo esta verificación, el evaluador debería tener en cuenta componentes de la Norma ISO/IEC 15408, este
informe técnico y otros componentes extendidos definidos en el SST, incluyendo refinados, sustituciones y combina-
ciones de componentes. Esta verificación no debería ser exhaustiva, bastando con detectar y excluir complicaciones
innecesarias, si los requisitos pueden expresarse claramente utilizando otros componentes.
D.3.7 Requisitos de seguridad (ASS_REQ)

Esta familia contiene dos componentes, ASS_REQ.1 Requisitos de seguridad declarados y ASS_REQ.1 Requisitos de
seguridad derivados.
D.3.7.2 Evaluación de la subactividad ASS_REQ.1
D.3.7.2.1 Acción ASS_REQ.1.1E

requisitos de seguridad su contenido y presentación y está compuesta por seis unidades de trabajo. La acción fracasa si
ASS_REQ.1-1 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que describe las
SSF y las SSA.
Las SSF y SSA pueden incluirse en el SST por referencia a un SPP, PP, ST o paquete, así como declararse explíci-
tamente.
ASS_REQ.1-2 El evaluador debe examinar el SST para confirmar que define todos los sujetos, objetos, operaciones,
atributos de seguridad, entidades externas y otros términos que se usen en las SSF y las SSA.
El objetivo de esta unidad de trabajo es asegurar que los SFR y SAR están bien definidos y que no puede producirse
ningún error de comprensión debido al uso de términos vagos. Esta unidad de trabajo no debería llevarse a su extremo,
obligando al escritor del SST a definir todas las palabras. Los términos pueden definirse dentro de la declaración de
requisitos de seguridad, pero también puede definirse en otro lugar del SST.
ASS_REQ.1-3 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que identifica
todas las operaciones en los requisitos de seguridad.
ASS_REQ.1-4 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que todas las
operaciones se realizan correctamente.
ISO/IEC 15408.
ASS_REQ.1-5 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que cada
declaración de requisitos de seguridad. El componente utilizado para satisfacer la dependencia debería, si es necesario,
ser modificado por operaciones para garantizar que realmente satisface esa dependencia.
Ésta es la única función para la justificación de los requisitos de seguridad para este miembro de la familia de requisitos
de seguridad. Una simple lista que muestre cómo se satisface cada dependencia o la identifica explícitamente como “no
satisfecha” es suficiente para satisfacer esta unidad de trabajo: no hace falta mayor justificación.
- 193 - ISO/IEC TR 19791:2010
ASS_REQ.1-6 El evaluador debe examinar la declaración de requisitos de seguridad para confirmar que es coherente
internamente.
D.3.7.3 Evaluación de la subactividad ASS_REQ.2
D.3.7.3.1 Acción ASS_REQ.1.2E

Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad y en la justificación de re-
quisitos de seguridad su contenido y presentación y está compuesta por diez unidades de trabajo, de la ASS_REQ.2-1 a
la ASS_REQ.2-10. Las unidades ASS_REQ.2-1 a ASS_REQ.2-4 son idénticas a ASS_REQ.1-1 a ASS_REQ.1-4 res-
pectivamente. La unidad de trabajo ASS_REQ.2-10 es idéntica la unidad de trabajo ASS_REQ.1-6.
ASS_REQ.2-5 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que cada
Esta unidad de trabajo es idéntica en su especificación a la ASS_REQ.1-5. Sin embargo, si no se satisface una
ASS_REQ.2-6 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que remonta
cada SSF a los objetivos funcionales de seguridad del STOE.
El evaluador debería determinar que cada SSF se remonta al menos a un objetivo funcional de seguridad del STOE. No
poder remontar implica que, o la justificación de requisitos de seguridad está incompleta, los objetivos de seguridad del
STOE son incompletos o la SSF no tiene ningún fin útil.
ASS_REQ.2-7 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra
que las SSF cumplen con todos los objetivos funcionales de seguridad del STOE que no cumplan los sistemas externos
o dominios individuales.
Si hay un objetivo funcional de seguridad del STOE al que no se remonta ninguna SSF y no se identifica como
cumplido por sistemas externos o dominios individuales, se incumple esta unidad de trabajo.
objetivo, entonces se cumple ese objetivo funcional de seguridad del STOE.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad del STOE
es necesaria: cuando se satisface la SSF, contribuye realmente a alcanzar el objetivo de seguridad.
ASS_REQ.2-8 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que remonta
cada SSA a los objetivos de garantía de seguridad del STOE.
El evaluador debería determinar que cada SSA se remonta al menos a un objetivo de garantía de seguridad del STOE.
del STOE son incompletos o la SSA no tiene ningún fin útil.
ASP_REQ.2-9 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra que
las SSA cumplen con todos los objetivos de garantía de seguridad del STOE que no cumplan los dominios individuales.
Si hay un objetivo de garantía de seguridad del STOE al que no se remonta ninguna SSA y no se identifica como
cumplido por dominios individuales, se incumple esta unidad de trabajo.
ISO/IEC TR 19791:2010 - 194 -
objetivo, entonces se cumple ese objetivo de garantía de seguridad del STOE.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad del
STOE es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
D.3.8 Especificación resumen del STOE (ASS_TSS)

Esta familia contiene un componente, ASS_TSS.1 Especificación resumen del STOE.
D.3.8.2 Evaluación de la subactividad ASS_TSS.1
D.3.8.2.1 Acción ASS_TSS.1.1E

Esta acción requiere que el evaluador examine en la especificación resumen del STOE su contenido y presentación y
está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
requisito relevante.
ASS_TSS.1-1 El evaluador debe examinar la especificación resumen del STOE para confirmar que cómo el STOE
cumple cada SSF.
Esta descripción se entiende como una visión general y no debería detallarse excesivamente. Su función principal
debería ser identificar cuando distintos subsistemas cumplen la misma SSF, pero de maneras diferentes.
ASS_TSS.1-2 El evaluador debe examinar la especificación resumen del STOE para confirmar que cómo el STOE
cumple cada SSA.
Esta descripción se entiende como una visión general y no debería detallarse excesivamente. Su función principal debe-
ría ser identificar cuando distintos subsistemas cumplen la misma SSA, pero de maneras diferentes.
D.3.8.2.2 Acción ASS_TSS.1.2E

Esta acción requiere que el evaluador confirme que la especificación resumen del STOE sea consistente con los
elementos descriptivos de la introducción del SST. Está compuesta por una unidad de trabajo.
ASS_TSS.1-3 El evaluador debe confirmar que la especificación resumen del STOE es coherente con la visión
general y la descripción del STOE.
El evaluador debería buscar en cada especificación para identificar información de identidad que sea inconsistente con
declaraciones de hecho en otras especificaciones. Por ejemplo, si la descripción del STOE dice que el STOE ofrece un
sistema remoto de acceso web, pero la especificación resumen del STOE describe solo instalaciones de acceso local,
esto sería inconsistente.
El evaluador debería asimismo verificar una por una que no hay características de seguridad descritas en la visión
general del STOE que no estén presentes en la especificación resumen del STOE y por tanto remontables a los objetivos
y la definición del problema de seguridad.
D.3.9 Introducción del dominio de seguridad (ASS_DMI)

Esta familia contiene un componente, ASS_DMI.1 Introducción al dominio de seguridad.
- 195 - ISO/IEC TR 19791:2010
D.3.9.2 Evaluación de la subactividad ASS_DMI.1
D.3.9.2.1 Acción ASS_DMI.1.1E

Esta acción requiere que el evaluador examine en cada introducción del dominio de seguridad su contenido y presen-
tación y está compuesta por cinco unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
ASS_DMI.1-1 El evaluador debe verificar que la introducción del dominio de seguridad contiene una referencia, una
visión general y una descripción del dominio de seguridad.
ASS_DMI.1-2 El evaluador debe examinar la referencia del dominio de seguridad para confirmar que identifica de
forma única el dominio de seguridad.
ASS_DMI.1-3 El evaluador debe examinar la visión general del dominio de seguridad para confirmar que resume el
uso y las principales características de seguridad del dominio de seguridad.
ASS_DMI.1-4 El evaluador debe examinar la descripción del dominio de seguridad para confirmar que identifica los
subsistemas incluidos o los componentes.
entre este dominio de seguridad y los subsistemas/componentes desde los que se construye el sistema operacional.
ASS_DMI.1-5 El evaluador debe examinar la descripción del dominio de seguridad para confirmar que identifica las
relaciones e interfaces con otros dominios.
entre este dominio de seguridad y otros.
D.3.9.2.2 Acción ASS_DMI.1.2E

Esta acción requiere que el evaluador busque inconsistencias dentro de la introducción del dominio de seguridad y está
ASS_DMI.1-6 El evaluador debe confirmar que la referencia, la visión general y la descripción del dominio de
seguridad son consistentes entre sí y con la introducción del SST.
El evaluador debería mirar una por una cada especificación para identificar información que sea inconsistente con de-
claraciones de hechos en las demás especificaciones. Por ejemplo, si la especificación de la organización del dominio en
la introducción del SST dice que este dominio tiene dos interfaces con otros dominios, pero la descripción del dominio
de seguridad define tres, esto sería inconsistente.
D.3.10 Declaraciones de conformidad del dominio de seguridad (ASS_DMC)

Esta familia contiene un componente, ASS_DMC.1 Declaraciones de conformidad del dominio de seguridad.
D.3.10.2 Evaluación de la subactividad ASS_DMC.1
D.3.10.2.1 Acción ASS_DMC.1.1E

Esta acción requiere que el evaluador examine en cada declaración de conformidad del dominio y justificación de las
declaraciones de conformidad del dominio su contenido y presentación y está compuesta por seis unidades de trabajo.
ISO/IEC TR 19791:2010 - 196 -
ASS_DMC.1-1 El evaluador debe examinar la declaración de conformidad del dominio para confirmar que identifica
todos los SPP, PP, ST y paquetes de requisitos de seguridad a los que el dominio declara conformidad.
El evaluador debería confirmar que cualquier SPP, PP, ST y paquete de requisitos de seguridad referenciado se iden-
tifica sin ambigüedades y que no hay referencias descriptivas a SPP, PP, ST o paquetes de requisitos de seguridad en la
introducción del dominio que no estén aquí listados.
ASS_DMC.1-2 El evaluador debe examinar la declaración de conformidad del dominio para confirmar que describe
cualquier conformidad del dominio con un paquete ya sea como paquete conforme o como paquete aumentado.
Si el dominio no declara conformidad con ningún paquete, esta unidad de trabajo no es aplicable y por tanto se consi-
dera satisfecha. En caso contrario, el evaluador debería verificar que las SSF y SSA definidas en el SST son consisten-
tes con el tipo de conformidad declarada para cada paquete identificado.
ASS_DMC.1-3 El evaluador debe examinar la justificación de las declaraciones de conformidad del dominio para
confirmar que demuestra que el tipo de STOE es consistente con el tipo de STOE en los SPP, PP y ST para los que se
está declarando conformidad.
Si el dominio no declara conformidad con ningún SPP, PP o ST, esta unidad de trabajo no es aplicable y por tanto se
confirmar que demuestra que la declaración de la definición del problema de seguridad del dominio es consistente con
la declaración de la definición del problema de seguridad en los SPP, PP y ST para los que se está declarando confor-
midad.
considera satisfecha. Si un SPP, PP o ST que se ha referenciado no tiene ninguna definición de política de seguridad, se
confirmar que demuestra que la declaración de objetivos de seguridad del dominio es consistente con la declaración de
objetivos en los SPP, PP y ST para los que se está declarando conformidad.
considera satisfecha. Si un SPP, PP o ST que se ha referenciado no tiene ninguna declaración de objetivos de seguridad,
se considera consistente sin más exámenes.
confirmar que demuestra que la declaración de requisitos de seguridad del dominio es consistente con la declaración de
requisitos de seguridad en los SPP, PP, ST y paquetes para los que se está declarando conformidad.
Si el dominio no declara conformidad con ningún SPP, PP, ST o paquete, esta unidad de trabajo no es aplicable y por
D.3.11 Definición del problema de seguridad del dominio de seguridad (ASS_DMP)

Esta familia contiene un componente, ASS_DMP.1 Definición del problema de seguridad del dominio de seguridad.
- 197 - ISO/IEC TR 19791:2010
D.3.11.2 Evaluación de la subactividad ASS_DMP.1
D.3.11.2.1 Acción ASS_DMP.1.1E

Esta acción requiere que el evaluador examine en cada definición del problema de seguridad del dominio su contenido y
presentación y está compuesta por tres unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
ASS_DMP.1-1 El evaluador debe examinar la definición del problema de seguridad del dominio para confirmar que
describe todos los riesgos únicos aplicables al dominio y que cada riesgo está categorizado como aceptable o
inaceptable.
Si todos los objetivos de seguridad derivan de políticas, no tendría que haber ninguna descripción de riesgos en el SPD
todos los riesgos inaceptables se describen en términos de amenazas y vulnerabilidades y que todas las amenazas se
describen en términos de agente de amenaza, activo y acción adversa.
describe las OSP únicas aplicables al dominio.
Si todos los objetivos de seguridad derivan de amenazas, no tiene que haber ninguna descripción de las OSP en la SPD
D.3.12 Objetivos de seguridad del dominio de seguridad (ASP_DMO)

Esta familia contiene un componente, ASS_DMO.1 Objetivos de seguridad del dominio de seguridad.
D.3.12.2 Evaluación de la subactividad ASS_DMO.1
D.3.12.2.1 Acción ASS_DMO.1.1E

Esta acción requiere que el evaluador examine en cada declaración de objetivos de seguridad del dominio y en la justifi-
cación de objetivos de seguridad del dominio su contenido y presentación y está compuesta por nueve unidades de
ASS_DMO.1-1 El evaluador debe examinar la declaración de objetivos de seguridad del dominio para confirmar que
describe los objetivos de seguridad funcional únicos para el dominio.
describe cualquier objetivo funcional de seguridad que cumplan otros dominios o sistemas operacionales externos.
ISO/IEC TR 19791:2010 - 198 -
Si no hay objetivos funcionales de seguridad para el dominio o sistemas operacionales externos, esta unidad de trabajo
no es aplicable y por tanto se considera satisfecha.
El evaluador debería verificar que los objetivos funcionales de seguridad cumplidos por otros dominios se describen en las
declaraciones de objetivos de seguridad del dominio para otros dominios como aplicados o disponibles en otros dominios.
Los objetivos de seguridad cumplidos por sistemas operacionales externos no se consideran más en la evaluación del
STOE, pero se validarán en la evaluación del SST.
describe los objetivos de garantía de seguridad únicos del dominio.
Si no hay objetivos de garantía de seguridad para el dominio, esta unidad de trabajo no es aplicable y por tanto se
describe todos los objetivos de seguridad del dominio que son aplicables o están disponibles en otros dominios.
Es aceptable para objetivos ser aplicados o estar disponibles para otros dominios sin que otros dominios hagan uso de
esos objetivos.
ASS_DMO.1-5 El evaluador debe examinar la justificación de los objetivos de seguridad del dominio para conformar
Cada objetivo funcional de seguridad para el dominio puede remontarse a amenazas u OSP o a una combinación de
ASS_DMO.1-6 El evaluador debe examinar la justificación de los objetivos de seguridad del dominio para confirmar
Si no hay objetivos funcionales de seguridad para otros dominios, esta unidad de trabajo no es aplicable y por tanto se
Cada objetivo funcional de seguridad para otros dominios puede remontarse a amenazas u OSP o a una combinación de
ASS_DMO.1-7 El evaluador debe examinar la justificación de los objetivos de seguridad para confirmar que demues-
tra que los objetivos funcionales de seguridad contrarrestan todos los riesgos inaceptables únicos del dominio.
Si no hay objetivos funcionales de seguridad ni riesgos inaceptables únicos para el dominio, esta unidad de trabajo no es
Para cada riesgo inaceptable único del dominio, el evaluador debería confirmar que si se alcanzan todos los objetivos
funcionales de seguridad que se remontan a ese riesgo, éste se elimina o mitiga hasta un nivel aceptable.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a un riesgo ina-
ceptable único del dominio: si se alcanza el objetivo de seguridad, contribuye realmente a la eliminación o mitigación
de ese riesgo.
- 199 - ISO/IEC TR 19791:2010
Si hay algún riesgo inaceptable único del dominio al que no se remonte un objetivo funcional de seguridad, se incumple
que demuestra que los objetivos funcionales de seguridad aplican todas las OSP únicas del dominio.
Si no hay objetivos funcionales de seguridad ni OSP únicas para el dominio, esta unidad de trabajo no es aplicable y por
Para cada OSP única para el dominio, el evaluador debería confirmar que si se alcanzan todos los objetivos funcionales
de seguridad que se remontan a esa OSP, se está aplicando la OSP.
El evaluador confirma asimismo que es necesario cada objetivo funcional de seguridad que se remonta a una OSP única
para el dominio: si se alcanza el objetivo de seguridad, contribuye realmente a la aplicación de esa OSP.
Si hay alguna OSP única para el dominio a la que no se remonte un objetivo funcional de seguridad, se incumple esta
unidad de trabajo.
que explica por qué se han elegido los objetivos de garantía de seguridad para el dominio.
Si no hay objetivos de garantía de seguridad únicos para el dominio, esta unidad de trabajo no es aplicable y por tanto se
justificar estas razones e incluso pueden indicarse como una elección arbitraria.
D.3.12.2.2 Acción ASS_DMO.1.2E

Esta acción requiere que el evaluador busque inconsistencias entre cada declaración de objetivos de seguridad del
dominio y la introducción del SST y está compuesta por una unidad de trabajo.
ASS_DMO.1-10 El evaluador debe confirmar que la declaración de objetivos de seguridad del dominio es consistente
con la especificación de la organización del dominio.
El evaluador debería mirar una por una cada especificación para identificar información que sea inconsistente con
declaraciones de hechos en las demás especificaciones. Por ejemplo, si la especificación de la organización del dominio
dice todos los dominios son independientes, pero la declaración de objetivos de seguridad del dominio muestra que
algunos objetivos se cumplen mediante otros dominios, esto sería inconsistente.
D.3.13 Requisitos de seguridad del dominio de seguridad (ASS_DMR)

Esta familia contiene dos componentes, ASS_DMR.1 Requisitos de seguridad del dominio declarados y ASS_DMR.2
Requisitos de seguridad del dominio derivados.
D.3.13.2 Evaluación de la subactividad ASS_DMR.1
D.3.13.2.1 Acción ASS_DMR.1.1E

Esta acción requiere que el evaluador examine en cada declaración de requisitos de seguridad del dominio y justifica-
ción de requisitos de seguridad del dominio su contenido y presentación y está compuesta por seis unidades de trabajo.
ASS_DMR.1-1 El evaluador debe examinar la declaración de requisitos de seguridad del dominio para confirmar que
describe las SSF y las SSA únicas aplicables al dominio.
ISO/IEC TR 19791:2010 - 200 -
Las SSF y SSA pueden incluirse en la especificación del dominio por referencia a un SPP, PP, ST o paquete, así como
declararse explícitamente.
ASS_DMR.1-2 El evaluador debe examinar el SST para confirmar que define todos los sujetos, objetos, operaciones,
atributos de seguridad, entidades externas y otros términos que se usen en las SSF y las SSA únicas aplicables al dominio.
El objetivo de esta unidad de trabajo es asegurar que los SFR y SAR del dominio están bien definidos y que no puede
producirse ningún error de comprensión debido al uso de términos vagos. Esta unidad de trabajo no debería llevarse a
su extremo, obligando al escritor del SST a definir todas las palabras. Los términos pueden definirse dentro de la
declaración de requisitos de seguridad, pero también pueden definirse en otro lugar del SST.
identifica todas las operaciones en los requisitos de seguridad.
todas las operaciones se realizan correctamente.
ISO/IEC 15408.
ASS_DMR.1-5 El evaluador debe examinar la justificación de requisitos de seguridad del dominio para confirmar
declaración de requisitos de seguridad del dominio. El componente utilizado para satisfacer la dependencia debería, si
es necesario, ser modificado por operaciones para garantizar que realmente satisface esa dependencia.
Ésta es la única función para la justificación de los requisitos de seguridad del dominio para este miembro de la familia
de requisitos de seguridad. Una simple lista que muestre cómo se satisface cada dependencia o la identifica explícita-
mente como “no satisfecha” es suficiente para satisfacer esta unidad de trabajo: no hace falta mayor justificación.
es coherente internamente.
D.3.13.3 Evaluación de la subactividad ASS_DMR.2
D.3.13.3.1 Acción ASS_DMR.2.1E

Esta acción requiere que el evaluador examine en la declaración de requisitos de seguridad del dominio y en la justifica-
ción de requisitos de seguridad del dominio su contenido y presentación y está compuesta por doce unidades de trabajo,
de la ASS_DMR.2-1 a la ASS_DMR.2-12. Las unidades de trabajo ASS_DMR.2-1 a ASS_DMR.2-4 son idénticas a
ASS_DMR.1-1 a ASS_DMR.1-4 respectivamente. La unidad de trabajo ASS_DMR.2-12 es idéntica la unidad de
trabajo ASS_DMR.1-6.
- 201 - ISO/IEC TR 19791:2010
Esta unidad de trabajo es idéntica en su especificación a la ASS_DMR.1-5. Sin embargo, si no se satisface una depen-
dencia, la justificación debería explicar, refiriéndose a los objetivos de seguridad o a otra cosa, por qué dicha dependen-
cia no es necesaria o útil.
que remonta cada SSF a los objetivos funcionales de seguridad del dominio.
Si no hay requisitos funcionales de seguridad para el dominio, esta unidad de trabajo no es aplicable y por tanto se
El evaluador debería determinar que cada SSF se remonta al menos a un objetivo funcional de seguridad del dominio.
No poder remontar implica que, o la justificación de requisitos de seguridad del dominio está incompleta, los objetivos
de seguridad del dominio son incompletos o la SSF no tiene ningún fin útil.
que demuestra que las SSF del dominio cumplen con todos los objetivos funcionales de seguridad del dominio que no
cumplan otros dominios o sistemas externos.
Si no hay requisitos funcionales de seguridad únicos ni objetivos funcionales de seguridad del dominio, esta unidad de
Si hay un objetivo funcional de seguridad del dominio al que no se remonta ninguna SSF y no se cumple por otros
dominios o sistemas externos, se incumple esta unidad de trabajo.
objetivo, entonces se cumple ese objetivo funcional de seguridad del dominio.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad del
dominio es necesaria: cuando se satisface la SSF, contribuye realmente a alcanzar el objetivo de seguridad.
que demuestra que las SSF del dominio cumplen todos los objetivos funcionales de seguridad del STOE que estén iden-
tificados en la justificación de requisitos de seguridad para el STOE completo que cumplan los dominios individuales.
Si no hay requisitos funcionales de seguridad únicos para el dominio ni objetivos funcionales de seguridad para la
totalidad del STOE que hayan de cumplir dominios individuales, esta unidad de trabajo no es aplicable y por tanto se
Si hay un objetivo funcional de seguridad para todo el STOE que hayan de cumplir dominios individuales a los que no
se remonte ninguna SSF del dominio, se incumple esta unidad de trabajo.
objetivo del STOE que hayan de cumplir dominios individuales, entonces se cumple ese objetivo funcional de seguridad
para todo el STOE.
El evaluador debería asimismo determinar que cada SSF que se remonte a un objetivo funcional de seguridad para todo
el STOE que hayan de cumplir dominios individuales es necesaria: cuando se satisface la SSF, contribuye realmente a
alcanzar el objetivo de seguridad.
que remonta cada SSA a los objetivos de garantía de seguridad del dominio.
Si no hay requisitos de garantía de seguridad únicos para el dominio, esta unidad de trabajo no es aplicable y por tanto
ISO/IEC TR 19791:2010 - 202 -
El evaluador debería determinar que cada SSA se remonta al menos a un objetivo de garantía de seguridad del dominio.
del dominio son incompletos o la SSA no tiene ningún fin útil.
que demuestra que las SSA cumplen todos los objetivos de garantía de seguridad únicos del dominio.
Si no hay requisitos de garantía de seguridad únicos ni objetivos de garantía de seguridad para el dominio, esta unidad
de trabajo no es aplicable y por tanto se considera satisfecha.
Si hay algún objetivo de garantía de seguridad para el dominio al que no pueda remontarse ninguna SSA, se incumple
objetivo, entonces se cumple ese objetivo de garantía de seguridad para el dominio.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad para el
dominio es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
ASS_DMR.2-11 El evaluador debe examinar la justificación de requisitos de seguridad para confirmar que demuestra
que las SSA del dominio cumplen con todos los objetivos de garantía de seguridad del STOE se identifican en la justifi-
cación de requisitos de seguridad para todo el STOE que hayan de cumplir dominios individuales.
Si no hay requisitos de garantía de seguridad únicos ni objetivos de garantía de seguridad para todo el STOE que hayan
de cumplir dominios individuales, esta unidad de trabajo no es aplicable y por tanto se considera satisfecha.
Si hay algún objetivo de garantía de seguridad para todo el STOE que hayan de cumplir dominios individuales al que no
pueda remontarse ninguna SSA, se incumple esta unidad de trabajo.
objetivo para todo el STOE que hayan de cumplir dominios individuales, entonces se cumple ese objetivo de garantía de
seguridad para todo el STOE.
El evaluador debería asimismo determinar que cada SSA que se remonte a un objetivo de garantía de seguridad para
todo el STOE es necesaria: cuando se satisface la SSA, contribuye realmente a alcanzar el objetivo de seguridad.
D.3.14 Especificación resumen del dominio de seguridad (ASS_DMS)

Esta familia contiene un componente, ASS_DMS.1 Especificación resumen del dominio de seguridad.
D.3.14.2 Evaluación de la subactividad ASS_DMS.1
D.3.14.2.1 Acción ASS_DMS.1.1E

Esta acción requiere que el evaluador examine en la especificación resumen del dominio de seguridad su contenido y
presentación y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
ASS_DMS.1-1 El evaluador debe examinar la especificación resumen del dominio de seguridad para confirmar que
describe cómo cumple el STOE cada SSF del dominio.
Esta descripción se entiende como una visión general y no debería detallarse excesivamente. Su función principal
debería ser identificar cuando distintos componentes del dominio cumplen la misma SSF, pero de maneras diferentes.
- 203 - ISO/IEC TR 19791:2010
ASS_DMS.1-2 El evaluador debe examinar la especificación resumen del dominio de seguridad para confirmar que
describe cómo cumple el STOE cada SSA del dominio.
Esta descripción se entiende como una visión general y no debería detallarse excesivamente. Su función principal debe-
ría ser identificar aproximaciones únicas de seguridad del dominio.
D.3.14.2.2 Acción ASS_DMS.1.2E

Esta acción requiere que el evaluador confirme que la especificación resumen del dominio de seguridad sea consistente
con los elementos descriptivos de la introducción del dominio. Está compuesta por una unidad de trabajo.
ASS_TSS.1-3 El evaluador debe confirmar que la especificación resumen del dominio de seguridad es coherente
con la visión general y la descripción del dominio.
El evaluador debería buscar una a una en cada especificación para identificar información de identidad que sea inconsis-
tente con declaraciones de hecho en otras especificaciones. Por ejemplo, si la visión general del dominio dice que un
dominio ofrece un sistema remoto de acceso web, pero la especificación resumen del dominio de seguridad describe
solo instalaciones de acceso local, esto sería inconsistente.
El evaluador debería asimismo verificar que no hay características de seguridad descritas en la visión general del
dominio que no estén presentes en la especificación resumen del dominio de seguridad y por tanto remontables a los
objetivos y la definición del problema de seguridad del dominio.
D.4 Clase AOD: Documento de guía del sistema operacional
D.4.1 Introducción
El propósito de la clase Documento de guía del sistema operacional es juzgar la adecuación de la documentación que
describe la integración y uso operacional del sistema operacional.
Hay tres familias dentro de esta clase, ocupándose de la configuración y documentación operacional y de la verificación
de que la documentación sigue siendo aplicable tras modificaciones del sistema.
D.4.2 Especificación de la configuración del sistema operacional (AOD_OCD)

Esta familia contiene dos componentes jerárquicos, AOD_OCD.1 Especificación de la configuración del sistema opera-
cional y AOD_OCD.2 Verificación de la especificación de la configuración del sistema operacional.
D.4.2.2 Evaluación de la subactividad AOD_OCD.1
D.4.2.2.1 Acción AOD_OCD.1.1E

Esta acción requiere que el evaluador examine en la especificación de configuración su contenido y presentación y está
compuesta por siete unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
AOD_OCD.1-1 El evaluador debe examinar la especificación de la configuración para confirmar que describe todos
los requisitos de configuración relativos al STOE, incluyendo su entorno operacional.
AOD_OCD.1-2 El evaluador debe examinar la especificación de la configuración para confirmar que describe los
parámetros de configuración de seguridad disponibles para el integrador del sistema o los usuarios/administradores
equivalentes del STOE con ese papel y responsabilidad.
ISO/IEC TR 19791:2010 - 204 -
AOD_OCD.1-3 El evaluador debe examinar la especificación de la configuración para confirmar que identifica todos
los posibles modos de operación del STOE (incluyendo la operación tras fallos o errores operacionales), sus conse-
cuencias e implicaciones para mantener una operación segura.
AOD_OCD.1-4 El evaluador debe examinar la especificación de la configuración para confirmar que contiene
advertencias acerca de las funciones y privilegios accesibles de configuración que deberían controlarse en un entorno de
procesamiento seguro.
AOD_OCD.1-5 El evaluador debe examinar la especificación de la configuración para confirmar que presenta clara-
mente todas las responsabilidades relacionadas con la configuración necesarias para una operación segura del STOE,
incluyendo dependencias en sistemas operacionales externos.
AOD_OCD.1-6 El evaluador debe examinar la especificación de la configuración para confirmar que es consistente
con el concepto de seguridad de las operaciones.
Para completar esta unidad de trabajo, el evaluador debería repasar completamente el documento del concepto de segu-
ridad de operaciones para listar todas las actividades de configuración operacional identificadas como necesarias por el
concepto de operaciones. El evaluador debería luego verificar que están descritas en la especificación de configuración.
AOD_OCD.1-7 El evaluador debe examinar la especificación de la configuración para confirmar que muestra que
todos los parámetros de seguridad del componente requeridos por el concepto de seguridad de operaciones están
implantados por el diseño del componente.
Para completar esta unidad de trabajo, el evaluador debería repasar completamente el documento del concepto de
seguridad de operaciones para listar todos los parámetros de seguridad de los componentes del sistema requeridos por el
concepto de operaciones. El evaluador debería luego verificar que están descritos en la especificación de configuración.
El evaluador puede necesitar referirse al diseño del componente para establecer cómo se implantan los parámetros con
el fin de identificar la descripción correspondiente.
D.4.2.3 Evaluación de la subactividad AOD_OCD.2

Esta acción requiere que el evaluador examine en la especificación de configuración su contenido y presentación y está
compuesta por siete unidades de trabajo, de la AOD_OCD.2-1 a la AOD_OCD.2-7. Son idénticas a sus equivalentes
AOD_OCD.1-1 a la AOD_OCD.1-7.

Esta acción requiere que el evaluador repita independientemente todos los procedimientos de configuración y está
AOD_OCD.2-8 El evaluador debe repetir todos los procedimientos de configuración e instalación para confirmar que
el STOE puede configurarse y usarse de forma segura utilizando solo la especificación de configuración suministrada.
La unidad de trabajo se limita a aquellos procedimientos aplicables al sistema operacional es su entorno operacional, es
decir, a los requeridos durante el uso operacional (pero incluyendo la recuperación de errores del sistema).
Puede no ser factible generar todas las situaciones de error descritas por la especificación de configuración para ejecutar
los procedimientos relacionados de recuperación. En estos casos, los procedimientos indicados deberían examinarse y
ejecutarse en la medida de lo posible.
La acción del evaluador fracasa si no puede ejecutarse un procedimiento como está documentado debido a que faltan
pasos o son inconsistentes con el sistema real. También fracasa si ejecutar un procedimiento pone el sistema en un
estado inseguro sin advertir que éste es el caso.
- 205 - ISO/IEC TR 19791:2010

Esta acción requiere que el evaluador realice pruebas independientes para tratar de poner el sistema en un estado
inseguro sin que resulte evidente. Está compuesta por dos unidades de trabajo.
AOD_OCD.2-9 El evaluador debe idear casos de prueba basados en seguir incorrectamente la especificación de confi-
guración, en los que el sistema se pone potencialmente en un estado inseguro y la especificación de configuración no
advierte que sería así.
El evaluador habrá ejecutado todos los procedimientos de especificación de configuración como parte de la acción
AOD_OCD.2.2E. Si el evaluador es incapaz de idear ningún caso posible de prueba para un posterior examen basado en
la ejecución de los procedimientos, entonces esta acción se completa con éxito sin realizar las siguientes unidades de
trabajo.
AOD_OCD.2-10 El evaluador debe ejecutar los casos de prueba y, en cada caso, determinar si un usuario, con una
comprensión de la especificación de configuración, sería razonablemente capaz de determinar si el STOE está
configurando y operando de una forma que resulta insegura.
Los casos de prueba que fracasen en poner el sistema en un estado inseguro deberían ignorarse a los fines de evaluar el
éxito o fracaso.
Si una prueba tiene éxito en poner al sistema en un estado inseguro y este estado solo puede determinarse como
inseguro utilizando técnicas de verificación o investigativas que fueran excesivas o irreales para que un usuario
ordinario pudiera realizar las acciones que lleven a ese estado inseguro, entonces esta acción fracasa.
AOD_OCD.2-11 El evaluador debe registrar la siguiente información acerca de los casos de prueba ejecutados:
a) identificación de la acción incorrecta de configuración a probar;
b) instrucciones para establecer todas las condiciones prerrequeridas;
c) instrucciones para configurar incorrectamente el STOE;
d) descripción de las acciones mínimas necesarias a realizar para confirmar que el STOE está configurado incorrec-
tamente;
e) resultados reales de la prueba, incluyendo si se ha recibido una advertencia y si el STOE era realmente inseguro.
El nivel de detalle debe ser tal que otro evaluador pueda repetir los casos de prueba y obtener un resultado equivalente.
D.4.3 Documentación de guía del usuario del sistema operacional (AOD_OGD)

Esta familia contiene dos componentes jerárquicos, AOD_OGD.1 Guía del usuario y AOD_OGD.2 Verificación de la
guía del usuario.
D.4.3.2 Evaluación de la subactividad AOD_OGD.1
D.4.3.2.1 Acción AOD_OGD.1.1E

Esta acción requiere que el evaluador examine en la guía del usuario su contenido y presentación y está compuesta por
siete unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito relevante.
AOD_OGD.1-1 El evaluador debe examinar la guía del usuario para confirmar que describe, para cada rol de usuario,
las funciones e interfaces disponibles para ese tipo de usuario del STOE.
ISO/IEC TR 19791:2010 - 206 -
los controles operacionales relacionados con ese tipo de usuario.
AOD_OGD.1-3 El evaluador debe examinar la guía del usuario para confirmar que describe el uso de funciones de
seguridad accesibles para el usuario ofrecidas por el STOE.
todos los parámetros de seguridad bajo el control de ese tipo de usuario, incluyendo los valores seguros cuando
corresponda.
AOD_OGD.1-5 El evaluador debe examinar la guía del usuario para confirmar que contiene advertencias acerca de
funciones y privilegios accesibles para el usuario que deberían controlarse en un entorno seguro de procesamiento.
AOD_OGD.1-6 El evaluador debe examinar la guía del usuario para confirmar que presenta claramente todas las res-
ponsabilidades de usuario necesarias para una operación segura del STOE, incluyendo las relativas al comportamiento
del usuario durante la operación del sistema.
AOD_OGD.1-7 El evaluador debe confirmar que la guía del usuario es consistente con el concepto de seguridad de
operaciones.
Para completar esta unidad de trabajo, el evaluador debería repasar completamente el documento del concepto de
seguridad de operaciones para listar todas las actividades de usuario identificadas como necesarias por el concepto de
operaciones. El evaluador debería luego verificar que están descritos en la guía del usuario.
D.4.3.3 Evaluación de la subactividad AOD_OGD.2

Esta acción requiere que el evaluador examine en la guía del usuario su contenido y presentación y está compuesta por
siete unidades de trabajo, de la AOD_OGD.2-1 a la AOD_OGD.2-7. Son idénticas a sus equivalentes AOD_OGD.1-1 a
la AOD_OGD.1-7.

Esta acción requiere que el evaluador verifique independientemente la usabilidad de la guía del usuario. Está compuesta
por una unidad de trabajo.
AOD_OGD.2-8 El evaluador debe verificar independientemente la usabilidad de la guía del usuario.
El evaluador debería seleccionar un método apropiado y eficiente de verificar la usabilidad de la guía del usuario, como
entrevistas personales, elegir procedimientos de ejemplo y ejecutarlos u otros métodos apropiados.
Si se encuentran evidencias de que uno o más procesos no son utilizables en la práctica, fracasa la acción de evaluación.
D.4.4 Verificación del documento de (AOD_GVR)

D.4.4.2 Evaluación de la subactividad AOD_GVR.1
D.4.4.2.1 Acción AOD_GVR.1.1E

Esta acción requiere que el evaluador examine en el análisis de verificación de la guía su contenido y presentación. Este
análisis lo produce la gestión de sistemas tras cambios o modificaciones en el sistema. Está compuesta por dos unidades
de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el requisito relevante.
- 207 - ISO/IEC TR 19791:2010
AOD_GVR.1-1 El evaluador debe examinar el análisis de verificación de la guía para confirmar que la especificación
de configuración no se ve afectada por los cambios o modificaciones o que ha sido actualizada correctamente para
AOD_GVR.1-2 El evaluador debe examinar el análisis de verificación de la guía para confirmar que la guía del
usuario no se ve afectada por los cambios o modificaciones del sistema o que ha sido actualizada correctamente para
D.5 Clase ASD: Documentación de arquitectura, diseño y configuración del sistema operacional
D.5.1 Introducción
El propósito de la clase documentación de arquitectura, diseño y configuración del sistema operacional es evaluar la
arquitectura, diseño y configuración del sistema operacional para asegurarse de que el sistema cumplirá sus requisitos
funcionales de seguridad.
Hay seis familias dentro de esta clase, ocupándose de la arquitectura general, el concepto de seguridad de operaciones,
la especificación funcional de la interfaz, el diseño del STOE, la verificación de requisitos y la verificación de docu-
mentos de diseño tras modificaciones.
D.5.2 Descripción de la arquitectura (ASD_SAD)

D.5.2.2 Evaluación de la subactividad ASD_SAD.1
D.5.2.2.1 Acción ASD_SAD.1.1E

Esta acción requiere que el evaluador examine en la descripción de la arquitectura su contenido y presentación y está
compuesta por cuatro unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
La descripción de la arquitectura es un documento general, no un documento específico de seguridad. No tiene que ocu-
parse de asuntos de seguridad. Se usa principalmente como un documento de referencia dentro de otras subactividades
de evaluación. Esta subactividad confirma que la descripción de la arquitectura contiene la necesaria información de la
arquitectura.
ASD_SAD.1-1 El evaluador debe examinar la descripción de la arquitectura para confirmar que identifica el STOE
en términos de sus subsistemas y las interfaces e interconexiones entre los subsistemas.
ASD_SAD.1-2 El evaluador debe examinar la descripción de la arquitectura para confirmar que identifica los
sistemas operacionales externos que interactúan con el STOE y las interfaces e interconexiones entre el STOE y los
sistemas operacionales externos.
ASD_SAD.1-3 El evaluador debe examinar la descripción de la arquitectura para confirmar que describe el propósito
y funciones de los subsistemas, interconexiones e interfaces identificados del STOE.
ASD_SAD.1-4 El evaluador debe examinar la descripción de la arquitectura para confirmar que describe el propósito
de las interconexiones e interfaces identificadas en el STOE con sistemas operacionales externos y describe los servi-
cios recibidos y prestados por los sistemas operacionales externos.
ISO/IEC TR 19791:2010 - 208 -
D.5.3 Concepto de seguridad de operaciones (ASD_CON)

D.5.3.2 Evaluación de la subactividad ASD_CON.1
D.5.3.2.1 Acción ASD_CON.1.1E

Esta acción requiere que el evaluador examine en el concepto de seguridad de operaciones su contenido y presentación
y está compuesta por once unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
Los requisitos de la documentación del concepto de seguridad de operaciones se ocupan exclusivamente de asuntos de
seguridad. Esto no significa que la información no pueda estar incluida dentro de una documentación más general que
se ocupe de otros atributos del sistema operacional.
ASD_CON.1-1 El evaluador debe examinar la documentación del concepto de seguridad de operaciones para
confirmar que ofrece un nivel de detalle en correspondencia con la descripción de interfaces e interconexiones ofrecidas
en la descripción de la arquitectura.
Si la documentación del concepto de seguridad de operaciones está escrita en términos de unidades de arquitectura que
no pueden identificarse dentro de la descripción de la arquitectura, esta unidad de trabajo fracasa.
confirmar que describe todas las políticas, propiedades y características de seguridad del STOE.
Se recuerda al evaluador que la documentación del concepto de seguridad de operaciones debería estar al mismo nivel
de detalle que la descripción de la arquitectura y que por tanto la descripción de las políticas, propiedades y
características de seguridad del sistema operacional no debe detallarse en exceso.
confirmar que cubre todos los modos de operación del STOE (por ejemplo, incluyendo los modos de operación de
backup o degradado).
confirmar que describe todas las opciones obligatorias de conjuración de seguridad para productos componentes.
confirmar que describe los dominios de seguridad del STOE.
La estructura del dominio de seguridad de un sistema operacional compuesto no tiene que ser la misma que su estruc-
tura de arquitectura. Un subsistema puede abarcar varios dominios de seguridad (por ejemplo, un solo sistema cliente-
servidor puede tener distintas políticas de seguridad para clientes y servidores). Igualmente, varios productos de diver-
sos vendedores pueden tener que tratarse como componentes separados para fines de construcción pero implantar
políticas de seguridad idénticas y por tanto caer dentro de un solo dominio de seguridad.
ASD_CON.1-6 El evaluador debe examinar la documentación del concepto de seguridad de operaciones para confir-
mar que describe las propiedades de seguridad que aplican los dominios de seguridad en otros dominios, incluyendo
medidas para asegurar la operación correcta de la SSF.
mar que demuestra que el proceso de inicialización de la SSF impide eludir o alterar el establecimiento de la funcionali-
dad de aplicación del SFR.
- 209 - ISO/IEC TR 19791:2010
de detalle que la descripción de la arquitectura y que por tanto la descripción del proceso de inicialización no tiene que
detallarse en exceso.
confirmar que demuestra que la SSF se protege ante alteraciones.
de detalle que la descripción de la arquitectura y que por tanto la descripción de los procesos de autoprotección no tiene
que detallarse en exceso.
La protección puede proporcionarse tanto por diseño de arquitectura como por funcionalidad.
confirmar que demuestra que la SSF impide eludir la funcionalidad de aplicación del SFR.
de detalle que la descripción de la arquitectura y que por tanto la descripción de los procesos para eludir la funcio-
nalidad de aplicación del SFR no tiene que detallarse en exceso.
La protección puede proporcionarse tanto por diseño de arquitectura como por funcionalidad.
mar que demuestra que los flujos de información entre dominios del STOE y entre el STOE y los sistemas operacio-
nales externos, no elude, interfieren o alteran la funcionalidad de aplicación del SFR.
confirmar que es consistente internamente.
D.5.3.2.2 Acción ASD_CON.1.2E

Esta acción requiere que el evaluador confirme que la documentación del concepto de seguridad de operaciones sea
consistente con la descripción de la arquitectura y está compuesta por una unidad de trabajo. La acción fracasa si la
ASD_CON.1-12 El evaluador debe confirmar que la documentación del concepto de seguridad de operaciones es
consistente con la descripción de la arquitectura.
Si la documentación del concepto de seguridad de operaciones se refiere a interfaces o flujos de datos que no pueden
identificarse dentro de la descripción de la arquitectura, esta unidad de trabajo fracasa.
D.5.4 Especificación funcional de la interfaz (ASD_IFS)

D.5.4.2 Evaluación de la subactividad ASD_IFS.1
D.5.4.2.1 Acción ASD_IFS.1.1E

Esta acción requiere que el evaluador examine en la especificación funcional de la interfaz su contenido y presentación
y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
ISO/IEC TR 19791:2010 - 210 -
La especificación funcional de la interfaz abarca tanto asuntos de arquitectura como de seguridad. Hace falta menos
detalle interna que para el examen de una especificación funcional del STOE durante una evaluación bajo la Norma
ISO/IEC 15408.
ASD_IFS.1-1 El evaluador debe examinar la especificación funcional de la interfaz para confirmar que identifica y
describe todas las interfaces visibles del STOE, las propiedades de seguridad de esas interfaces y las funciones de
seguridad accesibles a través de esas interfaces.
ASD_IFS.1-2 El evaluador debe examinar la especificación funcional de la interfaz para confirmar que es consisten-
te internamente.
D.5.4.2.2 Acción ASD_IFS.1.2E

Esta acción requiere que el evaluador confirme que la especificación funcional de la interfase es consistente con la des-
cripción de la arquitectura y está compuesta por una unidad de trabajo. La acción fracasa si la unidad de trabajo no
ASD_IFS.1-3 El evaluador debe confirmar que la especificación funcional de la interfaz es consistente con la
descripción de la arquitectura.
Si la especificación funcional de la interfaz se refiere a interfaces que no puedan identificarse dentro de la descripción
de la arquitectura, se incumple esta unidad de trabajo.
D.5.5 Diseño del STOE (ASD_STD)

Esta familia contiene tres componentes jerárquicos, ASD_STD.1 Diseño del subsistema, ASD_STD.2 Diseño del com-
ponente y ASD_STD.3 Representación del diseño más la implantación.
D.5.5.2 Evaluación de la subactividad ASD_STD.1
D.5.5.2.1 Acción ASD_STD.1.1E

Esta acción requiere que el evaluador examine en el diseño y mapeo del subsistema del diseño del subsistema a la des-
cripción de arquitectura su contenido y presentación y está compuesta por nueve unidades de trabajo. La acción fracasa
No es necesario que el diseño del subsistema sea un solo documento u ofrecer un nivel uniforme de detalle, siempre que
todas las unidades de trabajo siguientes puedan completarse utilizando la información suministrada.
No es necesario que el diseño del subsistema y la descripción de la arquitectura usen la misma descomposición
estructural o terminología, siempre que pueda determinarse la relación entre las dos representaciones a partir del mapeo
entre el diseño del subsistema y la descripción de la arquitectura.
ASD_STD.1-1 El evaluador debe examinar el diseño de los subsistemas para confirmar que describe la funcionalidad
de seguridad que ofrece cada subsistema.
Se recuerda al evaluador que esto incluye tanto la funcionalidad de seguridad técnica como la operacional.
ASD_STD.1-2 El evaluador debe examinar el diseño de los subsistemas para confirmar que identifica todo el
hardware, firmware y software requeridos por la funcionalidad de seguridad asignada al subsistema.
ASD_STD.1-3 El evaluador debe examinar el diseño de los subsistemas para confirmar que identifica las interfaces
para cada subsistema.
- 211 - ISO/IEC TR 19791:2010
ASD_STD.1-4 El evaluador debe examinar el diseño de los subsistemas para confirmar que identifica las propie-
dades de seguridad para cada subsistema.
ASD_STD.1-5 El evaluador debe examinar el diseño de los subsistemas para confirmar que describe las interfaces de
cada subsistema, en términos de su propósito y método de uso de los efectos, excepciones y mensajes de error.
ASD_STD.1-6 El evaluador debe examinar el diseño de los subsistemas para confirmar que identifica los componen-
tes a partir de los cuales se construye cada subsistema.
ASD_STD.1-7 El evaluador debe examinar el diseño de los subsistemas para confirmar que es coherente interna-
mente.
ASD_STD.1-8 El evaluador debe examinar el diseño de los subsistemas para confirmar que es una instanciación
completa de la funcionalidad de seguridad del STOE, incluyendo la funcionalidad específica del dominio.
El evaluador debería realizar un repaso completo a través de la declaración de requisitos de seguridad y cualquier requi-
sito de seguridad del dominio dentro del STOE para confirmar que cada SSF identificada dentro de esas declaraciones
de requisitos aparece como parte de la funcionalidad de seguridad descrita dentro del diseño de los subsistemas.
ASD_STD.1-9 El evaluador debe examinar el mapeo desde el diseño de los subsistemas a la descripción de la
arquitectura para confirmar que demuestra que todos los elementos de la descripción de la arquitectura están presentes
en el diseño del subsistema.
Si no puede identificarse cualquier aspecto de la descripción de la arquitectura del sistema operacional y sus subsiste-
mas dentro del diseño del subsistema, se incumple esta unidad de trabajo.

Esta acción requiere que el evaluador confirme que el diseño del subsistema es consistente con la descripción de la
arquitectura y la especificación funcional de la interfaz. Está compuesta por una unidad de trabajo. La acción fracasa si
la unidad de trabajo no confirma el requisito relevante.
ASD_STD.1-10 El evaluador debe confirmar que el diseño del subsistema es consistente con la descripción de la
La unidad de trabajo ASD_IFS.1-3 confirmará que todas las interfaces identificadas dentro de la especificación funcio-
nal de la interfaz están definidas dentro de la descripción de la arquitectura y la unidad de trabajo ASD_STD.1-9 por
tanto las habrá mapeado con el diseño del subsistema.
Si cualquier aspecto de la descripción de la arquitectura del sistema operacional y sus subsistemas, incluyendo las
definiciones de la interfaz, es inconsistente con el diseño del subsistema, se incumple esta unidad de trabajo.
Si cualquier aspecto de la descripción de las interfaces dentro de la descripción funcional de la interfaz es inconsistente
con el diseño del subsistema, se incumple esta unidad de trabajo.

Esta acción requiere que el evaluador examine en lo siguiente su contenido y presentación:
a) el diseño del subsistema y el diseño del componente;
b) el mapeo desde el diseño del componente al diseño y desde el diseño de los subsistemas a la descripción de la arqui-
tectura;
c) el análisis de consistencias de la especificación resumen del STOE.
ISO/IEC TR 19791:2010 - 212 -
Está compuesta por veinte unidades de trabajo. Las unidades de trabajo ASD_STD.2-1 a ASD_STD.2-9 son idénticas a
ASD_STD.1-1 a ASD_STD.1-9 respectivamente.
ASD_STD.2-10 El evaluador debe examinar el diseño del componente para confirmar que describe el propósito y
funciones de cada subsistema.
ASD_STD.2-11 El evaluador debe examinar el diseño del componente para confirmar que define las interrelaciones
entre los componentes de cada subsistema.
ASD_STD.2-12 El evaluador debe examinar el diseño del componente para confirmar que identifica las interfaces con
el subsistema del STOE que cumple cada componente.
ASD_STD.2-13 El evaluador debe examinar el diseño del componente para confirmar que describe las interfaces con
el subsistema del STOE que cumple cada componente en términos de su propósito y método de utilización.
ASD_STD.2-14 El evaluador debe examinar el diseño del componente para confirmar que describe la funcionalidad
de seguridad provista por cada componente.
ASD_STD.2-15 El evaluador debe examinar el diseño del componente para confirmar que identifica las propiedades
de seguridad para cada componente.
ASD_STD.2-16 El evaluador debe examinar el diseño del componente para confirmar que describe como se proveen
la funcionalidad y las propiedades de seguridad de cada componente.
ASD_STD.2-17 El evaluador debe examinar el diseño del componente para confirmar que es consistente interna-
mente.
ASD_STD.2-18 El evaluador debe examinar el diseño del componente para confirmar que ofrece una instanciación
completa de la funcionalidad de seguridad asignada a cada subsistema, incluyendo la funcionalidad específica del
dominio.
ASD_STD.2-19 El evaluador debe examinar el mapeo del diseño del componente para confirmar que demuestra que
todos los elementos del diseño del subsistema están presentes en el diseño del componente.
Si algún aspecto del diseño del subsistema no se repite o expande dentro del diseño del componente, se incumple esta
unidad de trabajo.
ASD_STD.2-20 El evaluador debe examinar el análisis de consistencia de la especificación resumen del STOE para
confirmar que demuestra que el diseño del componente es consistente con la descripción de implantación de las SSF en
la especificación resumen del STOE en el SST y cualesquiera especificaciones resumen del dominio del STOE.
La especificación resumen del STOE se considera una visión general de los asuntos de la implantación y por tanto el
diseño del componente debería ser más detallado y más exhaustivo en su descripción de la implantación de las SSF. El
análisis de consistencia debe demostrar que las dos descripciones no son inconsistentes en modo alguno y que no hay
nada especificado en la descripción del STOE de la implantación de las SSF que no esté presente en el diseño del
componente.

arquitectura y la especificación funcional de la interfaz. Está compuesta por una unidad de trabajo, ASD_STD.2-21 que
es idéntica a ASD_STD.1-10.
- 213 - ISO/IEC TR 19791:2010

Esta acción requiere que el evaluador confirme que el diseño del componente es consistente con el diseño del subsis-
tema y la especificación funcional de la interfaz. Está compuesta por una unidad de trabajo. La acción fracasa si la
ASD_STD.2-22 El evaluador debe confirmar que el diseño del componente es consistente con el diseño del
subsistema y la especificación funcional de la interfaz.
La unidad de trabajo ASD_IFS.2-3 confirmará que todas las interfaces identificadas dentro de la especificación funcio-
nal de la interfaz están definidas dentro de la descripción de la arquitectura y la unidad de trabajo ASD_STD.2-9 por
tanto las habrá mapeado con el diseño del subsistema.
Si cualquier aspecto del diseño del subsistema, incluyendo las definiciones de la interfaz, es inconsistente con el diseño
del componente, se incumple esta unidad de trabajo.
Si cualquier aspecto de la descripción de las interfaces dentro de la especificación funcional de la interfaz es inconsis-
tente con el diseño del componente, se incumple esta unidad de trabajo.

Esta acción requiere que el evaluador examine en lo siguiente su contenido y presentación:
a) el diseño del subsistema y el diseño del componente;
b) una representación de la implantación del diseño para componentes especificados;
c) el mapeo desde el diseño del componente al diseño y desde el diseño de los subsistemas a la descripción de la arqui-
tectura;
d) el análisis de consistencias de la especificación resumen del STOE.
Está compuesta por veintitrés unidades de trabajo. Las unidades de trabajo ASD_STD.3-1 a ASD_STD.3-9 son idénti-
cas a ASD_STD.1-1 a ASD_STD.1-9 respectivamente y las unidades de trabajo ASD_STD.3-10 a ASD_STD.3-20 son
idénticas a ASD_STD.2-10 a ASD_STD.2-20 respectivamente
ASD_STD.3-21 El evaluador debe examinar la representación de la implantación para confirmar que es una
implantación completa del diseño del componente para los componentes identificados, incluyendo toda funcionalidad y
propiedades de seguridad asignados a esos componentes.
Diferentes partes de la representación de la implantación pueden tomar diferentes formas: por ejemplo, un componente
puede presentarse como código fuente, otro como un script de configuración y un tercero como un procedimiento
detallado de seguridad.
ASD_STD.3-22 El evaluador debe examinar la representación de la implantación para confirmar que establece la
funcionalidad secundaria ofrecida por los componentes identificados en términos de sus requisitos concretos de
configuración.
Cualquiera que sea la forma de la representación de la implantación, si el componente contiene cualquier opción de
configuración o puede configurarse externamente, la representación de la implantación debería permitir la funcionalidad
precisa de seguridad ofrecida por el componente a ser determinado.
ISO/IEC TR 19791:2010 - 214 -
ASD_STD.3-23 El evaluador debe examinar la representación de la implantación para confirmar que es consistente
internamente.

arquitectura y la especificación funcional de la interfaz. Está compuesta por una unidad de trabajo, ASD_STD.3-24 que
es idéntica a ASD_STD.1-10.

Esta acción requiere que el evaluador confirme que el diseño del componente es consistente con el diseño del subsis-
tema y la especificación funcional de la interfaz. Está compuesta por una unidad de trabajo, ASD_STD.3-25 que es
idéntica a ASD_STD.2-22.
D.5.6 Verificación de requisitos (ASD_RVR)

D.5.6.2 Evaluación de la subactividad ASD_RVR.1
D.5.6.2.1 Acción ASD_RVR.1.1E

Esta acción requiere que el evaluador examine en el análisis de verificación de requisitos su contenido y presentación.
Este análisis lo realiza el desarrollador o integrador del sistema después de cambios o modificaciones a los riesgos de
los que se ocupa el sistema operacional o a otras limitaciones en su evaluación. Está compuesta por cuatro unidades de
ASD_RVR.1-1 El evaluador debe examinar el análisis de verificación de requisitos para confirmar que la definición
del problema de seguridad dentro del SST no se ve afectado por cambios o modificaciones en los riesgos o que ha sido
correctamente actualizado para reflejar los cambios o modificaciones.
Si el análisis de verificación de requisitos declara que no ha habido cambios o modificaciones en los riesgos, se cumple
ASD_RVR.1-2 El evaluador debe examinar el análisis de verificación de requisitos para confirmar que los objetivos
funcionales de seguridad dentro del SST no se ven afectado por cambios o modificaciones en la definición del problema
de seguridad o que han sido correctamente actualizados para reflejar los cambios o modificaciones requeridos.
Si el análisis de verificación de requisitos muestra que no ha habido cambios o modificaciones en la definición del
problema de seguridad dentro del SST, se cumple esta unidad de trabajo.
ASD_RVR.1-3 El evaluador debe examinar el análisis de verificación de requisitos para confirmar que los objetivos
de garantía de seguridad declarados dentro del SST siguen siendo válidos o que han sido correctamente actualizados
para reflejar los cambios o modificaciones requeridos.
Si el análisis de verificación de requisitos declara que no ha habido cambios o modificaciones en las razones para elegir
los objetivos de garantía de seguridad, se cumple esta unidad de trabajo.
ASD_RVR.1-4 El evaluador debe examinar el análisis de verificación de requisitos para confirmar que las SSF y las
SSA reflejan correctamente los objetivos actuales de seguridad declarados dentro del SST.
Si el análisis de verificación de requisitos muestra que no ha habido cambios o modificaciones en los objetivos de
seguridad declarados dentro del SST, se cumple esta unidad de trabajo.
- 215 - ISO/IEC TR 19791:2010
D.5.7 Verificación del diseño (ASD_DVR)

D.5.7.2 Evaluación de la subactividad ASD_DVR.1
D.5.7.2.1 Acción ASD_DVR.1.1E

Esta acción requiere que el evaluador examine en el análisis de verificación del diseño su contenido y presentación. Este
análisis lo realiza el desarrollador o integrador del sistema después de cambios o modificaciones en los componentes del
sistema. Está compuesta por una unidad de trabajo. La acción fracasa si la unidad de trabajo no confirma el requisito
relevante.
ASD_DVR.1-1 El evaluador debe examinar el análisis de verificación del diseño para confirmar que ningún docu-
mento de diseño se ve afectado por los cambios o modificaciones en los componentes del sistema o que han sido correc-
tamente actualizados para reflejar los cambios o modificaciones.
Los documentos de diseño incluyen la descripción de la arquitectura, la especificación funcional de la interfaz, el diseño
del subsistema y el concepto de seguridad de operaciones. El diseño del componente y la representación de la implantación
están asimismo incluidos si están presentes componentes relevantes de nievl superior de ASD_STD dentro del SST.
D.6 Clase AOC: Gestión de la configuración del sistema operacional
D.6.1 Introducción
El propósito de la clase gestión de la configuración del sistema operacional es ofrecer garantías de que el sistema insta-
lado en el entorno operacional está configurado correctamente y que si el sistema se modifica posteriormente, los cam-
bios relevantes están bajo el control de CM.
Hay tres familias dentro de esta clase, ocupándose de la gestión del sistema operacional una vez instalado en su entorno
operacional y de la configuración y garantía de los productos COTS evaluados o no.
D.6.2 Configuración del sistema operacional (AOC_OBM)

Esta familia contiene dos componentes jerárquicos, AOC_OBM.1 Configuración del sistema operacional y
AOC_OBM.2 Verificación de la configuración del sistema operacional.
D.6.2.2 Evaluación de la subactividad AOC_OBM.1
D.6.2.2.1 Acción AOC_OBM.1.1E

Esta acción requiere que el evaluador examine en el plan de CM y el uso del sistema de CM su contenido y presenta-
ción y está compuesta por cuatro unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no
AOC_OBM.1-1 El evaluador debe examinar el plan de CM para confirmar que describe cómo se configuró el STOE
durante la instalación.
AOC_OBM.1-2 El evaluador debe examinar el plan de CM para confirmar que describe cómo se verifican y controlan
los cambios en el STOE instalado.
ISO/IEC TR 19791:2010 - 216 -
AOC_OBM.1-3 El evaluador debe examinar el plan de CM para confirmar que incluye las opciones de configuración
del STOE instalado.
El sistema de CM no tiene que estar automatizado: cualquier mecanismo es suficiente siempre que pueda determinarse
cómo están instaladas las opciones de configuración del sistema. Igualmente, no es necesario determinar las opciones
reales de configuración, solo que están registradas o lo estarán.
AOC_OBM.1-4 El evaluador debe examinar el plan de CM para confirmar que identifica de forma única el STOE
instalado, cada cambio asociado y el estado de su evaluación.
No es necesario que el evaluador determine los cambios reales realizados al sistema instalado, solo que están registra-
dos o lo estarán, junto con el estado de su evaluación.
D.6.2.3 Evaluación de la subactividad AOC_OBM.2

Esta acción requiere que el evaluador examine en el plan de CM y el uso del sistema de CM su contenido y presen-
tación y está compuesta por cuatro unidades de trabajo, de la AOC_OBM.2-1 a la AOC_OBM.2-4. Éstas son idénticas a
AOC_OBM.1-1 a la AOC_OBM.1-4 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que el STOE instalado es o será consistente con el
plan y el sistema de CM y está compuesta por una unidad de trabajo.
AOC_OBM.2-5 El evaluador debe verificar independientemente el STOE instalado respecto del plan y el sistema de CM.
Esta actividad solo tiene que realizarse una vez y esto puede hacerse antes de que el sistema operacional nuevo o modi-
ficado entre a operar en real. Sin embargo, en este caso, los procedimientos de modificación de cambios deberían verifi-
carse en el entorno de desarrollo para confirmar que son consistentes con el plan de CM y que el sistema de CM infor-
mará del estado correcto de construcción y configuración.
El evaluador debería seleccionar un método de verificación apropiado y eficiente, como verificar los registros de insta-
lación y modificación frente al estado real del sistema, reconstruir independientemente el sistema y verificar la consis-
tencia, u otros métodos apropiados.
Si se encuentran evidencias de que la configuración o el estado de cambio del sistema instalado son inconsistentes con
el plan de CM o el informa del sistema de CM o lo serán tras los cambios futuros, se incumple la acción de evaluación.
D.6.3 Productos del componente evaluado (AOC_ECP)

Esta familia contiene dos componentes jerárquicos, AOC_ECP.1 Productos del componente evaluado y AOC_ECP.2
Verificación de productos del componente evaluado.
D.6.3.2 Evaluación de la subactividad AOC_ECP.1
D.6.3.2.1 Acción AOC_ECP.1.1E

Esta acción requiere que el evaluador examine en los resultados de los productos evaluados su contenido y presentación
y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no confirma
el requisito relevante.
AOC_ECP.1-1 El evaluador debe examinar el plan de CM para confirmar que los parámetros operacionales para
cada producto evaluado están configurados de acuerdo con sus procedimientos preparatorios.
- 217 - ISO/IEC TR 19791:2010
Esta unidad de trabajo se satisface sin examen del plan de CM si un producto no tiene opciones de configuración identi-
ficadas en sus procedimientos preparatorios.
AOC_ECP.1-2 Para cada producto evaluado, el evaluador debe examinar el informe independiente de certificación o
Informe Técnico de Evaluación para confirmar que se satisfacen los paquetes de aseguramiento requeridos.
Advertir que los requisitos de garantía están especificados para la totalidad del sistema operacional o en términos de
dominios individuales de seguridad. Si otros productos o componentes del sistema contribuyen a la garantía del sistema
o el dominio, esta unidad de trabajo solo debería considerar la contribución pretendida de cada producto evaluado a esa
garantía como se identifica en el SST.
D.6.3.2.2 Acción AOC_ECP.2.1E

Esta acción requiere que el evaluador examine en los paquetes de garantía y los resultados de la evaluación de pro-
ductos evaluados su contenido y presentación y está compuesta por dos unidades de trabajo, de la AOC_ECP.2-1 a la
AOC_ECP.2-2. Éstas son idénticas a AOC_ECP.1-1 a la AOC_ECP.1-2 respectivamente.

Esta acción requiere que el evaluador confirme independientemente que el entorno operacional del STOE sea consis-
tente con las suposiciones del entorno y otras condiciones supuestas en la evaluación del producto. Está compuesta por
una unidad de trabajo.
AOC_ECP.2-3 El evaluador debe confirmar que las suposiciones acerca del entorno operacional descrito en los
informes independientes de certificación o Informes Técnicos de Evaluación de los productos evaluados cumple con los
requisitos del entorno operacional del STOE.
Al realizar esta unidad de trabajo, el evaluador debería tener en cuenta las opciones de configuración especificadas en el
plan de CM. Dependiendo del formato y la exhaustividad de los resultados de la evaluación, esta unidad de trabajo
puede completarse con un simple chequeo de suposiciones frente a requisitos o puede requerir un examen mayor, más
detallado, de los resultados de la evaluación por parte del evaluador.
Si se encuentran evidencias de que el entorno supuesto por los productos es inconsistente con el entorno operacional
real, se incumple la acción de evaluación.
D.6.4 Productos del componente no evaluado (AOC_UCP)

Esta familia contiene dos componentes jerárquicos, AOC_UCP.1 Productos del componente no evaluado y
AOC_UCP.2 Verificación de productos del componente no evaluado.
D.6.4.2 Evaluación de la subactividad AOC_UCP.1
D.6.4.2.1 Acción AOC_UCP.1.1E

Esta acción requiere que el evaluador examine en la documentación de configuración y las declaraciones de seguridad
para productos no evaluados su contenido y presentación y está compuesta por cuatro unidades de trabajo. La acción
fracasa si cualquiera de las unidades de trabajo no confirma el requisito relevante.
AOC_UCP.1-1 El evaluador debe examinar el plan de CM para confirmar que los parámetros operacionales para
cada producto no evaluado están configurados de acuerdo con su documentación de configuración.
Esta unidad de trabajo se satisface sin examen del plan de CM si un producto no tiene opciones de configuración identi-
ficadas en su documentación de configuración que generen una configuración insegura del sistema.
ISO/IEC TR 19791:2010 - 218 -
AOC_UCP.1-2 Para cada producto no evaluado, el evaluador debe examinar las declaraciones de seguridad para con-
firmar que, si se cumplen éstas, se satisfacen los paquetes de garantía requeridos.
Advertir que los requisitos de garantía están especificados para la totalidad del sistema operacional o en términos de
dominios individuales de seguridad. Si otros productos o componentes del sistema contribuyen a la garantía del sistema
o el dominio, esta unidad de trabajo solo debería considerar la contribución pretendida de cada producto evaluado a esa
garantía como se identifica en el SST.
D.6.4.3 Evaluación de la subactividad AOC_UCP.2

Esta acción requiere que el evaluador examine en la documentación de configuración y las declaraciones de seguridad
para productos no evaluados su contenido y presentación y está compuesta por dos unidades de trabajo, de la
AOC_UCP.2-1 a la AOC_UCP.2-2. Éstas son idénticas a AOC_UCP.1-1 a la AOC_UCP.1-2 respectivamente.

Esta acción requiere que el evaluador confirme independientemente que los productos no evaluados ofrecen las garan-
tías requeridas para una evaluación con éxito del sistema operacional. Está compuesta por una unidad de trabajo.
AOC_UCP.2-3 El evaluador debe realizar la evaluación del producto y confirmar que los productos no evaluados
cumplen con los paquetes de garantía requeridos bajo el entorno operacional del STOE.
Al realizar esta unidad de trabajo, el evaluador debería tener en cuenta las opciones de configuración especificadas en el
plan de CM. La evaluación del producto debería realizarse de acuerdo con la Norma ISO/IEC 15408 y utilizando la
Norma ISO/IEC 18045 y gestionarse como una actividad de evaluación separada e independiente.
Si se encuentran evidencias de que cualquier producto no ofrece la garantía requerida, se incumple la acción de evaluación.
D.7 Clase AOT: Pruebas del sistema operacional
D.7.1 Introducción
El propósito de la clase pruebas del sistema operacional es verificar mediante pruebas que los componentes del sistema
operacional, cuando se instalen, integren y configuren de acuerdo con la arquitectura del sistema operacional y la
evidencia de configuración del sistema operacional, cumplirán con los requisitos funcionales de seguridad especificados
en el SST.
Hay cinco familias dentro de esta clase. Las primeras cuatro trabajan juntas para especificar pruebas del desarrollador
durante el desarrollo e integración del sistema. AOT_COV se utiliza para especificar el grado de cobertura de las prue-
bas del desarrollador. AOT_DPT se usa para especificar los materiales de desarrollo utilizados para controlar la profun-
didad de las pruebas del desarrollador AOT_FUN se utiliza para verificar las pruebas realizadas por el desarrollador y
AOT_IND para especificar pruebas independientes adicionales del evaluador. La última familia, AOT_REG se usa para
especificar pruebas de regresión a realizar tras cambios al sistema operacional en su entorno operacional.
La cobertura y profundidad de las pruebas del desarrollador están separadas del examen real de los resultados de la
prueba para aumentar la flexibilidad de los criterios. Sin embargo, los requisitos de las familias se dirigen a aplicarse
juntos. Esto lleva a algunas dependencias entre acciones del evaluador a lo largo de las distintas subactividades.
D.7.2 Cobertura de pruebas del sistema operacional (AOT_COV)

Esta familia contiene dos componentes jerárquicos, AOT_COV.1 Evidencia de cobertura y AOT_COV.2 Análisis
riguroso de la cobertura.
- 219 - ISO/IEC TR 19791:2010
D.7.2.2 Evaluación de la subactividad AOT_COV.1
D.7.2.2.1 Acción AOT_COV.1.1E

Esta acción requiere que el evaluador examine en el análisis de la cobertura de prueba su contenido y presentación y
está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no confirma
el requisito relevante.
AOT_COV.1-1 El evaluador debe examinar el análisis de la cobertura de prueba para confirmar la correspondencia
entre las pruebas identificadas en la documentación de las pruebas y el SSF accesible a través de las interfaces del
sistema operacional tal y como se describen en la especificación funcional de la interfaz.
La correspondencia se muestra mejor creando una matriz o tabla, si no se proporciona una. No todas las pruebas nece-
sitan un mapeo a las SSF accesibles.
AOT_COV.1-2 El evaluador debe examinar el análisis de la cobertura de prueba para confirmar que han sido proba-
das todas las SSF accesibles a través de interfaces visibles del sistema operacional descritas en la especificación funcio-
nal de la interfaz.
Deben probarse todas las SSF accesibles, aunque las pruebas no tienen que revisar todas las opciones y parámetros de
cada interfaz.
D.7.2.3 Evaluación de la subactividad AOT_COV.2
D.7.2.3.1 Acción AOT_COV.2.1E

Esta acción requiere que el evaluador examine en el análisis de la cobertura de prueba su contenido y presentación y
está compuesta por dos unidades de trabajo. La unidad de trabajo AOT_COV.2-1 es idéntica a AOT_COV.1-1.
AOT_COV.2-2 El evaluador debe examinar el análisis de la cobertura de prueba para confirmar que han sido comple-
tamente probadas todas las SSF accesibles a través de interfaces visibles del sistema operacional descritas en la especi-
ficación funcional de la interfaz.
Deben probarse todas las SSF accesibles, incluyendo todas las opciones y parámetros relacionados con cada SSF. Sin
embargo, no tienen que probarse todos los valores y parámetros, solo todos los casos funcionales.
D.7.3 Profundidad de las pruebas del sistema operacional (AOT_DPT)

Esta familia contiene tres componentes jerárquicos, AOT_DPT.1 Pruebas: diseño del subsistema, AOT_DPT.2 Pruebas:
diseño del componente y AOT_DPT.3 Pruebas: representación de la implantación.
D.7.3.2 Evaluación de la subactividad AOT_DPT.1
D.7.3.2.1 Acción AOT_DPT.1.1E

Esta acción requiere que el evaluador examine en el análisis de la profundidad de las pruebas su contenido y presenta-
ción y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no
AOT_DPT.1-1 El evaluador debe examinar el análisis de la profundidad de las pruebas para confirmar la corres-
pondencia entre las pruebas identificadas en la documentación de las pruebas y los subsistemas del STOE identificados
en el diseño del subsistema.
La correspondencia se muestra mejor creando una matriz o tabla que muestre la relación entre pruebas y aspectos del
comportamiento de los subsistemas, si no se proporciona ninguna. No todas las pruebas necesitan un mapeo para la
verificación del comportamiento del subsistema, pero la identificación de las pruebas como aplicables a un comporta-
miento concreto no debe ser ambigua.
ISO/IEC TR 19791:2010 - 220 -
AOT_DPT.1-2 El evaluador debe examinar el análisis de la profundidad de las pruebas para confirmar que se han
probado todos los subsistemas del STOE identificados en el diseño del subsistema.
Esta unidad de trabajo verifica la completitud del mapeo producido en la unidad de trabajo AOT_DPT.1-1. Deben
probarse todas las descripciones del comportamiento del subsistema de la SSF y de las interacciones entre subsistemas
que se ofrecen en el diseño del subsistema, con pruebas concretas atribuibles a cada aspecto.

Esta acción requiere que el evaluador examine en el análisis de la profundidad de las pruebas su contenido y presen-
tación y está compuesta por tres unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no
AOT_DPT.2-1 El evaluador debe examinar el análisis de la profundidad de las pruebas para confirmar la correspon-
dencia entre las pruebas identificadas en la documentación de las pruebas y los subsistemas y componentes del STOE
identificados en el diseño del subsistema y el componente.
La correspondencia se muestra mejor creando matrices o tablas que muestren la relación entre pruebas y aspectos del
comportamiento del subsistema y componente, si no se proporciona ninguna. No todas las pruebas necesitan un mapeo
para la verificación del comportamiento del subsistema o componente y algunas pruebas pueden verificar el
comportamiento ambos niveles, pero la identificación de las pruebas como aplicables a un comportamiento concreto no
debe ser ambigua.
probado todos los subsistemas del STOE identificados en el diseño del subsistema.
Esta unidad de trabajo verifica parcialmente la completitud del mapeo producido en la unidad de trabajo AOT_DPT.2-1.
Deben probarse todas las descripciones del comportamiento del subsistema de la SSF y de las interacciones entre
subsistemas que se ofrecen en el diseño del subsistema, con pruebas concretas atribuibles a cada aspecto.
probado todos los componentes del STOE identificados en el diseño del componente.
Esta unidad de trabajo completa la verificación de la completitud del mapeo producido en la unidad de trabajo
AOT_DPT.2-1. Deben probarse todas las descripciones del comportamiento del componente de la SSF y de las interac-
ciones entre componentes que se ofrecen en el diseño del componente, con pruebas concretas atribuibles a cada aspecto.

Esta acción requiere que el evaluador examine en el análisis de la profundidad de las pruebas su contenido y presenta-
ción y está compuesta por cuatro unidades de trabajo, de la AOT_DPT.3-1 a la AOT_DPT.3-4. Las unidades de trabajo
AOT_DPT.3-1 a AOT_DPT.3-3 son idénticas a de la AOT_DPT.2-1 a AOT_DPT.2-3 respectivamente.
AOT_DPT.3-4 El evaluador debe examinar el análisis de la profundidad de las pruebas para confirmar la SSF para la
que se ofrece la representación de implantación opera de acuerdo con dicha representación.
El análisis debería mostrar que se han probado todos los aspectos de las representaciones de implantación, con pruebas
concretas atribuibles a cada aspecto. Para cada representación de implantación de SSF, el valuador debería identificar el
componente del que forma parte. El evaluador puede utilizar luego el mapa generado por la unidad de trabajo
AOT_DPT.3-1 para confirmar que hay pruebas atribuibles a ese componente que prueban todos los aspectos de la
representación de implantación.
- 221 - ISO/IEC TR 19791:2010
D.7.4 Pruebas funcionales del sistema operacional (AOT_FUN)

Esta familia contiene un solo componente, AOT_FUN.1 Pruebas funcionales.
D.7.4.2 Evaluación de la subactividad AOT_FUN.1
D.7.4.2.1 Acción AOT_FUN.1.1E

Esta acción requiere que el evaluador examine en la documentación de las pruebas del desarrollador su contenido y
presentación y está compuesta por cinco unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo
no confirma el requisito relevante.
AOT_FUN.1-1 El evaluador debe comprobar que la documentación de pruebas consta de planes de pruebas, resul-
tados esperados de pruebas y resultados reales de pruebas.
AOT_FUN.1-2 El evaluador debe examinar los planes de pruebas para confirmar que identifican las pruebas a reali-
zar, describen los escenarios para realizar cada prueba y que los escenarios incluyen cualquier dependencia ordenada de
los resultados de otras pruebas.
El evaluador puede emplear una estrategia de muestreo al llevar a cabo esta unidad de trabajo.
AOT_FUN.1-3 El evaluador debe examinar los resultados esperados de las pruebas para confirmar que muestran los
resultados previstos para la ejecución con éxito de las pruebas.
AOT_FUN.1-4 El evaluador debe examinar los resultados reales de las pruebas para confirmar que son consistentes
con los resultados esperados de las pruebas.
Puede ser que no pueda realizarse una comparación directa de los resultados reales y los esperados hasta que se realice
antes alguna reducción o síntesis de datos. En esos casos, la documentación de pruebas del desarrollador debería des-
cribir el proceso para transformar los datos y el evaluador debería confirmar que este proceso es correcto y se ha usado
para comparar los resultados reales frente a los esperados.
AOT_FUN.1-5 El evaluador debe examinar la documentación de las pruebas para confirmar que incluye un análisis
de las dependencias ordenadas del procedimiento de pruebas.
Esta unidad de trabajo también se satisface si la documentación de las pruebas no identifica dependencias ordenadas del
procedimiento de pruebas.
D.7.5 Pruebas independientes del sistema operacional (AOT_IND)

Esta familia contiene tres componentes jerárquicos, AOT_IND.1 Pruebas independientes - conformidad, AOT_IND.2
Pruebas independientes - ejemplo y AOT_IND.3 Pruebas independientes - completas.
D.7.5.2 Evaluación de la subactividad AOT_IND.1
D.7.5.2.1 Acción AOT_IND.1.1E

Esta acción requiere que el evaluador confirme que el STOE es apropiado para pruebas y está compuesta por dos
unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no confirma el requisito relevante.
ISO/IEC TR 19791:2010 - 222 -
AOT_IND.1-1 El evaluador debe confirmar que el STOE proporcionado y configurado por el desarrollador o
integrador del sistema es consistente con el STOE especificado en el SST.
En particular, el evaluador debería confirmar que la referencia del STOE del sistema proporcionado es la misma que la
referencia del STOE especificada en el SST.
AOT_IND.1-2 El evaluador debe confirmar que el STOE ha sido instalado apropiadamente en su entorno de pruebas
y está en un estado conocido.
El evaluador debería seleccionar un método apropiado para confirmar que el STOE ha sido instalado apropiadamente y
está en un estado conocido, como verificar los registros de instalación del desarrollador o reinstalar el sistema basán-
dose en la guía del usuario.

Esta acción requiere que el evaluador pruebe un subgrupo de las interfaces del STOE. Está compuesta por seis unidades
de trabajo. La acción fracasa si la unidad de trabajo AOT_IND.1-7 demuestra que alguna SSF no opera como está
especificado.
Puede obtenerse guía adicional sobre las unidades de trabajo dentro de la actividad de evaluación AOT_IND.1.2E del
examen de las unidades de trabajo de la Norma ISO/IEC 18045 para la acción de evaluación equivalente
ATE_IND.1.2E.
AOT_IND.1-3 El evaluador debe idear un subgrupo de pruebas.
El evaluador debería seleccionar un subgrupo de pruebas y una estrategia de pruebas que sean apropiados para el STOE,
teniendo en cuenta el equilibrio entre medidas de seguridad técnicas y operacionales. La actividad del evaluador
empleada en la actividad de prueba independiente debería ser proporcional con la empleada en cualquier otra actividad
de evaluación.
AOT_IND.1-4 El evaluador debe producir documentación de pruebas para el subgrupo de pruebas que sea suficien-
temente detallada como para permitir que las pruebas sean reproducibles.
La documentación de pruebas del evaluador debería especificar las consecuencias de cada prueba, remontándose a la(s)
interfase(s) relevante(s).
AOT_IND.1-5 El evaluador debe realizar las pruebas.
El evaluador debería usar la documentación de pruebas desarrollada en la unidad de trabajo AOT_IND.1-4 como base
para la ejecución de pruebas en el STOE. Esta documentación de las pruebas se usa como base para probar pero no im-
pide al evaluador realizar pruebas adicionales ad hoc. El evaluador puede idear nuevas pruebas basándose en el compor-
tamiento del STOE descubierto durante las pruebas. Estas nuevas pruebas se añaden a la documentación de las pruebas.
AOT_IND.1-6 El evaluador debe registrar la siguiente información acerca de las pruebas que comprenden el grupo
completo de pruebas independientes ejecutadas:
a) identificación del comportamiento de la interfaz a probar;
b) instrucciones para conectar y configurar todo el equipamiento de prueba como se requiera para realizar las pruebas;
c) instrucciones para establecer todas las condiciones de prueba prerrequeridas;
d) instrucciones para estimular la interfaz;
e) instrucciones para observar el comportamiento de la interfaz;
- 223 - ISO/IEC TR 19791:2010
f) descripciones de todos los resultados esperados y del análisis necesario a realizar en el comportamiento observado
en comparación con los resultados esperados;
g) instrucciones para concluir las pruebas y establecer el estado de post-prueba necesario para el STOE;
h) resultados reales de las pruebas.
El nivel de detalle debería ser tal que otro evaluador pudiera repetir las pruebas y obtener un resultado equivalente.
Aunque algunos detalles concretos de los resultados de las pruebas pueden ser distintos (por ejemplo, los campos de
hora y fecha en un registro de auditoría), el resultado general debería ser idéntico.
Puede haber casos en que sea innecesario proporcionar toda la información presentada en esta unidad de trabajo (por
ejemplo, los resultados reales de determinadas pruebas pueden no requerir ningún análisis antes de que pueda realizarse
una comparación entre los resultados esperados). La determinación de omitir esta información queda para el evaluador,
igual que la justificación.
AOT_IND.1-7 El evaluador debe verificar que todos los resultados reales de las pruebas son consistentes con los
resultados esperados de las pruebas.
Las inconsecuencias entre los resultados reales y esperados pueden indicar que el STOE no funciona como está especi-
ficado o que la documentación de pruebas del evaluador es incorrecta. Esto puede requerir mantenimiento correctivo del
STOE o la documentación de pruebas y tal vez reejecutar las pruebas impactadas y modificar el tamaño y composición
de la muestra de prueba. Esta determinación queda para el evaluador, igual que la justificación.
AOT_IND.1-8 El evaluador debe informar en el ETR el trabajo de prueba independiente del evaluador, indicando la
aproximación, configuración, profundidad y resultados de la prueba.

Esta acción requiere que el evaluador confirme que el STOE es apropiado para pruebas y está compuesta por tres
unidades de trabajo, de la AOT_IND.2-1 a la AOT_IND.2-3. Las unidades de trabajo AOT_IND.2-1 y AOT_IND.2-2
son idénticas a de la AOT_IND.1-1 y la AOT_IND.1-2 respectivamente.
AOT_IND.2-3 El evaluador debe confirmar que el grupo de recursos ofrecido por el desarrollador o integrador es
equivalente al grupo de recursos utilizados por el desarrollador o integrador para probar funcionalmente la SSF.
El grupo de recursos utilizado por el desarrollador está documentado en el plan de pruebas del desarrollador. El grupo
de recursos puede incluir accesos al laboratorio y equipos especiales de prueba, entre otros. Los recursos que no sean
idénticos a os utilizados por el desarrollador tienen que ser equivalentes en términos de cualquier impacto que puedan
tener en los resultados de las pruebas.

Esta acción requiere que el evaluador repita una muestra de pruebas en la documentación de pruebas del desarrollador
para verificar los resultados de las pruebas del desarrollador. Está compuesta por dos unidades de trabajo. La acción
fracasa si la unidad de trabajo AOT_IND.2-5 demuestra que algunas pruebas, al ser realizadas por el evaluador, pro-
ducen resultados distintos, que no tienen una explicación satisfactoria.
AOT_IND.2-4 El evaluador debe realizar pruebas utilizando una muestra de pruebas encontradas en el plan y
procedimientos de prueba del desarrollador.
ISO/IEC TR 19791:2010 - 224 -
El objetivo general de esta unidad de trabajo es realizar un número suficiente de pruebas del desarrollador para confir-
mar la validez de los resultados de las pruebas del desarrollador. El evaluador tiene que decidir el tamaño de la muestra
y las pruebas del desarrollador que compondrán la muestra.
Los factores a considerar en la selección de las pruebas al componer la muestra son similares a los de la selección del
subgrupo en la unidad de trabajo AOT_IND.2.6. Adicionalmente, el evaluador puede querer emplear un método de
muestreo al azar para seleccionar pruebas del desarrollador a incluir en la muestra.
AOT_IND.2-5 El evaluador debe verificar que todos los resultados reales de las pruebas son consistentes con los
resultados esperados de las pruebas.
Las inconsecuencias entre los resultados de las pruebas esperados por el desarrollador y los resultados reales de las
pruebas podrían ser resueltos por una explicación válida del desarrollador.
La resolución de inconsistencias puede requerir cambios en las pruebas del desarrollador o la creación de nuevas
pruebas por parte del evaluador a añadir al plan de pruebas de la unidad de trabajo AOT_IND.2-6.
Si no puede lograrse una explicación o resolución satisfactoria de algunas de las inconsistencias identificadas, puede ser
necesario que el evaluador aumente el tamaño de la muestra de la unidad de trabajo AOT_IND.2-4 para recuperar la
confianza en que todo el STOE fue probado adecuadamente por el desarrollador.

Esta acción requiere que el evaluador pruebe un subgrupo de las interfaces del STOE. Está compuesta por seis unidades
de trabajo, de la AOT_IND.2-6 a la AOT_IND.2-11, que son idénticas a de la AOT_IND.1-3 y la AOT_IND.1-8
respectivamente.
La acción fracasa si la unidad de trabajo AOT_IND.2-10 demuestra que alguna SSF no opera como está especificado.

Esta acción requiere que el evaluador confirme que el STOE es apropiado para pruebas y está compuesta por tres
unidades de trabajo, de la AOT_IND.3-1 a la AOT_IND.3-3. Las unidades de trabajo AOT_IND.3-1 y AOT_IND.3-2
son idénticas a de la AOT_IND.1-1 y la AOT_IND.1-2 respectivamente. La unidad de trabajo AOT_IND.3-3 es
idéntica a la AOT_IND.2-3.

Esta acción requiere que el evaluador repita todas las pruebas en la documentación de pruebas del desarrollador para
verificar los resultados de las pruebas del desarrollador. Está compuesta por dos unidades de trabajo, AOT_IND.3-4 y
AOT_IND.3-5. La unidad de trabajo AOT_IND.3-5 es idéntica a la AOT_IND.2-5. La acción fracasa si la unidad de
trabajo AOT_IND.3-5 demuestra que algunas pruebas, al ser realizadas por el evaluador, producen resultados distintos,
que no tienen una explicación satisfactoria.
AOT_IND.3-4 El evaluador debe realizar pruebas repitiendo todas las pruebas encontradas en el plan y
procedimientos de prueba del desarrollador.

Esta acción requiere que el evaluador pruebe todas las interfaces del STOE. Está compuesta por seis unidades de
trabajo, de la AOT_IND.3-6 a la AOT_IND.3-11, que son idénticas a de la AOT_IND.1-3 y la AOT_IND.1-8 respecti-
vamente.
- 225 - ISO/IEC TR 19791:2010
La acción fracasa si la unidad de trabajo AOT_IND.3-10 demuestra que alguna SSF no opera como está especificado.
En la unidad de trabajo AOT_IND.3-6 se requiere que el evaluador idee pruebas que cubran todas las interfaces del
STOE y eso confirmaría que toda la SSF opera como está especificado. Incluso con esta limitación, no podrían idearse
todas las pruebas posibles a incluir en el subgrupo de prueba elegido para su ejecución. La pruebas que no añadan nada
a los resultados de la evaluación deberían excluirse.
D.7.6 Pruebas de regresión del sistema operacional (AOT_REG)

Esta familia contiene un solo componente, AOT_REG.1 Pruebas de regresión.
D.7.6.2 Evaluación de la subactividad AOT_REG.1
D.7.6.2.1 Acción AOT_REG.1.1E

Esta acción requiere que el evaluador examine el análisis de las pruebas de regresión y las pruebas de regresión
realizadas por el desarrollador después de cambios o modificaciones del sistema al STOE en su entorno operacional.
Está compuesta por ocho unidades de trabajo. La acción fracasa si cualquiera de las unidades de trabajo no confirma el
AOT_REG.1-1 El evaluador debe verificar que el análisis de las pruebas de regresión identifica aquellas SSF que son
implementadas por áreas cambiadas o modificadas del STOE y los cambios pretendidos o no en el comportamiento de
esas SSF.
AOT_REG.1-2 El evaluador debe verificar que la documentación de las pruebas de regresión cubre aquellas SSF que
son implementadas por áreas cambiadas o modificadas del STOE.
Las SSF relevantes se identifican en el análisis de las pruebas de regresión.
AOT_REG.1-3 El evaluador debe verificar que la documentación de las pruebas de regresión consiste en planes de
pruebas, resultados esperados de las pruebas y resultados reales de las pruebas.
AOT_REG.1-4 El evaluador debe examinar los planes de pruebas para confirmar que identifican las pruebas a
realizar, describen los escenarios para realizar cada prueba y que los escenarios incluyen cualquier dependencia ordena-
da de los resultados de otras pruebas.
AOT_REG.1-5 El evaluador debe examinar los resultados esperados de las pruebas para confirmar que muestran los
resultados anticipados de una ejecución con éxito de las pruebas.
AOT_REG.1-6 El evaluador debe examinar los resultados reales de las pruebas para confirmar que son consistentes
con los resultados esperados de las pruebas.
Puede ser que no pueda realizarse una comparación directa de los resultados reales y los esperados hasta que se realice
antes alguna reducción o síntesis de datos. En esos casos, la documentación de pruebas del desarrollador debería des-
cribir el proceso para transformar los datos y el evaluador debería confirmar que este proceso es correcto y se ha usado
para comparar los resultados reales frente a los esperados.
AOT_REG.1-7 El evaluador debe examinar los resultados reales de las pruebas para confirmar que demuestran que
cada SSF probada se comportó como estaba especificado en el análisis de pruebas de regresión.
ISO/IEC TR 19791:2010 - 226 -
AOT_REG.1-8 El evaluador debe examinar la documentación de pruebas para confirmar que incluye un análisis de
las dependencias de orden del procedimiento de pruebas.
También se cumple con esta unidad de trabajo si la documentación de pruebas no identifica dependencias de orden del
procedimiento de pruebas.
D.8 Clase AOV: Evaluación de vulnerabilidades del sistema operacional
D.8.1 Introducción
El propósito de la clase evaluación de vulnerabilidades del sistema operacional es determinar si las potenciales vulnera-
bilidades dentro del STOE representan vulnerabilidades reales que podrían ser explotadas por un atacante.
Esta clase realiza una única función de evaluación y por tanto contiene una familia de componentes de garantía.
D.8.2 Análisis de vulnerabilidades (AOV_VAN)

Esta familia contiene siete componentes jerárquicos, AOV_VAN.1 Encuesta de vulnerabilidades de arquitectura,
AOV_VAN.2 Encuesta de vulnerabilidades avanzada, AOV_VAN.3 Análisis de vulnerabilidades de la interfaz,
AOV_VAN.4 Análisis de vulnerabilidades del diseño, AOV_VAN.5 Análisis enfocado de vulnerabilidades,
AOV_VAN.6 Análisis metódico de vulnerabilidades y AOV_VAN.7 Análisis metódico avanzado de vulnerabilidades.
D.8.2.2 Evaluación de la subactividad AOV_VAN.1
D.8.2.2.1 Acción AOV_VAN.1.1E

Esta acción requiere que el evaluador confirme que el STOE es apropiado para pruebas y está compuesta por dos unida-
des de trabajo. Estas unidades de trabajo son idénticas a AOT_IND.1-1 y AOT_IND.1-2, pero se repiten aquí ya que la
acción forma parte de una clase de evaluación diferente.
La acción fracasa si cualquiera de ambas unidades de trabajo no confirma el requisito relevante.
AOV_VAN.1-1 El evaluador debe confirmar que el STOE proporcionado y configurado por el desarrollador o
integrador del sistema es consistente con el STOE especificado en el SST.
En particular, el evaluador debería confirmar que la referencia del STOE del sistema proporcionado es la misma que la
referencia del STOE especificada en el SST.
AOV_VAN.1-2 El evaluador debe confirmar que el STOE ha sido instalado apropiadamente en su entorno de pruebas
y está en un estado conocido.
El evaluador debería seleccionar un método apropiado para confirmar que el STOE ha sido instalado apropiadamente y
está en un estado conocido, como verificar los registros de instalación del desarrollador o reinstalar el sistema
basándose en la guía del usuario.

Esta acción requiere que el evaluador realice una búsqueda de fuentes de dominio público para identificar posibles
vulnerabilidades en el STOE, basándose en la descripción de la arquitectura. Está compuesta por tres unidades de
trabajo.
- 227 - ISO/IEC TR 19791:2010
Puede obtenerse guía adicional sobre las unidades de trabajo dentro de la actividad de evaluación AOV_VAN.1.2E del
examen de las unidades de trabajo de la Norma ISO/IEC 18045 para la acción de evaluación equivalente AVA_VAN.1.2E.
AOV_VAN.1-3 El evaluador debe identificar potenciales vulnerabilidades en el STOE realizando una búsqueda en
fuentes de dominio público, basándose en la descripción de la arquitectura.
Hay disponibles muchas fuentes de información pública que deberían considerarse, por ejemplo, listas de correo y foros
de seguridad en la red global que informan de vulnerabilidades conocidas en tecnología concretas. Sin embargo, el
evaluador no debería limitar su consideración de información disponible públicamente a lo anterior, sino que debería
considerar cualquier otra información relevante disponible. Las herramientas modernas de búsqueda hacen que esa
información esté fácilmente disponible para el evaluador y puede conseguirse encontrar potenciales vulnerabilidades
publicadas y ataques genéricos bien conocidos de una forma eficaz en costes.
El evaluador debería registrar en el ETR las fuentes utilizadas para realizar la búsqueda de potenciales vulnerabilidades.
AOV_VAN.1-4 El evaluador debe considerar una a una cada una de las potenciales vulnerabilidades para determinar
si es candidata a una prueba de penetración.
El evaluador debería registrar las razones para la exclusión de mayores consideraciones sobre vulnerabilidades poten-
ciales. Por ejemplo, algunas potenciales vulnerabilidades no podrían explotarse en el contexto del STOE debido a con-
troles operacionales. No tendría ningún sentido probar dichas vulnerabilidades en un entorno de pruebas que no inclu-
yera esos controles.
AOV_VAN.1-5 El evaluador debe registrar en el ETR las vulnerabilidades potenciales encontradas que sean candi-
datas a pruebas de penetración.

Esta acción requiere que el evaluador pruebe potenciales vulnerabilidades para determinar si representan vulnerabilidades
reales en el STOE que pudieran ser explotadas por un atacante con un potencial de ataque Básico. Si no se encuentran
vulnerabilidades reales, se considera al STOE como resistente a ataques de atacantes con potencial de ataque Básico.
Esta acción está compuesta por ocho unidades de trabajo. La acción fracasa si la unidad de trabajo AOV_VAN.1-11
confirma que existen vulnerabilidades que puedan ser explotadas por un atacante con un potencial de ataque Básico.
Puede obtenerse guía adicional sobre las unidades de trabajo dentro de la actividad de evaluación AOV_VAN.1.3E del
examen de las unidades de trabajo de la Norma ISO/IEC 18045 para la acción de evaluación equivalente AVA_VAN.1.3E.
AOV_VAN.1-6 El evaluador debe idear pruebas de penetración, basadas en las vulnerabilidades potenciales
identificadas.
Probablemente el evaluador encuentre más práctico llevar a cabo pruebas de penetración utilizando una serie de casos
de prueba, en las que cada caso de prueba pruebe una vulnerabilidad potencial concreta.
AOV_VAN.1-7 El evaluador debe producir documentación de pruebas para las pruebas de penetración que sea
suficientemente detallada como para permitir que las pruebas sean reproducibles.
La documentación de pruebas del evaluador debería especificar las consecuencias de cada prueba, remontándose a las
potenciales vulnerabilidades a explotar.
AOV_VAN.1-8 El evaluador debe realizar pruebas de penetración.
El evaluador debería usar la documentación de pruebas desarrollada en la unidad de trabajo AOV_VAN.1-7 como base
para la ejecución de pruebas en el STOE. Esta documentación de las pruebas se usa como base para probar pero no im-
pide al evaluador realizar pruebas adicionales ad hoc. El evaluador puede idear nuevas pruebas basándose en el compor-
tamiento del STOE descubierto durante las pruebas. Estas nuevas pruebas se añaden a la documentación de las pruebas.
ISO/IEC TR 19791:2010 - 228 -
AOV_VAN.1-9 El evaluador debe registrar la siguiente información acerca de las pruebas que comprenden el grupo
completo de pruebas independientes ejecutadas:
a) identificación de la potencial vulnerabilidad o vulnerabilidades a probar;
b) instrucciones para conectar y configurar todo el equipamiento de prueba como se requiera para realizar las pruebas;
c) instrucciones para establecer todas las condiciones de prueba prerrequeridas;
d) instrucciones para estimular la SSF en cuestión;
e) instrucciones para observar el comportamiento de la SSF;
f) descripciones de todos los resultados esperados si existen vulnerabilidades y del análisis necesario a realizar en el
comportamiento observado en comparación con los resultados esperados;
g) instrucciones para concluir las pruebas y establecer el estado de post-prueba necesario para el STOE;
h) resultados reales de las pruebas.
El nivel de detalle debería ser tal que otro evaluador pudiera repetir las pruebas y obtener un resultado equivalente.
Aunque algunos detalles concretos de los resultados de las pruebas pueden ser distintos (por ejemplo, los campos de
hora y fecha en un registro de auditoría), el resultado general debería ser idéntico.
Puede haber casos en que sea innecesario proporcionar toda la información presentada en esta unidad de trabajo (por
ejemplo, los resultados reales de determinadas pruebas pueden no requerir ningún análisis antes de que pueda realizarse
una comparación entre los resultados esperados). La determinación de omitir esta información queda para el evaluador,
igual que la justificación.
AOV_VAN.1-10 El evaluador debe comparar los resultados reales de las pruebas con los resultados esperados de las
pruebas.
Las inconsistencias entre los resultados reales y esperados pueden indicar que no exista ninguna vulnerabilidad explota-
ble. También puede indicar que la documentación de pruebas del evaluador es incorrecta o inadecuada. Una documenta-
ción de prueba incorrecta puede requerir modificaciones y tal vez reejecutar las pruebas impactadas. El evaluador
debería considerar cuidadosamente si los resultados negativos de las pruebas podrían sugerir más pruebas relacionadas
que identifiquen y confirmen una vulnerabilidad explotable relacionada.
No se espera que el evaluador pruebe potenciales vulnerabilidades más allá de las que requieren un potencial de ataque
Básico. Sin embargo, en algunos casos, será necesario llevar a cabo una prueba antes de que pueda determinarse la
explotabilidad o una prueba puede indicar que una vulnerabilidad es explotable, pero solo con información o recursos
adicionales. Cuando, como resultado de la experiencia de evaluación, el evaluador descubra una vulnerabilidad que solo
es explotable con un potencial de ataque mayor que Básico, debería reportarse en el ETR como una vulnerabilidad
residual.
AOV_VAN.1-11 El evaluador debe examinar los resultados de las pruebas para determinar si el STOE es resistente a
un atacante que posea un potencial de ataque Básico.
Si los resultados demuestran que el STOE tiene vulnerabilidades que son explotables por un atacante que no posea un
potencial de ataque mayor que Básico, se incumple esta acción del evaluador.
Los factores a considerar al determinar si puede conseguirse un ataque con éxito sin un potencial de ataque mayor que
el Básico se indican en el anexo B.4 de la Norma ISO/IEC 18045.
AOV_VAN.1-12 El evaluador debe registrar en el ETR todas las vulnerabilidades explotables y residuales, detallando
para cada una:
- 229 - ISO/IEC TR 19791:2010
a) su fuente (es decir, el origen de su consideración como potencial vulnerabilidad);
b) el o los SFR incumplido(s);
c) una descripción de la vulnerabilidad;
d) si es explotable por una atacante con el potencial de ataque indicado o no (es decir, es explotable o residual);
e) la cantidad de tiempo, nivel de experiencia, nivel de conocimiento del STOE, nivel de oportunidad y equipamiento
requerido para explotar la vulnerabilidad identificada, utilizando los criterios dados en el anexo B.4 de la Norma
ISO/IEC 18045.
AOV_VAN.1-13 El evaluador debe reflejar en el ETR los trabajos de pruebas de penetración, diseñando la
aproximación, configuración, profundidad y resultados de las pruebas.

des de trabajo, AOV_VAN.2-1 y AOV_VAN.2-2. Son idénticas a AOV_VAN.1-1 y AOV_VAN.1-2 respectivamente.

Esta acción requiere que el evaluador realice una búsqueda de fuentes de dominio público para identificar vulnerabilida-
des potenciales en el STOE, basándose tanto en la descripción de la arquitectura como en el concepto de seguridad de la
documentación de operaciones. Esto permite una búsqueda más dirigida que la de AOV_VAN.1.2E. Está compuesta
por tres unidades de trabajo, de la AOV_VAN.2-3 a la AOV_VAN.2-5. Las unidades de trabajo AOV_VAN.2-4 y
AOV_VAN.2-5 son idénticas a las AOV_VAN.1-4 y AOV_VAN.1-5 respectivamente.
AOV_VAN.2-3 El evaluador debe identificar potenciales vulnerabilidades en el STOE realizando una búsqueda en
fuentes de dominio público, basándose en la descripción de la arquitectura y la documentación de los conceptos de
seguridad de las operaciones.
El evaluador debería usar la documentación de los conceptos de seguridad de las operaciones para buscar potenciales
vulnerabilidades basadas en problemas o vulnerabilidades conocidos en productos utilizados en el sistema operacional o
en productos o sistemas con características similares, particularmente en las siguientes áreas:
a) backup o modos degradados de operación;
b) opciones obligatorias de configuración de la seguridad;
c) propiedades seguridad aplicadas por un dominio sobre otros;
d) proceso de inicialización de la SSF;
e) protección contra la elusión de la funcionalidad de aplicación del SFR o la alteración de la SSF debido a entidades
externas;
f) protección contra la elusión, interferencia o alteración de la SSF debido a flujos de información entre dominios o
con sistemas operacionales externos.
ISO/IEC TR 19791:2010 - 230 -
Hay disponibles muchas fuentes de información pública que deberían considerarse, por ejemplo, listas de correo y foros
de seguridad en la red global que informan de vulnerabilidades conocidas en tecnología concretas. Sin embargo, el
evaluador no debería limitar su consideración de información disponible públicamente a lo anterior, sino que debería
considerar cualquier otra información relevante disponible. Las herramientas modernas de búsqueda hacen que esa
información esté fácilmente disponible para el evaluador y puede conseguirse encontrar potenciales vulnerabilidades
publicadas y ataques genéricos bien conocidos de una forma eficaz en costes.
El evaluador debería registrar en el ETR las fuentes utilizadas para realizar la búsqueda de potenciales vulnerabilidades
y los criterios de búsqueda identificados del examen de la descripción de la arquitectura y la documentación del
concepto de seguridad de operaciones.

Esta acción está compuesta por ocho unidades de trabajo, de la AOV_VAN.2-6 a la AOV_VAN.2-13. Son idénticas a
las AOV_VAN.1-6 y AOV_VAN.1-13 respectivamente.
La acción fracasa si la unidad de trabajo AOV_VAN.2-11 confirma que existen vulnerabilidades que puedan ser explo-
tadas por un atacante con un potencial de ataque Básico.


documentación de operaciones. Está compuesta por tres unidades de trabajo, de la AOV_VAN.3-3 a la AOV_VAN.3-5.
AOV_VAN.3-3 y AOV_VAN.3-4 son idénticas a las AOV_VAN.1-3 y AOV_VAN.1-4 respectivamente.
AOV_VAN.3-5 es idéntica a AOV_VAN.2-5.

Esta acción requiere que el evaluador realice un análisis independiente de vulnerabilidades. Está compuesta por cuatro
unidades de trabajo.
AOV_VAN.3-6 El evaluador debe preparar una lista de potenciales vulnerabilidades identificadas durante la realiza-
ción de otras actividades de evaluación.
Durante todas las demás actividades de evaluación, el evaluador debería estar tratando de encontrar potenciales
vulnerabilidades al desarrollar la comprensión del sistema operacional y mediante el cuestionamiento continuo de las
evidencias. Es el verdadero propósito de estas actividades de evaluación.
AOV_VAN.3-7 El evaluador debe realizar una búsqueda el SST, descripción de arquitectura, documentación del
concepto de seguridad de operaciones, especificación funcional de la interfaz y documentación de guía del usuario para
identificar otras potenciales vulnerabilidades en el STOE.
El evaluador debería usar su experiencia general de evaluación para hacer hipótesis e identificar otras vulnerabilidades
potenciales dentro del STOE, basándose en el examen de los documentos antes identificados.
- 231 - ISO/IEC TR 19791:2010
El evaluador debería considerar los siguientes tipos de ataques:
a) ataques de tipo genérico relevantes para el tipo de sistema operacional a evaluar;
b) elusión;
c) alteración;
d) ataques directos;
e) monitorización;
f) mal uso.
Los puntos b) a f) de la lista anterior se explican con mayor detalle en el anexo B.2 de la Norma ISO/IEC 18045.
AOV_VAN.3-8 El evaluador debe considerar una a una cada vulnerabilidad potencial identificada para determinar si
es candidata a una prueba de penetración.
El evaluador debería registrar las razones para la exclusión de mayores consideraciones sobre vulnerabilidades poten-
ciales. Por ejemplo, el análisis de una vulnerabilidad potencial podría establecer que harían falta habilidades potenciales
de ataque mayores que la Básica para explotarla con éxito.
Si se han identificado muchísimas vulnerabilidades, el evaluador puede necesitar priorizar la lista de vulnerabilidades
potenciales y rechazar como candidatas para pruebas de penetración aquellas vulnerabilidades potenciales que tengan
un probabilidad baja de ser realmente explotables con un potencial de ataque Básico o, si se explotan con éxito, ofrez-
can solo un compromiso muy limitado de los SFR.
AOV_VAN.3-9 El evaluador debe registrar en el ETR las vulnerabilidades potenciales identificadas que sean candi-
datas a pruebas de penetración.

Esta acción está compuesta por siete unidades de trabajo, de la AOV_VAN.3-10 a la AOV_VAN.3-16. Son idénticas a
las unidades de trabajo de la AOV_VAN.1-6 a la AOV_VAN.1-13 respectivamente.
La acción fracasa si la unidad de trabajo AOV_VAN.3-15 confirma que existen vulnerabilidades que puedan ser
explotadas por un atacante con un potencial de ataque Básico.


Las unidades de trabajo AOV_VAN.4-3 y AOV_VAN.4-4 son idénticas a las unidades de trabajo AOV_VAN.1-3 y
AOV_VAN.1-4 respectivamente. AOV_VAN.4-5 es idéntica a AOV_VAN.2-5.
ISO/IEC TR 19791:2010 - 232 -

unidades de trabajo, de la AOV_VAN.4-6 a la AOV_VAN.4-9. AOV_VAN.4-6 es idéntica a AOV_VAN.3-6 y
AOV_VAN.4-8 y AOV_VAN.4-9 son idénticas a AOV_VAN.3-8 y AOV_VAN.3-9 respectivamente.
AOV_VAN.4-7 El evaluador debe realizar una búsqueda el SST, descripción de arquitectura, documentación del
concepto de seguridad de operaciones, especificación funcional de la interfaz, toda la documentación de diseño
disponible y documentación de guía del usuario para identificar otras potenciales vulnerabilidades en el STOE.
La documentación de diseño siempre incluye el diseño del subsistema. También se busca en el diseño del componente y la
representación de implantación si están presentes componentes relevantes de mayor nivel de ASD_STD dentro del SST.
potenciales dentro del STOE, basándose en el examen de los documentos antes identificados y las decisiones de diseño
que registran.
b) elusión;
c) alteración;
e) monitorización;
f) mal uso.

Esta acción requiere que el evaluador pruebe las potenciales vulnerabilidades identificadas para determinar si represen-
tan vulnerabilidades reales en el STOE que pudieran ser explotadas por un atacante con un potencial de ataque Básico.
Si no se encuentran vulnerabilidades reales, se considera al STOE como resistente a ataques de atacantes con potencial
de ataque Básico.
Esta acción está compuesta por siete unidades de trabajo, de la AOV_VAN.4-10 a la AOV_VAN.4-16. Sin idénticas a
las unidades de trabajo de la AOV_VAN.1-6 a la AOV_VAN.1-13 respectivamente.
tadas por un atacante con un potencial de ataque Básico.

Esta acción requiere que el evaluador confirme que el STOE es apropiado para pruebas y está compuesta por dos
unidades de trabajo, AOV_VAN.5-1 y AOV_VAN.5-2. Estas unidades de trabajo son idénticas a AOV_VAN.1-1 y
AOV_VAN.1-2 respectivamente.
- 233 - ISO/IEC TR 19791:2010

AOV_VAN.5-3 y AOV_VAN.5-4 son idénticas a las unidades de trabajo AOV_VAN.1-3 y AOV_VAN.1-4 respecti-
vamente. AOV_VAN.5-5 es idéntica a AOV_VAN.2-5.

En la unidad de trabajo AOV_VAN.5-8, el evaluador debería tener en cuenta cuando considere las vulnerabilidades
potenciales que en esta subactividad de evaluación el STOE es evaluado por su resistencia al ataque por parte de
atacantes con un potencial de ataque Básico-Avanzado.
AOV_VAN.4-7 El evaluador debe realizar una búsqueda enfocada del SST, descripción de arquitectura, documenta-
ción del concepto de seguridad de operaciones, especificación funcional de la interfaz, toda la documentación de diseño
disponible y documentación de guía del usuario para identificar otras potenciales vulnerabilidades en el STOE.
Una búsqueda enfocada significa que la documentación entregada es analizada para identificar fallos potenciales en el
desarrollo del STOE y errores potenciales en el método especificado de operación del STOE que podrían indicar
vulnerabilidades potenciales.
que registran.
b) elusión;
c) alteración;
e) monitorización;
f) mal uso.
Se puede encontrar más información sobre búsqueda enfocada de vulnerabilidades en el anexo B.2.2.2.2 de la Norma
ISO/IEC 18045.

tan vulnerabilidades reales en el STOE que pudieran ser explotadas por un atacante con un potencial de ataque Básico-
Avanzado. Si no se encuentran vulnerabilidades reales, se considera al STOE como resistente a ataques de atacantes con
potencial de ataque Básico-Avanzado.
ISO/IEC TR 19791:2010 - 234 -
Esta acción está compuesta por siete unidades de trabajo, de la AOV_VAN.5-10 a la AOV_VAN.5-16. Las unidades de
trabajo AOV_VAN.5-10 a AOV_VAN.5-14 son idénticas a las unidades de trabajo de la AOV_VAN.1-6 a la
AOV_VAN.1-10 respectivamente y la unidad de trabajo AOV_VAN.5-16 es idéntica a la AOV_VAN.1-12.
tadas por un atacante con un potencial de ataque Básico-Avanzado.
En la unidad de trabajo AOV_VAN.5-14, el evaluador debería tener en cuenta cuando evalúa los resultados de las
pruebas que en esta subactividad de evaluación el STOE está siendo evaluado por su resistencia al ataque de atacantes
con un potencial de ataque hasta Básico-Avanzado. Por tanto, las vulnerabilidades explotables con potencial de ataque
Básico-Avanzado son vulnerabilidades reales. Solo las vulnerabilidades que requieran un potencial de ataque mayor que
Básico-Avanzado se informan en el ETR como vulnerabilidades residuales.
un atacante que posea un potencial de ataque Básico-Avanzado.
potencial de ataque mayor que Básico-Avanzado, se incumple esta acción del evaluador.
el Básico-Avanzado se indican en el anexo B.4 de la Norma ISO/IEC 18045.

des de trabajo, AOV_VAN.6-1 y AOV_VAN.6-2. Estas unidades de trabajo son idénticas a AOV_VAN.1-1 y

Esta acción requiere que el evaluador realice una búsqueda de fuentes de dominio público para identificar vulnerabili-
dades potenciales en el STOE, basándose tanto en la descripción de la arquitectura como en el concepto de seguridad de
la documentación de operaciones. Está compuesta por tres unidades de trabajo, de la AOV_VAN.6-3 a la
AOV_VAN.6-5. AOV_VAN.6-3 y AOV_VAN.6-4 son idénticas a las unidades de trabajo AOV_VAN.1-3 y
AOV_VAN.1-4 respectivamente. AOV_VAN.6-5 es idéntica a AOV_VAN.2-5.

En la unidad de trabajo AOV_VAN.6-8, el evaluador debería tener en cuenta cuando considere las vulnerabilidades po-
tenciales que en esta subactividad de evaluación el STOE es evaluado por su resistencia al ataque por parte de atacantes
con un potencial de ataque Moderado.
AOV_VAN.6-7 El evaluador debe realizar una búsqueda enfocada del SST, descripción de arquitectura, documen-
tación del concepto de seguridad de operaciones, especificación funcional de la interfaz, toda la documentación de
diseño disponible y documentación de guía del usuario para identificar otras potenciales vulnerabilidades en el STOE.
- 235 - ISO/IEC TR 19791:2010
Un análisis metódico requiere un examen estructurado de la evidencia provista. El evaluador debería por tanto especifi-
car la estructura y forma que tendrá en análisis antes de iniciarlo (es decir, la manera en que se realice el análisis está
predeterminada, al contrario que en una búsqueda enfocada). El método debería especificarse en término de la infor-
mación que se considerará y cómo y por qué será considerada.
Puede ser necesario modificar el método de análisis a medida que se desarrolla el examen, basándose en su efectividad
en la práctica. Cualquier cambio en el método debería especificarse apropiadamente y aplicarse consistentemente al
resto del análisis. Suponiendo que se realice un análisis metódico generalizado, no es necesario documentar ni el méto-
do de análisis planeado ni el final en el ETR.
que registran.
b) elusión;
c) alteración;
e) monitorización;
f) mal uso.
Se puede encontrar más información sobre análisis metódico de vulnerabilidades en el anexo B.2.2.2.3 de la Norma
ISO/IEC 18045.

tan vulnerabilidades reales en el STOE que pudieran ser explotadas por un atacante con un potencial de ataque hasta
Moderado. Si no se encuentran vulnerabilidades reales, se considera al STOE como resistente a ataques de atacantes
con potencial de ataque hasta Moderado.
La acción fracasa si la unidad de trabajo AOV_VAN.6-15 confirma que existen vulnerabilidades que puedan ser
explotadas por un atacante con un potencial de ataque hasta Moderado.
En la unidad de trabajo AOV_VAN.6-14, el evaluador debería tener en cuenta cuando evalúa los resultados de las prue-
bas que en esta evaluación de la subactividad el STOE está siendo evaluado por su resistencia al ataque de atacantes con
un potencial de ataque hasta Moderado. Por tanto, las vulnerabilidades explotables con potencial de ataque Moderado
son vulnerabilidades reales. Solo las vulnerabilidades que requieran un potencial de ataque mayor que Moderado se
informan en el ETR como vulnerabilidades residuales.
un atacante que posea un potencial de ataque Moderado.
ISO/IEC TR 19791:2010 - 236 -
potencial de ataque mayor que Moderado, se incumple esta acción del evaluador.
el Moderado se indican en el anexo B.4 de la Norma ISO/IEC 18045.

des de trabajo, AOV_VAN.7-1 y AOV_VAN.7-2. Estas unidades de trabajo son idénticas a AOV_VAN.1-1 y

AOV_VAN.7-3 y AOV_VAN.7-4 son idénticas a las unidades de trabajo AOV_VAN.1-3 y AOV_VAN.1-4
respectivamente. AOV_VAN.7-5 es idéntica a AOV_VAN.2-5.

AOV_VAN.7-8 y AOV_VAN.7-9 son idénticas a AOV_VAN.3-8 y AOV_VAN.3-9 respectivamente. AOV_VAN.7-7
es idéntica a AOV_VAN.6-7.
En la unidad de trabajo AOV_VAN.7-8, el evaluador debería tener en cuenta cuando considere las vulnerabilidades
potenciales que en esta subactividad de evaluación el STOE es evaluado por su resistencia al ataque por parte de atacan-
tes con un potencial de ataque Alto.

tan vulnerabilidades reales en el STOE que pudieran ser explotadas por un atacante con un potencial de ataque hasta
Alto. Si no se encuentran vulnerabilidades reales, se considera al STOE como resistente a ataques de atacantes con
potencial de ataque hasta Alto.
tadas por un atacante con un potencial de ataque hasta Alto.
En la unidad de trabajo AOV_VAN.7-14, el evaluador debería tener en cuenta cuando evalúa los resultados de las prue-
bas que en esta evaluación de la subactividad el STOE está siendo evaluado por su resistencia al ataque de atacantes con
un potencial de ataque hasta Alto. Por tanto, las vulnerabilidades explotables con potencial de ataque Alto son vul-
nerabilidades reales. Solo las vulnerabilidades que requieran un potencial de ataque mayor que Alto se informan en el
ETR como vulnerabilidades residuales.
un atacante que posea un potencial de ataque Alto.
- 237 - ISO/IEC TR 19791:2010
potencial de ataque mayor que Alto, se incumple esta acción del evaluador.
Los factores a considerar al determinar si puede conseguirse un ataque con éxito sin un potencial de ataque mayor que el
Alto se indican en el anexo B.4 de la Norma ISO/IEC 18045. Sin embargo, un potencial de ataque a este nivel de ataque
también dependerá de la naturaleza del STOE y puede verse influido por factores no considerados en el anexo B.4 de la
Norma ISO/IEC 18045. El Plan de Evaluación debería por tanto consultarse para más guías sobre esta subactividad.
D.9 Clase APR: Preparación para la operación en producción
D.9.1 Introducción
El propósito de la clase preparación para la operación en producción es confirmar que están implantadas estructuras y
procedimientos necesarios para permitir una instalación segura antes de que el sistema operacional entre en operación
en producción.
Hay tres familias en esta clase, ocupándose de la formación en concienciación, comunicación con los usuarios y verifi-
caciones de instalación segura.
D.9.2 Formación en concienciación (APR_AWA)

Esta familia contiene dos componentes jerárquicos, APR_AWA.1 Formación en concienciación y APR_AWA.2 Verifi-
cación de la formación en concienciación.
D.9.2.2 Evaluación de la subactividad APR_AWA.1
D.9.2.2.1 Acción APR_AWA.1.1E

Esta acción requiere que el evaluador examine en la formación en concienciación su contenido y presentación y está
compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no confirma el
APR_AWA.1-1 El evaluador debe confirmar que existen registros de formación en concienciación.
El evaluador debería verificar que los registros cubren todos los tipos de controles y todos los plazos especificados en el ST.
APR_AWA.1-2 El evaluador debe examinar los registros para confirmar que contienen fecha y hora, personal
autorizado, personal objetivo, contenidos y resultado de la formación.
D.9.2.3 Evaluación de la subactividad APR_AWA.2

Esta acción requiere que el evaluador examine en la formación en concienciación su contenido y presentación y está
compuesta por dos unidades de trabajo, APR_AWA.2-1 y APR_AWA.2-2. Estas unidades de trabajo son idénticas a
APR_AWA.1-1 y APR_AWA.1-2 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que ha tenido lugar la formación en concienciación.
Está compuesta por una unidad de trabajo.
APR_AWA.2-3 El evaluador debe verificar independientemente la veracidad de la realización de la formación en

concienciación.
ISO/IEC TR 19791:2010 - 238 -
El evaluador debería seleccionar un método apropiado y eficiente para verificar que se realizó la formación en concien-
ciación, como entrevistas personales con el personal registrado como formado, verificar materiales de formación de
ejemplo u otros métodos apropiados.
Si se encuentra evidencia de que el tipo de formación declarado no tuvo lugar, fracasa la acción de evaluación.
D.9.3 Comunicación (APR_CMM)

Esta familia contiene dos componentes jerárquicos, APR_CMM.1 Información sobre controles y APR_CMM.2 Verifi-
cación de la información sobre controles.
D.9.3.2 Evaluación de la subactividad APR_CMM.1
D.9.3.2.1 Acción APR_CMM.1.1E

Esta acción requiere que el evaluador examine en la comunicación de controles de seguridad su contenido y presenta-
ción y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de trabajo no
APR_CMM.1-1 El evaluador debe confirmar que existen registros de comunicación de controles de seguridad.
El evaluador debería verificar que los registros cubren todos los tipos de controles especificados en el ST.
APR_CMM.1-2 El evaluador debe examinar los registros para confirmar que contienen fecha y hora, personal
autorizado, personal objetivo y contenidos de la formación.
D.9.3.3 Evaluación de la subactividad APR_CMM.2

Esta acción requiere que el evaluador examine en la comunicación de controles de seguridad su contenido y presenta-
ción y está compuesta por dos unidades de trabajo, APR_CMM.2-1 y APR_CMM.2-2. Estas unidades de trabajo son
idénticas a APR_CMM.1-1 y APR_CMM.1-2 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que ha tenido lugar la formación en concienciación.
Está compuesta por una unidad de trabajo.
APR_CMM.2-3 El evaluador debe verificar independientemente la veracidad de la comunicación de los controles

operacionales.
El evaluador debería seleccionar un método apropiado y eficiente para verificar que se comunicaron los controles, como
entrevistas personales con el personal registrado como informado, verificar materiales de comunicación de ejemplo u
otros métodos apropiados.
Si se encuentra evidencia de que el tipo de comunicación de controles declarado no tuvo lugar, fracasa la acción de
evaluación.
D.9.4 Verificación de la instalación segura (APR_SIC)

Esta familia contiene dos componentes jerárquicos, APR_SIC.1 Verificación de la instalación segura y APR_SIC.2
Verificación de la verificación de la instalación segura.
- 239 - ISO/IEC TR 19791:2010
D.9.4.2 Evaluación de la subactividad APR_SIC.1
D.9.4.2.1 Acción APR_SIC.1.1E

Esta acción requiere que el evaluador examine en la documentación mostrando cómo verificar que se ha instalado con
seguridad el STOE su contenido y presentación y está compuesta por una unidad de trabajo. La acción fracasa si la uni-
dad de trabajo no confirma el requisito relevante.
APR_SIC.1-1 El evaluador debe examinar la documentación de procedimientos de instalación segura para confir-
mar que describe los pasos necesarios para la verificación de la instalación segura, puesta en marcha e interoperación
del STOE en su entorno.
D.9.4.3 Evaluación de la subactividad APR_SIC.2

Esta acción requiere que el evaluador examine en la documentación mostrando cómo verificar que se ha instalado con
seguridad el STOE su contenido y presentación y está compuesta por una unidad de trabajo, APR_SIC.2-1. Esta unidad
de trabajo es idéntica a APR_SIC.1-1.

Esta acción requiere que el evaluador verifique independientemente que el uso de procedimientos de instalación segura
produce una configuración segura. Está compuesta por una unidad de trabajo.
APR_SIC.2-2 El evaluador debe verificar que los procedimientos de instalación segura producen una configuración
segura.
El evaluador debería seleccionar un método apropiado y eficiente para verificar que el uso correcto de procedimientos
de instalación segura produce una configuración segura, como verificar registros de instalación real y las consecuentes
verificaciones de estado seguro, instalando independientemente el sistema y verificando que es seguro, u otros métodos
apropiados.
Si se encuentra evidencia de que el uso de procedimientos de instalación segura puede generar un sistema inseguro, fra-
casa la acción de evaluación.
D.10 Clase ASO: Registros del sistema operacional
D.10.1 Introducción
El propósito de la actividad de evaluación de registros del sistema operacional es confirmar que la gestión del sistema
esta monitorizando y verificando los controles del sistema operacional en producción.
Hay tres familias en esta clase, ocupándose de registrar, verificar y monitorizar los controles.
D.10.2 Registros de operación de controles operacionales (ASO_RCD)

Esta familia contiene dos componentes jerárquicos, ASO_RCD.1 Registro de controles operacionales y ASO_RCD.2
Verificación de registros operacionales.
ISO/IEC TR 19791:2010 - 240 -
D.10.2.2 Evaluación de la subactividad ASO_RCD.1
D.10.2.2.1 Acción ASO_RCD.1.1E

Esta acción requiere que el evaluador examine en los registros de operación de controles operacionales su contenido y
presentación y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas unidades de
trabajo no confirma el requisito relevante.
ASO_RCD.1-1 El evaluador debe confirmar que se registra la información asociada con la evidencia de operación de
El evaluador debería verificar que las evidencias cubren todos los tipos de controles especificados en el ST.
No se espera que el evaluador vea todas las evidencias con detalle, bastando con confirmar que están cubiertos todos los
tipos de controles requeridos.
ASO_RCD.1-2 El evaluador debe examinar los registros para confirmar que contienen fecha y hora, persona
responsable, controles operacionales objetivo y resultados de la operación.
D.10.2.3 Evaluación de la subactividad ASO_RCD.2

Esta acción requiere que el evaluador examine en los registros de operación de controles operacionales su contenido y
presentación y está compuesta por dos unidades de trabajo, ASO_RCD.2-1 y ASO_RCD.2-2. Estas unidades de trabajo
son idénticas a ASO_RCD.1-1 y ASO_RCD.1-2 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que se ha registrado correctamente la información
relativa a la operación de los controles operacionales. Está compuesta por una unidad de trabajo.
APR_AWA.2-3 El evaluador debe verificar independientemente que la información relativa a la operación de los con-
troles operacionales se está registrando correctamente.
El evaluador debería seleccionar un método apropiado y eficiente para verificar que se están registrando correctamente
las evidencias, como entrevistas personales con el personal responsable de registrar las evidencias, verificar registros de
ejemplo para su consistencia con el sistema en producción u otros métodos apropiados.
Si se encuentra evidencia de que la información no se está registrando correctamente, fracasa la acción de evaluación.
D.10.3 Verificación de los controles operacionales (ASO_VER)

Esta familia contiene dos componentes jerárquicos, ASO_VER.1 Verificación de controles operacionales y
ASO_VER.2 Verificación independiente de controles operacionales.
D.10.3.2 Evaluación de la subactividad ASO_VER.1
D.10.3.2.1 Acción ASO_VER.1.1E

Esta acción requiere que el evaluador examine en los registros verificación de operación de controles operacionales su
contenido y presentación y está compuesta por dos unidades de trabajo. La acción fracasa si cualquiera de ambas
unidades de trabajo no confirma el requisito relevante.
- 241 - ISO/IEC TR 19791:2010
ASO_VER.1-1 El evaluador debe confirmar que se registra la información asociada con la verificación de operación
de controles operacionales.
El evaluador debería verificar que las evidencias cubren todos los tipos de controles especificados en el ST.
ASO_VER.1-2 El evaluador debe examinar los registros para confirmar que contienen fecha y hora, persona
responsable, controles operacionales objetivo y resultados de la operación.
D.10.3.3 Evaluación de la subactividad ASO_VER.2

Esta acción requiere que el evaluador examine en los registros de verificación de operación de controles operacionales
su contenido y presentación y está compuesta por dos unidades de trabajo, ASO_VER.2-1 y ASO_VER.2-2. Estas uni-
dades de trabajo son idénticas a ASO_VER.1-1 y ASO_VER.1-2 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que se han instalado los controles operacionales y
están operando correcta y eficazmente. Está compuesta por una unidad de trabajo.
APR_VER.2-3 El evaluador debe verificar independientemente que los controles operacionales están instalados y
operando correcta y eficazmente.
El evaluador debería seleccionar un método apropiado y eficiente para verificar que los controles operacionales están
instalados y operando correcta y eficazmente, como entrevistas personales con el personal responsable de la operación
del sistema, verificar personalmente una muestra de controles del sistema en producción u otros métodos apropiados.
Si se encuentra evidencia de que los controles no se están usando o no funcionan, fracasa la acción de evaluación.
D.10.4 Monitorización de los controles operacionales (ASO_MON)

Esta familia contiene dos componentes jerárquicos, ASO_MON.1 Monitorización de controles operacionales por la
dirección y ASO_MON.2 Verificación de la monitorización de controles operacionales.
D.10.4.2 Evaluación de la subactividad ASO_MON.1
D.10.4.2.1 Acción ASO_MON.1.1E

Esta acción requiere que el evaluador examine en los registros monitorización de operación de controles operacionales
su contenido y presentación y está compuesta por tres unidades de trabajo. La acción fracasa si alguna de las unidades
de trabajo no confirma el requisito relevante.
ASO_MON.1-1 El evaluador debe confirmar que se registra la información asociada con la monitorización de opera-
ción de controles operacionales.
El evaluador debería verificar que las evidencias cubren los niveles de provisión y rendimiento de todos los tipos de
controles especificados en el ST y se realizan regularmente.
ISO/IEC TR 19791:2010 - 242 -
No se espera que el evaluador vea todas las evidencias con detalle, bastando con confirmar que la monitorización de to-
dos los tipos de controles requeridos se está llevando a cabo y en las circunstancias necesarias.
ASO_MON.1-2 El evaluador debe confirmar que se registra la información asociada con la monitorización de cam-
bios de provisión de servicios.
Los cambios en los servicios incluyen el mantenimiento y la mejora de la políticas, procedimientos y controles de segu-
ridad y deberían tener en cuenta la criticidad de los sistemas y procesos de negocio implicados y, cuando sea necesario,
la reevaluación de los riesgos.
No se espera que el evaluador vea todas las evidencias con detalle, bastando con confirmar que los cambios en la pro-
visión de servicios se están monitorizando.
ASO_MON.1-3 El evaluador debe examinar los registros para confirmar que contienen fecha y hora, persona
responsable, controles operacionales objetivo y resultados de la monitorización.
No se espera que el evaluador vea todas las evidencias con detalle, bastando con confirmar que se registran en general
los tipos relevantes de información.
D.10.4.3 Evaluación de la subactividad ASO_MON.2

Esta acción requiere que el evaluador examine en los registros de monitorización de operación de controles operacionales
su contenido y presentación y está compuesta por tres unidades de trabajo, de la ASO_MON.2-1 a la ASO_MON.2-3.
Éstas son idénticas a de la ASO_MON.1-1 a la ASO_MON.1-3 respectivamente.

Esta acción requiere que el evaluador verifique independientemente que se están monitorizado los controles operaciona-
les por parte de la dirección. Está compuesta por una unidad de trabajo.
APR_MON.2-4 El evaluador debe verificar independientemente que la monitorización se realiza de acuerdo con la
política de seguridad.
El evaluador debería seleccionar un método apropiado y eficiente para verificar que está teniendo lugar la monitoriza-
ción por la dirección de la provisión y rendimiento de controles operacionales y de cambios en la provisión de servicios,
como entrevistas personales con el personal responsable de monitorizar controles y cambios, verificar personalmente
que se han identificado controles y cambios fallidos u otros métodos apropiados.
Si se encuentra evidencia de que los controles no se están monitorizando de acuerdo con la política de seguridad, fra-
casa la acción de evaluación.
- 243 - ISO/IEC TR 19791:2010
BIBLIOGRAFÍA
[1] ISO/IEC 27005, Information technology. Security techniques. Information security risk management.
[2] Guide for the Security Certification and Accreditation of Federal Information Systems, NIST Special Publication
SP 800 37, Department of Commerce, United States.
[3] ISO/IEC 27002, Information technology. Security techniques. Code of practice for information security
management.
[4] Recommended Security Controls for Federal Information Systems, NIST Special Publication SP 800 53,
Department of Commerce, United States.
[5] ISO/IEC 21827, Information technology. Security techniques. Systems Security Engineering – Capability
Maturity Model® (SSE-CMM®).
[6] ISO/IEC TR 15443 (todas las partes), Information technology. Security techniques. A Framework for IT security
assurance.
[7] ISO/IEC TR 15446, Information technology. Security techniques. Guide for the production of Protection
Profiles and Security Targets.
[8] Guide for Assessing the Security Controls in Federal Information Systems, NIST Special Publication SP 800
53A, Department of Commerce, United States.
[9] IT Baseline Protection Manual, Bundesamt für Sicherheit in der Informationstechnik, Germany. ISBN
3-88784-915-9.
[10] Minimum Security Requirements for Federal Information and Information Systems, FIPS PUB 200, March 2006,
Department of Commerce, United States.
[11] Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, September 2007,
Common Criteria Development Board.
[12] ISO Guide 73:2002, Risk management. Vocabulary. Guidelines for use in standards1).
1) La Guía ISO 73:2002 ha sido anulada y sustituida por la Guía ISO 73:2009.
Génova, 6 info@aenor.es Tel.: 902 102 201
28004 MADRID-España www.aenor.es Fax: 913 104 032

Une-Iso - Iec TR 19791 - 2010

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Une-Iso - Iec TR 19791 - 2010

Cargado por

Copyright:

Formatos disponibles

informee UNE-ISO/IEC TR

TÍTULO Tecnoologías de la información

uación de la seguridad de sistemas operaccionales

Informatioon technology. Security techniques. Security assessment of operationaal systems.

Technologgies de l'information. Techniques de sécurité. Évaluation de la sécuritté des systèmes opérationnels.

CORRESPONDENCIA Este infforme es idéntico al Informe Técnico ISO/IEC TR 197911:2010.

ANTECEDENTES Este infforme ha sido elaborado por el comité técnico AEN/CT

Editada e impresa por AENOR LAS OBSE

© AENOR 2013 Génova, 6 info@aenor.es Tel.: 902 102 201

1 OBJETO Y CAMPO DE APLICACIÓN ............................................................................. 6

2 NORMAS PARA CONSULTA ............................................................................................. 7

3 TÉRMINOS Y DEFINICIONES .......................................................................................... 7

5 ESTRUCTURA DE ESTE INFORME TÉCNICO ............................................................. 9

6 APROXIMACIÓN TÉCNICA ............................................................................................ 10

7 EXTENDIENDO LOS CONCEPTOS DE EVALUACIÓN BAJO

8 RELACIÓN CON LAS NORMAS DE SEGURIDAD EXISTENTES ............................ 32

9 EVALUACIÓN DE SISTEMAS OPERACIONALES ..................................................... 34

ANEXO A (Normativo) PERFILES DE PROTECCIÓN Y OBJETIVOS

ANEXO B (Normativo) REQUISITOS DE CONTROL FUNCIONAL

ANEXO C (Normativo) REQUISITOS DE GARANTÍA

ANEXO D (Normativo) METODOLOGÍA DE EVALUACIÓN

BIBLIOGRAFÍA ................................................................................................................................. 243

ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica Internacional)

En circunstancias excepcionales, el comité técnico conjunto puede proponer la publicación de un informe

1 OBJETO Y CAMPO DE APLICACIÓN

Este informe técnico ofrece:

a) una definición y modelo para sistemas operacionales;

2 NORMAS PARA CONSULTA

3.2 sistema operacional externo:

3.3 controles de gestión:

3.4 controles operacionales:

3.5 sistema operacional:

3.6 riesgo residual:

[Guía ISO/IEC 73:2002]

3.8 análisis de riesgos:

[Guía ISO/IEC 73:2002]

3.9 evaluación del riesgo:

[Guía ISO/IEC 73:2002]

3.10 gestión del riesgo:

[Guía ISO/IEC 73:2002]

3.11 tratamiento del riesgo:

[Guía ISO/IEC 73:2002]

3.12 controles de seguridad:

3.13 dominio de seguridad:

3.15 sistema objeto de evaluación:

3.16 controles técnicos:

COTS Commercial Off The Shelf (Producto comercial)

OSF Operational Security Functionality (Funcionalidad de seguridad operacional)

SP Special Publication (Publicación especial)

SPP System Protection Profile (Perfil de protección del sistema)

SSA System Security Assurance (Nivel deAseguramiento de seguridad del sistema)

SSF System Security Functionality (Funcionalidad de seguridad del sistema)

SST System Security Target (Objetivo de seguridad del sistema)

STOE System Target of Evaluation (Objetivo de evaluación del sistema)

5 ESTRUCTURA DE ESTE INFORME TÉCNICO

6.1 La naturaleza de los sistemas operacionales

Sin embargo los sistemas operacionales normalmente:

− se construyen a partir de necesidades concretas, para un tipo de operación concreto;

− cambian frecuentemente, ya sea en aspectos técnicos o en requisitos operacionales;

− contienen un número considerable (o incluso elevado) de componentes;

− contiene componentes con distintos grados y tipos de garantía de seguridad.

6.2 Estableciendo la seguridad del sistema operacional

Conceptualmente este proceso, de tres pasos se muestra a continuación en la figura 1.