ISO _ IEC 15408 2 Español

12/6/2014 ISO / IEC 15408-2

http://translate.googleusercontent.com/translate_f 1/206

Página 1

Número de referenciaISO / IEC 15408-2:2008 (E)

©ISO / IEC 2008

INTERNACIONAL

ESTÁNDAR

ISO / IEC

15408-2

Tercera edición2008-08-15

Versión corregida2011-06-01

Tecnología de la información - Seguridad

Criterios de evaluación de TI - técnicas

seguridad -

Parte 2:

Componentes funcionales de seguridad

Tecnologías de información de l'- Técnicas de sécurité - Critèresd'évaluation pour la sécurité TI -

Partie 2: Composants fonctionnels de sécurité

12/6/2014 ISO / IEC 15408-2


Página 2

ISO / IEC 15408-2:2008 (E)

COPYRIGHT PROTEGIDO DOCUMENTO

© ISO / IEC 2008Todos los derechos reservados.A menos que se especifique lo contrario, ninguna parte de esta publicación puede ser reproducida o utilizada de ninguna forma ni por ningún medio,electrónico o mecánico, de fotocopia o de microfilm, sin previa autorización por escrito recibida de ISO en la dirección abajo oOrganismo miembro de ISO en el país del solicitante.

La oficina de derechos de autor ISOCase postale 56 • CH-1211 Ginebra 20Tel. + 41 22 749 01 11Fax + 41 22 749 09 47E-mail [email protected] www.iso.org

Publicado en Suiza

ii © ISO / IEC 2008 - Todos los derechos reservados

Página 3

ISO / IEC 15408-2:2008 (E)

Contenido Página

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados iii

Prefacio ........................................................................................................................................................xviii

Introduction.......................................................................................................................................................xx

1 Scope......................................................................................................................................................1

2 Normativo references............................................................................................................................1

3 Términos y definiciones, símbolos y abreviaturas .......................................... ......................... 1

4 Overview.................................................................................................................................................14.1 Organización de esta parte de la norma ISO / IEC 15408 ......................................... ................................................ 1

5 Requisitos funcionales paradigma .....................................................................................................2

6 Seguridad funcional components..........................................................................................................56.1 Overview.................................................................................................................................................56.1.1 La estructura de clases ......................................................................................................................................56.1.2 Familia structure.....................................................................................................................................66.1.3 Componente structure............................................................................................................................86.2 Componente catalogue...........................................................................................................................96.2.1 Cambios de componentes destacando .....................................................................................................10

7 Clase FAU: Seguridad audit...................................................................................................................107.1 Respuesta automática Auditoría de seguridad (FAU_ARP) ........................................... .................................... 117.1.1 Familia Behaviour.................................................................................................................................117.1.2 Nivelación de componentes ...........................................................................................................................117.1.3 Gestión de FAU_ARP.1 ...............................................................................................................117.1.4 Auditoría de FAU_ARP.1............................................................................................................................117.1.5 FAU_ARP.1 Seguridad alarms...............................................................................................................117.2 La generación de datos de auditoría de seguridad (FAU_GEN) ........................................... ........................................... 117.2.1 Familia Behaviour.................................................................................................................................117.2.2 Nivelación de componentes ...........................................................................................................................117.2.3 Gestión de FAU_GEN.1, FAU_GEN.2 ......................................... ................................................ 117.2.4 Auditoría de FAU_GEN.1, FAU_GEN.2 .....................................................................................................117.2.5 FAU_GEN.1 generación de los datos de auditoría ....................................................................................................127.2.6 Identidad del usuario FAU_GEN.2 association...............................................................................................127.3 Análisis de las auditorías de seguridad (FAU_SAA) ...................................................................................................127.3.1 Familia Behaviour.................................................................................................................................127.3.2 Nivelación de componentes ...........................................................................................................................127.3.3 Gestión de FAU_SAA.1 ...............................................................................................................137.3.4 Gestión de FAU_SAA.2 ...............................................................................................................137.3.5 Gestión de FAU_SAA.3 ...............................................................................................................137.3.6 Gestión de FAU_SAA.4 ...............................................................................................................137.3.7 Auditoría de FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4 ................................. ......................... 137.3.8 FAU_SAA.1 análisis Potencial violación ............................................ ............................................... 137.3.9 Perfil FAU_SAA.2 basado detección de anomalías ........................................... ....................................... 147.3.10 FAU_SAA.3 heurística simple ataque ......................................... .................................................. ..... 147.3.11 FAU_SAA.4 ataque Complex heuristics.............................................................................................157.4 Examen de auditoría de seguridad (FAU_SAR) ......................................................................................................157.4.1 Familia Behaviour.................................................................................................................................157.4.2 Nivelación de componentes ...........................................................................................................................157.4.3 Gestión de FAU_SAR.1 ...............................................................................................................157.4.4 Gestión de FAU_SAR.2, FAU_SAR.3 ......................................... ................................................ 157.4.5 Auditoría de FAU_SAR.1............................................................................................................................157.4.6 Auditoría de FAU_SAR.2............................................................................................................................167.4.7 Auditoría de FAU_SAR.3............................................................................................................................16

Página 4

ISO / IEC 15408-2:2008 (E)

7.4.8 Examen de auditoría FAU_SAR.1 ....................................................................................................................167.4.9 FAU_SAR.2 examen de auditoría restringido ............................................ .................................................. .... 167.4.10 revisión FAU_SAR.3 auditoría seleccionable ......................................... .................................................. ....... 167.5 Selección de eventos de auditoría de seguridad (FAU_SEL) ........................................... ............................................. 167.5.1 Familia Behaviour.................................................................................................................................167.5.2 Nivelación de componentes ...........................................................................................................................177.5.3 Gestión de FAU_SEL.1................................................................................................................177.5.4 Auditoría de FAU_SEL.1.............................................................................................................................177.5.5 FAU_SEL.1 auditoría selectiva .................................................................................................................177.6 Almacenamiento de eventos de auditoría de seguridad (FAU_STG) ........................................... ............................................... 177.6.1 Familia Behaviour.................................................................................................................................177.6.2 Nivelación de componentes ...........................................................................................................................177.6.3 Gestión de FAU_STG.1................................................................................................................187.6.4 Gestión de FAU_STG.2................................................................................................................187.6.5 Gestión de FAU_STG.3................................................................................................................187.6.6 Gestión de FAU_STG.4................................................................................................................187.6.7 Auditoría de FAU_STG.1, FAU_STG.2.......................................................................................................18

12/6/2014 ISO / IEC 15408-2


iv © ISO / IEC 2008 - Todos los derechos reservados

7.6.8 Auditoría de FAU_STG.3.............................................................................................................................187.6.9 Auditoría de FAU_STG.4.............................................................................................................................187.6.10 FAU_STG.1 auditoría Protegida almacenamiento rastro ........................................ .................................................. 187.6.11 FAU_STG.2 Garantías de disponibilidad de los datos de auditoría ....................................... ..................................... 197.6.12 FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría .................................... ............................... 197.6.13 Prevención FAU_STG.4 de auditoría pérdida de datos ....................................... .................................................. 19

8 Clase FCO: Comunicación ...............................................................................................................208.1 No repudio de origen (FCO_NRO)...............................................................................................208.1.1 Familia Behaviour.................................................................................................................................208.1.2 Nivelación de componentes ...........................................................................................................................208.1.3 Gestión de FCO_NRO.1, FCO_NRO.2 ......................................... ............................................... 208.1.4 Auditoría de FCO_NRO.1............................................................................................................................208.1.5 Auditoría de FCO_NRO.2............................................................................................................................218.1.6 FCO_NRO.1 prueba selectiva de origin................................................................................................218.1.7 FCO_NRO.2 forzada prueba de origin................................................................................................218.2 No repudio de recepción (FCO_NRR).............................................................................................228.2.1 Familia Behaviour.................................................................................................................................228.2.2 Nivelación de componentes ...........................................................................................................................228.2.3 Gestión de FCO_NRR.1, FCO_NRR.2 ......................................... ............................................... 228.2.4 Auditoría de FCO_NRR.1............................................................................................................................228.2.5 Auditoría de FCO_NRR.2............................................................................................................................228.2.6 FCO_NRR.1 prueba selectiva de recibo ........................................... .................................................. 0.228.2.7 FCO_NRR.2 Forzadas prueba de recibo ........................................... .................................................. 0.23

9 Clase FCS: criptográficos support....................................................................................................249.1 La gestión de claves de cifrado (FCS_CKM) ............................................ ....................................... 249.1.1 Familia Behaviour.................................................................................................................................249.1.2 Nivelación de componentes ...........................................................................................................................249.1.3 Gestión de FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4 ................................. .......... 259.1.4 Auditoría de FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4 ................................. ....................... 259.1.5 La generación de claves de cifrado FCS_CKM.1 ............................................ .......................................... 259.1.6 Distribución de la clave de cifrado FCS_CKM.2 ............................................ ......................................... 259.1.7 Clave criptográfica FCS_CKM.3 access.............................................................................................259.1.8 FCS_CKM.4 criptográfico destrucción clave ............................................ ......................................... 269.2 Operación criptográfica (FCS_COP) ............................................. .................................................. 0.269.2.1 Familia Behaviour.................................................................................................................................269.2.2 Nivelación de componentes ...........................................................................................................................269.2.3 Gestión de FCS_COP.1 ...............................................................................................................269.2.4 Auditoría de FCS_COP.1 ............................................................................................................................269.2.5 FCS_COP.1 criptográficos operation................................................................................................27

10 Clase FDP: Los datos de usuario protection........................................................................................................2710.1 Política de control de acceso (FDP_ACC) .....................................................................................................29

Página 5

ISO / IEC 15408-2:2008 (E)

10.1.1 Familia Behaviour.................................................................................................................................2910.1.2 nivelación de componentes ...........................................................................................................................30Gestión 10.1.3 de FDP_ACC.1, FDP_ACC.2 ...................................... .................................................. 0.3010.1.4 Auditoría de FDP_ACC.1, FDP_ACC.2......................................................................................................30Control de acceso 10.1.5 FDP_ACC.1 Subset ...................................................................................................3010.1.6 FDP_ACC.2 Acceso completo control...............................................................................................3010.2 Funciones de control de acceso (FDP_ACF) ............................................ .................................................. 0.3010.2.1 Familia Behaviour.................................................................................................................................3010.2.2 nivelación de componentes ...........................................................................................................................30Gestión 10.2.3 de FDP_ACF.1 ...............................................................................................................3110.2.4 Auditoría de FDP_ACF.1 ............................................................................................................................31....................................... Control de acceso basado en atributo 10.2.5 FDP_ACF.1 Seguridad ............................... 3110.3 Autenticación de datos (FDP_DAU).........................................................................................................3210.3.1 Familia Behaviour.................................................................................................................................3210.3.2 nivelación de componentes ...........................................................................................................................32Gestión 10.3.3 de FDP_DAU.1, FDP_DAU.2 ...................................... .................................................. 0.3210.3.4 Auditoría de FDP_DAU.1............................................................................................................................3210.3.5 Auditoría de FDP_DAU.2............................................................................................................................3210.3.6 FDP_DAU.1 Básico de Datos Authentication.............................................................................................3210.3.7 FDP_DAU.2 datos de autenticación con la identidad del Garante ...................................... .................... 3310.4 Exportar desde el TOE (FDP_ETC) .......................................................................................................3310.4.1 Familia Behaviour.................................................................................................................................3310.4.2 nivelación de componentes ...........................................................................................................................3310.4.3 Gestión de FDP_ETC.1................................................................................................................3310.4.4 Gestión de FDP_ETC.2................................................................................................................3310.4.5 Auditoría de FDP_ETC.1, FDP_ETC.2.......................................................................................................3310.4.6 FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad ..................................... ...................... 3410.4.7 FDP_ETC.2 Exportación de los datos de usuario con atributos de seguridad ..................................... ............................ 3410.5 Política de control de flujo de la información (FDP_IFC) ........................................... ............................................ 34

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados v

10.5.1 Familia Behaviour.................................................................................................................................3410.5.2 nivelación de componentes ...........................................................................................................................35Gestión 10.5.3 de FDP_IFC.1, FDP_IFC.2.............................................................................................3510.5.4 Auditoría de FDP_IFC.1, FDP_IFC.2..........................................................................................................35Información 10.5.5 FDP_IFC.1 subconjunto de control de flujo ........................................ ............................................. 3510.5.6 FDP_IFC.2 Información completa de control de flujo ........................................ ......................................... 3510.6 Funciones de control de flujo de la información (FDP_IFF) ........................................... ....................................... 3510.6.1 Familia Behaviour.................................................................................................................................3510.6.2 nivelación de componentes ...........................................................................................................................36Gestión 10.6.3 de FDP_IFF.1, FDP_IFF.2..............................................................................................3610.6.4 Gestión de FDP_IFF.3, FDP_IFF.4, FDP_IFF.5 .................................. ........................................ 3610.6.5 Gestión de FDP_IFF.6..................................................................................................................3610.6.6 Auditoría de FDP_IFF.1, FDP_IFF.2, FDP_IFF.5 .................................. .................................................. 36 ...10.6.7 Auditoría de FDP_IFF.3, FDP_IFF.4, FDP_IFF.6 .................................. .................................................. 37 ...10.6.8 FDP_IFF.1 seguridad simple attributes................................................................................................3710.6.9 FDP_IFF.2 seguridad jerárquica atributos ......................................... .............................................. 37Fluye 10.6.10 FDP_IFF.3 Limited información ilícita ........................................ ............................................... 3810.6.11 FDP_IFF.4 Eliminación parcial de la información ilícita fluye ...................................... .......................... 3910.6.12 FDP_IFF.5 No hay información ilícita flows...............................................................................................3910.6.13 FDP_IFF.6 información Ilícito de monitoreo de flujo ........................................ ........................................... 3910.7 Importación desde fuera del TOE (FDP_ITC) ......................................... .............................................. 3910.7.1 Familia Behaviour.................................................................................................................................3910.7.2 nivelación de componentes ...........................................................................................................................39Gestión 10.7.3 de FDP_ITC.1, FDP_ITC.2.............................................................................................4010.7.4 Auditoría de FDP_ITC.1, FDP_ITC.2..........................................................................................................4010.7.5 FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad ..................................... ........................ 4010.7.6 FDP_ITC.2 Importación de los datos de usuario con atributos de seguridad ..................................... ............................. 4010.8 Transferencia TOE Interna (FDP_ITT).........................................................................................................4110.8.1 Familia Behaviour.................................................................................................................................4110.8.2 nivelación de componentes ...........................................................................................................................41Gestión 10.8.3 de FDP_ITT.1, FDP_ITT.2..............................................................................................41

Página 6

ISO / IEC 15408-2:2008 (E)

Gestión 10.8.4 de FDP_ITT.3, FDP_ITT.4..............................................................................................4210.8.5 Auditoría de FDP_ITT.1, FDP_ITT.2...........................................................................................................4210.8.6 Auditoría de FDP_ITT.3, FDP_ITT.4...........................................................................................................4210.8.7 FDP_ITT.1 básico de protección interno de transferencia ........................................ ........................................... 4210.8.8 FDP_ITT.2 Transmisión separación por atributo ........................................ ..................................... 42Monitoreo 10.8.9 FDP_ITT.3 Integridad ..........................................................................................................4310.8.10 FDP_ITT.4 basada en atributos vigilancia de la integridad ....................................... ....................................... 4310.9 Protección de la información residual (FDP_RIP) ............................................ .......................................... 4310.9.1 Familia Behaviour.................................................................................................................................4310.9.2 nivelación de componentes ...........................................................................................................................44Gestión 10.9.3 de FDP_RIP.1, FDP_RIP.2.............................................................................................4410.9.4 Auditoría de FDP_RIP.1, FDP_RIP.2..........................................................................................................4410.9.5 FDP_RIP.1 Subset protección de la información residual ........................................ ................................. 4410.9.6 Protección FDP_RIP.2 información completa residual ........................................ ....................................... 4410.10 Rollback (FDP_ROL)............................................................................................................................4410.10.1 Familia Behaviour.................................................................................................................................4410.10.2 nivelación de componentes ...........................................................................................................................4410.10.3 Gestión de FDP_ROL.1, FDP_ROL.2..........................................................................................4510.10.4 Auditoría de FDP_ROL.1, FDP_ROL.2.......................................................................................................4510.10.5 FDP_ROL.1 básico rollback..................................................................................................................4510.10.6 FDP_ROL.2 Avanzada rollback..........................................................................................................4510.11 integridad de los datos almacenados (FDP_SDI) .........................................................................................................4610.11.1 Familia Behaviour.................................................................................................................................4610.11.2 nivelación de componentes ...........................................................................................................................4610.11.3 Gestión de FDP_SDI.1 .................................................................................................................4610.11.4 Gestión de FDP_SDI.2 .................................................................................................................4610.11.5 Auditoría de FDP_SDI.1 ..............................................................................................................................4610.11.6 Auditoría de FDP_SDI.2 ..............................................................................................................................4610.11.7 monitoreo FDP_SDI.1 integridad de los datos almacenados ........................................ ............................................. 46Monitoreo 10.11.8 integridad FDP_SDI.2 datos almacenados y la acción ...................................... ............................ 4710.12 Inter-TSF protección transferencia confidencialidad de los datos de usuario (FDP_UCT) ...................................... ......... 4710.12.1 Familia Behaviour.................................................................................................................................4710.12.2 nivelación de componentes ...........................................................................................................................4710.12.3 Gestión de FDP_UCT.1................................................................................................................4710.12.4 Auditoría de FDP_UCT.1.............................................................................................................................4710.12.5 FDP_UCT.1 básico confidencialidad intercambio de datos ........................................ ..................................... 4710.13 Inter-TSF protección transferencia integridad de los datos de usuario (FDP_UIT) ...................................... ..................... 4810.13.1 Familia Behaviour.................................................................................................................................4810.13.2 nivelación de componentes ...........................................................................................................................4810.13.3 Gestión de FDP_UIT.1, FDP_UIT.2, FDP_UIT.3 .................................. ....................................... 4810.13.4 Auditoría de FDP_UIT.1 ..............................................................................................................................48

12/6/2014 ISO / IEC 15408-2


vi © ISO / IEC 2008 - Todos los derechos reservados

10.13.5 Auditoría de FDP_UIT.2, FDP_UIT.3 ..........................................................................................................4810.13.6 integridad FDP_UIT.1 El intercambio de datos ...................................................................................................49Recuperación de intercambio de datos 10.13.7 FDP_UIT.2 Fuente ........................................ ............................................. 4910.13.8 recuperación intercambio de datos FDP_UIT.3 Destino ........................................ ...................................... 49

11 Clase FIA: Identificación y authentication.....................................................................................5011.1 Los errores de autenticación (FIA_AFL)......................................................................................................5111.1.1 Familia Behaviour.................................................................................................................................5111.1.2 nivelación de componentes ...........................................................................................................................5111.1.3 Gestión de FIA_AFL.1..................................................................................................................5211.1.4 Auditoría de FIA_AFL.1...............................................................................................................................5211.1.5 FIA_AFL.1 autenticación manejo fracaso ......................................... .............................................. 5211.2 Definición de atributo de usuario (FIA_ATD)....................................................................................................5211.2.1 Familia Behaviour.................................................................................................................................5211.2.2 nivelación de componentes ...........................................................................................................................52Gestión 11.2.3 de FIA_ATD.1 .................................................................................................................5211.2.4 Auditoría de FIA_ATD.1 ..............................................................................................................................5211.2.5 atributo FIA_ATD.1 usuario definition...................................................................................................5311.3 Especificación de los secretos (FIA_SOS)....................................................................................................53

Página 7

ISO / IEC 15408-2:2008 (E)

11.3.1 Familia Behaviour.................................................................................................................................5311.3.2 nivelación de componentes ...........................................................................................................................5311.3.3 Gestión de FIA_SOS.1.................................................................................................................5311.3.4 Gestión de FIA_SOS.2.................................................................................................................5311.3.5 Auditoría de FIA_SOS.1, FIA_SOS.2.........................................................................................................5311.3.6 FIA_SOS.1 Verificación de los secretos .....................................................................................................5311.3.7 FIA_SOS.2 TSF Generación de secretos ........................................ .................................................. .... 5411.4 La autenticación de usuarios (FIA_UAU)..........................................................................................................5411.4.1 Familia Behaviour.................................................................................................................................5411.4.2 nivelación de componentes ...........................................................................................................................5411.4.3 Gestión de FIA_UAU.1.................................................................................................................5411.4.4 Gestión de FIA_UAU.2.................................................................................................................5511.4.5 Gestión de FIA_UAU.3, FIA_UAU.4, FIA_UAU.7 .................................. ..................................... 5511.4.6 Gestión de FIA_UAU.5.................................................................................................................5511.4.7 Gestión de FIA_UAU.6.................................................................................................................5511.4.8 Auditoría de FIA_UAU.1 .............................................................................................................................5511.4.9 Auditoría de FIA_UAU.2 .............................................................................................................................5511.4.10 Auditoría de FIA_UAU.3 .............................................................................................................................5511.4.11 Auditoría de FIA_UAU.4 .............................................................................................................................5611.4.12 Auditoría de FIA_UAU.5 .............................................................................................................................5611.4.13 Auditoría de FIA_UAU.6 .............................................................................................................................5611.4.14 Auditoría de FIA_UAU.7 .............................................................................................................................5611.4.15 FIA_UAU.1 Momento de la authentication.................................................................................................5611.4.16 autenticación FIA_UAU.2 usuario antes de cualquier acción ....................................... ................................... 5611.4.17 FIA_UAU.3 autenticación infalsificable .......................................... .................................................. 5704/11/18 FIA_UAU.4 de un solo uso de mecanismos de autenticación ....................................... ................................. 5704/11/19 FIA_UAU.5 mecanismos de autenticación múltiples ......................................... .................................... 5704/11/20 FIA_UAU.6 Re-autenticación ............................................................................................................5711/04/21 retroalimentación FIA_UAU.7 validación protegida ......................................... ....................................... 5711.5 Identificación del usuario (FIA_UID)..............................................................................................................5811.5.1 Familia Behaviour.................................................................................................................................5811.5.2 nivelación de componentes ...........................................................................................................................58Gestión 11.5.3 de FIA_UID.1 ..................................................................................................................58Gestión 11.5.4 de FIA_UID.2 ..................................................................................................................5811.5.5 Auditoría de FIA_UID.1, FIA_UID.2............................................................................................................5811.5.6 FIA_UID.1 Momento de la identification.....................................................................................................5811.5.7 identificación FIA_UID.2 usuario antes de cualquier acción ....................................... ....................................... 5911.6 El usuario sujeta la unión (FIA_USB)........................................................................................................5911.6.1 Familia Behaviour.................................................................................................................................5911.6.2 nivelación de componentes ...........................................................................................................................5911.6.3 Gestión de FIA_USB.1.................................................................................................................5911.6.4 Auditoría de FIA_USB.1..............................................................................................................................5911.6.5 FIA_USB.1 el usuario sujeta la unión .......................................................................................................59

12 FMT Clase: Seguridad management.....................................................................................................6012.1 Gestión de funciones en TSF (FMT_MOF) .......................................... ........................................ 6112.1.1 Familia Behaviour.................................................................................................................................6112.1.2 nivelación de componentes ...........................................................................................................................6112.1.3 Gestión de FMT_MOF.1...............................................................................................................6112.1.4 Auditoría de FMT_MOF.1............................................................................................................................6212.1.5 FMT_MOF.1 Gestión de la seguridad de las funciones de comportamiento ....................................... ..................... 6212.2 Gestión de los atributos de seguridad (FMT_MSA) ........................................... .................................... 6212.2.1 Familia Behaviour.................................................................................................................................62

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados vii

12.2.2 nivelación de componentes ...........................................................................................................................6212.2.3 Gestión de FMT_MSA.1...............................................................................................................6212.2.4 Gestión de FMT_MSA.2...............................................................................................................6212.2.5 Gestión de FMT_MSA.3...............................................................................................................6312.2.6 Gestión de FMT_MSA.4...............................................................................................................6312.2.7 Auditoría de FMT_MSA.1............................................................................................................................6312.2.8 Auditoría de FMT_MSA.2............................................................................................................................63

Página 8

ISO / IEC 15408-2:2008 (E)

viii © ISO / IEC 2008 - Todos los derechos reservados

12.2.9 Auditoría de FMT_MSA.3............................................................................................................................6312.2.10 Auditoría de FMT_MSA.4............................................................................................................................6312.2.11 FMT_MSA.1 Gestión de atributos de seguridad ........................................ ....................................... 6312.2.12 FMT_MSA.2 seguridad Secure atributos ......................................... .................................................. .. 6412.2.13 FMT_MSA.3 atributo estático initialisation..........................................................................................64Atributo 12.2.14 FMT_MSA.4 Seguridad valor herencia ........................................ ..................................... 6412.3 Gestión de los datos TSF (FMT_MTD)................................................................................................6512.3.1 Familia Behaviour.................................................................................................................................6512.3.2 nivelación de componentes ...........................................................................................................................65Gestión 12.3.3 de FMT_MTD.1 ...............................................................................................................65Gestión 12.3.4 de FMT_MTD.2 ...............................................................................................................65Gestión 12.3.5 de FMT_MTD.3 ...............................................................................................................6512.3.6 Auditoría de FMT_MTD.1............................................................................................................................6512.3.7 Auditoría de FMT_MTD.2............................................................................................................................6512.3.8 Auditoría de FMT_MTD.3............................................................................................................................6512.3.9 FMT_MTD.1 Gestión de TSF data...............................................................................................6512.3.10 FMT_MTD.2 Gestión de límites en los datos TSF ...................................... ......................................... 6612.3.11 FMT_MTD.3 datos TSF Secure .............................................................................................................6612.4 Revocación (FMT_REV) .......................................................................................................................6612.4.1 Familia Behaviour.................................................................................................................................6612.4.2 nivelación de componentes ...........................................................................................................................6612.4.3 Gestión de FMT_REV.1................................................................................................................6612.4.4 Auditoría de FMT_REV.1.............................................................................................................................6712.4.5 FMT_REV.1 Revocation.......................................................................................................................6712.5 Caducidad atributo Seguridad (FMT_SAE)...........................................................................................6712.5.1 Familia Behaviour.................................................................................................................................6712.5.2 nivelación de componentes ...........................................................................................................................6712.5.3 Gestión de FMT_SAE.1................................................................................................................6712.5.4 Auditoría de FMT_SAE.1.............................................................................................................................6712.5.5 FMT_SAE.1 tiempo limitado- authorisation.............................................................................................6712.6 Especificación de las funciones de gestión (FMT_SMF) ........................................... ........................... 6812.6.1 Familia Behaviour.................................................................................................................................6812.6.2 nivelación de componentes ...........................................................................................................................68Gestión 12.6.3 de FMT_SMF.1 ...............................................................................................................6812.6.4 Auditoría de FMT_SMF.1 ............................................................................................................................6812.6.5 FMT_SMF.1 especificación de las funciones de gestión ........................................ .............................. 6812.7 Las funciones de gestión de seguridad (FMT_SMR)...........................................................................................6812.7.1 Familia Behaviour.................................................................................................................................6812.7.2 nivelación de componentes ...........................................................................................................................6912.7.3 Gestión de FMT_SMR.1...............................................................................................................6912.7.4 Gestión de FMT_SMR.2...............................................................................................................6912.7.5 Gestión de FMT_SMR.3...............................................................................................................6912.7.6 Auditoría de FMT_SMR.1............................................................................................................................6912.7.7 Auditoría de FMT_SMR.2............................................................................................................................6912.7.8 Auditoría de FMT_SMR.3............................................................................................................................6912.7.9 FMT_SMR.1 Seguridad roles..................................................................................................................6912/07/10 FMT_SMR.2 Restricciones en los roles de seguridad ........................................ ............................................... 7012/07/11 papeles FMT_SMR.3 Suponiendo ..............................................................................................................70

13 FPR Clase: Privacidad ..............................................................................................................................7113.1 Anonimato (FPR_ANO)........................................................................................................................7113.1.1 Familia Behaviour.................................................................................................................................7113.1.2 nivelación de componentes ...........................................................................................................................71Gestión 13.1.3 de FPR_ANO.1, ...................................... FPR_ANO.2 .................................................. 0.7113.1.4 Auditoría de FPR_ANO.1, FPR_ANO.2......................................................................................................7113.1.5 FPR_ANO.1 Anonymity.......................................................................................................................7213.1.6 FPR_ANO.2 anonimato sin solicitar información ........................................ ........................... 7213.2 Seudónimos (FPR_PSE) ..................................................................................................................7213.2.1 Familia Behaviour.................................................................................................................................7213.2.2 nivelación de componentes ...........................................................................................................................72

12/6/2014 ISO / IEC 15408-2


Página 9

ISO / IEC 15408-2:2008 (E)

© ISO / IEC 2008 - Todos los derechos reservados ix

13.2.3 Gestión de FPR_PSE.1, FPR_PSE.2, FPR_PSE.3 .................................. ................................... 7213.2.4 Auditoría de FPR_PSE.1, FPR_PSE.2, FPR_PSE.3 .................................. ................................................ 7213.2.5 FPR_PSE.1 Pseudonymity..................................................................................................................7313.2.6 FPR_PSE.2 seudonimia Reversible .......................................... .................................................. .. 7313.2.7 FPR_PSE.3 Alias pseudonymity........................................................................................................7313.3 Imposibilidad de vinculación (FPR_UNL) .....................................................................................................................7413.3.1 Familia Behaviour.................................................................................................................................7413.3.2 nivelación de componentes ...........................................................................................................................74Gestión 13.3.3 de FPR_UNL.1 ...............................................................................................................7413.3.4 Auditoría de FPR_UNL.1 ............................................................................................................................7413.3.5 FPR_UNL.1 Unlinkability.....................................................................................................................7413.4 Inobservabilidad (FPR_UNO)...............................................................................................................7413.4.1 Familia Behaviour.................................................................................................................................7413.4.2 nivelación de componentes ...........................................................................................................................75Gestión 13.4.3 de FPR_UNO.1, ...................................... FPR_UNO.2 .................................................. 0.7513.4.4 Gestión de FPR_UNO.3...............................................................................................................7513.4.5 Gestión de FPR_UNO.4...............................................................................................................7513.4.6 Auditoría de FPR_UNO.1, FPR_UNO.2 .....................................................................................................7513.4.7 Auditoría de FPR_UNO.3............................................................................................................................7513.4.8 Auditoría de FPR_UNO.4............................................................................................................................7513.4.9 FPR_UNO.1 inobservabilidad ..............................................................................................................7513.4.10 FPR_UNO.2 Asignación de información impactando inobservabilidad ....................................... .......... 7613.4.11 FPR_UNO.3 inobservabilidad sin solicitar información ........................................ ................... 7613.4.12 FPR_UNO.4 Autorizado usuario observabilidad ......................................... ............................................. 76

14 Clase FPT: Protección del TSF ......................................................................................................7614.1 Fail secure (FPT_FLS).........................................................................................................................7714.1.1 Familia Behaviour.................................................................................................................................7714.1.2 nivelación de componentes ...........................................................................................................................7814.1.3 Gestión de FPT_FLS.1.................................................................................................................7814.1.4 Auditoría de FPT_FLS.1 .............................................................................................................................7814.1.5 FPT_FLS.1 Fracaso con la preservación de las condiciones de seguridad ...................................... ................................ 7814.2 La disponibilidad de los datos exportados TSF (FPT_ITA) .......................................... ........................................... 7814.2.1 Familia Behaviour.................................................................................................................................7814.2.2 nivelación de componentes ...........................................................................................................................7814.2.3 Gestión de FPT_ITA.1..................................................................................................................7814.2.4 Auditoría de FPT_ITA.1 ..............................................................................................................................7814.2.5 FPT_ITA.1 Inter-TSF disponibilidad dentro de una disponibilidad ................................... métrica definida .......... 7814.3 Confidencialidad de los datos exportados TSF (FPT_ITC) .......................................... .................................... 7914.3.1 Familia Behaviour.................................................................................................................................7914.3.2 nivelación de componentes ...........................................................................................................................7914.3.3 Gestión de FPT_ITC.1..................................................................................................................7914.3.4 Auditoría de FPT_ITC.1 ..............................................................................................................................7914.3.5 FPT_ITC.1 Inter-TSF confidencialidad durante la transmisión ...................................... ......................... 7914.4 Integridad de los datos TSF exportado (FPT_ITI)...........................................................................................7914.4.1 Familia Behaviour.................................................................................................................................7914.4.2 nivelación de componentes ...........................................................................................................................79Gestión 14.4.3 de FPT_ITI.1 ...................................................................................................................80Gestión 14.4.4 de FPT_ITI.2 ...................................................................................................................8014.4.5 Auditoría de FPT_ITI.1................................................................................................................................8014.4.6 Auditoría de FPT_ITI.2................................................................................................................................80Detección 14.4.7 FPT_ITI.1 Inter-TSF de ...................................... modificación ............................................ 80Detección 14.4.8 FPT_ITI.2 Inter-TSF y la corrección de la modificación .................................... .................... 8014.5 La transferencia de datos TSF TOE Interna (FPT_ITT) .......................................... ............................................... 8114.5.1 Familia Behaviour.................................................................................................................................8114.5.2 nivelación de componentes ...........................................................................................................................8114.5.3 Gestión de FPT_ITT.1..................................................................................................................8114.5.4 Gestión de FPT_ITT.2..................................................................................................................8114.5.5 Gestión de FPT_ITT.3..................................................................................................................8114.5.6 Auditoría de FPT_ITT.1, FPT_ITT.2............................................................................................................82

Página 10

ISO / IEC 15408-2:2008 (E)

14.5.7 Auditoría de FPT_ITT.3...............................................................................................................................8214.5.8 FPT_ITT.1 básico de protección de transferencia de datos TSF interna ...................................... .............................. 8214.5.9 Transferencia de datos TSF FPT_ITT.2 separation............................................................................................82

12/6/2014 ISO / IEC 15408-2


x © ISO / IEC 2008 - Todos los derechos reservados

14.5.10 FPT_ITT.3 TSF monitoreo de integridad de datos ........................................ .................................................. 8214.6 Protección física TSF (FPT_PHP) ............................................ .................................................. .... 8314.6.1 Familia Behaviour.................................................................................................................................8314.6.2 nivelación de componentes ...........................................................................................................................83Gestión 14.6.3 de FPT_PHP.1 ................................................................................................................83Gestión 14.6.4 de FPT_PHP.2 ................................................................................................................83Gestión 14.6.5 de FPT_PHP.3 ................................................................................................................8314.6.6 Auditoría de FPT_PHP.1 .............................................................................................................................8314.6.7 Auditoría de FPT_PHP.2 .............................................................................................................................8414.6.8 Auditoría de FPT_PHP.3 .............................................................................................................................8414.6.9 FPT_PHP.1 detección pasiva de ataque físico ....................................... ...................................... 8414.6.10 FPT_PHP.2 Notificación de ataque físico ........................................ ............................................... 8414.6.11 FPT_PHP.3 Resistencia al ataque físico ........................................ ................................................ 8414.7 Recuperación de confianza (FPT_RCV)..............................................................................................................8514.7.1 Familia Behaviour.................................................................................................................................8514.7.2 nivelación de componentes ...........................................................................................................................8514.7.3 Gestión de FPT_RCV.1................................................................................................................85Gestión 14.7.4 de FPT_RCV.2, FPT_RCV.3 ...................................... .................................................. .. 8514.7.5 Gestión de FPT_RCV.4................................................................................................................8514.7.6 Auditoría de FPT_RCV.1, FPT_RCV.2, FPT_RCV.3 .................................. ................................................ 8514.7.7 Auditoría de FPT_RCV.4.............................................................................................................................8514.7.8 Manual FPT_RCV.1 recovery..............................................................................................................8614.7.9 FPT_RCV.2 Automatizado recovery........................................................................................................8607/14/10 FPT_RCV.3 recuperación automatizada y sin pérdida indebida ....................................... ............................... 8614.7.11 recuperación FPT_RCV.4 Función ...........................................................................................................8714.8 Detección Replay (FPT_RPL)...............................................................................................................8714.8.1 Familia Behaviour.................................................................................................................................8714.8.2 nivelación de componentes ...........................................................................................................................87Gestión 14.8.3 de FPT_RPL.1 ................................................................................................................8714.8.4 Auditoría de FPT_RPL.1 .............................................................................................................................8714.8.5 FPT_RPL.1 Replay detection..............................................................................................................8714.9 Protocolo de sincronía Estado (FPT_SSP)................................................................................................8814.9.1 Familia Behaviour.................................................................................................................................8814.9.2 nivelación de componentes ...........................................................................................................................88Gestión 14.9.3 de FPT_SSP.1, FPT_SSP.2 ...................................... .................................................. 88 ...14.9.4 Auditoría de FPT_SSP.1, FPT_SSP.2 ........................................................................................................8814.9.5 FPT_SSP.1 reconocimiento confianza simple ......................................... ........................................ 8814.9.6 FPT_SSP.2 mutuo reconocimiento de confianza ......................................... ......................................... 8814.10 Las marcas de tiempo (FPT_STM).....................................................................................................................8914.10.1 Familia Behaviour.................................................................................................................................8914.10.2 nivelación de componentes ...........................................................................................................................8914.10.3 Gestión de FPT_STM.1................................................................................................................8914.10.4 Auditoría de FPT_STM.1.............................................................................................................................8914.10.5 FPT_STM.1 tiempo fiable stamps.......................................................................................................8914.11 consistencia de los datos entre TSF TSF (FPT_TDC) ........................................ ............................................. 8914.11.1 Familia Behaviour.................................................................................................................................8914.11.2 nivelación de componentes ...........................................................................................................................8914.11.3 Gestión de FPT_TDC.1 ................................................................................................................8914.11.4 Auditoría de FPT_TDC.1 .............................................................................................................................8914.11.5 FPT_TDC.1 Inter-TSF consistencia de los datos TSF básica ..................................... ..................................... 9014.12 Pruebas de entidades externas (FPT_TEE)..............................................................................................9014.12.1 Familia Behaviour.................................................................................................................................9014.12.2 nivelación de componentes ...........................................................................................................................9014.12.3 Gestión de FPT_TEE.1.................................................................................................................9014.12.4 Auditoría de FPT_TEE.1..............................................................................................................................9014.12.5 Prueba FPT_TEE.1 de entidades externas ........................................ .................................................. 90 ...14.13 TSF TOE interna coherencia de replicación de datos (FPT_TRC) ........................................ .................... 91

Página 11

ISO / IEC 15408-2:2008 (E)

14.13.1 Familia Behaviour.................................................................................................................................9114.13.2 nivelación de componentes ...........................................................................................................................9114.13.3 Gestión de FPT_TRC.1................................................................................................................9114.13.4 Auditoría de FPT_TRC.1.............................................................................................................................9114.13.5 FPT_TRC.1 TSF Interna consistency................................................................................................91Autotest 14.14 TSF (FPT_TST) ......................................................................................................................9214.14.1 Familia Behaviour.................................................................................................................................9214.14.2 nivelación de componentes ...........................................................................................................................9214.14.3 Gestión de FPT_TST.1.................................................................................................................9214.14.4 Auditoría de FPT_TST.1 .............................................................................................................................92Pruebas TSF 14.14.5 FPT_TST.1 .......................................................................................................................92

15 FRU Clase: Recursos utilisation........................................................................................................9315.1 La tolerancia a fallos (FRU_FLT)..................................................................................................................9315.1.1 Familia Behaviour.................................................................................................................................9315.1.2 nivelación de componentes ...........................................................................................................................93

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados xi

15.1.3 Gestión de FRU_FLT.1, FRU_FLT.2...........................................................................................9315.1.4 Auditoría de FRU_FLT.1.............................................................................................................................9315.1.5 Auditoría de FRU_FLT.2.............................................................................................................................9315.1.6 tolerancia FRU_FLT.1 culpa degradado ......................................... .................................................. ..... 9415.1.7 FRU_FLT.2 culpa Limited tolerance....................................................................................................9415.2 Prioridad de servicio (FRU_PRS)............................................................................................................9415.2.1 Familia Behaviour.................................................................................................................................9415.2.2 nivelación de componentes ...........................................................................................................................9415.2.3 Gestión de FRU_PRS.1, FRU_PRS.2 ...................................... .................................................. 0.9415.2.4 Auditoría de FRU_PRS.1, FRU_PRS.2 ......................................................................................................9415.2.5 FRU_PRS.1 prioridad limitada de service..............................................................................................9415.2.6 FRU_PRS.2 prioridad completa de service....................................................................................................9515.3 La asignación de recursos (FRU_RSA)........................................................................................................9515.3.1 Familia Behaviour.................................................................................................................................9515.3.2 nivelación de componentes ...........................................................................................................................9515.3.3 Gestión de FRU_RSA.1 ...............................................................................................................9515.3.4 Gestión de FRU_RSA.2 ...............................................................................................................9515.3.5 Auditoría de FRU_RSA.1, FRU_RSA.2......................................................................................................9615.3.6 FRU_RSA.1 máxima quotas............................................................................................................9615.3.7 FRU_RSA.2 mínimos y cuotas máximas ........................................ ............................................ 96

16 Clase FTA: acceso TOE ......................................................................................................................9716.1 Limitación al alcance de atributos seleccionables (FTA_LSA) ......................................... ....................... 9716.1.1 Familia Behaviour.................................................................................................................................9716.1.2 nivelación de componentes ...........................................................................................................................9716.1.3 Gestión de FTA_LSA.1................................................................................................................9716.1.4 Auditoría de FTA_LSA.1.............................................................................................................................9716.1.5 FTA_LSA.1 Limitación en el alcance de atributos seleccionables ...................................... .......................... 9816.2 Limitación en varias sesiones simultáneas (FTA_MCS) .......................................... ...................... 9816.2.1 Familia Behaviour.................................................................................................................................9816.2.2 nivelación de componentes ...........................................................................................................................98Gestión 16.2.3 de FTA_MCS.1 ...............................................................................................................98Gestión 16.2.4 de FTA_MCS.2 ...............................................................................................................9816.2.5 Auditoría de FTA_MCS.1, FTA_MCS.2......................................................................................................9816.2.6 FTA_MCS.1 limitación básica en varias sesiones simultáneas ...................................... ................ 9816.2.7 FTA_MCS.2 Per limitación atributo de usuario en múltiples sesiones concurrentes .................................. 9916.3 Cierre y finalización de sesión (FTA_SSL) ........................................... ......................................... 9916.3.1 Familia Behaviour.................................................................................................................................9916.3.2 nivelación de componentes ...........................................................................................................................99Gestión 16.3.3 de FTA_SSL.1 ................................................................................................................99Gestión 16.3.4 de FTA_SSL.2 ................................................................................................................99Gestión 16.3.5 de FTA_SSL.3 ................................................................................................................99Gestión 16.3.6 de FTA_SSL.4 ..............................................................................................................10016.3.7 Auditoría de FTA_SSL.1, FTA_SSL.2......................................................................................................10016.3.8 Auditoría de FTA_SSL.3...........................................................................................................................100

Página 12

ISO / IEC 15408-2:2008 (E)

16.3.9 Auditoría de FTA_SSL.4 ...........................................................................................................................10016.3.10 FTA_SSL.1 TSF-iniciado ....................................... Cierre de sesión ................................................ 10016.3.11 FTA_SSL.2 bloqueo iniciado por el usuario ....................................................................................................100Terminación iniciada por TSF 16/03/12 FTA_SSL.3 ........................................ .................................................. .... 10103/16/13 FTA_SSL.4 terminación iniciada por el usuario ........................................ .................................................. ... 10116.4 Acceso TOE banners (FTA_TAB)......................................................................................................10116.4.1 Familia Behaviour...............................................................................................................................10116.4.2 nivelación de componentes .........................................................................................................................10116.4.3 Gestión de FTA_TAB.1..............................................................................................................10116.4.4 Auditoría de FTA_TAB.1...........................................................................................................................10116.4.5 FTA_TAB.1 Defecto banners de acceso TOE ........................................ ................................................ 10116.5 Historial de acceso TOE (FTA_TAH)........................................................................................................10216.5.1 Familia Behaviour...............................................................................................................................10216.5.2 nivelación de componentes .........................................................................................................................10216.5.3 Gestión de FTA_TAH.1..............................................................................................................10216.5.4 Auditoría de FTA_TAH.1...........................................................................................................................10216.5.5 Acceso FTA_TAH.1 TOE history.......................................................................................................10216.6 Establecimiento de la sesión TOE (FTA_TSE) ............................................ .............................................. 10216.6.1 Familia Behaviour...............................................................................................................................10216.6.2 nivelación de componentes .........................................................................................................................102Gestión 16.6.3 de FTA_TSE.1 ..............................................................................................................10316.6.4 Auditoría de FTA_TSE.1 ...........................................................................................................................10316.6.5 sesión FTA_TSE.1 TOE establishment..........................................................................................103

17 Clase FTP: Trusted path/channels...................................................................................................10317.1 Canal Inter-TSF confianza (FTP_ITC) .......................................... .................................................. ... 10417.1.1 Familia Behaviour...............................................................................................................................104

12/6/2014 ISO / IEC 15408-2


xii © ISO / IEC 2008 - Todos los derechos reservados

17.1.2 nivelación de componentes .........................................................................................................................10417.1.3 Gestión de FTP_ITC.1................................................................................................................10417.1.4 Auditoría de FTP_ITC.1.............................................................................................................................10417.1.5 FTP_ITC.1 Inter-TSF confiar channel...............................................................................................10417.2 Ruta de confianza (FTP_TRP)....................................................................................................................10517.2.1 Familia Behaviour...............................................................................................................................10517.2.2 nivelación de componentes .........................................................................................................................105Gestión 17.2.3 de FTP_TRP.1 ..............................................................................................................10517.2.4 Auditoría de FTP_TRP.1 ...........................................................................................................................10517.2.5 FTP_TRP.1 Trusted path...................................................................................................................105

Anexo A (normativo) Seguridad notas de aplicación los requisitos funcionales ........................................ ....... 107A.1 Estructura de las notas .......................................................................................................................107A.1.1 Clase structure...................................................................................................................................107A.1.2 Familia structure.................................................................................................................................108A.1.3 Estructura de componentes ........................................................................................................................109A.2 Tablas de dependencia ............................................................................................................................109

Anexo B (normativo) Clases funcionales, familias y componentes ...................................... ................. 115

Anexo C (normativo) Clase FAU: Auditoría de seguridad ........................................ .................................................. 116C.1 Requisitos de auditoría en un entorno distribuido ............................................ .............................. 116C.2 Respuesta automática Auditoría de seguridad (FAU_ARP) ........................................... .................................. 117C.2.1 Notas para el usuario ..........................................................................................................................................117C.2.2 FAU_ARP.1 Seguridad alarms.............................................................................................................117C.3 La generación de datos de auditoría de seguridad (FAU_GEN) ........................................... ......................................... 118C.3.1 Notas para el usuario ..........................................................................................................................................118C.3.2 Datos de auditoría FAU_GEN.1 generation...................................................................................................119C.3.3 Identidad del usuario FAU_GEN.2 association.............................................................................................120C.4 Análisis de las auditorías de seguridad (FAU_SAA) ............................................ .................................................. ... 120C.4.1 Notas para el usuario ..........................................................................................................................................120C.4.2 FAU_SAA.1 análisis Potencial violación ............................................ ............................................. 120C.4.3 Perfil FAU_SAA.2 basado detección de anomalías ........................................... ..................................... 121C.4.4 FAU_SAA.3 ataque simple heuristics...............................................................................................122C.4.5 FAU_SAA.4 ataque Complex heuristics...........................................................................................122

Página 13

ISO / IEC 15408-2:2008 (E)

C.5 Examen de auditoría de seguridad (FAU_SAR) ....................................................................................................123C.5.1 Notas para el usuario ..........................................................................................................................................123C.5.2 Examen de auditoría FAU_SAR.1 ..................................................................................................................124C.5.3 FAU_SAR.2 auditoría restringido review................................................................................................124C.5.4 Auditoría FAU_SAR.3 seleccionable review................................................................................................124C.6 Selección de eventos de auditoría de seguridad (FAU_SEL) ........................................... ........................................... 125C.6.1 Notas para el usuario ..........................................................................................................................................125C.6.2 FAU_SEL.1 Selectivo audit...............................................................................................................125C.7 Almacenamiento de eventos de auditoría de seguridad (FAU_STG) ........................................... ............................................. 125C.7.1 Notas para el usuario ..........................................................................................................................................125C.7.2 FAU_STG.1 Protegida auditoría almacenamiento rastro ........................................... ............................................. 126C.7.3 FAU_STG.2 Garantías de disponibilidad de los datos de auditoría .......................................... ................................ 126C.7.4 FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría ....................................... .......................... 126C.7.5 Prevención de pérdida de datos FAU_STG.4 auditoría .......................................... ............................................ 127

Anexo D (normativo) Clase FCO: Communication......................................................................................128D.1 No repudio de origen (FCO_NRO) .......................................... .................................................. 128D.1.1 Notas para el usuario ..........................................................................................................................................128D.1.2 FCO_NRO.1 prueba selectiva de origin..............................................................................................129D.1.3 FCO_NRO.2 forzada prueba de origin..............................................................................................129D.2 No repudio de recepción (FCO_NRR)...........................................................................................130D.2.1 Notas para el usuario ..........................................................................................................................................130D.2.2 FCO_NRR.1 prueba selectiva de receipt............................................................................................130D.2.3 FCO_NRR.2 Forzadas prueba de receipt............................................................................................131

Anexo E (normativo) Clase FCS: Apoyo criptográfico ........................................ ................................... 132E.1 La gestión de claves de cifrado (FCS_CKM) ............................................ ..................................... 133E.1.1 Notas para el usuario ..........................................................................................................................................133E.1.2 La generación de claves de cifrado FCS_CKM.1 ............................................ ........................................ 134E.1.3 Distribución de la clave de cifrado FCS_CKM.2 ............................................ ....................................... 134E.1.4 FCS_CKM.3 criptográfico clave de acceso ............................................ .............................................. 134E.1.5 FCS_CKM.4 criptográfico destrucción clave ............................................ ....................................... 135E.2 Operación criptográfica (FCS_COP)..............................................................................................135E.2.1 Notas para el usuario ..........................................................................................................................................135E.2.2 Operación criptográfica FCS_COP.1 ............................................. ................................................ 136

Anexo F (normativo) Clase FDP: Usuario protección de datos ....................................... ........................................ 137F.1 Política de control de acceso (FDP_ACC)...................................................................................................140F.1.1 Notas para el usuario ..........................................................................................................................................140F.1.2 Control de acceso FDP_ACC.1 Subset ............................................ .................................................. ... 140

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados xiii

F.1.3 FDP_ACC.2 Acceso completo control.............................................................................................141F.2 Funciones de control de acceso (FDP_ACF) ............................................ ................................................. 141F.2.1 Notas para el usuario ..........................................................................................................................................141F.2.2 Atributo FDP_ACF.1 Seguridad control de acceso basado .......................................... .......................... 141F.3 Autenticación de datos (FDP_DAU).......................................................................................................143F.3.1 Notas para el usuario ..........................................................................................................................................143F.3.2 FDP_DAU.1 Básico de Datos Authentication...........................................................................................143F.3.3 FDP_DAU.2 datos de autenticación con la identidad del Garante ......................................... ............... 143F.4 Exportar desde el TOE (FDP_ETC) .....................................................................................................143F.4.1 Notas para el usuario ..........................................................................................................................................143F.4.2 FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad ........................................ ................. 144F.4.3 FDP_ETC.2 Exportación de los datos de usuario con atributos de seguridad ........................................ ....................... 144F.5 Política de control de flujo de la información (FDP_IFC) ........................................... .......................................... 145F.5.1 Notas para el usuario ..........................................................................................................................................145F.5.2 Información FDP_IFC.1 subconjunto de control de flujo ........................................... ........................................ 146F.5.3 FDP_IFC.2 Información completa de control de flujo ........................................... .................................... 146F.6 Funciones de control de flujo de la información (FDP_IFF) ........................................... ..................................... 146F.6.1 Notas para el usuario ..........................................................................................................................................146F.6.2 FDP_IFF.1 seguridad simple attributes..............................................................................................147F.6.3 Atributos de seguridad FDP_IFF.2 jerárquicas ............................................ ......................................... 148F.6.4 Fluye FDP_IFF.3 Limited información ilícita ........................................... .......................................... 149

Página 14

ISO / IEC 15408-2:2008 (E)

F.6.5 FDP_IFF.4 Eliminación parcial de la información ilícita fluye ......................................... ..................... 149F.6.6 FDP_IFF.5 No hay información ilícita flows.............................................................................................150F.6.7 Información FDP_IFF.6 Ilícito de monitoreo de flujo ........................................... ...................................... 150F.7 Importación desde fuera del TOE (FDP_ITC) ......................................... ............................................ 151F.7.1 Notas para el usuario ..........................................................................................................................................151F.7.2 FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad ........................................ ................... 152F.7.3 FDP_ITC.2 Importación de datos de usuario con atributos de seguridad ........................................ ......................... 152F.8 Transferencia TOE Interna (FDP_ITT).......................................................................................................152F.8.1 Notas para el usuario ..........................................................................................................................................152F.8.2 FDP_ITT.1 básico de protección interno de transferencia ........................................... ...................................... 153F.8.3 Separación FDP_ITT.2 Transmisión por atributo ........................................... ................................ 153F.8.4 Monitoreo FDP_ITT.3 Integridad ........................................................................................................153F.8.5 FDP_ITT.4 supervisión de integridad basada en atributos .......................................... .................................. 154F.9 Protección de la información residual (FDP_RIP) ............................................ ........................................ 155F.9.1 Notas para el usuario ..........................................................................................................................................155F.9.2 FDP_RIP.1 Subset protección de la información residual ........................................... ............................ 156F.9.3 FDP_RIP.2 protección de la información residual completa ........................................... .................................. 156F.10 Rollback (FDP_ROL)..........................................................................................................................156F.10.1 notas de usuario ..........................................................................................................................................156F.10.2 FDP_ROL.1 básico rollback................................................................................................................157F.10.3 FDP_ROL.2 Avanzada rollback........................................................................................................157F.11 Integridad de los datos almacenados (FDP_SDI) .......................................................................................................158F.11.1 notas de usuario ..........................................................................................................................................158F.11.2 FDP_SDI.1 Almacenado monitoreo de integridad de datos ........................................ ........................................... 158Monitoreo de integridad de los datos almacenados y F.11.3 FDP_SDI.2 acción ...................................... .......................... 158F.12 Inter-TSF protección transferencia confidencialidad de los datos de usuario (FDP_UCT) ....................................... ...... 158F.12.1 notas de usuario ..........................................................................................................................................158F.12.2 FDP_UCT.1 básico confidencialidad intercambio de datos ........................................ ................................... 159F.13 Inter-TSF protección transferencia integridad de los datos de usuario (FDP_UIT) ....................................... .................. 159F.13.1 notas de usuario ..........................................................................................................................................159Integridad intercambio F.13.2 FDP_UIT.1 datos ......................................... .................................................. ...... 159Recuperación de intercambio de datos F.13.3 FDP_UIT.2 Fuente ........................................ ........................................... 160Recuperación de intercambio de datos de destino F.13.4 FDP_UIT.3 ........................................ .................................... 160

Anexo G (normativo) Clase FIA: Identificación y autenticación ....................................... .................... 161G.1 Los errores de autenticación (FIA_AFL)....................................................................................................162G.1.1 notas de usuario ..........................................................................................................................................162G.1.2 FIA_AFL.1 autenticación manejo fracaso ......................................... ............................................ 163G.2 Definición de atributo de usuario (FIA_ATD)..................................................................................................164G.2.1 notas de usuario ..........................................................................................................................................164Atributo User G.2.2 FIA_ATD.1 definition.................................................................................................164G.3 Especificación de los secretos (FIA_SOS)..................................................................................................164G.3.1 notas de usuario ..........................................................................................................................................164G.3.2 FIA_SOS.1 Verificación de secrets....................................................................................................165G.3.3 FIA_SOS.2 TSF Generación de secretos ........................................ .................................................. .. 165G.4 La autenticación de usuarios (FIA_UAU) ........................................................................................................165G.4.1 notas de usuario ..........................................................................................................................................165G.4.2 FIA_UAU.1 Momento de autenticación ......................................... .................................................. .... 165G.4.3 FIA_UAU.2 La autenticación del usuario antes de que cualquier acción ....................................... .................................. 166G.4.4 FIA_UAU.3 autenticación infalsificable .......................................... ................................................ 166G.4.5 FIA_UAU.4 mecanismos de un solo uso de autenticación ....................................... ............................... 166

12/6/2014 ISO / IEC 15408-2


xiv © ISO / IEC 2008 - Todos los derechos reservados

G.4.6 FIA_UAU.5 mecanismos de autenticación múltiples ......................................... .................................. 167G.4.7 FIA_UAU.6 Re-authenticating...........................................................................................................167G.4.8 FIA_UAU.7 retroalimentación validación protegida ......................................... ..................................... 168G.5 Identificación del usuario (FIA_UID)............................................................................................................168G.5.1 notas de usuario ..........................................................................................................................................168G.5.2 FIA_UID.1 Momento de la identificación ...................................................................................................168G.5.3 FIA_UID.2 identificación del usuario antes de que cualquier acción ....................................... ..................................... 168G.6 El usuario sujeta la unión (FIA_USB) ......................................................................................................169G.6.1 notas de usuario ..........................................................................................................................................169

Página 15

ISO / IEC 15408-2:2008 (E)

G.6.2 FIA_USB.1 vinculante usuario-sujeto .....................................................................................................169

Anexo H (normativo) Clase FMT: Gestión de la seguridad ........................................ .................................... 170H.1 Gestión de funciones en TSF (FMT_MOF) .......................................... ...................................... 171H.1.1 Notas para el usuario ..........................................................................................................................................171H.1.2 Gestión FMT_MOF.1 de funciones de seguridad comportamiento .......................................... ................ 172H.2 Gestión de los atributos de seguridad (FMT_MSA) ........................................... .................................. 172H.2.1 Notas para el usuario ..........................................................................................................................................172H.2.2 Gestión FMT_MSA.1 de atributos de seguridad ........................................... ................................. 173H.2.3 FMT_MSA.2 seguridad Secure attributes...........................................................................................173H.2.4 Atributo FMT_MSA.3 estático initialisation........................................................................................174H.2.5 Atributo FMT_MSA.4 Seguridad valor herencia ........................................... ................................ 174H.3 Gestión de los datos de TSF (FMT_MTD) ........................................... .................................................. 174H.3.1 Notas para el usuario ..........................................................................................................................................174H.3.2 Gestión FMT_MTD.1 de los datos TSF ........................................... .................................................. 174H.3.3 Gestión FMT_MTD.2 de límites en los datos TSF ......................................... .................................... 175H.3.4 FMT_MTD.3 Proteja los datos TSF ...........................................................................................................175H.4 Revocación (FMT_REV).....................................................................................................................176H.4.1 Notas para el usuario ..........................................................................................................................................176H.4.2 FMT_REV.1 Revocación ....................................................................................................................176A.5 Caducidad atributo Seguridad (FMT_SAE) ............................................ ............................................ 176H.5.1 Notas para el usuario ..........................................................................................................................................176H.5.2 FMT_SAE.1 tiempo limitado- authorisation...........................................................................................177H.6 Especificación de las funciones de gestión (FMT_SMF) ........................................... ......................... 177H.6.1 Notas para el usuario ..........................................................................................................................................177H.6.2 FMT_SMF.1 especificación de las funciones de gestión ........................................... ........................ 177H.7 Las funciones de gestión de seguridad (FMT_SMR).........................................................................................177H.7.1 Notas para el usuario ..........................................................................................................................................177H.7.2 Papeles FMT_SMR.1 Seguridad ...............................................................................................................178H.7.3 FMT_SMR.2 Restricciones de roles de seguridad ........................................... ......................................... 178H.7.4 FMT_SMR.3 Asumiendo los roles ............................................................................................................178

Anexo I (normativo) Clase FPR: Privacidad ......................................................................................................179I.1 Anonimato (FPR_ANO) .....................................................................................................................180I.1.1 Notas para el usuario ..........................................................................................................................................180I.1.2 FPR_ANO.1 Anonymity.....................................................................................................................181I.1.3 FPR_ANO.2 anonimato sin solicitar información ........................................... ...................... 181I.2 Seudónimos (FPR_PSE) ................................................................................................................182I.2.1 Notas para el usuario ..........................................................................................................................................182I.2.2 FPR_PSE.1 Pseudonymity................................................................................................................183I.2.3 FPR_PSE.2 seudonimia Reversible ............................................. ............................................... 183I.2.4 FPR_PSE.3 Alias pseudonymity......................................................................................................184I.3 Imposibilidad de vinculación (FPR_UNL) ...................................................................................................................185I.3.1 Notas para el usuario ..........................................................................................................................................185I.3.2 FPR_UNL.1 Unlinkability...................................................................................................................186I.4 Inobservabilidad (FPR_UNO).............................................................................................................186I.4.1 Notas para el usuario ..........................................................................................................................................186I.4.2 FPR_UNO.1 inobservabilidad ............................................................................................................187I.4.3 FPR_UNO.2 Asignación de información impactando inobservabilidad .......................................... ..... 187I.4.4 FPR_UNO.3 inobservabilidad sin solicitar información ........................................... .............. 188I.4.5 FPR_UNO.4 Autorizado usuario observabilidad ............................................ ........................................ 189

Anexo J (Normativo) Clase FPT: Protección del TSF ...................................... ........................................ 190J.1 Fail secure (FPT_FLS).......................................................................................................................192J.1.1 Notas para el usuario ..........................................................................................................................................192J.1.2 Si no FPT_FLS.1 con preservación de las condiciones de seguridad ......................................... ........................... 192J.2 La disponibilidad de los datos exportados TSF (FPT_ITA) .......................................... ......................................... 192J.2.1 Notas para el usuario ..........................................................................................................................................192J.2.2 FPT_ITA.1 Inter-TSF disponibilidad dentro de una disponibilidad ...................................... métrica definida ..... 192J.3 Confidencialidad de los datos exportados TSF (FPT_ITC) .......................................... .................................. 193J.3.1 Notas para el usuario ..........................................................................................................................................193

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados xv

Página 16

ISO / IEC 15408-2:2008 (E)

xvi © ISO / IEC 2008 - Todos los derechos reservados

J.3.2 Confidencialidad FPT_ITC.1 Inter-TSF durante ......................................... transmisión .................... 193J.4 Integridad de los datos exportados TSF (FPT_ITI) .......................................... ............................................... 193J.4.1 Notas para el usuario ..........................................................................................................................................193J.4.2 Detección FPT_ITI.1 Inter-TSF de ......................................... modificación ....................................... 193J.4.3 Detección y corrección de ....................................... modificación FPT_ITI.2 Inter-TSF ............... 194J.5 La transferencia de datos TSF TOE Interna (FPT_ITT) .......................................... ............................................. 194J.5.1 Notas para el usuario ..........................................................................................................................................194J.5.2 Evaluador notes..................................................................................................................................194J.5.3 FPT_ITT.1 básico de protección de transferencia de datos TSF interno ......................................... ......................... 195J.5.4 La transferencia de datos FPT_ITT.2 TSF separation..........................................................................................195J.5.5 FPT_ITT.3 TSF monitoreo de integridad de datos ........................................... ............................................. 195J.6 Protección física TSF (FPT_PHP) ............................................ .................................................. .. 195J.6.1 Notas para el usuario ..........................................................................................................................................195J.6.2 Detección FPT_PHP.1 pasiva de ataque físico .......................................... ................................. 196J.6.3 FPT_PHP.2 Notificación de ataque físico ........................................... .......................................... 196J.6.4 FPT_PHP.3 Resistencia al ataque físico ........................................... ........................................... 196J.7 Recuperación de confianza (FPT_RCV)............................................................................................................197J.7.1 Notas para el usuario ..........................................................................................................................................197J.7.2 Manual FPT_RCV.1 recovery............................................................................................................198J.7.3 FPT_RCV.2 Automatizado recovery......................................................................................................199J.7.4 Recuperación FPT_RCV.3 automatizada y sin pérdida indebida .......................................... .......................... 199J.7.5 Recuperación de la función FPT_RCV.4 .........................................................................................................200J.8 Detección Replay (FPT_RPL).............................................................................................................200J.8.1 Notas para el usuario ..........................................................................................................................................200J.8.2 FPT_RPL.1 Replay detection............................................................................................................200J.9 Protocolo de sincronía Estado (FPT_SSP)..............................................................................................201J.9.1 Notas para el usuario ..........................................................................................................................................201J.9.2 FPT_SSP.1 simple acuse confianza ............................................ ................................... 201J.9.3 Reconocimiento mutuo de confianza FPT_SSP.2 ............................................ .................................... 201J.10 Las marcas de tiempo (FPT_STM)...................................................................................................................201Notas J.10.1 usuario ..........................................................................................................................................201J.10.2 FPT_STM.1 tiempo fiable stamps.....................................................................................................201J.11 Inter-TSF consistencia de los datos TSF (FPT_TDC) ......................................... .......................................... 202Notas J.11.1 usuario ..........................................................................................................................................202J.11.2 FPT_TDC.1 Inter-TSF consistencia de los datos TSF básica ..................................... ................................... 202J.12 Pruebas de entidades externas (FPT_TEE)............................................................................................202Notas J.12.1 usuario ..........................................................................................................................................202J.12.2 Evaluador notes..................................................................................................................................203J.12.3 Testing FPT_TEE.1 de entidades externas ........................................ .................................................. 0.203J.13 TSF TOE interna coherencia de replicación de datos (FPT_TRC) ......................................... ................. 204Notas J.13.1 usuario ..........................................................................................................................................204J.13.2 FPT_TRC.1 TSF Interna consistency..............................................................................................204J.14 Autotest TSF (FPT_TST) ....................................................................................................................204Notas J.14.1 usuario ..........................................................................................................................................204J.14.2 FPT_TST.1 TSF testing......................................................................................................................204

Anexo K (Normativo) Clase FRU: La utilización de recursos ........................................ ....................................... 206K.1 La tolerancia a fallos (FRU_FLT)................................................................................................................206K.1.1 Notas para el usuario ..........................................................................................................................................206K.1.2 FRU_FLT.1 Degradado culpa tolerance...............................................................................................207K.1.3 Tolerancia a fallos FRU_FLT.2 Limited ..................................................................................................207K.2 Prioridad de servicio (FRU_PRS) ..........................................................................................................207K.2.1 Notas para el usuario ..........................................................................................................................................207K.2.2 FRU_PRS.1 prioridad limitada de service............................................................................................208K.2.3 FRU_PRS.2 prioridad completa de servicio ..................................................................................................208K.3 La asignación de recursos (FRU_RSA) ......................................................................................................208K.3.1 Notas para el usuario ..........................................................................................................................................208K.3.2 Cuotas Máximo FRU_RSA.1 ..........................................................................................................209K.3.3 FRU_RSA.2 mínimos y cuotas máximas ........................................... ....................................... 209

Anexo L (Normativo) Clase FTA: TOE access..............................................................................................211

Página 17

ISO / IEC 15408-2:2008 (E)

L.1 Limitación al alcance de atributos seleccionables (FTA_LSA) ......................................... ..................... 211

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados xvii

L.1.1 Notas para el usuario ..........................................................................................................................................211L.1.2 FTA_LSA.1 Limitación en el alcance de atributos seleccionables ......................................... ..................... 212L.2 Limitación en varias sesiones simultáneas (FTA_MCS) .......................................... .................... 212L.2.1 Notas para el usuario ..........................................................................................................................................212L.2.2 FTA_MCS.1 limitación básica en varias sesiones simultáneas ......................................... ........... 212L.2.3 FTA_MCS.2 Per limitación atributo de usuario en múltiples sesiones concurrentes ................................ 212L.3 Cierre y finalización de sesión (FTA_SSL) ........................................... ....................................... 213L.3.1 Notas para el usuario ..........................................................................................................................................213L.3.2 Iniciado por el TSF FTA_SSL.1 bloqueo sesión .......................................... ............................................. 213L.3.3 Iniciado por el usuario FTA_SSL.2 locking....................................................................................................214L.3.4 Iniciado por el TSF FTA_SSL.3 termination..............................................................................................214L.3.5 Iniciado por el usuario FTA_SSL.4 termination.............................................................................................214L.4 Acceso TOE banners (FTA_TAB) .....................................................................................................214L.4.1 Notas para el usuario ..........................................................................................................................................214L.4.2 FTA_TAB.1 acceso predeterminados TOE banners ........................................... ............................................ 215L.5 Historial de acceso TOE (FTA_TAH) .......................................................................................................215L.5.1 Notas para el usuario ..........................................................................................................................................215L.5.2 Acceso TOE FTA_TAH.1 history.......................................................................................................215L.6 Establecimiento de la sesión TOE (FTA_TSE)..........................................................................................215L.6.1 Notas para el usuario ..........................................................................................................................................215L.6.2 Establecimiento FTA_TSE.1 sesión TOE ............................................ ............................................. 216

Anexo M (normativo) Clase FTP: ruta de confianza / canales ...................................... ..................................... 217M.1 Canal Inter-TSF confianza (FTP_ITC)...............................................................................................217M.1.1 notas de usuario ..........................................................................................................................................217M.1.2 FTP_ITC.1 Inter-TSF confiaba ....................................... canal .................................................. ..... 217M.2 Ruta segura (FTP_TRP) ...................................................................................................................218M.2.1 notas de usuario ..........................................................................................................................................218M.2.2 FTP_TRP.1 Trusted path...................................................................................................................218

Página 18

ISO / IEC 15408-2:2008 (E)

Prefacio

ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica InternacionalComisión) forman el sistema especializado para la normalización mundial. Los organismos nacionales que son miembros deISO e IEC participan en el desarrollo de Normas Internacionales a través de comités técnicosestablecido por la organización respectiva, para atender campos particulares de la actividad técnica. ISO e IECcomités técnicos colaboran en campos de interés mutuo. Otras organizaciones internacionales, gubernamentalesy no gubernamentales, en coordinación con ISO e IEC, también participan en el trabajo. En el campo de la informacióntecnología, ISO e IEC han establecido un comité técnico conjunto ISO / IEC JTC 1.

12/6/2014 ISO / IEC 15408-2


xviii © ISO / IEC 2008 - Todos los derechos reservados

Las Normas Internacionales se redactan de acuerdo con las reglas establecidas en las Directivas ISO / IEC, Parte 2.

La tarea principal del comité técnico conjunto es preparar Normas Internacionales. Proyecto InternacionalNormas aprobadas por el comité técnico conjunto se circulan a los organismos nacionales para votación. La publicación comoNorma Internacional requiere la aprobación por al menos el 75% de los organismos nacionales con derecho a voto.

Se llama la atención la posibilidad de que algunos de los elementos de este documento puedan ser objeto de patentederechos. ISO e IEC no se hace responsable de la identificación de cualquiera o todos los derechos de patente.

ISO / IEC 15408-2 fue preparada por el Comité Técnico Conjunto ISO / IEC JTC 1, Tecnología de la información ,Subcomité SC 27, IT Técnicas de seguridad . El texto idéntico de la norma ISO / IEC 15408 es una publicación de laCommon Criteria Proyecto Patrocinio Organizaciones como criterios comunes para la Tecnología de la Información de SeguridadEvaluación. Las fuentes en XML común para ambas publicaciones se puede encontrar en h ttp :/ / www.oc.ccn.cni.es / xml

Esta tercera edición anula y sustituye a la segunda edición (ISO / IEC 15408-2:2005), que ha sidorevisada técnicamente.

ISO / IEC 15408 consta de las siguientes partes, bajo el título general de tecnología de la información - Seguridadtécnicas - Criterios de evaluación de la seguridad de TI :

Parte 1: Introducción y modelo general

Parte 2: componentes funcionales de seguridad

Parte 3: Componentes de aseguramiento de la seguridad

Esta versión corregida de la norma ISO / IEC 15408-2:2008 incorpora correcciones de redacción misceláneos principalmenterelacionada con FDP_UTC, FDP_UIT, FDP_ACF.1.4, FAU_SEL.1.1, FPT_TST.1, FDP_ITT.4, y FPT_TEE.

Página 19

ISO / IEC 15408-2:2008 (E)

Aviso Legal

Las organizaciones no gubernamentales que figuran a continuación han contribuido al desarrollo de esta versión del CommonCriterios para la Tecnología de la Información de Seguridad de Evaluaciones. A medida que los cotitulares de los derechos de autor en el CommonCriterios para la Tecnología de la Información de Seguridad de las evaluaciones, la versión 3.1, partes 1 a 3 (se llama CC 3.1), seotorgo licencia no exclusiva a la norma ISO / IEC para usar CC 3.1 en el continuo desarrollo / mantenimiento deel 15408 norma internacional ISO / IEC. Sin embargo, estas organizaciones no gubernamentales se reservan el derecho de usar,copiar, distribuir, traducir o modificar CC 3.1 como mejor les parezca.

Australia / Nueva Zelanda: La Dirección de Señales de Defensa y de las Comunicaciones del GobiernoOficina de Seguridad, respectivamente;

Canadá: Communications Security Establishment;

Francia: Direction Centrale de la Sécurité des Systèmes d'Information;

Alemania: Bundesamt für Sicherheit in der Informationstechnik;

Japón: Agencia de Promoción de Tecnología de la Información;

Países Bajos: Holanda Comunicaciones Nacionales Agencia de Seguridad;

España: Ministerio de Administraciones Públicas y el Centro Criptológico Nacional;

Reino Unido: Comunicaciones-Electronic Security Group;

Estados Unidos: La Agencia de Seguridad Nacional y el Instituto Nacional de Estándares yTecnología.

http://translate.google.com/translate?hl=es&prev=_t&sl=en&tl=es&u=http://www.oc.ccn.cni.es/xml

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados xix

Página 20

ISO / IEC 15408-2:2008 (E)

Introducción

Componentes funcionales de seguridad, tal como se define en esta parte de la norma ISO / IEC 15408, son la base para la seguridadrequisitos funcionales expresadas en un perfil de protección (PP) o un objetivo de seguridad (ST). Estos requisitosdescribir el comportamiento de seguridad deseada se espera de un Objeto de Evaluación (TOE) y están destinados a satisfacerlos objetivos de seguridad como se indica en un PP o un ST. Estos requisitos describen las propiedades de seguridad que los usuariospuede detectar mediante la interacción directa (es decir, entradas, salidas) con la informática o por la respuesta de TI a los estímulos.

Componentes funcionales de Seguridad expresan los requisitos de seguridad previstos para contrarrestar las amenazas de la supuestaentorno operativo de la TOE y / o cubrir las políticas de seguridad organizativas identificadas ysupuestos.

La audiencia para esta parte de la norma ISO / IEC 15408 incluye los consumidores, desarrolladores y evaluadores de TI seguraproductos. ISO / IEC 15408-1:2009, cláusula 5 proporciona información adicional sobre el público objetivo deISO / IEC 15408, y en el uso de la norma ISO / IEC 15408 por los grupos que componen el público objetivo. Estosgrupos pueden usar esta parte de la norma ISO / IEC 5408 de la siguiente manera:

a) Los consumidores, que utilizan esta parte de la ISO / IEC 15408 al seleccionar los componentes para expresar funcionalrequisitos para satisfacer los objetivos de seguridad expresadas en un PP o ST. ISO / IEC 15408-1:2009, cláusula 6proporciona información más detallada sobre la relación entre los objetivos y la seguridad de seguridadrequisitos.

b) Los desarrolladores, que responden a las necesidades reales o percibidas de seguridad de los consumidores en la construcción de un TOE,pueden encontrar un método estandarizado para comprender los requisitos de esta parte de la norma ISO / IEC 15408. EllosTambién puede utilizar el contenido de esta parte de la norma ISO / IEC 15408 como base para definir aún más la seguridad del TOEfuncionalidad y mecanismos que cumplan con estos requisitos.

c) Los evaluadores, que utilizan los requisitos funcionales definidos en esta parte de la norma ISO / IEC 15408 en la verificación de que elRequisitos funcionales TOE expresadas en el PP o ST cumplen los objetivos de seguridad de TI y que todosdependencias se registran y se muestran para estar satisfechos. Los evaluadores también deben usar esta parte delISO / IEC 15408 para ayudar a determinar si un determinado satisface TOE requisitos establecidos.

12/6/2014 ISO / IEC 15408-2


xx © ISO / IEC 2008 - Todos los derechos reservados

Página 21

NORMA INTERNACIONAL ISO / IEC 15408-2:2008 (E)

Tecnología de la información - Técnicas de seguridad - Evaluación

criterios de seguridad de TI -

Parte 2:

Componentes funcionales de seguridad

1 Ámbito de aplicación

Esta parte de la Norma ISO / IEC 15408 define la estructura requerida y el contenido de los componentes funcionales de seguridad parael propósito de la evaluación de la seguridad. Incluye un catálogo de componentes funcionales que se reunirá con el comúnrequisitos de funcionalidad de seguridad de muchos productos de TI.

2 Referencias normativas

Los siguientes documentos de referencia son indispensables para la aplicación de este documento. Por fechareferencias, sólo se aplica la edición citada. Para las referencias sin fecha se aplica la última edición de la referenciadocumento (incluyendo cualquier modificación).

ISO / IEC 15408-1, Tecnología de la información - Técnicas de seguridad - Criterios de evaluación de la seguridad de TI -Parte 1: Introducción y modelo general

3 Términos y definiciones, símbolos y abreviaturas

Para los fines de este documento, los términos, las definiciones, símbolos y términos abreviados dan enAplica la norma ISO / IEC 15408-1.

4 Información general

Requisitos funcionales ISO / IEC 15408 y la seguridad asociados descritos en este documento no están destinados a ser unrespuesta definitiva a todos los problemas de seguridad de TI. Más bien, la norma ISO / IEC 15408 ofrece un conjunto de bien entendidorequisitos funcionales de seguridad que se pueden utilizar para crear productos de confianza que refleja las necesidades de lamercado. Estos requisitos funcionales de seguridad se presentan como el estado actual de la técnica en los requisitosespecificación y evaluación.

Esta parte de la Norma ISO / IEC 15408 no pretende incluir todos los posibles requisitos de seguridad funcionales, peromás bien contiene las que se conocen y acordó ser de valor en esta parte de la norma ISO / IEC 15408 autores en elmomento del lanzamiento.

Dado que el conocimiento y las necesidades de los consumidores pueden cambiar, los requisitos funcionales de esta parte del

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados 1

ISO / IEC 15408 tendrá que ser mantenido. Se prevé que algunos autores PP / ST pueden tener necesidades de seguridad(todavía) no cubiertas por los componentes de requisitos funcionales en esta parte de la norma ISO / IEC 15408. En esos casos, elPP / ST autor podrá optar por considerar el uso de requisitos funcionales no tomados de la norma ISO / IEC 15408 (denominadacomo extensibilidad), tal como se explica en el Anexo s A y B de la norma ISO / IEC 15408-1:2009.

4.1 Organización de esta parte de la norma ISO / IEC 15408

Cláusula 5 describe el paradigma utilizado en los requisitos funcionales de seguridad de esta parte de la norma ISO / IEC 15408.

Cláusula 6 presenta el catálogo de esta parte de la norma ISO / IEC 15408 componentes funcionales mientras que las cláusulas 7a través de 17 describir las clases funcionales.

Página 22

ISO / IEC 15408-2:2008 (E)

Anexo A proporciona información explicativa para los usuarios potenciales de los componentes funcionales que incluyen untabla de referencia cruzada completa de las dependencias de los componentes funcionales.

Anexo B t ediante Anexo M proporcionan la información explicativa para las clases funcionales. Este material debeser visto como instrucciones normativas sobre cómo aplicar las operaciones pertinentes y seleccione apropiada de auditoría oinformación documentación; el uso del verbo auxiliar debe significa que la instrucción es fuertementeprefieren, pero otras pueden ser justificables. Cuando se dan diferentes opciones, la elección se deja al PP / STautor.

Los que PPs autor o ST deben referirse a la cláusula 2 de la norma ISO / IEC 15408-1:2009 para estructuras relevantes, reglas,y orientación:

a) ISO / IEC 15408-1:2009, cláusula 3 d recisa los términos utilizados en la norma ISO / IEC 15408.

b) ISO / IEC 15408-1:2009, Anexo A d e las multas de la estructura para el STB.

c) ISO / IEC 15408-1:2009, Anexo B d ef ines la estructura de los PP.

5 Requisitos funcionales paradigma

Esta cláusula describe el paradigma utilizado en los requisitos funcionales de seguridad de esta parte de la norma ISO / IEC 15408.Conceptos claves discutidos se resaltan en negrita / cursiva. Este numeral no pretende reemplazar o sustituircualquiera de los términos que se encuentran en la norma ISO / IEC 15408-1:2009, cláusula 3 .

Esta parte de la Norma ISO / IEC 15408 es un catálogo de componentes funcionales de seguridad que se puede especificar para un objetivode Evaluación (TOE) . A TOE es un conjunto de software, firmware y / o hardware, posiblemente acompañados por el usuarioy documentación de orientación administrador. A TOE puede contener recursos como medios de almacenamiento electrónico(Por ejemplo, la memoria principal, el espacio en disco), dispositivos periféricos (por ejemplo, impresoras), y la capacidad de cálculo (por ejemplo, tiempo de CPU)que pueden ser utilizados para el procesamiento y almacenamiento de la información y es el objeto de una evaluación.

Evaluación TOE se ocupa principalmente de asegurar que un conjunto definido de requisitos funcionales de seguridad(SFR) se aplica sobre los recursos TOE. Los SFR definen las reglas por las que el TOE gobierna el acceso ay el uso de sus recursos, y por lo tanto la información y servicios controlado por el TOE.

Los SFRs pueden definir múltiples políticas de seguridad en funciones (SFP) para representar las reglas que el TOE debecumplir. Cada una de estas SFP debe especificar su ámbito de control , mediante la definición de los sujetos, objetos, recursos ola información y las operaciones a las que se aplica. Todos los programas de alimentación complementaria son implementadas por la TSF (ver abajo), cuyamecanismos de hacer cumplir las reglas definidas en los SFR y proporcionan capacidades necesarias.

Las partes de un TOE que deben ser invocado por la aplicación correcta de la SFR son colectivamentedenominada la funcionalidad TOE Seguridad (TSF) . La TSF consta de todo el hardware, software yfirmware de un dedo del pie que está directa o indirectamente invocada para la aplicación de la seguridad.

El TOE puede ser un producto monolítico que contiene el hardware, firmware y software.

Alternativamente, un dedo puede ser un producto distribuido que consta internamente de múltiples partes separadas. Cada uno deestas partes del TOE proporciona un servicio en particular para el dedo, y está conectado a las otras partes de laTOE a través de un canal de comunicación interna . Este canal puede ser tan pequeño como un bus del procesador, o puedenabarcar una red interna a la TOE.

Cuando el TOE se compone de varias partes, cada parte del TOE puede tener su propia parte de la TSF queintercambios de usuario y datos de TSF a través de canales de comunicación interna con otras partes de la TSF. Esteinteracción se llama transferencia TOE interna . En este caso las partes separadas de la TSF forman abstractamente lacompuesta TSF, que hace cumplir las SFR.

Interfaces de TOE se pueden localizar en la TOE en particular, o pueden permitir la interacción con otros productos de TIsobre canales de comunicación externos . Estas interacciones externas con otros productos de TI pueden tomar dosformas:

12/6/2014 ISO / IEC 15408-2


2 © ISO / IEC 2008 - Todos los derechos reservados

Página 23

ISO / IEC 15408-2:2008 (E)


a) Los SFRs de la otra "de confianza de TI producto" y las SFRs del TOE han sido administrativamentecoordinado y el otro producto de TI de confianza se supone para hacer cumplir sus SFRs correctamente (por ejemplo, por serevaluado por separado). Los intercambios de información en esta situación se llaman transferencias entre TSF , ya queestán entre las TSF de productos confiables distintas.

b) El otro producto de TI no puede ser de confianza, puede ser llamado un "producto de TI confiable". Por lo tanto sus SFRssean desconocidos o no su aplicación no se considera digno de confianza. Intercambios de TSF mediadasinformación en esta situación se llama transferencias fuera del TOE , ya que no hay TSF (o su políticacaracterísticas son desconocidas) en el otro producto de TI.

El conjunto de interfaces, ya sea interactiva (interfaz hombre-máquina) o programática (de programación de aplicacionesinterfaz), a través del cual se accede a los recursos que están mediadas por el TSF, o se obtiene la informaciónde la TSF, que se conoce como la interfaz de TSF (TSFI) . El TSFI define los límites de la TOEfuncionalidad que prevé la aplicación de la SFR.

Los usuarios se encuentran fuera del TOE. Sin embargo, con el fin de solicitar que los servicios de ser realizadas por el dedo del pie que estáncon sujeción a las reglas definidas en la SFR, los usuarios interactúan con el TOE través del TSFIs. Hay dos tipos deusuarios de interés para esta parte de la norma ISO IEC 15408 /: los usuarios humanos y entidades externos de TI . Los usuarios humanos puedeademás se diferencian como usuarios humanos locales , lo que significa que interactúan directamente con el OE a través de dispositivos TOE(por ejemplo, estaciones de trabajo), o los usuarios humanos a distancia , lo que significa que interactúan indirectamente con el TOE a través de otro de TIproducto.

Un período de la interacción entre los usuarios y la TSF se conoce como un usuario sesión . Establecimiento de usuariosesiones pueden ser controladas sobre la base de una variedad de consideraciones, por ejemplo: la autenticación de usuario, la hora del día,método de acceso a la TOE, y el número de sesiones simultáneas permitidas (por usuario o en total).

Esta parte de la Norma ISO / IEC 15408 se utiliza el término autorizado para significar un usuario que posee los derechos y / oprivilegios necesarios para realizar una operación. El término usuario autorizado , por lo tanto, indica que se tratapermitido para un usuario para realizar una operación específica o un conjunto de operaciones según la definición del SFR.

Para expresar los requisitos que exigen la separación de funciones de administrador, el importe de la garantía funcionalcomponentes (desde FMT_SMR familia) afirman explícitamente que administrativos papeles son obligatorios. Un rol es un pre-conjunto definido de normas que establecen las interacciones permitidas entre un usuario que opera en ese papel y el OE. LaTOE puede apoyar la definición de cualquier número de roles. Por ejemplo, las funciones relacionadas con la operación segura de unTOE puede incluir "Administrador de auditoría" y "Administrador de cuentas de usuario".

TOE contienen recursos que pueden ser utilizados para el procesamiento y almacenamiento de información. El objetivo principal deTSF es la aplicación completa y correcta de los SFRs sobre los recursos y la información que elControles de los pies.

Recursos TOE pueden estructurarse y utilizarse de muchas maneras diferentes. Sin embargo, esta parte de la norma ISO / IEC 15408hace una distinción específica que permite la especificación de propiedades de seguridad deseados. Todas las entidades que puedenser creado a partir de recursos puede caracterizarse en una de dos maneras. Las entidades pueden ser activos, lo que significa queque son la causa de las acciones que se producen interno para las operaciones de TOE y causar que se realizarán eninformación. Alternativamente, las entidades pueden ser pasivos, lo que significa que son o bien el recipiente del queinformación tenga su origen oa la que se almacena la información.

Entidades activas en el TOE que realizan operaciones sobre los objetos se conocen como los sujetos . Varios tipos dePueden existir temas dentro de un TOE:

a) las personas que actúan en nombre de un usuario autorizado (por ejemplo, los procesos de UNIX);

b) aquellos que actúan como un proceso funcional específica que a su vez puede actuar en nombre de varios usuarios (por ejemplo,funciona como se podrían encontrar en las arquitecturas cliente / servidor); o

c) aquellos que actúan como parte de la propia TOE (por ejemplo, los procesos de no actuar en nombre de un usuario).

Esta parte de la Norma ISO / IEC 15408 se ocupa de la ejecución de la SFR sobre tipos de sujetos como los enumeradosanteriormente.

Página 24

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Entidades pasivas del TOE que contienen o recibir información y sobre los que los sujetos realizan operacionesson llamados objetos . En el caso en que un sujeto (un ente activo) es el blanco de una operación (por ejemplo,la comunicación entre procesos), un sujeto puede también ser actuó en como un objeto.

Los objetos pueden contener información . Este concepto es necesario para especificar las políticas de control del flujo de informaciónabordado en la clase FDP.

Los usuarios, temas, información, objetos, sesiones y recursos controlados por las reglas de la SFR pueden poseerciertos atributos que contienen información que es utilizada por el TOE para su correcto funcionamiento. Algunos atributos,tales como los nombres de archivo, puede ser para propósitos informativos o pueden ser utilizados para identificar los recursos individuales, mientrasotras, como la información de control de acceso, pueden existir específicamente para la ejecución de la SFR. Estosúltimos atributos se refieren generalmente como " atributos de seguridad ". El atributo palabra se puede utilizar como untaquigrafía, en algunos lugares de esta parte de la norma ISO / IEC 15408 para la palabra "atributo de seguridad". Sin embargo, no importaqué, puede ser necesario el uso previsto de la información de atributos para tener controles en atributos comodictada por la SFR.

Los datos de una TOE se clasifica como datos de usuario o datos de TSF. Figura 1 De picts esta relación. datos de usuario esla información almacenada en los recursos TOE que se pueden utilizar para los usuarios, de acuerdo con los SFR ysobre la que el TSF coloca ningún significado especial. Por ejemplo, el contenido de un mensaje de correo electrónico eslos datos de usuario. TSF datos es la información utilizada por la TSF en la toma de decisiones como lo exigen los SFR. TSF datospuede estar influenciada por los usuarios si lo permite el SFR. Los atributos de seguridad, los datos de autenticación, TSF internavariables de estado utilizadas por las reglas definidas en los SFR o utilizadas para la protección de la TSF y el accesoentradas de la lista de control son ejemplos de datos de TSF.

Hay varios programas de alimentación complementaria que se aplican a la protección de datos, tales como los SFP de control de acceso y el flujo de informaciónSFP de control . Los mecanismos que implementan los SFP de control de acceso basan sus decisiones de política en los atributosde los usuarios, recursos, sujetos, objetos, sesiones, los datos de estado TSF y las operaciones en el ámbito dede control. Estos atributos se utilizan en el conjunto de normas que rigen las operaciones que los sujetos pueden realizar enobjetos.

Los mecanismos que implementan programas de alimentación complementaria de información de control de flujo basan sus decisiones de política sobre los atributos delos temas y la información en el ámbito del control y el conjunto de normas que rigen las operaciones detemas relativos a la información. Los atributos de la información, que puede estar asociado con los atributos de larecipiente o puede derivarse de los datos en el recipiente, se quedan con la información a medida que es procesada por elTSF.

Figura 1 - Relación entre los datos de usuario y datos de TSF

Dos tipos específicos de datos TSF corregidas por esta parte de la ISO / IEC 15408 puede ser, pero no necesariamente, elmisma. Estos son los datos de autenticación y secretos .

Datos de autenticación se utiliza para comprobar la identidad declarada de un usuario que solicita los servicios de un TOE. El másforma común de datos de autenticación es la contraseña, que depende de que se mantiene en secreto con el fin de ser unmecanismo de seguridad eficaz. Sin embargo, no todas las formas de datos de autenticación deben mantenerse en secreto. Biometricdispositivos de autenticación (por ejemplo, los lectores de huellas digitales, escáneres de retina) no se basan en el hecho de que los datos se mantienesecreto, sino más bien que los datos es algo que sólo un usuario posee y que no puede ser falsificada.

Página 25

ISO / IEC 15408-2:2008 (E)

Los secretos plazo, tal como se utiliza en esta parte de la norma ISO / IEC 15408, si bien son aplicables a la autenticación de datos, está destinado atambién ser aplicables a otros tipos de datos que deben ser mantenidas en secreto con el fin de hacer cumplir un programa de alimentación específico. Paraejemplo, un mecanismo de canal de confianza que se basa en la criptografía de preservar la confidencialidad de lainformación que se transmite a través del canal sólo puede ser tan fuerte como el método utilizado para mantener elclaves criptográficas secretas contra la divulgación no autorizada.

Por lo tanto, algunos, pero no todos, los datos de autenticación tiene que ser mantenido en secreto y algunos, aunque no todos, son secretosutilizado como datos de autenticación. La Figura 2 muestra la relación entre los secretos y los datos de autenticación. En elFigura de los tipos de datos que se encuentran típicamente en los datos de autenticación y las subcláusulas secretos sonindicado.

12/6/2014 ISO / IEC 15408-2



Figura 2 - Relación entre "datos de autenticación" y "secretos"

Componentes funcionales 6 Seguridad

6.1 Información general

Esta cláusula define el contenido y la presentación de los requisitos funcionales de la norma ISO / IEC 15408, yproporciona orientación sobre la organización de los requisitos para los nuevos componentes que se incluirán en un ST. Larequisitos funcionales se expresan en las clases, familias y componentes.

6.1.1 La estructura de clases

La Figura 3 ilustra la estructura de clase funcional en forma de diagrama. Cada clase funcional incluye una clasenombrar, introducción clase, y uno o más familias funcionales.

Figura 3 - Estructura Clase funcional

Página 26

ISO / IEC 15408-2:2008 (E)

6.1.1.1 Nombre de clase

El nombre de la clase subcláusula proporciona la información necesaria para identificar y clasificar una clase funcional. Cadaclase funcional tiene un nombre único. La información categórica consta de un nombre corto de tres caracteres.El nombre corto de la clase se utiliza en la especificación de los nombres cortos de las familias de esa clase.

6.1.1.2 Introducción de Clase

La introducción de clase se establece la voluntad común o enfoque de las familias para satisfacer la seguridadobjetivos. La definición de clases funcionales no refleja ninguna taxonomía formal en la especificación de larequisitos.

La introducción clase proporciona una figura que describe las familias en esta clase y la jerarquía de lacomponentes en cada familia, tal como se explica en 6 0.2.

6.1.2 La estructura familiar

La figura 4 ilustra la estructura de la familia funcional en forma de diagrama.

12/6/2014 ISO / IEC 15408-2



Figura 4 - Estructura de la familia funcional

6.1.2.1 Nombre familiar

El nombre de la familia subcláusula proporciona información categórica y descriptivo necesario identificar ycategorizar una familia funcional. Cada familia funcional tiene un nombre único. La información categórica consistede un nombre corto de siete caracteres, con los tres primeros idéntico al nombre corto de la clase seguido de unun subrayado y el nombre corto de la familia de la siguiente XXX_YYY. La forma corta única del apellidoproporciona el nombre de referencia principal para los componentes.

6.1.2.2 El comportamiento de la familia

El comportamiento de la familia es la descripción narrativa de la familia funcional que indica su objetivo de seguridad y unDescripción general de los requisitos funcionales. Estos se describen en mayor detalle a continuación:

a) Los objetivos de seguridad de la familia de direcciones un problema de seguridad que puede ser resuelto con la ayuda de unDedo del pie que incorpora un componente de esta familia;

b) La descripción de los requisitos funcionales se resumen todos los requisitos que se incluyen en elcomponente (s). La descripción está dirigida a los autores de los PP, STS y paquetes funcionales que deseenevaluar si la familia es relevante para sus necesidades específicas.

Página 27

ISO / IEC 15408-2:2008 (E)

6.1.2.3 Nivelación de componentes

Familias funcionales contienen uno o más componentes, uno cualquiera de los cuales puede ser seleccionado para su inclusión en PPS,ST y paquetes funcionales. El objetivo de este apartado es proporcionar información a los usuarios en la selección de uncomponente funcional apropiada una vez que la familia ha sido identificada como una parte necesaria o útil desus requisitos de seguridad.

Este numeral de la descripción de una familia funcional describe los componentes disponibles, y su razón de ser.Los detalles exactos de los componentes están contenidos dentro de cada componente.

Las relaciones entre los componentes dentro de una familia funcional pueden o no pueden ser jerárquica. Lacomponente es jerárquica a otra si ofrece más seguridad.

Como se explica en 6.2 las descripciones de las familias proporcionan un resumen gráfico de la jerarquía de lacomponentes en una familia.

6.1.2.4 Administración

Los de gestión de cláusulas contienen información para los autores PP / ST considerar como actividades de gestión deun componente dado. Las cláusulas de referencia componentes de la clase de gestión (FMT), y proporcionanorientación con respecto a las actividades de gestión posibles que se pueden aplicar a través de operaciones con esos componentes.

Un autor de PP / ST puede seleccionar los componentes de gestión indicados o puede incluir la gestión de otrosrequisitos que no figuran las actividades de gestión detalle. Como tal, la información debe ser consideradainformativo.

6.1.2.5 Auditoría

Las auditorías requisitos contienen sucesos comprobables para los autores PP / ST para seleccionar, si los requisitos de laclase FAU: Auditoría de seguridad, están incluidos en el PP / ST. Estos requisitos incluyen los eventos relevantes de seguridad entérminos de los diversos niveles de detalle con el apoyo de los componentes de la generación de los datos de auditoría de seguridad(FAU_GEN) fam ilia. Por ejemplo, una nota de auditoría puede incluir acciones que son, en términos de: Minimal - fundadoel uso del mecanismo de seguridad; Básico - cualquier uso del mecanismo de seguridad, así como información relevantecon respecto a los atributos de seguridad que implica; Completo - los cambios de configuración realizados en el mecanismo,

12/6/2014 ISO / IEC 15408-2



incluyendo los valores de configuración reales antes y después del cambio.

Debe observarse que la categorización de los eventos auditables es jerárquica. Por ejemplo, cuando básicoSe desea Generación de auditoría, todos los sucesos comprobables que se considere que tanto mínimo y básico deben incluirseen el PP / ST a través de la utilización de la operación de asignación apropiado, excepto cuando el evento de nivel más altosimplemente proporciona más detalle que el evento de nivel inferior. Cuando se desea Generación de auditoría detallada, todaeventos auditables identificados (Minimal, básica y de detalle) deben ser incluidos en el PP / ST.

En la clase FAU: Auditoría de Seguridad de las normas que rigen la auditoría se explican con más detalle.

Página 28

ISO / IEC 15408-2:2008 (E)

6.1.3 Estructura de componentes

La Figura 5 ilustra la estructura de componente funcional.

Figura 5 - Estructura componente funcional

6.1.3.1 Identificación de los componentes

La subcláusula identificación de componentes proporciona información descriptiva necesaria para identificar, categorizar,registrar y referencias cruzadas de un componente. A continuación se proporciona como parte de cada componente funcional:

Un nombre único . El nombre refleja el propósito del componente.

Un nombre corto . Una forma corta única del nombre del componente funcional. Este nombre corto sirve como el principalnombre de referencia para la categorización, el registro y la referencia cruzada del componente. Este nombre cortorefleja la clase y la familia a la que pertenece el componente y el número de componentes dentro de la familia.

A jerárquico-a la lista . Una lista de otros componentes que este componente es jerárquica a y para el cual estacomponente se puede utilizar para satisfacer las dependencias de los componentes indicados.

6.1.3.2 Elementos funcionales

Se proporciona un conjunto de elementos para cada componente. Cada elemento se define individualmente y es autónomo.

Un elemento funcional es un requisito funcional de seguridad que si se deben dividir además no produciría una significativaresultado de la evaluación. Es el requisito funcional de seguridad más pequeño identificado y reconocido en la norma ISO / IEC 15408.

Cuando los paquetes de construcción, PP y / o ST, no se le permite seleccionar sólo uno o más elementos de una

12/6/2014 ISO / IEC 15408-2



componente. El conjunto completo de elementos de un componente debe ser seleccionada para su inclusión en un PP, ST opaquete.

Se proporciona una forma corta única del nombre del elemento funcional. Por ejemplo, el nombre de requisitoFDP_IFF.4.2 dice lo siguiente: F - requisito funcional, DP - clase "de protección de datos de usuario", _IFF - familia"Flujo de información las funciones de control", 0,4 - cuarto componente denominado "eliminación parcial de la información ilícita fluye",0,2 - segundo elemento del componente.

6.1.3.3 Dependencias

Dependencias entre los componentes funcionales surgen cuando un componente no es autosuficiente y depende de lafuncionalidad o interacción con otro elemento para su propio funcionamiento adecuado.

Página 29

ISO / IEC 15408-2:2008 (E)

Cada componente funcional ofrece una lista completa de las dependencias a otros trabajos para atestiguar y funcionalcomponentes. Algunos componentes pueden enumerar "No hay dependencias". Los componentes dependían puede a su veztener dependencias de otros componentes. La lista que figura en los componentes será la directadependencias. Eso es sólo referencias a los requisitos funcionales que se requieren para este requisito derealizar su trabajo correctamente. Las dependencias indirectas, que son las dependencias que resultan de la dependidodependiendo de los componentes se pueden encontrar en un NEX A de esta parte de la norma ISO / IEC 15408. Cabe señalar que en algunos casos ladependencia es opcional en la que se proporcionan una serie de requisitos funcionales, donde cada uno de ellossería suficiente para satisfacer la dependencia (ver por ejemplo la integridad de cambio FDP_UIT.1 de datos).

La lista de dependencias identifica los componentes funcionales o de garantía de mínimos necesarios para satisfacer la seguridadrequisitos asociados con un componente identificado. Los componentes que son jerárquica a la identificadocomponente también se puede utilizar para satisfacer la dependencia.

Las dependencias que se indican en esta parte de la norma ISO / IEC 15408 son normativas. Ellos deben cumplirse dentro de unPP / ST. En las situaciones específicas de las dependencias indicadas podrían no ser aplicables. El autor de PP / ST, porindicación de los fundamentos de por qué no es el caso, puede dejar al dependía componente del paquete,PP o ST.

6.2 Catálogo de componentes

La agrupación de los componentes de esta parte de la norma ISO / IEC 15408 no refleja ninguna taxonomía formal.

Esta parte de la Norma ISO / IEC 15408 contiene clases de familias y componentes, que son agrupaciones ásperos en labase de la función o propósito relacionado, presenta en orden alfabético. Al inicio de cada clase es un informativoDiagrama que indica la taxonomía de cada clase, indicando las familias en cada categoría y los componentes encada familia. El diagrama es un indicador útil de la relación jerárquica que pueda existir entrecomponentes.

En la descripción de los componentes funcionales, un subcláusula identifica las dependencias entre elcomponente y cualquier otro componente.

En cada clase una figura que describe la jerarquía de la familia similar a la Figura 6 , se proporciona. En la Figura 6 la primerafamilia, de la familia 1, contiene tres componentes jerárquicos, en los que el componente 2 y el componente 3 pueden ser ambasutilizado para satisfacer las dependencias en el componente 1. Componente 3 es jerárquica al componente 2 y puede ser tambiénutilizado para satisfacer las dependencias en el componente 2.

Diagrama de la descomposición de clase de la muestra - la figura 6

En la familia de 2 hay tres componentes no todos los cuales son jerárquica. Componentes 1 y 2 son jerárquicaa ningún otro componente. Componente 3 es jerárquica al componente 2, y se puede utilizar para satisfacerdependencias de componente 2, pero no para satisfacer las dependencias en el componente 1.

En Familia 3, los componentes 2, 3, y 4 son jerárquicos al componente 1. Componentes 2 y 3 son ambos

12/6/2014 ISO / IEC 15408-2



jerárquica al componente 1, pero no comparable. Componente 4 es jerárquica para los dos componentes 2 ycomponente 3.

Página 30

ISO / IEC 15408-2:2008 (E)


Estos esquemas son solamente para complementar el texto de las familias y facilitar la identificación de las relacionesmás fácil. No sustituyen a la "jerárquica a:" nota en cada componente que es la afirmación obligatoria dejerarquía para cada componente.

6.2.1 cambios de componentes destacando

La relación entre los componentes dentro de una familia se pone de relieve utilizando una negrita convención. Esta negritaconvención pide la negrita de todos los nuevos requisitos. Para los componentes jerárquicos, los requisitos sonen negrita cuando están potenciados o modificados más allá de los requisitos del componente anterior. Además,cualquier operación de nuevos o mejorados permitidas más allá del componente anterior también se destacan el uso de negritaescriba.

7 Clase FAU: Auditoría de seguridad

La auditoría de seguridad implica reconocer, registrar, almacenar y analizar la información relacionada con la seguridadactividades pertinentes (es decir, las actividades controladas por el TSF). Los registros de auditoría resultantes pueden ser examinados paradeterminar las actividades pertinentes de seguridad se llevaron a cabo y quién (qué usuario) es responsable de ellos.

Figura 7 - FAU: Seguridad clase de auditoría descomposición

Página 31

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Respuesta automática 7.1 Auditoría de seguridad (FAU_ARP)

7.1.1 Familia Comportamiento

Esta familia define la respuesta que deben adoptarse en caso de eventos detectados que indican un potencial para la seguridadviolación.

7.1.2 nivelación de componentes

En las alarmas FAU_ARP.1 Seguridad, th e TSF debe tomar medidas en caso de que se detecte una posible violación de la seguridad.

7.1.3 Gestión de FAU_ARP.1

Las siguientes acciones podrían ser consideradas para las funciones de gestión en FMT:

a) la gestión (alta, baja o modificación) de las acciones.

7.1.4 Auditoría de FAU_ARP.1

Las siguientes acciones deben ser auditable si la generación de datos de auditoría FAU_GEN seguridad está incluido en elPP / ST:

a) Mínimo: Las acciones tomadas por los posibles violaciónes de seguridad.

7.1.5 alarmas FAU_ARP.1 Seguridad

Jerárquica para: No hay otros componentes.

Dependencias: Análisis violación potencial FAU_SAA.1

7.1.5.1 FAU_ARP.1.1

La TSF debe tomar [asignación: lista de acciones ] ante la detección de una posible violación de la seguridad.

Generación de los datos 7.2 Auditoría de seguridad (FAU_GEN)


Esta familia define requisitos para el registro de la ocurrencia de los eventos relevantes de seguridad que se llevan a cabo bajoControl de TSF. Esta familia identifica el nivel de auditoría, se enumeran los tipos de eventos que serán auditablespor el TSF, e identifica el conjunto mínimo de información relacionados con la auditoría que se debe proporcionar dentro de variosTipos de registros de auditoría.


Generación de datos FAU_GEN.1 Auditoría defi ne el nivel de los eventos auditables y especifica la lista de datos que deberánregistrarse en cada registro.

En FAU_GEN.2 asociación identidad del usuario, t él TSF debe asociar eventos auditables a las identidades de usuario individuales.

7.2.3 Gestión de FAU_GEN.1, FAU_GEN.2

No hay actividad de gestión prevista.

7.2.4 Auditoría de FAU_GEN.1, FAU_GEN.2

No hay eventos auditables previstas.

Página 32

ISO / IEC 15408-2:2008 (E)

7.2.5 generación de los datos FAU_GEN.1 Auditoría


Dependencias: FPT_STM.1 marcas de tiempo fiables

7.2.5.1 FAU_GEN.1.1

12/6/2014 ISO / IEC 15408-2



La TSF debe ser capaz de generar un registro de auditoría de los siguientes eventos auditables:

a) Puesta en marcha y parada de las funciones de auditoría;

b) Todos los sucesos comprobables para la [selección, elegir uno de: mínimo, básico, detallado, no especificado ]nivel de auditoría; y

c) [asignación: otros eventos auditables definidos específicamente ].

7.2.5.2 FAU_GEN.1.2

La TSF debe registrar dentro de cada registro de auditoría, al menos, la siguiente información:

a) Fecha y hora del evento, tipo de evento, identidad de objeto (si se aplica), y el resultado(Éxito o fracaso) del evento; y

b) Para cada tipo de evento de auditoría, basándose en las definiciones de eventos auditables de los componentes funcionalesincluido en el PP / ST, [asignación: otra auditoría de la información pertinente ].

7.2.6 asociación identidad FAU_GEN.2 usuario


Dependencias: FAU_GEN.1 generación de los datos de auditoría

FIA_UID.1 Momento de la identificación

7.2.6.1 FAU_GEN.2.1

Para los eventos de auditoría que resulten de las acciones de los usuarios identificados, la TSF debe ser capaz de asociar cadaevento auditable con la identidad del usuario que causó el evento.

7.3 análisis de las auditorías de seguridad (FAU_SAA)


Esta familia define requisitos para medios automáticos que analizan la actividad del sistema y de los datos de auditoría en busca deposibles o reales violaciónes de seguridad. Este análisis puede trabajar en apoyo de detección de intrusos, o automáticorespuesta a una potencial violación de la seguridad.

Las acciones a realizar sobre la base de la detección se pueden especificar utilizando la respuesta automática de auditoría de seguridad(FAU_ARP) fa milia si lo deseas.


En FAU_SAA.1 análisis de potencial violación , la detección del umbral de base a partir de una regla fija establecida esrequerida.

En FAU_SAA.2 perfil basado detección de anomalías, t él TSF mantiene perfiles individuales de uso del sistema, dondeun perfil representa los patrones históricos de uso realizadas por miembros del grupo de destino de perfil. Un perfilgrupo objetivo se refiere a un grupo de una o más personas (por ejemplo, un único usuario, los usuarios que comparten un ID de grupo o

Página 33

ISO / IEC 15408-2:2008 (E)

cuenta de grupo, los usuarios que operan con un papel asignado, los usuarios de un sistema o nodo de red) queinteractuar con el TSF. Cada miembro de un grupo objetivo perfiles se le asigna una calificación individual sospecha de querepresenta lo bien que la actividad actual de ese miembro corresponde a los patrones establecidos de usorepresentado en el perfil. Este análisis se puede realizar en tiempo de ejecución o durante un lote de modo después de la recolecciónanálisis.

En FAU_SAA.3 heurística simple ataque, la TSF debe ser capaz de detectar la ocurrencia de eventos de firmaque representan una amenaza significativa para la ejecución de la SFR. Esta búsqueda de eventos de firma puede ocurrir enen tiempo real o durante un análisis en modo por lotes después de la recolección.

En FAU_SAA.4 heurística de ataque complejos, t él TSF debe ser capaz de representar y detectar múltiples pasos de intrusionesescenarios. La TSF es capaz de comparar los eventos del sistema (posiblemente realizadas por varios individuos) contrasecuencias de eventos conocidos para representar a la totalidad de los escenarios de intrusión. La TSF debe ser capaz de indicar cuándo unevento de la firma o la secuencia de eventos se encuentra que indica una posible violación de la ejecución de la SFR.

7.3.3 Gestión de FAU_SAA.1


a) el mantenimiento de las normas por parte de (adición, modificación, supresión) de las reglas del conjunto de reglas.

12/6/2014 ISO / IEC 15408-2





a) mantenimiento (supresión, modificación, adición) del grupo de usuarios en el grupo de destino de perfil.



a) mantenimiento (supresión, modificación, adición) del subconjunto de los eventos del sistema.



a) mantenimiento (supresión, modificación, adición) del subconjunto de los eventos del sistema;

b) mantenimiento (supresión, modificación, adición) del conjunto de la secuencia de eventos del sistema.

7.3.7 Auditoría de FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4


a) Mínimo: Activación y desactivación de cualquiera de los mecanismos de análisis;

b) mínimos: respuestas automatizadas realizadas por la herramienta.

7.3.8 FAU_SAA.1 análisis Potencial violación



Página 34

ISO / IEC 15408-2:2008 (E)

7.3.8.1 FAU_SAA.1.1

La TSF debe ser capaz de aplicar un conjunto de reglas en la vigilancia de los eventos auditados y en base a estosnormas indican una violación potencial de la aplicación de la SFR.

7.3.8.2 FAU_SAA.1.2

La TSF debe aplicar las siguientes reglas para el seguimiento de los eventos auditados:

a) La acumulación o combinación de [asignación: subconjunto de incidentes auditables definidos ] sabe queindicar una potencial violación de la seguridad;

b) [asignación: cualquier otra regla ].

Detección de anomalías 7.3.9 FAU_SAA.2 Perfil basada


Dependencias: FIA_UID.1 Momento de la identificación

7.3.9.1 FAU_SAA.2.1

La TSF debe ser capaz de mantener perfiles de uso del sistema, donde un perfil individual representa lapatrones históricos de uso realizado por el miembro (s) de [asignación: el grupo objetivo perfil ].

7.3.9.2 FAU_SAA.2.2

La TSF debe ser capaz de mantener una calificación de sospecha asociado con cada usuario cuya actividad esregistrada en un perfil, en donde la calificación de sospecha representa el grado en el cual la corriente del usuariola actividad se encontró incompatible con los patrones establecidos de uso representado en el perfil.

12/6/2014 ISO / IEC 15408-2



7.3.9.3 FAU_SAA.2.3La TSF debe ser capaz de indicar una posible violación de la ejecución de los SFR cuando de un usuariocalificación sospecha excede las siguientes condiciones mínimas [asignación: condiciones bajo las cualesactividad anómala es reportado por la TSF ].

7.3.10 FAU_SAA.3 heurística simple ataque


Dependencias: No hay dependencias.

7.3.10.1 FAU_SAA.3.1

La TSF debe ser capaz de mantener una representación interna de los siguientes eventos de firma[Asignación: un subconjunto de los eventos del sistema ] que pueden indicar una violación de la ejecución de la SFR.

7.3.10.2 FAU_SAA.3.2

La TSF debe ser capaz de comparar los eventos de firmas contra el registro de la actividad del sistemaperceptible a partir de un examen de [asignación: la información que se utilizará para determinar el sistemaactividad ].

7.3.10.3 FAU_SAA.3.3

La TSF debe ser capaz de indicar una posible violación de la ejecución de los SFR cuando un sistemaevento se encuentra para que coincida con un evento de la firma que indica una posible violación de la ejecución de laSFR.

Página 35

ISO / IEC 15408-2:2008 (E)

7.3.11 FAU_SAA.4 heurística de ataque complejos

Jerárquica para: FAU_SAA.3 heurística simple ataque


7.3.11.1 FAU_SAA.4.1

La TSF debe ser capaz de mantener una representación interna de las siguientes secuencias de eventos de conocidoescenarios de intrusión [asignación: lista de secuencias de eventos del sistema cuya ocurrencia sonrepresentante de escenarios de penetración conocidos ] y los siguientes acontecimientos de la firma [asignación: un subconjuntode eventos del sistema ] que pueden indicar una potencial violación de la ejecución de la SFR.

7.3.11.2 FAU_SAA.4.2

La TSF debe ser capaz de comparar los acontecimientos de la firma y las secuencias de eventos con el registro del sistemaactividad perceptible a partir de un examen de [asignación: la información que se utilizará para determinar el sistemaactividad ].

7.3.11.3 FAU_SAA.4.3

La TSF debe ser capaz de indicar una posible violación de la ejecución de los SFR cuando el sistema de actividad esencontrado para que coincida con un evento de firma de secuencia o evento que indica una posible violación de la ejecución de laslos SFR.

7.4 Revisión de Auditoría de Seguridad (FAU_SAR)


Esta familia define los requisitos para las herramientas de auditoría que deben estar disponibles para los usuarios autorizados para asistir en larevisión de los datos de auditoría.


FAU_SAR.1 Examen de auditoría, pr ovides la capacidad de leer la información de los registros de auditoría.

FAU_SAR.2 examen de auditoría Restringido, exige que no haya otros usuarios excepto aquellos que han sidoi identificados n FAU_SAR.1 revisión Auditoría t sombrero puedo leer la información.

FAU_SAR.3 seleccionable examen de auditoría, r equiere herramientas de revisión de auditoría para seleccionar los datos de auditoría que se analizará teniendo enen criterios.

7.4.3 Gestión de FAU_SAR.1

12/6/2014 ISO / IEC 15408-2




a) mantenimiento (supresión, modificación, adición) del grupo de usuarios con acceso de lectura derecho de la auditoríaregistros.

7.4.4 Gestión de FAU_SAR.2, FAU_SAR.3


7.4.5 Auditoría de FAU_SAR.1


a) básica: Lectura de la información de los registros de auditoría.

Página 36

ISO / IEC 15408-2:2008 (E)



a) básica: Intentos sin éxito de leer la información de los registros de auditoría.



a) Detallado: los parámetros utilizados para la visualización.

7.4.8 revisión FAU_SAR.1 Auditoría



7.4.8.1 FAU_SAR.1.1

La TSF debe proporcionar [asignación: usuarios autorizados ] con la capacidad de leer [asignación: lista deauditoría de la información ] a partir de los registros de auditoría.

7.4.8.2 FAU_SAR.1.2

La TSF debe proporcionar los registros de auditoría de una manera adecuada para el usuario para interpretar la información.

7.4.9 FAU_SAR.2 restringido examen de auditoría


Dependencias: Examen de auditoría FAU_SAR.1

7.4.9.1 FAU_SAR.2.1

La TSF debe prohibir a todos los usuarios acceso de lectura a los registros de auditoría, salvo aquellos usuarios que han sidootorgado lectura acceso explícito.

7.4.10 revisión FAU_SAR.3 auditoría seleccionable


Dependencias: Examen de auditoría FAU_SAR.1

7.4.10.1 FAU_SAR.3.1

La TSF debe ofrecer la capacidad de aplicar [asignación: los métodos de selección y / o pedidos ] de auditoríadatos basados en [asignación: criterios con relaciones lógicas ].

Selección de eventos 7.5 Auditoría de seguridad (FAU_SEL)


12/6/2014 ISO / IEC 15408-2



Esta familia define requisitos para seleccionar el conjunto de eventos que se van a auditar durante el funcionamiento TOE del conjunto detodos los eventos auditables.

Página 37

ISO / IEC 15408-2:2008 (E)



FAU_SEL.1 auditoría selectiva, r equiere la posibilidad de seleccionar el conjunto de eventos a auditar a partir del conjunto de todos loseventos auditables, identificó i n FAU_GEN.1 la generación de datos de auditoría, como fundamento los atributos de la que determine laPP / ST autor.

7.5.3 Gestión de FAU_SEL.1


a) el mantenimiento de los derechos para ver / modificar los eventos de auditoría.

7.5.4 Auditoría de FAU_SEL.1


a) Mínimo: Todas las modificaciones de la configuración de auditoría que se producen mientras que las funciones de recopilación de auditoría sonoperativo.

7.5.5 FAU_SEL.1 auditoría selectiva



Gestión FMT_MTD.1 de datos TSF

7.5.5.1 FAU_SEL.1.1

La TSF debe ser capaz de seleccionar el conjunto de eventos a auditar a partir del conjunto de todos los eventos auditablessobre la base de los siguientes atributos:

a) [selección: objeto de identidad, la identidad del usuario, la identidad de sujeto, identidad del host, tipo de evento ]

b) [asignación: lista de atributos adicionales que la selectividad de auditoría se basa en ]

Almacenamiento de eventos 7.6 Auditoría de seguridad (FAU_STG)


Esta familia define los requisitos para la TSF para ser capaz de crear y mantener un registro de auditoría seguro. Almacenadoregistros de auditoría se refiere a aquellos registros dentro de la pista de auditoría, y no a los registros de auditoría que se han recuperado(Para el almacenamiento temporal) a través de la selección.


En FAU_STG.1 Protegida almacenamiento pista de auditoría, r equirements se colocan en la pista de auditoría. Se protegidade eliminación y / o modificación no autorizada.

FAU_STG.2 Garantías de disponibilidad de los datos de auditoría, especifica las garantías que la TSF mantiene por encima deldatos de auditoría dada la ocurrencia de una condición no deseada.

FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría, s acciones pecifies que deben adoptarse en caso de un umbral sobre la auditoríase supera sendero.

Prevención FAU_STG.4 de pérdida de datos de auditoría, espe cifies acciones en caso de que el registro de auditoría está lleno.

12/6/2014 ISO / IEC 15408-2


Página 38ISO / IEC 15408-2:2008 (E)


7.6.3 Gestión de FAU_STG.1




a) el mantenimiento de los parámetros que controlan la capacidad de almacenamiento de auditoría.



a) el mantenimiento del umbral;

b) mantenimiento (supresión, modificación, adición) de las acciones que deben adoptarse en caso de almacenamiento de auditoría inminentefracaso.



a) mantenimiento (supresión, modificación, adición) de las acciones que deben adoptarse en caso de fallo de almacenamiento de auditoría.

7.6.7 Auditoría de FAU_STG.1, FAU_STG.2


7.6.8 Auditoría de FAU_STG.3


a) Básicas: Las acciones tomadas por haber excedido un umbral.

7.6.9 Auditoría de FAU_STG.4


a) Básicas: Las acciones tomadas por el fallo de almacenamiento de auditoría.

7.6.10 FAU_STG.1 auditoría Protegida almacenamiento rastro



7.6.10.1 FAU_STG.1.1

La TSF debe proteger los registros de auditoría almacenados en el registro de auditoría de la destrucción no autorizadas.

7.6.10.2 FAU_STG.1.2

La TSF debe ser capaz de [selección, elegir uno de: prevenir, detectar ] modificaciones no autorizadas en laregistros de auditoría almacenados en el registro de auditoría.

Página 39

ISO / IEC 15408-2:2008 (E)

7.6.11 FAU_STG.2 Garantías de disponibilidad de los datos de auditoría

Jerárquica para: FAU_STG.1 Protegida auditoría almacenamiento rastro


12/6/2014 ISO / IEC 15408-2



7.6.11.1 FAU_STG.2.1

La TSF debe proteger los registros de auditoría almacenados en el registro de auditoría de la destrucción no autorizadas.

7.6.11.2 FAU_STG.2.2

La TSF debe ser capaz de [selección, elegir uno de: prevenir, detectar ] modificaciones no autorizadas en el almacenadoregistros de auditoría en el registro de auditoría.

7.6.11.3 FAU_STG.2.3

La TSF debe garantizar que [Asignación: métrica para guardar los registros de auditoría ] registros de auditoría almacenados seránmantenida cuando las siguientes condiciones se dan: [selección: el agotamiento de almacenamiento de auditoría, el fracaso, el ataque ].

7.6.12 FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría


Dependencias: FAU_STG.1 Protegida auditoría almacenamiento rastro

7.6.12.1 FAU_STG.3.1

La TSF debe [asignación: acciones a tomar en caso de un posible fallo de almacenamiento de auditoría ] si la auditoríarastro excede [asignación: límite predefinido ].

7.6.13 Prevención FAU_STG.4 de pérdida de datos de auditoría

Jerárquica para: FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría

Dependencias: FAU_STG.1 Protegida auditoría almacenamiento rastro

7.6.13.1 FAU_STG.4.1

La TSF debe [selección, elegir uno de: "ignorar eventos auditados", "prevenir eventos auditados, exceptolas adoptadas por el usuario autorizado con derechos especiales "," sobrescribe los registros de auditoría más antiguos almacenados " ]y [asignación: otras acciones que deben adoptarse en caso de fallo de almacenamiento de auditoría ] si el registro de auditoría está lleno.

Página 40

ISO / IEC 15408-2:2008 (E)

8 Clase FCO: Comunicación

Esta clase proporciona dos familias que específicamente se ocupan de asegurar la identidad de la parte que participe en unaintercambio de datos. Estas familias están relacionadas con asegurar la identidad del originador de la información transmitida(Prueba de origen) y asegurando la identidad del destinatario de la información transmitida (prueba de recibo). Estosfamilias aseguran que un autor no puede negar haber enviado el mensaje, ni pueden negar que el destinatariorecibido.

Figura 8 - FCO: Comunicación clase descomposición

12/6/2014 ISO / IEC 15408-2



8.1 No repudio de origen (FCO_NRO)


No repudio de origen garantiza que el autor de la información no puede negar haber enviado con éxito lainformación. Esta familia requiere que el TSF proporcionar un método para asegurar que un sujeto que recibeinformación durante un intercambio de datos se proporciona con la evidencia del origen de la información. Esta evidenciaentonces puede ser verificado por cualquiera este tema u otros temas.


FCO_NRO.1 prueba selectiva de origen, requiere la TSF para proporcionar los sujetos con la capacidad de peticiónevidencia de origen de la información.

Prueba FCO_NRO.2 forzada de origen, r equiere que el TSF siempre generan evidencia de origen para transmisióninformación.

8.1.3 Gestión de FCO_NRO.1, FCO_NRO.2


a) La gestión de los cambios en los tipos de información, los campos, los atributos originales y los destinatarios de las pruebas.

8.1.4 Auditoría de FCO_NRO.1


a) Mínimo: La identidad del usuario que solicitó que las pruebas de origen se generaría.

b) Minimal: La invocación del servicio de no repudio.

c) básica: Identificación de la información, el destino, y una copia de las pruebas presentadas.

d) Datos individuales: La identidad del usuario que solicitó la verificación de las pruebas.

Página 41

ISO / IEC 15408-2:2008 (E)

8.1.5 Auditoría de FCO_NRO.2


a) Mínimo: La invocación del servicio de no repudio.

b) básica: Identificación de la información, el destino, y una copia de las pruebas presentadas.

c) Datos individuales: La identidad del usuario que solicitó la verificación de las pruebas.

8.1.6 FCO_NRO.1 prueba selectiva de origen



8.1.6.1 FCO_NRO.1.1

La TSF debe ser capaz de generar evidencia de origen para transmisión [asignación: lista de informacióntipos ] a petición de la [selección: originales, receptores, [asignación: lista de terceros] ].

8.1.6.2 FCO_NRO.1.2

La TSF debe ser capaz de relacionar la [asignación: lista de atributos ] del autor de la información,y el [asignación: lista de campos de información ] de la información a la que se aplica la evidencia.

8.1.6.3 FCO_NRO.1.3

12/6/2014 ISO / IEC 15408-2



La TSF debe ofrecer la posibilidad de verificar la evidencia de origen de la información para [selección:originador, destinatario, [asignación: lista de terceros] ] dado [asignación: limitaciones en la evidenciade origen ].

8.1.7 FCO_NRO.2 forzada prueba de origen

Jerárquica para: FCO_NRO.1 prueba selectiva de origen


8.1.7.1 FCO_NRO.2.1

La TSF debe aplicar la generación de evidencia de origen para transmisión [asignación: lista de informacióntipos ] en todo momento.

8.1.7.2 FCO_NRO.2.2

La TSF debe ser capaz de relacionar la [asignación: lista de atributos ] del autor de la información, y la[Asignación: lista de campos de información ] de la información a la que se aplica la evidencia.

8.1.7.3 FCO_NRO.2.3

La TSF debe ofrecer la posibilidad de verificar la evidencia de origen de la información para [selección: emisor,receptor, [asignación: lista de terceros] ] dado [asignación: limitaciones de las pruebas de origen ].

Página 42

ISO / IEC 15408-2:2008 (E)

8.2 No repudio de recepción (FCO_NRR)


No repudio de recibo se garantiza que el receptor de la información no puede negarse a recibir con éxito lainformación. Esta familia requiere que el TSF proporcionar un método para asegurar que un sujeto que transmiteinformación durante un intercambio de datos se proporciona con la evidencia de la recepción de la información. Esta evidencia puedeluego ser verificada por cualquiera de este tema u otros temas.


FCO_NRR.1 prueba selectiva de la recepción, requiere de la TSF para proporcionar los sujetos con una capacidad de peticiónevidencia de la recepción de la información.

Prueba FCO_NRR.2 forzada de recibo, r equiere que el TSF siempre genera un acuse de recibo para recibirinformación.

8.2.3 Gestión de FCO_NRR.1, FCO_NRR.2


a) La gestión de los cambios en los tipos de información, los campos, los atributos originales y los terceros destinatariosde pruebas.

8.2.4 Auditoría de FCO_NRR.1


a) Mínimo: La identidad del usuario que solicitó que las pruebas de recepción se generaría.

b) Minimal: La invocación del servicio de no repudio.

c) básica: Identificación de la información, el destino, y una copia de las pruebas presentadas.

d) Datos individuales: La identidad del usuario que solicitó la verificación de las pruebas.

8.2.5 Auditoría de FCO_NRR.2


12/6/2014 ISO / IEC 15408-2



a) Mínimo: La invocación del servicio de no repudio.

b) básica: Identificación de la información, el destino, y una copia de las pruebas presentadas.

c) Datos individuales: La identidad del usuario que solicitó la verificación de las pruebas.

8.2.6 FCO_NRR.1 prueba selectiva de recibo



8.2.6.1 FCO_NRR.1.1

La TSF debe ser capaz de generar un acuse de recibo para recibir [asignación: lista de informacióntipos ] a petición de la [selección: originales, receptores, [asignación: lista de terceros] ].

Página 43

ISO / IEC 15408-2:2008 (E)

8.2.6.2 FCO_NRR.1.2

La TSF debe ser capaz de relacionar la [asignación: lista de atributos ] del destinatario de la información,y el [asignación: lista de campos de información ] de la información a la que se aplica la evidencia.

8.2.6.3 FCO_NRR.1.3

La TSF debe ofrecer la posibilidad de verificar la evidencia de la recepción de la información a la [selección:originador, destinatario, [asignación: lista de terceros] ] dado [asignación: limitaciones en la evidenciade recepción ].

8.2.7 FCO_NRR.2 forzada prueba de recibo

Jerárquica para: FCO_NRR.1 prueba selectiva de recibo


8.2.7.1 FCO_NRR.2.1

La TSF debe aplicar la generación de un acuse de recibo para recibir [asignación: lista de informacióntipos ] en todo momento.

8.2.7.2 FCO_NRR.2.2

La TSF debe ser capaz de relacionar la [asignación: lista de atributos ] del destinatario de la información, y la[Asignación: lista de campos de información ] de la información a la que se aplica la evidencia.

8.2.7.3 FCO_NRR.2.3

La TSF debe ofrecer la posibilidad de verificar la evidencia de la recepción de la información a la [selección: emisor,receptor, [asignación: lista de terceros] ] dado [asignación: limitaciones de las pruebas de recepción ].

12/6/2014 ISO / IEC 15408-2



Página 44

ISO / IEC 15408-2:2008 (E)


9 Clase FCS: Apoyo criptográfico

La TSF puede emplear la funcionalidad criptográfica para ayudar a satisfacer varios objetivos de seguridad de alto nivel. Estosincluir (pero no se limitan a): identificación y autenticación, no repudio, ruta de confianza, el canal de confianzay separación de datos. Esta clase se utiliza cuando el TOE implementa funciones criptográficas, laimplementación de lo que podría ser en el hardware, firmware y / o software.

Los FCS: Apoyo criptográfico clase se compone de dos familias: la gestión de claves criptográficas(FCS_CKM) una operación criptográfica nd (FCS_COP). La gestión de claves de cifrado (FCS_CKM)familia ocupa de los aspectos de gestión de claves criptográficas, mientras que la operación de cifrado(FCS_COP) fa milia se ocupa de la utilización práctica de esas claves criptográficas.

Figura 9 - FCS: Clase de Apoyo criptográfico descomposición

9.1 de gestión de claves de cifrado (FCS_CKM)


Las claves criptográficas deben ser manejados a través de su ciclo de vida. Esta familia tiene la intención de apoyar esaciclo de vida y, consecuentemente, define los requisitos para las siguientes actividades: generación de claves criptográficas,distribución de claves criptográficas, acceso de claves criptográficas y destrucción de claves criptográficas. Esta familia debeincluir de ser hay requisitos funcionales para la gestión de claves criptográficas.


La generación de claves de cifrado FCS_CKM.1, r equiere claves criptográficas que se generen de acuerdo con unespecificada algoritmo y tamaños de clave que puede basarse en un estándar asignado.

Distribución de la clave de cifrado FCS_CKM.2, r equiere claves criptográficas que se distribuirán de acuerdo con unmétodo de distribución especificada, que puede basarse en un estándar asignado.

FCS_CKM.3 criptográfico clave de acceso, r equiere acceso a claves criptográficas que se deben realizar de conformidadcon un método de acceso especificada que puede estar basado en una norma asignada.

FCS_CKM.4 criptográfico Destrucción de claves, r equiere claves criptográficas para ser destruidos de acuerdo con unmétodo de destrucción especificado que puede estar basado en un estándar asignado.

12/6/2014 ISO / IEC 15408-2


Página 45

ISO / IEC 15408-2:2008 (E)


9.1.3 Gestión de FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4


9.1.4 Auditoría de FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4


a) Mínimo: El éxito y el fracaso de la actividad.

b) Básico: El atributo (s) objeto y valor del objeto (s) con exclusión de toda información sensible (por ejemplo, en secreto oclaves privadas).

9.1.5 FCS_CKM.1 criptográfico de generación de claves


Dependencias: [ distribución de claves FCS_CKM.2 criptográfico, o

Operación criptográfica FCS_COP.1]

Destrucción de claves de cifrado FCS_CKM.4

9.1.5.1 FCS_CKM.1.1

La TSF debe generar las claves de cifrado de acuerdo con una clave criptográfica especificadaalgoritmo de generación [asignación: algoritmo de generación de claves criptográficas ] y especifiquetamaños criptográficos de clave [asignación: tamaños de clave ] que cumplan con lo siguiente: [asignación:lista de normas ].

9.1.6 FCS_CKM.2 distribución de claves criptográficas


Dependencias: [ FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad, o

FDP_ITC.2 Importación de datos de usuario con atributos de seguridad, o

La generación de claves de cifrado FCS_CKM.1]


9.1.6.1 FCS_CKM.2.1

La TSF debe distribuir claves criptográficas de acuerdo con una clave criptográfica especificadamétodo de distribución [asignación: método de distribución de claves criptográficas ] que cumpla con lo siguiente:[Asignación: lista de estándares ].

9.1.7 FCS_CKM.3 acceso de claves criptográficas






Página 46

ISO / IEC 15408-2:2008 (E)

9.1.7.1 FCS_CKM.3.1

La TSF debe realizar [asignación: tipo de acceso a claves criptográficas ] de acuerdo con un determinadométodo de acceso de claves criptográficas [asignación: método de acceso a claves criptográficas ] que responde a las

12/6/2014 ISO / IEC 15408-2



siguiente: [asignación: lista de estándares ].

9.1.8 FCS_CKM.4 criptográfico Destrucción de claves





9.1.8.1 FCS_CKM.4.1

La TSF debe destruir las claves de cifrado de acuerdo con una clave criptográfica especificadamétodo de destrucción [asignación: método de destrucción de claves criptográficas ] que cumpla con lo siguiente:[Asignación: lista de estándares ].

9.2 operación criptográfica (FCS_COP)


Para que una operación criptográfica para que funcione correctamente, la operación debe llevarse a cabo de conformidadcon un algoritmo y una clave criptográfica de un tamaño especificado. Esta familia se debe incluirsiempre que existan requisitos para las operaciones criptográficas que se deben realizar.

Operaciones criptográficas típicas incluyen el cifrado y / o descifrado de datos, generación de la firma digital y / ola verificación, la generación de la suma de comprobación criptográfica de integridad y / o la verificación de la suma de comprobación, control seguro(Resumen del mensaje), el cifrado de claves criptográficas y / o descifrado, y acuerdo de claves criptográficas.


FCS_COP.1 operación criptográfica, R equires una operación criptográfica para ser realizado de acuerdo conun algoritmo y una clave criptográfica de tamaños especificados. El algoritmo y se especificatamaños de clave se pueden basar en un estándar asignado.

9.2.3 Gestión de FCS_COP.1


9.2.4 Auditoría de FCS_COP.1


a) Mínimo: El éxito y el fracaso, y el tipo de operación criptográfica.

b) básica: Cualquier modo de aplicación criptográfica (s) de la operación, los atributos y los atributos de los objetos sujetos.

Página 47

ISO / IEC 15408-2:2008 (E)

9.2.5 operación criptográfica FCS_COP.1






9.2.5.1 FCS_COP.1.1

La TSF debe realizar [asignación: lista de las operaciones criptográficas ] de acuerdo con un determinado

12/6/2014 ISO / IEC 15408-2



algoritmo criptográfico [asignación: algoritmo de cifrado ] y tamaños de clave[Asignación: tamaños de clave ] que cumplan con lo siguiente: [asignación: lista de estándares ].

10 Clase FDP: protección de los datos del usuario

Esta clase contiene familias que especifican los requisitos relacionados con la protección de los datos del usuario. FDP: protección de los datos del usuariose divide en cuatro grupos de familias (listados abajo) que los datos de usuario de direcciones dentro de un TOE, durante la importación, exportación,y almacenamiento, así como los atributos de seguridad directamente relacionada con los datos de usuario.

Las familias de esta clase se organizan en cuatro grupos:

a) políticas de función de seguridad de protección de datos de los usuarios:

• Política de control de acceso (FDP_ACC); y

• Política de control de flujo de la información (FDP_IFC).

Los componentes de estas familias permiten que el autor PP / ST para nombrar la función de seguridad de protección de datos de usuariopolíticas y definen el alcance de la fiscalización de la política, necesaria para hacer frente a los objetivos de seguridad. Lanombres de estas políticas están destinados a ser utilizados en el resto de los componentes funcionales quesometerse a una operación que requiere de una asignación o selección de un "SFP de control de acceso" o una "informaciónSFP de control de flujo ". Las reglas que definen la funcionalidad del flujo de control denominado el acceso y la informaciónSFP de control se definirán en las funciones de control de acceso (FDP_ACF) y el control del flujo de informaciónfunciones (FDP_IFF) f as familias (respectivamente).

b) las formas de protección de datos de usuario:

• Funciones de control de acceso (FDP_ACF);

• Funciones de control de flujo de la información (FDP_IFF);

• Transferencia TOE Interna (FDP_ITT);

• Protección de la información residual (FDP_RIP);

• Rollback (FDP_ROL); y

• Integridad de los datos almacenados (FDP_SDI).

c) el almacenamiento fuera de línea, la importación y exportación:

• Autenticación de datos (FDP_DAU);

Página 48

ISO / IEC 15408-2:2008 (E)

• Exportar desde el TOE (FDP_ETC);

• Importación desde fuera del TOE (FDP_ITC).

Los componentes de estas familias frente a la transferencia confiable dentro o fuera del TOE.

d) La comunicación entre TSF:

• Protección Inter-TSF transferencia confidencialidad de los datos de usuario (FDP_UCT); y

• Protección de la integridad de transferencia de datos de usuario Inter-TSF (FDP_UIT).

Los componentes de estas familias frente a la comunicación entre la TSF del TOE y otro de confianzaProductos de TI.

12/6/2014 ISO / IEC 15408-2



Página 49

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Figura 10 - FDP: Usuario clase de protección de datos de descomposición

Política de control de acceso de 10.1 (FDP_ACC)


Esta familia identifica los SFP de control de acceso (por nombre) y define el alcance de la fiscalización de las políticas queformar la parte de control de acceso identificado de los SFR relacionados con la SFP. Este ámbito de aplicación de control esque se caracteriza por tres conjuntos: los sujetos bajo control de la política, los objetos bajo el control de la política,y las operaciones entre sujetos y objetos controlados que están cubiertos por la póliza. Lacriterios permite que existan múltiples políticas, cada una con un nombre único. Esto se logra mediante la iteracióncomponentes de esta familia una vez para cada política de control de acceso con nombre. Las reglas que definen la funcionalidadde un SFP de control de acceso se define por otras familias a dichas funciones de control de acceso s (FDP_ACF) yExportar desde el TOE (FDP_ETC). T él los nombres de los SFP de control de acceso identificados en este trabajo de control de acceso

Página 50

ISO / IEC 15408-2:2008 (E)

política (FDP_ACC) un re destinado a ser utilizado en todo el resto de los componentes funcionales que tienen unoperación que exige una asignación o selección de un "SFP de control de acceso."


Control de acceso FDP_ACC.1 Subset, re requiere que cada SFP de control de acceso que se identifiquen estar en su lugar para un subconjuntode las posibles operaciones en un subconjunto de los objetos en el TOE.

Control de acceso completa FDP_ACC.2, re requiere que cada cubierta SFP de control de acceso que se identifiquen todas las operacionesen sujetos y objetos cubiertos por dicho SFP. Se requiere, además, que todos los objetos y las operaciones protegidas porla TSF están cubiertos por al menos una identificado SFP de control de acceso.

Gestión 10.1.3 de FDP_ACC.1, FDP_ACC.2


10.1.4 Auditoría de FDP_ACC.1, FDP_ACC.2


Control de acceso 10.1.5 FDP_ACC.1 Subset


Dependencias: Control de acceso basado atributo FDP_ACF.1 Seguridad

10.1.5.1 FDP_ACC.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso ] en [asignación: lista de sujetos, objetos,y las operaciones entre sujetos y objetos cubiertos por la SFP ].

Control de acceso completa 10.1.6 FDP_ACC.2

Jerárquica para: Control de acceso FDP_ACC.1 Subset

Dependencias: Control de acceso basado atributo FDP_ACF.1 Seguridad

10.1.6.1 FDP_ACC.2.1

La TSF debe aplicar la [asignación: SFP de control de acceso ] en [asignación: lista de sujetos y objetos ] ytodas las operaciones entre sujetos y objetos cubiertos por la SFP.

10.1.6.2 FDP_ACC.2.2

La TSF debe garantizar que todas las operaciones entre cualquier sujeto controlado por la TSF y cualquier objetocontrolado por el TSF están cubiertos por un SFP de control de acceso.

Funciones de control de acceso 10.2 (FDP_ACF)


12/6/2014 ISO / IEC 15408-2



Esta familia se describen las reglas para las funciones específicas que pueden implementar una política de control de acceso con nombre enPolítica de control de acceso (FDP_ACC). política de control de acceso (FDP_ACC) especifica el ámbito de control de lapolítica.


Esta familia se ocupa del uso de atributos de seguridad y características de las políticas. El componente dentro de esta familiaestá destinado a ser utilizado para describir las normas para la función que implementa la SFP como se identifica en el acceso

Página 51

ISO / IEC 15408-2:2008 (E)

política de control (FDP_ACC). El autor PP / ST también puede repetir este componente para abordar múltiples políticas enTOE.

Control de acceso basado atributo FDP_ACF.1 Seguridad S de control de acceso basado en atributo eguridad permite la TSF paraforzar un acceso como fundamento los atributos de seguridad y grupos de atributos con nombre. Por otra parte, la TSF puedetener la capacidad de autorizar o negar explícitamente el acceso a un objeto como fundamento los atributos de seguridad.

Gestión 10.2.3 de FDP_ACF.1


a) La gestión de los atributos que se utilizan para hacer que el acceso o la negación explícita decisiones basadas.

10.2.4 Auditoría de FDP_ACF.1


a) Mínimo: Peticiones exitosas para llevar a cabo una operación en un objeto cubierto por la SFP.

b) básica: Todas las solicitudes para llevar a cabo una operación en un objeto cubierto por la SFP.

c) Detallado: Los atributos de seguridad específicos que se utilizan en la fabricación de una comprobación de acceso.

Control de acceso basado atributo 10.2.5 FDP_ACF.1 Seguridad


Dependencias: Control de acceso FDP_ACC.1 Subset

FMT_MSA.3 estático atributo de inicialización

10.2.5.1 FDP_ACF.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso ] para objetos en función de lo siguiente:[Asignación: lista de sujetos y objetos controlados bajo la SFP indicado, y para cada uno, la SFP-atributos de seguridad pertinentes, o llamado grupos de atributos de seguridad SFP-pertinentes ].

10.2.5.2 FDP_ACF.1.2

La TSF debe aplicar las siguientes reglas para determinar si una operación entre sujetos yse permite objetos controlados: [asignación: reglas que rigen el acceso entre sujetos yobjetos controlados, con operaciones controladas sobre objetos controlados ].

10.2.5.3 FDP_ACF.1.3

La TSF debe autorizar explícitamente el acceso de sujetos a objetos en función de los siguientes adicionalreglas: [asignación: reglas, basado en los atributos de seguridad, que autoricen explícitamente el acceso de los sujetos aobjetos ].

10.2.5.4 FDP_ACF.1.4

La TSF debe negar explícitamente el acceso de sujetos a objetos en función de las siguientes reglas adicionales:[Asignación: normas, sobre la base de atributos de seguridad, que niegan explícitamente el acceso de sujetos a objetos ].

12/6/2014 ISO / IEC 15408-2



Página 52

ISO / IEC 15408-2:2008 (E)


10.3 autenticación de datos (FDP_DAU)


Autenticación de datos permite a la entidad a aceptar responsabilidad por la autenticidad de la información (por ejemplo, porla firma digital de ella). Esta familia proporciona un método para proporcionar una garantía de la validez de una unidad específica dede datos que se puede utilizar posteriormente para verificar que el contenido de información no ha sido falsificada o fraudulentamentemodificado. En contraste con la FAU: auditoría de seguridad, esta familia está destinado a ser aplicado a los datos "estáticos" en lugar dedatos que se están transfiriendo.


Datos de autenticación FDP_DAU.1 Basic, r equiere que el TSF es capaz de generar una garantía deautenticidad de la información contenida en los objetos (por ejemplo, documentos).

FDP_DAU.2 datos de autenticación con la identidad de un Garante dditionally requiere que el TSF es capaz deestablecer la identidad del sujeto que proporcionó la garantía de autenticidad.

Gestión 10.3.3 de FDP_DAU.1, FDP_DAU.2


a) La asignación o modificación de los objetos para los que se puede aplicar la autenticación de datos podrían serconfigurable.

10.3.4 Auditoría de FDP_DAU.1


a) Mínimo: generación con éxito de las pruebas de validez.

b) básica: generación sin éxito de las pruebas de validez.

c) Datos individuales: La identidad del sujeto que solicita la prueba.

10.3.5 Auditoría de FDP_DAU.2


a) Mínimo: generación con éxito de las pruebas de validez.

b) básica: generación sin éxito de las pruebas de validez.

c) Datos individuales: La identidad del sujeto que solicita la prueba.

d) Datos individuales: La identidad del sujeto que ha generado la evidencia.

10.3.6 FDP_DAU.1 autenticación básica de datos



10.3.6.1 FDP_DAU.1.1

La TSF debe proporcionar una capacidad para generar evidencia de que puede ser utilizado como una garantía de la validezde [asignación: lista de objetos o tipos de información ].

Página 53

ISO / IEC 15408-2:2008 (E)

10.3.6.2 FDP_DAU.1.2

12/6/2014 ISO / IEC 15408-2



La TSF debe proporcionar [asignación: lista de temas ] con la posibilidad de verificar la evidencia de la validez dela información indicada.

10.3.7 FDP_DAU.2 datos de autenticación con la identidad del Garante

Jerárquica para: Datos de autenticación FDP_DAU.1 básico


10.3.7.1 FDP_DAU.2.1

La TSF debe proporcionar una capacidad para generar evidencia de que puede ser utilizado como una garantía de la validez de los[Asignación: lista de objetos o tipos de información ].

10.3.7.2 FDP_DAU.2.2

La TSF debe proporcionar [asignación: lista de temas ] con la posibilidad de verificar la evidencia de la validez de lase indica la información y la identidad del usuario que ha generado la evidencia.

10.4 Exportar en el TOE (FDP_ETC)


Esta familia define funciones para exportar mediada TSF de datos de usuario en el TOE de forma que su seguridadatributos y protección, ya sea se pueden conservar de manera explícita o pueden ser ignorados una vez que ha sido exportado. Espreocupados por las limitaciones a la exportación y con la asociación de atributos de seguridad con los datos del usuario exportados.


FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad , requiere que el TSF cumplir la adecuadaSFP al exportar datos de usuario fuera de la TSF. Los datos de usuario que se exporta por esta función se exportasin sus atributos de seguridad asociados.

FDP_ETC.2 Exportación de los datos de usuario con atributos de seguridad , requiere que el TSF hacer cumplir los programas de alimentación complementariaadecuadasel uso de una función que asocia con precisión y sin ambigüedades los atributos de seguridad con los datos de usuario que esexportado.

Gestión 10.4.3 de FDP_ETC.1


Gestión 10.4.4 de FDP_ETC.2


a) Las normas de control de exportación adicionales podrían ser configurables por un usuario en un papel definido.

10.4.5 Auditoría de FDP_ETC.1, FDP_ETC.2


a) Mínimo: exportación exitosa de la información.

b) Básico: Todos los intentos de exportar la información.

Página 54

ISO / IEC 15408-2:2008 (E)

10.4.6 FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad


Dependencias: [ FDP_ACC.1 Subset control de acceso, o

El control del flujo de información FDP_IFC.1 Subset]

10.4.6.1 FDP_ETC.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]al exportar datos de usuario, controlados por el SFP (s), en las afueras de la TOE.

12/6/2014 ISO / IEC 15408-2



10.4.6.2 FDP_ETC.1.2

La TSF debe exportar los datos de usuario sin atributos de seguridad asociados de los datos de usuario.

10.4.7 FDP_ETC.2 Exportación de los datos de usuario con atributos de seguridad




10.4.7.1 FDP_ETC.2.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]al exportar datos de usuario, controlados por el SFP (s), en las afueras de la TOE.

10.4.7.2 FDP_ETC.2.2

La TSF debe exportar los datos de usuario con atributos de seguridad asociados de los datos de usuario.

10.4.7.3 FDP_ETC.2.3

La TSF debe garantizar que los atributos de seguridad, cuando se exporten fuera de la TOE, están inequívocamenteasociado con los datos de usuario exportados.

10.4.7.4 FDP_ETC.2.4

La TSF debe aplicar las siguientes reglas cuando los datos de usuario se exporta desde el TOE: [asignación:normas de control de exportación adicionales ].

Política de control de flujo 10.5 Información (FDP_IFC)


Esta familia identifica los SFP de control del flujo de información (por nombre) y define el ámbito de aplicación de control para cadadenominada Información SFP de control de flujo. Este ámbito de control se caracteriza por tres conjuntos: los temas que secontrol de la política, la información bajo el control de la política y las operaciones que causan controladala información fluya hacia y desde los sujetos controlados cubiertos por la póliza. El criterio permite que múltiples políticas paraexisten, cada uno con un nombre único. Esto se logra mediante la iteración componentes de esta familia de una vez porcada una política de control de flujo de información con nombre. Las reglas que definen la funcionalidad de un flujo de informacióncontrol de la SFP se definirá por otras familias, como las funciones de control del flujo de la información (FDP_IFF) y Exportacióndel TOE (FDP_ETC). Th nombres correos de los SFP de control del flujo de información identificados en este trabajo Flujo de informaciónpolítica de control (FDP_IFC) están destinados a ser utilizada en todo el resto de los componentes funcionales quesometerse a una operación que requiere de una asignación o selección de un "SFP de control del flujo de la información."

Página 55

ISO / IEC 15408-2:2008 (E)

El mecanismo de TSF controla el flujo de información de acuerdo con la SFP de control de flujo de información.Operaciones que podrían cambiar los atributos de seguridad de la información no están generalmente permitidos ya que estoestar en violación de un SFP de control del flujo de información. Sin embargo, estas operaciones pueden ser permitidos como excepcionesa la SFP de control del flujo de información, si se especifica de forma explícita.


Información de control de flujo FDP_IFC.1 Subset, requiere que cada uno identificado SFP de control del flujo de información estarán encolocar para un subconjunto de las posibles operaciones en un subconjunto de los flujos de información en el TOE.

FDP_IFC.2 Información completa de control de flujo, r equiere que cada dato que se Cover Flow SFP de controltodas las operaciones sobre los temas y la información que se refiere dicha SFP. Se requiere, además, que todos los flujos de informacióny operaciones controladas por el TSF están cubiertas por al menos uno identificado SFP de control de flujo de información.

Gestión 10.5.3 de FDP_IFC.1, FDP_IFC.2


10.5.4 Auditoría de FDP_IFC.1, FDP_IFC.2


El control del flujo de información 10.5.5 FDP_IFC.1 Subset


12/6/2014 ISO / IEC 15408-2



Dependencias: FDP_IFF.1 atributos de seguridad simples

10.5.5.1 FDP_IFC.1.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] de [asignación: lista de temas,información, y las operaciones que la información causa controlado fluya hacia y desde los sujetos controladoscubierto por la SFP ].

10.5.6 FDP_IFC.2 Información completa de control de flujo

Jerárquica para: El control del flujo de información FDP_IFC.1 Subset

Dependencias: FDP_IFF.1 atributos de seguridad simples

10.5.6.1 FDP_IFC.2.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] de [asignación: lista de temas yla información ] y todas las operaciones que hacen que la información fluya hacia y desde temas cubiertos por la SFP.

10.5.6.2 FDP_IFC.2.2

La TSF debe garantizar que todas las operaciones que causen cualquier información en el TOE fluyan hacia y desde cualquiertema en el TOE están cubiertos por un SFP de control del flujo de información.

Funciones de control de flujo de 10,6 de la Información (FDP_IFF)


Esta familia se describen las reglas para las funciones específicas que pueden implementar los programas de alimentación complementaria de control del flujo de informaciónNombrado en I nformación política de control de flujo (FDP_IFC), w hich también especifica el alcance del control de la política. Lose compone de dos tipos de requisitos: uno frente a los problemas de la función de flujo de información común y unaabordar segunda información flujos ilícitos (por ejemplo, canales encubiertos). Esta división surge porque los temasrelativas a los flujos de información ilícitos son, en algún sentido, ortogonal al resto de un control del flujo de información

Página 56

ISO / IEC 15408-2:2008 (E)

SFP. Por su naturaleza que sirven para eludir la SFP de control del flujo de información que resulta en una violación de la política. Comotales, requieren funciones especiales para limitar o prevenir su ocurrencia.


Atributos de seguridad simples FDP_IFF.1, requiere los atributos de seguridad de la información, y sobre temas que causanque la información fluya y sujetos que actúan como receptores de esa información. Se especifican las reglas quedebe ser protegido por la función, y describe cómo los atributos de seguridad se derivan de la función.

FDP_IFF.2 jerárquicas Attribut seguridad es amplían en los requisitos de seguridad FDP_IFF.1 simpleatributos , al exigir que todos los SFP de control del flujo de información en el conjunto de los SFR utilizan la seguridad jerárquicaatributos que forman un entramado (como se define en las matemáticas). FDP_IFF.2.6 se deriva de la matemáticapropiedades de una celosía. Una red consiste en un conjunto de elementos con una relación de pedidos con la propiedaddefinido en la primera viñeta, una cota superior mínima que es el elemento único en el conjunto que es mayor o igual (enla relación de pedido) que cualquier otro elemento de la red, y un extremo inferior, que es elelemento único en el conjunto que es menor o igual que cualquier otro elemento de la red.

FDP_IFF.3 limitada información ilícita flujo s, requiere de la SFP para cubrir la información ilícita flujos, pero nonecesariamente eliminarlos.

FDP_IFF.4 eliminación parcial de ilícito flujo de información s, requiere la SFP para cubrir la eliminación de algunos (perono necesariamente todos) los flujos de información ilícita.

FDP_IFF.5 fluye Ninguna información ilícita, requiere SFP para cubrir la eliminación de todos los flujos de información ilícita.

Información de monitoreo de flujo FDP_IFF.6 ilícita, requiere de la SFP para supervisar la información ilícita fluye por especificaday capacidades máximas.

Gestión 10.6.3 de FDP_IFF.1, FDP_IFF.2


a) La gestión de los atributos que se utilizan para tomar decisiones basadas en el acceso explícito.

Gestión 10.6.4 de FDP_IFF.3, FDP_IFF.4, FDP_IFF.5


12/6/2014 ISO / IEC 15408-2



Gestión 10.6.5 de FDP_IFF.6


a) La activación o desactivación de la función de supervisión.

b) Modificación de la capacidad máxima a la que se produce la monitorización.

10.6.6 Auditoría de FDP_IFF.1, FDP_IFF.2, FDP_IFF.5


a) Mínimos: Decisiones para permitir información solicitada flujos.

b) básica: Todas las decisiones sobre las solicitudes de flujo de información.

c) Detallado: Los atributos de seguridad específicos que se utilizan en la fabricación de un flujo de información de decisiones de ejecución.

d) Datos individuales: Algunos subconjuntos específicos de la información que ha fluido en base a los objetivos de política (por ejemplo, la auditoríade material degradado).

Página 57

ISO / IEC 15408-2:2008 (E)

10.6.7 Auditoría de FDP_IFF.3, FDP_IFF.4, FDP_IFF.6


a) Mínimos: Decisiones para permitir información solicitada flujos.

b) básica: Todas las decisiones sobre las solicitudes de flujo de información.

c) Básico: El uso de los canales de flujo de información ilícitos identificados.

d) Detallado: Los atributos de seguridad específicos que se utilizan en la fabricación de un flujo de información de decisiones de ejecución.

e) Datos individuales: Algunos subconjuntos específicos de la información que ha fluido en base a los objetivos de política (por ejemplo, la auditoríade material degradado).

f) Detallada: El uso de los canales de flujo de información ilícitos identificados con capacidad máxima estimadasuperior a un valor determinado.

10.6.8 FDP_IFF.1 atributos de seguridad simples


Dependencias: El control del flujo de información FDP_IFC.1 Subset


10.6.8.1 FDP_IFF.1.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] sobre la base de los siguientes tipos deatribuye tema y la información de seguridad: [asignación: lista de temas y la información controladabajo la SFP indicado, y para cada uno, los atributos de seguridad ].

10.6.8.2 FDP_IFF.1.2

La TSF debe permitir un flujo de información entre un sujeto y la información controlada controlada a través deuna operación controlada si las reglas siguientes se cumplen: [asignación: para cada operación, la seguridadrelación basada en atributos que deben mantener entre sujeto y seguridad de la información de atributos ].

10.6.8.3 FDP_IFF.1.3

La TSF debe aplicar la [asignación: reglas SFP de control del flujo de información adicionales ].

10.6.8.4 FDP_IFF.1.4

La TSF debe autorizar explícitamente un flujo de información en base a las siguientes reglas: [asignación:normas, sobre la base de atributos de seguridad, que autoricen explícitamente los flujos de información ].

10.6.8.5 FDP_IFF.1.5

12/6/2014 ISO / IEC 15408-2



La TSF debe negar explícitamente un flujo de información en base a las siguientes reglas: [asignación: reglas,basado en los atributos de seguridad, que niegan explícitamente los flujos de información ].

10.6.9 FDP_IFF.2 atributos de seguridad Jerárquico

Jerárquica para: FDP_IFF.1 atributos de seguridad simples



Página 58

ISO / IEC 15408-2:2008 (E)

10.6.9.1 FDP_IFF.2.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] sobre la base de los siguientes tipos de objetoy los atributos de seguridad de la información: [asignación: lista de temas e información controlados por el indicadoSFP, y para cada uno, los atributos de seguridad ].

10.6.9.2 FDP_IFF.2.2

La TSF debe permitir un flujo de información entre un sujeto y la información controlada controlada a través de unoperación controlada si las siguientes reglas, basadas en las relaciones entre los atributos de seguridad de pedidosostener: [asignación: para cada operación, la relación basada en atributos de seguridad que debe tener entre sujetoy los atributos de seguridad de la información ].

10.6.9.3 FDP_IFF.2.3

La TSF debe aplicar la [asignación: reglas SFP de control del flujo de información adicionales ].

10.6.9.4 FDP_IFF.2.4

La TSF debe autorizar explícitamente un flujo de información en base a las siguientes reglas: [asignación: reglas, basadasen los atributos de seguridad, que autoricen explícitamente los flujos de información ].

10.6.9.5 FDP_IFF.2.5

La TSF debe negar explícitamente un flujo de información en base a las siguientes reglas: [asignación: reglas, basado enatributos de seguridad, que niegan explícitamente los flujos de información ].

10.6.9.6 FDP_IFF.2.6

La TSF debe aplicar las siguientes relaciones de ningún tipo de seguridad de control de flujo de dos información válidaatributos:

a) Si existe una función ordenadora que, dadas dos atributos de seguridad válidos, determina si elatributos de seguridad son iguales, si un atributo de seguridad es mayor que la otra, o si la seguridadatributos son incomparables; y

b) Existe un "límite superior menos" en el conjunto de atributos de seguridad, de forma que, teniendo en cuenta cualesquiera dos válidaatributos de seguridad, no es un atributo de seguridad válido que es mayor que o igual a los dos válidalos atributos de seguridad; y

c) Existe un "extremo inferior" en el conjunto de atributos de seguridad, de forma que, teniendo en cuenta cualquiera de los dosatributos de seguridad válidos, existe un atributo de seguridad válida que no sea superior a los dos válidalos atributos de seguridad.

Fluye 10.6.10 FDP_IFF.3 Limited información ilícita



10.6.10.1 FDP_IFF.3.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] para limitar la capacidad de los[Asignación: tipos de información ilícita flujos ] a un [asignación: la capacidad máxima ].

12/6/2014 ISO / IEC 15408-2



Página 59

ISO / IEC 15408-2:2008 (E)


10.6.11 FDP_IFF.4 Eliminación parcial de la información ilícita fluye

Jerárquica para: Fluye FDP_IFF.3 Limited información ilícita


10.6.11.1 FDP_IFF.4.1

La TSF debe aplicar la [asignación: SFP de control del flujo de información ] para limitar la capacidad de [asignación:tipos de información ilícita flujos ] a un [asignación: la capacidad máxima ].

10.6.11.2 FDP_IFF.4.2

La TSF debe evitar [asignación: tipos de información ilícita flujos ].

Fluye 10.6.12 FDP_IFF.5 No hay información ilícita

Jerárquica para: FDP_IFF.4 Eliminación parcial de la información ilícita fluye


10.6.12.1 FDP_IFF.5.1

La TSF debe garantizar que no existan flujos de información ilícitos para eludir [asignación: Nombre dela información de control de flujo SFP ].

10.6.13 FDP_IFF.6 información Ilícito de monitoreo de flujo



10.6.13.1 FDP_IFF.6.1

La TSF debe aplicar las [asignación: SFP de control del flujo de información ] para vigilar [asignación: tiposde información de flujos ilícitos ] cuando supera el [asignación: la capacidad máxima ].

10.7 Importación desde fuera del TOE (FDP_ITC)


Esta familia define los mecanismos para la importación mediada TSF de datos de usuario en el TOE de forma que tengalos atributos de seguridad apropiada y está protegido de manera apropiada. Esto tiene que ver con las limitaciones a la importación,determinación de atributos de seguridad deseados, y la interpretación de los atributos de seguridad asociados con el usuariodatos.


FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad, requiere que la seguridad atribuye correctamenterepresentar los datos de usuario y se suministran por separado del objeto.

FDP_ITC.2 Importación de datos de usuario con atributos de seguridad, r equiere que los atributos de seguridad representan correctamente eldatos de usuario y están exacta y sin ambigüedades asociadas con los datos de usuario importados desde fuera delTOE.

Página 60

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Gestión 10.7.3 de FDP_ITC.1, FDP_ITC.2


a) La modificación de las reglas de control adicionales que se utilizan para la importación.

10.7.4 Auditoría de FDP_ITC.1, FDP_ITC.2


a) Mínimo: Successful importación de datos de los usuarios, incluyendo los atributos de seguridad.

b) Básico: Todos los intentos de importar los datos de usuario, incluidas posibles atributos de seguridad.

c) Detallada: La especificación de los atributos de seguridad de los datos de usuario importados suministrados por un usuario autorizado.

10.7.5 FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad





10.7.5.1 FDP_ITC.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]al importar datos de usuario, controlados por el SFP, desde fuera del TOE.

10.7.5.2 FDP_ITC.1.2

La TSF debe ignorar los atributos de seguridad asociados a los datos de usuario cuando se importan desde fueraTOE.

10.7.5.3 FDP_ITC.1.3

La TSF debe aplicar las siguientes reglas para la importación de datos de usuario controladas en virtud del SFP defuera del TOE: [asignación: reglas de control de importación adicionales ].

10.7.6 FDP_ITC.2 Importación de datos de usuario con atributos de seguridad




[ FTP_ITC.1 Inter-TSF confiaba canal, o

Ruta FTP_TRP.1 Segura]

FPT_TDC.1 Inter-TSF TSF consistencia de los datos básicos

Página 61

ISO / IEC 15408-2:2008 (E)

10.7.6.1 FDP_ITC.2.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]al importar datos de usuario, controlados por el SFP, desde fuera del TOE.

10.7.6.2 FDP_ITC.2.2

La TSF debe utilizar los atributos de seguridad asociados a los datos de usuario importados.

10.7.6.3 FDP_ITC.2.3

12/6/2014 ISO / IEC 15408-2



La TSF debe garantizar que el protocolo utilizado prevé la asociación inequívoca entre elatributos de seguridad y los datos de usuario recibidos.

10.7.6.4 FDP_ITC.2.4

La TSF debe garantizar que la interpretación de los atributos de seguridad de los datos de usuario importados es tanpretendido por la fuente de los datos de usuario.

10.7.6.5 FDP_ITC.2.5

La TSF debe aplicar las siguientes reglas para la importación de datos de usuario controladas en virtud del SFP defuera del TOE: [asignación: reglas de control de importación adicionales ].

10.8 Transferencia TOE Interna (FDP_ITT)


Esta familia proporciona los requisitos que se ocupan de la protección de los datos de usuario cuando se transfiere entrepartes separadas de una TDT a través de un canal interno. Esto puede ser contrastado con el de datos de usuario Inter-TSFprotección de la confidencialidad de transferencia (FDP_UCT) y la protección de la integridad de la transferencia de datos de usuario de Inter-TSF (FDP_UIT)familias, que proporcionan protección para los datos de usuario cuando se transfiere entre las TSF distintas a través de un externocanal y Exportar en el TOE (FDP_ETC) una importación nd desde fuera del TOE (FDP_ITC), que la direcciónTransferencia mediada por TSF de datos hacia o desde fuera del TOE.


FDP_ITT.1 básico de protección internos de transferencia , requiere que los datos de los usuarios pueden proteger las transmisiones entrepartes del TOE.

Separación FDP_ITT.2 Transmisión por atributo , requiere la separación de los datos basado en el valor de la SFP-atributos relevantes en adición a la primera componente.

Monitoreo FDP_ITT.3 Integridad, requiere que los datos de usuario del monitor TSF transmiten entre partes del TOEpor fallos de integridad identificados.

FDP_ITT.4 supervisión de integridad basada en atributos se expande en el tercer componente al permitir que la forma devigilancia de la integridad a diferir en atributo SFP-relevante.

Gestión 10.8.3 de FDP_ITT.1, FDP_ITT.2


a) Si el TSF proporciona múltiples métodos para proteger los datos del usuario durante la transmisión entre físicamentepartes de la TOE separados, la TSF podría proporcionar un papel pre-definido con la capacidad de seleccionar el métodoque se utilizará.

Página 62

ISO / IEC 15408-2:2008 (E)

Gestión 10.8.4 de FDP_ITT.3, FDP_ITT.4


a) La especificación de las acciones que se deben tomar cuando se detecta un error de integridad podría ser configurable.

10.8.5 Auditoría de FDP_ITT.1, FDP_ITT.2


a) Mínimos: transferencias exitosas de los datos del usuario, incluyendo la identificación del método de protección utilizado.

b) Básico: Todos los intentos de transferir los datos del usuario, incluyendo el método de protección utilizado y cualquier error queocurrido.

10.8.6 Auditoría de FDP_ITT.3, FDP_ITT.4


a) Mínimos: transferencias exitosas de los datos del usuario, incluyendo la identificación del método de protección de integridad utilizado.

12/6/2014 ISO / IEC 15408-2



b) Básico: Todos los intentos de transferir los datos del usuario, incluyendo el método de protección de la integridad utilizados y los erroresque ocurrió.

c) básica: intentos no autorizados para cambiar el método de protección de la integridad.

d) Datos individuales: La acción tomada cuando se detecta un error de integridad.

10.8.7 FDP_ITT.1 básico de protección interno de transferencia




10.8.7.1 FDP_ITT.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]para evitar que la [selección: la divulgación, modificación, pérdida de uso ] de los datos de usuario cuando se transmiteentre partes físicamente separados del TOE.

10.8.8 FDP_ITT.2 Transmisión separación por atributo

Jerárquica para: FDP_ITT.1 básico de protección interno de transferencia



10.8.8.1 FDP_ITT.2.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ] paraevitar que la [selección: la divulgación, modificación, pérdida de uso ] de los datos de usuario cuando se transmite entrepartes físicamente separados del dedo.

Página 63

ISO / IEC 15408-2:2008 (E)

10.8.8.2 FDP_ITT.2.2

La TSF debe separar los datos controlados por la SFP (s) cuando se transmiten entre físicamente separados-partes de la TOE, basado en los valores de los siguientes: [asignación: atributos de seguridad que requierenseparación ].

Monitoreo 10.8.9 FDP_ITT.3 Integridad




FDP_ITT.1 básico de protección interno de transferencia

10.8.9.1 FDP_ITT.3.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]para supervisar los datos de usuario transmitidos entre partes físicamente separados del TOE para el siguienteerrores: [asignación: errores de integridad ].

10.8.9.2 FDP_ITT.3.2

Tras la detección de un error de integridad de los datos, la TSF debe [asignación: especificar la acción a tomaral error de integridad ].

10.8.10 FDP_ITT.4 supervisión de integridad basada en atributos

Jerárquica para: Monitoreo FDP_ITT.3 Integridad



12/6/2014 ISO / IEC 15408-2



FDP_ITT.2 Transmisión separación por atributo

10.8.10.1 FDP_ITT.4.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ] parasupervisar los datos de usuario transmitidos entre partes físicamente separados del TOE para los siguientes errores:[Asignación: errores de integridad ], sobre la base de los siguientes atributos: [asignación: los atributos de seguridad querequerir canales de transmisión separados ].

10.8.10.2 FDP_ITT.4.2

Tras la detección de un error de integridad de los datos, la TSF debe [asignación: especificar la acción a tomar enerror de integridad ].

10.9 Residual protección de la información (FDP_RIP)


Esta familia se refiere a la necesidad de asegurar que los datos contenidos en un recurso no está disponible cuando elrecurso se desasignada de un objeto y reasignado a un objeto diferente. Esta familia necesita protecciónde los datos contenidos en un recurso que ha sido eliminado lógica o liberado, pero todavía puede estar presente dentro deel recurso controlado-TSF que a su vez puede ser reasignada a otro objeto.

Página 64

ISO / IEC 15408-2:2008 (E)


FDP_RIP.1 Subset protección de la información residual, requiere que el TSF asegurar que cualquier información residualcontenido de cualquier recurso no está disponible a un subconjunto definido de los objetos controlados por el TSF sobre lala asignación o cancelación de asignación de recursos.

FDP_RIP.2 completa protección de la información residual, requiere que el TSF asegurar que cualquier información residualcontenido de cualquier recurso no está disponible para todos los objetos sobre la asignación o cancelación de asignación del recurso.

Gestión 10.9.3 de FDP_RIP.1, FDP_RIP.2


a) La elección de cuándo realizar la protección de la información residual (es decir, sobre la asignación o cancelación de asignación) podríasean configurables dentro del TOE.

10.9.4 Auditoría de FDP_RIP.1, FDP_RIP.2


10.9.5 FDP_RIP.1 Subset protección de la información residual



10.9.5.1 FDP_RIP.1.1

La TSF debe garantizar que todo el contenido de la información previa de un recurso se hace disponible alla [selección: la asignación de los recursos para, cancelación de asignación del recurso de ] los siguientes objetos:[Asignación: lista de objetos ].

10.9.6 Protección FDP_RIP.2 información completa residual

Jerárquica para: FDP_RIP.1 Subset protección de la información residual


10.9.6.1 FDP_RIP.2.1

La TSF debe garantizar que todo el contenido de la información previa de un recurso se hace disponible en el[Selección: la asignación de los recursos para, cancelación de asignación del recurso de ] todos los objetos.

10.10 Rollback (FDP_ROL)


12/6/2014 ISO / IEC 15408-2



La operación de reversión implica deshacer la última operación o una serie de operaciones, delimitado por un límite,tales como un período de tiempo, y el retorno a un estado conocido anterior. Rollback ofrece la posibilidad de deshacer laefectos de una operación o serie de operaciones para preservar la integridad de los datos de usuario.


FDP_ROL.1 básico rollback un ddresses la necesidad de revertir o deshacer un número limitado de operaciones dentro de lalímites definidos.

FDP_ROL.2 avanzada rollback ad vestidos de la necesidad de revertir o deshacer todas las operaciones dentro de la definidalímites.

Página 65

ISO / IEC 15408-2:2008 (E)

10.10.3 Gestión de FDP_ROL.1, FDP_ROL.2


a) El plazo límite para la cual se puede realizar la reversión podría ser un elemento configurable en el TOE.

b) La autorización para llevar a cabo una operación de reversión podría limitarse a un papel bien definido.

10.10.4 Auditoría de FDP_ROL.1, FDP_ROL.2


a) Mínimo: Todas las operaciones de rollback exitosos.

b) Básico: Todos los intentos para llevar a cabo operaciones de rollback.

c) detallada: Todos los intentos para llevar a cabo operaciones de rollback, incluyendo la identificación de los tipos de operacionesdeshecho.

10.10.5 FDP_ROL.1 rollback básico




10.10.5.1 FDP_ROL.1.1

La TSF debe aplicar [asignación: SFP (s) de control de acceso y / o información de la SFP (s) de control de flujo ] parapermitir la retrotracción de la [asignación: lista de operaciones ] en el [asignación: información y / o de la listade objetos ].

10.10.5.2 FDP_ROL.1.2

La TSF debe permitir operaciones que revertirse dentro de [asignación: límite de frontera a la querollback puede llevar a cabo ].

10.10.6 FDP_ROL.2 rollback Avanzada

Jerárquica para: Rollback FDP_ROL.1 básico



10.10.6.1 FDP_ROL.2.1

La TSF debe aplicar [asignación: SFP (s) de control de acceso y / o información de la SFP (s) de control de flujo ] para permitirel desmantelamiento de todas las operaciones en el [asignación: lista de objetos ].

10.10.6.2 FDP_ROL.2.2

La TSF debe permitir operaciones que revertirse dentro de [asignación: límite límite al que puede deshacerrealizar ].

12/6/2014 ISO / IEC 15408-2



Página 66

ISO / IEC 15408-2:2008 (E)


10.11 integridad de los datos almacenados (FDP_SDI)


Esta familia proporciona los requisitos que se ocupan de la protección de los datos del usuario mientras se almacena dentro de contenedorescontrolado por el TSF. Errores de integridad pueden afectar a los datos de usuario almacenados en la memoria o en un dispositivo de almacenamiento. Estefamilia difiere de la transferencia TOE Interna (FDP_ITT) que protege los datos de usuario de errores de integridad, mientras queser trasladado dentro del TOE.


FDP_SDI.1 almacenado monitoreo de integridad de datos, requiere que el TSF monitorear los datos del usuario almacenados en contenedorescontrolado por el TSF de errores de integridad identificados.

Monitoreo FDP_SDI.2 integridad de los datos almacenados y de la acción de un dds la capacidad adicional de la primera componente porteniendo en cuenta las acciones a tomar como resultado de una detección de errores.

10.11.3 Gestión de FDP_SDI.1


10.11.4 Gestión de FDP_SDI.2


a) Las medidas que deben adoptarse tras la detección de un error de integridad pueden ser configurable.

10.11.5 Auditoría de FDP_SDI.1


a) Mínimos: intentos exitosos para comprobar la integridad de los datos del usuario, incluida una indicación de los resultados deel cheque.

b) Básicos: Todos los intentos para comprobar la integridad de los datos del usuario, incluyendo una indicación de los resultados de la verificación, sirealizado.

c) Datos individuales: El tipo de error de integridad que se produjo.

10.11.6 Auditoría de FDP_SDI.2


a) Mínimos: intentos exitosos para comprobar la integridad de los datos del usuario, incluida una indicación de los resultados deel cheque.

b) Básicos: Todos los intentos para comprobar la integridad de los datos del usuario, incluyendo una indicación de los resultados de la verificación, sirealizado.

c) Datos individuales: El tipo de error de integridad que se produjo.

d) Datos individuales: La acción tomada cuando se detecta un error de integridad.

10.11.7 FDP_SDI.1 almacenado monitoreo de integridad de datos



Página 67

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



10.11.7.1 FDP_SDI.1.1

La TSF debe supervisar los datos de usuario almacenados en contenedores controlados por la TSF para [asignación: la integridaderrores ] en todos los objetos, con base en los siguientes atributos: [asignación: atributos de datos de usuario ].

10.11.8 monitoreo y acción FDP_SDI.2 integridad de los datos almacenados

Jerárquica para: FDP_SDI.1 almacenado monitoreo de integridad de datos


10.11.8.1 FDP_SDI.2.1

La TSF debe supervisar los datos de usuario almacenados en contenedores controlados por la TSF para [asignación: errores de integridad ]en todos los objetos, con base en los siguientes atributos: [asignación: atributos de datos de usuario ].

10.11.8.2 FDP_SDI.2.2

Tras la detección de un error de integridad de los datos, la TSF debe [asignación: medidas que deben adoptarse ].

10.12 Inter-TSF protección transferencia confidencialidad de los datos de usuario (FDP_UCT)


Esta familia define los requisitos para garantizar la confidencialidad de los datos de usuario cuando se transfiere medianteun canal externo entre el TOE y otro producto de TI de confianza.


En el intercambio de datos FDP_UCT.1 básico confidencialidad, t l objetivo es proporcionar protección contra la divulgación de usuariolos datos mientras están en tránsito.

10.12.3 Gestión de FDP_UCT.1


10.12.4 Auditoría de FDP_UCT.1


a) Mínimo: La identidad de cualquier usuario o un objeto utilizando los mecanismos de intercambio de datos.

b) básica: La identidad de cualquier usuario no autorizado o sujeto de intentar utilizar los mecanismos de intercambio de datos.

c) Básico: Una referencia a los nombres u otra información de indexación de utilidad en la identificación de los datos del usuario que fuetransmitida o recibida. Esto podría incluir atributos de seguridad asociados con la información.

10.12.5 FDP_UCT.1 básico confidencialidad intercambio de datos


Dependencias: [ FTP_ITC.1 Inter-TSF confiaba canal, o


[ FDP_ACC.1 Subset control de acceso, o


Página 68

ISO / IEC 15408-2:2008 (E)

10.12.5.1 FDP_UCT.1.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]para [selección: transmisión, recepción ] los datos del usuario de una manera protegida contra la divulgación no autorizada.

10.13 Inter-TSF protección transferencia integridad de los datos de usuario (FDP_UIT)


12/6/2014 ISO / IEC 15408-2



Esta familia define los requisitos para proporcionar la integridad de los datos del usuario en tránsito entre el OE yotro producto de TI confiable y recuperación de errores detectables. Como mínimo, esta familia supervisa laintegridad de los datos del usuario para las modificaciones. Además, esta familia es compatible con diferentes formas de corregir detectadoerrores de integridad.


FDP_UIT.1 Datos integridad de intercambio de anuncios vestidos de detección de modificaciones, supresiones, inserciones, y reproducciónerrores de los datos de usuario transmitidos.

Anuncios de recuperación de intercambio de datos FDP_UIT.2 Fuente vestidos de recuperación de los datos de los usuarios originales de la TSF receptoracon la ayuda del producto de las TI fuente de confianza.

Anuncios de recuperación de intercambio de datos FDP_UIT.3 Destino vestidos de recuperación de los datos de los usuarios originales de la recepciónTSF por sí sola sin ninguna ayuda de la fuente de confianza de TI producto.

10.13.3 Gestión de FDP_UIT.1, FDP_UIT.2, FDP_UIT.3


10.13.4 Auditoría de FDP_UIT.1



b) básica: La identidad de cualquier usuario o un objeto de tratar de usar los mecanismos de intercambio de datos de usuario, sino queno está autorizado para hacerlo.

c) Básico: Una referencia a los nombres u otra información de indexación de utilidad en la identificación de los datos del usuario que fuetransmitida o recibida. Esto podría incluir atributos de seguridad asociados con los datos de usuario.

d) básica: Cualquier intento identificados para bloquear la transmisión de datos de usuario.

e) Detallado: Los tipos y / o los efectos de las modificaciones detectadas de datos de usuario transmitidos.

10.13.5 Auditoría de FDP_UIT.2, FDP_UIT.3



b) Minimal: La recuperación exitosa de los errores, incluyendo que tipo de error que se ha detectado.

c) básica: La identidad de cualquier usuario o un objeto de tratar de usar los mecanismos de intercambio de datos de usuario, sino queno está autorizado para hacerlo.

Página 69

ISO / IEC 15408-2:2008 (E)

d) Básico: Una referencia a los nombres u otra información de indexación de utilidad en la identificación de los datos del usuario que fuetransmitida o recibida. Esto podría incluir atributos de seguridad asociados con los datos de usuario.

e) básica: Cualquier intento identificados para bloquear la transmisión de datos de usuario.

f) Detallada: Los tipos y / o los efectos de las modificaciones detectadas de datos de usuario transmitidos.

10.13.6 integridad FDP_UIT.1 El intercambio de datos




[ FTP_ITC.1 Inter-TSF confiaba canal, o


10.13.6.1 FDP_UIT.1.1

12/6/2014 ISO / IEC 15408-2



La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]para [selección: transmisión, recepción ] los datos del usuario de una manera protegida de [selección: la modificación,eliminación, inserción de reproducción ] errores.

10.13.6.2 FDP_UIT.1.2

La TSF debe ser capaz de determinar la recepción de datos de los usuarios, ya sea [selección: la modificación, supresión,inserción, repetición ] se ha producido.

Recuperación de intercambio de datos 10.13.7 FDP_UIT.2 Fuente




[ integridad intercambio FDP_UIT.1 datos, o

Canal FTP_ITC.1 Inter-TSF de confianza]

10.13.7.1 FDP_UIT.2.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o SFP (s) de control de flujo de información ]ser capaz de recuperarse de [asignación: lista de errores recuperables ] con la ayuda de la fuente de confianzaProductos de TI.

10.13.8 recuperación intercambio de datos FDP_UIT.3 Destino

Jerárquica para: Recuperación de intercambio de datos FDP_UIT.2 Fuente



[ integridad intercambio FDP_UIT.1 datos, o

Canal FTP_ITC.1 Inter-TSF de confianza]

Página 70

ISO / IEC 15408-2:2008 (E)

10.13.8.1 FDP_UIT.3.1

La TSF debe aplicar la [asignación: SFP de control de acceso (s) y / o información de la SFP (s) de control de flujo ] para sercapaz de recuperarse de [asignación: lista de errores recuperables ] sin ninguna ayuda de la fuente de confianza de TIproducto.

11 Clase FIA: Identificación y autenticación

Las familias de esta clase frente a los requisitos para las funciones de establecer y verificar la identidad del usuario reclamado.

Se requiere identificación y autenticación para garantizar que los usuarios se relacionan con la seguridad adecuadaatributos (por ejemplo, los niveles de identidad, grupos, funciones, seguridad o integridad).

La identificación inequívoca de los usuarios autorizados y la asociación correcta de atributos de seguridad conlos usuarios y los temas es fundamental para la aplicación de las políticas de seguridad previstos. Las familias de esta claselidiar con la determinación y la verificación de la identidad de los usuarios, la determinación de su autoridad para interactuar con el TOE,y con la asociación correcta de los atributos de seguridad de cada usuario autorizado. Otras clases de requisitos(Por ejemplo, usuario de Protección de Datos, Seguridad Audit) dependen de la identificación y autenticación de la correctalos usuarios con el fin de ser eficaces.

12/6/2014 ISO / IEC 15408-2



Página 71

ISO / IEC 15408-2:2008 (E)

Figura 11 - FIA: Identificación y autenticación de la clase de descomposición

12/6/2014 ISO / IEC 15408-2



11.1 Los errores de autenticación (FIA_AFL)


Esta familia contiene los requisitos para la definición de valores para algún número de autenticación incorrectaintentos y acciones de TSF en casos de fracasos de intentos de autenticación. Los parámetros incluyen, pero no se limitana, el número de intentos de autenticación fallidos y umbrales de tiempo.


Manejo de la insuficiencia FIA_AFL.1 Autenticación, requiere que el TSF poder terminar la sesiónproceso de establecimiento después de un número determinado de intentos fallidos de autenticación de usuario. También requiereque, después de la terminación del proceso de establecimiento de la sesión, la TSF sea capaz de desactivar la cuenta de usuario o

Página 72

ISO / IEC 15408-2:2008 (E)

el punto de entrada (por ejemplo, estación de trabajo) de la que se hicieron los intentos hasta que un administrador-definidocondición ocurre.

Gestión 11.1.3 de FIA_AFL.1


a) La gestión del umbral de intentos de autenticación fallidos;

b) la gestión de las acciones que se deben tomar en caso de un error de autenticación.

11.1.4 Auditoría de FIA_AFL.1


a) Mínimo: el alcance del umbral para los intentos de autenticación fallidos y las acciones (por ejemplo,desactivación de un terminal) tomada y la posterior, en su caso, la restauración al estado normal (por ejemplo, re-habilitación de un terminal).

Tratamiento de fallos 11.1.5 FIA_AFL.1 autenticación


Dependencias: FIA_UAU.1 Momento de autenticación

11.1.5.1 FIA_AFL.1.1

La TSF debe detectar cuando [selección: [asignación: número entero positivo], un administradorentero positivo configurable dentro de [asignación: rango de valores aceptables] ] fallidoslos intentos de autenticación se producen en relación con [asignación: lista de eventos de autenticación ].

11.1.5.2 FIA_AFL.1.2

Cuando el número definido de intentos de autenticación fallidos ha sido [selección: cumplido,superado ], la TSF debe [asignación: lista de acciones ].

Definición de atributo 11,2 Usuario (FIA_ATD)


Todos los usuarios autorizados pueden tener un conjunto de atributos de seguridad, aparte de la identidad del usuario, que se utiliza para hacer cumplirlos SFR. Esta familia define los requisitos para la participación de los atributos de seguridad de los usuarios con los usuarios como sea necesario paraapoyar la TSF en la toma de decisiones de seguridad.


FIA_ATD.1 definición de atributo de usuario, permite a los atributos de seguridad de usuario para cada usuario que se mantenga de forma individual.

Gestión 11.2.3 de FIA_ATD.1


a) si así se indica en la asignación, el administrador autorizado podría ser capaz de definir la seguridad adicionalatributos para los usuarios.

12/6/2014 ISO / IEC 15408-2



11.2.4 Auditoría de FIA_ATD.1


Página 73

ISO / IEC 15408-2:2008 (E)


11.2.5 definición de atributo FIA_ATD.1 usuario



11.2.5.1 FIA_ATD.1.1

La TSF debe mantener la siguiente lista de atributos de seguridad que pertenecen a usuarios individuales:[Asignación: lista de atributos de seguridad ].

11.3 Especificación de los secretos (FIA_SOS)


Esta familia define requisitos para los mecanismos que hacen cumplir las métricas de calidad definidos en la proporcionados secretos ygenerar secretos para satisfacer la métrica definida.


FIA_SOS.1 Verificación de secretos, requiere la TSF para verificar que los secretos se encuentran los indicadores de calidad definidos.

FIA_SOS.2 TSF Generación de secretos, r equiere la TSF para poder generar secretos que cumplen definidométricas de calidad.

Gestión 11.3.3 de FIA_SOS.1


a) la gestión de la métrica utilizada para verificar los secretos.

Gestión 11.3.4 de FIA_SOS.2


a) la gestión de la métrica utilizada para generar los secretos.

11.3.5 Auditoría de FIA_SOS.1, FIA_SOS.2


a) Mínimo: Rechazo por el TSF de cualquier secreto probado;

b) básica: Rechazo o aceptación por el TSF de cualquier secreto probado;

c) detallada: Identificación de cualquier cambio en los parámetros de calidad definidos.

11.3.6 FIA_SOS.1 Verificación de los secretos



11.3.6.1 FIA_SOS.1.1

La TSF debe proporcionar un mecanismo para verificar que cumplen con los secretos [asignación: una métrica de calidad definida ].

Página 74

12/6/2014 ISO / IEC 15408-2


ISO / IEC 15408-2:2008 (E)


11.3.7 Generación FIA_SOS.2 TSF de secretos



11.3.7.1 FIA_SOS.2.1

La TSF debe proporcionar un mecanismo para generar secretos que cumplan [asignación: una calidad definidamétrica ].

11.3.7.2 FIA_SOS.2.2

La TSF debe ser capaz de imponer el uso de TSF genera secretos para [asignación: lista de TSFfunciones ].

11.4 La autenticación de usuarios (FIA_UAU)


Esta familia define los tipos de mecanismos de autenticación de usuarios que admite el TSF. Esta familia tambiéndefine los atributos necesarios en los que deben basarse los mecanismos de autenticación de usuario.


FIA_UAU.1 Momento de autenticación, una llows un usuario para realizar ciertas acciones antes de la autenticación della identidad del usuario.

FIA_UAU.2 La autenticación del usuario antes de cualquier acción, requiere que los usuarios se autentican antes de cualquier otroacción será permitida por el TSF.

FIA_UAU.3 autenticación infalsificable U autenticación nforgeable, requiere el mecanismo de autenticación paraser capaz de detectar e impedir el uso de datos de autentificación que se ha forjado o copiados.

FIA_UAU.4 mecanismos de autenticación de un solo uso, requiere un mecanismo de autenticación que opera condatos de autenticación de un solo uso.

FIA_UAU.5 múltiples mecanismos de autenticación, requiere que los diferentes mecanismos de autenticación seanprestado y utilizado para autenticar la identidad del usuario para eventos específicos.

FIA_UAU.6 Re-autenticación, requiere la capacidad de especificar los eventos para los que el usuario tiene que ser re-autenticada.

FIA_UAU.7 Protegida retroalimentación autenticación, r equiere que la información de retroalimentación se proporciona es restringida ael usuario durante la autenticación.

Gestión 11.4.3 de FIA_UAU.1


a) La gestión de los datos de autenticación por un administrador;

b) La gestión de los datos de autenticación, el usuario asociado;

c) la gestión de la lista de acciones que se pueden tomar antes de que el usuario está autenticado.

Página 75

ISO / IEC 15408-2:2008 (E)



a) La gestión de los datos de autenticación por un administrador;

b) La gestión de los datos de autenticación, el usuario asociado a estos datos.

12/6/2014 ISO / IEC 15408-2



11.4.5 Gestión de FIA_UAU.3, FIA_UAU.4, FIA_UAU.7




a) la gestión de los mecanismos de autenticación;

b) la gestión de las reglas para la autenticación.



a) si un administrador autorizado puede solicitar re-autenticación, la gestión incluye un re-solicitud de autenticación.

11.4.8 Auditoría de FIA_UAU.1


a) Mínimo: haber quedado desierto el mecanismo de autenticación;

b) básica: Todo uso del mecanismo de autenticación;

c) detallada: Todas las acciones mediadas TSF realizadas antes de la autenticación del usuario.



a) Mínimo: haber quedado desierto el mecanismo de autenticación;

b) básica: Todo el uso del mecanismo de autenticación.



a) Mínimo: Detección de datos de autenticación fraudulenta;

b) básica: Todas las medidas inmediatas tomadas y los resultados de los controles sobre los datos fraudulentos.

Página 76

ISO / IEC 15408-2:2008 (E)



a) Mínimo: Los intentos de reutilizar los datos de autenticación.



a) Mínimo: La decisión final sobre la autenticación;

b) Básico: El resultado de cada mecanismo se activa junto con la decisión final.


Las siguientes acciones deben ser auditable si la generación de datos de auditoría FAU_GEN seguridad está incluido en el

12/6/2014 ISO / IEC 15408-2



PP / ST:

a) Mínimo: Fracaso de reautenticación;

b) Básico: Todos los intentos de reautenticación.



11.4.15 FIA_UAU.1 Momento de autenticación



11.4.15.1 FIA_UAU.1.1

La TSF debe permitir [asignación: lista de acciones mediadas TSF ] en nombre del usuario a realizarantes de que el usuario está autenticado.

11.4.15.2 FIA_UAU.1.2

La TSF debe exigir que cada usuario se autentica correctamente antes de permitir que cualquier otra TSF-acciones mediadas por cuenta de ese usuario.

11.4.16 autenticación FIA_UAU.2 usuario antes de cualquier acción

Jerárquica para: FIA_UAU.1 Momento de autenticación


11.4.16.1 FIA_UAU.2.1

La TSF debe exigir que cada usuario se autentica correctamente antes de permitir que cualquier otra mediada por TSFacciones en nombre de ese usuario.

Página 77

ISO / IEC 15408-2:2008 (E)

11.4.17 FIA_UAU.3 autenticación infalsificable



11.4.17.1 FIA_UAU.3.1

La TSF debe [selección: detectar, prevenir ] el uso de datos de autentificación que se ha forjado por cualquier usuariodel TSF.

11.4.17.2 FIA_UAU.3.2

La TSF debe [selección: detectar, prevenir ] el uso de datos de autentificación que se ha copiado de cualquierotro usuario del TSF.

04/11/18 FIA_UAU.4 de un solo uso de mecanismos de autenticación



11.4.18.1 FIA_UAU.4.1

La TSF debe evitar la reutilización de los datos de autenticación relacionados con [asignación: autentificación identificadomecanismo (s) ].

04/11/19 FIA_UAU.5 mecanismos de autenticación múltiples


12/6/2014 ISO / IEC 15408-2




11.4.19.1 FIA_UAU.5.1

La TSF debe proporcionar [asignación: lista de múltiples mecanismos de autenticación ] para apoyar el usuariola autenticación.

11.4.19.2 FIA_UAU.5.2

La TSF debe autenticar la identidad declarada de cualquier usuario de acuerdo con el [asignación: reglas que describecómo los múltiples mecanismos de autenticación proporcionan autenticación ].

04/11/20 FIA_UAU.6 Re-autenticación



11.4.20.1 FIA_UAU.6.1

La TSF debe volver a autenticar al usuario en las condiciones [asignación: lista de condiciones bajo lasSe requiere que re-autenticación ].

11/04/21 FIA_UAU.7 Protegida retroalimentación autenticación



Página 78

ISO / IEC 15408-2:2008 (E)

11.4.21.1 FIA_UAU.7.1

La TSF debe proporcionar sólo [asignación: lista de votaciones ] para el usuario, mientras que la autenticación está enprogreso.

11.5 Identificación de Usuario (FIA_UID)


Esta familia define las condiciones en las que se exigirá a los usuarios que se identifiquen antes dela realización de cualesquiera otras actuaciones que se van a la mediación de la TSF y que requieren la identificación del usuario.


FIA_UID.1 Momento de la identificación, permite a los usuarios realizar ciertas acciones antes de ser identificado por el TSF.

FIA_UID.2 identificación del usuario antes de cualquier acción , requiere que los usuarios se identifican antes que cualquier otroacción será permitida por el TSF.

Gestión 11.5.3 de FIA_UID.1


a) la gestión de las identidades de los usuarios;

b) si un administrador autorizado puede cambiar las acciones permitidas antes de la identificación, el manejo de lalistas de acciones.

Gestión 11.5.4 de FIA_UID.2


a) la gestión de las identidades de usuario.

11.5.5 Auditoría de FIA_UID.1, FIA_UID.2


a) Mínimo: haber quedado desierto el mecanismo de identificación del usuario, incluyendo la identidad de usuario proporcionada;

12/6/2014 ISO / IEC 15408-2



b) básica: Todo el uso del mecanismo de identificación del usuario, incluyendo la identidad de usuario proporcionada.

11.5.6 FIA_UID.1 Momento de la identificación



11.5.6.1 FIA_UID.1.1

La TSF debe permitir [asignación: lista de acciones mediadas por TSF ] en nombre del usuario que se deben realizarantes de que se identifique el usuario.

11.5.6.2 FIA_UID.1.2

La TSF debe exigir que cada usuario sea identificado con éxito antes de permitir que cualquier otra mediada por TSFacciones en nombre de ese usuario.

Página 79

ISO / IEC 15408-2:2008 (E)

11.5.7 identificación FIA_UID.2 usuario antes de cualquier acción

Jerárquica para: FIA_UID.1 Momento de la identificación


11.5.7.1 FIA_UID.2.1

La TSF debe exigir que cada usuario sea identificado con éxito antes de permitir que las demás acciones mediadas por TSFen nombre de ese usuario.

11.6 el usuario sujeta la unión (FIA_USB)


Un usuario autenticado, con el fin de utilizar el TOE, típicamente activa un sujeto. Los atributos de seguridad del usuario sonasociado (total o parcialmente) con este tema. Esta familia define requisitos para crear y mantener laasociación de seguridad del usuario atribuye a un sujeto que actúa en nombre del usuario.


FIA_USB.1 usuario-sujeto vinculante, requiere la especificación de las normas que rigen la relación entre elatributos de usuario y los atributos del objeto en el que se asignan.

Gestión 11.6.3 de FIA_USB.1


a) un administrador autorizado puede definir los atributos de seguridad sujeta por defecto.

b) un administrador autorizado puede cambiar los atributos de seguridad en cuestión.

11.6.4 Auditoría de FIA_USB.1


a) Mínimo: Sin éxito la unión de la seguridad del usuario atribuye a un sujeto (por ejemplo, creación de un sujeto).

b) Básico: El éxito y el fracaso de la unión de la seguridad del usuario atribuye a un sujeto (por ejemplo, el éxito o el fracaso decrear un objeto).

11.6.5 FIA_USB.1 el usuario sujeta la unión


Dependencias: Definición de atributo FIA_ATD.1 usuario

11.6.5.1 FIA_USB.1.1

La TSF debe asociar los siguientes atributos de seguridad del usuario con los sujetos que actúan en nombre deese usuario: [asignación: lista de atributos de seguridad de usuario ].

12/6/2014 ISO / IEC 15408-2



11.6.5.2 FIA_USB.1.2

La TSF debe aplicar las siguientes reglas sobre la asociación inicial de los atributos de seguridad de los usuarios conlos sujetos que actúan en el nombre de los usuarios: [asignación: reglas para la asociación inicial de atributos ].

Página 80

ISO / IEC 15408-2:2008 (E)


11.6.5.3 FIA_USB.1.3

La TSF debe aplicar las siguientes normas que rigen los cambios en los atributos de seguridad de usuario asociadoscon los sujetos que actúan en el nombre de los usuarios: [asignación: reglas para el cambio de atributos ].

12 Clase FMT: Gestión de la seguridad

Esta clase está diseñada para especificar la gestión de varios aspectos de la TSF: atributos de seguridad, datos de TSFy funciones. Las diferentes funciones de gestión y su interacción, como la separación de la capacidad, pueden serespecificado.

Esta clase tiene varios objetivos:

a) La gestión de los datos de la TSF, que incluyen, por ejemplo, las banderas;

b) la gestión de los atributos de seguridad, que incluyen, por ejemplo, las listas de control de acceso, y CapacidadListas;

c) la gestión de las funciones de la TSF, que incluye, por ejemplo, la selección de funciones y reglas ocondiciones que influyen en el comportamiento de la TSF;

d) la definición de los roles de seguridad.

12/6/2014 ISO / IEC 15408-2


Página 81

ISO / IEC 15408-2:2008 (E)


Figura 12 - FMT: clase de gestión de seguridad de descomposición

12.1 Gestión de funciones en TSF (FMT_MOF)


Esta familia permite a los usuarios autorizados el control sobre la gestión de las funciones de la TSF. Ejemplos defunciones en el TSF incluyen las funciones de auditoría y de las múltiples funciones de autenticación.


Gestión FMT_MOF.1 de funciones de seguridad de comportamiento cols mínimos los usuarios autorizados (roles) para gestionar elcomportamiento de las funciones de la TSF que utilizan reglas o que tienen condiciones específicas que puedan ser manejables.

Gestión 12.1.3 de FMT_MOF.1


a) la gestión del grupo de funciones que pueden interactuar con las funciones de la TSF;

Página 82

ISO / IEC 15408-2:2008 (E)

12.1.4 Auditoría de FMT_MOF.1


12/6/2014 ISO / IEC 15408-2



a) básica: Todas las modificaciones en el comportamiento de las funciones de la TSF.

12.1.5 FMT_MOF.1 Gestión de las funciones de seguridad de la conducta


Dependencias: Papeles FMT_SMR.1 Seguridad

FMT_SMF.1 Especificación de funciones de gestión de

12.1.5.1 FMT_MOF.1.1

La TSF debe restringir la capacidad de [selección: determinar el comportamiento de, deshabilitar, habilitar, modificar elcomportamiento de las funciones] [asignación: lista de funciones ] a [asignación: el autorizado identificadopapeles ].

12.2 Gestión de los atributos de seguridad (FMT_MSA)


Esta familia permite a los usuarios autorizados el control sobre la gestión de los atributos de seguridad. Esta gestiónpodría incluir capacidades para la visualización y modificación de los atributos de seguridad.


Gestión FMT_MSA.1 de atributos de seguridad a llows usuarios autorizados (roles) para gestionar la especificadalos atributos de seguridad.

FMT_MSA.2 seguridad Secure atributos e nsures que los valores asignados a los atributos de seguridad son válidos conrespecto al estado seguro.

FMT_MSA.3 estático atributo de inicialización asegura que los valores por defecto de los atributos de seguridad estén debidamenteya sea permisiva o restrictiva en la naturaleza.

Atributo FMT_MSA.4 Seguridad de valor de herencia cols mínimos las reglas / políticas que se especifiquen que dictarán lavalor para ser heredado por un atributo de seguridad.

Gestión 12.2.3 de FMT_MSA.1


a) la gestión del grupo de funciones que pueden interactuar con los atributos de seguridad;

b) la gestión de reglas por las cuales los atributos de seguridad heredan los valores especificados.



a) La gestión de reglas por las cuales los atributos de seguridad heredan valores especificados.

Página 83

ISO / IEC 15408-2:2008 (E)



a) la gestión del grupo de papeles que pueden especificar los valores iniciales;

b) la gestión de la configuración permisiva o restrictiva de los valores predeterminados de un SFP de control de acceso determinada;

c) la gestión de reglas por las cuales los atributos de seguridad heredan los valores especificados.



a) especificación de la función permite establecer o modificar los atributos de seguridad.

12/6/2014 ISO / IEC 15408-2



12.2.7 Auditoría de FMT_MSA.1


a) básica: Todas las modificaciones de los valores de los atributos de seguridad.



a) Mínimo: Todas ofrecido y rechazado los valores de un atributo de seguridad.

b) detallada: Todos los ofrecidos y aceptados los valores seguros para un atributo de seguridad.



a) básica: Modificaciones de la configuración por defecto de las normas permisivas o restrictivas.

b) básica: Todas las modificaciones de los valores iniciales de los atributos de seguridad.



a) Básicas: Las modificaciones de los atributos de seguridad, posiblemente con la edad y / o valores de atributos de seguridad quese han modificado.

12.2.11 FMT_MSA.1 Gestión de atributos de seguridad




Papeles FMT_SMR.1 Seguridad


Página 84

ISO / IEC 15408-2:2008 (E)

12.2.11.1 FMT_MSA.1.1

La TSF debe aplicar la [asignación: SFP (s) de control de acceso, SFP (s) de control de flujo de información ] pararestringir la capacidad de [selección: change_default, consultar, modificar, eliminar, [asignación: otras operaciones] ]los atributos de seguridad [asignación: lista de atributos de seguridad ] en [asignación: la autorizadapapeles identificados ].

02/12/12 FMT_MSA.2 atributos de seguridad Secure




Gestión FMT_MSA.1 de atributos de seguridad


12.2.12.1 FMT_MSA.2.1

La TSF debe garantizar que sólo los valores seguros son aceptados para [asignación: lista de atributos de seguridad ].

12.2.13 FMT_MSA.3 estático inicialización atributo


Dependencias: Gestión FMT_MSA.1 de atributos de seguridad

12/6/2014 ISO / IEC 15408-2




12.2.13.1 FMT_MSA.3.1

La TSF debe aplicar la [asignación: SFP de control de acceso, el flujo de información de control de la SFP ] para proporcionar[Selección, elegir uno de: restrictiva, permisiva, [asignación: otros bienes] ] valores predeterminados paraatributos de seguridad que se utilizan para hacer cumplir la SFP.

12.2.13.2 FMT_MSA.3.2

La TSF debe permitir que el [asignación: los roles identificados autorizados ] para especificar inicial alternativavalores para anular los valores por defecto cuando se crea un objeto o información.

12.2.14 FMT_MSA.4 Seguridad valor del atributo de herencia




12.2.14.1 FMT_MSA.4.1

La TSF debe utilizar las siguientes reglas para establecer el valor de los atributos de seguridad: [asignación: reglas paraestablecer los valores de los atributos de seguridad ].

Página 85

ISO / IEC 15408-2:2008 (E)

12.3 Gestión de los datos de TSF (FMT_MTD)


Esta familia permite a los usuarios autorizados (roles) de control de la gestión de datos de la TSF. Ejemplos de datos TSFincluir información de auditoría, el reloj y otros parámetros de configuración de TSF.


Gestión FMT_MTD.1 de los datos TSF todos ows usuarios autorizados para administrar los datos de TSF.

Gestión FMT_MTD.2 de límites en espe datos TSF cifies la acción a tomar si los límites en los datos de TSF sonalcanzado o superado.

FMT_MTD.3 Asegure TSF ens datos das que los valores asignados a los datos de TSF son válidos con respecto a la seguridadestado.

Gestión 12.3.3 de FMT_MTD.1


a) la gestión del grupo de funciones que pueden interactuar con los datos de la TSF.



a) la gestión del grupo de funciones que pueden interactuar con los límites de los datos de la TSF.



12.3.6 Auditoría de FMT_MTD.1


a) básica: Todas las modificaciones de los valores de los datos de la TSF.

12/6/2014 ISO / IEC 15408-2





a) básica: Todas las modificaciones de los límites de los datos TSF.

b) básica: Todas las modificaciones en las medidas que deben adoptarse en caso de violación de los límites.



a) Mínimo: Todos los valores de los datos TSF rechazada.

12.3.9 FMT_MTD.1 Gestión de los datos TSF


Página 86

ISO / IEC 15408-2:2008 (E)



12.3.9.1 FMT_MTD.1.1

La TSF debe restringir la capacidad de [selección: change_default, consultar, modificar, borrar, claro,[Asignación: otras operaciones] ] de [asignación: lista de datos de la TSF ] que [Asignación: la autorizaciónpapeles identificados ].

12.3.10 FMT_MTD.2 Gestión de límites en los datos TSF


Dependencias: Gestión FMT_MTD.1 de datos TSF


12.3.10.1 FMT_MTD.2.1

La TSF debe restringir la especificación de los límites de [asignación: lista de datos de la TSF ] que [Asignación:los papeles identificados autorizados ].

12.3.10.2 FMT_MTD.2.2

La TSF debe tomar las siguientes acciones, si los datos están en TSF, o superar, los límites que se indican:[Asignación: acciones a tomar ].

12.3.11 FMT_MTD.3 datos TSF Secure


Dependencias: Gestión FMT_MTD.1 de datos TSF

12.3.11.1 FMT_MTD.3.1

La TSF debe garantizar que sólo los valores seguros son aceptados para [asignación: lista de datos TSF ].

12.4 Revocación (FMT_REV)


Esta direcciones familiares revocación de atributos de seguridad para una variedad de entidades dentro de un TOE.


FMT_REV.1 revocación prov ides para la revocación de atributos de seguridad que deba ejecutarse en algún momento en el tiempo.

Gestión 12.4.3 de FMT_REV.1


12/6/2014 ISO / IEC 15408-2



a) la gestión del grupo de papeles que pueden invocar la revocación de los atributos de seguridad;

b) la gestión de las listas de usuarios, sujetos, objetos y otros recursos para que la revocación sea posible;

c) la gestión de las reglas de revocación.

Página 87

ISO / IEC 15408-2:2008 (E)


12.4.4 Auditoría de FMT_REV.1


a) Mínimo: revocación frustrado de los atributos de seguridad.

b) Básico: Todos los intentos de revocar los atributos de seguridad.

12.4.5 FMT_REV.1 Revocación



12.4.5.1 FMT_REV.1.1

La TSF debe restringir la capacidad de revocar [asignación: lista de atributos de seguridad ] asociado a la[Selección: los usuarios, los sujetos, objetos, [asignación: otros recursos adicionales] ] bajo el control de laTSF que [Asignación: los roles identificados autorizados ].

12.4.5.2 FMT_REV.1.2

La TSF debe aplicar las reglas [asignación: especificación de reglas de revocación ].

Caducidad atributo 12.5 Seguridad (FMT_SAE)


Esta familia se refiere a la capacidad de hacer cumplir los plazos de validez de los atributos de seguridad.


Autorización FMT_SAE.1 tiempo limitado-pr ovides la capacidad de un usuario autorizado para especificar una caducidadtiempo en los atributos de seguridad especificados.

Gestión 12.5.3 de FMT_SAE.1


a) la gestión de la lista de atributos de seguridad para los que la expiración se va a apoyar;

b) las acciones a tomar si ha pasado la fecha de caducidad.

12.5.4 Auditoría de FMT_SAE.1


a) básica: Especificación de la fecha de caducidad de un atributo;

b) básica: Medidas adoptadas por atribuir caducidad.

12.5.5 FMT_SAE.1 autorización limitada en el tiempo



FPT_STM.1 marcas de tiempo fiables

12/6/2014 ISO / IEC 15408-2


Página 88

ISO / IEC 15408-2:2008 (E)


12.5.5.1 FMT_SAE.1.1

La TSF debe restringir la capacidad de especificar una fecha de caducidad para [asignación: lista de seguridadatributos para los cuales vencimiento se va a apoyar ] a [asignación: los roles identificados autorizados ].

12.5.5.2 FMT_SAE.1.2

Para cada uno de estos atributos de seguridad, la TSF debe ser capaz de [asignación: lista de las acciones que se deben tomarpara cada atributo de seguridad ] después de la fecha de caducidad para el atributo de seguridad indicada ha pasado.

12.6 Especificación de las funciones de gestión (FMT_SMF)


Esta familia permite la especificación de las funciones de gestión que ha de proporcionar el TOE. Administraciónfunciones proporcionan TSFI que permiten a los administradores definir los parámetros que controlan el funcionamiento de la seguridad-aspectos relacionados con la TOE, como atributos de protección de datos, atributos de protección para los dedos, los atributos de la auditoría, yatributos de identificación y autenticación. Las funciones de gestión también incluyen las funciones llevadas a cabo poroperador para garantizar el funcionamiento continuo de la TOE, tales como copias de seguridad y recuperación. Esta familia trabaja enjunto con los otros componentes de la FMT: Gestión de la seguridad c lass: el componente de esta familiapide a cabo las funciones de gestión, y otras familias en FMT: res de gestión de seguridad trito la capacidad de utilizarestas funciones de gestión.


FMT_SMF.1 Especificación de funciones de gestión de r equiere que el TSF proporciona una gestión específicafunciones.

Gestión 12.6.3 de FMT_SMF.1


12.6.4 Auditoría de FMT_SMF.1


a) Mínimo: El uso de las funciones de gestión.

12.6.5 FMT_SMF.1 Especificación de funciones de gestión de



12.6.5.1 FMT_SMF.1.1

La TSF debe ser capaz de realizar las siguientes funciones de administración: [asignación: lista defunciones de gestión a ser provistos por el TSF ].

12.7 roles de gestión de seguridad (FMT_SMR)


Esta familia está destinado a controlar la asignación de diferentes funciones a los usuarios. Las capacidades de estos roles conrespecto a la gestión de la seguridad se describen en el resto de las familias de esta clase.

Página 89

ISO / IEC 15408-2:2008 (E)


12/6/2014 ISO / IEC 15408-2



Papeles FMT_SMR.1 Seguridad sp ecifies los roles con respecto a la seguridad de que el TSF reconoce.

Restricciones FMT_SMR.2 sobre los roles de seguridad spe cifies que, además de la especificación de las funciones, hayreglas que controlan la relación entre las funciones.

FMT_SMR.3 Asumiendo roles req uires que una petición explícita se da a la TSF para asumir un papel.

Gestión 12.7.3 de FMT_SMR.1


a) la gestión del grupo de usuarios que forman parte de un papel.



a) la gestión del grupo de usuarios que forman parte de un papel;

b) la gestión de las condiciones que los papeles deben satisfacer.



12.7.6 Auditoría de FMT_SMR.1


a) Mínimo: modificaciones en el grupo de usuarios que forman parte de un papel.

b) Datos individuales: cada uso de los derechos de un papel.



a) Mínimo: modificaciones en el grupo de usuarios que forman parte de un papel.

b) Minimal: intentos fallidos de utilizar un papel, debido a las condiciones dadas en los roles.

c) Datos individuales: cada uso de los derechos de un papel.



a) Mínimo: petición explícita de asumir un papel.

12.7.9 papeles FMT_SMR.1 Seguridad



Página 90

ISO / IEC 15408-2:2008 (E)

12.7.9.1 FMT_SMR.1.1

La TSF debe mantener los papeles [asignación: los roles identificados autorizados ].

12.7.9.2 FMT_SMR.1.2

La TSF debe ser capaz de asociar a los usuarios con roles.

12/07/10 FMT_SMR.2 Restricciones a las funciones de seguridad

Jerárquica para: Papeles FMT_SMR.1 Seguridad


12/6/2014 ISO / IEC 15408-2



12.7.10.1 FMT_SMR.2.1

La TSF debe mantener los roles: [asignación: autorizados roles identificados ].

12.7.10.2 FMT_SMR.2.2

La TSF debe ser capaz de asociar a los usuarios con roles.

12.7.10.3 FMT_SMR.2.3

La TSF debe garantizar que las condiciones [asignación: condiciones para los diferentes roles ] están satisfechos.

12/07/11 papeles FMT_SMR.3 Suponiendo



12.7.11.1 FMT_SMR.3.1

La TSF debe requerir una solicitud explícita para asumir las siguientes funciones: [asignación: los roles ].

Página 91

ISO / IEC 15408-2:2008 (E)

13 Clase FPR: Privacidad

Esta clase contiene los requisitos de privacidad. Estos requisitos proporcionan una protección del usuario contra el descubrimiento yel uso indebido de la identidad de otros usuarios.

12/6/2014 ISO / IEC 15408-2



Figura 13 - FPR: Privacidad clase descomposición

13.1 El anonimato (FPR_ANO)


Esta familia asegura que un usuario puede utilizar un recurso o servicio sin revelar la identidad del usuario. Lalos requisitos para el anonimato proporcionan protección de la identidad del usuario. El anonimato no está diseñado para proteger elidentidad del sujeto.


FPR_ANO.1 anonimato, re requiere que otros usuarios o sujetos son incapaces de determinar la identidad de un usuariounido a un sujeto o la operación.

FPR_ANO.2 anonimato sin solicitar informació n aumenta los requisitos de FPR_ANO.1 Anonimatoasegurando que el TSF no pide la identidad del usuario.

Gestión 13.1.3 de FPR_ANO.1, FPR_ANO.2


13.1.4 Auditoría de FPR_ANO.1, FPR_ANO.2


a) Mínimo: La invocación del mecanismo de anonimato.

Página 92

ISO / IEC 15408-2:2008 (E)

13.1.5 FPR_ANO.1 Anonimato



13.1.5.1 FPR_ANO.1.1

La TSF debe garantizar que [Asignación: conjunto de usuarios y / o sujetos ] no son capaces de determinar la verdaderaNombre de usuario vinculado a [asignación: lista de temas y / u operaciones y / u objetos ].

13.1.6 FPR_ANO.2 anonimato sin solicitar información

Jerárquica para: FPR_ANO.1 Anonimato


13.1.6.1 FPR_ANO.2.1

La TSF debe garantizar que [Asignación: conjunto de usuarios y / o sujetos ] no son capaces de determinar el usuario realnombrar con destino a [asignación: lista de temas y / u operaciones y / u objetos ].

13.1.6.2 FPR_ANO.2.2

La TSF debe proporcionar [asignación: lista de servicios ] que [Asignación: lista de temas ] sin solicitarcualquier referencia al nombre de usuario real.

13.2 seudónimos (FPR_PSE)


Esta familia asegura que un usuario puede utilizar un recurso o servicio, sin revelar su identidad de usuario, pero todavía puedeser responsable de ese uso.


FPR_PSE.1 seudonimia requ IRES que un conjunto de usuarios y / o sujetos son incapaces de determinar la identidad de

12/6/2014 ISO / IEC 15408-2



un usuario enlazado a un objeto u operación, pero que este usuario es todavía responsable de sus acciones.

FPR_PSE.2 seudonimia reversible, re requiere la TSF para proporcionar una capacidad de determinar el usuario originalidentidad sobre la base de un alias de proporcionado.

FPR_PSE.3 Alias seudónimos, req uires la TSF que seguir ciertas reglas de construcción para el alias para el usuarioidentidad.

Gestión 13.2.3 de FPR_PSE.1, FPR_PSE.2, FPR_PSE.3


13.2.4 Auditoría de FPR_PSE.1, FPR_PSE.2, FPR_PSE.3


a) Mínimo: El sujeto / usuario que solicitó la resolución de la identidad del usuario debe ser auditado.

Página 93

ISO / IEC 15408-2:2008 (E)

13.2.5 FPR_PSE.1 seudonimia



13.2.5.1 FPR_PSE.1.1

La TSF debe garantizar que [Asignación: conjunto de usuarios y / o sujetos ] no son capaces de determinar la verdaderaNombre de usuario vinculado a [asignación: lista de temas y / u operaciones y / u objetos ].

13.2.5.2 FPR_PSE.1.2

La TSF debe ser capaz de proporcionar [asignación: número de alias ] alias del nombre de usuario real para[Asignación: lista de temas ].

13.2.5.3 FPR_PSE.1.3

La TSF debe [selección, elegir uno de: determinar un alias para un usuario, acepte el alias del usuario ]y comprobar que se ajusta a la [asignación: alias métrica ].

13.2.6 FPR_PSE.2 seudonimia Reversible

Jerárquica para: FPR_PSE.1 seudonimia


13.2.6.1 FPR_PSE.2.1


13.2.6.2 FPR_PSE.2.2


13.2.6.3 FPR_PSE.2.3

La TSF debe [selección, elegir uno de: determinar un alias para un usuario, acepte el alias del usuario ] yverificar que se ajusta a la [asignación: alias métrica ].

13.2.6.4 FPR_PSE.2.4

La TSF debe proporcionar [selección: un usuario autorizado, [asignación: lista de temas de confianza] ] uncapacidad de determinar la identidad del usuario en base a los alias proporcionadas solamente bajo las siguientes[Asignación: lista de condiciones ].

13.2.7 FPR_PSE.3 Alias seudonimia

12/6/2014 ISO / IEC 15408-2



Jerárquica para: FPR_PSE.1 seudonimia


13.2.7.1 FPR_PSE.3.1


Página 94

ISO / IEC 15408-2:2008 (E)

13.2.7.2 FPR_PSE.3.2


13.2.7.3 FPR_PSE.3.3

La TSF debe [selección, elegir uno de: determinar un alias para un usuario, acepte el alias del usuario ] yverificar que se ajusta a la [asignación: alias métrica ].

13.2.7.4 FPR_PSE.3.4

La TSF debe proporcionar un alias para el nombre de usuario real que será idéntica a un alias proporcionadoanteriormente con el siguiente [asignación: lista de condiciones ] de lo contrario el alias proporcionada deberásin relación a proporcionadas anteriormente alias.

13.3 imposibilidad de vinculación (FPR_UNL)


Esta familia asegura que un usuario puede hacer múltiples usos de los recursos o servicios sin que los demás la posibilidad devincular estos usos juntos.


FPR_UNL.1 imposibilidad de vinculación, requiere que los usuarios y / o sujetos son incapaces de determinar si el mismo usuariocausado ciertas operaciones específicas.

Gestión 13.3.3 de FPR_UNL.1


a) la gestión de la función de imposibilidad de vinculación.

13.3.4 Auditoría de FPR_UNL.1


a) Mínimo: La invocación del mecanismo de imposibilidad de vinculación.

13.3.5 FPR_UNL.1 imposibilidad de vinculación



13.3.5.1 FPR_UNL.1.1

La TSF debe garantizar que [Asignación: conjunto de usuarios y / o sujetos ] no son capaces de determinar si[Asignación: lista de operaciones ] [selección: fueron causadas por el mismo usuario, se relacionan comosiguiente [asignación: lista de relaciones] ].

13.4 inobservabilidad (FPR_UNO)


Esta familia asegura que un usuario puede utilizar un recurso o servicio sin otros, especialmente tercera partes, siendopodido observar que se está utilizando el recurso o servicio.

12/6/2014 ISO / IEC 15408-2



Página 95

ISO / IEC 15408-2:2008 (E)



FPR_UNO.1 imposibilidad de observación r equiere que los usuarios y / o sujetos no pueden determinar si una operación esque se realiza.

FPR_UNO.2 Asignación de información impactando imposibilidad de observación requiere que el TSF proporciona específicomecanismos para evitar la concentración de la privacidad de la información relacionada en el TOE. Tales concentracionespodría afectar inobservabilidad si se produce un riesgo de seguridad.

FPR_UNO.3 inobservabilidad sin solicitar información, requiere que el TSF no trata de obtener privacidadinformación relacionada que pueda ser utilizada para comprometer inobservabilidad.

FPR_UNO.4 Autorizado usuario observabilidad, requiere la TSF para proporcionar uno o más usuarios autorizados con unla capacidad para observar el uso de los recursos y / o servicios.

Gestión 13.4.3 de FPR_UNO.1, FPR_UNO.2


a) la gestión del comportamiento de la función imposibilidad de observación.

13.4.4 Gestión de FPR_UNO.3


13.4.5 Gestión de FPR_UNO.4


a) la lista de usuarios autorizados que son capaces de determinar la ocurrencia de operaciones.

13.4.6 Auditoría de FPR_UNO.1, FPR_UNO.2


a) Mínimo: La invocación del mecanismo de imposibilidad de observación.

13.4.7 Auditoría de FPR_UNO.3


13.4.8 Auditoría de FPR_UNO.4


a) Mínimo: La observación de la utilización de un recurso o servicio por un usuario o materia.

13.4.9 FPR_UNO.1 inobservabilidad



Página 96

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



13.4.9.1 FPR_UNO.1.1

La TSF debe garantizar que [asignación: lista de usuarios y / o sujetos ] no son capaces de observar laoperación [asignación: lista de operaciones ] de [asignación: lista de objetos ] por [asignación: lista deusuarios y / o sujetos protegidos ].

13.4.10 FPR_UNO.2 Asignación de información impactando inobservabilidad

Jerárquica para: FPR_UNO.1 inobservabilidad


13.4.10.1 FPR_UNO.2.1

La TSF debe garantizar que [asignación: lista de usuarios y / o sujetos ] no son capaces de observar el funcionamiento[Asignación: lista de operaciones ] de [asignación: lista de objetos ] por [asignación: lista de usuarios y / o protegidastemas ].

13.4.10.2 FPR_UNO.2.2

La TSF debe asignar el [asignación: inobservabilidad información relacionada ] entre las diferentes partes delTOE tal que cumplen las siguientes condiciones durante la vida útil de la información: [asignación:lista de condiciones ].

13.4.11 FPR_UNO.3 inobservabilidad sin solicitar información


Dependencias: FPR_UNO.1 inobservabilidad

13.4.11.1 FPR_UNO.3.1

La TSF debe proporcionar [asignación: lista de servicios ] que [Asignación: lista de temas ] sin solicitarcualquier referencia a [asignación: la información relacionada con la privacidad ].

13.4.12 FPR_UNO.4 Autorizado usuario observabilidad



13.4.12.1 FPR_UNO.4.1

La TSF debe proporcionar [asignación: conjunto de usuarios autorizados ] con la capacidad de observar el usode [asignación: lista de recursos y / o servicios ].

14 Clase FPT: Protección del TSF

Esta clase contiene familias de requisitos funcionales que se relacionan con la integridad y la gestión de lamecanismos que constituyen el TSF y para la integridad de los datos TSF. En cierto sentido, las familias de esta clase puedeparecen duplicar componentes en el FDP: protección de datos de usuario de clase; incluso pueden ser implementados utilizandolos mismos mecanismos. Sin embargo, FDP : protección de los datos del usuario fo centra en la protección de datos de usuario, mientras FPT:Protección del TSF se centra en la protección de los datos TSF. De hecho, los componentes de la FPT: Protección de laTSF clase son necesarios para proporcionar los requisitos que los programas de alimentación complementaria en el TOE no pueden ser manipulados oanulada.

Desde el punto de vista de esta clase, con respecto a la TSF hay tres elementos importantes:

a) la aplicación del TSF, que ejecuta e implementa los mecanismos que hacen cumplir la SFR.

Página 97

ISO / IEC 15408-2:2008 (E)

b) Los datos de la TSF, que son las bases de datos administrativas que rigen la aplicación de la SFR.

c) Las entidades externas que el TSF puede interactuar con el fin de hacer cumplir la SFR.

12/6/2014 ISO / IEC 15408-2



Figura 14 - FPT: Protección de la clase de descomposición TSF

14.1 fail secure (FPT_FLS)


Los requisitos de esta familia aseguran que el TOE siempre hará cumplir sus SFRs en caso de identificarcategorías de fallos en la TSF.

Página 98

ISO / IEC 15408-2:2008 (E)


Esta familia se compone de un solo componente, F Falla PT_FLS.1 con la preservación de las condiciones de seguridad, querequiere que el TSF preservar las condiciones de seguridad en la cara de los fallos detectados.

Gestión 14.1.3 de FPT_FLS.1


14.1.4 Auditoría de FPT_FLS.1


a) básica: Fracaso de la TSF.

14.1.5 El incumplimiento FPT_FLS.1 con la preservación de las condiciones de seguridad



14.1.5.1 FPT_FLS.1.1

12/6/2014 ISO / IEC 15408-2



La TSF debe mantener un estado seguro cuando se producen los siguientes tipos de errores: [asignación: lista detipos de fallos en la TSF ].

14.2 Disponibilidad de los datos TSF exportados (FPT_ITA)


Esta familia define las normas para la prevención de la pérdida de la disponibilidad de datos de TSF se mueve entre la TSF yotro producto de TI de confianza. Estos datos podrían, por ejemplo, ser TSF datos críticos tales como contraseñas, claves, auditoríadatos, o TSF código ejecutable.


Esta familia se compone de un solo componente, FP T_ITA.1 Inter-TSF disponibilidad dentro de una disponibilidad definidamétrica. Este componente requiere que el TSF asegurar, en un grado determinado de la probabilidad, la disponibilidad deDatos TSF prestados a otro producto de TI de confianza.

Gestión 14.2.3 de FPT_ITA.1


a) la gestión de la lista de tipos de datos de TSF que deben estar a disposición de otro producto de TI de confianza.

14.2.4 Auditoría de FPT_ITA.1


a) Mínimo: la ausencia de datos TSF cuando sea requerido por una TOE.

14.2.5 FPT_ITA.1 Inter-TSF disponibilidad dentro de una métrica definida disponibilidad



Página 99

ISO / IEC 15408-2:2008 (E)

14.2.5.1 FPT_ITA.1.1

La TSF debe garantizar la disponibilidad de [asignación: lista de tipos de datos de la TSF ] proporcionado a otroproducto de TI confiable dentro de [asignación: una métrica disponibilidad definida ] dadas las siguientes condiciones[Asignación: las condiciones para garantizar la disponibilidad ].

14.3 Confidencialidad de los datos TSF exportados (FPT_ITC)


Esta familia define las normas para la protección contra la divulgación no autorizada de datos TSF durante su transmisiónentre la TSF y otro producto de TI de confianza. Estos datos podrían, por ejemplo, ser TSF datos críticos tales comocontraseñas, claves, datos de auditoría, o TSF código ejecutable.


Esta familia se compone de un solo componente, confidencialidad FPT_ITC.1 Inter-TSF durante su transmisión , lo querequiere que el TSF garantizar que los datos transmitidos entre el TSF y otro producto de TI de confianza esprotegida contra la divulgación durante el transporte.

Gestión 14.3.3 de FPT_ITC.1


14.3.4 Auditoría de FPT_ITC.1


Confidencialidad 14.3.5 FPT_ITC.1 Inter-TSF durante su transmisión



14.3.5.1 FPT_ITC.1.1

12/6/2014 ISO / IEC 15408-2



La TSF debe proteger todos los datos transmitidos desde el TSF TSF a otro producto de TI de confianza desdedivulgación no autorizada durante la transmisión.

14.4 Integridad de los datos TSF exportados (FPT_ITI)


Esta familia define las normas para la protección, la modificación no autorizada de los datos de la TSF durantetransmisión entre la TSF y otro producto de TI de confianza. Estos datos podrían, por ejemplo, ser TSF críticodatos como contraseñas, claves, datos de auditoría, o TSF código ejecutable.


Detección FPT_ITI.1 Inter-TSF de modificación, proporciona la capacidad de detectar la modificación de los datos de TSF durantetransmisión entre la TSF y otro producto de TI de confianza, bajo el supuesto de que otro de confianza de TIproducto es consciente del mecanismo utilizado.

Detección y corrección de la modificación FPT_ITI.2 Inter-TSF, ofrece la posibilidad de otro producto de TI de confianzano sólo para detectar la modificación, pero para corregir los datos de TSF modificados bajo el supuesto de que otro de confianza de TIproducto es consciente del mecanismo utilizado.

Página 100

ISO / IEC 15408-2:2008 (E)

Gestión 14.4.3 de FPT_ITI.1


Gestión 14.4.4 de FPT_ITI.2


a) la gestión de los tipos de datos que el TSF TSF debe tratar de corregir si se modifican durante el transporte;

b) la gestión de los tipos de acción que el TSF podría tomar si los datos TSF es modificado en tránsito.

14.4.5 Auditoría de FPT_ITI.1


a) Mínimo: la detección de la modificación de los datos de TSF transmitidos.

b) básica: las medidas adoptadas después de la detección de la modificación de los datos TSF transmitidos.

14.4.6 Auditoría de FPT_ITI.2


a) Mínimo: la detección de la modificación de los datos de TSF transmitidos.

b) básica: las medidas adoptadas después de la detección de la modificación de los datos TSF transmitidos.

c) básica: el uso del mecanismo de corrección.

Detección 14.4.7 FPT_ITI.1 Inter-TSF de la modificación



14.4.7.1 FPT_ITI.1.1

La TSF debe ofrecer la capacidad de detectar la modificación de todos los datos de la TSF durante su transmisiónentre la TSF y otro producto de confianza de TI dentro de las siguientes mediciones: [asignación: una definidamétrica modificación ].

14.4.7.2 FPT_ITI.1.2

12/6/2014 ISO / IEC 15408-2



La TSF debe ofrecer la posibilidad de verificar la integridad de todos los datos transmitidos entre el TSF TSFy otro producto de TI de confianza y realizar [asignación: medidas que deben adoptarse ] si las modificaciones sondetectado.

Detección y corrección de la modificación 14.4.8 FPT_ITI.2 Inter-TSF

Jerárquica para: Detección FPT_ITI.1 Inter-TSF de la modificación


Página 101

ISO / IEC 15408-2:2008 (E)

14.4.8.1 FPT_ITI.2.1

La TSF debe ofrecer la capacidad de detectar la modificación de todos los datos de la TSF durante su transmisión entre laTSF y otro producto de TI de confianza dentro de las siguientes mediciones: [asignación: una métrica definida modificación ].

14.4.8.2 FPT_ITI.2.2

La TSF debe ofrecer la posibilidad de verificar la integridad de todos los datos de la TSF transmitidos entre la TSF yotro producto de confianza de TI y realizar [asignación: medidas que deben adoptarse ] si se detectan modificaciones.

14.4.8.3 FPT_ITI.2.3

La TSF debe ofrecer la capacidad para corregir [asignación: tipo de modificación ] de todos los datos TSFtransmitida entre el TSF y otro producto de TI de confianza.

14.5 TOE interna de transferencia de datos TSF (FPT_ITT)


Esta familia proporciona los requisitos que se ocupan de la protección de los datos TSF cuando se transfiere entre separadapartes de un TOE través de un canal interno.


FPT_ITT.1 básico de protección de transferencia de datos TSF interno, requiere que los datos TSF ser protegidos cuando se transmitenentre partes separadas del TOE.

FPT_ITT.2 TSF separación transferencia de datos, requiere que los datos de usuario por separado a partir de datos de TSF TSF durantetransmisión.

FPT_ITT.3 TSF monitoreo de integridad de datos, requiere que los datos TSF transmiten entre partes separadas delTOE es monitoreado por fallos de integridad identificados.

Gestión 14.5.3 de FPT_ITT.1


a) la gestión de los tipos de modificación respecto al cual la TSF debe proteger;

b) la gestión del mecanismo utilizado para proporcionar la protección de los datos en tránsito entre diferentespartes de la TSF.




b) la gestión del mecanismo utilizado para proporcionar la protección de los datos en tránsito entre diferentespartes de la TSF;

c) la gestión del mecanismo de separación.




12/6/2014 ISO / IEC 15408-2



Página 102

ISO / IEC 15408-2:2008 (E)


b) la gestión del mecanismo utilizado para proporcionar la protección de los datos en tránsito entre diferentespartes de la TSF;

c) la gestión de los tipos de modificación de los datos de la TSF TSF debe tratar de detectar;

d) la gestión de la acción> s que se tomará.

14.5.6 Auditoría de FPT_ITT.1, FPT_ITT.2


14.5.7 Auditoría de FPT_ITT.3


a) Mínimo: la detección de la modificación de los datos de TSF;

b) básica: las medidas adoptadas tras la detección de un error de integridad.

14.5.8 FPT_ITT.1 básico de protección de transferencia de datos TSF interna



14.5.8.1 FPT_ITT.1.1

La TSF debe proteger los datos de la TSF [selección: la divulgación, modificación ] cuando se transmiteentre partes separadas del TOE.

14.5.9 FPT_ITT.2 TSF separación de transferencia de datos

Jerárquica para: FPT_ITT.1 básico de protección de transferencia de datos TSF interna


14.5.9.1 FPT_ITT.2.1

La TSF debe proteger los datos de la TSF [selección: la divulgación, modificación ] cuando se transmite entrepartes separadas del TOE.

14.5.9.2 FPT_ITT.2.2

La TSF debe separar los datos del usuario a partir de datos de TSF cuando tales datos se transmiten entre partes separadasdel TOE.

14.5.10 FPT_ITT.3 TSF monitoreo de integridad de datos


Dependencias: FPT_ITT.1 básico de protección de transferencia de datos TSF interna

14.5.10.1 FPT_ITT.3.1

La TSF debe ser capaz de detectar [selección: la modificación de los datos, la sustitución de datos, re-ordenamiento dede datos, la eliminación de datos, [asignación: otros errores de integridad] ] para los datos TSF transmitida entre separadapartes del TOE.

Página 103

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



14.5.10.2 FPT_ITT.3.2

Tras la detección de un error de integridad de los datos, la TSF debe tomar las siguientes medidas: [asignación: especificarla acción a tomar ].

Protección física 14.6 TSF (FPT_PHP)


TSF componentes de protección física se refieren a las restricciones de acceso físico no autorizado a la TSF, y parala disuasión y la resistencia a, la modificación física no autorizado, o la sustitución de la TSF.

Los requisitos de los componentes de esta familia aseguran que el TSF está protegido de la manipulación física yinterferencia. La satisfacción de los requerimientos de estos componentes da como resultado la TSF está envasados y utilizadas ende tal manera que la manipulación física es detectable, o la resistencia a la manipulación indebida física se aplica. Sinestos componentes, las funciones de protección de una TSF pierden su eficacia en entornos en físicael daño no puede ser prevenido. Esta familia también proporciona los requisitos relativos a la forma en la TSF debe responder amanipulación física intentos.


Detección FPT_PHP.1 pasiva de ataque físico, establece las características que indican cuando un dispositivo TSF oElemento TSF está sujeta a la manipulación. Sin embargo, la notificación de la manipulación no es automática; un usuario autorizadodebe invocar una función administrativa de seguridad o llevar a cabo la inspección manual para determinar si la manipulación tieneocurrido.

FPT_PHP.2 Notificación de ataque físico, prevé la notificación automática de manipulación para un determinadosubconjunto de penetraciones físicas.

FPT_PHP.3 Resistencia al ataque físico, p roporciona para las características que previenen o se resisten a la manipulación física conTSF dispositivos y elementos de TSF.

Gestión 14.6.3 de FPT_PHP.1


a) la gestión del usuario o función que determina si se ha producido manipulación física.



a) la gestión del usuario o rol que consigue informado sobre las intrusiones;

b) la gestión de la lista de dispositivos que deben informar al usuario indicado o papel sobre la intrusión.



a) la gestión de las respuestas automáticas a la manipulación física.

14.6.6 Auditoría de FPT_PHP.1


a) Mínimo: si la detección por medios informáticos, detección de intrusión.

Página 104

ISO / IEC 15408-2:2008 (E)



a) Mínimo: detección de intrusión.


12/6/2014 ISO / IEC 15408-2




14.6.9 FPT_PHP.1 detección pasiva de ataque físico



14.6.9.1 FPT_PHP.1.1

La TSF debe proporcionar una detección inequívoca de manipulación física que pudiera comprometer la TSF.

14.6.9.2 FPT_PHP.1.2

La TSF debe ofrecer la posibilidad de determinar si la manipulación física de los dispositivos de la TSFo se ha producido elementos de la TSF.

14.6.10 FPT_PHP.2 Notificación de ataque físico

Jerárquica para: Detección FPT_PHP.1 pasiva de ataque físico

Dependencias: Gestión FMT_MOF.1 de funciones de seguridad comportamiento

14.6.10.1 FPT_PHP.2.1

La TSF debe proporcionar una detección inequívoca de manipulación física que pudiera comprometer la TSF.

14.6.10.2 FPT_PHP.2.2

La TSF debe ofrecer la posibilidad de determinar si la manipulación física de los dispositivos de la TSF TSF o dese ha producido elementos.

14.6.10.3 FPT_PHP.2.3

Para [asignación: se requiere la lista de dispositivos / TSF elementos para los que la detección activa ], la TSF debemonitorizar los dispositivos y elementos y notificar [asignación: un usuario o rol designado ] cuando físicamanipulación de los dispositivos de la TSF o elementos de la TSF ha ocurrido.

14.6.11 FPT_PHP.3 Resistencia a la agresión física



14.6.11.1 FPT_PHP.3.1

La TSF debe resistir [asignación: escenarios de manipulación física ] a la [asignación: lista de TSFdispositivos / elementos ] respondiendo tal forma automática que las SFR siempre se hacen cumplir.

Página 105

ISO / IEC 15408-2:2008 (E)

14.7 recuperación de confianza (FPT_RCV)


Los requisitos de esta familia aseguran que el TSF puede determinar que el TOE se pone en marcha sincompromiso de protección y puede recuperar sin la protección de compromiso después de la discontinuidad de las operaciones. Estela familia es importante porque el estado de puesta en marcha de la TSF determina la protección de los estados siguientes.


FPT_RCV.1 Manual de recuperación, un llows un dedo del pie para proporcionar sólo los mecanismos que implican la intervención humana paravolver a un estado seguro.

Recuperación FPT_RCV.2 automatizado, Pro proporciona, para al menos un tipo de discontinuidad del servicio, la recuperación a un seguroEstado sin intervención humana; recuperación para otras discontinuidades puede requerir intervención humana.

Recuperación FPT_RCV.3 automatizada y sin pérdida indebida, un lso prevé la recuperación automatizada, pero fortalecelos requisitos de no permitir la pérdida indebida de bienes protegidos.

Recuperación de la función FPT_RCV.4, p roporciona para la recuperación en el nivel de funciones particulares, asegurando ya seacompletar con éxito o rollback de los datos TSF a un estado seguro.

12/6/2014 ISO / IEC 15408-2



Gestión 14.7.3 de FPT_RCV.1


a) Gestión de quién puede tener acceso a la capacidad de restaurar en el modo de mantenimiento.

Gestión 14.7.4 de FPT_RCV.2, FPT_RCV.3


a) Gestión de quién puede tener acceso a la capacidad de restaurar en el modo de mantenimiento;

b) la gestión de la lista de discontinuidades fracasos / servicios que se manejan a través de la automáticaprocedimientos.

Gestión 14.7.5 de FPT_RCV.4


14.7.6 Auditoría de FPT_RCV.1, FPT_RCV.2, FPT_RCV.3


a) Mínimo: el hecho de que se produjo un error o servicio discontinuidad;

b) Minimal: reanudación de la aplicación regular;

c) básica: tipo de falla o servicio discontinuidad.

14.7.7 Auditoría de FPT_RCV.4


a) Mínimo: si es posible, la imposibilidad de volver a un estado seguro después de un fallo de la TSF;

Página 106

ISO / IEC 15408-2:2008 (E)

b) básica: si es posible, la detección de un fallo de una función.

14.7.8 FPT_RCV.1 Manual de recuperación


Dependencias: AGD_OPE.1 guía de usuario Operacional

14.7.8.1 FPT_RCV.1.1

Después de [asignación: lista de fallos / discontinuidades de servicios ] la TSF pasará a un modo de mantenimientodonde se ofrece la posibilidad de volver a un estado seguro.

Recuperación 14.7.9 FPT_RCV.2 Automatizado

Jerárquico de: FPT_RCV.1 Manual de recuperación


14.7.9.1 FPT_RCV.2.1

Cuando la recuperación automatizada de [asignación: lista de discontinuidades fallas / Servicio ] no es posible, la TSFpasará a un modo de mantenimiento en el que se proporciona la posibilidad de volver a un estado seguro.

14.7.9.2 FPT_RCV.2.2

Para [asignación: lista de discontinuidades fallas / Servicio ], la TSF debe garantizar el retorno de la TOEun estado seguro mediante procedimientos automatizados.

07/14/10 FPT_RCV.3 recuperación automatizada y sin pérdida indebida

Jerárquico de: recuperación FPT_RCV.2 Automatizado

12/6/2014 ISO / IEC 15408-2




14.7.10.1 FPT_RCV.3.1

Cuando la recuperación automatizada de [asignación: lista de discontinuidades fallas / Servicio ] no es posible, la TSFpasará a un modo de mantenimiento en el que se proporciona la posibilidad de volver a un estado seguro.

14.7.10.2 FPT_RCV.3.2

Para [asignación: lista de discontinuidades fallas / Servicio ], la TSF debe garantizar el retorno de la TOE a un seguroestado utilizando procedimientos automatizados.

14.7.10.3 FPT_RCV.3.3

Las funciones proporcionadas por la TSF para recuperarse de un fallo o discontinuidad del servicio se asegurarán de queel estado inicial seguro que se restablezca sin exceder [asignación: cuantificación ] por la pérdida de datos de TSFu objetos bajo el control de la TSF.

14.7.10.4 FPT_RCV.3.4

La TSF debe ofrecer la capacidad para determinar los objetos que fueron o no fueron capaces de serrecuperado.

Página 107

ISO / IEC 15408-2:2008 (E)

14.7.11 recuperación FPT_RCV.4 Función



14.7.11.1 FPT_RCV.4.1

La TSF debe garantizar que [asignación: lista de funciones y situaciones de fallo ] tienen la propiedad de quela función o bien se realiza correctamente, o para los escenarios de fallo indicados, se recupera a unestado consistente y seguro.

14.8 Detección Replay (FPT_RPL)


Esta familia se ocupa de la detección de la repetición de varios tipos de entidades (por ejemplo, los mensajes, las solicitudes de servicio,respuestas de servicio) y las acciones posteriores para corregir. En el caso en el que la repetición puede ser detectada, esteefectivamente lo impide.


La familia se compone de un solo componente, detección FPT_RPL.1 Replay, que exige que la TSF debeser capaz de detectar la repetición de las entidades identificadas.

Gestión 14.8.3 de FPT_RPL.1


a) la gestión de la lista de entidades identificadas para los que se detectó la repetición;

b) la gestión de la lista de acciones que se deben tomar en caso de repetición.

14.8.4 Auditoría de FPT_RPL.1


ataques de repetición detectadas: a) Basic.

b) detallada: Acciones a tomar en base a las acciones específicas.

14.8.5 Detección FPT_RPL.1 Replay

12/6/2014 ISO / IEC 15408-2





14.8.5.1 FPT_RPL.1.1

La TSF debe detectar la repetición de las siguientes entidades: [asignación: lista de entidades identificadas ].

14.8.5.2 FPT_RPL.1.2

La TSF debe realizar [asignación: lista de acciones específicas ] cuando se detecta replay.

Página 108

ISO / IEC 15408-2:2008 (E)

Protocolo sincronía 14.9 Estado (FPT_SSP)


TOE distribuidos pueden dar lugar a una mayor complejidad de las TOE monolíticos a través de la posibilidad dediferencias en el estado entre partes del TOE, y por medio de los retrasos en la comunicación. En la mayoría de los casossincronización de estado entre las funciones distribuidas implica un protocolo de intercambio, no una simple acción.Cuando existe malicia en el entorno distribuido de estos protocolos, los protocolos defensivas son más complejosrequerida.

Protocolo de sincronía Estado (FPT_SSP) es tablece la obligación para ciertas funciones críticas de la TSF parautilizar este protocolo de confianza . Protocolo de sincronía Estado (FPT_SSP) asegura que dos partes distribuidas de la TOE(Por ejemplo, los ejércitos) han sincronizado sus estados después de una acción relevante para la seguridad.


FPT_SSP.1 reconocimiento confianza simple, re requiere sólo un simple reconocimiento por parte del receptor de datos.

Reconocimiento mutuo de confianza FPT_SSP.2, r equiere reconocimiento mutuo del intercambio de datos.

Gestión 14.9.3 de FPT_SSP.1, FPT_SSP.2


14.9.4 Auditoría de FPT_SSP.1, FPT_SSP.2


a) Mínimo: falta de recepción de un acuse de recibo cuando se espera.

14.9.5 FPT_SSP.1 reconocimiento confianza simple



14.9.5.1 FPT_SSP.1.1

La TSF debe reconocer, a petición de otra parte de la TSF, la recepción de un sin modificarLa transmisión de datos TSF.

Reconocimiento mutuo de confianza 14.9.6 FPT_SSP.2

Jerárquica para: FPT_SSP.1 reconocimiento confianza simple


14.9.6.1 FPT_SSP.2.1

La TSF debe reconocer, a petición de otra parte de la TSF, la recepción de una TSF sin modificarla transmisión de datos.

14.9.6.2 FPT_SSP.2.2

La TSF debe garantizar que las partes pertinentes de la TSF saben el estado correcto de los datos transmitidos

12/6/2014 ISO / IEC 15408-2



entre sus diferentes partes, con agradecimientos.

Página 109

ISO / IEC 15408-2:2008 (E)


14.10 Las marcas de tiempo (FPT_STM)


Esta familia se ocupa de los requisitos para una función de sello de tiempo de confianza dentro de una TOE.


Esta familia se compone de un solo componente, FPT_STM.1 marcas de tiempo fiable, que requiere que el TSFproporcionar marcas de tiempo fiables para las funciones de TSF.

14.10.3 Gestión de FPT_STM.1


a) la gestión del tiempo.

14.10.4 Auditoría de FPT_STM.1


a) Mínimos: cambios en el tiempo.

b) detallada: proporcionar una indicación de la hora.

14.10.5 FPT_STM.1 marcas de tiempo fiables



14.10.5.1 FPT_STM.1.1

La TSF debe ser capaz de proporcionar marcas de tiempo fiables.

14.11 consistencia de los datos entre TSF TSF (FPT_TDC)


En un entorno distribuido, una TOE puede necesitar para intercambiar datos de TSF (por ejemplo, los SFP-atributos asociados conde datos, la información de auditoría, la información de identificación) con otro producto de TI confiable, Esta familia define elrequisitos para el intercambio y la interpretación uniforme de estos atributos entre la TSF del TOE y unadiferentes productos de TI de confianza.


FPT_TDC.1 Inter-TSF coherencia básica de datos TSF, r equiere que el TSF proporcionan la capacidad para asegurarconsistencia de atributos entre TSF.

14.11.3 Gestión de FPT_TDC.1


14.11.4 Auditoría de FPT_TDC.1


Página 110

12/6/2014 ISO / IEC 15408-2


ISO / IEC 15408-2:2008 (E)


a) Mínimo: El uso exitoso de TSF mecanismos de consistencia de datos.

b) Básico: El uso de los mecanismos de coherencia de datos de TSF.

c) básica: Identificación de los cuales los datos de TSF se han interpretado.

d) básica: Detección de datos TSF modificados.

14.11.5 FPT_TDC.1 Inter-TSF TSF consistencia de los datos básicos



14.11.5.1 FPT_TDC.1.1

La TSF debe ofrecer la capacidad de interpretar constantemente [asignación: lista de tipos de datos de la TSF ] cuandocompartida entre la TSF y otro producto de TI de confianza.

14.11.5.2 FPT_TDC.1.2

La TSF debe utilizar [asignación: lista de reglas de interpretación que deben aplicar la TSF ] al interpretarlos datos de TSF de otro producto de TI de confianza.

14.12 Prueba de entidades externas (FPT_TEE)


Esta familia define requisitos para la TSF para llevar a cabo pruebas en una o más entidades externas.

Este componente no está destinado a ser aplicado a los usuarios humanos.

Las entidades externas pueden incluir aplicaciones que se ejecutan en el TOE, hardware o software que se ejecuta "por debajo" de laTOE (plataformas, sistemas operativos, etc) o aplicaciones / cajas conectadas a la TOE (detección de intrusossistemas, cortafuegos, servidores de acceso, servidores de tiempo etc.)


Pruebas FPT_TEE.1 de entidades externas, ofrece para las pruebas de las entidades externas por el TSF.

14.12.3 Gestión de FPT_TEE.1


a) la gestión de las condiciones bajo las que se produce la prueba de entidades externas, como durante la formación inicialpuesta en marcha, el intervalo regular, o bajo condiciones específicas;

b) La gestión del intervalo de tiempo en su caso.

14.12.4 Auditoría de FPT_TEE.1


a) básica: Ejecución de las pruebas de las entidades externas y los resultados de las pruebas.

14.12.5 Prueba FPT_TEE.1 de entidades externas


Página 111

ISO / IEC 15408-2:2008 (E)


14.12.5.1 FPT_TEE.1.1

La TSF debe ejecutar una serie de pruebas [selección: durante la primera puesta en marcha, periódicamente durante el funcionamiento normaloperación, a solicitud de un usuario autorizado, [asignación: otras condiciones] ] para comprobar lacumplimiento de [asignación: lista de propiedades de las entidades externas ].

12/6/2014 ISO / IEC 15408-2



14.12.5.2 FPT_TEE.1.2

Si la prueba falla, la TSF debe [asignación: la acción (s) ].

14.13 TSF TOE interna coherencia de replicación de datos (FPT_TRC)


Se necesitan los requisitos de esta familia para garantizar la coherencia de los datos TSF cuando tales datos sonreplicado interna a la TOE. Tales datos pueden ser incompatibles si el canal interno entre las partes de laTOE deja de funcionar. Si el TOE se estructura internamente como una red y las partes de la red TOEconexiones se rompen, esto puede ocurrir cuando las piezas se convierten en discapacitados.


Esta familia se compone de un solo componente, FPT_TRC.1 TSF interna consistencia, que exige que laTSF garantizar la coherencia de los datos TSF que se replica en varios lugares.

14.13.3 Gestión de FPT_TRC.1


14.13.4 Auditoría de FPT_TRC.1


a) Mínimo: restaurar la consistencia después de la reconexión.

b) básica: inconsistencia detectada entre los datos de la TSF.

14.13.5 FPT_TRC.1 TSF interna consistencia



14.13.5.1 FPT_TRC.1.1

La TSF debe garantizar que los datos TSF es consistente cuando se replican entre partes del TOE.

14.13.5.2 FPT_TRC.1.2

Cuando se desconectan partes del TOE que contiene datos de TSF replicados, la TSF debe garantizar lala consistencia de los datos TSF replicados al volver a conectarse antes de procesar cualquier solicitud de[Asignación: lista de las funciones que dependen de la replicación de datos TSF consistencia ].

Página 112

ISO / IEC 15408-2:2008 (E)

Autotest 14.14 TSF (FPT_TST)


La familia define los requisitos para el autodiagnóstico de la TSF respecto de algunos correcta esperadaoperación. Ejemplos son interfaces para las funciones de aplicación, y las operaciones aritméticas de ejemplo en críticopartes del TOE. Estas pruebas se pueden realizar en la puesta en marcha, periódicamente, a petición del usuario autorizado,o cuando se cumplen otras condiciones. Las acciones a ser tomadas por el TOE como el resultado de las pruebas de auto se definenen otras familias.

También son necesarios los requisitos de esta familia para detectar la corrupción de los datos TSF TSF y sí (es decir, TSFcódigo ejecutable o TSF componente de hardware) por diversas fallas que no se detienen necesariamente del TOEoperación (que sería manejado por otras familias). Estos controles deben ser realizados debido a que estosfallas pueden no necesariamente ser prevenidos. Tales fallas pueden ocurrir ya sea debido a un fallo imprevistomodos o descuidos asociados en el diseño de hardware, firmware o software, o por la maliciosacorrupción de la TSF debido a la protección lógica y / o física inadecuada.


12/6/2014 ISO / IEC 15408-2



Pruebas TSF FPT_TST.1, ofrece la posibilidad de probar el correcto funcionamiento de la TSF. Estas pruebas pueden serrealizado en la puesta en marcha, periódicamente, a petición del usuario autorizado, o cuando se cumplan otras condiciones. LoTambién ofrece la posibilidad de verificar la integridad de los datos de la TSF y la propia TSF.

14.14.3 Gestión de FPT_TST.1


a) la gestión de las condiciones bajo las que se produce la prueba de auto TSF, como en la primera puesta en marcha, regularintervalo, o bajo condiciones específicas;

b) La gestión del intervalo de tiempo en su caso.

14.14.4 Auditoría de FPT_TST.1


a) básica: Ejecución de las pruebas de auto TSF y los resultados de las pruebas.

Pruebas TSF 14.14.5 FPT_TST.1



14.14.5.1 FPT_TST.1.1

La TSF debe ejecutar una serie de pruebas de auto [selección: durante la primera puesta en marcha, periódicamente durante el funcionamiento normaloperación, a petición del usuario autorizado, en las condiciones [asignación: condiciones en las queautotest debe ocurrir] ] para demostrar el correcto funcionamiento de [selección: [asignación: partes de TSF],la TSF ].

14.14.5.2 FPT_TST.1.2

La TSF debe proporcionar a los usuarios autorizados la capacidad de verificar la integridad de [selección:[Asignación: partes de los datos de la TSF], los datos TSF ].

Página 113

ISO / IEC 15408-2:2008 (E)

14.14.5.3 FPT_TST.1.3

La TSF debe proporcionar a los usuarios autorizados la capacidad de verificar la integridad de [selección:[Asignación: partes de TSF], TSF ].

FRU 15 Class: La utilización de recursos

Esta clase proporciona tres familias que apoyan a la disponibilidad de los recursos necesarios, tales como el procesamiento decapacidad y / o capacidad de almacenamiento. La tolerancia a fallos de la familia proporciona protección contra la falta de disponibilidad decapacidades causados por el fallo de la TOE. La prioridad de la familia de servicio asegura que los recursos seránasignado a las tareas más importantes o críticos en el tiempo y no pueden ser monopolizados por tareas de menor prioridad. Lade asignación de recursos de la familia proporciona límites sobre el uso de los recursos disponibles, por lo tanto, evitar que los usuariosmonopolizar los recursos.

Figura 15 - FRU: Recurso clase de utilización de descomposición

15.1 Tolerancia a fallos (FRU_FLT)


12/6/2014 ISO / IEC 15408-2



Los requisitos de esta familia aseguran que el TOE mantendrá un correcto funcionamiento incluso en caso defracasos.


FRU_FLT.1 Degradado de tolerancia a fallos, re requiere la TOE para continuar el funcionamiento correcto de las capacidades identificadasen el caso de los fallos detectados.

Tolerancia a fallos FRU_FLT.2 Limited, requiere que el TOE para continuar el funcionamiento correcto de todas las capacidades en elcaso de los fallos detectados.

15.1.3 Gestión de FRU_FLT.1, FRU_FLT.2


15.1.4 Auditoría de FRU_FLT.1


a) Mínimo: Cualquier fallo detectado por el TSF.

b) básica: Todas las capacidades de TOE se interrumpieron debido a un fallo.

15.1.5 Auditoría de FRU_FLT.2


Página 114

ISO / IEC 15408-2:2008 (E)

a) Mínimo: Cualquier fallo detectado por el TSF.

15.1.6 FRU_FLT.1 tolerancia a fallos degradado


Dependencias: Si no FPT_FLS.1 con preservación de las condiciones de seguridad

15.1.6.1 FRU_FLT.1.1

La TSF debe garantizar el funcionamiento de [asignación: lista de capacidades TOE ] cuando la siguientefracasos ocurren: [asignación: lista de tipo de fallos ].

Tolerancia a fallos 15.1.7 FRU_FLT.2 Limited

Jerárquica para: FRU_FLT.1 tolerancia a fallos degradado

Dependencias: Si no FPT_FLS.1 con preservación de las condiciones de seguridad

15.1.7.1 FRU_FLT.2.1

La TSF debe garantizar el funcionamiento de todas las capacidades de la TOE cuando ocurran los siguientes fallos:[Asignación: lista de tipo de fallos ].

15.2 Prioridad de servicio (FRU_PRS)


Los requisitos de esta familia permiten la TSF para controlar el uso de los recursos bajo el control de la TSF porlos usuarios y los sujetos de tal manera que las actividades de alta prioridad en el marco del control de la TSF siempre se lograránsin interferencia indebida o retraso causado por las actividades de baja prioridad.


FRU_PRS.1 limitada prioridad del servicio, proporciona prioridades para el uso de un sujeto de un subconjunto de los recursosbajo el control de la TSF.

FRU_PRS.2 prioridad completa de servicio, proporciona las prioridades para el uso de un tema de todos los recursos en el marco delcontrol de la TSF.

15.2.3 Gestión de FRU_PRS.1, FRU_PRS.2

12/6/2014 ISO / IEC 15408-2




a) la asignación de prioridades a cada tema en el TSF.

15.2.4 Auditoría de FRU_PRS.1, FRU_PRS.2


a) Mínimo: Rechazo de la operación basado en el uso de prioridad dentro de una asignación.

b) básica: Todos los intentos de usos de la función de asignación que implica la prioridad de las funciones de servicio.

15.2.5 FRU_PRS.1 prioridad limitada de servicio


Página 115

ISO / IEC 15408-2:2008 (E)


15.2.5.1 FRU_PRS.1.1

La TSF debe asignar una prioridad a cada sujeto en el TSF.

15.2.5.2 FRU_PRS.1.2

La TSF debe garantizar que cada acceso a [asignación: controlado recursos ] deberá ser mediado en elbase de los sujetos asignados prioridad.

15.2.6 FRU_PRS.2 prioridad completa de servicio

Jerárquica para: Prioridad FRU_PRS.1 limitada de servicio


15.2.6.1 FRU_PRS.2.1

La TSF debe asignar una prioridad a cada sujeto en el TSF.

15.2.6.2 FRU_PRS.2.2

La TSF debe garantizar que cada acceso a todos los recursos que se pueden compartir , se medió en la base de lalos sujetos asignan prioridad.

15.3 La asignación de recursos (FRU_RSA)


Los requisitos de esta familia permiten la TSF para controlar el uso de recursos por parte de los usuarios y los sujetos de tal manera quedenegación de servicio no se producirá debido a la monopolización no autorizado de recursos.


Cuotas Máximo FRU_RSA.1, p roporciona requisitos para los mecanismos de cuotas que garantizan que los usuarios ylos sujetos no monopolizar un recurso controlado.

FRU_RSA.2 mínimo y cupos máximos, pr ovides requisitos para los mecanismos de cuotas que aseguren quelos usuarios y los sujetos tendrán siempre al menos un mínimo de un recurso especificado y que no serán capacesmonopolizar un recurso controlado.

15.3.3 Gestión de FRU_RSA.1


a) especificar los límites máximos para un recurso para grupos y / o usuarios y / o sujetos individuales por unadministrador.

15.3.4 Gestión de FRU_RSA.2


12/6/2014 ISO / IEC 15408-2



a) especificar los límites máximos para un recurso mínimo y para los grupos y / o usuarios y / o sujetos individualespor un administrador.

Página 116

ISO / IEC 15408-2:2008 (E)


15.3.5 Auditoría de FRU_RSA.1, FRU_RSA.2


a) Mínimo: Rechazo de la operación de asignación debido a los límites de recursos.

b) Básico: Todos los intentos de los usos de las funciones de asignación de recursos para los recursos que se encuentran bajo el control de laTSF.

15.3.6 FRU_RSA.1 cuotas máximas



15.3.6.1 FRU_RSA.1.1

La TSF debe aplicar las cuotas máximas de los siguientes recursos: [asignación: controladorecursos ] que [selección: usuario individual, grupo definido de usuarios, temas ] puede utilizar [selección:al mismo tiempo, durante un período determinado de tiempo ].

15.3.7 FRU_RSA.2 mínimos y cuotas máximas

Jerárquica para: Cuotas Máximo FRU_RSA.1


15.3.7.1 FRU_RSA.2.1

La TSF debe aplicar las cuotas máximas de los siguientes recursos [asignación: control de recursos ] que[Selección: usuario individual, grupo definido de usuarios, temas ] puede utilizar [selección: al mismo tiempo, a través de unaespecificado período de tiempo ].

15.3.7.2 FRU_RSA.2.2

La TSF debe garantizar la prestación de la cantidad mínima de cada [asignación: recurso controlado ]que está disponible para [selección: un usuario individual, grupo definido de usuarios, los sujetos ] para utilizar [selección:al mismo tiempo, durante un período determinado de tiempo ].

12/6/2014 ISO / IEC 15408-2


Página 117

ISO / IEC 15408-2:2008 (E)


16 Clase FTA: acceso TOE

Esta familia se especifican los requisitos funcionales para controlar el establecimiento de la sesión de un usuario.

Figura 16 - FTA: clase de acceso TOE descomposición

16.1 Limitación de alcance de atributos seleccionables (FTA_LSA)


Esta familia define requisitos para limitar el alcance de la sesión de los atributos de seguridad que un usuario puede seleccionar para unasesión.


FTA_LSA.1 limitación en el alcance de atributos seleccionables, proporciona el requisito de un TOE limitar el alcancede la sesión de los atributos de seguridad durante el establecimiento de la sesión.

Gestión 16.1.3 de FTA_LSA.1


a) La gestión del alcance de la seguridad de sesión atribuye por un administrador.

16.1.4 Auditoría de FTA_LSA.1


a) Mínimo: Todos intentos fallido de la selección de un atributo de seguridad de sesión.

b) Básico: Todos los intentos de la selección de un atributo de seguridad de sesión.

c) detallada: Captura de los valores de cada uno los atributos de seguridad de sesión.

Página 118

ISO / IEC 15408-2:2008 (E)

16.1.5 FTA_LSA.1 Limitación en el alcance de atributos seleccionables



12/6/2014 ISO / IEC 15408-2



16.1.5.1 FTA_LSA.1.1

La TSF debe restringir el alcance de los atributos de seguridad de sesión [asignación: seguridad de sesiónatributos ], sobre la base de [asignación: atributos ].

16.2 Limitación de las múltiples sesiones concurrentes (FTA_MCS)


Esta familia define requisitos para colocar límites en el número de sesiones simultáneas que pertenecen a la mismade usuario.


FTA_MCS.1 limitación básica en varias sesiones simultáneas, pr ovides limitaciones que se aplican a todos los usuarios de laTSF.

FTA_MCS.2 Por limitación de atributos de usuario en múltiples concurrentes sesión s extiende limitación FTA_MCS.1 básicoen varias sesiones simultáneas , al exigir la posibilidad de especificar las limitaciones sobre el número de concurrentessesiones sobre la base de los atributos de seguridad relacionados.

Gestión 16.2.3 de FTA_MCS.1


a) la gestión del número máximo permitido de las sesiones de usuario simultáneas por un administrador.

Gestión 16.2.4 de FTA_MCS.2


a) la gestión de las reglas que rigen el número máximo permitido de las sesiones de usuario simultáneas por unadministrador.

16.2.5 Auditoría de FTA_MCS.1, FTA_MCS.2


a) Mínimo: Rechazo de una nueva sesión basada en la limitación de las múltiples sesiones concurrentes.

b) detallada: Captura del número de sesiones de usuario concurrentes actualmente y el atributo (s) de seguridad del usuario.

16.2.6 FTA_MCS.1 limitación básica en varias sesiones simultáneas



16.2.6.1 FTA_MCS.1.1

La TSF debe restringir el número máximo de sesiones simultáneas que pertenecen al mismo usuario.

Página 119

ISO / IEC 15408-2:2008 (E)

16.2.6.2 FTA_MCS.1.2

La TSF debe aplicar, por defecto, un límite de [asignación: número por defecto ] sesiones por usuario.

16.2.7 FTA_MCS.2 Por usuario atributo limitación en varias sesiones simultáneas

Jerárquica para: FTA_MCS.1 limitación básica en varias sesiones simultáneas


16.2.7.1 FTA_MCS.2.1

La TSF debe restringir el número máximo de sesiones simultáneas que pertenecen al mismo usuario segúna las reglas [asignación: reglas para el número de sesiones simultáneas máximas ].

16.2.7.2 FTA_MCS.2.2

12/6/2014 ISO / IEC 15408-2



La TSF debe aplicar, por defecto, un límite de [asignación: número por defecto ] sesiones por usuario.

Bloqueo 16,3 y finalización de sesión (FTA_SSL)


Esta familia define requisitos para la TSF para proporcionar la capacidad de TSF-iniciado y promovido por el usuariobloqueo, desbloqueo, y la terminación de las sesiones interactivas.


Cierre la sesión iniciada por el TSF FTA_SSL.1 en sistema incluye iniciará el bloqueo de una sesión interactiva después de unespecificado período de inactividad del usuario.

FTA_SSL.2 de bloqueo iniciada por el usuario, proporciona capacidades para el usuario para bloquear y desbloquear propia del usuariosesiones interactivas.

Terminación iniciada por TSF FTA_SSL.3, proporciona los requisitos para la TSF para terminar la sesión después de unespecificado período de inactividad del usuario.

FTA_SSL.4 terminación iniciada por el usuario, p roporciona capacidades para el usuario de rescindir el usuario del propio interactivosesiones.

Gestión 16.3.3 de FTA_SSL.1


a) especificación del tiempo de inactividad tras el cual se produce bloqueo de un usuario individual;

b) especificación de la hora predeterminada de inactividad después del cual se produce bloqueo;

c) la gestión de los eventos que deben ocurrir antes de desbloquear la sesión.



a) la gestión de los eventos que deben ocurrir antes de desbloquear la sesión.



Página 120

ISO / IEC 15408-2:2008 (E)

a) especificación del tiempo de inactividad del usuario después de que la terminación de la sesión interactiva se produce unausuario individual;

b) especificación de la hora predeterminada de inactividad después del cual se produce la terminación de la sesión interactiva.



16.3.7 Auditoría de FTA_SSL.1, FTA_SSL.2


a) Mínimo: Bloqueo de una sesión interactiva con el mecanismo de cierre de sesión.

b) Minimal: Successful desbloqueo de una sesión interactiva.

c) básica: Cualquier intento de desbloquear una sesión interactiva.

16.3.8 Auditoría de FTA_SSL.3


a) Mínimo: Terminación de una sesión interactiva con el mecanismo de cierre de sesión.

16.3.9 Auditoría de FTA_SSL.4

12/6/2014 ISO / IEC 15408-2




a) Mínimo: Terminación de una sesión interactiva por el usuario.

Cierre la sesión iniciada por el TSF 16.3.10 FTA_SSL.1



16.3.10.1 FTA_SSL.1.1

La TSF debe bloquear una sesión interactiva después de [asignación: intervalo de tiempo de inactividad del usuario ] a través de:

a) compensación o sobrescribir los dispositivos de visualización, por lo que el contenido actual ilegible;

b) que impide cualquier actividad de los dispositivos de acceso a datos / pantalla del usuario se aparte de abrir la sesión.

16.3.10.2 FTA_SSL.1.2

La TSF debe exigir a los siguientes eventos que se produzcan antes de abrir la sesión: [asignación:eventos que ocurran ].

16.3.11 FTA_SSL.2 bloqueo iniciado por el usuario



Página 121

ISO / IEC 15408-2:2008 (E)

16.3.11.1 FTA_SSL.2.1

La TSF debe permitir bloqueo iniciado por el usuario de la propia sesión interactiva del usuario, a través de:

a) compensación o sobrescribir los dispositivos de visualización, por lo que el contenido actual ilegible;

b) que impide cualquier actividad de los dispositivos de acceso a datos / pantalla del usuario se aparte de abrir la sesión.

16.3.11.2 FTA_SSL.2.2

La TSF debe exigir a los siguientes eventos que se produzcan antes de abrir la sesión: [asignación:eventos que ocurran ].

Terminación TSF-iniciado 16/03/12 FTA_SSL.3



16.3.12.1 FTA_SSL.3.1

La TSF debe terminar una sesión interactiva después de un [asignación: intervalo de tiempo de inactividad del usuario ].

03/16/13 FTA_SSL.4 terminación iniciada por el usuario



16.3.13.1 FTA_SSL.4.1

La TSF debe permitir la terminación iniciada por el usuario de la propia sesión interactiva del usuario.

16.4 banners de acceso TOE (FTA_TAB)


Esta familia define requisitos para mostrar un mensaje de advertencia configurable asesoramiento a los usuarios en cuanto a lauso adecuado del TOE.

12/6/2014 ISO / IEC 15408-2




FTA_TAB.1 acceso predeterminados TOE banners, p roporciona el requisito de un TOE Acceso Banner. Esta bandera esaparece antes del establecimiento del diálogo para una sesión.

Gestión 16.4.3 de FTA_TAB.1


a) el mantenimiento de la bandera por el administrador autorizado.

16.4.4 Auditoría de FTA_TAB.1


16.4.5 FTA_TAB.1 Defecto banners de acceso TOE



Página 122

ISO / IEC 15408-2:2008 (E)

16.4.5.1 FTA_TAB.1.1

Antes de establecer una sesión de usuario, la TSF debe mostrar un mensaje de advertencia consultiva sobreuso no autorizado de la TOE.

16.5 historial de acceso TOE (FTA_TAH)


Esta familia define requisitos para la TSF para mostrar a un usuario, al establecimiento de sesión exitoso, unhistoria de los intentos exitosos y fallidos de acceso a la cuenta del usuario.


FTA_TAH.1 historial de acceso TOE, pr ovides el requisito de un TOE para ver la información relacionada con la anteriorlos intentos de establecer una sesión.

Gestión 16.5.3 de FTA_TAH.1


16.5.4 Auditoría de FTA_TAH.1


16.5.5 historia FTA_TAH.1 acceso TOE



16.5.5.1 FTA_TAH.1.1

Una vez establecida la sesión con éxito, la TSF debe mostrar la [selección: fecha, hora y método,ubicación ] del último establecimiento de sesión con éxito para el usuario.

16.5.5.2 FTA_TAH.1.2

Una vez establecida la sesión con éxito, la TSF debe mostrar la [selección: fecha, hora y método,ubicación ] del último intento fallido de establecimiento de la sesión y el número de éxitolos intentos desde el último período de sesiones establecimiento exitoso.

16.5.5.3 FTA_TAH.1.3

El TSF no hará que desaparezca la información del historial de acceso desde la interfaz de usuario sin dar al usuariouna oportunidad para revisar la información.

Establecimiento de la sesión 16.6 TOE (FTA_TSE)


12/6/2014 ISO / IEC 15408-2



Esta familia define requisitos para denegar un permiso de usuario para establecer una sesión con el TOE.


Establecimiento FTA_TSE.1 sesión TOE, establece los requisitos para denegar a los usuarios el acceso a la TOE basadaen atributos.

Página 123

ISO / IEC 15408-2:2008 (E)


Gestión 16.6.3 de FTA_TSE.1


a) la gestión de las condiciones de establecimiento de la sesión por el administrador autorizado.

16.6.4 Auditoría de FTA_TSE.1


a) Mínimo: Denegación de un establecimiento de la sesión debido al mecanismo de establecimiento de la sesión.

b) Básico: Todos los intentos de establecimiento de una sesión de usuario.

c) detallada: Captura del valor de los parámetros de acceso seleccionados (por ejemplo, la ubicación de acceso, tiempo dede acceso).

16.6.5 establecimiento de sesión FTA_TSE.1 TOE



16.6.5.1 FTA_TSE.1.1

La TSF debe ser capaz de negar el establecimiento de sesión basado en [asignación: atributos ].

17 Clase FTP: Trusted ruta / canales

Las familias de esta clase se especifican los requisitos para una ruta de comunicación de confianza entre los usuarios y la TSF, ypara un canal de comunicación confiable entre la TSF y otros productos de TI de confianza. Caminos y de confianzacanales tienen las siguientes características generales:

• El camino de comunicaciones se construye utilizando los canales de comunicación internos y externos (comoapropiado para el componente) que aislar un subconjunto identificado de los datos de la TSF y los comandos delresto de la TSF y datos de usuario.

• El uso de la vía de comunicación puede ser iniciado por el usuario y / o la TSF (según corresponda a lacomponente).

• El camino de comunicaciones es capaz de proporcionar la seguridad de que el usuario se está comunicando con lacorrecta TSF, y que la TSF se está comunicando con el usuario correcto (según sea apropiado para el componente).

En este paradigma, un canal de confianza es un canal de comunicación que puede ser iniciado por cualquier lado de lacanal, y proporciona características de no repudio con respecto a la identidad de los lados del canal.

Una ruta de confianza proporciona un medio para que los usuarios realizar funciones a través de una interacción directa con el seguroTSF. Ruta de confianza es generalmente deseable para las acciones del usuario, como la identificación y / o autenticación inicial, peroTambién puede ser deseable en otros momentos durante la sesión de un usuario. Intercambios ruta de confianza pueden ser iniciados por un usuarioo la TSF. Las respuestas de los usuarios a través de la ruta de confianza están garantizados para estar protegidos frente a posibles modificaciones por odivulgación de las aplicaciones son de confianza.

12/6/2014 ISO / IEC 15408-2


Página 124

ISO / IEC 15408-2:2008 (E)


Figura 17 - FTP: Trusted ruta / canales clase descomposición

17.1 Inter-TSF canal de confianza (FTP_ITC)


Esta familia define requisitos para la creación de un canal de confianza entre la TSF y otros confiaron en TIproductos para el desempeño de las operaciones críticas de seguridad. Esta familia debe incluirse siempre que hayarequisitos para la comunicación segura de datos de usuario o TSF entre la punta y el otro de confianza de TIproductos.


FTP_ITC.1 Inter-TSF canal de confianza, requiere que el TSF proporciona un canal de comunicación de confianzaentre el mismo y otro producto de TI de confianza.

Gestión 17.1.3 de FTP_ITC.1


a) Configuración de las acciones que requieren de canal de confianza, si es compatible.

17.1.4 Auditoría de FTP_ITC.1


a) Mínimo: Fracaso de las funciones de canal de confianza.

b) Minimal: Identificación del iniciador y el destino de funciones de canal de confianza que han fallado.

c) básica: Todas las tentativas de los usos de las funciones de canal de confianza.

d) Básico: Identificación del iniciador y el destino de todas las funciones de canal de confianza.

17.1.5 FTP_ITC.1 Inter-TSF confiaba canal



17.1.5.1 FTP_ITC.1.1

La TSF debe proporcionar un canal de comunicación entre él y otro producto de TI de confianza que eslógicamente distinto de otros canales de comunicación y proporciona la identificación segura de su finpuntos y la protección de los datos del canal de modificación o divulgación.

Página 125

ISO / IEC 15408-2:2008 (E)

17.1.5.2 FTP_ITC.1.2

La TSF debe permitir a [selección: la TSF, otro producto de TI de confianza ] para iniciar la comunicación a través de la

12/6/2014 ISO / IEC 15408-2



canal de confianza.

17.1.5.3 FTP_ITC.1.3

La TSF debe iniciar la comunicación a través del canal de confianza para [asignación: lista de funciones paraque se requiere un canal de confianza ].

17.2 ruta segura (FTP_TRP)


Esta familia define los requisitos para establecer y mantener una comunicación de confianza para o de los usuarios y laTSF. Una ruta de confianza puede ser requerida por cualquier interacción relevante para la seguridad. Intercambios ruta de confianza pueden seriniciado por un usuario durante una interacción con el TSF, o la TSF puede establecer la comunicación con el usuarioa través de una ruta de confianza.


Ruta FTP_TRP.1 confianza, r equiere que se proporcione una ruta de confianza entre la TSF y un usuario para un conjunto deeventos definidos por un autor PP / ST. El usuario y / o la TSF pueden tener la capacidad de iniciar la ruta de confianza.

Gestión 17.2.3 de FTP_TRP.1


a) Configuración de las acciones que requieren ruta de confianza, si es compatible.

17.2.4 Auditoría de FTP_TRP.1


a) Mínimos: Fallas de los tipos de trayectoria de confianza.

b) Minimal: Identificación del usuario asociado a todas las fallas de ruta de confianza, si está disponible.

c) básica: Todas las tentativas de los usos de las funciones de trayectoria de confianza.

d) Básico: Identificación del usuario asociado a todas las invocaciones de ruta de confianza, si está disponible.

17.2.5 camino FTP_TRP.1 Trusted



17.2.5.1 FTP_TRP.1.1

La TSF debe proporcionar una ruta de comunicación entre él y [selección: remotos, locales ] usuarios, esto eslógicamente distinta de otras vías de comunicación y proporciona la identificación segura de su finpuntos y la protección de los datos comunicados de [selección: modificaciones, divulgación,[Asignación: otros tipos de integridad o violación de confidencialidad] ].

Página 126

ISO / IEC 15408-2:2008 (E)

17.2.5.2 FTP_TRP.1.2

La TSF debe permitir a [selección: la TSF, los usuarios locales, usuarios remotos ] para iniciar la comunicación a través de laruta de confianza.

17.2.5.3 FTP_TRP.1.3

La TSF debe exigir la utilización de la vía de confianza para [selección: la autenticación de usuario inicial,[Asignación: Se requiere otros servicios para los que confiaron en ruta] ].

12/6/2014 ISO / IEC 15408-2



Página 127

ISO / IEC 15408-2:2008 (E)

Anexo A

(Normativo)

Notas de seguridad los requisitos funcionales de la aplicación

Este anexo contiene orientaciones adicionales para las familias y los componentes definidos en los elementos de esta partede la norma ISO / IEC 15408, que pueda ser requerida por los usuarios, desarrolladores o evaluadores para utilizar los componentes. Afacilitar la búsqueda de la información adecuada, la presentación de las clases, las familias y los componentes de esteanexo es similar a la presentación dentro de los elementos.

Estructura de las notas A.1

Esta cláusula define el contenido y la presentación de las notas relacionadas con los requisitos funcionales deISO / IEC 15408.

Estructura A.1.1 Clase

Figura A.1 b elow ilustra la estructura de la clase funcional en este anexo.

12/6/2014 ISO / IEC 15408-2



Figura A.1 - estructura de clase funcional

Nombre A.1.1.1 Clase

Este es el nombre único de la clase definida dentro de los elementos normativos de esta parte de la norma ISO / IEC 15408.

Introducción A.1.1.2 Clase

La introducción de clases en este anexo se ofrece información sobre el uso de las familias y los componentes de laclase. Esta información se completa con el diagrama informativo que describe la organización de cada clasecon las familias de cada clase y la relación jerárquica entre los componentes de cada familia.

Página 128

ISO / IEC 15408-2:2008 (E)

Estructura A.1.2 Familia

Figura A.2 ilustra la estructura familiar funcional para notas de aplicación en forma de diagrama.

Figura A.2 - estructura familiar funcional para notas de aplicación

Nombre A.1.2.1 Familia

Este es el nombre único de la familia se define dentro de los elementos normativos de esta parte de la norma ISO / IEC 15408.

A.1.2.2 notas de usuario

Las notas de usuario contienen información adicional que sea de interés para los usuarios potenciales de la familia, es decir PP, STy los autores de paquetes funcionales, y los desarrolladores de las TOE que incorporan los componentes funcionales. Lapresentación es informativa, y podría cubrir las advertencias acerca de las limitaciones de uso y las zonas donde específicapuede ser necesaria la atención cuando se utilizan los componentes.

Notas A.1.2.3 Evaluador

Las notas evaluador contienen ninguna información que sea de interés para los desarrolladores y evaluadores de las TOE que la reclamaciónel cumplimiento de un componente de la familia. La presentación es de carácter informativo y puede cubrir una variedad de áreasdonde podría ser necesaria una atención especial en la evaluación de la TOE. Esto puede incluir aclaraciones del significadoy la especificación de la forma de interpretar los requisitos, así como advertencias y avisos de interés específico para

12/6/2014 ISO / IEC 15408-2



evaluadores.Estas notas de usuario y evaluador Notas subcláusulas no son obligatorios y aparecen sólo si es apropiado.

Página 129

ISO / IEC 15408-2:2008 (E)

Estructura A.1.3 Componente

Figura A.3 ilustra la estructura de componentes funcionales para las notas de aplicación.

Figura A.3 - estructura de componentes funcionales

A.1.3.1 identificación de componentes

Este es el nombre exclusivo del componente definido dentro de los elementos normativos de esta parte de la norma ISO / IEC15408.

A.1.3.2 Componentes fundamento y la aplicación Notas

Cualquier información específica relacionada con el componente se puede encontrar en esta subcláusula.

• La justificación contiene los detalles de las razones que refinan las declaraciones generales sobre justificación de lanivel específico, y sólo se debe utilizar si se requiere la amplificación específica de grado.

• Las notas de aplicación contienen refinamiento adicional en términos de calificación de la narrativa en lo que respecta a unacomponente específico. Este refinamiento puede pertenecer a las notas de usuarios y / o notas evaluador como se describe enA.1.2. Este refinamiento se puede utilizar para explicar la naturaleza de las dependencias (por ejemplo, información compartida, ooperación compartida).

Este numeral no es obligatorio y sólo aparece si es apropiado.

A.1.3.3 operaciones permitidas

Esta porción de cada componente contiene asesoramiento en relación con las operaciones permitidas del componente.

Este numeral no es obligatorio y sólo aparece si es apropiado.

Tablas de dependencia A.2

12/6/2014 ISO / IEC 15408-2



En las siguientes tablas de dependencia de los componentes funcionales muestran su directo, indirecto y opcionaldependencias. Cada uno de los componentes que es una dependencia de algún componente funcional se asigna unla columna. Cada componente funcional se asigna una fila. El valor en la celda de la tabla indica si la columnacomponente de etiqueta es necesaria directamente (indicado por una cruz "X"), de manera indirecta requerida (indicado por un guión "-"), oopcionalmente requerida (indicado por una "o") por el componente de etiqueta de la fila. Un ejemplo de un componente opcionaldependencias es FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad , que requiere ya sea FDP_ACC.1Subconjunto de control de acceso o información de FDP_IFC.1 subconjunto de control de flujo a estar presente. Así que si FDP_ACC.1 Subsetcontrol de acceso está presente, la información de control de flujo FDP_IFC.1 subconjunto no es necesario y viceversa. Si no haycarácter se presenta, el componente no depende de otro componente.

Página 130

ISO / IEC 15408-2:2008 (E)

FAU_GE

N.1

FLaU_SA

A.1

FLaU_SAR

0.1

FAU_STG.1

FIA_UI

D.1

FM

T_MTD.1

FM

T_SM

F.1

FM

T_SM

R.1

FPT_STM.1

FAU_ARP.1 - X -FAU_GEN.1 XFAU_GEN.2 X X -FAU_SAA.1 X -FAU_SAA.2 XFAU_SAA.3FAU_SAA.4FAU_SAR.1 X -FAU_SAR.2 - X -FAU_SAR.3 - X -FAU_SEL.1 X - X - - -FAU_STG.1 X -FAU_STG.2 X -FAU_STG.3 - X -FAU_STG.4 - X -

Tabla A.1 - tabla de dependencias para la clase FAU: Auditoría de seguridad

FIA_UI

D.1

FCO_NRO.1 XFCO_NRO.2 XFCO_NRR.1 XFCO_NRR.2 X

Tabla A.2 - tabla de dependencias para la clase FCO: Comunicación

FCS

_CKM.1

FCS

_CKM.2

FCS

_CKM.4

FCS_CO

P.1

FDP_ACC.1

FDP_ACF

.1

FDP

_IFC.

1

FDP

_IFF.

1

FDP

_ITC.

1

FDP

_ITC.

2

FIA_UI

D.1

FM

T_MSLa.1

FM

T_MSLa.3

FM

T_SM

F.1

FM

T_SM

R.1

FPT_TDC.

1

FTP

_YoTC.

1

FTP

_TRP.1

FCS_CKM.1 - O X O - - - - - - - - - - - - - -FCS_CKM.2 O - X - - - - - OO - - - - - - - -FCS_CKM.3 O - X - - - - - OO - - - - - - - -FCS_CKM.4 O - - - - - - - OO - - - - - - - -FCS_COP.1 O - X - - - - - OO - - - - - - - -

Tabla A.3 - tabla de dependencias para la clase FCS: Apoyo criptográfico

12/6/2014 ISO / IEC 15408-2



Página 131

ISO / IEC 15408-2:2008 (E)


FDP_ACC.1

FDP_ACF

.1

FDP

_IFC.

1

FDP

_IFF.

1

FDP

_ITT.

1

FDP

_ITT.

2

FDP

_UIT.

1

FIA_UI

D.1

FM

T_MSLa.1

FM

T_MSLa.3

FM

T_SM

F.1

FM

T_SM

R.1

FPT_TDC.

1

FTP

_YoTC.

1

FTP

_TRP.1

FDP_ACC.1 - X - - - - - - -FDP_ACC.2 - X - - - - - - -FDP_ACF.1 X - - - - - X - -FDP_DAU.1FDP_DAU.2 XFDP_ETC.1 O - O - - - - - -FDP_ETC.2 O - O - - - - - -FDP_IFC.1 - - - X - - - - -FDP_IFC.2 - - - X - - - - -FDP_IFF.1 - - X - - - X - -FDP_IFF.2 - - X - - - X - -FDP_IFF.3 - - X - - - - - -FDP_IFF.4 - - X - - - - - -FDP_IFF.5 - - X - - - - - -FDP_IFF.6 - - X - - - - - -FDP_ITC.1 O - O - - - X - -FDP_ITC.2 O - O - - - - - - X O OFDP_ITT.1 O - O - - - - - -FDP_ITT.2 O - O - - - - - -FDP_ITT.3 O - O - X - - - - -FDP_ITT.4 O - O - X - - - - -FDP_RIP.1FDP_RIP.2FDP_ROL.1 O - O - - - - - -FDP_ROL.2 O - O - - - - - -FDP_SDI.1FDP_SDI.2FDP_UCT.1 O - O - - - - - - O OFDP_UIT.1 O - O - - - - - - O OFDP_UIT.2 O - O - O - - - - - O -FDP_UIT.3 O - O - O - - - - - O -

Cuadro A.4 - tabla de dependencias para la clase FDP: protección de los datos del usuario

Página 132

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



FYoA_ATD.1

FIA_ULaU.1

FIA_UI

D.1

FIA_AFL.1 X -FIA_ATD.1FIA_SOS.1FIA_SOS.2FIA_UAU.1 XFIA_UAU.2 XFIA_UAU.3FIA_UAU.4FIA_UAU.5FIA_UAU.6FIA_UAU.7 X -FIA_UID.1FIA_UID.2FIA_USB.1 X

Cuadro A.5 - tabla de dependencias para la clase FIA: Identificación y autenticación

FDP_ACC.1

FDP_ACF

.1

FDP

_IFC.

1

FDP

_IFF.

1

FIA_UI

D.1

FM

T_MSLa.1

FM

T_MSLa.3

FM

T_MTD.1

FM

T_SM

F.1

FM

T_SM

R.1

FPT_STM.1

FMT_MOF.1 - X XFMT_MSA.1 O - O - - - - X XFMT_MSA.2 O - O - - X - - XFMT_MSA.3 - - - - - X - - XFMT_MSA.4 O - O - - - - - -FMT_MTD.1 - X XFMT_MTD.2 - X - XFMT_MTD.3 - X - -FMT_REV.1 - XFMT_SAE.1 - X XFMT_SMF.1FMT_SMR.1 XFMT_SMR.2 XFMT_SMR.3 - X

Cuadro A.6 - tabla de dependencias para la clase FMT: Gestión de la seguridad

Página 133

ISO / IEC 15408-2:2008 (E)

FIA_UI

D.1

FPR_UNO.

1

FPR_ANO.1FPR_ANO.2FPR_PSE.1FPR_PSE.2 XFPR_PSE.3FPR_UNL.1

12/6/2014 ISO / IEC 15408-2



FPR_UNO.1FPR_UNO.2FPR_UNO.3 XFPR_UNO.4

Cuadro A.7 - tabla de dependencias para la clase FPR: Privacidad

AG

D_O

PE.1

FIA_UI

D.1

FM

T_MOF.1

FM

T_SM

F.1

FM

T_SM

R.1

FPT_ITT.1

FPT_FLS.1FPT_ITA.1FPT_ITC.1FPT_ITI.1FPT_ITI.2FPT_ITT.1FPT_ITT.2FPT_ITT.3 XFPT_PHP.1FPT_PHP.2 - X - -FPT_PHP.3FPT_RCV.1 XFPT_RCV.2 XFPT_RCV.3 XFPT_RCV.4FPT_RPL.1FPT_SSP.1 XFPT_SSP.2 XFPT_STM.1FPT_TDC.1FPT_TEE.1FPT_TRC.1 XFPT_TST.1

Cuadro A.8 - tabla de dependencias para la clase FPT: Protección del TSF

Página 134

ISO / IEC 15408-2:2008 (E)

FPT_FloridaS.1

FRU_FLT.1 XFRU_FLT.2 XFRU_PRS.1FRU_PRS.2FRU_RSA.1FRU_RSA.2

Cuadro A.9 - Mesa de Dependencia para FRU Clase: Utilización de recursos

FIA

_ULaU.1

FIA_UI

D.1

FTA_LSA.1

12/6/2014 ISO / IEC 15408-2



FTA_MCS.1 XFTA_MCS.2 XFTA_SSL.1 X -FTA_SSL.2 X -FTA_SSL.3FTA_SSL.4FTA_TAB.1FTA_TAH.1FTA_TSE.1

Cuadro A.10 - Tabla de Dependencia para la clase FTA: acceso TOE

Página 135

ISO / IEC 15408-2:2008 (E)

Anexo B

(Normativo)

Clases funcionales, familias y componentes

Los siguientes anexos Anexo C t ediante Anexo M proporcionan las notas de aplicación para las clases funcionalesdefinida en el cuerpo principal de esta parte de la norma ISO / IEC 15408.

12/6/2014 ISO / IEC 15408-2



Página 136

ISO / IEC 15408-2:2008 (E)

Anexo C

(Normativo)

Clase FAU: Auditoría de seguridad

ISO / IEC 15408 familias de auditoría permiten a los autores PP / ST la capacidad de definir los requisitos para el control de usuarioactividades y, en algunos casos, la detección de violaciónes reales, posibles o inminentes de la aplicación de la SFR.Funciones de auditoría de seguridad del TOE se definen para ayudar a los eventos relevantes para la seguridad del monitor, y tener un efecto disuasoriocontra violaciónes de seguridad. Los requisitos de las familias de auditoría se refieren a las funciones que incluyen los datos de auditoríaprotección, formato de registro y selección de eventos, así como herramientas de análisis, alarmas de violación, y en tiempo realanálisis. La pista de auditoría se debe presentar en formato legible por humanos, ya sea directamente (por ejemplo, el almacenamiento de la auditoríasendero en formato legible por humanos) o indirectamente (por ejemplo, utilizando herramientas de reducción de auditoría), o ambos.

Durante el desarrollo de los requisitos de auditoría de seguridad, el autor PP / ST debería tomar nota de las interrelacionesentre las familias y los componentes de auditoría. Existe la posibilidad de especificar un conjunto de requisitos de auditoría quecumplir con las listas de dependencias familia / componentes, mientras que al mismo tiempo resulta en una auditoría deficientefunción (por ejemplo, una función de auditoría que requiere que todos los eventos relevantes de seguridad para ser auditados, pero sin la selectividadpara su control en cualquier criterio razonable como usuario individual o un objeto).

Requisitos de auditoría C.1 en un entorno distribuido

La aplicación de los requisitos de auditoría de redes y otros sistemas de gran tamaño puede diferir significativamente delos necesarios para sistemas aislados. Los sistemas más grandes, más complejas y activas requieren más reflexiónrespecto a la cual la auditoría de datos para recolectar y cómo debe ser gestionado, debido a la bajada de viabilidadinterpretación (o incluso el almacenamiento) lo que se recogió. La noción tradicional de una lista de horas-ordenado o "rastro" deeventos auditados pueden no ser aplicables en una red asíncrona global con arbitrariamente muchos eventos que ocurrena la vez.

Además, los diferentes hosts y servidores en un TOE distribuidas pueden tener diferentes políticas y valores de nombres.Presentación nombres simbólicos para la revisión de auditoría puede requerir una convención amplia red para evitar redundancias y"conflictos de nombres."

Un depósito de auditoría multi-objeto, partes de la cual se puede acceder por una potencialmente gran variedad de autorizaciónusuarios, pueden ser necesarias si los repositorios de auditoría han de cumplir una función útil en sistemas distribuidos.

Por último, el uso indebido de la autoridad por los usuarios autorizados deberán dirigirse al evitar sistemáticamente el almacenamiento localde los datos de auditoría relacionada con las acciones del administrador.

12/6/2014 ISO / IEC 15408-2



Página 137

ISO / IEC 15408-2:2008 (E)

Figura C.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura C.1 - FAU: Seguridad clase de auditoría descomposición

Respuesta automática de auditoría C.2 Seguridad (FAU_ARP)

Notas de usuario C.2.1

La familia de respuesta automática de auditoría de seguridad describe los requisitos para el manejo de eventos de auditoría. Larequisito podría incluir requisitos para alarmas o acción TSF (respuesta automática). Por ejemplo, el TSFpodría incluir la generación de alarmas en tiempo real, la terminación del proceso de ofender, incapacitante de un servicio,o desconexión o invalidación de una cuenta de usuario.

Un evento de auditoría se define como un "potencial violación de la seguridad", si así se indica por el análisis de las auditorías de seguridad(FAU_SAA) componentes.

Alarmas C.2.2 FAU_ARP.1 Seguridad

C.2.2.1 notas de aplicación de usuario

Una acción se debe tomar para las medidas de seguimiento en el caso de una alarma. Esta acción puede ser la de informar alusuario autorizado, para presentar al usuario autorizado con un conjunto de posibles acciones de contención, o tomaracciones correctivas. El calendario de las acciones debe ser considerado cuidadosamente por el autor PP / ST.

12/6/2014 ISO / IEC 15408-2



Página 138

ISO / IEC 15408-2:2008 (E)


Operaciones C.2.2.2

C.2.2.2.1 Asignación

En FAU_ARP.1.1, t él PP / ST autor debe especificar las acciones que se deben tomar en caso de un valor potencialviolación. Un ejemplo de una lista de este tipo es: "informar al usuario autorizado, desactivar el objeto que creó elposible violación de seguridad ". También puede especificar que la acción a tomar puede ser especificado por un representante autorizadode usuario.

La generación de datos de auditoría C.3 Seguridad (FAU_GEN)


La auditoría de la familia de generación de datos de seguridad incluye los requisitos para especificar los eventos de auditoría que deben sergenerado por la TSF para los eventos relevantes para la seguridad.

Esta familia se presenta de una manera que evite una dependencia de todos los componentes que requieren el apoyo de auditoría.Cada componente tiene una subcláusula de auditoría desarrollado en el que los eventos a auditar para esa área funcionalse enumeran. Cuando el autor de PP / ST monta el PP / ST, los elementos del área de auditoría se utilizan para completar elvariable en este componente. Por lo tanto, la especificación de lo que podría ser auditados por un área funcional se localiza enesa área funcional.

La lista de eventos auditables es totalmente dependiente de las otras familias funcionales dentro del PP / ST. Cada familiaPor lo tanto, la definición debe incluir una lista de sus eventos auditables específicos de la familia. Cada evento auditable en la listaeventos de auditables especificados en la familia funcional debe corresponder a uno de los niveles de eventos de auditoríageneración se especifica en esta familia (es decir, mínima, básica y detallada). Esto proporciona el autor de PP / ST coninformación necesaria para garantizar que todos los eventos auditables apropiados se especifican en el PP / ST. La siguienteejemplo muestra cómo los eventos auditables han de especificarse en las familias funcionales apropiados:

"Las siguientes acciones deben ser auditable si la generación de datos de auditoría de seguridad (FAU_GEN) i que está incluido en elPP / ST:

a) Mínimo: El uso exitoso de las funciones de administración de atributos de seguridad del usuario.

b) Básico: Todos los intentos de los usos de las funciones de administración de atributos de seguridad del usuario.

c) Básico: Identificación de los cuales los atributos de seguridad de usuario se han modificado.

d) Datos individuales: Con la excepción de los elementos de datos de atributos sensibles específicos (por ejemplo, contraseñas, cifradoteclas), los nuevos valores de los atributos deben ser capturados ".

Para cada componente funcional que se elija, los sucesos comprobables que se indican en dicho componente, eny por debajo del nivel indicado en la generación de los datos de seguridad de auditoría (FAU_GEN) sh Ould ser auditable. Si, porejemplo, en el ejemplo anterior "Basic" sería seleccionado en Seguridad auditoría generación de los datos (FAU_GEN),los eventos auditables de los apartados a), b) yc) deberían ser auditable.

Observe que la categorización de los sucesos comprobables es jerárquica. Por ejemplo, cuando básico Generación de Auditoríase desea, todos los eventos auditables identificados como mínimos o de base, deben también ser incluidos en elPP / ST a través de la utilización de la operación de asignación apropiado, excepto cuando el evento de nivel más alto simplementeproporciona más detalle que el evento de nivel inferior. Cuando se desea Generación de auditoría detallada, todos identificadoseventos auditables (mínimos, básicos y detallados) deben ser incluidos en el PP / ST.

Un autor de PP / ST podrá decidir incluir otros eventos auditables allá de las requeridas para un nivel dado de auditoría.Por ejemplo, el PP / ST puede reclamar capacidades de auditoría sólo mínimos, mientras incluyendo la mayor parte de la basecapacidades, ya los pocos excluidos conflicto capacidades con otras limitaciones PP / ST (por ejemplo, porque serequerirán la recopilación de datos no disponibles).

La funcionalidad que crea el evento auditable debe ser especificado en el PP o ST como funcionalrequisito.

Página 139

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Los siguientes son ejemplos de los tipos de los eventos que deben ser definidas como auditable en cada PP / STcomponente funcional:

a) Introducción de objetos dentro del control de la TSF en el espacio de direcciones de un sujeto;

b) Supresión de los objetos;

c) La distribución o la revocación de los derechos de acceso o capacidades;

d) Los cambios de sujeto u objeto atributos de seguridad;

e) Política de cheques realizados por el TSF, como resultado de una solicitud de un sujeto;

f) El uso de los derechos de acceso para eludir un control de la política;

g) El uso de las funciones de identificación y autenticación;

h) Las medidas adoptadas por un operador, y / o usuario autorizado (por ejemplo, supresión de un mecanismo de protección TSF comoetiquetas legibles);

i) Importación / exportación de datos desde / a un medio extraíble (por ejemplo, la salida impresa, cintas, disquetes).

C.3.2 generación de los datos de auditoría FAU_GEN.1


Este componente define los requisitos para identificar los eventos auditables para que los registros de auditoría deben sergenera, así como la información que debe facilitarse en los registros de auditoría.

FAU_GEN.1 Auditoría de generación de datos por sí misma podría ser utilizada cuando los SFR no requieren que usuario individualidentidades estar asociados con eventos de auditoría. Esto podría ser apropiado cuando el PP / ST también contiene privacidadrequisitos. Si la identidad de usuario debe incorporar d FAU_GEN.2 asociación de identidad de usuario podría ser utilizado enAdemás.

Si el sujeto es un usuario, la identidad del usuario se puede registrar como la identidad del sujeto. La identidad del usuario puedei todavía no ha verificado f La autenticación de usuarios (FIA_UAU) no se ha aplicado. Por lo tanto en el ejemplo de unno válido de inicio de sesión de la identidad del usuario reclamado se debe registrar. Se debe considerar para indicar cuando un grabadoidentidad no ha sido autenticada.

Notas C.3.2.2 Evaluador

Hay una dependencia de T iempo sellos (FPT_STM). Si la corrección de tiempo no es un problema para este TOE,eliminación de esta dependencia podría estar justificada.

Operaciones C.3.2.3

C.3.2.3.1 Selección

En FAU_GEN.1.1, el autor PP / ST debe seleccionar el nivel de los eventos auditables llamados en la auditoríasubcláusula de otros componentes funcionales incluidos en el PP / ST. Este nivel es uno de los siguientes: "mínimo","Básico", "detalle" o "no especificada".


En FAU_GEN.1.1, t él PP / ST autor debe asignar una lista de otros eventos auditables definidos específicamente para serincluido en la lista de eventos auditables. La asignación puede comprender ninguno, o eventos que podrían ser auditableeventos de un requisito funcional que son de un nivel de auditoría superior a la solicitada en b), así como los eventosgenerada a través del uso de una interfaz de programación de la aplicación especificada (API).

Página 140

ISO / IEC 15408-2:2008 (E)

En FAU_GEN.1.2, t él PP / ST autor debe asignar, para cada uno de los eventos auditables incluidos en el PP / ST, ya sea unlista de otra auditoría de la información que deberá figurar en los registros de eventos de auditoría o ninguna.

C.3.3 FAU_GEN.2 asociación identidad del usuario


Este componente se refiere a la exigencia de responsabilidad de los sucesos comprobables a nivel de usuario individualidentidad. Este componente debe utilizarse además t o FAU_GEN.1 la generación de datos de auditoría.

12/6/2014 ISO / IEC 15408-2



Existe un conflicto potencial entre el requisitos de privacidad de la auditoría y. Para fines de auditoría puede serconveniente saber quién realiza una acción. El usuario puede querer mantener su / sus acciones a mismo / ayno ser identificado por otras personas (por ejemplo, un sitio con las ofertas de empleo). O podría ser necesario en el OrganizacionalPolítica de Seguridad de que la identidad de los usuarios debe ser protegido. En esos casos, los objetivos de la auditoría yprivacidad puede contradecirse. Por lo tanto, si se selecciona este requisito y la privacidad es importante,inclusión de la pseudonimity usuario componente puede ser considerado. Requisitos relativos a la determinación de la verdaderanombre de usuario en función de su seudónimo se especifican en la clase privacidad.

Si la identidad del usuario aún no ha sido verificado a través de la autenticación, en el caso de un inicio de sesión válido ella identidad del usuario reclamado debe ser registrada. Se debe considerar para indicar cuando una identidad registrada no tienesido autenticado.

Análisis de auditoría C.4 Seguridad (FAU_SAA)


Esta familia define requisitos para medios automáticos que analizan la actividad del sistema y de los datos de auditoría en busca deposibles o reales violaciónes de seguridad. Este análisis puede trabajar en apoyo de detección de intrusos, o automáticorespuesta a una potencial violación de la seguridad.

La acción a realizar por la TSF en la detección de una posible violación se define en la auditoría de seguridadde respuesta automática (FAU_ARP) componentes.

Para el análisis en tiempo real, datos de auditoría pueden ser transformados en un formato útil para el tratamiento automatizado, pero en undiferente formato útil para la entrega a los usuarios autorizados para su revisión.

C.4.2 FAU_SAA.1 análisis Potencial violación


Este componente se utiliza para especificar el conjunto de eventos auditables cuya existencia real o acumuladoscelebrada para indicar una posible violación de la ejecución de los SFR, y cualquier regla que se utilizarán para llevar a cabo laanálisis de violación.

Operaciones C.4.2.2


En FAU_SAA.1.2, el autor PP / ST debe identificar el subconjunto de incidentes auditables definidos cuya ocurrenciao la necesidad de ocurrencia acumulada para ser detectado como una indicación de una posible violación de la ejecución de laslos SFR.

En FAU_SAA.1.2, t él PP / ST autor debe especificar todas las demás normas que la TSF debe utilizar en su análisis dela pista de auditoría. Esas reglas podrían incluir requisitos específicos para expresar las necesidades de los acontecimientos que se producen enun cierto período de tiempo (por ejemplo, el período de días, la duración). Si no hay reglas adicionales que el TSF debeutilizar en el análisis de la pista de auditoría, esta tarea se puede completar con "ninguno".

Página 141

ISO / IEC 15408-2:2008 (E)

Detección de anomalías C.4.3 FAU_SAA.2 Perfil basada


Un perfil es una estructura que caracteriza el comportamiento de los usuarios y / o sujetos; que representa cómo elusuarios / sujetos interactúan con el TSF en una variedad de maneras. Los patrones de uso se establecen con respecto a ladiversos tipos de actividad de los usuarios / sujetos realizan (por ejemplo, los patrones de las excepciones planteadas, los patrones de los recursosutilización (cuando, que, cómo), los patrones de las acciones realizadas). Las formas en que los distintos tipos de actividadse registran en el perfil (por ejemplo, medidas de recursos, contadores de eventos, temporizadores) se conocen como la métrica del perfil .

Cada perfil representa los patrones esperados de uso realizadas por miembros del grupo destinatario perfil .Este patrón puede estar basado en el uso anterior (patrones históricos) o en condiciones normales de uso para los usuarios de los grupos objetivo similares(Comportamiento esperado). Un grupo destino de perfil se refiere a uno o más usuarios que interactúan con el TSF. Lala actividad de cada miembro del grupo de perfil es utilizado por la herramienta de análisis en el establecimiento de los patrones de usorepresentado en el perfil. Los siguientes son algunos ejemplos de perfil grupos objetivo:

a) la cuenta de usuario individual : un perfil para cada usuario;

b) Grupo de ID o de grupo de cuentas : un perfil para todos los usuarios que poseen el mismo ID de grupo o funcionan conla misma cuenta de grupo;

12/6/2014 ISO / IEC 15408-2



c) Papel de funcionamiento : un perfil para todos los usuarios que comparten un papel operativo dado;d) Sistema : un perfil para todos los usuarios de un sistema.

Cada miembro de un grupo objetivo perfiles se le asigna un individuo calificación sospecha que representa cómo de cercanueva actividad de ese miembro corresponde a los patrones establecidos de uso representado en el perfil de grupo.

La sofisticación de la herramienta de detección de anomalías dependerá en gran medida por el número de perfil de destinogrupos requeridos por el PP / ST y de la complejidad de las métricas perfil requerido.

El autor PP / ST debe enumerar específicamente qué actividad deben ser controlados y / o analizados por elTSF. El autor PP / ST también debe identificar específicamente qué información relativa a la actividad es necesariopara la construcción de los perfiles de uso.

FAU_SAA.2 perfil basado detección de anomalías r equiere que el TSF mantener perfiles de uso del sistema. Lapalabra mantener implica que el detector de anomalías activamente actualiza el perfil de uso basada en la nueva actividadrealizado por los miembros de destino perfil. Es importante aquí que los parámetros para la representación de la actividad del usuario sondefinido por el autor de PP / ST. Por ejemplo, puede haber un millar de acciones diferentes que un individuo puede sercapaz de realizar, pero el detector de anomalía puede elegir para supervisar un subconjunto de esa actividad. Anómaloactividad se integra en el perfil al igual que la actividad no anómala (suponiendo que la herramienta está monitoreando losacciones). Las cosas que pueden haber aparecido anómala hace cuatro meses, podrían con el tiempo convertirse en la norma (yviceversa) como cambian las obligaciones laborales de los usuarios. El TSF no sería capaz de captar esta noción si fuera filtradaactividad anómala de los algoritmos de actualización del perfil.

Notificación de administración debe ser proporcionada de tal manera que el usuario autorizado entiende la importancia dela calificación de la sospecha.

El autor PP / ST debe definir cómo interpretar calificaciones sospecha y las condiciones bajo las cuales anómalaactividad está indicada para la auditoría de seguridad de respuesta automática (FAU_ARP ) mecanismo.

Operaciones C.4.3.2


En FAU_SAA.2.1, el autor PP / ST debe especificar el grupo de destino de perfil. Un único PP / ST puede incluirperfil múltiples grupos destinatarios.

Página 142

ISO / IEC 15408-2:2008 (E)

En FAU_SAA.2.3, el autor PP / ST debe especificar las condiciones bajo las cuales la actividad anómala se reporta porla TSF. Las condiciones pueden incluir la calificación de la sospecha de llegar a un cierto valor, o basarse en el tipo deactividad anómala observada.

C.4.4 FAU_SAA.3 heurística de ataque simple


En la práctica, es en el mejor de raro cuando una herramienta de análisis puede detectar con certeza cuando una violación de la seguridad esinminente. Sin embargo, sí existen algunos eventos del sistema que son tan importantes que siempre son dignos derevisión independiente. Ejemplo de este tipo de eventos incluye la eliminación de un archivo de datos de seguridad TSF clave (por ejemplo, elarchivo de contraseñas) o la actividad como un usuario remoto intentar obtener privilegios administrativos. Estos eventos sonreferido como acontecimientos de la firma en que su aparición en el aislamiento del resto de la actividad del sistema sonindicativo de la actividad intrusiva.

La complejidad de una determinada herramienta dependerá en gran medida de las tareas definidas por el autor PP / ST enidentificar el conjunto base de acontecimientos de la firma .

El autor PP / ST debe enumerar específicamente qué eventos deben ser controlados por el TSF con el fin derealizar el análisis. El autor de PP / ST debe identificar específicamente lo que la información relativa al evento esnecesaria para determinar si el evento se asigna a un evento de la firma.

Notificación de administración debe ser proporcionada de tal manera que el usuario autorizado entiende la importancia deel evento y las posibles respuestas apropiadas.

Se hizo un esfuerzo en la especificación de estos requisitos para evitar una dependencia de los datos de auditoría como el únicode entrada para la actividad del sistema de vigilancia. Esto se hizo en reconocimiento de la existencia de desarrollado previamenteherramientas de detección de intrusos que no realizan sus análisis de la actividad del sistema sólo a través de la utilización de la auditoríadatos (ejemplos de otros datos de entrada incluyen datagramas de red, datos de recursos / contabilidad, o combinaciones dediversos datos del sistema).

Los elementos de FAU_SAA.3 heurísticas simples ataque d o no requieren que el TSF aplicación de la inmediataheurística de ataque sean los mismos TSF cuya actividad se está supervisando. Por lo tanto, uno puede desarrollar una intrusión

12/6/2014 ISO / IEC 15408-2



componente de detección que funciona independientemente del sistema cuya actividad del sistema se está analizando.

Operaciones C.4.4.2


En FAU_SAA.3.1, el autor PP / ST debe identificar un subconjunto de base de los eventos del sistema cuya ocurrencia, enaislamiento del resto de la actividad del sistema, puede indicar una violación de la ejecución de la SFR. Estos incluyeneventos que por sí mismos indican una clara violación a la ejecución de los SFR, o cuya ocurrencia estan importantes que justifican las acciones.

En FAU_SAA.3.2, t él PP / ST autor debe especificar la información que se utiliza para determinar la actividad del sistema. Esteinformación son los datos de entrada utilizados por la herramienta de análisis para determinar la actividad del sistema que se ha producido enTOE. Estos datos pueden incluir datos de auditoría, combinaciones de datos de auditoría con otros datos del sistema, o puede consistir ende datos distintos de los datos de auditoría. El autor PP / ST debe definir lo que precisamente los acontecimientos y sucesos del sistemaatributos están siendo monitoreados dentro de los datos de entrada.

Heurística de ataque C.4.5 FAU_SAA.4 complejos


En la práctica, es en el mejor de raro cuando una herramienta de análisis puede detectar con certeza cuando una violación de la seguridad esinminente. Sin embargo, sí existen algunos eventos del sistema, que son tan importantes que siempre son dignos derevisión independiente. Ejemplo de este tipo de eventos incluye la eliminación de un archivo de datos de seguridad TSF clave (por ejemplo, elarchivo de contraseñas) o la actividad como un usuario remoto intentar obtener privilegios administrativos. Estos eventos sonreferido como acontecimientos de la firma en que su aparición en el aislamiento del resto de la actividad del sistema son

Página 143

ISO / IEC 15408-2:2008 (E)

indicativo de la actividad intrusiva. Secuencias de eventos son un conjunto ordenado de eventos distintivos que pueden indicaractividad intrusiva.

La complejidad de una determinada herramienta dependerá en gran medida de las tareas definidas por el autor PP / ST enidentificar el conjunto base de los eventos de firma y secuencias de eventos.

El autor PP / ST debe enumerar específicamente qué eventos deben ser controlados por el TSF con el fin derealizar el análisis. El autor de PP / ST debe identificar específicamente lo que la información relativa al evento esnecesaria para determinar si el evento se asigna a un evento de la firma.

Notificación de administración debe ser proporcionada de tal manera que el usuario autorizado entiende la importancia deel evento y las posibles respuestas apropiadas.

Se hizo un esfuerzo en la especificación de estos requisitos para evitar una dependencia de los datos de auditoría como el únicode entrada para la actividad del sistema de vigilancia. Esto se hizo en reconocimiento de la existencia de desarrollado previamenteherramientas de detección de intrusos que no realizan sus análisis de la actividad del sistema sólo a través de la utilización de la auditoríadatos (ejemplos de otros datos de entrada incluyen datagramas de red, datos de recursos / contabilidad, o combinaciones dediversos datos del sistema). Nivelación, por lo tanto, requiere que el autor PP / ST para especificar el tipo de datos de entrada se utiliza parasupervisar la actividad del sistema.

Los elementos de FAU_SAA.4 heurística de ataque complejos d o no requieren que el TSF aplicación de la complejaheurística de ataque sean los mismos TSF cuya actividad se está supervisando. Por lo tanto, uno puede desarrollar una intrusióncomponente de detección que funciona independientemente del sistema cuya actividad del sistema se está analizando.

Operaciones C.4.5.2


En FAU_SAA.4.1, el autor PP / ST debe identificar un conjunto base de la lista de secuencias de eventos del sistema, cuyaocurrencia son representativos de escenarios de penetración conocidos. Estas secuencias de eventos representan conocidoescenarios de penetración. Cada evento representado en la secuencia debe asignar a un evento de sistema supervisado,de tal manera que a medida que se realizan los eventos del sistema, están obligados (asignada) para el caso de la penetración conocidosecuencias.

En FAU_SAA.4.1, el autor PP / ST debe identificar un subconjunto de base de los eventos del sistema cuya ocurrencia, enaislamiento del resto de la actividad del sistema, puede indicar una violación de la ejecución de la SFR. Estos incluyeneventos que por sí mismos indican una clara violación a la SFR, o cuya ocurrencia es tan significativa queacción warrant.

En FAU_SAA.4.2, t él PP / ST autor debe especificar la información que se utiliza para determinar la actividad del sistema. Esteinformación son los datos de entrada utilizados por la herramienta de análisis para determinar la actividad del sistema que se ha producido enTOE. Estos datos pueden incluir datos de auditoría, combinaciones de datos de auditoría con otros datos del sistema, o puede consistir ende datos distintos de los datos de auditoría. El autor PP / ST debe definir lo que precisamente los acontecimientos y sucesos del sistemaatributos están siendo monitoreados dentro de los datos de entrada.

12/6/2014 ISO / IEC 15408-2



Examen de auditoría C.5 Seguridad (FAU_SAR)


El examen de auditoría de seguridad de la familia define los requisitos relacionados con la revisión de la información de auditoría.

Estas funciones deben permitir la selección de auditoría de pre-almacenamiento o después de almacenamiento que incluye, por ejemplo, la capacidadrevisar selectivamente:

• las acciones de uno o más usuarios (por ejemplo, de identificación, de autenticación, de entrada TOE, y control de accesoacciones);

• las acciones realizadas en un objeto o TOE recurso específico;

Página 144

ISO / IEC 15408-2:2008 (E)

• todo de un conjunto especificado de excepciones auditados; o

• acciones asociadas a un atributo específico SFR.

La distinción entre los exámenes de auditoría se basa en la funcionalidad. Revisión de Auditoría (solamente) abarca la capacidad dever los datos de auditoría. Revisión seleccionable es más sofisticado y requiere la capacidad de seleccionar subconjuntos de auditoríadatos basados en un criterio único o múltiples criterios con las relaciones lógicas (es decir, y / o), y el orden de los datos de auditoríaantes de que se revisa.

C.5.2 Examen de auditoría FAU_SAR.1

C.5.2.1 Justificación

Este componente proporcionará a los usuarios autorizados la capacidad para obtener e interpretar la información. En caso deusuarios humanos esta información tiene que estar en una presentación comprensible humana. En caso de IT externaentidades la información que necesita para ser representado de forma inequívoca en forma electrónica.


Este componente se utiliza para especificar que los usuarios y / o los usuarios autorizados puedan leer los registros de auditoría. Estos auditoríaregistros serán proporcionados de manera adecuada al usuario. Hay diferentes tipos de usuarios (usuarios humanos,usuarios de la máquina), que pueden tener diferentes necesidades.

El contenido de los registros de auditoría que se pueden ver se puede especificar.

Operaciones C.5.2.3


En FAU_SAR.1.1, el autor PP / ST debe especificar los usuarios autorizados que pueden utilizar esta capacidad. Siapropiarse del autor PP / ST puede incluir funciones de seguridad (ver papeles FMT_SMR.1 Seguridad).

En FAU_SAR.1.1, t él PP / ST autor debe especificar el tipo de información que el usuario especificado está permitidoobtener de los registros de auditoría. Algunos ejemplos son "todos", "identidad del sujeto", "toda la información perteneciente a auditar los registrosreferencia a este usuario ". Cuando se emplea la SFR, FAU_SAR.1, no es necesario repetir, con todo detalle, lalista de la información de auditoría primero se especifica en FAU_GEN.1. El uso de términos tales como "todos" o "toda la información de auditoría" ayudaren la eliminación de la ambigüedad y la mayor necesidad de un análisis comparativo entre los dos requisitos de seguridad.

C.5.3 FAU_SAR.2 Restricted examen de auditoría


Este componente se especifica que cualquier usuario no identificados en FAU_SAR.1 revisión Auditoría wi no será capaz de leer elauditar los registros.

C.5.4 FAU_SAR.3 seleccionable examen de auditoría


Este componente se utiliza para especificar que debería ser posible llevar a cabo la selección de los datos de auditoría a serrevisado. Si se basa en varios criterios, tales criterios deben relacionarse junto con lógica (es decir, "y" u "o")las relaciones, y las herramientas deben proporcionar la capacidad de manipular los datos de auditoría (por ejemplo, clasificar, filtrar).

Operaciones C.5.4.2


12/6/2014 ISO / IEC 15408-2



En FAU_SAR.3.1, t él PP / ST autor debe especificar si la capacidad para seleccionar y / o los datos de auditoría orden esrequerida de la TSF.

Página 145

ISO / IEC 15408-2:2008 (E)


En FAU_SAR.3.1, t él PP / ST autor debe asignar los criterios, posiblemente con relaciones lógicas, para ser utilizado aseleccione los datos de auditoría para la revisión. Las relaciones lógicas están destinadas a especificar si la operación puede ser enun atributo individual o un conjunto de atributos. Un ejemplo de esta tarea podría ser: "la aplicación, el usuariocuenta y / o la ubicación. " En este caso, la operación podría especificarse utilizando cualquier combinación de los tresatributos: la aplicación, la cuenta de usuario y la ubicación.

Selección de eventos de auditoría C.6 Seguridad (FAU_SEL)


La familia de la selección de eventos de auditoría de seguridad proporciona los requisitos relacionados con la capacidad de identificar quéde los posibles sucesos comprobables deben ser controladas. Los eventos auditables se definen en la información de auditoría de seguridadgeneración (FAU_GEN) fa milia, pero esos eventos deben ser definidos como siendo seleccionable en este componente paraauditar.

Esta familia asegura que es posible para mantener la pista de auditoría se convierta en tan grande que se vuelve inútil,mediante la definición de la granularidad adecuada de los eventos de auditoría de seguridad seleccionados.

C.6.2 FAU_SEL.1 auditoría selectiva


Este componente se definen los criterios de selección utilizados, y los subconjuntos auditados resultantes del conjunto de todas las auditableeventos, basados en los atributos de usuario, los atributos temáticos, atributos de los objetos, o los tipos de eventos.

La existencia de identidades de usuarios individuales no se asume para este componente. Esto permite que para los dedos, tales comoLos routers que no sean compatibles con la noción de los usuarios.

Para un entorno distribuido, la identidad de acogida podría ser utilizado como un criterio de selección para los eventos que se van a auditar.

La función de administración de F MT_MTD.1 Gestión de los datos TSF será manejar los derechos de los usuarios autorizados aconsultar o modificar las selecciones.

Operaciones C.6.2.2


En FAU_SEL.1.1, t él PP / ST autor debe seleccionar si la seguridad de los atributos sobre los que la selectividad de auditoría esbasado, está relacionada con el objeto de identidad, la identidad del usuario, la identidad de sujeto, identidad del host, o el tipo de evento.


En FAU_SEL.1.1, t él PP / ST autor debe especificar los atributos adicionales sobre los que la selectividad de auditoría esbasado. Si no hay reglas adicionales sobre los que se basa la selectividad de auditoría, esta tarea puede ser completadacon "ninguno".

Almacenamiento de eventos de auditoría C.7 Seguridad (FAU_STG)


La familia de almacenamiento de eventos de auditoría de seguridad describe los requisitos para el almacenamiento de los datos de auditoría para su uso posterior, incluyendorequisitos que controlan la pérdida de información de auditoría debido a un fallo TOE, el ataque y / o el agotamiento de almacenamientoespacio.

Página 146

12/6/2014 ISO / IEC 15408-2


ISO / IEC 15408-2:2008 (E)


C.7.2 FAU_STG.1 Protegida auditoría almacenamiento rastro


En un entorno distribuido, como la ubicación de la pista de auditoría se encuentra en la TSF, pero no necesariamente co-ubicada conla función de la generación de los datos de auditoría, el autor PP / ST podría solicitar la autenticación del autor de laregistro de auditoría, o el no repudio del origen del registro antes de guardar este registro en la pista de auditoría.

La TSF protegerá a los registros de auditoría almacenados en el registro de auditoría de eliminación y modificación no autorizada. Esseñaló que en algunos TOE auditor (papel) podría no estar autorizado para eliminar los registros de auditoría para un determinadoperíodo de tiempo.

Operaciones C.7.2.2


En FAU_STG.1.2, el autor PP / ST debe especificar si el TSF debe evitar o ser capaz de detectar sólomodificaciones de los registros de auditoría almacenados en el registro de auditoría. Sólo una de estas opciones se puede elegir.

Garantías C.7.3 FAU_STG.2 de disponibilidad de los datos de auditoría


Este componente permite al autor PP / ST para especificar a qué parámetros la pista de auditoría debe cumplir.

En un entorno distribuido, como la ubicación de la pista de auditoría se encuentra en la TSF, pero no necesariamente co-ubicada conla función de la generación de los datos de auditoría, el autor PP / ST podría solicitar la autenticación del autor de laregistro de auditoría, o el no repudio del origen del registro antes de guardar este registro en la pista de auditoría.

Operaciones C.7.3.2


En FAU_STG.2.2, el autor PP / ST debe especificar si el TSF debe evitar o ser capaz de detectar sólomodificaciones de los registros de auditoría almacenados en el registro de auditoría. Sólo una de estas opciones se puede elegir.


En FAU_STG.2.3, el autor de PP / ST debe especificar la métrica que la TSF debe garantizar con respecto a laalmacena los registros de auditoría. Esta medida limita la pérdida de datos mediante la enumeración de la cantidad de registros que deben mantenerse,o el tiempo que los registros están garantizados para ser mantenida. Un ejemplo de la métrica podría ser "100000"lo que indica que 100.000 registros de auditoría se pueden almacenar.


En FAU_STG.2.3, t él PP / ST autor debe especificar la condición bajo la cual la TSF debe todavía ser capaz demantener una cantidad definida de los datos de auditoría. Esta condición puede ser cualquiera de los siguientes: el agotamiento de almacenamiento de auditoría,fracaso, ataque.

C.7.4 FAU_STG.3 Actuación en caso de una posible pérdida de datos de auditoría


Este componente requiere que se tomarán las acciones cuando la pista de auditoría supera ciertos límites predefinidos.

Página 147

ISO / IEC 15408-2:2008 (E)

Operaciones C.7.4.2


En FAU_STG.3.1, t él PP / ST autor debe indicar el límite pre-definido. Si las funciones de gestión indicanque este número puede ser cambiado por el usuario autorizado, este valor es el valor predeterminado. El autor de PP / STpodrían optar por dejar que el usuario autorizado a definir este límite. En ese caso, la asignación puede ser por ejemplo "unlímite fijado por el usuario autorizado ".

12/6/2014 ISO / IEC 15408-2



En FAU_STG.3.1, el autor PP / ST debe especificar las acciones que se deben tomar en caso de auditoría inminentefallo de almacenamiento indicado por la superación del umbral. Acciones pueden incluir informar a un usuario autorizado.

C.7.5 Prevención FAU_STG.4 de pérdida de datos de auditoría


Este componente especifica el comportamiento de la TOE, si el registro de auditoría está lleno: o bien los registros de auditoría se ignoran, oTOE se congela de tal manera que no hay eventos auditados pueden tener lugar. El requisito, además, que no importa loel requisito se crea una instancia, el usuario autorizado con derechos específicos en este sentido, se puede seguir generandoeventos auditados (acciones). La razón es que de lo contrario el usuario autorizado ni siquiera podía restablecer el TOE.Se debe considerar que la elección de la acción a ser tomada por el TSF en el caso de almacenamiento de auditoríaagotamiento, como ignorar los acontecimientos, lo que proporciona una mayor disponibilidad de la TOE, también permitirá que las acciones a serrealizado sin estar registrado y sin que el usuario tener que rendir cuentas.

Operaciones C.7.5.2


En FAU_STG.4.1, t él PP / ST autor debe seleccionar si la TSF debe ignorar las acciones auditadas, o sidebe evitar las acciones auditadas suceda, o si los registros de auditoría antiguos deben ser eliminadoscuando el TSF puede almacenar registros de auditoría ya no importa. Sólo una de estas opciones se puede elegir.


En FAU_STG.4.1, t él PP / ST autor debe especificar otras acciones que se deben tomar en caso de un almacenamiento de auditoríafracaso, tales como informar al usuario autorizado. Si no hay ninguna otra acción a tomar en caso de un almacenamiento de auditoríafracaso, esta tarea se puede completar con "ninguno".

Página 148

ISO / IEC 15408-2:2008 (E)

Anexo D

(Normativo)

Clase FCO: Comunicación

Esta clase describe los requisitos específicamente de interés para los dedos que se utilizan para el transporte deinformación. Las familias dentro de este acuerdo de la clase con el no repudio.

En esta clase se utiliza el concepto de "información". Esta información debe ser interpretada como el objeto de sercomunicado, y podría contener un mensaje electrónico electrónico, un archivo o un conjunto de tipos de atributos predefinidos.

En la literatura, los términos "a prueba de recibo" y "prueba de origen" son términos de uso común. Sin embargo, esreconoció que el término "prueba" podría interpretarse en un sentido legal implicar una forma de matemáticarazón de ser. Los componentes de esta clase interpretan el uso de facto de la palabra "prueba" en el contexto de"Evidencia" de que el TSF demuestra el transporte no repudiado de tipos de información.

12/6/2014 ISO / IEC 15408-2



Figura D.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura D.1 - FCO: Comunicación clase descomposición

D.1 no repudio de origen (FCO_NRO)

D.1.1 notas de usuario

No repudio de origen define los requisitos para acreditar a los usuarios / temas sobre la identidad de lacreador de alguna información. El autor no puede negar haber enviado con éxito la información porquepruebas de origen (por ejemplo, la firma digital) proporciona evidencia de la unión entre el iniciador y elinformación enviada. El destinatario o un tercero puede verificar la evidencia de origen. Esta evidencia no debe serforjable.

Si la información o los atributos asociados se alteran de ninguna manera, la validación de las pruebas de origen podríafallar. Por lo tanto, un autor de PP / ST debe considerar la inclusión de requisitos de integridad de un tal s Datos FDP_UIT.1integridad de cambio en el PP / ST.

En el no repudio hay varios papeles de distintos actores, cada uno de los cuales se podrían combinar en una o mássujetos. La primera función es un tema que pide pruebas de origen (sólo en FCO_NRO.1 prueba selectiva deorigen ). El segundo papel es el receptor y / o de otros temas a los que se presentasen las pruebas (por ejemplo, un notario).La tercera función es un tema que solicita la verificación de las pruebas de origen, por ejemplo, un destinatario o un tercerofiesta como un árbitro.

El autor PP / ST debe especificar las condiciones que deben cumplirse para poder verificar la validez de lapruebas. Un ejemplo de una condición que podría especificarse es donde debe tener lugar la verificación de pruebasdentro de las 24 horas. Estas condiciones, por lo tanto, permiten la adaptación del no repudio a los requisitos legales,tales como ser capaz de proporcionar pruebas durante varios años.

En la mayoría de los casos, la identidad del receptor será la identidad del usuario que recibió la transmisión. Enalgunos casos, el autor PP / ST no quiere que la identidad del usuario que se va a exportar. En ese caso, el PP / ST

Página 149

ISO / IEC 15408-2:2008 (E)

autor debe considerar si es conveniente incluir esta clase, o si la identidad del transporteproveedor de servicios o la identidad del huésped debe ser utilizado.

Además de (o en lugar de) la identidad del usuario, un autor de PP / ST podría estar más preocupado por el tiempo de lainformación fue transmitida. Por ejemplo, las solicitudes de propuestas deben ser transmitidos antes de una fecha determinada enPara ser considerado. En tales casos, estos requisitos se pueden personalizar para proporcionar una indicación de la horaindicación (tiempo de origen).

D.1.2 FCO_NRO.1 prueba selectiva de origen

Operaciones D.1.2.1

D.1.2.1.1 Asignación

En FCO_NRO.1.1, th e PP / ST autor deberá rellenar los tipos de información sujeta a la prueba de origende función, por ejemplo, mensajes de correo electrónico.

D.1.2.1.2 Selección

En FCO_NRO.1.1, t él PP / ST autor debe especificar el usuario / sujeto que puede solicitar pruebas de origen.


En FCO_NRO.1.1, t él PP / ST autor, depende de la selección, debe especificar los terceros que puedensolicitar pruebas de origen. Un tercero podría ser un árbitro, juez o cuerpo legal.

En FCO_NRO.1.2, el autor PP / ST debe completar la lista de los atributos que se pueden vincular a la información;por ejemplo, el originador de identidad, fecha de origen y el lugar de origen.

En FCO_NRO.1.2, th e PP / ST autor debe rellenar la lista de campos de información dentro de la información sobre la cuallos atributos proporcionan evidencia de origen, tales como el cuerpo de un mensaje.

12/6/2014 ISO / IEC 15408-2




En FCO_NRO.1.3, th e PP / ST autor debe especificar el usuario / sujeto que pueda verificar la evidencia de origen.


En FCO_NRO.1.3, el autor PP / ST debe rellenar la lista de limitaciones bajo las cuales las pruebas pueden serverificada. Por ejemplo, la evidencia sólo puede ser verificada dentro de un intervalo de tiempo de 24 horas. La cesión de"Inmediata" o "indefinido" es aceptable.

En FCO_NRO.1.3, t él PP / ST autor, depende de la selección, debe especificar los terceros que puedenverificar la evidencia de origen.

Prueba D.1.3 FCO_NRO.2 forzada de origen

Operaciones D.1.3.1


En FCO_NRO.2.1, th e PP / ST autor deberá rellenar los tipos de información sujeta a la prueba de origende función, por ejemplo, mensajes de correo electrónico.

En FCO_NRO.2.2, el autor PP / ST debe completar la lista de los atributos que se pueden vincular a la información;por ejemplo, el originador de identidad, fecha de origen y el lugar de origen.

En FCO_NRO.2.2, th e PP / ST autor debe rellenar la lista de campos de información dentro de la información sobre la cuallos atributos proporcionan evidencia de origen, tales como el cuerpo de un mensaje.

Página 150

ISO / IEC 15408-2:2008 (E)


En FCO_NRO.2.3, th e PP / ST autor debe especificar el usuario / sujeto que pueda verificar la evidencia de origen.


En FCO_NRO.2.3, el autor PP / ST debe rellenar la lista de limitaciones bajo las cuales las pruebas pueden serverificada. Por ejemplo, la evidencia sólo puede ser verificada dentro de un intervalo de tiempo de 24 horas. La cesión de"Inmediata" o "indefinido" es aceptable.

En FCO_NRO.2.3, t él PP / ST autor, depende de la selección, debe especificar los terceros que puedenverificar la evidencia de origen. Un tercero podría ser un árbitro, juez o cuerpo legal.

D.2 No repudio de recepción (FCO_NRR)

D.2.1 notas de usuario

No repudio de recepción define los requisitos para proporcionar evidencia a otros usuarios / asignaturas que ella información fue recibida por el destinatario. El receptor no puede negar éxito de haber recibido lainformación debido a la evidencia de la recepción (firma digital, por ejemplo) proporciona evidencia de la unión entre elAtributos de destinatario y la información. El originador o un tercero pueden verificar la constancia de su recepción. Estepruebas no debe ser forjable.

Cabe señalar que la presentación de pruebas de que se ha recibido la información no implica necesariamenteque la información se ha leído o comprendido, pero sólo entrega.

Si la información o los atributos asociados se alteran de ninguna manera, la validación de las pruebas de recepción conrespecto a la información original puede fallar. Por lo tanto, un autor de PP / ST debe considerar la inclusión de la integridadrequisitos tales como la integridad de cambio FDP_UIT.1 datos en el PP / ST.

En el no repudio, hay varios papeles de distintos actores, cada uno de los cuales se podrían combinar en una o mássujetos. La primera función es un tema que solicita un acuse de recibo (sólo en FCO_NRR.1 prueba selectiva derecibo ). La segunda función es el receptor y / o otros sujetos a los que se proporciona la evidencia, (por ejemplo, unanotario). La tercera función es un tema que solicita la verificación de la constancia de su recepción, por ejemplo, unoriginador o de un tercero, como un árbitro.

El autor PP / ST debe especificar las condiciones que deben cumplirse para poder verificar la validez de lapruebas. Un ejemplo de una condición que podría especificarse es donde debe tener lugar la verificación de pruebasdentro de las 24 horas. Estas condiciones, por lo tanto, permiten la adaptación del no repudio a los requisitos legales,tales como ser capaz de proporcionar pruebas durante varios años.

En la mayoría de los casos, la identidad del receptor será la identidad del usuario que recibió la transmisión. En

12/6/2014 ISO / IEC 15408-2



algunos casos, el autor PP / ST no quiere que la identidad del usuario que se va a exportar. En ese caso, el PP / STautor debe considerar si es conveniente incluir esta clase, o si la identidad del transporteproveedor de servicios o la identidad del huésped debe ser utilizado.

Además de (o en lugar de) la identidad del usuario, un autor de PP / ST podría estar más preocupado por el tiempo de lase recibió información. Por ejemplo, cuando una oferta expira en una fecha determinada, los pedidos deben ser recibidosantes de una fecha determinada con el fin de ser considerado. En tales casos, estos requisitos se pueden personalizar paraproporcionar una indicación de fecha y hora (hora de recepción).

D.2.2 FCO_NRR.1 prueba selectiva de recibo

Operaciones D.2.2.1


En FCO_NRR.1.1, t él PP / ST autor deberá rellenar los tipos de información sujeta a la prueba de la recepciónde función, por ejemplo, mensajes de correo electrónico.

Página 151

ISO / IEC 15408-2:2008 (E)


En FCO_NRR.1.1, t él PP / ST autor debe especificar el usuario / sujeto que puede solicitar un acuse de recibo.


En FCO_NRR.1.1, t él PP / ST autor, depende de la selección, debería especificar las terceras personas que puedensolicitar acuse de recibo. Un tercero podría ser un árbitro, juez o cuerpo legal.

En FCO_NRR.1.2, el autor PP / SAN debe completar la lista de los atributos que deben estar relacionados con la información,por ejemplo, la identidad del destinatario, la hora de recepción, y el lugar de la recepción.

En FCO_NRR.1.2, t él PP / ST autor debe rellenar la lista de campos de información con los campos de lainformación sobre la cual los atributos proporcionan evidencia de la recepción, tales como el cuerpo de un mensaje.


En FCO_NRR.1.3, t él PP / ST autor debe especificar el usuario / asignaturas que puedan verificar el acuse de recibo.


En FCO_NRR.1.3, el autor PP / ST debe rellenar la lista de limitaciones bajo las cuales las pruebas pueden serverificada. Por ejemplo, la evidencia sólo puede ser verificada dentro de un intervalo de tiempo de 24 horas. La cesión de"Inmediata" o "indefinido" es aceptable.

En FCO_NRR.1.3, t él PP / SAN autor, depende de la selección, debe especificar los terceros que puedenverificar el acuse de recibo.

Prueba D.2.3 FCO_NRR.2 forzada de recibo

Operaciones D.2.3.1


En FCO_NRR.2.1, t él PP / ST autor deberá rellenar los tipos de información sujeta a la prueba de la recepciónfunción, por ejemplo, mensajes de correo electrónico.

En FCO_NRR.2.2, el autor PP / ST debe completar la lista de los atributos que se pueden vincular a la información;por ejemplo, la identidad del destinatario, la hora de recepción, y el lugar de la recepción.

En FCO_NRR.2.2, t él PP / ST autor debe rellenar la lista de campos de información con los campos de lainformación sobre la cual los atributos proporcionan evidencia de la recepción, tales como el cuerpo de un mensaje.


En FCO_NRR.2.3, t él PP / ST autor debe especificar el usuario / asignaturas que puedan verificar el acuse de recibo.


En FCO_NRR.2.3, el autor PP / ST debe rellenar la lista de limitaciones bajo las cuales las pruebas pueden serverificada. Por ejemplo, la evidencia sólo puede ser verificada dentro de un intervalo de tiempo de 24 horas. La cesión de"Inmediata" o "indefinido" es aceptable.

En FCO_NRR.2.3, t él PP / ST autor, depende de la selección, debe especificar los terceros que pueden

12/6/2014 ISO / IEC 15408-2



verificar el acuse de recibo. Un tercero podría ser un árbitro, juez o cuerpo legal.

Página 152

ISO / IEC 15408-2:2008 (E)


Anexo E

(Normativo)

Clase FCS: Apoyo criptográfico

La TSF puede emplear la funcionalidad criptográfica para ayudar a satisfacer varios objetivos de seguridad de alto nivel. Estosincluir (pero no se limitan a): identificación y autenticación, no repudio, ruta de confianza, el canal de confianzay separación de datos. Esta clase se utiliza cuando el TOE implementa funciones criptográficas, laimplementación de lo que podría ser en el hardware, firmware y / o software.

Los FCS: Apoyo criptográfico clase se compone de dos familias: la gestión de claves criptográficas(FCS_CKM) una operación criptográfica nd (FCS_COP). La gestión de claves de cifrado (FCS_CKM)familia ocupa de los aspectos de gestión de claves criptográficas, mientras que la operación de cifrado(FCS_COP) fa milia se ocupa de la utilización práctica de esas claves criptográficas.

Para cada método criptográfico de generación de claves implementado por el TOE, si la hay, el autor de PP / ST debeseleccionar la generación de claves de cifrado FCS_CKM.1 componente.

Para cada método de distribución de claves criptográficas implementado por el TOE, si la hay, el autor de PP / ST debeseleccionar la distribución de la clave de cifrado FCS_CKM.2 componente.

Para cada método de acceso clave criptográfica implementado por el TOE, si la hay, el autor de PP / ST debe seleccionarla clave de acceso FCS_CKM.3 criptográfico componente.

Para cada método de destrucción de claves criptográficas implementado por el TOE, si la hay, el autor de PP / ST debeseleccionar la destrucción clave criptográfica FCS_CKM.4 componente.

Para cada operación criptográfica (como la firma digital, cifrado de datos, de acuerdo de claves, hash seguro,etc) realizado por el TOE, si la hay, el autor PP / ST debe seleccionar th e FCS_COP.1 operación criptográficacomponente.

Funcionalidad de cifrado se puede utilizar para cumplir los objetivos especificados en clas s FCO: Comunicación, y enfamilias de autenticación de datos (FDP_DAU), integridad de los datos almacenados (FDP_SDI), Inter-TSF confidencialidad de los datos de usuariotransferir protección (FDP_UCT), la protección de transferencia de integridad de los datos de usuario Inter-TSF (FDP_UIT), Especificación desecretos (FIA_SOS), U autentificación ser (FIA_UAU), para cumplir con una variedad de objetivos. En los casos en losfuncionalidad criptográfica se utiliza para cumplir con los objetivos de otras clases, los componentes funcionales individualesespecificar los objetivos que la funcionalidad criptográfica debe satisfacer. Los objetivos en clas s FCS: criptográficosel apoyo se debe utilizar cuando la funcionalidad criptográfica del TOE es buscado por los consumidores.

12/6/2014 ISO / IEC 15408-2


Página 153

ISO / IEC 15408-2:2008 (E)


Figura E.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura E.1 - FCS: Clase de Apoyo criptográfico descomposición

La gestión de claves de cifrado E.1 (FCS_CKM)

Notas de usuario E.1.1

Las claves criptográficas deben ser administrados durante toda su vida. Los eventos típicos en el ciclo de vida de unclave criptográfica incluye (pero no se limitan a): la generación, la distribución, la entrada, el almacenamiento, el acceso (por ejemplo, copia de seguridad,custodia, archivo, recuperación) y la destrucción.

La inclusión de otras etapas depende de la estrategia de gestión de claves está aplicando, como el TOEno tiene por qué estar involucrado en todo el ciclo de vida de claves (por ejemplo, el TOE sólo puede generar y distribuir criptográficateclas).

Esta familia tiene por objeto apoyar el ciclo de vida de claves criptográficas y en consecuencia define los requisitos paralas siguientes actividades: generación de claves criptográficas, distribución de claves criptográficas, acceso a claves criptográficasy la destrucción de claves criptográficas. Esta familia debe incluirse siempre que haya requisitos funcionalespara la gestión de claves criptográficas.

Si la generación de datos de auditoría de seguridad (FAU_GEN) S eguridad Auditoría de generación de datos está incluido en el PP / ST a continuación, enel contexto de los hechos objeto de la auditoría:

a) Los atributos de los objetos pueden incluir el usuario asignado a la clave criptográfica, el rol del usuario, eloperación criptográfica que la clave de cifrado se va a utilizar para, el identificador de clave criptográfica yel período de validez de claves criptográficas.

b) El valor del objeto puede incluir los valores de la clave de cifrado (s) y los parámetros de exclusión de cualquier información sensibleinformación (como claves criptográficas secretas o privadas).

Típicamente, los números aleatorios se usan para generar claves criptográficas. Si este es el caso, TH es FCS_CKM.1La generación de claves de cifrado se debe utilizar en lugar de la FIA_SOS.2 componente TSF Generación desecretos. En los casos en que se requiere la generación de números al azar para otros fines que para la generación declaves criptográficas, el componente FIA_SOS.2 TSF generación de secretos deben ser utilizados.

Página 154

ISO / IEC 15408-2:2008 (E)

La generación de claves de cifrado E.1.2 FCS_CKM.1

E.1.2.1 Notas de la aplicación de usuario

Este componente requiere los tamaños de clave y el método utilizados para generar las claves de cifrado para ser

12/6/2014 ISO / IEC 15408-2



especificada, esto puede ser de acuerdo con un estándar asignado. Se debe utilizar para especificar el criptográficatamaños de clave y el método (por ejemplo, algoritmo) utilizados para generar las claves criptográficas. Sólo una instancia delse necesita componente para el mismo método y múltiples tamaños de clave. El tamaño de la clave podría ser común o diferentepara las diversas entidades, y podría ser o bien la señal de entrada o la salida del método.

E.1.2.2 Operaciones

E.1.2.2.1 Asignación

En FCS_CKM.1.1, t él PP / ST autor debe especificar el algoritmo de generación de claves criptográficas para ser utilizado.

En FCS_CKM.1.1, el autor PP / ST debe especificar los tamaños de clave que se utilizarán. Los tamaños de claveespecificada debe ser apropiado para el algoritmo y su uso previsto.

En FCS_CKM.1.1, t él PP / ST autor debe especificar el estándar asignado que documenta el método utilizado paragenerar claves criptográficas. El estándar asignado puede comprender ninguna, una o más normas realespublicaciones, por ejemplo, de nivel internacional, nacional, de la industria o de las normas de organización.

Distribución de la clave de cifrado E.1.3 FCS_CKM.2


Este componente requiere que el método utilizado para distribuir las claves criptográficas que se especifiquen, esto puede ser enarreglo a una norma asignada.

E.1.3.2 Operaciones


En FCS_CKM.2.1, t él PP / ST autor debe especificar el método de distribución de claves criptográficas para ser utilizado.

En FCS_CKM.2.1, t él PP / ST autor debe especificar el estándar asignado que documenta el método utilizado paradistribuir claves criptográficas. El estándar asignado puede comprender ninguna, una o más normas realespublicaciones, por ejemplo, de nivel internacional, nacional, de la industria o de las normas de organización.

E.1.4 FCS_CKM.3 criptográfico clave de acceso


Este componente requiere el método utilizado para acceder a las claves criptográficas ser especificada, esto puede ser enarreglo a una norma asignada.

E.1.4.2 Operaciones


En FCS_CKM.3.1, el autor PP / ST debe especificar el tipo de acceso clave criptográfica que se utiliza.Ejemplos de tipos de acceso clave criptográfica incluyen (pero no se limitan a) de copia de seguridad de claves criptográficas,archivística criptográfico de clave, depósito de claves de cifrado y la recuperación de claves criptográficas.

En FCS_CKM.3.1, t él PP / ST autor debe especificar el método de acceso a claves criptográficas que se utilizará.

Página 155

ISO / IEC 15408-2:2008 (E)

En FCS_CKM.3.1, t él PP / ST autor debe especificar el estándar asignado que documenta el método utilizado paraacceso a claves criptográficas. El estándar asignado puede comprender ninguna, una o más normas realespublicaciones, por ejemplo, de nivel internacional, nacional, de la industria o de las normas de organización.

Destrucción de claves E.1.5 FCS_CKM.4 criptográficos


Este componente requiere que el método utilizado para destruir especificarse claves criptográficas, esto puede ser enarreglo a una norma asignada.

E.1.5.2 Operaciones


En FCS_CKM.4.1, el autor de PP / ST debe especificar el método de clave de la destrucción a ser usado para destruirclaves criptográficas.

12/6/2014 ISO / IEC 15408-2



En FCS_CKM.4.1, t él PP / SAN autor debe especificar el estándar asignado que documenta al método utilizado paradestruir las claves criptográficas. El estándar asignado puede comprender ninguna, una o más normas realespublicaciones, por ejemplo, de nivel internacional, nacional, de la industria o de las normas de organización.

E.2 operación criptográfica (FCS_COP)

Notas de usuario E.2.1

Una operación criptográfica puede tener el modo (s) de cifrado de operación asociada con ella. Si este es el caso,a continuación, se debe especificar el modo de cifrado (s). Ejemplos de modos de cifrado de atención es de cifradoencadenamiento de bloques, el modo de realimentación de salida, modo de libro de código electrónico, y el modo de cifrado de.

Operaciones criptográficas pueden ser utilizados para apoyar uno o más servicios de seguridad del TOE. El criptográficosoperación (FCS_COP) C omponente puede necesitar ser iterado más de una vez en función de:

a) la aplicación de usuario para el que se está utilizando el servicio de seguridad,

b) el uso de diferentes algoritmos criptográficos y / o tamaños de clave,

c) el tipo o la sensibilidad de los datos que están siendo operados.

Si la generación de datos de auditoría de seguridad (FAU_GEN) S de generación de datos de auditoría ecurity está incluido en el PP / ST a continuación, enel contexto de los sucesos de operación de cifrado que está siendo auditada:

a) El tipo de operación criptográfica pueden incluir la generación de firmas digitales y / o verificación,la generación de la suma de comprobación criptográfica de integridad y / o para la verificación de la suma de comprobación, control seguro(Resumen del mensaje) el cálculo, el cifrado de datos y / o descifrado, el cifrado de claves criptográficas y / odescifrado, el acuerdo de claves criptográficas y la generación de números aleatorios.

b) Los sujetos atributos pueden incluir papel sujeto (s) y usuario (s) asociados con el sujeto.

c) Los atributos de los objetos pueden incluir el usuario asignado a la clave criptográfica, el papel de usuario, cifradooperación de la clave de cifrado se va a utilizar para, identificador de clave criptográfica, y la clave criptográficaperíodo de validez.

Página 156

ISO / IEC 15408-2:2008 (E)

Operación E.2.2 FCS_COP.1 criptográficos


Este componente requiere el algoritmo de cifrado y tamaño de clave utilizada para realizar criptográfico especificadooperación (s) que puede estar basado en una norma asignada.

E.2.2.2 Operaciones


En FCS_COP.1.1, el autor PP / ST debería especificar las operaciones criptográficas que se realiza. Típicooperaciones criptográficas incluyen la generación de firma digital y / o verificación, suma de control criptográficageneración de integridad y / o para la verificación de la suma de comprobación, control seguro (resumen del mensaje) el cálculo, los datoscifrado y / o descifrado, el cifrado de claves criptográficas y / o descifrado, el acuerdo de claves criptográficasy la generación de número aleatorio. La operación criptográfica se puede realizar en los datos de usuario o datos de TSF.

En FCS_COP.1.1, el autor de PP / ST debe especificar el algoritmo de cifrado a ser utilizado. Típicoalgoritmos criptográficos incluyen, pero no se limitan a, DES, RSA e IDEA.

En FCS_COP.1.1, t él PP / ST autor debe especificar los tamaños de clave que se utilizarán. Los tamaños de claveespecificada debe ser apropiado para el algoritmo y su uso previsto.

En FCS_COP.1.1, t él PP / ST autor debe especificar el estándar asignado que documenta cómo los identificanoperación criptográfica (s) se llevan a cabo. El estándar asignado puede comprender ninguno, uno o más realpublicaciones de estándares, por ejemplo, de nivel internacional, nacional, de la industria o de las normas de organización.

12/6/2014 ISO / IEC 15408-2



Página 157

ISO / IEC 15408-2:2008 (E)

Anexo F

(Normativo)

Clase FDP: protección de los datos del usuario

Esta clase contiene familias que especifican los requisitos relacionados con la protección de los datos del usuario. Esta clase difiere de la FIAy FPT en ese FDP: protección de los datos de usuario especifica los componentes de protección de datos de usuario, especifica la FIAcomponentes para proteger los atributos asociados con el usuario, y FPT especifica componentes para proteger TSFinformación.

La clase no contiene requisitos explícitos para los controles tradicionales de acceso obligatorio (MAC) oControles de Acceso Discrecional (DAC tradicional); sin embargo, tales requisitos pueden ser construidos utilizandocomponentes de esta clase.

FDP: protección de los datos del usuario doe s no trata explícitamente la confidencialidad, integridad o disponibilidad, ya que los tres sonmás a menudo entrelazadas en la política y los mecanismos. Sin embargo, la política de seguridad del TOE debe adecuadamentecubrir estos tres objetivos en el PP / ST.

Un último aspecto de esta clase es que especifica el control de acceso en términos de "operaciones". Una operación se define comoun tipo específico de acceso sobre un objeto específico. Depende del nivel de abstracción del autor PP / STsi estas operaciones se describen como "leer" y / o "escribir" las operaciones, o como operaciones más complejastales como "actualizar la base de datos".

Las políticas de control de acceso son las condiciones que controlan el acceso a la información contenida. Los atributosrepresentar atributos del recipiente. Una vez que la información está fuera del recipiente, el descriptor de acceso es libre demodificar dicha información, incluyendo escribir la información en un recipiente diferente con diferentes atributos. PorPor el contrario, un flujo de información de las políticas de control de acceso a la información, independientemente del contenedor. Laatributos de la información, que pueden estar asociados con los atributos del envase (o no, como enel caso de una base de datos multi-nivel) se quede con la información a medida que avanza. El descriptor de acceso no tiene lacapacidad, en ausencia de una autorización expresa, para cambiar los atributos de la información.

Esta clase no está destinado a ser una taxonomía completa de las políticas de acceso de TI, ya que otros pueden ser imaginados. Aquellospolíticas incluidas aquí son simplemente aquellos para los que la experiencia actual con los sistemas reales proporciona una base paraespecificar los requisitos. Puede haber otras formas de intenciones que no son capturados en las definiciones aquí.

Por ejemplo, uno podría imaginar una meta de que los controles (y definido por el usuario) impuesta por el usuario en la informaciónflujo (por ejemplo, una aplicación automatizada de la NO EXTERIOR manejo de advertencia). Tales conceptos podrían ser

12/6/2014 ISO / IEC 15408-2



manejados como refinamientos de o ampliaciones de la FDP: protección de datos de usuario de componentes.

Por último, es importante cuando se mira en los componentes i n FDP: Usuario protecció de datos n recordar que estoscomponentes son los requisitos para las funciones que pueden ser implementadas por un mecanismo que también sirve opodría servir a otro propósito. Por ejemplo, es posible construir una política de control de acceso ( control de accesopolítica (FDP_ACC)) t sombrero usa etiquetas (FDP_IFF.1 atributos de seguridad simples) como la base del control de accesomecanismo.

Un conjunto de SFR puede abarcar muchas de las políticas de seguridad de función (SFP), cada uno a ser identificados por las dos políticascomponentes orientados Una política de control de cceso (FDP_ACC), una política de control de flujo de información nd (FDP_IFC). Estospolíticas típicamente tendrán aspectos de confidencialidad, integridad y disponibilidad en cuenta según sea necesario, parasatisfacer los requisitos de los pies. Se debe tener cuidado para asegurar que todos los objetos están cubiertas por al menos un SFPy que no existen los conflictos derivados de la aplicación de los múltiples programas de alimentación complementaria.

Cuando se construye un PP / ST utilizando componentes de la FD P: Usuario protección de datos cl culo, la siguiente informaciónproporciona orientación sobre dónde buscar y qué seleccionar de la clase.

Los requisitos establecidos en la F DP: protección de datos de usuario de clase se definen en términos de un conjunto de SFR que seimplementar un SFP. Dado que una TOE puede implementar múltiples SFP simultáneamente, el autor PP / ST debe especificar

Página 158

ISO / IEC 15408-2:2008 (E)

el nombre de cada SFP, por lo que se puede hacer referencia a otras familias. Este nombre se utilizará en cadacomponente seleccionado para indicar que se está utilizando como parte de la definición de los requisitos para que la SFP. Estepermite al autor para indicar fácilmente el alcance de las operaciones, tales como objetos cubiertos, las operaciones cubiertas,usuarios autorizados, etc

Cada instancia de un componente se puede aplicar a una sola SFP. Por lo tanto, si se especifica un SFP en un componenteentonces este SFP se aplicará a todos los elementos de este componente. Los componentes se pueden crear instancias múltiplesveces dentro de un PP / ST para tener en cuenta diferentes políticas si así se desea.

La clave para la selección de los componentes de esta familia es tener un conjunto bien definido de objetivos de seguridad para TOEpermitir la selección adecuada de los componentes de los dos componentes de la política; política de control de acceso (FDP_ACC)y Flujo de información política de control (FDP_IFC) . En la política de control de acceso (FDP_ACC) y el flujo de informaciónpolítica de control (FDP_IFC) r espectively, todas las políticas de control de acceso y todas las políticas de control de flujo de la información sonnombrado. Además, el alcance de la fiscalización de estos componentes en función de los sujetos, objetos ylas operaciones relacionadas con esta funcionalidad de seguridad. Los nombres de estas políticas están destinados a ser utilizados en todoel resto de los componentes funcionales que tienen una operación que requiere una asignación o selección deun "control de acceso SFP" o un "control de flujo de información SFP". Las reglas que definen la funcionalidad de laSFP de control del flujo de control de acceso y el nombre de información se definen en las funciones de control de acceso(FDP_ACF) un d Información funciones de control de flujo (FDP_IFF) familias (respectivamente).

Los siguientes pasos son una guía sobre cómo se aplica esta clase en la construcción de un PP / ST:

a) Identificar las políticas que se aplican desde la política de control de acceso (FDP_ACC), y el flujo de información(FDP_IFC) política de control de las familias. Estas familias definen el alcance del control de la política, la granularidad decontrolar y pueden identificar algunas reglas a seguir con la política.

b) Identificar los componentes y realizar cualquier operación aplicable en los componentes de la política. Laoperaciones de asignación se puede realizar en general (por ejemplo, con una declaración "Todos los archivos") o específicamente("Los archivos de" A "," B ", etc) dependiendo del nivel de detalle que se conoce.

c) Identificar los componentes de función de aplicación de las funciones de control de acceso (FDP_ACF) yFunciones de control de flujo de la información (FDP_IFF) las familias para hacer frente a las familias de directivas con nombre de accesopolítica de control (FDP_ACC) una política de control de flujo de información nd (FDP_IFC). Realizar las operaciones para hacerlos componentes definen las reglas a ser aplicadas por las directivas con nombre. Esto debería hacer que los componentesajustarse a los requisitos de la función seleccionada o previstos para ser construido.

d) Identificar que tendrá la capacidad de controlar y cambiar los atributos de seguridad en virtud de la función, por ejemplo, sóloun administrador de seguridad, sólo el propietario del objeto, etc Seleccione los componentes apropiados de FMT:Gestión de la seguridad de un nd realizar las operaciones. Matices pueden ser útiles para identificar desaparecidoscaracterísticas, como que algunos o todos los cambios se deben hacer a través de ruta de confianza.

e) Identificar los componentes apropiados de la F MT: Gestión de la seguridad para los valores iniciales para el nuevoobjetos y sujetos.

f) Identificar los componentes de rollback aplicables desde el Rollback (FDP_ROL) f amilia.

g) Identificar los requisitos de protección de la información residuales aplicables a partir de la R información esidualprotección (FDP_RIP) f amilia.

h) Identificar los componentes de importación o de exportación aplicables, y cómo se deben manejar los atributos de seguridaddurante la importación y exportación, a la importación desde fuera del TOE (FDP_ITC) y Exportar en el TOE(FDP_ETC) f as familias.

12/6/2014 ISO / IEC 15408-2



i) Identificar los componentes de comunicación TOE internos aplicables a partir de la que la transferencia TOE nternal(FDP_ITT) f amilia.

j) Identificar los requisitos para la protección de la integridad de la información almacenada en la integridad de los datos almacenados(FDP_SDI).

Página 159

ISO / IEC 15408-2:2008 (E)


k) Identificar los componentes de comunicación entre TSF aplicables a partir de la De la confidencialidad de datos de usuario ter-TSFprotección de transferencia (FDP_UCT) o r Inter-TSF protección transferencia integridad de los datos de usuario (FDP_UIT) familias.

Figura F.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura F.1 - FDP: Usuario clase de protección de datos de descomposición

12/6/2014 ISO / IEC 15408-2


Página 160

ISO / IEC 15408-2:2008 (E)


Política de control de acceso F.1 (FDP_ACC)

F.1.1 notas de usuario

Esta familia se basa en el concepto de controles arbitrarios en la interacción de los sujetos y objetos. Laalcance y finalidad de los controles se basa en los atributos del descriptor de acceso (sujeto), los atributos de laestá accediendo contenedor (objeto), las acciones (operaciones) y las reglas de control de acceso asociada.

Los componentes de esta familia son capaces de identificar los SFP de control de acceso (por nombre) para ser aplicadas porlos tradicionales Control de Acceso Discrecional (DAC) mecanismos. Además, define los sujetos, objetos yoperaciones que están cubiertos por los SFP de control de acceso identificados. Las reglas que definen la funcionalidad de unSFP de control de acceso se define por otras familias, a tales funciones de control de acceso s (FDP_ACF) y la exportacióndel TOE (FDP_ETC). T él los nombres de los SFP de control de acceso definidas en la política de control de acceso(FDP_ACC) AR correo destinado a ser utilizado en todo el resto de los componentes funcionales que tienen unoperación que exige una asignación o selección de un "SFP de control de acceso."

La SFP de control de acceso abarca un conjunto de trillizos: sujeto, objeto, y las operaciones. Por lo tanto, un sujeto puede sercubierto por múltiples SFP de control de acceso pero sólo con respecto a una operación diferente o un objeto diferente. DePor supuesto, el mismo se aplica a los objetos y las operaciones.

Un aspecto crítico de una función de control de acceso que impone un SFP de control de acceso es la capacidad para que los usuariosmodificar los atributos que intervienen en las decisiones de control de acceso. Th política de control electrónico de acceso (FDP_ACC) familia haceno abordar estos aspectos. Algunos de estos requisitos se quedan sin definir, pero se puede agregar como refinamientos,mientras que otros están cubiertos en otras partes de otras familias y clases como un s FMT: gestión de la seguridad.

No hay requisitos de auditoría en la política de control de acceso (FDP_ACC) como esta familia especifica de control de accesoRequisitos SFP. Requisitos de auditoría se encuentran en las familias especificando funciones para satisfacer el accesoSFP de control identificados en esta familia.

Esta familia ofrece un autor de PP / ST la posibilidad de especificar una serie de políticas, por ejemplo, un acceso fijoSFP de control que se aplicará a un ámbito de control, y un programa de alimentación de control de acceso flexible para ser definido para undiferente ámbito de control. Para especificar más de una política de control de acceso, los componentes de esta familiase pueden repetir varias veces en un PP / ST para diferentes subconjuntos de operaciones y objetos. Esta voluntadacomodar las TOE que contienen múltiples políticas, abordando cada uno un determinado conjunto de operaciones y objetos.En otras palabras, el autor PP / ST debe especificar la información requerida en el componente de ACC para cada uno delos SFP de control de acceso que el TSF hará cumplir. Por ejemplo, una TOE que incorpora tres de control de accesoSFP, cada uno cubre sólo un subconjunto de los objetos, temas, y las operaciones dentro de la TOE, contendrá unaFDP_ACC.1 Subconjunto de control de acceso c omponente para cada uno de los tres SFP de control de acceso, lo que exige untotal de thre e FDP_ACC.1 subconjunto de control de acceso componentes.

Control de acceso F.1.2 FDP_ACC.1 Subset

F.1.2.1 Notas de la aplicación de usuario

Los términos objeto y sujeto se refieren a elementos genéricos en el TOE. Para que una política sea implementable, ellas entidades deben estar claramente identificados. Para un PP, los objetos y las operaciones pueden ser expresados como tipos, tales como:objetos con nombre, repositorios de datos, observan accesos, etc Para una TOE específica estos términos genéricos (sujeto,objeto) debe ser refinados, por ejemplo, archivos, registros, los puertos, los demonios, convocatorias, etc

Este componente se especifica que la póliza cubre un conjunto bien definido de las operaciones en algún subconjunto de laobjetos. Se coloca ninguna restricción sobre las operaciones fuera del conjunto - incluyendo las operaciones sobre los objetos para los queotras operaciones son controladas.

F.1.2.2 Operaciones

F.1.2.2.1 Asignación

En FDP_ACC.1.1, el autor PP / ST debe especificar un nombre único SFP de control de acceso que deban hacer cumplirla TSF.

Página 161

ISO / IEC 15408-2:2008 (E)

En FDP_ACC.1.1, t él PP / ST autor debe especificar la lista de sujetos, objetos y las operaciones entre sujetosy objetos cubiertos por la SFP.

12/6/2014 ISO / IEC 15408-2



Control de acceso completa F.1.3 FDP_ACC.2


Este componente requiere que todas las posibles operaciones sobre objetos, que se incluyen en la SFP, están cubiertos porun SFP de control de acceso.

El autor PP / ST debe demostrar que cada combinación de objetos y sujetos está cubierto por un accesoSFP control.

F.1.3.2 Operaciones


En FDP_ACC.2.1, el autor PP / ST debe especificar un nombre único SFP de control de acceso que deban hacer cumplirla TSF.

En FDP_ACC.2.1, t él PP / ST autor debe especificar la lista de sujetos y objetos cubiertos por la SFP. Todooperaciones entre los sujetos y los objetos serán cubiertas por el SFP.

Funciones de control de acceso F.2 (FDP_ACF)


Esta familia se describen las reglas para las funciones específicas que pueden implementar una política de control de acceso con nombre enPolítica de control de acceso (FDP_ACC) wh ich también especifica el alcance del control de la política.

Esta familia proporciona un autor PP / ST la capacidad para describir las reglas de control de acceso. Esto resulta en unaTOE donde el acceso a los objetos no cambiará. Un ejemplo de un objeto, es "mensaje del día",que sólo es legible por todos, y cambiante sólo por el administrador autorizado. Esta familia también proporciona laPP / ST autor con la capacidad de describir las normas que establecen excepciones a las reglas de control de acceso general.Tales excepciones serían permitir o denegar la autorización para acceder a un objeto, ya sea de forma explícita.

No hay componentes explícitos para especificar otras posibles funciones, como el control de dos personas, la secuenciareglas para las operaciones o los controles de exclusión. Sin embargo, estos mecanismos, así como tradicional DACmecanismos, se pueden representar con los componentes existentes, mediante la cuidadosa redacción de las reglas de control de acceso.

Una variedad de funcionalidad de control de acceso aceptable puede ser especificado en esta familia, tales como:

• Listas de control de acceso (ACL)

• Especificaciones de control de acceso basadas en el tiempo

• Especificaciones de control de acceso basado en Origen

• Atributos de control de acceso controlado por sus propietarios

Control de acceso basado atributo F.2.2 FDP_ACF.1 Seguridad


Este componente proporciona los requisitos para un mecanismo que interviene en el control de acceso basado en la seguridadatributos asociados a los sujetos y objetos. Cada objeto y el sujeto tiene un conjunto de atributos asociados,tales como la ubicación, el tiempo de la creación, los derechos de acceso (por ejemplo, listas de control de acceso (ACL)). Este componente permite

Página 162

ISO / IEC 15408-2:2008 (E)

el autor de PP / ST para especificar los atributos que se utilizarán para la mediación de control de acceso. Este componenteadmite un régimen de control de acceso, el uso de estos atributos, que se determine.

Los ejemplos de los atributos que un autor de PP / ST podría asignar se presentan en los siguientes párrafos.

Un atributo de identidad puede estar asociada con los usuarios, los sujetos u objetos que se utilizarán para la mediación. Ejemplos detales atributos pueden ser el nombre de la imagen del programa utilizado en la creación del sujeto, o una garantíaatributo asignado a la imagen del programa.

Una vez atributo puede utilizarse para especificar que el acceso será autorizado durante ciertas horas del día, duranteciertos días de la semana, o durante un determinado año calendario.

Un atributo de ubicación podría especificar si la ubicación es la ubicación de la solicitud de la operación, elubicación en la que se llevará a cabo la operación, o ambos. Se podría basarse en tablas internas para traducir elinterfaces lógicas de la TSF en lugares como a través de los lugares de conexión, lugares de CPU, etc

12/6/2014 ISO / IEC 15408-2



Un atributo de agrupación permite que un solo grupo de usuarios a estar asociada con una operación para los fines decontrol de acceso. Si es necesario, la operación de refinamiento se debe utilizar para especificar el número máximo degrupos definibles, el número máximo de miembros de un grupo, y el número máximo de grupos a los que un usuarioal mismo tiempo puede ser asociado.

Este componente también proporciona los requisitos para las funciones de seguridad de control de acceso para poder explícitamenteautorizar o denegar el acceso a un objeto como fundamento los atributos de seguridad. Esto podría ser utilizado para proporcionar privilegio,los derechos de acceso, o autorizaciones de acceso dentro de la TOE. Tales privilegios, derechos o autorizaciones podrían aplicarse alos usuarios, los sujetos (que representan a los usuarios o aplicaciones), y objetos.

F.2.2.2 Operaciones


En FDP_ACF.1.1, el autor PP / ST debe especificar un nombre de SFP de control de acceso que el TSF debe aplicar.El nombre de la SFP de control de acceso, y el ámbito de control para que la política se definen en los componentes dePolítica de control de acceso (FDP_ACC).

En FDP_ACF.1.1, el autor PP / ST debe especificar, por cada uno controlado sujeto y objeto, la seguridadatributos y / o grupos con nombre de atributos de seguridad que la función va a utilizar en la especificación de las reglas.Por ejemplo, tales atributos pueden ser cosas tales como la identidad del usuario, la identidad sujeto, papel, hora del día,ubicación, ACL, o cualquier otro atributo especificado por el autor de PP / ST. Grupos de atributos de seguridad con nombre puedeser especificado para proporcionar un medio conveniente para referirse a varios atributos de seguridad. Los grupos con nombre podríaproporcionar una forma útil para asociar "roles" que definí n de gestión de Seguridad roles (FMT_SMR), un nd todos de suatributos relevantes, con los sujetos. En otras palabras, cada función podría referirse a un grupo llamado de los atributos.

En FDP_ACF.1.2, el autor PP / ST debe especificar las reglas que rigen el acceso SFP entre sujetosy objetos usando operaciones controladas sobre objetos controlados controlada. Estas reglas especifican cuando el acceso esconcedido o denegado. Puede especificar las funciones generales de control de acceso (por ejemplo, los bits de permiso típicos) o granularfunciones de control de acceso (ACL) por ejemplo.

En FDP_ACF.1.3, el autor PP / ST debería especificar las normas, sobre la base de atributos de seguridad, que de forma explícitaautorizar el acceso de los sujetos a los objetos que se utilizarán para autorizar explícitamente el acceso. Estas reglas están enademás de los especificados i n FDP_ACF.1.1. Ellos están incluidos en FDP_ACF.1.3 ya que están destinadas acontener excepciones a las reglas en FDP_ACF.1.1. Un ejemplo de reglas para autorizar explícitamente el acceso se basaen un vector de privilegio asociado a un tema que siempre garantiza el acceso a los objetos cubiertos por el accesola SFP de control que haya sido especificado. Si no se desea tal capacidad, entonces el autor de PP / ST debe especificar"Ninguno".

En FDP_ACF.1.4, t él PP / ST autor debe especificar las reglas, en base a los atributos de seguridad, que se niegan de forma explícitael acceso de los sujetos a los objetos. Estas reglas son adicionales a los especificados i n FDP_ACF.1.1 . Ellos sonincluido en FDP_ACF.1.4 , ya que están destinados a contener excepciones a las reglas en FDP_ACF.1.1. Unejemplo de reglas para denegar explícitamente el acceso se basa en un vector de privilegio asociado con un tema que siempre

Página 163

ISO / IEC 15408-2:2008 (E)

niega el acceso a los objetos cubiertos por la SFP de control de acceso que se ha especificado. Si tal capacidad no esdeseada, entonces el autor PP / ST debe especificar "none".

Autenticación de datos F.3 (FDP_DAU)


Esta familia describe funciones específicas que pueden ser utilizados para autenticar los datos "estáticos".

Los componentes de esta familia se van a utilizar cuando no es un requisito para la autenticación de los datos "estáticos", es decir,donde los datos se va a firmar, pero que no se transmite. (Tenga en cuenta que el no repudio de origen (FCO_NRO) familiaprevé el no repudio de origen de la información recibida durante el intercambio de datos.)

Datos de autenticación F.3.2 FDP_DAU.1 básico


Este componente puede ser satisfecha por las funciones hash unidireccionales (suma de comprobación criptográfica, huellas digitales, mensajesdigerir), para generar un valor hash para un documento definitivo que puede usarse como verificación de la validez oautenticidad de su contenido de información.

F.3.2.2 Operaciones


En FDP_DAU.1.1, t él PP / ST autor debe especificar la lista de objetos o tipos de información para los que el TSF

12/6/2014 ISO / IEC 15408-2



deberá ser capaz de generar pruebas de autenticación de datos.

En FDP_DAU.1.2, t él PP / ST autor debe especificar la lista de temas que tendrán la capacidad de verificar los datospruebas de autenticación para los objetos identificados en el elemento anterior. La lista de temas podría ser muyespecífica, si se conocen los sujetos, o podría ser más genérico y se refieren a un "tipo" de sujetos tales comopapel identificado.

F.3.3 FDP_DAU.2 datos Autenticación con Identidad de Garante


Este componente, además, requiere la capacidad de verificar la identidad del usuario que proporciona la garantía deautenticidad (por ejemplo, una tercera parte de confianza).

F.3.3.2 Operaciones


En FDP_DAU.2.1, t él PP / ST autor debe especificar la lista de objetos o tipos de información para los que el TSFdeberá ser capaz de generar pruebas de autenticación de datos.

En FDP_DAU.2.2, t él PP / ST autor debe especificar la lista de temas que tendrán la capacidad de verificar los datospruebas de autenticación para los objetos identificados en el elemento anterior, así como la identidad del usuario quecreado las pruebas de autenticación de datos.

F.4 Exportar en el TOE (FDP_ETC)


Esta familia define funciones para exportar mediada TSF de datos de usuario en el TOE de forma que su seguridadatributos o bien se puede conservar de manera explícita o puede ser ignorada una vez que ha sido exportado. La consistencia de estosatributos de seguridad se abordan b y consistencia de los datos entre TSF TSF (FPT_TDC).

Página 164

ISO / IEC 15408-2:2008 (E)

Exportar desde el TOE (FDP_ETC) está preocupado por limitaciones a la exportación y la asociación de atributos de seguridadcon los datos de usuario exportados.

Esta familia, y de la correspondiente importación famil y de importación desde fuera del TOE (FDP_ITC), frente a la forma en laTOE se ocupa de los datos de usuario transferidos dentro y fuera de su control. En principio esta familia se ocupa de laExportadora mediada TSF de datos de usuario y sus atributos relacionados con la seguridad.

Una variedad de actividades podría estar involucrado aquí:

a) la exportación de los datos del usuario sin atributos de seguridad;

b) la exportación de datos de usuario que incluye los atributos de seguridad donde los dos están asociados entre sí y lalos atributos de seguridad de forma inequívoca representan los datos de los usuarios exportados.

Si hay varios programas de alimentación complementaria (control de acceso y / o control de flujo de la información), entonces puede ser apropiado para iterarestos componentes una vez para cada llamada SFP.

F.4.2 FDP_ETC.1 Exportación de los datos de usuario sin atributos de seguridad


Este componente se utiliza para especificar el exportador mediada TSF de los datos del usuario sin la exportación de su seguridadatributos.

F.4.2.2 Operaciones


En FDP_ETC.1.1, t él PP / ST autor debe especificar el SFP de control de acceso (s) y / o el flujo de información de controlSFP (s) que se aplica al exportar los datos del usuario. Los datos de usuario que esta función exportaciones pertenecerán al ámbito dela asignación de estos programas de alimentación complementaria.

F.4.3 FDP_ETC.2 Exportación de los datos de usuario con atributos de seguridad


Los datos de usuario se exporta junto con sus atributos de seguridad. Los atributos de seguridad son inequívocamenteasociado con los datos de usuario. Hay varias maneras de lograr esta asociación. Una manera en que esto puede ser

12/6/2014 ISO / IEC 15408-2



alcanzado es por ubicar juntos físicamente los datos de usuario y los atributos de seguridad (por ejemplo, el mismo disquete), o porel uso de técnicas criptográficas como firmas seguras para asociar los atributos y los datos del usuario. I nter-TSF canal de confianza (FTP_ITC) co ULD puede utilizar para asegurar que los atributos se reciben correctamente en el otroconfianza IT producto noc e consistencia de datos entre TSF TSF (FPT_TDC) se puede utilizar para asegurarse de que losatributos se interpretan correctamente. Además , ruta de confianza (FTP_TRP) se podría utilizar para asegurarse de que elexportación está siendo iniciado por el usuario adecuado.

F.4.3.2 Operaciones


En FDP_ETC.2.1, t él PP / ST autor debe especificar el SFP de control de acceso (s) y / o el flujo de información de controlSFP (s) que se aplica al exportar los datos del usuario. Los datos de usuario que esta función exportaciones pertenecerán al ámbito dela asignación de estos programas de alimentación complementaria.

En FDP_ETC.2.4, t él PP / ST autor debe especificar todas las normas de control de exportación adicionales o "ninguna" si nohay reglas de control de exportación adicionales. Estas reglas se harán cumplir por el TSF, además del accesoSFP de control y / o de información SFP de control de flujo que he seleccionado n FDP_ETC.2.1.

Página 165

ISO / IEC 15408-2:2008 (E)

Política de control de flujo de información F.5 (FDP_IFC)


Esta familia abarca la identificación de los SFP de control del flujo de información; y para cada, especifica el alcance decontrol de la SFP.

Las componentes de esta familia son capaces de identificar los SFP de control del flujo de información que deban hacer cumplirlos mecanismos tradicionales de control de acceso obligatorios que se encontrarían en un dedo del pie. Sin embargo, se vanmás allá de los mecanismos MAC tradicionales y se puede utilizar para identificar y describir la no injerenciapolíticas y estatales-transiciones. Además, define los temas bajo el control de la política, la información bajocontrol de la política, y las operaciones que hacen que la información controlada fluya hacia y desde los sujetos controladospara cada SFP de control del flujo de información en el TOE. El SFP de control de flujo de información se define por otralas familias, tales como funciones de control de flujo de la información (FDP_IF F) y la exportación de la TOE (FDP_ETC). LaSFP de control del flujo de información con nombre aquí en Política de control del flujo (FDP_IFC) están destinados a ser utilizadosen el resto de los componentes funcionales que tienen una operación que requiere una asignación oselección de un "SFP de control del flujo de la información."

Estos componentes son bastante flexibles. Permiten el dominio de control de flujo que se especifica y no hayrequisito de que el mecanismo se basa en etiquetas. Los diferentes elementos de la información de control de flujocomponentes también permiten diferentes grados de excepción a la política.

Cada SFP abarca un conjunto de trillizos: sujeto, la información y las operaciones que hacen que la información fluya hacia yde los sujetos. Algunas políticas de control de flujos de información pueden estar en un nivel muy bajo de detalle y de forma explícitadescribir los sujetos en términos de los procesos dentro de un sistema operativo. Otras políticas de control del flujo de informaciónpuede estar en un nivel alto y describir los sujetos en el sentido genérico de los usuarios o los canales de entrada / salida. Si elpolítica de control de flujo de la información está en un nivel demasiado alto de detalle, es posible que no define claramente la seguridad de TI deseadafunciones. En estos casos, es más conveniente incluir las descripciones de las políticas de control del flujo de informacióncomo objetivos. A continuación, las funciones de seguridad de TI deseados se pueden especificar como un apoyo a esos objetivos.

En el segundo componente (F DP_IFC.2 La información completa de control de flujo), cada información de control de flujo SFPcubrirá todas las operaciones posibles que hacen que la información se refiere el citado SFP fluya hacia y desde los sujetoscubierto por dicho SFP. Además, tendrá que ser cubierta por un SFP todos los flujos de información. Por lo tanto para cada unoacción que hace que la información fluya, habrá un conjunto de reglas que definen si se permite que la acción. Sihay varios programas de alimentación complementaria que sean aplicables para un flujo de información dado, todos los SFP involucradas deben permitir este flujoantes de que se permite que tenga lugar.

Un SFP de control del flujo de información abarca un conjunto bien definido de operaciones. La cobertura puede ser SFP"Completar" con respecto a algunos flujos de información, o puede abordar sólo algunas de las operaciones que afectanel flujo de información.

Un SFP de control de acceso controla el acceso a los objetos que contienen información. Un SFP de control del flujo de informacióncontrola el acceso a la información, independiente de su contenedor. Los atributos de la información, que puedeestar asociados con los atributos del recipiente (o no, como en el caso de una base de datos de múltiples niveles) estanciacon la información a medida que fluye. El descriptor de acceso no tiene la capacidad, en ausencia de una explícitaautorización, para cambiar los atributos de la información.

Los flujos de información y las operaciones se pueden expresar en múltiples niveles. En el caso de un ST, la informaciónflujos y operaciones pueden ser especificadas en un nivel específico del sistema: los paquetes TCP / IP que fluyen a través de un cortafuegossobre la base de direcciones IP conocidas. Para un PP, los flujos y las operaciones de información pueden ser expresados como

12/6/2014 ISO / IEC 15408-2



tipos: correo electrónico, bases de datos, observar accesos, etc

Los componentes de esta familia se pueden aplicar varias veces en un PP / ST para diferentes subconjuntos de operaciones yobjetos. Esto acomodará TOE que contienen varias políticas, el problema a cada uno un conjunto particular deobjetos, sujetos y operaciones.

Página 166

ISO / IEC 15408-2:2008 (E)

El control del flujo de información F.5.2 FDP_IFC.1 Subset


Este componente requiere que una política de control de flujo de información se aplica a un subconjunto de las posibles operaciones enTOE.

F.5.2.2 Operaciones


En FDP_IFC.1.1, el autor PP / ST debe especificar un control del flujo de información de nombre único SFP serforzada por el TSF.

En FDP_IFC.1.1, el autor PP / ST debe especificar la lista de temas, la información y las operaciones que causainformación controlada a fluir hacia y desde los sujetos controlados cubiertos por la SFP. Como se mencionó anteriormente, lalista de temas podría estar en varios niveles de detalle en función de las necesidades del autor PP / ST. Podríaespecificar los usuarios, máquinas o procesos, por ejemplo. La información podría referirse a los datos como el correo electrónico o la redprotocolos u objetos más específicos similares a los especificados en una política de control de acceso. Si la informaciónque se especifica está contenido dentro de un objeto que está sujeto a una política de control de acceso, tanto en el accesopolítica de control y la información de política de control de flujo debe ser ejecutada antes de que la información especificada podría fluirhacia o desde el objeto.

F.5.3 FDP_IFC.2 Información completa de control de flujo


Este componente requiere que todas las operaciones posibles que causan que la información fluya hacia y desde los sujetosincluido en la SFP, que están cubiertos por un SFP de control del flujo de información.

El autor PP / ST debe demostrar que cada combinación de los flujos de información y los sujetos está cubierto por unSFP de control del flujo de información.

F.5.3.2 Operaciones


En FDP_IFC.2.1, el autor PP / ST debe especificar un control del flujo de información de nombre único SFP serforzada por el TSF.

En FDP_IFC.2.1, el autor PP / ST debe especificar la lista de temas e información que serán cubiertos porla SFP. Todas las operaciones que hacen que la información fluya hacia y desde los sujetos serán cubiertas por el SFP. Comomencionado anteriormente, la lista de temas podría ser en varios niveles de detalle en función de las necesidades de la PP / STautor. Puede especificar usuarios, máquinas o procesos, por ejemplo. La información podría referirse a los datos, comocorreo electrónico o protocolos de red, o más específicas objetos similares a los especificados en una política de control de acceso.Si la información que se especifica está contenida dentro de un objeto que está sujeto a una política de control de acceso,tanto de la política de control de acceso y la información de la política de control de flujo debe aplicarse antes de que la especificadainformación podría fluir hacia o desde el objeto.

Funciones de control de flujo de información F.6 (FDP_IFF)


Esta familia se describen las reglas para las funciones específicas que pueden implementar los programas de alimentación complementaria de control del flujo de informaciónNombrado en I nformación política de control de flujo (FDP_IFC), w hich también especifica el alcance de la fiscalización de las políticas. Loconsta de dos "árboles:" uno que abordan las cuestiones de la función de control del flujo de información común, y un segundoinformación de direccionamiento ilícito fluye (es decir, canales encubiertos) con respecto al control de flujo de uno o más informaciónSFP. Esta división se debe a que las cuestiones relativas a los flujos de información ilícitos son, en algún sentido,

12/6/2014 ISO / IEC 15408-2



Página 167

ISO / IEC 15408-2:2008 (E)


ortogonal al resto de un SFP. Los flujos de información ilícitas son flujos en violación de la política; por lo tanto no son unacuestión de política.

Con el fin de poner en práctica una fuerte protección contra la divulgación o modificación en la cara de software no fiable,Se requieren controles sobre el flujo de información. Los controles de acceso por sí solas no son suficientes, ya que sólo controlanel acceso a los contenedores, lo que permite la información que contienen fluya, sin controles, a lo largo de un sistema.

En esta familia, se utiliza la expresión "tipos de información ilícita fluye". Esta frase puede ser usado para referirse a lacategorización de los flujos como "Canales de almacenamiento" o "Canales Timing", o puede referirse a la mejora de las categorizacionesun reflejo de las necesidades de un autor PP / ST.

La flexibilidad de estos componentes permite la definición de una política de privilegios con la seguridad en FDP_IFF.1 simpleatributos y los atributos de seguridad FDP_IFF.2 jerárquica para permitir la derivación controlada de todo o parte de unparticular, la SFP. Si hay una necesidad de un enfoque predefinido a la SFP de derivación, el autor de PP / ST debe considerarla incorporación de una política de privilegios.

Atributos de seguridad simple F.6.2 FDP_IFF.1


Este componente requiere los atributos de seguridad de la información, y sobre temas que hacen que la información fluyay los sujetos que actúan como receptores de esa información. Los atributos de los contenedores de la informaciónTambién debe tenerse en cuenta si se desea que deberían jugar un papel en las decisiones de control de flujo de información o sique estén cubiertos por una política de control de acceso. Este componente especifica las reglas fundamentales que se aplican, ydescribe cómo se han obtenido los atributos de seguridad.

Este componente no especifica los detalles de cómo se asigna un atributo de seguridad (es decir, el usuario frente al proceso).La flexibilidad en la política es provista teniendo asignaciones que permiten la especificación de la política y la función adicionalrequisitos, según sea necesario.

Este componente también proporciona los requisitos para las funciones de control de flujo de información para poder explícitamenteautorizar y denegar un flujo de información como fundamento los atributos de seguridad. Esto podría ser utilizado para implementar unpolítica de privilegios que cubre las excepciones a la política básica definida en este componente.

F.6.2.2 Operaciones


En FDP_IFF.1.1, el autor PP / ST debe especificar los SFP de control del flujo de información impuestas por la TSF. Lanombre de la SFP de control del flujo de información, y el alcance de control para que la política se definen en los componentesde la política de control de flujo de la información (FDP_IFC).

En FDP_IFF.1.1, el autor PP / ST deberá especificar, para cada tipo de objeto controlado y la información, laatributos de seguridad que son relevantes para la especificación de las normas SFP. Por ejemplo, tales atributos de seguridadpueden ser cosas como el identificador de objeto, etiqueta de sensibilidad tema, etiqueta aclaramiento tema, la informaciónetiqueta de sensibilidad, etc Los tipos de atributos de seguridad deberían ser suficientes para satisfacer las necesidades ambientales.

En FDP_IFF.1.2, el autor PP / ST debe especificar para cada operación, la relación basada en atributos de seguridadque debe mantener entre el sujeto y la información de los atributos de seguridad que el TSF hará cumplir.

En FDP_IFF.1.3, el autor PP / ST debe especificar todas las normas SFP de control del flujo de información adicionales que elTSF es hacer cumplir. Esto incluye todas las reglas de la SFP que, o bien no están basados en los atributos de seguridad de lala información y el sujeto o normas que modifican automáticamente los atributos de seguridad de la información o sujetoscomo resultado de una operación de acceso. Un ejemplo del primer caso es una norma de la SFP controlar un umbralvalor para los tipos específicos de información. Esto sería, por ejemplo, ser el caso cuando el flujo de información SFPcontiene normas sobre el acceso a los datos estadísticos en los que un sujeto sólo se le permite acceder a este tipo de informaciónhasta un número específico de accesos. Un ejemplo del segundo caso sería una regla que indica bajo el cualcondiciones y cómo los atributos de seguridad de un sujeto o de objeto de cambio como el resultado de una operación de acceso.

Página 168

ISO / IEC 15408-2:2008 (E)

Algunas políticas de flujo de información, por ejemplo, pueden limitar el número de operaciones de acceso a la información con

12/6/2014 ISO / IEC 15408-2



los atributos de seguridad específico. Si no hay reglas adicionales a continuación, el autor PP / ST debería especificar "none".

En FDP_IFF.1.4, el autor PP / ST debería especificar las normas, sobre la base de atributos de seguridad, que de forma explícitaautorizar los flujos de información. Estas reglas son adicionales a los especificados en los elementos anteriores. Ellos sonincluido en FDP_IFF.1.4 un s que están destinados a contener excepciones a las normas de los elementos anteriores. Unejemplo de reglas para autorizar explícitamente los flujos de información se basa en un vector de privilegio asociado con untema que siempre concede el tema de la capacidad de causar un flujo de información para la información que está cubierta porla SFP que se ha especificado. Si no se desea tal capacidad, entonces el autor de PP / ST debe especificar"Ninguno".

En FDP_IFF.1.5, el autor PP / ST debe especificar las reglas, basadas en los atributos de seguridad, que se niegan de forma explícitalos flujos de información. Estas reglas son adicionales a los especificados en los elementos anteriores. Están incluidosen FDP_IFF.1.5 un s que están destinados a contener excepciones a las reglas de los elementos anteriores. Un ejemplode reglas para denegar explícitamente los flujos de información se basa en un vector de privilegio asociado a un tema que siempreniega el tema de la capacidad de causar un flujo de información para la información que está cubierta por la SFP que tieneha especificado. Si no se desea tal capacidad, entonces el autor PP / ST debe especificar "none".

Atributos de seguridad F.6.3 FDP_IFF.2 jerárquicos


Este componente requiere que la SFP de control del flujo de información llamado utiliza los atributos de seguridad jerárquico queformar una celosía.

Es importante tener en cuenta que los requisitos de relación jerárquica identificados en FDP_IFF.2.4 necesitan sólo se aplicana los atributos de seguridad de control de flujo de información para los programas de alimentación complementaria de control del flujo de información que se han identificadoen FDP_IFF.2.1. Este componente no está destinado a aplicarse a otros programas de alimentación complementaria, como SFP de control de acceso.

FDP_IFF.2.6 frases con los requisitos para el conjunto de atributos de seguridad para formar un enrejado. Un número depolíticas de flujo de la información definidos en la literatura y aplicadas en productos de TI se basan en un conjunto de seguridadatributos que forman una celosía. FDP_IFF.2.6 se incluye específicamente para hacer frente a este tipo de flujo de informaciónpolíticas.

Si se da el caso de que los SFP de control del flujo de información múltiple han de especificarse, y que cada uno de estos programas de alimentación complementaria setienen sus propios atributos de seguridad que no están relacionados entre sí, entonces el autor PP / ST debe repetir estecomponente una vez para cada uno de esos SFP. De lo contrario, podría surgir un conflicto con los subtemas de FDP_IFF.2.4ya no existirán las relaciones requeridas.

F.6.3.2 Operaciones



En FDP_IFF.2.1, el autor PP / ST deberá especificar, para cada tipo de objeto controlado y la información, laatributos de seguridad que son relevantes para la especificación de las normas SFP. Por ejemplo, tales atributos de seguridadpueden ser cosas como el identificador de objeto, etiqueta de sensibilidad tema, etiqueta aclaramiento tema, la informaciónetiqueta de sensibilidad, etc Los tipos de atributos de seguridad deberían ser suficientes para satisfacer las necesidades ambientales.

En FDP_IFF.2.2, el autor PP / ST debe especificar para cada operación, la relación basada en atributos de seguridadque debe mantener entre el sujeto y la información de los atributos de seguridad que el TSF hará cumplir. Estoslas relaciones deben estar basadas en las relaciones de ordenación entre los atributos de seguridad.

En FDP_IFF.2.3, el autor PP / ST debe especificar todas las normas SFP de control del flujo de información adicionales que elTSF es hacer cumplir. Esto incluye todas las reglas de la SFP que, o bien no están basados en los atributos de seguridad de lala información y el sujeto o normas que modifican automáticamente los atributos de seguridad de la información o sujetos

Página 169

ISO / IEC 15408-2:2008 (E)

como resultado de una operación de acceso. Un ejemplo del primer caso es una norma de la SFP controlar un umbralvalor para los tipos específicos de información. Esto sería, por ejemplo, ser el caso cuando el flujo de información SFPcontiene normas sobre el acceso a los datos estadísticos en los que un sujeto sólo se le permite acceder a este tipo de informaciónhasta un número específico de accesos. Un ejemplo del segundo caso sería una regla que indica bajo el cualcondiciones y cómo los atributos de seguridad de un sujeto o de objeto de cambio como el resultado de una operación de acceso.Algunas políticas de flujo de información, por ejemplo, pueden limitar el número de operaciones de acceso a la información conlos atributos de seguridad específico. Si no hay reglas adicionales a continuación, el autor PP / ST debería especificar "none".

En FDP_IFF.2.4, el autor PP / ST debería especificar las normas, sobre la base de atributos de seguridad, que de forma explícitaautorizar los flujos de información. Estas reglas son adicionales a los especificados en los elementos anteriores. Ellos sonincluido en FDP_IFF.2.4 un s que están destinados a contener excepciones a las normas de los elementos anteriores. Unejemplo de reglas para autorizar explícitamente los flujos de información se basa en un vector de privilegio asociado con untema que siempre concede el tema de la capacidad de causar un flujo de información para la información que está cubierta por

12/6/2014 ISO / IEC 15408-2



la SFP que se ha especificado. Si no se desea tal capacidad, entonces el autor de PP / ST debe especificar"Ninguno".

En FDP_IFF.2.5, el autor PP / ST debe especificar las reglas, basadas en los atributos de seguridad, que se niegan de forma explícitalos flujos de información. Estas reglas son adicionales a los especificados en los elementos anteriores. Están incluidosen FDP_IFF.2.5 un s que están destinados a contener excepciones a las reglas de los elementos anteriores. Un ejemplode reglas para denegar explícitamente los flujos de información se basa en un vector de privilegio asociado a un tema que siempreniega el tema de la capacidad de causar un flujo de información para la información que está cubierta por la SFP que tieneha especificado. Si no se desea tal capacidad, entonces el autor PP / ST debe especificar "none".

F.6.4 fluye FDP_IFF.3 limitada información ilícita


Este componente debe ser utilizado cuando al menos uno de los programas de alimentación complementaria que requiere control de la información ilícita fluyeno requiere la eliminación de los flujos.

Para los flujos de información ilícita especificada, deben proporcionarse determinadas capacidades máximas. Además un PP / STautor tiene la posibilidad de especificar si los flujos de información ilícitos deben ser auditados.

F.6.4.2 Operaciones



En FDP_IFF.3.1, el autor PP / ST debe especificar los tipos de flujos de información ilícitos que están sujetos a unalimitación de la capacidad máxima.

En FDP_IFF.3.1, el autor PP / ST debe especificar la capacidad máxima permitida para cualquier ilícito identificadolos flujos de información.

F.6.5 FDP_IFF.4 Eliminación parcial de la información ilícita fluye


Este componente debe utilizarse cuando todos los programas de alimentación complementaria que requiera el control de los flujos de información ilícitas requiereneliminación de algunas (pero no necesariamente todos) información ilícita fluye.

Página 170

ISO / IEC 15408-2:2008 (E)

F.6.5.2 Operaciones



En FDP_IFF.4.1, el autor PP / ST debe especificar los tipos de flujos de información ilícitos que están sujetos a unalimitación de la capacidad máxima.

En FDP_IFF.4.1, el autor PP / ST debe especificar la capacidad máxima permitida para cualquier ilícito identificadolos flujos de información.

En FDP_IFF.4.2, t él PP / ST autor debe especificar el tipo de información ilícita fluye a eliminar. Esta listano puede estar vacío ya que este componente requiere que algunos flujos de información ilícitos deben ser eliminados.

F.6.6 fluye FDP_IFF.5 información No ilícito


Este componente debe utilizarse cuando los programas de alimentación complementaria que requieren un control de los flujos de información ilícitas requierenla eliminación de toda la información ilícita fluye. Sin embargo, el autor de PP / ST debe considerar cuidadosamente el potencialimpacto que la eliminación de toda la información de los flujos ilícitos podría tener en la operación funcional normal de la TOE.

12/6/2014 ISO / IEC 15408-2



Muchas aplicaciones prácticas han demostrado que existe una relación indirecta entre la información ilícita flujosy la funcionalidad normal dentro de un TOE y la eliminación de toda la información de los flujos ilícitos puede resultar en menos de lo deseadofuncionalidad.

F.6.6.2 Operaciones


En FDP_IFF.5.1, el autor PP / ST debe especificar el SFP de control del flujo de información para que la información ilícitaflujos son para ser eliminado. El nombre de la SFP de control de flujo de información, y el alcance de control para quela política se define en los componentes de la I nformación política de control de flujo (FDP_IFC).

Vigilancia del flujo de información F.6.7 FDP_IFF.6 Ilícito


Este componente debe ser utilizada cuando se desea que el TSF proporciona la capacidad de controlar el uso de drogas ilícitasflujos de información que excedan la capacidad especificada. Si se desea que tales flujos ser auditados, entonces estecomponente podría servir como la fuente de los eventos de auditoría para ser utilizados por los componentes de la S eguridad datos de auditoríageneración (FAU_GEN) f amilia.

F.6.7.2 Operaciones



En FDP_IFF.6.1, el autor PP / ST debe especificar los tipos de flujos de información ilícitos que serán monitoreadas parasuperior a la capacidad máxima.

En FDP_IFF.6.1, el autor PP / ST debe especificar la capacidad máxima por encima del cual los flujos de información ilícitaserá objeto de seguimiento por el TSF.

Página 171

ISO / IEC 15408-2:2008 (E)

F.7 importación desde fuera del TOE (FDP_ITC)


Esta familia define los mecanismos para la importación mediada TSF de datos de usuario de fuera de la TOE en el TOEde tal manera que los atributos de seguridad de datos de usuario pueden ser preservados. La consistencia de estos atributos de seguridad sondirigida por la coherencia de datos entre TSF TSF (FPT_TDC).

Importación desde fuera del TOE (FDP_ITC) i s preocupados por las limitaciones a la importación, la especificación del usuariolos atributos de seguridad, y la asociación de atributos de seguridad de los datos del usuario.

Esta familia, y el correspondiente fami exportación ly Exportar en el TOE (FDP_ETC) , frente a cómo el TOEse ocupa de los datos del usuario fuera de su control. Esta familia está preocupada con la asignación y la abstracción del usuariolos atributos de seguridad de los datos.

Una variedad de actividades podría estar involucrado aquí:

a) la importación de datos de usuario de un medio sin formato (por ejemplo, disco floppy, cinta, escáner, señal de vídeo o auditoría),sin incluir los atributos de seguridad, y delimita materialmente el medio para indicar su contenido;

b) la importación de datos de usuarios, incluidos los atributos de seguridad, de un medio y la verificación de que la seguridad de los objetosatributos son apropiadas;

c) la importación de datos de usuarios, incluidos los atributos de seguridad, a partir de un medio usando una técnica de sellado criptográficopara proteger la asociación de datos de usuario y los atributos de seguridad.

Esta familia no se ocupa de la determinación de si los datos de los usuarios pueden ser importados. Le preocupacon los valores de la atributos de seguridad para asociar con los datos de usuario importados.

Existen dos posibilidades para la importación de datos de usuario: o bien los datos de usuario está asociado sin ambigüedad conatributos fiables de seguridad de objetos (valores y sentido de los atributos de seguridad no se modifica), o no confiableatributos de seguridad (o atributos de seguridad en absoluto) están disponibles desde el origen de la importación. Esta dirección de la familiaambos casos.

Si existen atributos de seguridad fiables, que pueden haber sido asociados con los datos de los usuarios por medios físicosmedios (los atributos de seguridad están en el mismo medio), o por medios lógicos (los atributos de seguridad son

12/6/2014 ISO / IEC 15408-2



distribuidos de manera diferente, pero incluir la identificación de objeto único, por ejemplo la suma de comprobación criptográfica).

Esta familia tiene que ver con la importación mediada TSF de los datos de usuario y mantiene la asociación de seguridadatributos según sea necesario por la SFP. Otras familias se ocupan de otros aspectos, tales como la importaciónconsistencia, los canales de confianza e integridad que están más allá del alcance de esta familia. Por otra parte, la importación defuera del TOE (FDP_ITC) i S sólo se refiere a la interfaz con el medio de importación. Exportar en el TOE(FDP_ETC) es responsable por el otro punto extremo del medio (la fuente).

Algunos de los requisitos de importación conocidos son:

a) la importación de los datos del usuario sin atributos de seguridad;

b) importación de los datos de usuario que incluye atributos de seguridad donde los dos están asociados uno con el otro y elatributos de seguridad representan sin ambigüedad la información que se importa.

Estos requisitos de importación pueden ser manejados por el TSF, con o sin intervención humana, en función de laLimitaciones de TI y la política de seguridad de la organización. Por ejemplo, si los datos del usuario se recibe en un "confidencial"canal, los atributos de seguridad de los objetos se establecerá en "confidencial".


Página 172

ISO / IEC 15408-2:2008 (E)

F.7.2 FDP_ITC.1 Importación de datos de usuario sin atributos de seguridad


Este componente se utiliza para especificar la importación de los datos de usuario que no tiene seguridad fiable (o cualquier)atributos asociados. Esta función requiere que los atributos de seguridad de los datos de usuario importado seainicializado dentro de la TSF. También podría darse el caso de que el autor de PP / ST especifica las reglas para la importación. Se puedeser apropiado, en algunos ambientes, de exigir que estos atributos pueden suministrar a través de una ruta de confianza o unmecanismo de canal de confianza.

F.7.2.2 Operaciones


En FDP_ITC.1.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que se aplica cuando se importan los datos de usuario desde fuera del TOE. Los datos de usuario que estaimportaciones de funciones pertenecerán al ámbito de la cesión de los citados programas de alimentación complementaria.

En FDP_ITC.1.3, t él PP / SAN autor debe especificar todas las reglas de control de importación adicionales o "ninguno" si hayno hay reglas de control de importación adicionales. Estas reglas se harán cumplir por el TSF, además del accesoSFP de control y / o de información SFP de control de flujo seleccionados en FDP_ITC.1.1.

F.7.3 FDP_ITC.2 Importación de datos de usuario con atributos de seguridad


Este componente se utiliza para especificar la importación de los datos de usuario con atributos de seguridad fiables asociados aella. Esta función se basa en los atributos de seguridad que se precisa y sin ambigüedades asociadas con elobjetos en el medio de la importación. Una vez importados, los objetos tendrán los mismos atributos. Esto requiereInter-TSF TSF consistencia de los datos (FPT_TDC) para garantizar la coherencia de los datos. También podría ser el casoque el autor de PP / ST especifica las reglas para la importación.

F.7.3.2 Operaciones


En FDP_ITC.2.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que se aplica cuando se importan los datos de usuario desde fuera del TOE. Los datos de usuario que estaimportaciones de funciones pertenecerán al ámbito de la cesión de los citados programas de alimentación complementaria.

En FDP_ITC.2.5, t él PP / ST autor debe especificar todas las normas de control de importación adicionales o "ninguno" si hayno hay reglas de control de importación adicionales. Estas reglas se harán cumplir por el TSF, además del accesoSFP de control y / o de información SFP de control de flujo seleccionados en FDP_ITC.2.1.

Transferencia TOE Interna F.8 (FDP_ITT)


12/6/2014 ISO / IEC 15408-2



Esta familia proporciona los requisitos que se ocupan de la protección de los datos de usuario cuando se transfiere entre las partes deluna TDT a través de un canal interno. Esto puede ser contrastado con el En de usuario transferencia de confidencialidad de los datos ter-TSFprotección (FDP_UCT) una protección de la integridad de transferencia de datos de usuario Inter-TSF nd familia (FDP_UIT), que proporcionanprotección de los datos de usuario cuando se transfiere entre las TSF distintas a través de un canal externo y Exportacióndel TOE (FDP_ETC) e Importación desde fuera del TOE (FDP_ITC), que aborda mediada TSFtransferencia de datos hacia o desde fuera del TOE.

Los requisitos de esta familia permiten que un autor PP / ST para especificar la seguridad deseada para los datos del usuario, mientras que en eltránsito en el TOE. Esta seguridad puede ser la protección contra la divulgación, modificación o pérdida de disponibilidad.

Página 173

ISO / IEC 15408-2:2008 (E)

La determinación del grado de separación física por encima del cual debe aplicarse esta familia depende de laentorno de uso previsto. En un ambiente hostil, puede haber riesgos derivados de las transferencias entre partesdel TOE separados por sólo un bus de sistema. En ambientes más benignos, las transferencias pueden ser a través de máslos medios de comunicación de la red tradicional.


F.8.2 FDP_ITT.1 básico de protección interno de transferencia

F.8.2.1 Operaciones


En FDP_ITT.1.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que cubre la información que se transfiere.

F.8.2.1.2 Selección

En FDP_ITT.1.1, el autor PP / ST debe especificar los tipos de errores de transmisión que la TSF debe evitarocurre para los datos de usuario, mientras que en el transporte. Las opciones son la divulgación, modificación, pérdida de uso.

F.8.3 FDP_ITT.2 Transmisión separación por atributo


Este componente podría, por ejemplo, ser usado para proporcionar diferentes formas de protección a la información condiferentes niveles de desclasificación.

Una de las maneras de lograr la separación de los datos cuando se transmite es mediante el uso de lógica independiente ocanales físicos.

F.8.3.2 Operaciones


En FDP_ITT.2.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que cubre la información que se transfiere.


En FDP_ITT.2.1, el autor PP / ST debe especificar los tipos de errores de transmisión que la TSF debe evitarocurre para los datos de usuario, mientras que en el transporte. Las opciones son la divulgación, modificación, pérdida de uso.


En FDP_ITT.2.2, el autor PP / ST debe especificar los atributos de seguridad, los valores de los que el TSF utilizarápara determinar cuándo separar datos que se transmiten entre partes físicamente separadas-de TOE.Un ejemplo es que los datos de usuario asociados con la identidad de un propietario se transmite por separado del usuariodatos asociados con la identidad de un propietario diferente. En esta caso, el valor de la identidad del propietario de lade datos es lo que se utiliza para determinar cuándo separar los datos para la transmisión.

Monitoreo F.8.4 FDP_ITT.3 Integridad


Este componente se utiliza en combinación con cualquiera de FDP_ITT.1 básica Protectio transferencia interna N o FDP_ITT.2Separación Transmisión por atributo. Asegura que los controles TSF recibidos los datos del usuario (y sus atributos)para la integridad . FDP_ITT.1 básico protectio transferencia interna n o separación FDP_ITT.2 Transmisión por atributo

12/6/2014 ISO / IEC 15408-2



Página 174

ISO / IEC 15408-2:2008 (E)


proporcionará los datos de tal manera que está protegido de la modificación (de modo que FDP_ITT.3 Integridadmonitoreo puede detectar cualquier modificación).

El autor PP / ST tiene para especificar los tipos de errores que deben ser detectados. El autor PP / ST debe considerar:modificación de datos, la sustitución de datos, cambio de pedido irrecuperable de datos, grabación de datos, incompletasde datos, además de otros errores de integridad.

El autor PP / ST debe especificar las acciones que el TSF debe tomar en la detección de un fallo. Por ejemplo:caso omiso de los datos del usuario, solicitar de nuevo los datos, informar al administrador autorizado, desviar el tráfico por otras líneas.

F.8.4.2 Operaciones


En FDP_ITT.3.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que cubre la información que se transfiere y supervisado por fallos de integridad.

En FDP_ITT.3.1, el autor PP / ST debe especificar el tipo de posibles errores de integridad objeto de seguimiento durantetransmisión de los datos de usuario.

En FDP_ITT.3.2, el autor PP / ST debe especificar la acción a ser tomada por el TSF cuando un error de integridad esencontrado. Un ejemplo podría ser que el TSF debe pedir a la nueva presentación de los datos del usuario. LaSFP (s) especificado en FDP_ITT.3.1 w enfermos en vigencia a las acciones que se tomen por el TSF.

F.8.5 FDP_ITT.4 supervisión de integridad basada en atributos


Este componente se utiliza en combinación con F separación DP_ITT.2 Transmisión por atributo. Se asegura de quelos controles TSF recibieron datos de usuario, que ha sido transmitido por canales separados (basada en los valores deatributos de seguridad especificados), para la integridad. Permite que el autor PP / ST para especificar las acciones que se deben tomar endetección de un error de integridad.

Por ejemplo, este componente puede ser usado para proporcionar diferentes de detección de error de integridad y de acción parainformación a diferentes niveles de integridad.

El autor PP / ST tiene para especificar los tipos de errores que deben ser detectados. El autor PP / ST debe considerar:modificación de datos, la sustitución de datos, cambio de pedido irrecuperable de datos, grabación de datos, incompletasde datos, además de otros errores de integridad.

El autor PP / ST debe especificar los atributos (y los canales de transmisión asociadas) que requierensupervisión de errores de integridad.

El autor PP / ST debe especificar las acciones que el TSF debe tomar en la detección de un fallo. Por ejemplo:caso omiso de los datos del usuario, solicitar de nuevo los datos, informar al administrador autorizado, desviar el tráfico por otras líneas.

F.8.5.2 Operaciones


En FDP_ITT.4.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que cubre la información que se transfiere y supervisado por fallos de integridad.

En FDP_ITT.4.1, el autor PP / ST debe especificar el tipo de posibles errores de integridad objeto de seguimiento durantetransmisión de los datos de usuario.

En FDP_ITT.4.1, el autor PP / ST debe especificar una lista de atributos de seguridad que requieren la transmisión separadacanales. Esta lista se utiliza para determinar qué datos de usuario para controlar de errores de integridad., Sobre la base de su seguridad

Página 175

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



atributos y su canal de transmisión. Este elemento está directamente relacionada a la separación FDP_ITT.2 Transmisiónpor atributo.

En FDP_ITT.4.2, el autor PP / ST debe especificar la acción a ser tomada por el TSF cuando un error de integridad esencontrado. Un ejemplo podría ser que el TSF debe pedir a la nueva presentación de los datos del usuario. LaSFP (s) especificado en FDP_ITT.4.1 w enfermos en vigencia a las acciones que se tomen por el TSF.

Residual protección de la información F.9 (FDP_RIP)


Protección de la información residual asegura que los recursos TSF controlada cuando desasignada de un objeto yantes de que se reasignan a otro objeto se asimilan por el TSF de una manera que no es posiblereconstruir la totalidad o parte de los datos contenidos en el recurso antes de que se desasigna.

Un dedo del pie por lo general tiene un número de funciones que potencialmente desasignar los recursos de un objeto y potencialmentereasignar esos recursos a los objetos. Algunos, pero no todos los recursos pueden haber sido utilizados para almacenardatos críticos de la utilización anterior de los recursos y de los recursos FDP_RIP requiere que seanpreparado para su reutilización. Reutilización de objetos se aplica a las solicitudes explícitas de un sujeto o de usuario para liberar los recursos, asíacciones implícitas de la TSF que resultan en la de-asignación y posterior re-asignación de recursos paradiferentes objetos. Ejemplos de peticiones explícitas son la eliminación o truncamiento de un archivo o la liberación de un áreade la memoria principal. Los ejemplos de acciones implícitas de la TSF son los de-asignación y reasignación de cachéregiones.

El requisito para la reutilización de objetos está relacionada con el contenido del recurso perteneciente a un objeto, no todosinformación acerca del recurso o un objeto que se puede almacenar en la TSF en otro lugar. Como un ejemplo para satisfacerel requisito FDP_RIP para los archivos como objetos requiere que todos los sectores que conforman el archivo deben serpreparado para su reutilización.

También se aplica a los recursos que están en serie reutilizados por diferentes temas dentro del sistema. Por ejemplo, la mayoríasistemas operativos normalmente se basan en registros de hardware (recursos) para apoyar los procesos en el sistema.Como los procesos son cambiados de un estado de "ejecutar" a un estado de "reposo" (y viceversa), estos registros son en seriereutilizados por diferentes temas. Mientras que esta acción "intercambio" no se puede considerar una asignación o cancelación de asignaciónde un recurso, la protección de la información residual (FDP_RIP) podría aplicarse a este tipo de eventos y recursos.

Protección de la información residual (FDP_RIP) t controles ypically acceso a información que no es parte de ningunaActualmente definido u objeto accesible; Sin embargo, en algunos casos esto puede no ser cierto. Por ejemplo, el objeto "A"es un archivo y el objeto "B" es el disco en el que reside el archivo. Si el objeto "A" se borra, la información deobjeto "A" está bajo el control de la protección de la información residual (FDP_RIP) ev es a pesar de que sigue siendo parte del objeto"B".

Es importante tener en cuenta tha t protección de la información residual (FDP_RIP) sólo se aplica a los objetos en línea y nooff-line objetos tales como las de copia de seguridad en cinta. Por ejemplo, si se elimina un archivo en el TOE, Residualprotección de la información (FDP_RIP) ca n pueden crear instancias para exigir que no existe información residual encancelación de asignación; sin embargo, la TSF no puede extender este cumplimiento a ese mismo archivo que existe en la línea de offback-up. Por lo tanto, ese mismo archivo sigue estando disponible. Si esto es una preocupación, entonces el autor de PP / ST debe hacerasegurarse de que los objetivos ambientales adecuadas están en el lugar para apoyar la orientación del usuario operativa para hacer frente a off-objetos de línea.

Protección residual información (FDP_RIP) y Rollback (FDP_ROL) pueden entrar en conflicto cuando la información residualprotección (FDP_RIP) se crea una instancia de exigir que la información residual se borrará en el momento de la aplicaciónlibera el objeto a la TSF (es decir, sobre desafectación). Por lo tanto, la protección de la información residual(FDP_RIP) s elección de "desafectación" no debe ser utilizado con Rollback (FDP_ROL), ya que no habríainformación para hacer retroceder. La otra selección, "la falta de disponibilidad en la asignación", se puede usar con Rollback(FDP_ROL), b ut existe el riesgo de que el recurso que sostuvo que la información haya sido asignado a un nuevoobjeto antes de la tirada hacia atrás se llevó a cabo. Si eso llegara a ocurrir, entonces la parte de atrás rollo no sería posible.

Página 176

ISO / IEC 15408-2:2008 (E)

No hay requisitos de auditoría de protección de la información residual (FDP_RIP) porque esto no es un usuario-función invocable. Auditoría de los recursos asignados o cancelaciones de asignación sería auditable como parte del accesoSFP de control o las operaciones de SFP de control del flujo de información.

Esta familia debe aplicarse a los objetos especificados en el SFP (s) de control de acceso o el control del flujo de informaciónSFP (s) según lo especificado por el autor PP / ST.

F.9.2 FDP_RIP.1 Subset protección de la información residual


12/6/2014 ISO / IEC 15408-2



Este componente requiere que, para un subconjunto de los objetos de la TOE, la TSF se asegurará de que no hay esinformación residual disponible contenido en un recurso asignado a esos objetos o cancelado la asignación de losobjetos.

F.9.2.2 Operaciones


En FDP_RIP.1.1, t él PP / ST autor debe especificar el evento, la asignación de los recursos o cancelación de asignación de larecursos de que invoca la función de la protección de información residual.


En FDP_RIP.1.1, t él PP / ST autor debe especificar la lista de objetos sujetos a la protección de la información residual.

F.9.3 FDP_RIP.2 completa protección de la información residual


Este componente requiere que para todos los objetos de la TOE, la TSF se asegurará de que no hay residual disponibleinformación contenida en un recurso asignado a este objeto o cancelar la asignación de esos objetos.

F.9.3.2 Operaciones


En FDP_RIP.2.1, t él PP / ST autor debe especificar el evento, la asignación de los recursos o cancelación de asignación de larecursos de que invoca la función de la protección de información residual.

F.10 Rollback (FDP_ROL)


Esta familia se dirige a la necesidad de volver a un estado válido bien definida, tales como la necesidad de un usuario para deshacermodificaciones a un archivo o para deshacer las transacciones en caso de una serie incompleta de transacción como en el caso debases de datos.

Esta familia tiene la intención de ayudar al usuario a volver a un estado válido bien definido cuando el usuario cancela la últimaconjunto de acciones o, en bases de datos distribuidas, la devolución de todas las copias distribuidas de las bases de datos aldeclarar ante un error en la operación.

Protección residual información (FDP_RIP ) y Rollback (FDP_ROL) conflicto cuando la información residualprotección (FDP_RIP) e nforces que los contenidos se harán disponibles en el momento en que un recurso escancelado la asignación de un objeto. Por lo tanto, este uso de la protección de la información residual (FDP_RIP) no puede sercombinado con Rollback (FDP_ROL) como no habría información para hacer retroceder. Residual informaciónprotección (FDP_RIP) puede ser utilizado sólo con Rollback (FDP_ROL) cuando se obliga a que el contenido seadisponible en el momento que un recurso está asignado a un objeto. Esto se debe a th e Rollback (FDP_ROL)

Página 177

ISO / IEC 15408-2:2008 (E)

mecanismo tendrá la oportunidad de acceder a la información previa de que todavía puede estar presente en la TOE enPara rodar con éxito de nuevo la operación.

El requisito de reversión está limitada por ciertos límites. Por ejemplo, un editor de texto por lo general sólo le permite rodaruna copia de seguridad a un cierto número de comandos. Otro ejemplo podría ser las copias de seguridad. Si las cintas de respaldo son rotados,después se vuelve a utilizar una cinta, la información ya no se puede recuperar. Esto también supone un salto en la reversiónrequisito.

F.10.2 FDP_ROL.1 básico rollback

F.10.2.1 notas de aplicación de usuario

Este componente permite que un usuario o un objeto de deshacer una serie de operaciones en un conjunto predefinido de objetos. El deshacersólo es posible dentro de ciertos límites, por ejemplo, hasta un número de caracteres o hasta un límite de tiempo.

Operaciones F.10.2.2

Asignación F.10.2.2.1

En FDP_ROL.1.1, t él PP / ST autor debe especificar el SFP de control de acceso (s) y / o el flujo de información de controlSFP (s) que se aplica cuando se realizan operaciones de rollback. Esto es necesario para asegurarse de que rolloespalda no se utiliza para eludir los programas de alimentación complementaria especificados.

12/6/2014 ISO / IEC 15408-2



En FDP_ROL.1.1, t él PP / ST autor debe especificar la lista de operaciones que se pueden deshacer.

En FDP_ROL.1.1, t él PP / ST autor debe especificar la información y / o una lista de los objetos que están sometidos ala política de reversión.

En FDP_ROL.1.2, el autor PP / ST debe especificar el límite de frontera a la que rollback operaciones pueden serrealizado. El límite se puede especificar como un período de tiempo predefinido, por ejemplo, las operaciones pueden sersin hacer que se llevaron a cabo en los últimos dos minutos. Otros límites posibles pueden definirse como lanúmero máximo de operaciones permitidas o el tamaño de un tampón.

Rollback F.10.3 FDP_ROL.2 Avanzada


Este componente hace cumplir que el TSF proporciona la capacidad de deshacer todas las operaciones; Sin embargo, el usuario puedeoptar por deshacer sólo una parte de ellos.



En FDP_ROL.2.1, t él PP / ST autor debe especificar el SFP de control de acceso (s) y / o el flujo de información de controlSFP (s) que se aplica cuando se realizan operaciones de rollback. Esto es necesario para asegurarse de que rolloespalda no se utiliza para eludir los programas de alimentación complementaria especificados.

En FDP_ROL.2.1, th e PP / ST autor debe especificar la lista de objetos que están sometidos a la política de reversión.

En FDP_ROL.2.2, el autor PP / ST debe especificar el límite de frontera a la que rollback operaciones pueden serrealizado. El límite se puede especificar como un período de tiempo predefinido, por ejemplo, las operaciones pueden sersin hacer que se llevaron a cabo en los últimos dos minutos. Otros límites posibles pueden definirse como lanúmero máximo de operaciones permitidas o el tamaño de un tampón.

Página 178

ISO / IEC 15408-2:2008 (E)

Integridad de los datos almacenados F.11 (FDP_SDI)


Esta familia proporciona los requisitos que se ocupan de la protección de los datos del usuario mientras se almacena dentro de contenedorescontrolado por el TSF.

Fallos de hardware o errores pueden afectar a los datos almacenados en la memoria. Esta familia proporciona los requisitos para la detecciónestos errores no intencionales. La integridad de los datos del usuario durante su almacenamiento en dispositivos de almacenamiento controlados por la TSF sontambién abordada por esta familia.

Para evitar que un sujeto de modificación de los datos, la información fluya funciones de control (FDP_IFF) o Accesofunciones de control (FDP_ACF) fa milias se requieren (en lugar de esta familia).

Esta familia se diferencia de la transferencia TOE Interna (FDP_ITT) t sombrero protege los datos de usuario de errores de integridad, mientras queser trasladado dentro del TOE.

F.11.2 FDP_SDI.1 monitoreo integridad de los datos almacenados


Este componente supervisa los datos almacenados en los medios de comunicación de errores de integridad. El autor PP / ST puede especificar diferentestipos de atributos de datos de usuario que se utilizarán como base para el monitoreo.



En FDP_SDI.1.1, t él PP / ST autor debe especificar los errores de integridad que el TSF detectará.

En FDP_SDI.1.1, el autor de PP / ST debe especificar los atributos de datos de usuario que se utilizarán como base para elmonitoreo.

12/6/2014 ISO / IEC 15408-2



F.11.3 FDP_SDI.2 almacenado el seguimiento y la acción integridad de los datos

F.11.3.1 notas de la aplicación de usuario

Este componente supervisa los datos almacenados en los medios de comunicación de errores de integridad. El autor PP / ST puede especificar qué acciónse deben tomar en caso de que se detecta un error de integridad.



En FDP_SDI.2.1, t él PP / ST autor debe especificar los errores de integridad que el TSF detectará.

En FDP_SDI.2.1, el autor de PP / ST debe especificar los atributos de datos de usuario que se utilizarán como base para elmonitoreo.

En FDP_SDI.2.2, t él PP / ST autor debe especificar las acciones que se deben tomar en caso de que se detecta un error de integridad.

Protección de la confidencialidad de transferencia de datos de usuario F.12Inter-TSF (FDP_UCT)


Esta familia define los requisitos para garantizar la confidencialidad de los datos de usuario cuando se transfiere medianteun canal externo entre el TOE y otro producto de TI de confianza. La confidencialidad es impuesta por

Página 179

ISO / IEC 15408-2:2008 (E)

impedir la divulgación no autorizada de los datos de usuario en tránsito entre los dos puntos finales. Los puntos finales pueden seruna TSF o un usuario.

Esta familia ofrece un requisito para la protección de los datos de los usuarios durante el tránsito. En contraste, C ONFIDENCIALIDAD deexportados los datos TSF (FPT_ITC) maneja los datos TSF.

Intercambio de datos F.12.2 FDP_UCT.1 básico confidencialidad


Dependiendo de las políticas de control de acceso o de flujo de información que el TSF tiene la obligación de enviar o recibir datos de usuariode tal manera que la confidencialidad de los datos de usuario está protegido.



En FDP_UCT.1.1, t él PP / ST autor debe especificar el SFP de control de acceso (s) y / o el flujo de información de controlSFP (s) a ser aplicada en el intercambio de los datos de usuario. Las políticas especificadas se aplicarán para hacerdecisiones sobre quién puede intercambiar datos y que se pueden intercambiar datos.

Selección F.12.2.2.2

En FDP_UCT.1.1, el autor de PP / ST debe especificar si este elemento se aplica a un mecanismo quetransmite o recibe datos de usuario.

Protección de la integridad de transferencia de datos de usuario F.13 Inter-TSF (FDP_UIT)


Esta familia define los requisitos para proporcionar la integridad de los datos del usuario en el tránsito entre la TSF yotro producto de TI confiable y recuperación de errores detectables. Como mínimo, esta familia supervisa laintegridad de los datos del usuario para las modificaciones. Además, esta familia es compatible con diferentes formas de corregir detectadoerrores de integridad.

Esta familia define los requisitos para proporcionar la integridad de los datos del usuario en tránsito; mientras Integridad de exportaDatos de TSF (FPT_ITI) maneja los datos TSF.

Protección Inter-TSF transferencia integridad de los datos de usuario (FDP_UIT) e Inter-TSF transferencia de confidencialidad de los datos de usuarioprotección (FDP_UCT) un re duales de unos a otros, como la protección de la confidencialidad de transferencia de datos de usuario de Inter-TSF(FDP_UCT) ad vestidos de confidencialidad de los datos de usuario. Por lo tanto, el mismo mecanismo que implementa Inter-TSFprotección de la integridad de transferencia de datos de usuario (FDP_UIT) posiblemente podría ser usado para implementar otras familias tales comoProtección Inter-TSF transferencia confidencialidad de los datos de usuario (FDP_UCT) e Importación desde fuera del TOE(FDP_ITC).

12/6/2014 ISO / IEC 15408-2



Integridad intercambio F.13.2 FDP_UIT.1 datos


Dependiendo de las políticas de control de acceso o de flujo de información que el TSF tiene la obligación de enviar o recibir datos de usuariode una manera tal que se detecta la modificación de los datos de usuario. No hay ningún requisito para un mecanismo de TSFpara intentar recuperar a partir de la modificación.



En FDP_UIT.1.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que se aplica en los datos transmitidos o en los datos recibidos. Las políticas especificadas serán

Página 180

ISO / IEC 15408-2:2008 (E)

forzada a tomar decisiones sobre quién puede transmitir o que puede recibir datos, y que los datos pueden sertransmitida o recibida.

Selección F.13.2.2.2

En FDP_UIT.1.1, el autor PP / ST debe especificar si este elemento se aplica a una TSF que se transmite orecibir objetos.

En FDP_UIT.1.1, el autor PP / ST debe especificar si los datos deben estar protegidos frente a posibles modificaciones,deleción, inserción o de repetición.

En FDP_UIT.1.2, el autor PP / ST debe especificar si los errores del tipo: modificación, supresión,inserción o repetición se detectan.

Recuperación de intercambio de datos F.13.3 FDP_UIT.2 Fuente


Este componente proporciona la capacidad de recuperarse de un conjunto de errores de transmisión identificados, si es necesario, con laayuda del otro producto de TI de confianza. A medida que el otro producto de TI de confianza está fuera del TOE, la TSF no puede controlarsu comportamiento. Sin embargo, puede proporcionar funciones que tienen la capacidad de cooperar con la otra de confianza de TIproducto a los efectos de la recuperación. Por ejemplo, la TSF podría incluir funciones que dependen de laTrusted Source IT producto para volver a enviar los datos en el caso de que se detecte un error. Este componente se ocupa dela capacidad de la TSF para manejar una recuperación tal error.



En FDP_UIT.2.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que se aplica al recuperar los datos de usuario. Las políticas especificadas se aplicarán para hacerdecisiones sobre qué datos pueden ser recuperados y cómo se pueden recuperar.

En FDP_UIT.2.1, el autor PP / ST debe especificar la lista de errores de integridad de la que el TSF, con la ayudadel producto de TI fuente de confianza, es ser capaz de recuperar los datos de usuario originales.

Recuperación de intercambio de datos de destino F.13.4 FDP_UIT.3


Este componente proporciona la capacidad de recuperarse de un conjunto de errores de transmisión identificados. Esto se logratarea sin la ayuda del producto de las TI fuente de confianza. Por ejemplo, si se detectan determinados errores, laprotocolo de transmisión debe ser lo suficientemente robusta como para permitir que la TSF para recuperarse del error basado en sumas de comprobacióny otra información disponible dentro de ese protocolo.



En FDP_UIT.3.1, el autor de PP / ST debe especificar la SFP (s) de control de acceso y / o de control de flujo de informaciónSFP (s) que se aplica al recuperar los datos de usuario. Las políticas especificadas se aplicarán para hacerdecisiones sobre qué datos pueden ser recuperados y cómo se pueden recuperar.

En FDP_UIT.3.1, el autor PP / ST debe especificar la lista de errores de integridad de la que el TSF receptora,solo, es capaz de recuperar los datos de usuario originales.

12/6/2014 ISO / IEC 15408-2



Página 181

ISO / IEC 15408-2:2008 (E)


Anexo G

(Normativo)

Clase FIA: Identificación y autenticación

Un requisito de seguridad común es identificar de forma inequívoca a la persona y / o entidad que desarrolle funciones en unTOE. Esto implica no sólo el establecimiento de la identidad declarada de cada usuario, sino también verificar que cada usuario esde hecho, que él / ella dice ser. Esto se logra al exigir que los usuarios den el TSF con alguna informaciónlo que se conoce por el TSF que se asocia con el usuario en cuestión.

Las familias de esta clase frente a los requisitos para las funciones de establecer y verificar la identidad del usuario reclamado.Se requiere identificación y autenticación para garantizar que los usuarios se relacionan con la seguridad adecuadaatributos (por ejemplo, los niveles de identidad, grupos, funciones, seguridad o integridad).

La identificación inequívoca de los usuarios autorizados y la asociación correcta de atributos de seguridad conlos usuarios y los temas es fundamental para la aplicación de las políticas de seguridad.

El U de identificación de servicio (FIA_UID) direcciones de la familia que determinan la identidad de un usuario.

El U autentificación ser (FIA_UAU) fa mily direcciones que verifican la identidad de un usuario.

Los errores de autenticación (FIA_AFL) direcciones de la familia que definen los límites de éxito repetidolos intentos de autenticación.

El U definición de atributo ser (FIA_ATD) f amilia abordar la definición de los atributos de usuario que se utiliza en elejecución de la SFR.

La U de unión (FIA_USB) fa ser-sujeto aborda mily la asociación correcta de los atributos de seguridad para cadausuario autorizado.

El S pecification de secretos (FIA_SOS) fa mily aborda la generación y verificación de los secretos que satisfaganuna métrica definida.

Figura G.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Página 182

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Figura G.1 - FIA: Identificación y autenticación de la clase de descomposición

Fallos de autenticación G.1 (FIA_AFL)

G.1.1 notas de usuario

Esta familia se ocupa de los requisitos para la definición de los valores de los intentos de autenticación y acciones TSF en casosde fallo de intento de autenticación. Los parámetros incluyen, pero no se limitan a, el número de intentos y tiempoumbrales.

El proceso de establecimiento de sesión es la interacción con el usuario para llevar a cabo el establecimiento de la sesiónindependiente de la aplicación real. Si el número de intentos de autenticación fallidos excede elumbral indicado, o bien la cuenta de usuario o el terminal (o ambos) se bloqueará. Si la cuenta de usuario esdeshabilitada, el usuario no puede iniciar sesión en el sistema. Si el terminal está desactivado, el terminal (o la dirección que elterminal ha) no puede ser utilizado para cualquier inicio de sesión. Ambas situaciones continúan hasta que la condición para la re-establecimiento está satisfecho.

Página 183

ISO / IEC 15408-2:2008 (E)

Manejo de la insuficiencia G.1.2 FIA_AFL.1 autenticación

G.1.2.1 notas de aplicación de usuario

El autor PP / ST puede definir el número de intentos de autenticación fallidos o puede optar por dejar que laDesarrollador dedo del pie o el usuario autorizado para definir este número. Los intentos de autenticación fallidos necesitanno ser consecutivos, sino que se relaciona con un evento de autenticación. Tal evento de autenticación podría ser elcontar desde el último período de sesiones establecimiento exitoso en un terminal dado.

12/6/2014 ISO / IEC 15408-2



El autor PP / ST podría especificar una lista de acciones que el TSF debe tomar en el caso de fallo de autenticación. Unadministrador autorizado también se podía permitir que la gestión de los eventos, si se estima oportuno por el PP / STautor. Estas acciones pueden ser, entre otras cosas, la desactivación del terminal, cuenta de usuario o de desactivación,alarma administrador. Las condiciones en que la situación va a ser restaurado a la normalidad se deben especificar enla acción.

Con el fin de evitar la denegación de servicio, de los pies generalmente aseguran que hay al menos una cuenta de usuario que no puedeestar deshabilitado.

Nuevas medidas para el TSF pueden establecerse por el autor PP / ST, incluyendo reglas para volver a habilitar la sesión de usuarioproceso de creación, o enviar una alarma al administrador. Ejemplos de estas acciones son: hasta untiempo especificado ha transcurrido, hasta que el administrador autorizado vuelve a activar el terminal / cuenta, una vez relacionado conanteriores intentos fallidos (cada vez que el intento falla, se duplica el tiempo incapacitante).

Operaciones G.1.2.2

G.1.2.2.1 Selección

En FIA_AFL.1.1, el autor PP / ST debe seleccionar la asignación de un número entero positivo, o la frase "unaadministrador configurable entero positivo "que especifica el rango de valores aceptables.

G.1.2.2.2 Asignación

En FIA_AFL.1.1, el autor PP / ST debe especificar los eventos de autenticación. Ejemplos de estos autenticacióneventos son: los intentos de autenticación fallidos desde la última autenticación correcta para el indicadola identidad del usuario, los intentos de autenticación fallidos desde la última autenticación exitosa para la corrienteterminal, el número de intentos de autenticación fallidos en los últimos 10 minutos. Al menos unoevento de autenticación debe ser especificado.

En FIA_AFL.1.1, si se selecciona la asignación de un número entero positiva, el autor de PP / ST debe especificar el valor por defectonúmero (entero positivo) de autenticación infructuosos los intentos que, cuando se alcanzaron o superaron, dará lugar a laeventos.

En FIA_AFL.1.1, si se selecciona un administrador entero positivo configurable, el autor de PP / ST debe especificarel rango de valores aceptables de las que el administrador del TOE puede configurar el número delos intentos de autenticación fallidos. El número de intentos de autenticación debe ser menor que o igual ael límite superior y mayor o igual a los valores límite inferior.


En FIA_AFL.1.2, el autor PP / ST debe seleccionar si el evento de reunión o superando la definidanúmero de intentos de autenticación fallidos deberá activar una acción por el TSF.


En FIA_AFL.1.2, el autor PP / ST debe especificar las acciones que se deben tomar en caso de que se alcance el umbral osuperado, según se seleccione. Estas acciones pueden ser incapacitantes de una cuenta durante 5 minutos, desactivar el terminalpor una cantidad cada vez mayor de tiempo (2 a la potencia del número de intentos fallidos en segundos), ola desactivación de la cuenta hasta desbloqueado por el administrador y simultáneamente informar al administrador.

Página 184

ISO / IEC 15408-2:2008 (E)

Las acciones deben especificar las medidas y en su caso la duración de la medida (o las condicionesen las que se puso fin a la medida).

Definición de atributo G.2 Usuario (FIA_ATD)


Todos los usuarios autorizados pueden tener un conjunto de atributos de seguridad, aparte de la identidad del usuario, que se utiliza parahacer cumplir la SFR. Esta familia define los requisitos para la participación de los atributos de seguridad del usuario con los usuarios,necesaria para apoyar la TSF en la toma de decisiones de seguridad.

Hay dependencias de la política de seguridad individual (SFP) las definiciones. Estas definiciones individuales debencontendrá la lista de atributos que son necesarios para la aplicación de políticas.

G.2.2 FIA_ATD.1 definición de atributo de usuario


Este componente especifica los atributos de seguridad que deben mantenerse en el nivel del usuario. Este medio

12/6/2014 ISO / IEC 15408-2



que los atributos de seguridad enumerados se asignan y pueden ser modificados a nivel de usuario. En otras palabras,cambiar un atributo de seguridad en la lista asociada a un usuario no debería tener ningún impacto sobre los atributos de seguridadde cualquier otro usuario.

En el caso de los atributos de seguridad pertenecen a un grupo de usuarios (tales como lista de capacidades para un grupo), el usuario deberátener una referencia (como atributo de seguridad) para el grupo correspondiente.

Operaciones G.2.2.2


En FIA_ATD.1.1, el autor PP / ST debe especificar los atributos de seguridad asociados a un individuode usuario. Un ejemplo de dicha lista es {"despacho", "identificador de grupo", "derechos"}.

G.3 Especificación de los secretos (FIA_SOS)


Esta familia define requisitos para los mecanismos que hacen cumplir las métricas de calidad definidos en la proporcionados secretos, ygenerar secretos para satisfacer la métrica definida. Ejemplos de tales mecanismos pueden incluir automatizadola comprobación de usuario suministra las contraseñas, o automatizar la generación de contraseñas.

Un secreto puede generarse fuera del TOE (por ejemplo, seleccionado por el usuario y se introdujo en el TOE). En talescasos, la FIA_SOS.1 Verificación de secretos componente se puede utilizar para asegurar que generó el externoadhiere secretos a ciertas normas, por ejemplo, un tamaño mínimo, no se presentan en un diccionario, y / o noutilizado anteriormente.

Secretos también pueden ser generados por el OE. En esos casos, th e FIA_SOS.2 TSF Generación de secretoscomponente se puede utilizar para requerir el TOE para asegurar que los secretos que se adherirán a algunos especificanmétricas.

Secretos contienen los datos de autenticación proporcionados por el usuario para un mecanismo de autenticación que se basa enel conocimiento que el usuario posee. Cuando se emplean claves criptográficas, la clase FCS: criptográficosel apoyo debe ser utilizado en lugar de esta familia.

Página 185

ISO / IEC 15408-2:2008 (E)

G.3.2 FIA_SOS.1 Verificación de los secretos


Secretos pueden ser generados por el usuario. Este componente se asegura de que los secretos generados por el usuario pueden serverificado para cumplir con una cierta métrica de calidad.

Operaciones G.3.2.2


En FIA_SOS.1.1, el autor PP / ST debe proporcionar una métrica de calidad definido. La especificación métrica de calidad puedeser tan simple como una descripción de los controles de calidad que se deben realizar, o tan formales como una referencia a unGobierno norma publicada que define las métricas de calidad que deben cumplir los secretos. Ejemplos de calidadmétricas pueden incluir una descripción de la estructura alfanumérica de secretos aceptables y / o el tamaño del espaciosecretos que aceptables deben cumplir.

G.3.3 FIA_SOS.2 TSF Generación de secretos


Esta componente permite la TSF para generar secretos para funciones específicas, tales como la autenticación por medio decontraseñas.

Cuando se utiliza un generador de números pseudo-aleatorios en un algoritmo de generación de secreto, que debe aceptar como entradadatos aleatorios que proporcionar una salida que tiene un alto grado de imprevisibilidad. Estos datos aleatorios (semilla) puedeser derivado de un número de parámetros disponibles, tales como un reloj de sistema, los registros del sistema, fecha, hora, etcLos parámetros deben ser seleccionados para asegurar que el número de semillas únicas que se pueden generar a partirestas entradas deben ser al menos igual al número mínimo de secretos que debe ser generado.

Operaciones G.3.3.2

12/6/2014 ISO / IEC 15408-2




En FIA_SOS.2.1, el autor PP / ST debe proporcionar una métrica de calidad definido. La especificación métrica de calidad puedeser tan simple como una descripción de los controles de calidad que se deben realizar o como formales como una referencia a unGobierno norma publicada que define las métricas de calidad que deben cumplir los secretos. Ejemplos de calidadmétricas pueden incluir una descripción de la estructura alfanumérica de secretos aceptables y / o el tamaño del espaciosecretos que aceptables deben cumplir.

En FIA_SOS.2.2, el autor PP / ST debe proporcionar una lista de las funciones para las que el TSF TSF genera secretosdebe ser utilizado. Un ejemplo de una función de este tipo podría incluir un mecanismo de autenticación basada en contraseña.

La autenticación de usuarios G.4 (FIA_UAU)


Esta familia define los tipos de mecanismos de autenticación de usuarios que admite el TSF. Esta familia define laatributos necesarios en los que deben basarse los mecanismos de autenticación de usuario.

G.4.2 FIA_UAU.1 Momento de autenticación


Este componente requiere que el autor PP / ST definir las acciones mediadas por TSF que se pueden realizar por elTSF en nombre de el usuario antes de la identidad alegada de que el usuario está autenticado. Las acciones mediadas por TSFno debería tener problemas de seguridad con los usuarios de forma incorrecta identificarse antes de ser autenticado.

Página 186

ISO / IEC 15408-2:2008 (E)

Para todas las otras acciones no mediadas por TSF en la lista, el usuario debe estar autenticado antes de la acción puede serrealizado por el TSF en nombre del usuario.

Este componente no puede controlar si las acciones también se pueden realizar antes de la identificación se llevó a cabo.Esto requiere el uso de cualquiera de FIA_UID.1 Momento de identificación o FIA_UID.2 Identificación del usuario antes de cualquieracción con las asignaciones correspondientes.

Operaciones G.4.2.2


En FIA_UAU.1.1, el autor PP / ST debe especificar una lista de las acciones mediadas por TSF que se pueden realizar por elTSF en nombre de un usuario antes de que la identidad alegada de que el usuario está autenticado. Esta lista no puede estar vacío. Sihay acciones son apropiadas, componente FIA_UAU.2 La autenticación del usuario antes de cualquier acción se debe utilizaren su lugar. Un ejemplo de tal acción podría incluir la solicitud de ayuda en el procedimiento de conexión.

G.4.3 FIA_UAU.2 La autenticación del usuario antes de cualquier acción


Este componente requiere que un usuario se autentica antes de cualquier otra acción mediada TSF puede tener lugar ennombre de ese usuario.

G.4.4 FIA_UAU.3 autenticación infalsificable


Este componente se ocupa de los requisitos para los mecanismos que proporcionan protección de datos de autenticación.Datos de autenticación que se copian de otro usuario, o de alguna manera está construido deben ser detectados y / orechazado. Estos mecanismos ofrecen la confianza que los usuarios autenticados por el TSF son realmente quiendicen ser.

Este componente puede ser útil sólo con mecanismos de autenticación que se basan en los datos de autenticaciónque no pueden ser compartidos (por ejemplo, biometría). Es imposible que un TSF para detectar o prevenir el intercambio decontraseñas fuera del control de la TSF.

Operaciones G.4.4.2


En FIA_UAU.3.1, el autor PP / ST debe especificar si el TSF detectar, prevenir, o detectar y prevenirforja de datos de autenticación.

12/6/2014 ISO / IEC 15408-2



En FIA_UAU.3.2, el autor PP / ST debe especificar si el TSF detectar, prevenir, o detectar y prevenirla copia de los datos de autenticación.

G.4.5 FIA_UAU.4 mecanismos de autenticación de un solo uso


Este componente se ocupa de los requisitos para los mecanismos de autenticación basados en la autenticación de un solo usodatos. Datos de autenticación de un solo uso pueden ser algo que el usuario tiene o sabe, pero no es algo que el usuario es.Ejemplos de datos de autenticación de un solo uso incluyen las contraseñas de un solo uso, cifrada sellos de tiempo, y / onúmeros aleatorios de una tabla de búsqueda secreta.

El autor PP / SAN pueden especificar al que sea aplicable este requisito mecanismo (s) de autentificación.

Página 187

ISO / IEC 15408-2:2008 (E)

Operaciones G.4.5.2


En FIA_UAU.4.1, el autor de PP / ST debe especificar la lista de mecanismos de autenticación a la que estarequisito se aplica. Esta asignación puede ser "todos los mecanismos de autenticación". Un ejemplo de esta asignaciónque podría ser "el mecanismo de autenticación utilizado para autenticar a las personas en la red externa".

G.4.6 FIA_UAU.5 mecanismos de autenticación múltiples


El uso de este componente permite la especificación de los requisitos para más de un mecanismo de autenticaciónpara ser utilizado dentro de un TOE. Para cada mecanismo distinto, los requisitos aplicables deben ser escogidos de la FIA:Identificación y autenticación de la clase que se aplicarán a cada mecanismo. Es posible que el mismocomponente podría ser seleccionado varias veces con el fin de reflejar los diferentes requisitos para el uso de diferentesel mecanismo de autenticación.

Las funciones de gestión de la FMT clase pueden proporcionar capacidades de mantenimiento para el conjunto demecanismos de autenticación, así como las reglas que determinan si la autenticación se realizó correctamente.

Para permitir que los usuarios anónimos para interactuar con el TOE, un "ninguno" mecanismo de autenticación se puede incorporar.El uso de dicho acceso debe estar claramente explicado en las reglas de FIA_UAU.5.2.

Operaciones G.4.6.2


En FIA_UAU.5.1, el autor PP / ST debe definir los mecanismos de autenticación disponibles. Un ejemplo deuna lista de este tipo podría ser: "ninguno, el mecanismo de contraseña, biométrico (escáner de retina), S / mecanismo clave".

En FIA_UAU.5.2, el autor PP / ST debe especificar las reglas que describen cómo los mecanismos de autenticaciónproporcionar autenticación y cuando cada uno es para ser utilizado. Esto significa que para cada situación el conjunto de mecanismosque podrían ser utilizados para autenticar el usuario debe ser descrito. Un ejemplo de una lista de tales reglas es: "si elusuario tiene privilegios especiales, un mecanismo de contraseña y un mecanismo biométrico tanto se utilizarán, conel éxito sólo si ambos tienen éxito; para el resto de los usuarios se utilizará un mecanismo de contraseña ".

El autor PP / ST podría dar a los límites dentro de los cuales el administrador autorizado puede especificar específicanormas. Un ejemplo de una regla es: "el usuario siempre será autenticada por medio de una ficha; el administradorpodría especificar los mecanismos de autenticación adicionales que también deben ser utilizados ". El autor PP / ST también podríaoptar por no especificar ningún límite, pero dejan los mecanismos de autenticación y sus reglas completamentepara el administrador autorizado.

G.4.7 FIA_UAU.6 Reautenticación


Este componente se ocupa de las necesidades potenciales de volver a autenticar a los usuarios en lugares definidos en el tiempo. Estos puedenincluir las peticiones de usuarios para la TSF para llevar a cabo las acciones pertinentes de seguridad, así como las peticiones de no TSFentidades de re-autenticación (por ejemplo, una aplicación de servidor solicita que el TSF re-autenticar al cliente esración).

Operaciones G.4.7.2


12/6/2014 ISO / IEC 15408-2



En FIA_UAU.6.1, el autor PP / ST debe especificar la lista de condiciones que requieren re-autenticación. Esta listapodría incluir un período de inactividad especificado que ha transcurrido, el usuario que solicita un cambio en activolos atributos de seguridad, o el usuario que solicita la TSF para realizar alguna función crítica de seguridad.

Página 188

ISO / IEC 15408-2:2008 (E)


El autor PP / ST podría dar a los límites dentro de los cuales debe ocurrir la nueva autenticación y dejar elespecíficos para el administrador autorizado. Un ejemplo de una norma de este tipo es: "el usuario siempre será re-autenticada por lo menos una vez al día; el administrador puede especificar que la re-autenticación debe sucedermás a menudo, pero no más de una vez cada 10 minutos. "

G.4.8 FIA_UAU.7 Protegida retroalimentación autenticación


Este componente se refiere a la información sobre el proceso de autenticación que se proporcionará al usuario. Enalgunos sistemas de la retroalimentación consiste en indicar cuántos caracteres se han escrito, pero no muestra lapropios personajes, en otros sistemas, incluso esta información podría no ser apropiada.

Este componente requiere que los datos de autenticación no se proporciona como está de vuelta al usuario. En una estación de trabajomedio ambiente, que podría mostrar una "ficticia" (por ejemplo, la estrella) para cada carácter de la contraseña proporcionada, y no el originalcarácter.

Operaciones G.4.8.2


En FIA_UAU.7.1, el autor PP / ST debería especificar las votaciones relacionadas con el proceso de autenticación que seser proporcionado al usuario. Un ejemplo de una tarea de regeneración es "el número de caracteres al escribir", otrotipo de regeneración es "el mecanismo de autenticación que ha fallado la autenticación".

G.5 identificación de usuario (FIA_UID)


Esta familia define las condiciones en las que los usuarios están obligados a identificarse antes de realizar cualquierotras acciones que han de ser mediada por la TSF y que requieren la identificación del usuario.

G.5.2 FIA_UID.1 Momento de la identificación


Este componente plantea requisitos para que el usuario sea identificado. El autor de PP / ST puede indicar específicalas acciones que se pueden realizar antes de la identificación se lleva a cabo.

Si FIA_UID.1 Momento de la identificació n se utiliza, las acciones mediadas por TSF mencionados en FIA_UID.1 Momento de laidentificatio n debe aparecer en este Momento FIA_UAU.1 de autentificación.

Operaciones G.5.2.2


En FIA_UID.1.1, el autor PP / ST debe especificar una lista de las acciones mediadas por TSF que se pueden realizar por elTSF en nombre de un usuario antes de que el usuario tiene que identificarse a sí mismo. Si hay acciones son apropiadas, componenteFIA_UID.2 identificación del usuario antes de cualquier actio n se debe utilizar en su lugar. Un ejemplo de una acción de este tipo podríaincluir la solicitud de ayuda en el procedimiento de conexión.

G.5.3 FIA_UID.2 identificación del usuario antes de cualquier acción


En este componente se identificarán los usuarios. Un usuario no está permitido por la TSF para realizar cualquier acción antes de seridentificado.

12/6/2014 ISO / IEC 15408-2


Página 189ISO / IEC 15408-2:2008 (E)


G.6 el usuario sujeta la unión (FIA_USB)


Un usuario autenticado, con el fin de utilizar el TOE, típicamente activa un sujeto. Los atributos de seguridad del usuario sonasociado (total o parcialmente) con este tema. Esta familia define requisitos para crear y mantener laasociación de seguridad del usuario atribuye a un sujeto que actúa en nombre del usuario.

G.6.2 FIA_USB.1 vinculante usuario-sujeto


Se pretende que un sujeto actúa en nombre del usuario que ha causado el tema para llegar a existir o seractivado para realizar una tarea determinada.

Por lo tanto, cuando se crea un objeto, ese tema está actuando en nombre del usuario que inició la creación. Enlos casos en que se utiliza el anonimato, el tema todavía está actuando en nombre de un usuario, pero la identidad de ese usuario esdesconocido. Una categoría especial de los sujetos son aquellos sujetos que sirven varios usuarios (por ejemplo, un proceso de servidor).En tales casos, el usuario que ha creado este tema se supone que es el "dueño".

Operaciones G.6.2.2


En FIA_USB.1.1, el autor de PP / ST debe especificar una lista de los atributos de seguridad de usuario que han de ser obligado asujetos.

En FIA_USB.1.2, el autor PP / ST debe especificar todas las normas que se han de aplicar a la asociación inicial deatributos con los sujetos, o "ninguno".

En FIA_USB.1.3, el autor PP / ST debe especificar todas las normas que han de aplicarse cuando se realizan cambios en lalos atributos de seguridad de usuario asociados con los sujetos que actúan en nombre de los usuarios, o "ninguno".

Página 190

ISO / IEC 15408-2:2008 (E)

Anexo H

(Normativo)

Clase FMT: Gestión de la seguridad

12/6/2014 ISO / IEC 15408-2



Esta clase especifica la gestión de varios aspectos de la TSF: atributos de seguridad, los datos de la TSF yfunciones en el TSF. Las diferentes funciones de gestión y su interacción, como la separación de la capacidad,También se puede especificar.

En un entorno en el TOE se compone de varias piezas separadas físicamente, los problemas de tiempo conrespecto a la propagación de los atributos de seguridad, los datos de la TSF y modificación de la función a ser muy compleja,especialmente si se requiere la información para ser replicado a través de las partes del TOE. Esto debería sercuenta a la hora de seleccionar los componentes, tales como FMT_REV.1 Revocación, o FMT_SAE.1 tiempo limitado-autorización , en el que el comportamiento podría verse afectada. En tales situaciones, el uso de componentes de InternaTSF TOE coherencia de replicación de datos (FPT_TRC) i s aconsejable.

Figura A.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Página 191

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Figura A.1 - FMT: clase de gestión de seguridad de descomposición

Gestión H.1 de funciones en TSF (FMT_MOF)

Notas H.1.1 usuario

Las funciones de gestión de la alimentación suplementaria selectiva permiten a los usuarios autorizados a establecer y controlar la operación segura de laTOE. Estas funciones administrativas normalmente se dividen en una serie de diferentes categorías:

a) Las funciones de gestión que se relacionan con el control de acceso, controles de rendición de cuentas y autenticación cumplirpor el TOE. Por ejemplo, la definición y actualización de las características de seguridad de usuario (por ejemplo, identificadores únicosasociada a los nombres de usuario, cuentas de usuario, los parámetros de entrada del sistema) o la definición y actualización de la auditoríacontroles del sistema (por ejemplo, selección de eventos de auditoría, gestión de los registros de auditoría, análisis de seguimiento de auditoría y la auditoríageneración de informes), la definición y actualización de los atributos de política de cada usuario (como el despacho de usuario), definiciónetiquetas de control de acceso del sistema de conocido, y el control y la gestión de grupos de usuarios.

b) Las funciones de gestión que se refieren a los controles sobre la disponibilidad. Por ejemplo, la definición y actualización deparámetros de disponibilidad o de cuotas de recursos.

Página 192

ISO / IEC 15408-2:2008 (E)

c) Las funciones de gestión relacionadas con la instalación y la configuración general. Por ejemplo, TOEconfiguración, recuperación manual, la instalación de parches de seguridad TOE (si los hay), la reparación y reinstalación dede hardware.

d) Las funciones de gestión que se relacionan con el control de rutina y mantenimiento de los recursos TOE. Por ejemplo,activación y desactivación de los dispositivos periféricos, el montaje de medios extraíbles de almacenamiento, backup y recuperación.

Tenga en cuenta que estas funciones necesitan estar presentes en una TOE sobre la base de las familias incluidas en el PP o ST. Es laresponsabilidad del autor PP / ST para asegurar que las funciones adecuadas se proporcionará para gestionar la TOE en unasegurar la moda.

La TSF puede contener funciones que pueden ser controlados por un administrador. Por ejemplo, la auditoríafunciones podrían ser apagadas, la sincronización de tiempo podría ser conmutable, y / o la autenticaciónmecanismo podría ser modificable.

Gestión FMT_MOF.1 H.1.2 de las funciones de seguridad comportamiento

Notas de aplicación H.1.2.1 usuario

Este componente permite que los roles identificados para la gestión de las funciones de seguridad del TSF. Esto podría implicar la obtenciónel estado actual de una función de seguridad, desactivar o activar la función de seguridad, o modificar el comportamientode la función de seguridad. Un ejemplo de la modificación del comportamiento de las funciones de seguridad está cambiando demecanismos de autenticación.

Operaciones H.1.2.2

H.1.2.2.1 Selección

En FMT_MOF.1.1, t él PP / ST autor debe seleccionar si el papel se puede determinar el comportamiento de, deshabilitar,

12/6/2014 ISO / IEC 15408-2



habilitar y / o modificar el comportamiento de las funciones de seguridad.

H.1.2.2.2 Asignación

En FMT_MOF.1.1, t él PP / ST autor deberá especificar las funciones que pueden ser modificadas por los roles identificados.Los ejemplos incluyen la auditoría y la determinación del tiempo.

En FMT_MOF.1.1, t él PP / ST autor deberá especificar las funciones que se les permite modificar las funciones en elTSF. Las posibles funciones se especifican i n FMT_SMR.1 Seguridad roles.

Gestión H.2 de atributos de seguridad (FMT_MSA)

H.2.1 notas de usuario

Esta familia define los requisitos relativos a la gestión de los atributos de seguridad.

Los atributos de seguridad afectan el comportamiento de la TSF. Ejemplos de atributos de seguridad son los grupos a los que unusuario pertenece, los papeles que él / ella podría asumir, la prioridad de un proceso (sujeto), y los derechos que pertenecen a unpapel o un usuario. Estos atributos de seguridad que tenga que ser administrado por el usuario, un objeto, una específicausuario autorizado (un usuario con derechos otorgados expresamente para esta gestión) o valores heredan de acuerdo con un determinadopolítica / conjunto de reglas.

Cabe señalar que el derecho de asignar derechos a los usuarios es en sí misma un atributo de seguridad y / o potencialmente sujetas agestión por F MT_MSA.1 Gestión de atributos de seguridad.

Atributos de seguridad FMT_MSA.2 seguros pueden ser utilizados para garantizar que cualquier combinación de seguridad aceptadasatributos se encuentra dentro de un estado seguro. La definición de lo "seguro" significa que se deja a la orientación TOE.

Página 193

ISO / IEC 15408-2:2008 (E)

En algunos casos se crean los sujetos, objetos o cuentas de usuario. Si no hay valores explícitos para la seguridad relacionadosse dan atributos, valores por defecto deben ser uso d. Gestión FMT_MSA.1 de atributos de seguridad puede serse utiliza para especificar que estos valores predeterminados pueden ser manejados.

Gestión FMT_MSA.1 H.2.2 de los atributos de seguridad


Este componente permite a los usuarios que actúan en ciertas funciones para gestionar los atributos de seguridad identificados. Los usuarios de Internet estánasignado un papel dentro de los componentes papeles FMT_SMR.1 Seguridad.

El valor predeterminado de un parámetro es el valor del parámetro toma cuando se crea una instancia sin específicamentevalores asignados. Un valor inicial se proporcionó durante la creación de instancias (la creación) de un parámetro, y anulacionesel valor por defecto.

Operaciones H.2.2.2


En FMT_MSA.1.1, el autor PP / ST debe enumerar la SFP (s) de control de acceso o el control del flujo de informaciónLa SFP (s) por el cual los atributos de seguridad son aplicables.


En FMT_MSA.1.1, TH e PP / ST autor debe especificar las operaciones que se pueden aplicar a la seguridad identificadoatributos. El autor PP / ST puede especificar que el papel puede modificar el valor por defecto (change_default), consulta,modificar el atributo de seguridad, elimine los atributos de seguridad completa o definir su propio funcionamiento.


En FMT_MSA.1.1, t él PP / ST autor debe especificar los atributos de seguridad que puedan ser explotados en elpapeles identificados. Es posible que el autor de PP / ST para especificar que el valor por defecto como el acceso-defaultderechos pueden ser manejados. Ejemplos de estos son los atributos de seguridad del usuario al despacho, la prioridad de nivel de servicio,lista de control de acceso, los derechos de acceso predeterminado.

En FMT_MSA.1.1, el autor PP / ST debe especificar las funciones que se les permite operar en la seguridadatributos. Las posibles funciones se especifican en los roles FMT_SMR.1 Seguridad.

En FMT_MSA.1.1, i f seleccionado, el autor PP / ST debería especificar qué otras operaciones el papel podría realizar.Un ejemplo de tal operación podría ser "crear".

12/6/2014 ISO / IEC 15408-2



Atributos de seguridad Secure FMT_MSA.2 H.2.3


Este componente contiene requerimientos sobre los valores que se pueden asignar a los atributos de seguridad. La asignadovalores deben ser tales que el TOE permanecerá en un estado seguro.

La definición de lo "seguro" los medios no se responde en este componente, pero se deja a la evolución de laTOE y la información resultante de la orientación. Un ejemplo podría ser que si se crea una cuenta de usuario,debería tener una contraseña no trivial.

Operaciones H.2.3.2


En FMT_MSA.2.1, th e PP / ST autor debe especificar la lista de atributos de seguridad que requieren valores sólo segurasque se preste.

Página 194

ISO / IEC 15408-2:2008 (E)

FMT_MSA.3 H.2.4 estático inicialización atributo


Este componente requiere que el TSF proporcionan valores por defecto para los atributos de seguridad de objetos relevantes, lo que puedeser anulado por un valor inicial. Todavía puede ser posible que un nuevo objeto de tener diferentes atributos de seguridad encreación, si no existe un mecanismo para especificar los permisos en el momento de la creación.

Operaciones H.2.4.2


En FMT_MSA.3.1, t él PP / ST autor debe indicar el SFP de control de acceso o SFP de control del flujo de información paraque los atributos de seguridad son aplicables.


En FMT_MSA.3.1, t él PP / ST autor debe seleccionar si la propiedad predeterminada del atributo de control de accesoserá restrictiva, permisiva, u otra propiedad. Sólo una de estas opciones se puede elegir.


En FMT_MSA.3.1, i f autor PP / ST selecciona otra propiedad, el autor PP / ST debe especificar el deseadocaracterísticas de los valores por defecto.

En FMT_MSA.3.2, t él PP / SAN autor deberá especificar las funciones que están autorizados para modificar los valores de lalos atributos de seguridad. Las posibles funciones se especifican en los roles FMT_SMR.1 Seguridad.

H.2.5 FMT_MSA.4 Seguridad valor del atributo de herencia


Este componente requiere la especificación del conjunto de reglas a través del cual el atributo de seguridad hereda los valoresy las condiciones que deben cumplirse para estas normas que deben aplicarse.

Operaciones H.2.5.2


En FMT_MSA.4.1, th e PP / ST autor precisa las normas que regulan el valor que se heredan por laatributo de seguridad especificado, incluyendo las condiciones que se deben cumplir para las normas que deben aplicarse. Por ejemplo,si se crea un nuevo archivo o directorio (en un sistema de archivos de múltiples niveles), su etiqueta es la etiqueta en la que se registra el usuarioen el momento de su creación.

Gestión H.3 de datos de TSF (FMT_MTD)


Este componente impone requisitos sobre la gestión de los datos de la TSF. Ejemplos de datos de TSF son elhora actual y la pista de auditoría. Así, por ejemplo, esta familia permite especificar quién puede leer, borraro crear la pista de auditoría.

12/6/2014 ISO / IEC 15408-2



H.3.2 FMT_MTD.1 Gestión de los datos TSF


Este componente permite a los usuarios con un cierto papel para gestionar los valores de los datos de la TSF. Los usuarios se asignan a unpapel dentro de los componentes papeles FMT_SMR.1 Seguridad.

Página 195

ISO / IEC 15408-2:2008 (E)


El valor predeterminado de un parámetro son los valores del parámetro toma cuando se crea una instancia sin específicamentevalores asignados. Un valor inicial se proporcionó durante la creación de instancias (la creación) de un parámetro y anulacionesel valor por defecto.

Operaciones H.3.2.2


En FMT_MTD.1.1, t él PP / ST autor deberá especificar las operaciones que se pueden aplicar a la TSF identificadodatos. El autor PP / ST puede especificar que el papel puede modificar el valor por defecto (change_default), claro, consultao modificar los datos de TSF, o borrar los datos TSF completo. Si así lo desea el autor PP / ST podría especificar cualquier tipo dede operación. Para aclarar "datos TSF claro" significa que se elimina el contenido de los datos de TSF, pero que la entidadque almacena los datos TSF permanece en el TOE.


En FMT_MTD.1.1, t él PP / ST autor debe especificar los datos TSF que puede ser operado por la identificadaroles. Es posible que el autor de PP / ST para especificar que el valor por defecto puede ser controlado.

En FMT_MTD.1.1, t él PP / ST autor deberá especificar las funciones que se les permite operar en los datos TSF. Laposibles funciones se especifican i n FMT_SMR.1 Seguridad roles.

En FMT_MTD.1.1, i f seleccionado, el autor PP / ST debería especificar qué otras operaciones el papel podría realizar.Un ejemplo podría ser "crear".

H.3.3 FMT_MTD.2 Gestión de límites en los datos TSF


Este componente especifica límites en los datos de TSF, y las acciones que se deben tomar si se superan estos límites. Estecomponente, por ejemplo, permitirá a límites en el tamaño de la pista de auditoría a ser definidos, y la especificación de lalas acciones que se deben tomar cuando se superan estos límites.

Operaciones H.3.3.2


En FMT_MTD.2.1, t él PP / ST autor debe especificar los datos TSF que pueden tener límites, y el valor de loslímites. Un ejemplo de tales datos TSF es el número de usuarios registrados en.

En FMT_MTD.2.1, t él PP / ST autor deberá especificar las funciones que se les permite modificar los límites a la TSFlos datos y las acciones a tomar. Las posibles funciones se especifican i n FMT_SMR.1 Seguridad roles.

En FMT_MTD.2.2, th e PP / ST autor debe especificar las acciones que se tomarán si el límite especificado en el especificadoSe excede de datos TSF. Un ejemplo de tal acción TSF es que el usuario autorizado se informó y una auditoríase genera registro.

FMT_MTD.3 H.3.4 Secure datos TSF


Este componente abarca las prescripciones sobre los valores que se pueden asignar a los datos de la TSF. Los valores asignadosdebe ser tal que el dedo se mantendrá en un estado seguro.

La definición de lo "seguro" los medios no se responde en este componente, pero se deja a la evolución de laTOE y la información resultante de la orientación.

12/6/2014 ISO / IEC 15408-2


Página 196

ISO / IEC 15408-2:2008 (E)


Operaciones H.3.4.2


En FMT_MTD.3.1, t él PP / ST autor debe especificar lo que requieren los datos TSF únicos valores seguros para ser aceptados.

H.4 Revocación (FMT_REV)


Esta direcciones familiares revocación de atributos de seguridad para una variedad de entidades dentro de un TOE.

Revocación FMT_REV.1 H.4.2


Este componente especifica los requisitos sobre la revocación de los derechos. Se requiere la especificación de lareglas de revocación. Ejemplos son:

a) La revocación se llevará a cabo en el siguiente inicio de sesión del usuario;

b) La revocación se llevará a cabo en el siguiente intento para abrir el archivo;

c) Revocación se llevará a cabo dentro de un plazo fijo. Esto podría significar que todas las conexiones abiertas se vuelven a evaluarcada x minutos.

Operaciones H.4.2.2


En FMT_REV.1.1, t él PP / ST autor debe especificar los atributos de seguridad deben ser revocado cuando un cambiose hace referencia a la asociada objeto / sujeto / user / otro recurso.


En FMT_REV.1.1, t él PP / ST autor debe especificar si la capacidad de revocar los atributos de seguridad de los usuarios,temas, objetos o recursos adicionales estarán a cargo de la TSF.


En FMT_REV.1.1, t él PP / ST autor deberá especificar las funciones que se les permite modificar las funciones en elTSF. Las posibles funciones se especifican i n FMT_SMR.1 Seguridad roles.

En FMT_REV.1.1, t él PP / ST autor debe, si se selecciona recursos adicionales, especificar si la capacidad derevocar sus atributos de seguridad estarán a cargo de la TSF.

En FMT_REV.1.2, el autor PP / ST debe especificar las reglas de revocación. Ejemplos de estas normas podríaincluir: "con anterioridad a la próxima operación en el recurso asociado", o "para todas las nuevas creaciones sujetas a investigación".

Caducidad atributo A.5 Seguridad (FMT_SAE)


Esta familia se refiere a la capacidad de hacer cumplir los plazos de validez de los atributos de seguridad. Esta familia puedeaplicarse para especificar los requisitos de caducidad de los atributos de control de acceso, identificación y autenticaciónatributos, certificados (certificados de clave como ANSI X509, por ejemplo), atributos de auditoría, etc

Página 197

ISO / IEC 15408-2:2008 (E)

Autorización H.5.2 FMT_SAE.1 tiempo limitado-

Operaciones H.5.2.1

12/6/2014 ISO / IEC 15408-2




En FMT_SAE.1.1, t él PP / ST autor debe proporcionar la lista de atributos de seguridad para los que de caducidad es serapoyado. Un ejemplo de tal atributo podría ser la habilitación de seguridad de un usuario.

En FMT_SAE.1.1, t él PP / ST autor deberá especificar las funciones que tienen permiso para modificar los atributos de seguridaden la TSF. Las posibles funciones se especifican i n FMT_SMR.1 Seguridad roles.

En FMT_SAE.1.2, t él PP / ST autor debe proporcionar una lista de acciones a realizar para cada atributo de seguridad cuandode que expire. Un ejemplo podría ser que la habilitación de seguridad del usuario, cuando éste expire, está ajustado a la más bajaholgura admisible en el TOE. Si la revocación inmediata es deseado por el PP / ST, la acción "inmediata"se debe especificar la revocación.

H.6 Especificación de las funciones de gestión (FMT_SMF)


Esta familia permite la especificación de las funciones de gestión que ha de proporcionar el TOE. Cada valorfunción de administración que se muestra en el cumplimiento de la asignación es o bien la gestión de atributo de seguridad, TSFgestión de datos, o la gestión de la función de seguridad.

FMT_SMF.1 H.6.2 La especificación de las funciones de gestión


Este componente se especifican las funciones de gestión que se preste.

Autores PP / ST deben consultar las subcláusulas "gestión" de los componentes incluidos en el PP / ST paraproporcionar una base para las funciones de gestión que se enumeran a través de este componente.

Operaciones H.6.2.2


En FMT_SMF.1.1, el autor PP / ST debería especificar las funciones de gestión a ser proporcionada por el TSF,ya sea la gestión de atributo de seguridad, gestión de datos TSF, o la gestión de la función de seguridad.

Funciones de gestión H.7 Seguridad (FMT_SMR)


Esta familia reduce la posibilidad de daños resultantes de los usuarios abusen de su autoridad por medio de accionesfuera de sus responsabilidades funcionales asignados. También se ocupa de la amenaza de que los mecanismos inadecuadosse han previsto para administrar de forma segura el TSF.

Esta familia requiere que se mantenga la información para identificar si un usuario está autorizado a utilizar una determinadafunción administrativa relevante para la seguridad.

Algunas acciones de manejo pueden ser realizadas por los usuarios, los demás sólo por personas designadas dentro de laorganización. Esta familia permite la definición de diferentes roles, como propietario, auditor, administrador, todos los días-gestión.

Los papeles como empleados en esta familia son los roles de seguridad relacionados. Cada rol puede abarcar un amplio conjunto decapacidades (por ejemplo, la raíz en UNIX), o puede ser un solo derecho (por ejemplo, derecho a leer un solo objeto como el archivo de ayuda).

Página 198

ISO / IEC 15408-2:2008 (E)

Esta familia define los papeles. Las capacidades de la función se definen en Gestión de funciones en TSF(FMT_MOF), M estión de los atributos de seguridad (FMT_MSA) y de gestión de los datos de la TSF (FMT_MTD).

Algunos tipo de papeles podría ser mutuamente excluyentes. Por ejemplo la gestión diaria podría ser capaz de definiry activar a los usuarios, pero podría no ser capaz de eliminar los usuarios (las cuales está reservada para el administrador (papel)). Esteclase permitirá a políticas tales como el control de dos personas que se determine.

Papeles H.7.2 FMT_SMR.1 Seguridad


Este componente se especifican los diferentes roles que la TSF debe reconocer. A menudo, el sistema distingueentre el propietario de una entidad, un administrador y otros usuarios.

Operaciones H.7.2.2

12/6/2014 ISO / IEC 15408-2




En FMT_SMR.1.1, t él PP / ST autor deberá especificar las funciones que son reconocidos por el sistema. Estos son losroles que los usuarios podían ocupar con respecto a la seguridad. Algunos ejemplos son: propietario, auditor y administrador.

Restricciones FMT_SMR.2 H.7.3 sobre los roles de seguridad

Notas de la aplicación H.7.3.1 usuario

Este componente se especifican los diferentes roles que la TSF debe reconocer, y condiciones sobre cómo esos rolespodría ser administrado. A menudo, el sistema distingue entre el propietario de una entidad, un administrador y otralos usuarios.

Las condiciones en esas funciones especifican la interrelación entre las diferentes funciones, así como las restriccionescuando el papel puede ser asumido por el usuario.

Operaciones H.7.3.2


En FMT_SMR.2.1, t él PP / ST autor deberá especificar las funciones que son reconocidos por el sistema. Estos son losroles que los usuarios podían ocupar con respecto a la seguridad. Algunos ejemplos son: propietario, auditor, administrador.

En FMT_SMR.2.3, t él PP / ST autor deberá especificar las condiciones que rigen la asignación de funciones. Ejemplos deestas condiciones son: "una cuenta no puede tener tanto el auditor y el papel de administrador" o "un usuario con elfunción auxiliar también debe tener la función de propietario ".

FMT_SMR.3 H.7.4 Asumiendo los roles


Este componente se especifica que una petición explícita se debe dar a asumir el rol específico.

Operaciones H.7.4.2


En FMT_SMR.3.1, t él PP / ST autor deberá especificar las funciones que requieren una petición explícita para ser asumido.Ejemplos de ello son: el auditor y administrador.

Página 199

ISO / IEC 15408-2:2008 (E)

Anexo I

(Normativo)

FPR Clase: Privacidad

Esta clase describe los requisitos que podían percibirse a satisfacer las necesidades de privacidad de los usuarios, al tiempo quepermitiendo la flexibilidad del sistema en la medida de lo posible para mantener un control suficiente sobre el funcionamiento del sistema.

En los componentes de esta clase hay flexibilidad en cuanto a si o no los usuarios autorizados están cubiertas por lafuncionalidad de seguridad requerida. Por ejemplo, un autor de PP / ST considere oportuno no exigirprotección de la privacidad de los usuarios contra un usuario debidamente autorizado.

Esta clase, junto con otras clases (como los relacionados con la auditoría, control de acceso, ruta de confianza, yno repudio) proporciona la flexibilidad para especificar el comportamiento de la privacidad deseada. Por otro lado, larequisitos de esta categoría podrían imponer limitaciones sobre el uso de los componentes de las otras clases, tales comoFIA: Identificación y autenticación o FAU: Auditoría de seguridad. Por ejemplo, los usuarios autorizados si no se les permitepara ver la identidad del usuario (por ejemplo, el anonimato o seudónimos), es obvio que no será posible mantener individuousuarios responsables por ninguna acción pertinentes de seguridad que realizan que están cubiertos por los requisitos de privacidad.Sin embargo, todavía puede ser posible incluir los requisitos de auditoría en un PP / ST, en el que el hecho de que un particular,la seguridad se ha producido un evento relevante es más importante que saber quién era el responsable.

Se proporciona información adicional en las notas de aplicación para la clase FAU: Auditoría de seguridad, donde se explicaque la definición de "identidad" en el contexto de la auditoría también puede ser un alias o cualquier otra información que pudieraidentificar a un usuario.

12/6/2014 ISO / IEC 15408-2



Esta clase describe cuatro familias: El anonimato, seudónimos, imposibilidad de vinculación y de imposibilidad de observación. El anonimato,Seudónimos y imposibilidad de vinculación tienen una interrelación compleja. Al elegir una familia, la elección debedependerá de las amenazas identificadas. Para algunos tipos de amenazas a la privacidad, seudonimia será más apropiadode anonimato (por ejemplo, si existe un requisito para la auditoría). Además, algunos tipos de amenazas a la privacidad son mejorcontrarrestada por una combinación de componentes de varias familias.

Todas las familias asumen que un usuario no realiza explícitamente una acción que da a conocer la propia identidad del usuario. Paraejemplo, no se espera que el TSF a la pantalla el nombre de usuario en los mensajes electrónicos o bases de datos.

Todas las familias en esta clase tienen componentes que pueden ser a través de cuyo ámbito de operaciones. Estas operaciones permiten laPP / ST autor para exponer los cooperantes usuarios / temas a los que la TSF deben ser resistentes. Un ejemplo de uncreación de instancias de anonimato podría ser: "La TSF debe garantizar que los usuarios y / o sujetos son incapaces dedeterminar la identidad de usuario con destino a la aplicación de teleconsulta ".

Se observa que la TSF no sólo debe proporcionar esta protección contra usuarios individuales, sino también contra los usuarioscooperar para obtener la información.

Figura I.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Página 200

ISO / IEC 15408-2:2008 (E)

Figura I.1 - FPR: Privacidad clase descomposición

I.1 Anonimato (FPR_ANO)

I.1.1 notas de usuario

El anonimato asegura que un sujeto puede utilizar un recurso o servicio, sin revelar su identidad del usuario.

La intención de esta familia es especificar que un usuario o tema podría actuar sin la liberación de su usuarioidentidad a otras personas como usuarios, sujetos u objetos. La familia proporciona el autor de PP / ST con un medio paraidentificar el conjunto de usuarios que no pueden ver la identidad de quien realiza ciertas acciones.

Por lo tanto si un sujeto, utilizando el anonimato, realiza una acción, otro tema no será capaz de determinarya sea la identidad o incluso una referencia a la identidad del usuario que emplea el sujeto. El enfoque de lael anonimato es relativo a la protección de la identidad de los usuarios, no sobre la protección de la identidad del sujeto; por lo tanto, la

12/6/2014 ISO / IEC 15408-2



identidad del sujeto no está protegida contra la divulgación.

Aunque la identidad del sujeto no se libera a otros sujetos o usuarios, la TSF no es explícitamenteprohíbe la obtención de la identidad de los usuarios. En caso de que el TSF no se le permite conocer la identidad del usuario,FPR_ANO.2 anonimato sin solicitar información c Ould ser invocada. En ese caso, el TSF no deberíasolicitar la información del usuario.

La interpretación de "determinar" debe tomarse en el sentido amplio de la palabra.

La nivelación componente distingue entre los usuarios y un usuario autorizado. Un usuario autorizado es a menudoexcluidos de la componente, y por lo tanto permitido para recuperar la identidad de un usuario. Sin embargo, no hay ninguna específicarequisito de que un usuario autorizado ha de ser capaz de tener la capacidad de determinar la identidad del usuario. Paramáxima privacidad de los componentes se utilizan para decir que ningún usuario o usuario autorizado pueden ver la identidad decualquier persona que realice ninguna acción.

Aunque algunos sistemas proporcionarán el anonimato de todos los servicios que se proporcionan, otros sistemas proporcionananonimato para ciertos temas / operaciones. Para proporcionar esta flexibilidad, se incluye una operación en el ámbitodel requisito se define. Si el autor de PP / ST quiere abordar todos los temas / operaciones, las palabras "todo"se podrían proporcionar materias y todas las operaciones.

Página 201

ISO / IEC 15408-2:2008 (E)

Las aplicaciones posibles incluyen la posibilidad de realizar consultas de carácter confidencial a las bases de datos públicas,responder a encuestas electrónicas, o hacer pagos o donaciones anónimas.

Ejemplos de los usuarios hostiles potenciales o temas son los proveedores, operadores de sistemas, socios de comunicación yusuarios, que contrabandean partes maliciosos (por ejemplo, caballos de Troya) en los sistemas. Todos estos usuarios pueden investigarlos patrones de uso (por ejemplo, que los usuarios utilizan los servicios de los cuales) y el mal uso de esta información.

I.1.2 FPR_ANO.1 Anonimato

I.1.2.1 Notas de la aplicación de usuario

Este componente se asegura de que la identidad de un usuario está protegido de la divulgación. Puede haber casos,sin embargo, que un usuario autorizado dado puede determinar quién lleva a cabo ciertas acciones. Este componente dala flexibilidad necesaria para capturar ya sea una política de privacidad limitada o total.

I.1.2.2 Operaciones

I.1.2.2.1 Asignación

En FPR_ANO.1.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_ANO.1.1, t él PP / ST autor debe identificar la lista de temas y / u operaciones y / u objetos dondeel nombre de usuario real del sujeto debe ser protegido, por ejemplo, "la solicitud de votación".

I.1.3 FPR_ANO.2 anonimato sin solicitar información


Este componente se utiliza para asegurar que el TSF no se le permite conocer la identidad del usuario.

I.1.3.2 Operaciones


En FPR_ANO.2.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_ANO.2.1, t él PP / ST autor debe identificar la lista de temas y / u operaciones y / u objetos dondeel nombre de usuario real del sujeto debe ser protegido, por ejemplo, "la solicitud de votación".

En FPR_ANO.2.2, t él PP / ST autor debe identificar la lista de servicios que están sujetos al anonimatorequisito, por ejemplo, "la que accede de descripciones de puestos".

12/6/2014 ISO / IEC 15408-2



En FPR_ANO.2.2, t él PP / ST autor debe identificar la lista de temas entre los cuales el nombre de usuario real deltema debe ser protegida cuando se prestan los servicios especificados.

Página 202

ISO / IEC 15408-2:2008 (E)

I.2 seudónimos (FPR_PSE)


Seudonimia asegura que un usuario puede utilizar un recurso o servicio, sin revelar su identidad, pero todavía puede serresponsable de dicho uso. El usuario puede ser responsable por directamente por estar relacionados con una referencia (alias) en poder dela TSF, o proporcionando un alias que se utilizará para fines de procesamiento, tales como un número de cuenta.

En varios aspectos, se asemeja seudonimia anonimato. Tanto seudónimos y el anonimato protegen laidentidad del usuario, pero en seudonimia se mantiene una referencia a la identidad del usuario para la rendición de cuentas ootros fines.

El componente F PR_PSE.1 seudonimia no no especifica los requisitos sobre la referencia para el usuario deidentidad. Con el fin de especificar los requisitos en esta referencia se presentan dos conjuntos de requisitos:FPR_PSE.2 seudonimia reversible y FPR_PSE.3 Alias seudónimos.

Una manera de utilizar la referencia es por ser capaz de obtener la identidad de usuario original. Por ejemplo, en un efectivo digitalmedio ambiente que sería ventajoso ser capaz de rastrear la identidad del usuario cuando un cheque se ha emitidovarias veces (es decir, el fraude). En general, la identidad del usuario necesita ser recuperado en condiciones específicas. LaPP / ST autor podría querer incorporar FPR_PSE.2 seudonimia Reversible para describir esos servicios.

Otro uso de la referencia es como un alias para un usuario. Por ejemplo, un usuario que no desea estaridentificado, puede proporcionar una cuenta a la que la utilización de los recursos se debe cargar. En tales casos, lareferencia a la identidad de usuario es un alias para el usuario, donde los demás usuarios o sujetos pueden utilizar el alias deel desempeño de sus funciones sin tener que obtener la identidad del usuario (por ejemplo, las operaciones estadísticas sobre el uso dedel sistema). En este caso, el autor PP / ST podría desear Incorporat e FPR_PSE.3 Alias seudónimos paraprecisar las normas a las que la referencia debe ajustarse.

El uso de estas construcciones anteriormente, el dinero digital se puede crear usin g FPR_PSE.2 seudonimia Reversibleespecificando que la identidad de usuario estará protegido y, de ser así se especifica en la condición, de que haya unarequisito de rastrear la identidad del usuario, si el dinero digital se pasó dos veces. Cuando el usuario es honesto, el usuarioidentidad está protegida; si el usuario intenta hacer trampas, la identidad del usuario se puede remontar.

Un tipo diferente de sistema podría ser una tarjeta de crédito digital, donde el usuario proporcionará un seudónimo queindica una cuenta de la que el dinero se puede restar. En tales casos, por ejemplo, FPR_PSE.3 Aliasseudonimia co uld ser utilizado. Este componente especificar que la identidad de usuario será protegida y,además, que el mismo usuario se consigue solamente valores para los que él / ella ha proporcionado el dinero asignado (en caso afirmativoespecificado en las condiciones).

Debe tenerse en cuenta que los componentes más estrictas potencialmente no se pueden combinar con otrorequisitos, tales como la identificación y la autenticación o la auditoría. La interpretación de "determinar la identidad"debe ser tomada en el sentido más amplio de la palabra. La información no es proporcionada por el TSF durante eloperación, ni puede la entidad determinar el objeto o el propietario del sujeto que invoca la operación, niserá la información del registro TSF, a disposición de los usuarios o sujetos, que podría liberar la identidad del usuario en elfuturo.

La intención es que el TSF no revela ninguna información que pueda comprometer la identidad del usuario, por ejemplo, lala identidad de los sujetos que actúan en nombre del usuario. La información que se considera que es sensible dependeel esfuerzo un atacante es capaz de gastar.

Las aplicaciones posibles incluyen la posibilidad de cobrar una llamada para los servicios telefónicos de tarificación adicional sinrevelar su identidad, o para ser cobrado por el uso anónimo de un sistema de pago electrónico.

Ejemplos de posibles usuarios hostiles son los proveedores, operadores de sistemas, socios de comunicación y los usuarios, quecontrabandear partes maliciosos (por ejemplo, caballos de Troya) en los sistemas. Todos estos atacantes pueden investigar qué usuariosque utiliza los servicios y el uso indebido de esta información. Adicionalmente a los servicios de anonimato, Servicios seudonimiacontiene métodos de autorización sin identificación, sobre todo para el pago anónimo ("Cash Digital").Esto ayuda a los proveedores para obtener el pago de una manera segura mientras se mantiene el anonimato del cliente.

12/6/2014 ISO / IEC 15408-2



Página 203

ISO / IEC 15408-2:2008 (E)


I.2.2 FPR_PSE.1 seudonimia


Este componente proporciona la protección del usuario contra la divulgación de la identidad de otros usuarios. El usuario permaneceráresponsable de sus acciones.

I.2.2.2 Operaciones


En FPR_PSE.1.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_PSE.1.1, t él PP / ST autor debe identificar la lista de temas y / u operaciones y / u objetos dondeel nombre de usuario real del sujeto debe ser protegido, por ejemplo, "la que accede de ofertas de empleo". Tenga en cuenta que"Objetos" incluye cualquier otro atributo que podrían permitir que otro usuario o sujetos a derivar la identidad real deel usuario.

En FPR_PSE.1.2, el autor PP / ST debe identificar el número (uno o más) de los alias de la TSF es capaz deproporcionar.

En FPR_PSE.1.2, t él PP / ST autor debe identificar la lista de temas a los que el TSF es capaz de proporcionar unaalias.

I.2.2.2.2 Selección

En FPR_PSE.1.3, t él PP / ST autor deberá especificar si el alias de usuario es generado por el TSF, o suministrapor el usuario. Sólo una de estas opciones se puede elegir.


En FPR_PSE.1.3, el autor PP / ST debe identificar la métrica a la que el TSF genera-o generado por el usuarioalias deben ajustarse.

I.2.3 FPR_PSE.2 seudonimia Reversible


En este componente, la TSF debe garantizar que, en condiciones especiales siempre la identidad del usuario en relación con unade referencia puede ser determinada.

En FPR_PSE.1 seudonimia la TSF debe proporcionar un alias en lugar de la identidad del usuario. Cuando el especificadocondiciones se satisfacen, la identidad de usuario a la que pertenecen los alias se puede determinar. Un ejemplo de talcondición en un entorno de dinero electrónico es: "El TSF debe proporcionar al notario una capacidad para determinar laidentidad de usuario basada en los alias proporcionados sólo en las condiciones que un cheque se ha emitido en dos ocasiones. ".

I.2.3.2 Operaciones


En FPR_PSE.2.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

Página 204

ISO / IEC 15408-2:2008 (E)

En FPR_PSE.2.1, t él PP / ST autor debe identificar la lista de temas y / u operaciones y / u objetos donde

12/6/2014 ISO / IEC 15408-2



el nombre de usuario real del sujeto debe ser protegido, por ejemplo, "la que accede de ofertas de empleo". Tenga en cuenta que"Objetos" incluye cualquier otro atributo que podrían permitir que otro usuario o sujetos a derivar la identidad real deel usuario.

En FPR_PSE.2.2, el autor PP / ST debe identificar el número (uno o más) de los alias de la TSF, es capaz deproporcionar.



En FPR_PSE.2.3, t él PP / ST autor deberá especificar si el alias de usuario es generado por la TSF o suministrapor el usuario. Sólo una de estas opciones se puede elegir.




En FPR_PSE.2.4, el autor PP / ST debe seleccionar si el usuario autorizado y / o temas de confianza puededeterminar el nombre de usuario real.


En FPR_PSE.2.4, t él PP / ST autor debe identificar la lista de condiciones bajo las cuales los sujetos y de confianzausuario autorizado puede determinar el nombre de usuario real en base a la referencia proporcionada. Estas condiciones pueden sercondiciones tales como la hora del día, o pueden ser de carácter administrativo, como en una orden judicial.

En FPR_PSE.2.4, t él PP / ST autor debe identificar la lista de temas de confianza que pueden obtener el usuario realnombre bajo una condición específica, por ejemplo, un usuario autorizado notario o especial.

I.2.4 FPR_PSE.3 Alias seudonimia


En este componente, la TSF debe garantizar que la referencia proporcionada cumple con ciertas normas de construcción, ypor lo tanto puede ser utilizado de una manera segura por los sujetos potencialmente inseguras.

Si un usuario desea utilizar los recursos de disco sin revelar su identidad, se puede utilizar seudónimos. Sin embargo,cada vez que el usuario accede al sistema, se debe usar el mismo alias. Tales condiciones se pueden especificar en laeste componente.

I.2.4.2 Operaciones


En FPR_PSE.3.1, el autor PP / ST deberá especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_PSE.3.1, t él PP / ST autor debe identificar la lista de temas y / u operaciones y / u objetos dondeel nombre de usuario real del sujeto debe ser protegido, por ejemplo, "la que accede de ofertas de empleo". Tenga en cuenta que

Página 205

ISO / IEC 15408-2:2008 (E)

"Objetos" incluye cualquier otro atributo que podrían permitir que otro usuario o sujetos a derivar la identidad realdel usuario.

En FPR_PSE.3.2, el autor PP / ST debe identificar el número (uno o más) de los alias de la TSF es capaz deproporcionar.



En FPR_PSE.3.3, t él PP / ST autor deberá especificar si el alias de usuario es generado por el TSF, o suministrapor el usuario. Sólo una de estas opciones se puede elegir.

12/6/2014 ISO / IEC 15408-2





En FPR_PSE.3.4, t él PP / ST autor debe identificar la lista de condiciones que indican cuando la referencia utilizadapara el nombre de usuario real será idéntico y cuando éste será diferente, por ejemplo, "cuando el usuario inicia sesión ael mismo host "se utilizará un alias único.

I.3 imposibilidad de vinculación (FPR_UNL)


Imposibilidad de vinculación garantiza que un usuario puede hacer múltiples usos de los recursos o servicios sin que los demás la posibilidad devincular estos usos juntos. Imposibilidad de vinculación se diferencia de seudónimos que, aunque en seudonimia el usuario esTambién se desconocen, las relaciones entre las diferentes acciones pueden ser proporcionados.

Los requisitos para la imposibilidad de vinculación tienen por objeto proteger la identidad de los usuarios en contra del uso del perfil de laoperaciones. Por ejemplo, cuando una tarjeta inteligente de teléfono se emplea con un número único, el teléfonoempresa puede determinar el comportamiento del usuario de esta tarjeta telefónica. Cuando un perfil de teléfono de lalos usuarios se conoce, la tarjeta puede ser vinculada a un usuario específico. Cómo ocultar la relación entre las distintas invocacionesde un servicio o el acceso de un recurso evitará este tipo de recopilación de información.

Como resultado, un requisito para la imposibilidad de vinculación podría implicar que el sujeto y el usuario la identidad de un mosto de operaciónser protegidos. De lo contrario, esta información podría ser utilizada para vincular las operaciones en conjunto.

Imposibilidad de vinculación requiere que las diferentes operaciones que no se pueden relacionar. Esta relación puede tomar varias formas. Paraejemplo, el usuario asociado a la operación, o el terminal que inició la actuación, o el tiempo de lase ejecutó la acción. El autor PP / ST puede especificar qué tipo de relaciones están presentes que deben sercontrarrestado.

Las aplicaciones posibles incluyen la capacidad de hacer uso múltiple de un seudónimo sin crear un patrón de usoque podrían revelar la identidad del usuario.

Ejemplos de temas hostiles y usuarios potenciales son los proveedores, operadores de sistemas, socios de comunicacióny usuarios, que contrabandean partes maliciosos, (por ejemplo, caballos de Troya) en los sistemas, no funcionan pero quierenobtener información sobre. Todos estos atacantes pueden investigar (por ejemplo, que los usuarios que utiliza los servicios) yun mal uso de esta información. Imposibilidad de vinculación a sus usuarios de los vínculos, los cuales podrían extraerse entre variosacciones de un cliente. Un ejemplo es una serie de llamadas telefónicas hechas por un cliente anónimo para diferentessocios, en los que la combinación de las identidades de la pareja pudiera revelar la identidad del cliente.

Página 206

ISO / IEC 15408-2:2008 (E)

I.3.2 FPR_UNL.1 imposibilidad de vinculación


Este componente garantiza que los usuarios no pueden conectarse diferentes operaciones en el sistema y obtener de esa formainformación.

I.3.2.2 Operaciones


En FPR_UNL.1.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_UNL.1.1, t él PP / ST autor debe identificar la lista de las operaciones que deben estar sometidos a larequisito imposibilidad de vinculación, por ejemplo, "el envío de correo electrónico."


En FPR_UNL.1.1, el autor PP / ST debe seleccionar las relaciones que deben quedar ocultas. La selecciónpermite ya sea la identidad del usuario o una cesión de las relaciones que se especifiquen.

12/6/2014 ISO / IEC 15408-2




En FPR_UNL.1.1, t él PP / ST autor debe identificar la lista de las relaciones que deben ser protegidas contra, porejemplo, "proceder de la misma terminal".

I.4 inobservabilidad (FPR_UNO)


Inobservabilidad garantiza que un usuario puede utilizar un recurso o servicio sin otros, especialmente tercera partes,pudiendo observar que se está utilizando el recurso o servicio.

Imposibilidad de observación acerca de la identidad del usuario desde una dirección diferente a la familias anteriores anonimato,Seudónimos y imposibilidad de vinculación. En este caso, la intención es la de ocultar el uso de un recurso o servicio, en lugar depara ocultar la identidad del usuario.

Un número de técnicas se pueden aplicar a implementar imposibilidad de observación. Ejemplos de técnicas para proporcionarimposibilidad de observación son:

a) Asignación de la información que afectan inobservabilidad: inobservabilidad información relevante (por ejemplo, informaciónque describe que se ha producido una operación) se puede asignar en varios lugares dentro del TOE. Lala información puede ser asignado a una sola parte elegido al azar de la TOE tal que un atacante haceNo sé qué parte del TOE debe ser atacado. Un sistema alternativo podría distribuir la informaciónde tal manera que ninguna de sus partes del TOE tiene información suficiente para que, si eludido, la privacidad del usuariopueda estar en peligro. Esta técnica se aborda explícitamente en FPR_UNO.2 Asignación de informaciónimpactando inobservabilidad.

b) Difusión: Cuando la información se transmite (por ejemplo, Ethernet, radio), los usuarios no pueden determinar quién realmenterecibido y utilizado esa información. Esta técnica es especialmente útil cuando la información debe alcanzarreceptores que tienen que temer un estigma por estar interesados en esa información (por ejemplo, médicos sensiblesinformación).

Página 207

ISO / IEC 15408-2:2008 (E)

c) la protección de cifrado y el mensaje padding: Gente observando un flujo de mensajes pueden obtenerinformación del hecho de que se transfiere un mensaje y de atributos en el mensaje. Por tráficorelleno, el relleno y el mensaje cifrado de la secuencia de mensaje, la transmisión de un mensaje y suatributos pueden ser protegidos.

A veces, los usuarios no deben ver el uso de un recurso, pero un usuario autorizado debe permitir ver elel uso de los recursos con el fin de ejercer sus funciones. En tales casos, t él FPR_UNO.4 usuario autorizadoobservabilidad se podría utilizar, que proporciona la capacidad para uno o más usuarios autorizados para ver el uso.

Esta familia hace uso de las "partes del TOE" concepto. Esto se considera cualquier parte del dedo del pie que es ya seafísica o lógicamente separada de otras partes del TOE.

Imposibilidad de observación de las comunicaciones puede ser un factor importante en muchas áreas, tales como la aplicación dederechos constitucionales, políticas de organización, o en aplicaciones relacionadas con la defensa.

I.4.2 FPR_UNO.1 inobservabilidad


Este componente requiere que el uso de una función o recurso no puede ser observada por los usuarios no autorizados.

I.4.2.2 Operaciones


En FPR_UNO.1.1, t él PP / ST autor debe especificar la lista de usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_UNO.1.1, el autor PP / ST debe identificar la lista de operaciones que se somete a larequisito inobservabilidad. Otros usuarios / sujetos entonces no será capaz de observar las operaciones en una cubiertaobjeto de la lista especificada (por ejemplo, la lectura y la escritura para el objeto).

En FPR_UNO.1.1, th e PP / ST autor debe identificar la lista de objetos que están cubiertos por la imposibilidad de observación

12/6/2014 ISO / IEC 15408-2



requisito. Un ejemplo podría ser un servidor de correo o sitio ftp.En FPR_UNO.1.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o materias protegidas cuyainformación inobservabilidad será protegida. Un ejemplo podría ser: "los usuarios acceder al sistema a través de laInternet ".

I.4.3 FPR_UNO.2 Asignación de información impactando inobservabilidad


Este componente requiere que el uso de una función o recurso no puede ser observada por los usuarios especificados osujetos. Además, este componente se especifica que la información relacionada con la privacidad del usuario se distribuyedentro del TOE de forma que los atacantes podrían no saber qué parte de la TOE para apuntar, o necesitar atacarvarias partes del TOE.

Un ejemplo del uso de este componente es el uso de un nodo asignado al azar para proporcionar una función. Ental caso, el componente podría exigir que la privacidad de la información se refiere únicamente estará disponible para unaidentificado parte del TOE, y no serán comunicados fuera de esta parte del TOE.

Un ejemplo más complejo se puede encontrar en algunos "algoritmos de votación". Varias partes de la TOE participaránen el servicio, pero ninguna parte individual del TOE podrá violar la política. Así, una persona puede emitir un voto(O no) sin el TOE ser capaz de determinar si un voto ha sido emitido y lo que pasó con el votoser (a menos que el voto fue unánime).

Página 208

ISO / IEC 15408-2:2008 (E)

I.4.3.2 Operaciones


En FPR_UNO.2.1, t él PP / ST autor debe especificar la lista de usuarios y / o temas contra los que el TSFdebe proporcionar protección. Por ejemplo, incluso si el autor PP / ST especifica un único usuario o rol sujeto, la TSFno sólo debe proporcionar protección frente a cada usuario individual o sujeto, sino que debe proteger con respecto ausuarios y / o temas de cooperación. Un conjunto de usuarios, por ejemplo, podría ser un grupo de usuarios que pueden operarbajo el mismo papel o puede utilizar el mismo proceso (s).

En FPR_UNO.2.1, el autor PP / ST debe identificar la lista de operaciones que se somete a larequisito inobservabilidad. Otros usuarios / sujetos entonces no será capaz de observar las operaciones en una cubiertaobjeto de la lista especificada (por ejemplo, la lectura y la escritura para el objeto).

En FPR_UNO.2.1, th e PP / ST autor debe identificar la lista de objetos que están cubiertos por la imposibilidad de observaciónrequisito. Un ejemplo podría ser un servidor de correo o sitio ftp.

En FPR_UNO.2.1, el autor PP / ST debe especificar el conjunto de los usuarios y / o materias protegidas cuyainformación inobservabilidad será protegida. Un ejemplo podría ser: "los usuarios acceder al sistema a través de laInternet ".

En FPR_UNO.2.2, th e PP / ST autor debe identificar qué información relacionada con la privacidad debe ser distribuido en unde manera controlada. Ejemplos de esta información podrían ser: la dirección IP del asunto, la dirección IP del objeto, tiempo,claves de cifrado utilizadas.

En FPR_UNO.2.2, el autor PP / ST debería especificar las condiciones a las que la difusión de lainformación debe adherirse. Estas condiciones deberán mantenerse a lo largo de la vida útil de la privacidadinformación relacionada de cada instancia. Ejemplos de estas condiciones podrían ser: "la información sólo serápresente en una sola parte separada de la TOE y no será comunicada fuera de esta parte del TOE. ","La información sólo deberá residir en una sola parte separada de la TOE, pero se trasladó a otra parte delTOE periódicamente "," la información se distribuirá entre las diferentes partes del TOE tal quecompromiso de las 5 partes separadas del TOE no pondrá en peligro la política de seguridad ".

I.4.4 FPR_UNO.3 inobservabilidad sin solicitar información


Este componente se utiliza para exigir que la TSF no trata de obtener información que pudiera comprometerimposibilidad de observación cuando se proporcionan servicios específicos. Por tanto, la TSF no solicitará (es decir, tratar de obtener de otraentidades) cualquier información que pudiera ser utilizada para comprometer inobservabilidad.

I.4.4.2 Operaciones


En FPR_UNO.3.1, th e PP / ST autor debe identificar la lista de servicios que están sujetos a la imposibilidad de observaciónrequisito, por ejemplo, "la que accede de descripciones de puestos".

12/6/2014 ISO / IEC 15408-2



En FPR_UNO.3.1, t él PP / ST autor debe identificar la lista de temas que puede facilitar información relacionada con la privacidaddeben ser protegidas cuando se prestan los servicios especificados.

En FPR_UNO.3.1, t él PP / ST autor debe especificar la información relacionada con la privacidad que será protegidalas materias especificadas. Los ejemplos incluyen la identidad del sujeto que utiliza un servicio y la cantidad de unservicio que ha sido utilizado como la utilización de recursos de memoria.

Página 209

ISO / IEC 15408-2:2008 (E)

I.4.5 FPR_UNO.4 Autorizado usuario observabilidad


Este componente se utiliza para requerir que habrá uno o más usuarios autorizados con los derechos para ver ella utilización de recursos. Sin este componente, se permite esta revisión, pero no obligatoria.

I.4.5.2 Operaciones


En FPR_UNO.4.1, t él PP / ST autor debe especificar el conjunto de usuarios autorizados para el que el TSF debe proporcionarla capacidad de observar la utilización de los recursos. Un conjunto de usuarios autorizados, por ejemplo, podría ser un grupo deusuarios que pueden operar bajo el mismo papel o puede utilizar el mismo proceso (s) autorizada.

En FPR_UNO.4.1, t él PP / ST autor debe especificar el conjunto de recursos y / o servicios que la autoricenusuario debe ser capaz de observar.

12/6/2014 ISO / IEC 15408-2



Página 210

ISO / IEC 15408-2:2008 (E)


Anexo J

(Normativo)

Clase FPT: Protección del TSF

Esta clase contiene familias de requisitos funcionales que se relacionan con la integridad y la gestión de lamecanismos que constituyen el TSF y para la integridad de los datos TSF. En cierto sentido, las familias de esta clase puedeparecen duplicar componentes en el FDP: protección de datos de usuario de clase; incluso pueden ser implementados utilizandolos mismos mecanismos. Sin embargo, FDP : protección de los datos del usuario fo centra en la protección de datos de usuario, mientras FPT:Protección del TSF se centra en la protección de los datos TSF. De hecho, los componentes de la FPT: Protección de laTSF clase son necesarios para proporcionar los requisitos que los programas de alimentación complementaria en el TOE no pueden ser manipulados oanulada.

Desde el punto de vista de esta clase, con respecto a la TSF hay tres elementos importantes:

a) la aplicación del TSF, que ejecuta e implementa los mecanismos que hacen cumplir la SFR.

b) Los datos de la TSF, que son las bases de datos administrativas que rigen la aplicación de la SFR.

c) Las entidades externas que el TSF puede interactuar con el fin de hacer cumplir la SFR.

Todas las familias de la FPT: Protección del TSF clase puede estar relacionada con estas áreas, y caer en lasiguientes agrupaciones:

a) T protección física SF (FPT_PHP), WH ich proporciona un usuario autorizado con la capacidad de detectar externaataques a las partes del TOE que componen el TSF.

b) T sante de entidades externas (FPT_TEE) y auto prueba TSF (FPT_TST), que proporcionan un usuario autorizadocon la capacidad de verificar el correcto funcionamiento de las entidades externas que interactúan con el TSF para hacer cumplir laSFR y la integridad de los datos de la TSF y la propia TSF.

c) T recuperación oxidado (FPT_RCV), M ail segura (FPT_FLS) y TSF TOE coherencia de replicación de datos interna(FPT_TRC), w hich abordar el comportamiento de la TSF, cuando se produzca el fallo e inmediatamente después.

d) Av. dimensiones pueden ser de los datos TSF exportados (FPT_ITA), C ONFIDENCIALIDAD de los datos TSF exportados (FPT_ITC), Integridad deexportados los datos TSF (FPT_ITI), que se ocupan de la protección y disponibilidad de los datos entre el TSF TSFy otro producto de TI de confianza.

e) I nternal TOE TSF transferencia de datos (FPT_ITT), que se ocupa de la protección de los datos TSF cuando se transmiteentre partes físicamente separados del TOE.

f) Detección Replay (FPT_RPL), que se ocupa de la reproducción de diversos tipos de información y / ooperaciones.

g) S protocolo sincronía tate (FPT_SSP), que se ocupa de la sincronización de los estados, en base a TSFde datos, entre diferentes partes de un TSF distribuido.

h) T iempo (sellos FPT_STM), qu direcciones ich sincronización fiable.

i) Inter-TSF TSF consistencia de los datos (FPT_TDC), que se ocupa de la coherencia de los datos TSF compartidosentre la TSF y otro producto de TI de confianza.

Página 211

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



Figura J.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura J.1 - FPT: Protección de la clase de descomposición TSF

Página 212

ISO / IEC 15408-2:2008 (E)

J.1 falla segura (FPT_FLS)

J.1.1 notas de usuario

Los requisitos de esta familia aseguran que el TOE siempre hará cumplir sus SFR en el caso de ciertos tiposde fallos en la TSF.

Si no J.1.2 FPT_FLS.1 con preservación de las condiciones de seguridad

J.1.2.1 Notas de la aplicación de usuario

12/6/2014 ISO / IEC 15408-2



El término "estado seguro" se refiere a un estado en el que los datos son consistentes y TSF TSF continúa correctaejecución de la SFR.

Aunque es deseable para auditar situaciones en las que se produce un fallo con la preservación del estado seguro, no esposible en todas las situaciones. El autor PP / ST deberá especificar aquellas situaciones en las que se desea la auditoría yfactible.

Las fallas en la TSF pueden incluir fallas "duras", que indican un mal funcionamiento del equipo y que tenga larequiere mantenimiento, servicio o reparación de la TSF. Las fallas en la TSF también pueden incluir recuperable "suave"fracasos, que sólo pueden requerir la inicialización o reposición del TSF.

J.1.2.2 Operaciones

J.1.2.2.1 Asignación

En FPT_FLS.1.1, t él PP / ST autor se deben enumerar los tipos de fallos en la TSF para los que el TSF debe "fallarasegurar ", es decir, debe conservar un estado seguro y continuará aplicando correctamente el SFR.

J.2 disponibilidad de los datos TSF exportados (FPT_ITA)


Esta familia define las normas para la prevención de la pérdida de la disponibilidad de datos de TSF se mueve entre la TSF yotro producto de TI de confianza. Estos datos podrían ser TSF datos críticos tales como contraseñas, claves, datos de auditoría, o TSFcódigo ejecutable.

Esta familia se utiliza en un contexto distribuido donde la TSF está proporcionando datos de TSF a otro producto de TI de confianza.La TSF sólo puede tomar las medidas a su sitio y no puede ser considerado responsable de la TSF en el otro de confianzaProductos de TI.

Si hay diferentes métricas de disponibilidad para los diferentes tipos de datos de TSF, a continuación, este componente debe ser reiteradopara cada combinación única de las métricas y tipos de datos de la TSF.

J.2.2 FPT_ITA.1 Inter-TSF disponibilidad dentro de una métrica definida disponibilidad

J.2.2.1 Operaciones


En FPT_ITA.1.1, el autor PP / ST debe especificar los tipos de datos de TSF que están sujetos a la disponibilidadmétrica.

En FPT_ITA.1.1, PP / ST debe especificar la métrica de la disponibilidad de los datos TSF aplicables.

En FPT_ITA.1.1, el autor PP / ST debería especificar las condiciones en las que la disponibilidad debe estar garantizada. Paraejemplo: tiene que haber una conexión entre la punta y el otro producto de TI de confianza.

Página 213

ISO / IEC 15408-2:2008 (E)

J.3 Confidencialidad de los datos TSF exportados (FPT_ITC)


Esta familia define las normas para la protección contra la divulgación no autorizada de datos TSF se mueve entre elTSF y otro producto de TI de confianza. Ejemplos de estos datos son TSF datos críticos tales como contraseñas, claves,datos de auditoría, o TSF código ejecutable.

Esta familia se utiliza en un contexto distribuido donde la TSF está proporcionando datos de TSF a otro producto de TI de confianza.El TSF sólo puede tomar las medidas a su sitio y no puede ser considerado responsable de la conducta de la otraproductos de TI de confianza.

Confidencialidad J.3.2 FPT_ITC.1 Inter-TSF durante su transmisión

J.3.2.1 Notas del Evaluador

Confidencialidad de los datos TSF durante su transmisión es necesaria para proteger dicha información deba ser revelada.Algunas de las posibles implementaciones que podrían proporcionar confidencialidad incluyen el uso de algoritmos criptográficosasí como las técnicas de espectro ensanchado.

J.4 Integridad de los datos TSF exportados (FPT_ITI)

12/6/2014 ISO / IEC 15408-2




Esta familia define las normas para la protección, la modificación no autorizada de los datos de la TSF durantetransmisión entre la TSF y otro producto de TI de confianza. Ejemplos de estos datos son los datos críticos TSFtales como contraseñas, claves, datos de auditoría, o TSF código ejecutable.

Esta familia se utiliza en un contexto distribuido donde la TSF está intercambiando datos TSF con otra confianza TIproducto. Tenga en cuenta que el requisito de que se ocupa de la modificación, la detección, o la recuperación en otro de confianza de TIproducto no se puede especificar, como los mecanismos que otro producto de TI de confianza utilizará para proteger sus datosno puede ser determinado de antemano. Por esta razón, estos requisitos se expresan en términos de la "TSFproporcionando una capacidad "que otro producto de TI de confianza puede utilizar.

Detección J.4.2 FPT_ITI.1 Inter-TSF de la modificación


Este componente debe utilizarse en situaciones en las que es suficiente para detectar cuando se han modificado los datos. Unejemplo de tal situación es una en la que otro producto de TI de confianza puede solicitar TSF del dedo del pie seretransmitir datos cuando la modificación se ha detectado, o responder a ese tipo de petición.

La resistencia deseada de la detección de la modificación se basa en una métrica modificación especificada que es una funcióndel algoritmo utilizado, que puede variar de una suma de comprobación de paridad y la debilidad de los mecanismos que pueden fallar en la detecciónmúltiples cambios de bits, a enfoques más complejos de suma de comprobación criptográfica.

J.4.2.2 Operaciones


En FPT_ITI.1.1, PP / ST debe especificar la métrica modificación de que el mecanismo de detección debe satisfacer.Esta métrica modificación especificará la fuerza deseada de la detección de la modificación.

En FPT_ITI.1.2, PP / ST debe especificar las acciones a tomar en caso de una modificación de los datos de la TSF ha sidodetectado. Un ejemplo de una acción es: "ignorar los datos de TSF, y solicitar el producto originario de confianza para enviarlos datos TSF otra vez. "

Página 214

ISO / IEC 15408-2:2008 (E)

La detección y corrección de la modificación J.4.3 FPT_ITI.2 Inter-TSF


Este componente debe utilizarse en situaciones en las que es necesario detectar o corregir modificaciones de TSFdatos críticos.

La resistencia deseada de la detección de la modificación se basa en una métrica modificación especificada que es una funcióndel algoritmo utilizado, que puede variar de una suma de comprobación de paridad y los mecanismos que pueden fallar en la detecciónmúltiples cambios de bits, a enfoques más complejos de suma de comprobación criptográfica. La métrica que necesita estardefinida puede referirse a los ataques que se resisten (por ejemplo, sólo 1 de cada 1000 mensajes aleatorios serán aceptadas),o a los mecanismos que son bien conocidos en la literatura pública (por ejemplo, la fuerza debe ser conformes a laresistencia ofrecida por Secure Hash Algorithm).

El enfoque adoptado para la modificación correcta podría hacerse a través de alguna forma de corrección de errores de suma de comprobación.


Algunos medios posibles de satisfacer este requisito implica el uso de funciones criptográficas o alguna formade la suma de comprobación.

J.4.3.3 Operaciones


En FPT_ITI.2.1, PP / ST debe especificar la métrica modificación de que el mecanismo de detección debe satisfacer.Esta métrica modificación especificará la fuerza deseada de la detección de la modificación.

En FPT_ITI.2.2, PP / ST debe especificar las acciones a tomar en caso de una modificación de los datos de la TSF ha sidodetectado. Un ejemplo de una acción es: "ignorar los datos de TSF, y solicitar el producto originario de confianza para enviarlos datos TSF otra vez. "

En FPT_ITI.2.3 , el autor PP / ST debe definir los tipos de modificación de la que el TSF debe sercapaz de recuperar.

12/6/2014 ISO / IEC 15408-2



La transferencia de datos TSF TOE J.5 Interna (FPT_ITT)


Esta familia proporciona los requisitos que se ocupan de la protección de los datos TSF cuando se transfiere entre separadapartes de un TOE través de un canal interno.

La determinación del grado de separación (es decir, físico o lógico) que haría que la aplicación de estefamilia utilidad depende del entorno de uso previsto. En un ambiente hostil, puede haber riesgos derivadosde las transferencias entre partes del TOE separados por sólo un bus de sistema o de una red de comunicaciones entre procesoscanal. En ambientes más benignos, las transferencias pueden ser a través de los medios de comunicación más tradicionales de la red.

Notas J.5.2 Evaluador

Un mecanismo práctico a disposición de una TSF para proporcionar esta protección se basa criptográficamente.

Página 215

ISO / IEC 15408-2:2008 (E)

J.5.3 FPT_ITT.1 básico de protección de transferencia de datos TSF interna

J.5.3.1 Operaciones

J.5.3.1.1 Selección

En FPT_ITT.1.1, el autor PP / ST debe especificar el tipo de protección que se desea proporcionada desde elopciones: la divulgación, modificación.

J.5.4 FPT_ITT.2 TSF separación de transferencia de datos


Una de las maneras de lograr la separación de los datos TSF basado en atributos SFP-pertinentes es mediante el uso decanales lógicos o físicos separados.

J.5.4.2 Operaciones


En FPT_ITT.2.1, el autor PP / ST debe especificar el tipo de protección que se desea proporcionada desde elopciones: la divulgación, modificación.

J.5.5 FPT_ITT.3 TSF monitoreo de integridad de datos

J.5.5.1 Operaciones


En FPT_ITT.3.1, el autor PP / ST debe especificar el tipo deseado de la modificación que la TSF debe ser capaz dedetectar. El autor de PP / ST debe seleccionar de: modificación de los datos, la sustitución de datos, la reordenación de los datos,cancelación de sus datos, o cualquier otro error de integridad.


En FPT_ITT.3.1, si el autor de PP / ST elige la última selección observó en el párrafo anterior, entonces laautor también debería especificar cuáles son esos otros errores de integridad son que la TSF debe ser capaz de detectar.

En FPT_ITT.3.2, el autor PP / ST debe especificar la acción que debe realizarse cuando se detecta un error de integridad.

Protección física TSF J.6 (FPT_PHP)


TSF componentes de protección física se refieren a las restricciones de acceso físico no autorizado a la TSF, y para

12/6/2014 ISO / IEC 15408-2



la disuasión y la resistencia a, la modificación física no autorizado, o la sustitución de la TSF.

Los requisitos de esta familia aseguran que el TSF está protegido de la manipulación física y la interferencia.La satisfacción de los requerimientos de estos componentes da como resultado la TSF está envasados y utilizadas de talde manera que la manipulación física es detectable, o la resistencia a la manipulación indebida física es medible sobre la base defactores de trabajo definidos. Sin estos componentes, las funciones de protección de una TSF pierden su eficacia enentornos en los que no se puede prevenir el daño físico. Este componente también proporciona los requisitoscon respecto a cómo la TSF debe responder a los intentos de manipulación física.

Ejemplos de escenarios de manipulación física incluyen agresiones mecánicas, la radiación, el cambio de la temperatura.

Es aceptable que las funciones que están disponibles para un usuario autorizado para detectar la manipulación física de serdisponible sólo en modo fuera de línea o de mantenimiento. Los controles deben estar en su lugar de limitar el acceso durante dicho

Página 216

ISO / IEC 15408-2:2008 (E)

modos a los usuarios autorizados. A medida que el TSF puede no ser "operativa" en esos modos, puede que no sea capaz deprovisionalmente de la aplicación normal para el acceso del usuario autorizado. La implementación física de un dedo podría consistirde varias estructuras: por ejemplo, un blindaje exterior, tarjetas y chips. Este conjunto de "elementos" como toda una necesidadproteger (proteger a notificar y resistir) la TSF de la manipulación física. Esto no quiere decir que todos los dispositivos debenproporcionar estas características, pero el físico completo a construir en su conjunto debería.

Aunque sólo hay auditoría mínima asociar con estos componentes, esto es únicamente porque no es elpotencial de que los mecanismos de detección y alarma pueden ser implementadas completamente en el hardware, por debajo de lanivel de interacción con un subsistema de auditoría (por ejemplo, un sistema de detección basado en hardware basado enromper un circuito y encender un diodo emisor de luz (LED) si el circuito se rompe cuando se pulsa un botón porel usuario autorizado). Sin embargo, un autor de PP / ST podrá determinar, para una amenaza anticipada especialmedio ambiente, hay una necesidad de auditar la manipulación indebida física. Si este es el caso, el autor de PP / ST debe incluirrequisitos apropiados en la lista de eventos de auditoría. Tenga en cuenta que la inclusión de estos requisitos puede tenerimplicaciones en el diseño de hardware y su interfaz con el software.

La detección pasiva J.6.2 FPT_PHP.1 de ataque físico


Detección FPT_PHP.1 pasiva de ataque físico se debe utilizar cuando las amenazas de origen físico no autorizadola manipulación de partes del TOE no se contrarrestan mediante métodos de procedimiento. Se ocupa de la amenaza defísica no detectado la manipulación de la TSF. Típicamente, un usuario autorizado se le daría la función averificar si la manipulación se llevó a cabo. Como está escrito, este componente sólo proporciona una capacidad de TSF para detectarmanipulación. Especificación de las funciones de gestión de i n Gestión FMT_MOF.1 de funciones de seguridadcomportamiento debe ser considerado para especificar quién puede hacer uso de esa capacidad, y cómo se puede hacer usode esa capacidad. Si esto se hace por mecanismos no-TI (por ejemplo, inspección física) las funciones de gestión sonno se requiere.

J.6.3 FPT_PHP.2 Notificación de ataque físico


FPT_PHP.2 Notificación de ataque físico se debe utilizar cuando las amenazas de sabotaje físico no autorizadocon partes del TOE no se ven contrarrestados por los métodos de procedimiento, y se requiere que las personas designadasser notificado de la manipulación física. Se ocupa de la amenaza de que la manipulación física con elementos de la TSF, aunquedetectada, no podrá ser notado. Especificación de las funciones de gestión en el manejo de la seguridad FMT_MOF.1funciones de comportamiento debe ser considerado para especificar quién puede hacer uso de esa capacidad, y cómo puedenhacer uso de esa capacidad.

J.6.3.2 Operaciones


En FPT_PHP.2.3, t él PP / ST autor debe proporcionar una lista de dispositivos / TSF elementos para los que la detección activa dese requiere la manipulación indebida física.

En FPT_PHP.2.3, el autor PP / ST debe designar a un usuario o rol que debe ser notificado cuando la manipulación sedetectado. El tipo de usuario o función puede variar dependiendo del componente de administración de seguridad en particular(A partir de la Gestión de las funciones de seguridad FMT_MOF.1 comportamiento fa milia) incluido en el PP / ST.

J.6.4 FPT_PHP.3 Resistencia a la agresión física


Para algunas formas de manipulación, es necesario que el TSF no sólo detecta la manipulación, pero en realidad resisteo retrasa el atacante.

12/6/2014 ISO / IEC 15408-2



Página 217

ISO / IEC 15408-2:2008 (E)


Este componente se debe utilizar cuando se espera que los dispositivos y elementos de TSF TSF para operar en unentorno en el que una manipulación física (por ejemplo, la observación, el análisis, o modificación) de la parte interna de una TSFdispositivo o elemento de TSF en sí es una amenaza.

J.6.4.2 Operaciones


En FPT_PHP.3.1, el autor PP / ST debe especificar la manipulación escenarios a una lista de dispositivos / TSF elementos paraque la TSF debe resistir la manipulación física. Esta lista se puede aplicar a un subconjunto definido de la TSFdispositivos físicos y elementos basados en consideraciones tales como limitaciones de la tecnología y física relativala exposición del dispositivo. Tal subconjuntos debe estar claramente definida y justificada. Por otra parte, la TSF deberesponder automáticamente a la manipulación física. La respuesta automática debe ser tal que la política de ladispositivo se conserva; Por ejemplo, con una política de confidencialidad, sería aceptable para desactivar físicamente eldispositivo de modo que la información protegido no puede ser recuperada.

En FPT_PHP.3.1, el autor PP / ST debe especificar la lista de dispositivos / TSF elementos para los que el TSF deberíanresistir a la manipulación física de los escenarios que se han identificado.

Recuperación J.7 confianza (FPT_RCV)


Los requisitos de esta familia aseguran que el TSF puede determinar que se inició la TOE-sincompromiso de protección y puede recuperar sin la protección de compromiso después de la discontinuidad de las operaciones. Estela familia es importante porque el estado de puesta en marcha de la TSF determina la protección de los estados siguientes.

Componentes de recuperación de reconstruir los Estados seguros TSF, o prevenir transiciones a estados inseguros, como consecuencia directa derespuesta para los casos de fallos esperados, la discontinuidad de funcionamiento o puesta en marcha. Las fallas que deben sergeneralmente anticipado se encuentran los siguientes:

a) las fallas de acción Unmaskable que siempre dan lugar a una caída del sistema (por ejemplo, la inconsistencia persistente críticolas tablas del sistema, transferencias incontroladas dentro del código de TSF causados por fallos transitorios de hardware ofirmware, apagones, fallos de procesadores, fallos de comunicación).

b) las fallas de los medios haciendo que parte o todos los medios de comunicación que representan los objetos TSF a ser inaccesible ocorruptos (por ejemplo, errores de paridad, fallo del sistema principal del disco, fallos de lectura / escritura persistente causada por los jefes de discos desalineados,revestimiento magnético desgastado, el polvo en la superficie del disco).

c) La discontinuidad de funcionamiento causado por la acción administrativa errónea o falta de oportuna administrativaacción (por ejemplo, cierres inesperados apagando el poder, ignorando el agotamiento de los recursos críticos,inadecuada configuración instalada).

Tenga en cuenta que la recuperación puede ser de cualquiera de un escenario completo o parcial fracaso. Aunque lo haría un completo fracasose producen en un sistema operativo monolítico, es menos probable que ocurra en un entorno distribuido. En talesambientes, subsistemas pueden fallar, pero otras porciones seguir funcionando. Además, los componentes críticos puedenredundante (duplicación de discos, rutas alternativas), y los puestos de control pueden estar disponibles. Por lo tanto, la recuperación esexpresado en términos de recuperación a un estado seguro.

Hay diferentes interacciones betwe en la recuperación de confianza (FPT_RCV ) y autotest TSF (FPT_TST)componentes que deben considerarse al seleccionar la recuperación de confianza (FPT_RCV):

a) La necesidad de recuperación de confianza se puede indicar a través de los resultados de las pruebas automáticas TSF, donde los resultadosde las auto-pruebas indican que el TSF está en un estado de inseguridad y regresar a un estado seguro o de la entrada ense requiere el modo de mantenimiento.

b) Un fracaso, como se mencionó anteriormente, se puede identificar por un administrador. O bien el administrador puede realizarlas acciones para devolver el TOE a un estado seguro y luego invocar TSF auto-pruebas para confirmar que el seguroestado ha sido alcanzado. O bien, las pruebas automáticas de TSF puede ser invocada para completar el proceso de recuperación.

Página 218

ISO / IEC 15408-2:2008 (E)

12/6/2014 ISO / IEC 15408-2



c) Una combinación de un. y b. de arriba, donde la necesidad de recuperación de confianza se indica a través de los resultados deAutodiagnóstico TSF, el administrador realiza las acciones para devolver el TOE a un estado seguro y luegoinvoca TSF auto-pruebas para confirmar que el estado de seguridad se ha logrado.

d) las pruebas de auto detectar una discontinuidad fracaso / servicio, entonces la recuperación ya sea automatizado o entrada a unel modo de mantenimiento.

Esta familia identifica un modo de mantenimiento. En este modo de funcionamiento normal, el mantenimiento puede ser imposible oseveramente restringida, de lo contrario podrían producirse situaciones de inseguridad. Por lo general, sólo los usuarios autorizados deben serpermitido el acceso a este modo pero los detalles reales de los que pueden acceder a este modo es una función de FMT: de Seguridadgestión. I f FMT: Gestión de la seguridad no pone ningún tipo de control sobre quién puede acceder a este modo, entoncespuede ser aceptable para permitir a cualquier usuario a restaurar el sistema si el TOE entra en ese estado. Sin embargo, enpráctica, esto probablemente no es deseable, ya que el usuario restaurar el sistema tiene la oportunidad de configurar elTOE de una manera tal que viole los SFR.

Mecanismos diseñados para detectar condiciones excepcionales durante el otoño operación bajo la auto prueba de TSF (FPT_TST),Falla segura (FPT_FLS), un nd de otras áreas que abordan el concepto de "Seguridad Software." Es probable que el usode una de estas familias serán necesarios para apoyar la adopción o f recuperación de confianza (FPT_RCV). Esto es paraasegurarse de que el TOE será capaz de detectar cuando se requiere la recuperación.

A lo largo de esta familia, se utiliza la expresión "estado seguro". Esto se refiere a un estado en el que el TOE tienedatos TSF consistentes y una TSF que pueden cumplir correctamente la política. Este estado puede ser el "arranque" inicial de unsistema limpio, o podría ser algún estado checkpoints.

Después de la recuperación, puede ser necesario para confirmar que el estado seguro se ha logrado a través de auto-prueba de la TSF. Sin embargo, si la recuperación se lleva a cabo de tal manera que sólo un estado seguro puede serlogrado, de lo contrario la recuperación falla, entonces la dependencia a th e FPT_TST.1 TSF pruebas TSF componente de auto-testPuede argumentarse distancia.

J.7.2 FPT_RCV.1 Manual de recuperación


En la jerarquía de la familia de la recuperación, la recuperación de confianza que sólo requiere una intervención manual es el menosdeseable, ya que impide el uso del sistema de una forma desatendida.

Este componente está diseñado para utilizarse en dedos que no requieren recuperación desatendido a un estado seguro. Larequisitos de este componente reduce la amenaza de compromiso de protección resultante de una TOE asistidoregresar a un estado de inseguridad después de la recuperación de un fallo u otra discontinuidad.


Es aceptable que las funciones que están disponibles para un usuario autorizado para la recuperación de confianza que esté disponiblesolamente en un modo de mantenimiento. Los controles deben estar en su lugar de limitar el acceso durante el mantenimiento al personal autorizadolos usuarios.

J.7.2.3 Operaciones


En FPT_RCV.1.1, t él PP / ST autor debe especificar la lista de fallas o discontinuidades de servicios (por ejemplo, el poderfracaso, agotamiento de almacenamiento de auditoría, cualquier falla o discontinuidad) tras lo cual el TOE entrará en un mantenimientomodo.

Página 219

ISO / IEC 15408-2:2008 (E)

Recuperación J.7.3 FPT_RCV.2 Automatizado


Recuperación automatizada se considera que es más útil que la recuperación manual, ya que permite a la máquinaoperar en modo desatendido.

El componente FPT_RCV.2 Recuperación automatizada e xtends la cobertura característica del Manual FPT_RCV.1recuperación por exigir que no haya al menos un método automatizado de la recuperación de un fallo o de servicios

12/6/2014 ISO / IEC 15408-2



discontinuidad. Aborda la amenaza de comprometer la protección resultante de un TOE desatendida de regresar aun estado de inseguridad después de la recuperación de un fallo u otra discontinuidad.



Para FPT_RCV.2.1, es responsabilidad del desarrollador de la TSF para determinar el conjunto de recuperablefracasos y discontinuidades de servicios.

Se supone que la robustez de los mecanismos de recuperación automatizados será verificada.

J.7.3.3 Operaciones


En FPT_RCV.2.1, t él PP / ST autor debe especificar la lista de fallas o discontinuidades de servicios (por ejemplo, el poderfracaso, agotamiento de almacenamiento de auditoría) tras lo cual necesitará la TOE para introducir un modo de mantenimiento.

En FPT_RCV.2.2, el autor de PP / ST debe especificar la lista de fallos u otras discontinuidades para el cualrecuperación automática debe ser posible.

Recuperación J.7.4 FPT_RCV.3 automatizada y sin pérdida indebida


Recuperación automatizada se considera que es más útil que la recuperación manual, pero se corre el riesgo de perder unanúmero considerable de objetos. Cómo prevenir la pérdida excesiva de objetos ofrece una utilidad adicional a la recuperaciónesfuerzo.

El componente F recuperación PT_RCV.3 automatizada y sin pérdida indebida e xtends la cobertura de las características deRecuperación FPT_RCV.2 Automatizado por requiriendo que no haya pérdida indebida de los datos u objetos TSF bajo lacontrol de la TSF. En la recuperación FPT_RCV.2 Automatizado, los mecanismos de recuperación automatizados podríanrecuperar concebible mediante la supresión de todos los objetos y devolver el TSF a un estado seguro conocido. Este tipo de drásticarecuperación automática está impedido i n FPT_RCV.3 automatizado de recuperación sin pérdida indebida.

Este componente se refiere a la amenaza de compromiso de protección resultante de una TOE desatendida de regresar aun estado de inseguridad después de la recuperación de un fallo u otra discontinuidad con una gran pérdida de datos u objetos TSFbajo el control de la TSF.



, Se supone que los evaluadores verificarán la solidez de los mecanismos de recuperación automatizados.

Página 220

ISO / IEC 15408-2:2008 (E)

J.7.4.3 Operaciones


En FPT_RCV.3.1, t él PP / ST autor debe especificar la lista de fallas o discontinuidades de servicios (por ejemplo, el poderfracaso, agotamiento de almacenamiento de auditoría) tras lo cual necesitará la TOE para introducir un modo de mantenimiento.

En FPT_RCV.3.2, el autor de PP / ST debe especificar la lista de fallos u otras discontinuidades para el cualrecuperación automática debe ser posible.

En FPT_RCV.3.3, t él PP / ST autor debe proporcionar una cuantificación de la cantidad de pérdida de los datos de la TSF oobjetos que es aceptable.

Recuperación Función J.7.5 FPT_RCV.4


Recuperación de la función requiere que si debe haber algún fallo en la TSF, que ciertas funciones en el TSFo bien debe terminar con éxito o recuperar a un estado seguro.

12/6/2014 ISO / IEC 15408-2



J.7.5.2 Operaciones


En FPT_RCV.4.1, t él PP / ST autor debe especificar una lista de las funciones y situaciones de fallo. En el caso de quecualquiera de los escenarios de falla identificadas suceda, las funciones que se han especificado debe ya sea completaéxito o recuperar a un estado coherente y seguro.

J.8 Replay detección (FPT_RPL)


Esta familia se ocupa de la detección de la repetición de varios tipos de entidades y las acciones posteriores para corregir.

Detección J.8.2 FPT_RPL.1 Replay


Las entidades incluidas aquí son, por ejemplo, los mensajes, las solicitudes de servicio, las respuestas de servicio, o sesiones.

J.8.2.2 Operaciones


En FPT_RPL.1.1, t él PP / ST autor debe proporcionar una lista de las entidades identificadas para que la detección de la repeticióndebería ser posible. Ejemplos de este tipo de entidades pueden ser: mensajes, solicitudes de servicio, las respuestas de servicio,y las sesiones de usuario.

En FPT_RPL.1.2, el autor PP / ST debe especificar la lista de acciones a realizar por el TSF cuando la repetición esdetectado. El posible conjunto de acciones que se pueden tomar incluyen: haciendo caso omiso de la entidad jugado de nuevo, solicitandola confirmación de la entidad de la fuente identificada, y se concluye el sujeto del que re-interpretó elentidad se originó.

Página 221

ISO / IEC 15408-2:2008 (E)

Protocolo sincronía J.9 Estado (FPT_SSP)


TOE distribuidos pueden dar lugar a una mayor complejidad de las TOE monolíticos a través de la posibilidad dediferencias en el estado entre partes del TOE, y por medio de los retrasos en la comunicación. En la mayoría de los casos,sincronización de estado entre las funciones distribuidas implica un protocolo de intercambio, no una simple acción.Cuando existe malicia en el entorno distribuido de estos protocolos, los protocolos defensivas son más complejosrequerida.

Protocolo de sincronía Estado (FPT_SSP) es tablece la obligación para ciertas funciones críticas de la TSF parautilizar un protocolo de confianza. protocolo de sincronía Estado (FPT_SSP) asegura que dos partes distribuidas de la TOE(Por ejemplo, los ejércitos) han sincronizado sus estados después de una acción relevante para la seguridad.

Algunos estados no pueden sincronizarse, o el costo de transacción pueden ser demasiado altos para el uso práctico; cifradorevocación de clave es un ejemplo, donde conocer el estado después de que se inicie la acción de revocación no puede ser nuncaconocido. O bien la acción fue tomada y el reconocimiento no puede ser enviado o el mensaje fue ignorado porlos compañeros de comunicación hostiles y la revocación nunca ocurrieron. La indeterminación es exclusivo de distribuciónDedos del pie. La indeterminación y la sincronía estado están relacionados, y pueden aplicar la misma solución. Es inútil para diseñarpara los estados indeterminados; el autor PP / ST debe expresar otros requisitos en tales casos (por ejemplo, levantar unalarma, auditar el evento).

J.9.2 FPT_SSP.1 reconocimiento confianza simple


En este componente, las TSF debe proporcionar un acuse de recibo a otra parte de la TSF cuando se le solicite.Este reconocimiento debe indicar que una parte de un TOE distribuido recibido con éxito un sin modificarla transmisión de una parte diferente del TOE distribuida.

Reconocimiento mutuo de confianza J.9.3 FPT_SSP.2

12/6/2014 ISO / IEC 15408-2




En este componente, además de la TSF ser capaz de proporcionar un acuse de recibo para la recepción de un datotransmisión, la TSF debe cumplir con una petición de otra parte de la TSF recibir una confirmación deel acuse de recibo.

Por ejemplo, el TSF local transmite algunos datos a una parte remota de la TSF. La parte remota de la TSFreconoce la recepción satisfactoria de los datos y solicita que el TSF envío de confirmar que se recibeel acuse de recibo. Este mecanismo proporciona la confianza adicional de que ambas partes de la TSF involucrados enla transmisión de datos sabe que la transmisión ha finalizado satisfactoriamente.

Sellos J.10 Tiempo (FPT_STM)

Notas J.10.1 usuario

Esta familia se ocupa de los requisitos para una función de sello de tiempo de confianza dentro de una TOE.

Es la responsabilidad del autor PP / ST para aclarar el significado de la frase "el sello de tiempo de confianza", y paraindicar donde la responsabilidad recae en la determinación de la aceptación de la confianza.

J.10.2 FPT_STM.1 marcas de tiempo fiable

Notas de aplicación J.10.2.1 usuario

Algunos usos posibles de este componente incluyen proporcionar marcas de tiempo fiables a efectos de auditoría, asícomo para la expiración atributo de seguridad.

Página 222

ISO / IEC 15408-2:2008 (E)

Consistencia de los datos J.11 Inter-TSF TSF (FPT_TDC)


En un entorno distribuido o compuesto, una TOE puede necesitar para intercambiar datos de TSF (por ejemplo, los SFP-atributosasociada a los datos, la información de auditoría, la información de identificación) con otro producto de TI confiable, Esta familiadefine los requisitos para el intercambio y la interpretación uniforme de estos atributos entre la TSF delTOE y la de un grande IT producto diferente.

Los componentes de esta familia tienen por objeto proporcionar los requisitos para el soporte automatizado de datos TSFconsistencia cuando tales datos se transmiten entre la TSF del TOE y otro producto TI de confianza. EsTambién es posible que los medios de procedimiento total se podrían utilizar para producir la consistencia atributo de seguridad, peroNo se proporcionan para aquí.

Esta familia es diferente de FDP_ETC y FDP_ITC, ya que estas dos familias se preocupan sólo de resolverlos atributos de seguridad entre la TSF y su medio de importación / exportación.

Si la integridad de los datos TSF es motivo de preocupación, requisitos deben ser elegidos de la que ntegridad de exportadoDatos de TSF (FPT_ITI) f amilia. Estos componentes especifican los requisitos para la TSF para ser capaz de detectar o detectary las modificaciones correctas a los datos de TSF en tránsito.

J.11.2 FPT_TDC.1 Inter-TSF TSF consistencia de los datos básicos


La TSF es responsable de mantener la coherencia de los datos TSF utilizado por o asociado con la especificadafunción y que son comunes entre dos o más sistemas de confianza. Por ejemplo, los datos de TSF de dosdiferentes sistemas pueden tener diferentes convenios internamente. Para los datos de TSF para ser utilizados adecuadamente (por ejemplo, parapermitirse los datos de usuario de la misma protección en el TOE) por el producto de TI de confianza que recibe, el TOE yel otro producto de TI confiable debe utilizar un protocolo preestablecido para intercambiar datos de TSF.

Operaciones J.11.2.2

Asignación J.11.2.2.1

En FPT_TDC.1.1, t él PP / ST autor debe definir la lista de tipos de datos de TSF, para los que el TSF debe proporcionarla capacidad de interpretar constantemente, cuando se comparte entre la TSF y otro producto de TI de confianza.

En FPT_TDC.1.2, t él PP / ST debe asignar la lista de reglas de interpretación para ser aplicada por el TSF.

Pruebas J.12 de entidades externas (FPT_TEE)


12/6/2014 ISO / IEC 15408-2



Esta familia define los requisitos para la verificación de una o varias entidades externas por el TSF. Estos externaentidades no son usuarios humanos, y pueden incluir combinaciones de software y / o hardware interactuar conTOE.

Los ejemplos de los tipos de pruebas que pueden realizarse son:

a) examina la presencia de un firewall, y, posiblemente, si está configurado correctamente;

b) pruebas de algunas de las propiedades del sistema operativo que un dedo del pie aplicación se ejecuta en;

c) las pruebas de algunas de las propiedades de la IC que un inteligente TOE OS tarjeta se ejecuta en (por ejemplo, el número aleatoriogenerador).

Página 223

ISO / IEC 15408-2:2008 (E)

Tenga en cuenta que la entidad externa puede "mentir" acerca de los resultados de la prueba, ya sea a propósito o porque no está funcionandocorrectamente.

Estas pruebas pueden ser llevadas a cabo en algún estado de mantenimiento, en el arranque, en línea, o de manera continua. Laacciones a ser tomadas por el TOE como el resultado de la prueba se definen también en esta familia.

Notas J.12.2 Evaluador

Las pruebas de las entidades externas deben ser suficientes para probar todas las características de las mismas sobre la cual la TSFconfía.

J.12.3 Testing FPT_TEE.1 de entidades externas


Este componente no está destinado a ser aplicado a los usuarios humanos.

Este componente proporciona soporte para el control periódico de las propiedades relacionadas con entidades externas sobre las cualesla operación de la TSF depende, al requerir la capacidad de invocar periódicamente funciones de prueba.

El autor PP / ST puede refinar la obligación de declarar si la función debe estar disponible en off-line, on-line o en modo de mantenimiento.

Notas J.12.3.2 Evaluador

Es aceptable para las funciones para las pruebas periódicas que estarán disponibles sólo en el modo fuera de línea o de mantenimiento.Los controles deben estar en su lugar para limitar el acceso, durante el mantenimiento, para los usuarios autorizados.


Selección J.12.3.3.1

En FPT_TEE.1.1, t él PP / ST autor debe especificar cuando el TSF se ejecutará la comprobación de las entidades externas, duranteprimera puesta en marcha, periódicamente durante el funcionamiento normal, a solicitud de un usuario autorizado, o en virtud de otrocondiciones. Si se ejecutan las pruebas a menudo, entonces los usuarios finales deben tener más confianza en que el TOE esfuncionando correctamente, que si se ejecutan con menos frecuencia las pruebas. Sin embargo, esta necesidad de confianza en que el TOE esfuncionando correctamente debe equilibrarse con el posible impacto en la disponibilidad de la TOE, como muchas veces,las pruebas de las entidades externas puede retrasar el funcionamiento normal de un dedo.


En FPT_TEE.1.1, t él PP / ST autor debe especificar las propiedades de las entidades externas a ser controladas por lapruebas. Ejemplos de estas propiedades pueden incluir las propiedades de configuración o la disponibilidad de un servidor de directorioel apoyo a una parte de control de acceso de la TSF.

En FPT_TEE.1.1, el autor PP / ST debe, si se seleccionan otras condiciones, especificar la frecuencia con la quese llevará a cabo la prueba de entidades externas. Un ejemplo de esta otra frecuencia o condición puede ser para ejecutar elpone a prueba cada vez que un usuario solicita iniciar una sesión con el TOE. Por ejemplo, este podría ser el caso de losprueba de un servidor de directorio antes de su interacción con el TSF durante el proceso de autenticación de usuario.

En FPT_TEE.1.2, el autor PP / ST debería especificar cuáles son la acción (s) que la TSF debe realizar cuando elprueba falla. Ejemplos de estos acción (s), ilustrado por una instancia de servidor de directorio, pueden incluir para conectarse auna disposición alternativa del servidor o de otra manera para buscar un servidor de copia de seguridad.

12/6/2014 ISO / IEC 15408-2



Página 224

ISO / IEC 15408-2:2008 (E)


TSF TOE J.13 interna coherencia de replicación de datos (FPT_TRC)


Se necesitan los requisitos de esta familia para garantizar la coherencia de los datos TSF cuando tales datos sonreplicado interna a la TOE. Tales datos pueden ser incompatibles si un canal interno entre las partes de laTOE deja de funcionar. Si el TOE se estructura internamente como una red de partes del TOE, esto puede ocurrircuando las piezas se convierten en discapacitados, las conexiones de red están rotos, y así sucesivamente.

El método de garantizar la coherencia no se especifica en este componente. Esto podría lograrse a través de una forma deel registro de transacciones (donde las transacciones correspondientes se "deshacen" a un sitio después de la reconexión); podría serla actualización de los datos replicados a través de un protocolo de sincronización. Si un protocolo particular, es necesario que unPP / ST, se puede especificar a través de refinamiento.

Puede ser imposible sincronizar algunos estados, o el costo de dicha sincronización puede ser demasiado alto.Ejemplos de esta situación son el canal de comunicación y la revocación de claves de cifrado. Estados indeterminadosTambién pueden ocurrir, si se desea un comportamiento específico, es conveniente precisar a través de refinamiento.

J.13.2 FPT_TRC.1 TSF interna consistencia



En FPT_TRC.1.2, t él PP / ST autor debe especificar la lista de funciones depende de la replicación de datos TSFconsistencia.

Autotest J.14 TSF (FPT_TST)


La familia define los requisitos para el autodiagnóstico de la TSF respecto de algunos correcta esperadaoperación. Ejemplos son interfaces para las funciones de aplicación, y las operaciones aritméticas de ejemplo en críticopartes del TOE. Estas pruebas se pueden realizar en la puesta en marcha, periódicamente, a solicitud de un usuario autorizado,o cuando se cumplen otras condiciones. Las acciones a ser tomadas por el TOE como el resultado de las pruebas de auto se definenen otras familias.

También son necesarios los requisitos de esta familia para detectar la corrupción de los datos TSF TSF y sí (es decir, TSFcódigo ejecutable o TSF componente de hardware) por diversas fallas que no se detienen necesariamente del TOEoperación (que sería manejado por otras familias). Estos controles deben ser realizados debido a que estosfallas pueden no necesariamente ser prevenidos. Tales fallas pueden ocurrir ya sea debido a un fallo imprevistomodos o descuidos asociados en el diseño de hardware, firmware o software, o por la maliciosacorrupción de la TSF debido a la protección lógica y / o física inadecuada.

Además, el uso de este componente puede, con las condiciones apropiadas, ayudar a prevenir inapropiado o perjudicialCambios TSF se aplican a una TOE operacional como resultado de las actividades de mantenimiento.

El término "correcto funcionamiento de la TSF" se refiere principalmente a la operación de la TSF y la integridad de laDatos de la TSF.

Pruebas J.14.2 FPT_TST.1 TSF


Este componente proporciona soporte para la comprobación de las funciones críticas de la operación de la TSF, al exigir lacapacidad de invocar funciones de prueba y comprobar la integridad de los datos de la TSF y el código ejecutable.

Página 225

12/6/2014 ISO / IEC 15408-2


ISO / IEC 15408-2:2008 (E)


Notas J.14.2.2 Evaluador

Es aceptable que las funciones que están disponibles para el usuario autorizado para realizar pruebas periódicas para estar disponiblesólo en un modo fuera de línea o de mantenimiento. Los controles deben estar en su lugar de limitar el acceso durante estos modos deusuarios autorizados.



En FPT_TST.1.1, t él PP / ST autor debe especificar cuando el TSF ejecutará la prueba TSF; durante la puesta en marcha inicialmarcha, periódicamente durante el funcionamiento normal, a solicitud de un usuario autorizado, en otras condiciones. En el casode esta última opción, el autor PP / ST también debe asignar cuáles son esas condiciones a través de las siguientesasignación.

En FPT_TST.1.1, el autor PP / ST debe especificar si las pruebas de auto se llevarán a cabo para demostrarel correcto funcionamiento de todo el TSF, o de sólo determinadas partes de TSF.


En FPT_TST.1.1, t él PP / ST autor debe, si se selecciona, especifique las condiciones en que el auto-test debellevará a cabo.

En FPT_TST.1.1, t él PP / ST autor debe, si se selecciona, especifique la lista de partes de la TSF que estará sujeta aAutodiagnóstico TSF.


En FPT_TST.1.2, t él PP / ST autor debe especificar si la integridad de datos se vaya a verificar todos los datos de TSF, osólo para los datos seleccionados.


En FPT_TST.1.2, t él PP / ST autor debe, si se selecciona, especifique la lista de datos TSF que será verificada porintegridad.


En FPT_TST.1.3, t él PP / ST autor debe especificar si la integridad TSF debe ser verificado para todos TSF, o sólo paraTSF seleccionado.


En FPT_TST.1.3, t él PP / ST autor debe, si se selecciona, especifique la lista de TSF que será verificada por la integridad.

Página 226

ISO / IEC 15408-2:2008 (E)

Anexo K

(Normativo)

FRU Clase: Utilización de recursos

12/6/2014 ISO / IEC 15408-2



Esta clase proporciona tres familias que apoyan a la disponibilidad de los recursos necesarios, tales como el procesamiento decapacidad y / o capacidad de almacenamiento. La tolerancia a fallos de la familia proporciona protección contra la falta de disponibilidad decapacidades causados por el fallo de la TOE. La prioridad de la familia de servicio asegura que los recursos seránasignado a las tareas más importantes o críticos en el tiempo, y no puede ser monopolizado por tareas de menor prioridad. Lade asignación de recursos de la familia proporciona límites sobre el uso de los recursos disponibles, por lo tanto, evitar que los usuariosmonopolizar los recursos.

Figura K.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura K.1 - FRU: Recurso clase de utilización de descomposición

Tolerancia K.1 Fallo (FRU_FLT)

K.1.1 notas de usuario

Esta familia proporciona los requisitos para la disponibilidad de capacidades, incluso en el caso de fallas. Ejemplos detales fallas son apagón, fallo de hardware o un error de software. En el caso de estos errores, si así se especifica, elTOE mantendrá las capacidades especificados. El autor de PP / ST podía especificar, por ejemplo, que un TOE utilizado enuna planta nuclear continuará con el funcionamiento del procedimiento de apagado en caso de fallas del suministro eléctrico ola comunicación de fallos.

Debido a que el TOE sólo puede continuar su funcionamiento correcto si se cumplen los SFR, hay un requisito de queel sistema debe permanecer en un estado seguro después de un fracaso. Esta capacidad se proporciona b y FPT_FLS.1 Falla conpreservación de las condiciones de seguridad.

Los mecanismos para proporcionar tolerancia a fallos podrían ser activa o pasiva. En caso de un mecanismo activo,funciones específicas están en el lugar que se activan en caso de que se produzca el error. Por ejemplo, una alarma de incendio es un activomecanismo: la TSF detectará el fuego y puede tomar medidas como el cambio de la operación a una copia de seguridad. En unaesquema de pasivo, la arquitectura del TOE es capaz de manejar el error. Por ejemplo, el uso de unesquema de votación por mayoría con múltiples procesadores es una solución pasiva; fracaso de un procesador no interrumpirála operación del TOE (aunque necesita para ser detectado para permitir la corrección).

Para esta familia, no importa si el hecho se ha iniciado accidentalmente (como las inundaciones odesconectar el dispositivo equivocado) o intencionalmente (como acaparamiento).

Página 227

ISO / IEC 15408-2:2008 (E)

Tolerancia a fallos K.1.2 FRU_FLT.1 degradado

Notas de aplicación K.1.2.1 usuario

Este componente tiene por objeto especificar las capacidades de la TOE aun proporcionará después de un fallo del sistema.Puesto que sería difícil de describir todas las fallas específicas, categorías de fallas pueden ser especificados. Ejemplos defallas generales son la inundación de la sala de ordenadores, interrupción de energía a corto plazo, la ruptura de una CPU oanfitrión, falla de software, o de desbordamiento de búfer.

Operaciones K.1.2.2

K.1.2.2.1 Asignación

En FRU_FLT.1.1, t él PP / SAN autor debe especificar la lista de capacidades TOE TOE mantendrá durante ydespués de un fallo determinado.

En FRU_FLT.1.1, t él PP / ST autor debe especificar la lista de tipo de fallos contra los que el TOE debe serexplícitamente protegido. Si se produce un fallo en esta lista, el TOE será capaz de continuar con su operación.

12/6/2014 ISO / IEC 15408-2



Tolerancia a fallos K.1.3 FRU_FLT.2 Limited


Este componente está destinado a precisar contra qué tipo de fallas del TOE debe ser resistente. Desde que lo haríaser difícil de describir todas las fallas específicas, categorías de fallas pueden ser especificados. Ejemplos de en generalfracasos son la inundación de la sala de ordenadores, interrupción de energía a corto plazo, la ruptura de una CPU o anfitrión,falla de software, o de desbordamiento de búfer.

Operaciones K.1.3.2


En FRU_FLT.2.1, t él PP / ST autor debe especificar la lista de tipo de fallos contra los que el TOE debe serexplícitamente protegido. Si se produce un fallo en esta lista, el TOE será capaz de continuar con su operación.

Prioridad K.2 del servicio (FRU_PRS)


Los requisitos de esta familia permiten la TSF para controlar el uso de los recursos bajo el control de la TSF porlos usuarios y los sujetos de tal manera que las actividades de alta prioridad en el marco del control de la TSF siempre se lograránsin interferencia o retraso debido a las actividades de baja prioridad. En otras palabras, las tareas de tiempo crítico no se retrasarápor tareas que tiempo es menos crítico.

Esta familia podría ser aplicable a varios tipos de recursos, por ejemplo, capacidad de procesamiento, yla capacidad del canal de comunicación.

La prioridad del mecanismo de servicio puede ser pasiva o activa. En una prioridad pasiva del sistema de servicio, lasistema seleccionará la tarea con mayor prioridad cuando se les da a elegir entre dos aplicaciones de espera.Durante el uso de Prioridad pasiva de los mecanismos de servicio, cuando una tarea de baja prioridad se está ejecutando, no puede serinterrumpida por una tarea de alta prioridad. Mientras se utiliza una prioridad activa de mecanismos de servicio, las tareas de menor prioridadpodría ser interrumpido por las nuevas tareas de alta prioridad.

El requisito de auditoría establece que todos los motivos de rechazo deben ser auditados. Se deja a los desarrolladores para discutirque una operación no se rechaza, pero retrasó.

Página 228

ISO / IEC 15408-2:2008 (E)

Prioridad K.2.2 FRU_PRS.1 limitada de servicio


Este componente define prioridades para un sujeto, y los recursos para los cuales se utilizará esta prioridad. Si unintentos sujetas a tomar acción en un recurso controlado por la prioridad de las necesidades de servicios, el accesoy / o el tiempo de acceso será dependiente de la prioridad del objeto, la prioridad del objeto actualmente actuando,y la prioridad de los sujetos todavía en la cola.

Operaciones K.2.2.2


En FRU_PRS.1.2, t él PP / ST autor debe especificar la lista de los recursos controlados por el cual las hace cumplir TSFprioridad del servicio (por ejemplo, recursos tales como procesos, el espacio en disco, memoria, bandwidth).

FRU_PRS.2 K.2.3 prioridad completa de servicio


Este componente define prioridades para un sujeto. Todos los recursos que se pueden compartir en el marco del control de la TSF seránsometido al Orden de Prelación de mecanismo de servicio. Si un sujeto intenta tomar una decisión sobre una TSF compartiblede recursos, el acceso y / o el tiempo de acceso dependerán de la prioridad del tema, la prioridad de laActualmente actuando tema, y la prioridad de los temas todavía en la cola.

La asignación de recursos K.3 (FRU_RSA)


12/6/2014 ISO / IEC 15408-2



Los requisitos de esta familia permiten la TSF para controlar el uso de los recursos bajo el control de la TSF porlos usuarios y los sujetos de tal manera que la negación no autorizado del servicio no se llevará a cabo por medio de la monopolización derecursos por parte de otros usuarios o sujetos.

Las reglas de asignación de recursos permiten la creación de cuotas u otros medios para definir límites en la cantidad deespacio de recursos o el tiempo que puede ser asignada en nombre de un usuario o temas específicos. Estas reglas pueden ser, porejemplo:

• La apertura de contingentes de objetos que limitan el número y / o tamaño de los objetos a un usuario específico puede asignar.

• Controlar la asignación / desasignación de unidades de recursos preasignados donde estas unidades se encuentran bajo el control dedel TSF.

En general, estas funciones se llevarán a cabo mediante el uso de atributos asignados a los usuarios y los recursos.

El objetivo de estos componentes es para asegurar una cierta cantidad de equidad entre los usuarios (por ejemplo, un solousuario no debe recaer, en todo el espacio disponible) y los sujetos. Dado que la asignación de recursos a menudo va más allá dela esperanza de vida de un sujeto (es decir, archivos menudo existen más de las aplicaciones que los generaron), y múltiplesinstancias de los sujetos por el mismo usuario no deben afectar negativamente a otros usuarios demasiado, los componentespermiten que los límites de asignación están relacionados con los usuarios. En algunas situaciones los recursos se asignan por unsujeto (por ejemplo, la memoria principal o ciclos de CPU). En aquellos casos en los componentes permiten que el recursoasignación de estar en el nivel de los sujetos.

Esta familia impone requisitos sobre la asignación de recursos, y no en el uso del recurso mismo. La auditoríarequisitos, por lo tanto, como se dijo, se aplican también a la asignación de los recursos, no a la utilización del recurso.

Página 229

ISO / IEC 15408-2:2008 (E)

Cuotas K.3.2 FRU_RSA.1 Máximo


Este componente proporciona requisitos para los mecanismos de cuotas que se aplican sólo a un grupo específico de lalos recursos que se pueden compartir en la puntera. Los requisitos permiten que las cuotas a estar asociados con un usuario, posiblementeasignado a grupos de usuarios o sujetos como aplicables a la TOE.

Operaciones K.3.2.2


En FRU_RSA.1.1, el autor PP / ST debe especificar la lista de los recursos controlados por las que el máximose requieren límites de asignación de recursos (por ejemplo, procesos, espacio en disco, memoria, ancho de banda). Si todos los recursos bajonecesita el control de la TSF que se incluirán las palabras "todos los recursos TSF" se pueden especificar.

K.3.2.2.2 Selección

En FRU_RSA.1.1, t él PP / ST autor debe seleccionar si los cupos máximos se aplican a los usuarios individuales, a ungrupo definido de usuarios o sujetos o cualquier combinación de éstos.

En FRU_RSA.1.1, el autor PP / ST debe seleccionar si las cuotas máximas son aplicables a cualquier dadotiempo (simultáneamente), o durante un intervalo de tiempo específico.

K.3.3 FRU_RSA.2 mínimos y cuotas máximas


Este componente proporciona requisitos para los mecanismos de cuotas que se aplican a un conjunto determinado de la compartiblerecursos en el TOE. Los requisitos permiten que las cuotas a estar asociados con un usuario, o posiblemente asignados agrupos de usuarios como aplicables a la TOE.

Operaciones K.3.3.2


En FRU_RSA.2.1, el autor PP / ST debe especificar los recursos controlados por las que el máximo y el mínimose requieren límites de asignación de recursos (por ejemplo, procesos, espacio en disco, memoria, ancho de banda). Si todos los recursos bajonecesita el control de la TSF que se incluirán las palabras "todos los recursos TSF" se pueden especificar.


12/6/2014 ISO / IEC 15408-2



En FRU_RSA.2.1, t él PP / ST autor debe seleccionar si los cupos máximos se aplican a los usuarios individuales, a ungrupo definido de usuarios o sujetos o cualquier combinación de éstos.

En FRU_RSA.2.1, el autor PP / ST debería seleccionar si las cuotas máximas son aplicables a cualquier dadotiempo (simultáneamente), o durante un intervalo de tiempo específico.


En FRU_RSA.2.2, t él PP / ST autor debe especificar los recursos controlados por el cual una asignación mínimalímite debe establecerse (por ejemplo, los procesos, el espacio en disco, memoria, ancho de banda). Si todos los recursos bajo el control de laTSF deben incluirse las palabras "todos los recursos TSF" se pueden especificar.

Página 230

ISO / IEC 15408-2:2008 (E)


En FRU_RSA.2.2, t él PP / ST autor debe seleccionar si las cuotas mínimas se aplican a los usuarios individuales, para ungrupo definido de usuarios o sujetos o cualquier combinación de éstos.

En FRU_RSA.2.2, el autor PP / ST debe seleccionar si las cuotas mínimas son aplicables a cualquier dadotiempo (simultáneamente), o durante un intervalo de tiempo específico.

12/6/2014 ISO / IEC 15408-2



Página 231

ISO / IEC 15408-2:2008 (E)


Anexo L

(Normativo)

Clase FTA: acceso TOE

El establecimiento de la sesión de un usuario normalmente consiste en la creación de uno o varios sujetos que realizanoperaciones en el TOE en nombre del usuario. Al final del procedimiento de establecimiento de la sesión, siempre que elRequisitos de acceso TOE están satisfechos, los temas creados tienen los atributos que determine elfunciones de identificación y autenticación. Esta familia se especifican los requisitos funcionales para el control de laestablecimiento de la sesión de un usuario.

Una sesión de usuario se define como el período que comienza en el momento de la identificación / autenticación, o si másapropiado, el inicio de una interacción entre el usuario y el sistema, hasta el momento en que todos los sujetos(Recursos y atributos) relacionados con ese período de sesiones se han cancelado la asignación.

Figura B.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura B.1 - FTA: clase de acceso TOE descomposición

Limitación L.1 el alcance de atributos seleccionables (FTA_LSA)

L.1.1 notas de usuario

Esta familia define requisitos que limiten la seguridad de sesión atribuye un usuario puede seleccionar, y elsujetos a los que un usuario puede estar unido, basado en: el método de acceso; la ubicación o puerto de acceso; y / oel tiempo (por ejemplo, tiempo-de-día, día de la semana).

Esta familia proporciona la capacidad de un autor de PP / ST para especificar requisitos para la TSF para colocar límites ael dominio de los atributos de seguridad de un usuario autorizado basa en una condición ambiental. Por ejemplo, unausuario puede ser autorizado a establecer una "sesión secreta" durante el horario normal, pero fuera de esas horas, la

12/6/2014 ISO / IEC 15408-2


Página 232

ISO / IEC 15408-2:2008 (E)


mismo usuario puede estar restringido a sólo el establecimiento de "sesiones no clasificados". La identificación de relevanteslimitaciones en el dominio de atributos seleccionables se pueden lograr mediante el uso de la operación de selección.Estas restricciones se pueden aplicar de forma atributo por atributo. Cuando existe la necesidad de especificarrestricciones en varios atributos de este componente deberán ser replicado para cada atributo. Ejemplos deatributos que podrían ser utilizados para limitar los atributos de seguridad de sesión son:

a) El método de acceso se puede utilizar para especificar en qué tipo de entorno de usuario estará operando (por ejemplo,protocolo de transferencia de archivos, terminal, VTAM).

b) La ubicación de acceso se puede utilizar para limitar el dominio de atributos seleccionables de un usuario basado en unaubicación del usuario o puerto de acceso. Esta capacidad es de uso particular en entornos en los que el dial-upinstalaciones o instalaciones de la red están disponibles.

c) El tiempo de acceso se puede utilizar para limitar el dominio de los atributos seleccionables de un usuario. Por ejemplo,intervalos pueden basarse en, o las fechas del calendario de hora del día día de la semana. Esta limitación proporciona algunosprotección operacional contra las acciones del usuario que podrían ocurrir en un momento en que un control adecuado o cuandomedidas procesales adecuadas pueden no estar en su lugar.

L.1.2 FTA_LSA.1 Limitación en el alcance de atributos seleccionables

L.1.2.1 Operaciones

L.1.2.1.1 Asignación

En FTA_LSA.1.1, el autor PP / ST debe especificar el conjunto de atributos de seguridad de sesión que van a serlimitado. Ejemplos de estos atributos de seguridad de sesión son nivel de autorización del usuario, nivel de integridad y roles.

En FTA_LSA.1.1, el autor PP / ST debe especificar el conjunto de atributos que se pueden utilizar para determinar el alcancede los atributos de seguridad de sesión. Ejemplos de tales atributos son la identidad del usuario, la ubicación de origen, el tiempo deel acceso, y el método de acceso.

Limitación L.2 en varias sesiones simultáneas (FTA_MCS)


Esta familia define cuántas sesiones un usuario puede tener al mismo tiempo (sesiones concurrentes). Este númerode sesiones simultáneas puede ser bien sea para un grupo de usuarios o para cada usuario individual.

L.2.2 FTA_MCS.1 básico limitación en varias sesiones simultáneas

L.2.2.1 Notas de la aplicación de usuario

Este componente permite que el sistema para limitar el número de sesiones con el fin de utilizar eficazmente los recursos deTOE.

L.2.2.2 Operaciones


En FTA_MCS.1.2, el autor PP / ST debería especificar el número predeterminado de sesiones simultáneas máximas para serutilizado.

L.2.3 FTA_MCS.2 Por usuario atributo limitación en varias sesiones simultáneas


Este componente proporciona capacidades adicionales sobre los de FTA_MCS.1 limitación básica sobre múltiplessesiones simultáneas, permitiendo nuevas limitaciones para ser colocado en el número de sesiones simultáneas que

Página 233

ISO / IEC 15408-2:2008 (E)

los usuarios son capaces de invocar. Estas limitaciones son, en términos de los atributos de seguridad de un usuario, como por ejemplo un usuario deidentidad o pertenencia a un determinado rol.

L.2.3.2 Operaciones

12/6/2014 ISO / IEC 15408-2




En FTA_MCS.2.1, el autor PP / ST debe especificar las reglas que determinan el número máximo desesiones simultáneas. Un ejemplo de una regla es el "número máximo de sesiones simultáneas es uno si el usuario tieneun nivel de clasificación de "secreto" y cinco de otra manera ".

En FTA_MCS.2.2, el autor PP / ST debe especificar el número predeterminado de sesiones simultáneas máximas para serutilizado.

L.3 bloqueo y finalización de sesión (FTA_SSL)


Esta familia define requisitos para la TSF para proporcionar la capacidad de TSF-iniciado y promovido por el usuariobloqueo, desbloqueo, y la terminación de las sesiones interactivas.

Cuando un usuario está interactuando directamente con los sujetos en el TOE (sesión interactiva), el terminal del usuario esvulnerables si no se corrige. Esta familia proporciona los requisitos para la TSF para desactivar (bloquear) el terminal oterminar la sesión después de un período de inactividad, y para el usuario para iniciar la desactivación (bloqueo) determinal o terminar la sesión. Para reactivar la terminal, un evento especificada por el autor PP / ST, talescomo el usuario debe ocurrir re-autenticación.

Un usuario es considerado inactivo, si él / ella no ha proporcionado ningún estímulo a la TOE durante un período determinado detiempo.

Un autor de PP / ST debe considerar si FTP _TRP.1 sho camino Trusted uld ser incluido. En ese caso, lafunción de "sesión de bloqueo" debe ser incluido en la operación i n FTP_TRP.1 Trusted camino.

Cierre la sesión iniciada por el TSF L.3.2 FTA_SSL.1


Cierre la sesión iniciada por el TSF FTA_SSL.1, proporciona la capacidad de la TSF para bloquear una sesión de usuario activadespués de un período de tiempo especificado. El bloqueo de un terminal de prevendría otras interacciones con una activa existentesesión a través de la utilización de la terminal de bloqueado.

Si se sobrescriben los dispositivos de visualización, los contenidos de reemplazo no deben ser estáticas (es decir, "protectores de pantalla" sonpermitida).

Este componente permite al autor PP / ST para especificar qué eventos va a desbloquear la sesión. Estos eventos pueden serrelacionado con el terminal (por ejemplo, conjunto fijo de pulsaciones de teclas para desbloquear la sesión), el usuario (por ejemplo, nueva autenticación), otiempo.

L.3.2.2 Operaciones


En FTA_SSL.1.1, t él PP / ST autor debe especificar el intervalo de inactividad del usuario que activará el bloqueo deuna sesión interactiva. Si así lo desea el autor PP / ST podría, a través de la asignación, especifique que el tiempointervalo se deja a la administrador autorizado o el usuario. Las funciones de gestión de la clase FMT puedeespecificar la capacidad de modificar este intervalo de tiempo, por lo que es el valor predeterminado.

En FTA_SSL.1.2, el autor PP / ST debe especificar el evento (s) que debe ocurrir antes de que la sesión esdesbloqueado. Ejemplos de tal evento son: "usuario re-autenticación" o "usuario introduce desbloquear key-sequence".

Página 234

ISO / IEC 15408-2:2008 (E)

L.3.3 FTA_SSL.2 bloqueo iniciado por el usuario


FTA_SSL.2 bloqueo iniciado por el usuario, proporciona la capacidad de un usuario autorizado para bloquear y desbloquear su / supropia sesión interactiva. Esto proporcionaría a los usuarios autorizados la capacidad de bloquear de manera efectiva el uso adicional desus sesiones activas sin tener que interrumpir la sesión activa.

Si se sobrescriben los dispositivos, los contenidos de reemplazo no deben ser estáticas (es decir, "protectores de pantalla" están permitidos).

L.3.3.2 Operaciones


En FTA_SSL.2.2, el autor PP / ST debe especificar el evento (s) que debe ocurrir antes de que la sesión esdesbloqueado. Ejemplos de tal evento son: "usuario re-autenticación", o "usuario introduce desbloquear key-sequence".

12/6/2014 ISO / IEC 15408-2



Terminación iniciada por TSF L.3.4 FTA_SSL.3


Terminación iniciada por TSF FTA_SSL.3, requiere que el TSF terminar una sesión de usuario interactiva después de unperíodo de inactividad.

El autor PP / ST debe ser consciente de que una sesión puede continuar después de que el usuario termina su / su actividad, porejemplo, el proceso de fondo. Este requisito podría dar por terminado este fondo sujeto después de un período deinactividad del usuario sin tener en cuenta el estado de la materia.

L.3.4.2 Operaciones


En FTA_SSL.3.1, t él PP / ST autor debe especificar el intervalo de inactividad del usuario que desencadenará la terminaciónde una sesión interactiva. Si así se desea, el autor de PP / ST podría, a través de la asignación, especificar que elintervalo se deja a la administrador autorizado o el usuario. Las funciones de gestión de la clase FMT puedeespecificar la capacidad de modificar este intervalo de tiempo, por lo que es el valor predeterminado.

L.3.5 FTA_SSL.4 terminación iniciada por el usuario


FTA_SSL.4 terminación iniciada por el usuario, proporciona la capacidad de un usuario autorizado a rescindir su / susesión interactiva.

El autor PP / ST debe ser consciente de que una sesión puede continuar después de que el usuario termina su / su actividad, porejemplo, el proceso de fondo. Este requisito sería que el usuario pueda terminar este fondo objetosin tener en cuenta el estado de la materia.

Acceso TOE L.4 banners (FTA_TAB)


Antes de la identificación y autenticación, los requisitos de acceso TOE proporcionan la capacidad para el dedo para mostrarun mensaje de advertencia de asesoramiento a los usuarios potenciales relacionados con el uso apropiado de la TOE.

Página 235

ISO / IEC 15408-2:2008 (E)

L.4.2 FTA_TAB.1 acceso predeterminados TOE banners


Este componente requiere que haya una advertencia de asesoramiento en relación con el uso no autorizado de la TOE. LaPP / ST autor podría refinar el requisito de incluir una bandera por defecto.

Historial de acceso TOE L.5 (FTA_TAH)


Esta familia define requisitos para la TSF para mostrar a los usuarios, en el establecimiento de sesión con éxito a laTOE, una historia de intentos fallidos de acceder a la cuenta. Esta historia puede incluir la fecha, hora,medios de acceso, y el puerto de la última conexión exitosa a la TOE, así como el número de éxitolos intentos de acceder a la TOE desde el último acceso exitoso por el usuario identificado.

Historial de acceso TOE FTA_TAH.1 L.5.2


Esta familia puede proporcionar a los usuarios autorizados con información que puede indicar la posible mal uso de su usuariocuenta.

Esta solicitud componente que se presenta al usuario con la información. El usuario debe ser capaz de revisar elinformación, pero no está obligado a hacerlo. Si un usuario así lo desee podría, por ejemplo, crear secuencias de comandos que hacen caso omiso de estainformación y empezar a otros procesos.

12/6/2014 ISO / IEC 15408-2



L.5.2.2 Operaciones

L.5.2.2.1 Selección

En FTA_TAH.1.1, el autor PP / ST debe seleccionar los atributos de seguridad de la última sesión exitosaestablecimiento que se mostrará en la interfaz de usuario. Los artículos son: fecha, hora y método de acceso (comoftp), y / o ubicación (por ejemplo, el terminal 50).

En FTA_TAH.1.2, el autor PP / ST debe seleccionar los atributos de seguridad de la última sesión sin éxitoestablecimiento que se mostrará en la interfaz de usuario. Los artículos son: fecha, hora y método de acceso (comoftp), y / o ubicación (por ejemplo, el terminal 50).

Establecimiento de la sesión TOE L.6 (FTA_TSE)


Esta familia define requisitos para negar un permiso de usuario para establecer una sesión con el TOE basado enatributos tales como la ubicación o el puerto de acceso, atributo de seguridad del usuario (por ejemplo, la identidad, nivel de autorización,nivel de integridad, la pertenencia a un papel), rangos de tiempo (por ejemplo, la hora del día, día de la semana, las fechas del calendario) ocombinaciones de parámetros.

Esta familia proporciona la capacidad para el autor PP / ST para especificar los requisitos para el TOE para colocarlimitaciones sobre la capacidad de un usuario autorizado a establecer una sesión con el dedo del pie. La identificación de losrestricciones pertinentes se pueden lograr mediante el uso de la operación de selección. Los ejemplos de atributos quepodría ser utilizado para especificar la sesión limitaciones establecimiento son:

a) La ubicación de acceso se puede utilizar para limitar la capacidad de un usuario para establecer una sesión activa conTOE, basado en la ubicación del usuario o puerto de acceso. Esta capacidad es de uso particular enentornos en los que las instalaciones de acceso telefónico o instalaciones de la red están disponibles.

Página 236

ISO / IEC 15408-2:2008 (E)

b) los atributos de seguridad del usuario se pueden usar para colocar restricciones en la capacidad de un usuario para establecer unasesión activa con el TOE. Por ejemplo, estos atributos proporcionarían la capacidad de negar sesiónestablecimiento basado en cualquiera de los siguientes:

• la identidad de un usuario;

• nivel de autorización del usuario;

• nivel de integridad de un usuario; y

• la pertenencia de un usuario en un papel.

Esta capacidad es especialmente importante en situaciones en las que la autorización o el inicio de sesión puede tener lugar en una diferentelugar desde donde se realizan las comprobaciones de acceso TOE.

a) El tiempo de acceso se puede utilizar para limitar la capacidad de un usuario para establecer una sesión activa con laTOE basado en intervalos de tiempo. Por ejemplo, los rangos pueden basarse en el tiempo-de-día, día de la semana, olas fechas del calendario. Esta restricción proporciona una cierta protección contra las acciones operativas que podrían ocurrir en untiempo en el que un control adecuado, o cuando las medidas procesales adecuadas pueden no estar en su lugar.

L.6.2 FTA_TSE.1 establecimiento de sesión TOE

L.6.2.1 Operaciones


En FTA_TSE.1.1, el autor PP / ST debe especificar los atributos que se pueden utilizar para restringir la sesiónestablecimiento. Ejemplo de posibles atributos son la identidad del usuario, la ubicación (por ejemplo, no hay terminales remotos) de origen,tiempo de acceso (por ejemplo, en las horas), o método de acceso (por ejemplo X-Windows).

12/6/2014 ISO / IEC 15408-2



Página 237

ISO / IEC 15408-2:2008 (E)

Anexo M

(Normativo)

FTP Clase: Trusted ruta / canales

Los usuarios a menudo necesitan para realizar funciones a través de la interacción directa con el TSF. Una ruta de confianza proporcionaconfianza de que un usuario se comunica directamente con la TSF cada vez que se invoca. La respuesta de un usuario a través dela ruta de confianza garantiza que las aplicaciones no son de confianza no pueden interceptar o modificar la respuesta del usuario.Del mismo modo, los canales de confianza son uno de los enfoques para la comunicación segura entre la TSF y otro grandeProductos de TI.

La ausencia de una ruta de confianza puede permitir que las infracciones de la rendición de cuentas o el control de acceso en entornos en los quese utilizan aplicaciones no confiables. Estas aplicaciones pueden interceptar la información privada del usuario, como por ejemplocontraseñas, y lo utilizan para hacerse pasar por otros usuarios. Como consecuencia, la responsabilidad de cualquier acción del sistemano se puede asignar de forma fiable a una entidad responsable. Además, estas aplicaciones podría generar erróneainformación en la pantalla de un usuario desprevenido, lo que resulta en acciones de los usuarios posteriores que puedan ser erróneay puede conducir a un fallo de seguridad.

Figura M.1 muestra la descomposición de esta clase en sus componentes constitutivos.

Figura M.1 - FTP: Trusted ruta / canales clase descomposición

M.1 canal Inter-TSF confianza (FTP_ITC)

M.1.1 notas de usuario

Esta familia define las reglas para la creación de una conexión de canal de confianza que va entre la TSF yotro producto de TI de confianza para el desempeño de las operaciones críticas de seguridad entre los productos. Unejemplo de una operación crítica como la seguridad es la actualización de la base de datos de autenticación TSF por la transferenciade los datos de un producto de confianza, cuya función es la recogida de datos de auditoría.

M.1.2 FTP_ITC.1 Inter-TSF confiaba canal

Notas de aplicación M.1.2.1 usuario

Este componente debe utilizarse cuando un canal de comunicación confiable entre la TSF y otro de confianzaSe requiere de productos de TI.

12/6/2014 ISO / IEC 15408-2



Operaciones M.1.2.2

Selección M.1.2.2.1

En FTP_ITC.1.2, el autor PP / ST debe especificar si el TSF locales, otro producto de TI de confianza, o ambostendrá la capacidad de iniciar el canal de confianza.

Página 238

ISO / IEC 15408-2:2008 (E)

218

Asignación M.1.2.2.2

En FTP_ITC.1.3, el autor PP / ST debería especificar las funciones para las que se requiere un canal de confianza.Algunos ejemplos de estas funciones pueden incluir la transferencia de usuario, el asunto y / o los atributos de seguridad de objetos ygarantizar la coherencia de los datos de la TSF.

Ruta M.2 confianza (FTP_TRP)

M.2.1 notas de usuario

Esta familia define los requisitos para establecer y mantener una comunicación de confianza para o de los usuarios y laTSF. Una ruta de confianza puede ser requerida por cualquier interacción relevante para la seguridad. Intercambios ruta de confianza pueden seriniciado por un usuario durante una interacción con el TSF, o la TSF puede establecer la comunicación con el usuarioa través de una ruta de confianza.

Ruta M.2.2 FTP_TRP.1 Trusted

Notas de aplicación M.2.2.1 usuario

Este componente debe ser utilizada cuando se requiere una comunicación confiable entre un usuario y la TSF, ya seasólo o para operaciones de usuario especificadas adicionales propósitos iniciales de autenticación.

Operaciones M.2.2.2


En FTP_TRP.1.1, el autor PP / ST debe especificar si la ruta de confianza debe extenderse a distanciay / o los usuarios locales.

En FTP_TRP.1.1, el autor PP / ST debe especificar si la ruta de confianza protegerá los datos demodificación, divulgación y / o otros tipos de integridad o violación de confidencialidad.


En FTP_TRP.1.1, i f seleccionado, el autor PP / ST debería identificar cualquier tipos adicionales de integridad o confidencialidadviolación contra el cual la ruta de confianza deberá proteger los datos.


En FTP_TRP.1.2, el autor PP / ST debe especificar si el TSF, los usuarios locales, y / o los usuarios remotos debenpoder iniciar el camino de confianza.

En FTP_TRP.1.3, el autor PP / ST debe especificar si la ruta de confianza se va a utilizar para el usuario inicialde autenticación y / o para otros servicios especificados.


En FTP_TRP.1.3, i f seleccionado, el autor PP / ST debe identificar otros servicios para los cuales se requiere un directorio de confianza,si los hubiere.

12/6/2014 ISO / IEC 15408-2


© ISO / IEC 2008 - Todos los derechos reservados

Página 239Página 240

ISO / IEC 15408-2:2008 (E)

ICS 35.040

Precio basado en 218 páginas

© ISO / IEC 2008 - Todos los derechos reservados

ISO _ IEC 15408 2 Español

Documents

Transcript of ISO _ IEC 15408 2 Español