D R A F T Common Criteria for Information Technology Security Evaluation -------------------------- CCEB-94/083 Part 2: Security functional requirements P r e l i m i n a r y D R A F T Version 0.90 94/10/31 D R A F T This document is paginated from i to x and from 1 to 246 D R A F T CCEB-94/083 Table of contents 94/10/31 Version 0.90 Page i of x Table of contents Chapter 1 Introduction .................................................... 1 1.1 Scope ................................................................. 1 1.2 Organisation of Part 2 ................................................ 1 1.3 Functional requirements paradigm ...................................... 2 1.3.1 Decomposition of the Target of Evaluation ........................... 3 1.3.1.1 Target of Evaluation .............................................. 3 1.3.1.2 TOE Security Policy ............................................... 3 1.3.1.3 TOE Security Functions ............................................ 4 1.3.1.4 TSF Scope of Control .............................................. 4 1.3.1.5 TSF Interface ..................................................... 4 1.3.1.6 Security Function ................................................. 4 1.3.1.7 Security Function Policy .......................................... 4 1.3.1.8 Security Mechanisms ............................................... 5 1.3.2 Isolation ........................................................... 5 1.3.2.1 Security Attributes ............................................... 5 1.3.2.2 Objects ........................................................... 5 1.3.2.3 Subjects .......................................................... 5 1.3.2.4 Processes ......................................................... 5 1.3.2.5 Users ............................................................. 5 1.3.2.6 Session ........................................................... 6 1.3.2.7 Authorised User ................................................... 6 1.3.2.8 Role .............................................................. 6 1.3.2.9 TSF versus User Data .............................................. 6 1.3.2.10 Security Domain .................................................. 7 1.3.3 Security enforcement ................................................ 7 1.3.4 Communications ...................................................... 7 1.3.4.1 Trusted Path ...................................................... 8 1.3.4.2 Trusted Channel ................................................... 8 1.3.4.3 User Data Communications .......................................... 8 1.3.4.4 Consistency ....................................................... 8 Chapter 2 Security functional requirements ................................ 9 2.1 Component taxonomy .................................................... 9 2.2 Threats mapping and risk analysis .................................... 10 2.3 Components relationship .............................................. 10 Class FIA Identification and Authentication .............................. 11 FIA_ATD User Attribute Definition ........................................ 12 FIA_ATD.1 Minimal User Attribute Definition .............................. 13 FIA_ATD.2 Basic User Attribute Definition ................................ 14 FIA_ATA User Attribute Administration .................................... 14 D R A F T Table of contents CCEB-94/083 Page ii of x Version 0.90 94/10/31 FIA_ATA.1 User Security Attribute Initialisation ......................... 16 FIA_ATA.2 Basic User Security Attribute Administration ................... 17 FIA_ATA.3 Role Based User Security Attribute Administration .............. 17 FIA_ATP User Attribute Protection ........................................ 18 FIA_ATP.1 User Attribute Protection ...................................... 19 FIA_ATC User Attribute Consistency ....................................... 20 FIA_ATC.1 User Attribute Consistency between TSFs ........................ 21 FIA_USB User-Subject Binding ............................................. 21 FIA_USB.1 User-Subject Binding ........................................... 23 FIA_UID User Identification .............................................. 23 FIA_UID.1 Basic User Identification ...................................... 24 FIA_UID.2 Unique Identification of Users ................................. 25 FIA_UAU User Authentication .............................................. 25 FIA_UAU.1 Basic User Authentication ...................................... 27 FIA_UAU.2 Single-use Authentication Mechanisms ........................... 28 FIA_UAU.3 On-demand Authentication ....................................... 29 FIA_UAU.4 Non-repudiation of Authentication .............................. 29 FIA_UAU.5 Multiple Authentication Mechanisms ............................. 30 FIA_UAU.6 Policy-based Authentication Mechanisms ......................... 31 FIA_UAU.7 Installable Authentication Mechanisms .......................... 32 FIA_ADP User Authentication Data Protection .............................. 33 FIA_ADP.1 Basic User Authentication Data Protection ...................... 34 FIA_ADP.2 Extended User Authentication Data Protection ................... 34 FIA_AAA User Authentication Attribute Administration ..................... 35 FIA_AAA.1 Minimal User Authentication Attribute Administration ........... 37 FIA_AAA.2 Basic User Authentication Attribute Administration ............. 37 FIA_AAA.3 Role-based User Authentication Attribute Administration ........ 38 FIA_SOS Selection of Secrets ............................................. 39 FIA_SOS.1 Basic selection of Secrets ..................................... 40 FIA_SOS.2 TSF Generation of Secrets ...................................... 40 Class FTP Trusted Path ................................................... 41 FTP_TRP Trusted Path ..................................................... 42 FTP_TRP.1 Basic Trusted Path ............................................. 43 FTP_TRP.2 Expanded-Use Trusted Path ...................................... 44 FTP_TRP.3 User-TSF Initiated Trusted Path ................................ 45 FTP_ITP Inter-TSF Trusted Path ........................................... 46 FTP_ITP.1 Basic Inter-TSF Trusted Path ................................... 47 FTP_ITP.2 Expanded-Use Inter-TSF Trusted Path ............................ 48 FTP_ITP.3 Trusted Remote User-TSF Communication .......................... 49 FTP_ITC Inter-TSF Trusted Channel ........................................ 50 FTP_ITC.1 Inter-TSF Trusted Channel ...................................... 51 Class FAU Security Audit ................................................. 53 FAU_GEN Security Audit Event Generation .................................. 54 FAU_GEN.1 Minimal Audit Generation ....................................... 57 D R A F T CCEB-94/083 Table of contents 94/10/31 Version 0.90 Page iii of x FAU_GEN.2 Basic Audit Generation ......................................... 58 FAU_GEN.3 Detailed Audit Generation ...................................... 59 FAU_PRO Security Audit Trail Protection .................................. 60 FAU_PRO.1 Basic Audit Trail Protection ................................... 60 FAU_PRO.2 Complete Audit Trail Protection ................................ 61 FAU_SEL Security Audit Event Selection ................................... 61 FAU_SEL.1 Selective Audit by Attributes Only ............................. 63 FAU_SEL.2 Selective Audit by Individuals Only ............................ 63 FAU_SEL.3 Selective Audit by Attributes and Individuals .................. 64 FAU_SEL.4 Selective Audit Per-Event ...................................... 64 FAU_SEL.5 Runtime Selective Audit ........................................ 65 FAU_PRP Security Audit Pre-storage Processing ............................ 66 FAU_PRP.1 Symbolic Name Association ...................................... 67 FAU_PRA Security Audit Pre-storage Analysis .............................. 67 FAU_PRA.1 Imminent Violation Analysis .................................... 68 FAU_PRA.2 Intrusion Detection Analysis ................................... 69 FAU_ARP Security Audit Automatic Response ................................ 70 FAU_ARP.1 Security Alarms ................................................ 71 FAU_ARP.2 Pre-emptive Response ........................................... 71 FAU_STG Security Audit Event Storage ..................................... 72 FAU_STG.1 Enumeration of Audit Data Loss ................................. 73 FAU_STG.2 Prevention of Audit Data Loss .................................. 73 FAU_POP Security Audit Post-storage Processing ........................... 73 FAU_POA Security Audit Post-storage Analysis ............................. 74 FAU_POA.1 Audit Review ................................................... 75 FAU_POA.2 Audit Analysis ................................................. 75 FAU_MGT Security Audit Management ........................................ 76 FAU_MGT.1 Administration of Audit ........................................ 77 FAU_MGT.2 Separate Audit Administration .................................. 77 Class FTE TOE Entry ...................................................... 79 FTE_TEB TOE Entry Banners ................................................ 80 FTE_TEB.1 Default TOE Entry Banners ...................................... 81 FTE_TEB.2 Configurable TOE Entry Banners ................................. 82 FTE_MCS Limitation on Multiple Concurrent Sessions ....................... 83 FTE_MCS.1 Basic Limitation on Multiple Concurrent Sessions ............... 84 FTE_MCS.2 Per User Attribute Limitation on Multiple Concurrent Sessions .. 85 FTE_MTE Method of Entry .................................................. 85 FTE_MTE.1 Method of Entry ................................................ 87 FTE_MDE Mode of Entry .................................................... 87 FTE_MDE.1 Mode of Entry .................................................. 89 FTE_TME Time of Entry .................................................... 89 FTE_TME.1 Basic Time of Entry ............................................ 91 FTE_TME.2 Selective Time of Entry ........................................ 91 FTE_LCE Location of Entry ................................................ 92 FTE_LCE.1 Basic Location of Entry ........................................ 93 FTE_LCE.2 Extended Location of Entry ..................................... 94 FTE_TEH TOE Entry History ................................................ 95 D R A F T Table of contents CCEB-94/083 Page iv of x Version 0.90 94/10/31 FTE_TEH.1 TOE Entry History .............................................. 96 FTE_SSL Session Locking .................................................. 96 FTE_SSL.1 Session Locking and Unlocking .................................. 97 FTE_SSL.2 User-initiated Locking ......................................... 98 FTE_TEM TOE Entry Management ............................................. 99 FTE_TEM.1 Basic TOE Entry Management .................................... 100 FTE_TEM.2 Role-based TOE Entry Management ............................... 100 Class FDP User Data Protection .......................................... 103 FDP_ACC Access Control .................................................. 107 FDP_ACC.1 Subset Access Control ......................................... 111 FDP_ACC.2 Object Access Control ......................................... 112 FDP_ACC.3 Complete Access Control ....................................... 113 FDP_ACC.4 Subset Fixed Protection ....................................... 114 FDP_ACC.5 Object Fixed Protection ....................................... 114 FDP_ACC.6 Complete Fixed Protection ..................................... 115 FDP_IFC Information Flow Control ........................................ 116 FDP_IFC.1 Subset flow control ........................................... 119 FDP_IFC.2 Object Flow Control ........................................... 119 FDP_IFC.3 Specified Flow Control ........................................ 120 FDP_IFC.4 Bounded Flow Control .......................................... 121 FDP_IFC.5 Complete Operation Flow Control ............................... 122 FDP_IFC.6 Complete Flow Control ......................................... 122 FDP_RIP Residual Information Protection ................................. 123 FDP_RIP.1 Subset Deletion Protection .................................... 125 FDP_RIP.2 Full Deletion Protection ...................................... 126 FDP_RIP.3 Subset Creation Protection .................................... 126 FDP_RIP.4 Full Creation Protection ...................................... 127 FDP_ACM Access Control Mechanisms ....................................... 128 FDP_ACM.1 Single Identity-based Access Control .......................... 130 FDP_ACM.2 Multiple Identity-based Access Control ........................ 131 FDP_ACM.3 Single Group-based Access Control ............................. 132 FDP_ACM.4 Multiple Group-based Access Control ........................... 132 FDP_ACM.5 Single Subject-based Access Control ........................... 133 FDP_ACM.6 Multiple Subject-based Access Control ......................... 134 FDP_ACM.7 Single Role-based Access Control .............................. 135 FDP_ACM.8 Multiple Role-based Access Control ............................ 136 FDP_ACM.9 Single Time-based Access Control .............................. 137 FDP_ACM.10 Multiple Time-based Access Control ........................... 137 FDP_ACM.11 Single Location-based Access Control ......................... 138 FDP_ACM.12 Single Location-based Access Control ......................... 139 FDP_IFM Information Flow Control Mechanisms ............................. 140 FDP_IFM.1 Single user-based labels ...................................... 142 FDP_IFM.2 Multiple user-based labels .................................... 142 FDP_IFM.3 Lattice of user-based labels .................................. 143 FDP_IFM.4 Single subject-based labels ................................... 144 FDP_IFM.5 Multiple user-based labels .................................... 145 FDP_IFM.6 Lattice of subject-based labels ............................... 146 D R A F T CCEB-94/083 Table of contents 94/10/31 Version 0.90 Page v of x FDP_IFM.7 Specific Information Flow Limitation .......................... 147 FDP_IFM.8 Global Information Flow Limitation ............................ 148 FDP_SAQ Security Attribute Query ........................................ 148 FDP_SAQ.1 Minimal Attribute Query ....................................... 150 FDP_SAQ.2 Basic Attribute Query ......................................... 150 FDP_SAM Security Attribute Modification ................................. 151 FDP_SAM.1 Minimal Attribute Modification ................................ 153 FDP_SAM.2 Basic Attribute Modification .................................. 153 FDP_SAM.3 Safe Attribute Modification ................................... 154 FDP_SAI Security Attribute Initialisation ............................... 154 FDP_SAI.1 Static Attribute Initialisation ............................... 155 FDP_SAI.2 Minimal Attribute Initialisation .............................. 156 FDP_SAI.3 Basic Attribute Initialisation ................................ 157 FDP_SAI.4 Safe Attribute Initialisation ................................. 157 FDP_ITC Import from Outside TSF Control ................................. 158 FDP_ETC Export to Outside TSF Control ................................... 159 FDP_ITP Information Transfer Protection ................................. 161 FDP_ITP.1 Basic Data Exchange Confidentiality ........................... 163 FDP_ITP.2 Basic Data Exchange Integrity ................................. 164 FDP_ITP.3 Enhanced Data Exchange Integrity .............................. 165 FDP_ITP.4 Basic Data Exchange Integrity and Recovery .................... 166 FDP_ITP.5 Reliable Data Exchange Integrity .............................. 167 FDP_SAC Security Attribute Consistency .................................. 168 FDP_SAC.1 Security Attribute Consistency between TSFs ................... 169 FDP_SAT Security Attribute Transfer ..................................... 170 FDP_SAT.1 Basic Security Attribute Transfer ............................. 171 FDP_SAT.2 Reliable Security Attribute Transfer .......................... 171 Class FRU Resource Utilisation .......................................... 173 FRU_RSA Resource Allocation ............................................. 173 FRU_RSA.1 Simple Quotas ................................................. 175 FRU_RSA.2 Complete Quotas ............................................... 176 FRU_RSA.3 Individual Quotas ............................................. 176 FRU_RSA.4 Complete Individual Quotas .................................... 177 FRU_RSA.5 Complete Resource Control ..................................... 178 FRU_PRS Priority of Service ............................................. 178 FRU_PRS.1 Limited Priority of Service ................................... 180 FRU_PRS.2 Passive Priority of Service ................................... 180 FRU_PRS.3 Pre-emptive Priority of Service ............................... 181 FRU_FLT Fault Tolerance ................................................. 182 FRU_FLT.1 Limited Fault Tolerance ....................................... 182 FRU_FLT.2 Fault Tolerance ............................................... 182 Class FPT Protection of the Trusted Security Functions .................. 183 FPT_SEP Domain Separation ............................................... 184 FPT_SEP.1 TSF Domain Separation ......................................... 185 D R A F T Table of contents CCEB-94/083 Page vi of x Version 0.90 94/10/31 FPT_SEP.2 Separate Reference Validation Mechanism (RVM) Domain .......... 186 FPT_TSA TOE Security Administration ..................................... 187 FPT_TSA.1 Basic Security Administration ................................. 188 FPT_TSA.2 Separate Security Administrative Role ......................... 190 FPT_TSA.3 Multiple Security Administrative Roles ........................ 191 FPT_TSA.4 Well-Defined Administrative Roles ............................. 194 FPT_TSM TOE Security Management ......................................... 196 FPT_TSM.1 Partial Management Functions .................................. 198 FPT_TSM.2 Full Management Functions ..................................... 200 FPT_TSU TOE Administrative Safe Use ..................................... 201 FPT_TSU.1 Enforcement of Administrative Guidance ........................ 202 FPT_TSU.2 Safe Administrative Defaults .................................. 203 FPT_RCV Trusted Recovery ................................................ 204 FPT_RCV.1 Manual Recovery ............................................... 206 FPT_RCV.2 Automated Recovery ............................................ 207 FPT_RCV.3 Automated Recovery without Undo Loss .......................... 208 FPT_RVM Reference Mediation ............................................. 210 FPT_RVM.1 Mediation of a Defined Set of Objects ......................... 211 FPT_RVM.2 Mediation of All Objects ...................................... 213 FPT_RVM.3 Mediation of All Objects and Attributes ....................... 214 FPT_RVM.4 Separate Reference Validation Mechanism ....................... 215 FPT_ITC Inter-TSF Confidentiality of TSF Data ........................... 216 FPT_ITI Inter-TSF Integrity of TSF Data ................................. 216 FPT_ITA Inter-TSF Availability of TSF Data .............................. 217 FPT_SWM TSF Software Modification ....................................... 217 FPT_TST TSF Self Test ................................................... 218 FPT_AMT Underlying Abstract Machine Test ................................ 219 FPT_AMT.1 Periodic Abstract Machine Testing ............................. 220 FPT_AMT.2 Abstract Machine Testing During Start-Up ...................... 221 FPT_AMT.3 Abstract Machine Testing During Normal Operation .............. 222 FPT_FLS Fail-safe ....................................................... 222 FPT_PHP TSF Physical Protection ......................................... 223 FPT_PHP.1 Passive Detection of Physical Attack .......................... 225 FPT_PHP.2 Notification of Physical Attack ............................... 225 FPT_PHP.3 Resistance to Physical Attack ................................. 226 Class FPR Privacy ....................................................... 229 FPR_UNO Unobservability ................................................. 229 FPR_ANO Anonymity ....................................................... 231 FPR_PSE Pseudonymity .................................................... 232 FPR_UNL Unlinkability ................................................... 233 Class FTE Communication ................................................. 235 FTE_NRO Non-Repudiation of Origin ....................................... 235 FTE_NRO.1 Selective Proof of Origin ..................................... 236 FTE_NRO.2 Enforced Proof of Origin ...................................... 237 D R A F T CCEB-94/083 Table of contents 94/10/31 Version 0.90 Page vii of x FTE_NRO.3 Indefinite Proof of Origin .................................... 238 FTE_NRR Non-Repudiation of Receipt ...................................... 238 FTE_NRR.1 Selective Proof of Receipt .................................... 239 FTE_NRR.2 Providing of Basic Proof of Receipt ........................... 240 FTE_NRR.3 Indefinite Proof of Receipt ................................... 241 Chapter 3 Predefined functional packages ................................ 243 Annex A Relationship of CC predefined functional packages to ITSEC, CTCPEC, FC / TCSEC (informative) ................................ 245 D R A F T List of figures CCEB-94/083 Page viii of x Version 0.90 94/10/31 List of figures Figure 1.1 - Diagram of security functional requirements paradigm ......... 3 Figure 2.1 - Sample class decomposition diagram ........................... 9 Figure 2.2 - Identification and Authentication class decomposition ....... 12 Figure 2.3 - Trusted Path class decomposition ............................ 41 Figure 2.4 - Security Audit class decomposition .......................... 54 Figure 2.5 - TOE Entry class decomposition ............................... 80 Figure 2.6 - User Data Protection class decomposition ................... 104 Figure 2.7 - User Data Protection class decomposition (cont.) ........... 105 Figure 2.8 - Resource Utilisation class decomposition ................... 173 Figure 2.9 - Protection of the Trusted Security Functions class decomposition ................................................... 183 Figure 2.10 - Privacy class decomposition ............................... 229 Figure 2.11 - Communication class decomposition ......................... 235 D R A F T CCEB-94/083 List of tables 94/10/31 Version 0.90 Page ix of x List of tables Version D R A F T List of tables CCEB-94/083 Page x of x Version 0.90 94/10/31 D R A F T CCEB-94/083 94/10/31 Version 0.90 Page 1 of 246 Chapter 1 Introduction Editor Note: The Security Functional Requirements in Part 2 do not currently disregard distributed environments. However, the following paradigm discussion is not currently up to date with respect to efforts to include the capability to evaluate distributed environment TOEs. 1.1 Scope 1 Security functional requirements, as defined in this Part 2, are the basis for the security requirements expressed in a Protection Profile (PP) or a Security Target (ST) in terms of functional components and/or packages. These requirements express the desired security behaviour expected of a TOE and are intended to meet the security objectives in the stated threat environment. These requirements express security properties that users can detect by direct interaction with the TOE (i.e. inputs, outputs) or by the TOE's response to stimulus. 2 Security functional components and packages express security requirements intended to counter threats in the operating environment of the TOE. 3 The audience for this part includes consumers, developers, and evaluators of secure IT systems and products. Part 1 chapter 3 provides additional information on the target audience of the CC. In addition, Part 1 section 5.6 provides information on the use of the CC by the target audiences. 4 When selecting components to express requirements to satisfy the Top Level Security Objectives (TLSO) expressed in a PP or ST, consumers may use this part of the Common Criteria (CC). Part 1 chapter 8 provides more detailed information on TLSO and security requirements. 5 Developers, who define the security functions and select the security mechanisms of the TOE, may use this part of the CC to better understand the user requirements. 6 Evaluators should use the functional requirements defined in this part of the CC to verify the security behaviour of the TOE security functions are compliant with the objectives. They will verify if the functions are suitable to counter the threats and determine the dependencies such that a complete set of security functions are chosen to accomplish the desired behaviour. 1.2 Organisation of Part 2 7 Chapter 1 is the introductory material for part 2. D R A F T 1 - Introduction CCEB-94/083 Page 2 of 246 Version 0.90 94/10/31 8 Chapter 2 is the catalogue of CC functional components. 9 Chapter 3 is the catalogue of CC functional packages. 10 Annex A discusses the relationship of the CC functional components and packages to existing criteria, that is CTCPEC, FC/TCSEC, and ITSEC. 11 Those who develop PPs or STs should refer to Part 1 for relevant structures, rules and guidance. - Part 1 annex A defines the terms and concepts used in the CC. - Part 1 annex B defines structure and rules for components. - Part 1 annex D defines structure and rules for packages. - Part 1 annex F defines structure and rules for PPs. - Part 1 annex G defines structure and rules for STs. 1.3 Functional requirements paradigm 12 The purpose of this section is to provide a description of the paradigm used in this Part 2 of the CC in writing the requirements. Figure 1.1, below, provides a diagram of some of the central concepts used. This section is meant to provide descriptive text in support of the definitions in Part 1 annex A; it is not meant to replace or supersede those definitions. Editor Note: There is no specific meaning in the use of different forms or shadowing in the following figure. This will be improved in the next version of the document. D R A F T CCEB-94/083 1 - Introduction 94/10/31 Version 0.90 Page 3 of 246 [Attempt to diagram the relationships elements of the security paradigm described in this section.] Figure 1.1 - Diagram of security functional requirements paradigm 1.3.1 Decomposition of the Target of Evaluation 1.3.1.1 Target of Evaluation 13 The Target of Evaluation (TOE), as defined elsewhere, contains automated resources , possibly including such things as disk storage, devices, processing capability, communications bandwidth, etc. Some of these resources may be structured into active elements, called subjects . Others may be structured into passive elements, called objects . Objects are TOE specific. Objects could for instance be files, channels, queues, or packets. 1.3.1.2 TOE Security Policy 14 There will exist the set of security rules which are enforced within the TOE. These rules are called the TOE Security Policy (TSP). The TSP is the totality of all of the security rules, the completeness of which is a judgement based upon the expected threat environment and any environmental assumptions which are made for the D R A F T 1 - Introduction CCEB-94/083 Page 4 of 246 Version 0.90 94/10/31 TOE. The requirements for a TSP are dependent upon the particulars of the environment and the details of the intended usage. 1.3.1.3 TOE Security Functions 15 Within the TOE there exists the TOE Security Functions (TSF) which is the hardware, software and firmware which are responsible for the enforcement of the TSP. The TSF need not be and is unlikely to be the complete TOE although it could be. 16 The TSF may not implement a complete reference monitor, but rather may rely upon enforcement assumptions about things in the environment. Thus a TSF is not necessarily a complete Trusted Computing Base (TCB). The terms are defined this way in order to ensure that evaluations can be carried out on TOEs which are less than complete systems. 17 If the TSF implements a complete reference monitor then the TSF can also be called a TCB. In order to specify functional requirements for a TCB look to the FPT_SEP Domain Separation and FPT_RVM Reference Mediation families of Part 2. 1.3.1.4 TSF Scope of Control 18 The TSF controls the interactions with and between everything which is within the TSF Scope of Control (TSC), as described in the TSP. The TSC need not be the complete TOE, but any TOE resources which are outside of the TSC will not be protected by the rules in the TSP. 1.3.1.5 TSF Interface 19 The interface through which services and resources are obtained from the TSF is called the TSF Interface (TSFI). 1.3.1.6 Security Function 20 Sometimes there may be a need to levy requirements against a portion of the TOE which implements only a part of the TSP. This can be described as a single Security Function (SF). For example, an access control SF, an I&A SF, etc. 1.3.1.7 Security Function Policy 21 A Security Function Policy (SFP) exists when some subset of the TSF can be identified which has control over enforcement over that subset of the TSP. Arbitrary selections of parts of the TSP do not of necessity make an SFP and it should not be considered to always exist. It may be found to be most useful when describing an access control policy such as for instance a Discretionary Access Control policy, Mandatory Access Control policy, etc. D R A F T CCEB-94/083 1 - Introduction 94/10/31 Version 0.90 Page 5 of 246 1.3.1.8 Security Mechanisms 22 If the requirement is meant to be levied against a specific part of the implementation of the TOE, this part can be called a Security Mechanism (SM), for example an authentication mechanism, or a domain isolation mechanism. Such requirements are designed to constrain the allowable implementation choices for the TOE. 1.3.2 Isolation 23 The primary goal of the TSF is the correct enforcement of the TSP. To this end, some requirements are needed which allow the TSF to identify and bound the things for or against which the enforcement will be levied. 1.3.2.1 Security Attributes 24 In order to perform enforcement, the TSF needs to have sufficient information to make the decisions. Some of this information is the security attributes associated with the objects , subjects , processes or users and may contain such information as an access list, ownership, recipient, resource type, legal access types, etc. This information may also just be stored in a TSF internal resource such as an access rule base. 1.3.2.2 Objects 25 Within the TSC, there will exist resources for which the TSP indicates a set of rules of enforcement of access. A resource or group of resources and its associated security attributes is known as an object . These security attributes may be referred to as object security attributes . 1.3.2.3 Subjects 26 A subject is something active which interacts with the TSF; it may be internal to or external from the TOE but a subject always acts on behalf of a user and is not a part of the TSF. A subject has subject security attributes . Another way of looking at a subject is as the logical representation of a user or process created and maintained by the TSF. 1.3.2.4 Processes 27 Within the TSC, there may exist active resources defined as processes . The TSF will associate needed security attributes and constrain the interactions of these processes in accordance with the TSP. This definition of process is not necessarily the same as the definition of process used in other contexts such a Unix-like operating system. 1.3.2.5 Users 28 Outside of the TSC, there will exist users . Users are active and interact with the TOE through interfaces which form a subset of the TSFI. A user , for the purposes of the CC, is not considered to be able to be constrained other than in his/her ability D R A F T 1 - Introduction CCEB-94/083 Page 6 of 246 Version 0.90 94/10/31 to interact with the TSF and the TSF controlled resources. A user interacting with the TSF is considered to have established a session, although the exact meaning of a session as it pertains to the TOE will be described in the TSP. 29 Some security considerations which can be looked at for a user are the interface to the TSF used (e.g. FTE_MTE Method of Entry) or the security attributes associated with the user for the session (e.g. FTE_MDE Mode of Entry). 1.3.2.6 Session 30 In general, when a user interacts with the TOE, the TSF will need to identify and authenticate the user in some manner and then have a mechanism for ensuring that this identity can be associated with any later activities performed by that user. This is a session . In many cases, once a user has established a session , the TSF will initiate a process acting on behalf of that user . 1.3.2.7 Authorised User 31 An authorised user is a user who has been determined to be able to effect the correct enforcement of some defined policy. This effect could be as global as being the security officer able to override or change any settings of the TSF or it could be as narrow as being authorised to change the security attributes of one or a defined set of objects . When a user is described as " authorised " it is only with respect to the access rights being discussed at the time in that specific requirement and should not be read as implying any global authorisation. In addition, an authorisation of a user may or may not be inherited or inheritable by a process acting on behalf of the user, depending upon other security requirements and the design decision of the TOE developer. 1.3.2.8 Role 32 One way of defining the security attributes of a user might be through a role which defines the user as an authorised user for a set of access rights and in addition defines security attributes which can be used for determining other access rights as access is requested. A role should be considered as a grouping of access rights , authorisations and security attributes which can be created and manipulated independently of any specific user. 1.3.2.9 TSF versus User Data 33 In the TOE, in general there will be two kinds of identifiable data: TSF and user data . The policies applied to each of these will most likely be very different in terms of the enforcement rules. TSF data is critical to the correct operation of the TSF and must be protected against unauthorised modification and possibly even disclosure. User data on the other hand is the data which users of the TOE intend in some manner to process and share within the TOE and possibly share with other users. 34 It may be that for a given TOE, the TSF is built using the same mechanism for protecting TSF data and user data . The policy which applies though should differ D R A F T CCEB-94/083 1 - Introduction 94/10/31 Version 0.90 Page 7 of 246 in terms of who is authorised to Access the data and who can change the access to the data. 35 In the security requirements, TSF data is protected by the TSF protection requirements while user data is protected by the user data protection requirements even though the same mechanism may be implemented to protect both. 1.3.2.10 Security Domain 36 A static set of security attributes in the TSF and a given set of security attributes which have been defined for a subject defines a scope of interaction for the subject , also called for convenience its security domain . For a user, its security domain may be its ability to interact with the processes acting on its behalf, which in turn can access objects. Note that if any security attributes in the TSF change, then this could have an immediate impact on the security domain of any subject , as its possible scope of interaction is affected. 1.3.3 Security enforcement 37 One of the primary goals of IT security enforcement is to enforce the correct separation and sharing of information and resources by users. 38 With respect to processes , this enforcement might be done through the use of, for example, security rings, separate address spaces, virtual processors or distinct physical processors. With respect to a user , the isolation could be defined by the unique and protected association of a process with the communications port the user was authenticated at, cryptographic isolation of incoming packets, the physical location of the user, etc. 39 Security attributes for a subject can be associated with the subject from a static database of security attributes and/or access rights . These security attributes could come from a role definition for a user , a capability list for a process , etc. The security attributes of an object may come from the creating process , from a default for the TOE or for the specific accountable user, etc. A key factor is that the security attributes must be protected from unauthorised modification or they cannot practically be used by the TSF in enforcement. 40 Some users , and possibly processes acting on behalf of the user, may have a security attribute that defines the user as having a specific authorisation to perform an action. Such an authorisation could be as narrow as the ability to change the security attributes of a set of processes or objects, as global as change the system time of day, or the ability to bypass all user data protection mechanisms. 1.3.4 Communications 41 In the day to day operation of the TOE, the TSF will have to communicate with the outside world. D R A F T 1 - Introduction CCEB-94/083 Page 8 of 246 Version 0.90 94/10/31 1.3.4.1 Trusted Path 42 A trusted path provides an assured means of communication between a user and the TSF . The primary purpose of a trusted path is accountability but it can also provide confidentiality , integrity or availability as needed. It can be used at such critical times as authentication where a secret may be exchanged, when an administrative user is changing the security attributes of an object which no process is allowed to alter; etc. 1.3.4.2 Trusted Channel 43 A trusted channel provides an assured means of communication between two TSFs . It is otherwise very similar to a trusted path .. 1.3.4.3 User Data Communications 44 When a user has stored data in a TOE or communicated it to a TOE, it may be necessary for this user data to be securely communicated to another TSF protection from the existing TSF's protection. User data communications covers the protection of user data when it is in communication between TSFs and is not or could not be subject to the security enforcement of one or either TSF. It also covers the correct transfer of the necessary security attributes associated with the user data such that the receiving TSF can correctly continue enforcement of the user data protection policy. 1.3.4.4 Consistency 45 When a TSF is built to work in an interconnected environment, it will be necessary to be able to verify that each of the parts of the system are able to consistently communicate with each other in a manner which allows for correct enforcement of the TSP of the system and also that of each element of the system. D R A F T 10 CCEB-94/083 94/10/31 Version 0.90 Page 9 of 246 Chapter 2 Security functional requirements 46 This chapter reflects the functional requirements expressed in the different source criteria used as the basis for the development of the CC. The current grouping of the components in this section does not reflect any formal taxonomy. 47 In the definition of the behaviour of a functional family, a section exists to identify other functional families which are considered relevant for the understanding of the family behaviour and which offer at least partial coverage of any of the stated threats of the family. This section is only informative. 48 In the definition of the functional components a section has been created to identify the dependencies between this component and any other components. These dependencies reflect a "mandatory aspect" for the satisfaction of the behaviour of this component. 2.1 Component taxonomy 49 Part 2 of the CC contains nine classes of families and components which are rough groupings on the basis of related function or purpose. At the start of each class is a diagram which indicates the component taxonomy of each class indicating the families in each class and the components in each family. The diagram is a useful indicator of the hierarchical relationships which exist between components. Class Name | | - Family 1 - 1 - 2 - 3 | | 1 | - Family 2 < | 2 - 3 | | 2 | - Family 3 - 1 < > 4 3 Figure 2.1 - Sample class decomposition diagram 50 In Fig. 2.1, above, the class as shown contains three families. The first family, Family 1, contains three hierarchical components where component 2 and component 3 can both be used to meet dependencies on component 1. Component D R A F T 2 - Security functional requirements CCEB-94/083 Page 10 of 246 Version 0.90 94/10/31 3 is hierarchical to component 2 and can also be used to meet dependencies on component 2. 51 In Family 2, there are three components but they are not all hierarchical. Components 1 and 2 are hierarchical to no other components. Component 3 is hierarchical component 2 and can be used to meet dependencies on component 2. 52 In Family 3, all of components 2, 3 and 4 are hierarchical to component 1. Components 2 and 3 are non-comparable. Component 4 is hierarchical to component 2 and component 3 as well. 53 These diagrams are meant to complement the text of the families and make figuring out the relationships more visual. They do not completely replace the "Hierarchical to:" note in each component. For instance, in the creation of a security target new security functional requirements might be developed which are to be used to meet an existing dependency and subject to the evaluation the new requirements might be hierarchical to the existing dependency but there is no mechanism for the modification of the diagram. 2.2 Threats mapping and risk analysis Editor Note: As we have to develop a taxonomy for the components and component families, it should be useful to develop a taxonomy for the threats addressed by the components, to allow a mapping between threats and components. 54 2.3 Components relationship 55 D R A F T CCEB-94/083 94/10/31 Version 0.90 Page 11 of 246 Class FIA Identification and Authentication 56 A common security requirement is the need to control the access of users to the TOE. This involves not only establishing the claimed identity of a user, but also verifying that the user is indeed the user claimed. This is done by the user providing the TSF with some information that is known by the TSF to be associated with the user in question. 57 Families in this class address the requirements for functions to establish and verify a claimed identity. 58 Identification and Authentication is required to ensure that users are associated with the proper Security Attributes (e.g., identity, groups, roles, security or integrity levels, time intervals, location). 59 The unambiguous identification of authorised users and the correct association of security attributes with users is critical to the enforcement of the intended security policies. The families in this class deal with determining the identity of users, determining their authority to interact with the TOE, and with the correct association of security attributes for each authorised user. D R A F T FIA_ATD - User Attribute Definition Identification and Authentication Page 12 of 246 CCEB-94/083 Version 0.90 94/10/31 60 Identification and Authenticaion | | - FIA_ATD - 1 - 2 | | - FIA_ATA - 1 - 2 - 3 | | - FIA_ATP - 1 | | - FIA_ATC - 1 | | - FIA_USB - 1 | | - FIA_UID - 1 - 2 | | 1 - 2 - 3 - 4 | / | - FIA_UAU <- 5 - 6 | \ | 7 | | - FIA_ADP - 1 - 2 | | - FIA_AAA - 1 - 2 - 3 | | 1 | - FIA_SOS < 2 Figure 2.2 - Identification and Authentication class decomposition FIA_ATD User Attribute Definition Family behaviour 61 All authorised users may have a set of security attributes, separate from the user's identity, that are used to enforce the TSP. This family defines the requirements for associating user security attributes with users as needed to support the TSP. Threats 62 This family addresses the threats preventing correct application of the TSP caused by inappropriate definition of user security attributes. D R A F T Identification and Authentication FIA_ATD - User Attribute Definition 94/10/31 CCEB-94/083 Version 0.90 Page 13 of 246 Other relevant families 63 All Security Policy management families 64 FIA_ATA User Attribute Administration Component levelling 65 This family is levelled based on the granularity at which user security attributes are associated with users. 66 The first component, FIA_ATD.1 Minimal User Attribute Definition, allows user security attributes to be associated with a group of users. 67 The second component, FIA_ATD.2 Basic User Attribute Definition, requires that user security attributes be uniquely associated with each individual user. Application Notes User Application Notes 68 There are obvious dependencies on the individual security policy definitions. These individual definitions should contain the listing of attributes that are necessary for policy enforcement. Documentation 69 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the user-related TSP attributes and the manner in which they are associated with the user. [ADV_FSP Functional specification] FIA_ATD.1 Minimal User Attribute Definition Hierarchical to: no other components. Component rationale and application notes User Application Notes 70 At this component level it is acceptable for more than one user to share the same association with TSP attributes. Operations No permitted operation. D R A F T FIA_ATA - User Attribute Administration Identification and Authentication Page 14 of 246 CCEB-94/083 Version 0.90 94/10/31 Dependencies: FIA_UID.1 Basic User Identification ADV_FSP.2 Informal security policy model Elements: FIA_ATD.1.1 The TSF shall maintain an association between each user and the user security attributes necessary to enforce the TSP. FIA_ATD.2 Basic User Attribute Definition Hierarchical to: FIA_ATD.1 Component rationale and application notes User Application Notes 71 At this component level it is not acceptable for more than one user to share the same association with TSP attributes. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users ADV_FSP.2 Informal security policy model Elements: FIA_ATD.2.1 The TSF shall maintain a unique association between each user and the user security attributes necessary to enforce the TSP. FIA_ATA User Attribute Administration Family behaviour 72 All authorised users have a set of security attributes to support the enforcement of the TSP. This family defines the requirements to initially set up, change, or review the user's security attributes. This family defines requirements to enable new user identities to be added, and old user identities to be removed or invalidated. Threats 73 This family addresses the threats preventing correct set-up of user security attributes. D R A F T Identification and Authentication FIA_ATA - User Attribute Administration 94/10/31 CCEB-94/083 Version 0.90 Page 15 of 246 74 This family addresses the threat of uncontrolled modification of user security attributes. 75 This family addresses the threat of use of obsolete user security attribute values. Other relevant families 76 FIA_ATD User Attribute Definition 77 FDP_SAI Security Attribute Initialisation 78 FDP_SAM Security Attribute Modification 79 FDP_SAQ Security Attribute Query 80 FPT_TSA TOE Security Administration 81 FPT_TSM TOE Security Management 82 FPT_TSU TOE Administrative Safe Use Component levelling 83 The levelling of this family is based on increased functional scope and coverage. 84 The first component, FIA_ATA.1 User Security Attribute Initialisation, only requires that the TSF provide the ability to initialise user security attributes. 85 The second component, FIA_ATA.2 Basic User Security Attribute Administration, requires that the TSF provide the ability to initialise, query and modify user security attributes. 86 The third component, FIA_ATA.3 Role Based User Security Attribute Administration, introduces the role of a User Attribute Administrator. Application Notes Audit 87 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the user security attribute administration functions. b) Basic: All attempted uses of the user security attribute administration functions. D R A F T FIA_ATA - User Attribute Administration Identification and Authentication Page 16 of 246 CCEB-94/083 Version 0.90 94/10/31 c) Basic: Identification of which user security attributes have been modified. d) Detailed: With the exception of specific sensitive attribute data items (e.g., passwords, cryptographic keys), the new values of the attributes must be captured. Documentation 88 The indicated assurance documentation (if applicable) shall contain the following information: a) Guidance on how to use the TSF provided functions related to user security attributes. [AGD_USR User guidance]. b) Guidance on how to use the TSF provided user security attribute administration functions. [AGD_ADM Administrator guidance]. c) Specification of the TSF provided user security attribute administration functions. [ADV_HLD High-level design, ADV_FSP Functional specification]. FIA_ATA.1 User Security Attribute Initialisation Hierarchical to: no other components. Component rationale and application notes 89 At this level, the TSF must provide a mechanism to initialise user security attributes and default values for these attributes. Documentation 90 In addition to the documentation requirements specified at the family level, this component requires that the indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the default values for user security attributes [ADV_FSP Functional specification]. Operations No permitted operation. Dependencies: ADV_FSP.2 Informal security policy model FIA_ATD.1 Minimal User Attribute Definition FPT_TSA.1 Basic Security Administration FDP_SAI.1 Static Attribute Initialisation D R A F T Identification and Authentication FIA_ATA - User Attribute Administration 94/10/31 CCEB-94/083 Version 0.90 Page 17 of 246 Elements: FIA_ATA.1.1 The TSF shall provide default values for user security attributes to be used when initialising attributes for a user. FIA_ATA.2 Basic User Security Attribute Administration Hierarchical to: FIA_ATA.1 Component rationale and application notes User Application Notes 91 At this level, the TSF must provide a mechanism to allow the display and modification of user security attributes. Operations No permitted operation. Dependencies: ADV_FSP.2 Informal security policy model FIA_ATD.1 Minimal User Attribute Definition FDP_SAI.1 Static Attribute Initialisation FDP_SAQ.1 Minimal Attribute Query FDP_SAM.1 Minimal Attribute Modification FPT_TSA.2 Separate Security Administrative Role Elements: FIA_ATA.2.1 The TSF shall provide default values for user security attributes to be used when initialising attributes for a user. FIA_ATA.2.2 The TSF shall provide the ability to display user security attributes. FIA_ATA.2.3 The TSF shall provide the ability to modify user security attributes. FIA_ATA.3 Role Based User Security Attribute Administration Hierarchical to: FIA_ATA.2 Component rationale and application notes User Application Notes 92 At this level, the TSF must provide a User attribute administrator role to initialise, display or modify user security attributes. D R A F T FIA_ATP - User Attribute Protection Identification and Authentication Page 18 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations No permitted operation. Dependencies: ADV_FSP.2 Informal security policy model FIA_ATD.1 Minimal User Attribute Definition FDP_SAI.1 Static Attribute Initialisation FDP_SAQ.1 Minimal Attribute Query FDP_SAM.1 Minimal Attribute Modification FPT_TSA.3 Multiple Security Administrative Roles Elements: FIA_ATA.3.1 The TSF shall provide default values for user security attributes to be used when initialising attributes for a user. FIA_ATA.3.2 The TSF shall provide the ability to display user security attributes. FIA_ATA.3.3 The TSF shall provide the ability to modify user security attributes. FIA_ATA.3.4 The TSF shall provide a User Attribute Administrator Role which is limited to performing only those activities directly associated with user security attribute administration. FIA_ATP User Attribute Protection Family behaviour 93 This family defines the requirements to protect the user's security attributes, in any form, within the TSF boundary. This family defines the differences between authorised access (using administration requirements), and unauthorised access. Threats 94 This family addresses the threat of unauthorised access to the user's security attribute definitions stored in the TOE. 95 This family addresses the threat of unauthorised access to the user's security attributes associated with a user's session. 96 This family addresses the threat of unauthorised access to the user's security attributes associated with subjects acting on behalf of the user. D R A F T Identification and Authentication FIA_ATP - User Attribute Protection 94/10/31 CCEB-94/083 Version 0.90 Page 19 of 246 Other relevant families 97 FIA_ATC User Attribute Consistency 98 FIA_USB User-Subject Binding 99 FIA_ADP User Authentication Data Protection 100 Access Control Policies Component levelling 101 There is only one component in this family. 102 FIA_ATP.1 User Attribute Protection requires that the TSF provide mechanisms to prevent the unauthorised use of user security attributes. Application Notes Audit 103 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Basic: All attempts by unauthorised users to use, observe, modify, or destroy user attributes. Documentation 104 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF protects the user security attributes in accordance with the TSP. [ADV_FSP Functional specification] FIA_ATP.1 User Attribute Protection Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition FIA_ATA.1 User Security Attribute Initialisation D R A F T FIA_ATC - User Attribute Consistency Identification and Authentication Page 20 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FIA_ATP.1.1 The TSF shall protect user security attributes from unauthorised use, observation, modification, and destruction. FIA_ATC User Attribute Consistency Family behaviour 105 The security attributes attached to a subject could be transmitted to a different TSF, applying the same security policy, but with a different interpretation of the user's security attributes. This family defines the requirements to enforce a consistent mapping of any relevant user security attributes transmitted between different TSFs. Threats 106 This family addresses the threats of inconsistent interpretation of user security attributes between TSFs. Other relevant families 107 FIA_ATD User Attribute Definition Component levelling 108 There is only one component in this family. 109 FIA_ATC.1 User Attribute Consistency between TSFs, requires that the TSF provide mechanisms to provide consistency of attributes between TSFs. Application Notes Evaluator's application notes 110 User attributes in the context of this family refer to both the security attributes as specified in FIA_ATD User Attribute Definition and the authentication-related TSP attributes as specified in FIA_AAA User Authentication Attribute Administration. Audit 111 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of user security attribute consistency mechanisms. b) Basic: Any use of the user security attribute consistency mechanisms. D R A F T Identification and Authentication FIA_USB - User-Subject Binding 94/10/31 CCEB-94/083 Version 0.90 Page 21 of 246 c) Basic: Identification of which user security attributes have been interpreted. d) Detailed: Capture of the actual values of each user security attribute. Documentation 112 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF maintains consistency of user attributes within a single security domain. [ADV_FSP Functional specification] FIA_ATC.1 User Attribute Consistency between TSFs Hierarchical to: no other components. Component rationale and application notes User Application Notes 113 The TSF is responsible for maintaining the consistency of attributes associated with users that are common between two or more TSFs. Operations No permitted operation. Dependencies: FIA_ATD User Attribute Definition Elements: FIA_ATC.1.1 The TSF shall provide the capability to allow the consistent interpretation of user security attributes transmitted between TSFs. FIA_USB User-Subject Binding Family behaviour 114 An authenticated user, to perform an action in the TOE, typically activates a subject. The user's security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user's security attributes to a subject acting on the user's behalf. D R A F T FIA_USB - User-Subject Binding Identification and Authentication Page 22 of 246 CCEB-94/083 Version 0.90 94/10/31 Threats 115 This family addresses the threat of misuse of the user's security attributes attached to a subject, (i.e., by unexpected or incorrect association of inappropriate user security attributes). 116 This family addresses the threat of loss of user's security attributes associated with a subject. Other relevant families FIA_ATP User Attribute Protection FIA_ATC User Attribute Consistency FIA_ATD User Attribute Definition Component levelling 117 There is only one component in this family. 118 FIA_USB.1 User-Subject Binding requires the maintenance of an association between the user's security attributes and a subject acting on the user's behalf. Application Notes User Application Notes 119 There are obvious dependencies on the individual security policy definitions. These individual definitions should contain the listing of the user security attributes that should be bound to subjects. That listing does not go here. Audit 120 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful binding of user security attributes to a subject (i.e., creation of a subject). b) Basic: Success and failure of binding of user security attributes to a subject (e.g., success and failure to create a subject). Documentation 121 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which user attributes are associated with subjects they own. [ADV_FSP Functional specification] D R A F T Identification and Authentication FIA_UID - User Identification 94/10/31 CCEB-94/083 Version 0.90 Page 23 of 246 FIA_USB.1 User-Subject Binding Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition ADV_FSP.2 Informal security policy model Elements: FIA_USB.1.1 The TSF shall associate, in accordance with the TSP, the appropriate user security attributes with subjects acting on behalf of that user. FIA_UID User Identification Family behaviour 122 This family defines the conditions under which users shall be required to identify themselves before beginning to perform any other actions that are to be mediated by the TSF. This family defines the requirements that pertain to user identification functions. Threats 123 This family addresses the threat of unidentified users obtaining access to TOE resources. Other relevant families 124 FIA_ATD User Attribute Definition 125 FIA_UAU User Authentication Component levelling 126 This family is levelled based on increased granularity of user identification. 127 In the first component, FIA_UID.1 Basic User Identification, users are allowed to share the same user identity. 128 In the second component, FIA_UID.2 Unique Identification of Users, each user must have a unique identity. D R A F T FIA_UID - User Identification Identification and Authentication Page 24 of 246 CCEB-94/083 Version 0.90 94/10/31 Application Notes User Application Notes Audit 129 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the user identification mechanism. b) Minimal: Identification of the user identity provided. c) Basic: All attempts to use the user identification mechanism. Documentation 130 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the user identification function. [ADV_FSP Functional specification] b) Guidance to users on how to identify themselves to the TOE. [AGD_USR User guidance] c) Guidance on configuring the TOE identification mechanism. [AGD_ADM Administrator guidance] FIA_UID.1 Basic User Identification Hierarchical to: no other components. Component rationale and application notes User Application Notes 131 In this component, it is acceptable for more than one user to share the same identity. This component is always needed. It provides the basic component of user identification needed in order for a security policy to be implemented. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition D R A F T Identification and Authentication FIA_UAU - User Authentication 94/10/31 CCEB-94/083 Version 0.90 Page 25 of 246 Elements: FIA_UID.1.1 For all users, the TSF shall identify the user before performing any TSF mediated actions on behalf of that user. FIA_UID.2 Unique Identification of Users Hierarchical to: FIA_UID.1 Component rationale and application notes User Application Notes 132 In this component, users can not share the same identity. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition Elements: FIA_UID.2.1 For all users, the TSF shall uniquely identify the user before performing any TSF mediated actions on behalf of that user. FIA_UAU User Authentication Family behaviour 133 This family defines the types of users which shall be authenticated and the types of authentication supported. This family defines the required attributes of user authentication functions and mechanisms. This family defines requirements for mechanisms to enforce limits on attempts to establish a false identity. Threats 134 This family addresses the threat of unauthorised impersonation of a user's identity. 135 This family addresses the threat of unauthorised use of TOE resources before the claimed user identity is validated. 136 This family addresses the threat of replay of authentication data to gain unauthorised access. D R A F T FIA_UAU - User Authentication Identification and Authentication Page 26 of 246 CCEB-94/083 Version 0.90 94/10/31 137 This family addresses the threat that an authenticated user can disclaim responsibility for an authenticated access. 138 This family addresses the threat of a user's authenticated session being taken over by another user. 139 This family addresses the threat of inadequate authentication being available to counter a changing threat environment. Other relevant families FIA_UID User Identification FIA_ATD User Attribute Definition Component levelling 140 The levelling of the first four components is hierarchical and based on increased coverage of the threats addressed by the family. Two additional hierarchical components are levelled based on scope and cover the existence of two or more authentication mechanisms. A seventh component is completely non- hierarchical. 141 The first component, FIA_UAU.1 Basic User Authentication, includes only minimal forms of individual user authentication, and is intended for use in products that will have limited exposure to authentication-based attacks. 142 The second component, FIA_UAU.2 Single-use Authentication Mechanisms, requires an authentication mechanism which operates with single-use authentication data. 143 The third component, FIA_UAU.3 On-demand Authentication, requires that the TSF be able to re-authenticate the user at times after initial login. 144 The fourth component, FIA_UAU.4 Non-repudiation of Authentication, requires the authentication mechanism to be able to provide proof of successful authentication. 145 The fifth component, FIA_UAU.5 Multiple Authentication Mechanisms, requires that two or more authentication mechanisms be provided and used to authenticate user identities. 146 The sixth component, FIA_UAU.6 Policy-based Authentication Mechanisms, requires the ability to specify separate authentication mechanisms for specific security attributes. 147 The seventh component, FIA_UAU.7 Installable Authentication Mechanisms, requires an interface to support the installation of new authentication mechanisms. D R A F T Identification and Authentication FIA_UAU - User Authentication 94/10/31 CCEB-94/083 Version 0.90 Page 27 of 246 Editor Note: It is recognised that components for authentication data lifetimes and limits on repeated unsuccessful authentication attempts are needed as components in this family. Application Notes User Application Notes 148 The Multiple Authentication Mechanisms and Policy-based Authentication Mechanisms components require the selection of two or more of the first four components from within this family. It is possible that the same component could be selected twice, but in doing so it would have to be selected twice with respect to two different security functions within the TOE. 149 The Installable Authentication Mechanisms component can be combined with any other component from this family. Audit 150 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the authentication mechanism. b) Basic: Any use of the authentication mechanism. Documentation 151 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the TSF authentication mechanism(s). [ADV_FSP Functional specification] b) Guidance on use of the TSF authentication mechanism(s). [AGD_USR User guidance] c) Guidance on configuring the TSF authentication mechanism(s). [AGD_ADM Administrator guidance] FIA_UAU.1 Basic User Authentication Hierarchical to: no other components. Operations No permitted operation. D R A F T FIA_UAU - User Authentication Identification and Authentication Page 28 of 246 CCEB-94/083 Version 0.90 94/10/31 Dependencies: FIA_UID.1 Basic User Identification Elements: FIA_UAU.1.1 The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.1.2 The TSF shall perform this authentication before performing any other TSF mediated actions on behalf of the user. FIA_UAU.2 Single-use Authentication Mechanisms Hierarchical to: FIA_UAU.1 Component rationale and application notes User Application Notes 152 Single-use authentication data can be such things as single-use passwords, encrypted time-stamps, random numbers from a secret lookup table, etcetera. Operations No permitted operation. Dependencies: FIA_UID.1 Basic User Identification Elements: FIA_UAU.2.1 The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.2.2 The TSF shall perform this authentication before performing any other TSF mediated actions on behalf of the user. FIA_UAU.2.3 The authentication mechanism provided by the TSF shall prevent reuse of authentication data. D R A F T Identification and Authentication FIA_UAU - User Authentication 94/10/31 CCEB-94/083 Version 0.90 Page 29 of 246 FIA_UAU.3 On-demand Authentication Hierarchical to: FIA_UAU.2 Component rationale and application notes User Application Notes 153 This component addresses potential needs to re-authenticate users at TSP defined points in time. These may include user requests for the TSF to perform security relevant actions, as well as requests from non-TSF entities for re-authentication. Operations Assignment: 154 A list of conditions under which the TSF shall require users to re authenticate themselves must be provided by the PP/ST writer. Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication Elements: FIA_UAU.3.1 The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.3.2 The TSF shall perform this authentication before performing any other TSF mediated actions on behalf of the user. FIA_UAU.3.3 The authentication mechanism shall prevent reuse of authentication data. FIA_UAU.3.4 The TSF shall provide the ability to re-authenticate users under the following circumstances: [list of conditions requiring re-authentication]. FIA_UAU.4 Non-repudiation of Authentication Hierarchical to: FIA_UAU.3 Component rationale and application notes User Application Notes 155 An authentication mechanism which is not subject to repudiation is one where it can be demonstrated that the authentication data used by a user could not have been forged by or copied from any other user including trusted users of the TOE. D R A F T FIA_UAU - User Authentication Identification and Authentication Page 30 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations No permitted operation. Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication Elements: FIA_UAU.4.1 The TSF shall provide a mechanism to authenticate any user's claimed identity. FIA_UAU.4.2 The TSF shall perform this authentication before performing any other TSF mediated actions on behalf of the user. FIA_UAU.4.3 The authentication mechanism shall prevent reuse of authentication data. FIA_UAU.4.4 The TSF shall provide the ability to re-authenticate users in accordance with the TSP. FIA_UAU.4.5 The TSF shall ensure that no user can disclaim responsibility for a successful authentication. FIA_UAU.5 Multiple Authentication Mechanisms Hierarchical to: no other components. Component rationale and application notes User Application Notes 156 The use of this component allows specification of requirements for more than one authentication mechanism. For each separate mechanism, requirements must be chosen from components FIA_UAU.1 through FIA_UAU.4 to be applied to each mechanism. Additional refinements could be used to further restrict the requirements for each mechanism. Operations Assignment: 157 In FIA_UAU.5.1, define the actual number of required mechanisms. Selection: 158 In FIA_UAU.5.1, for each of the required authentication mechanisms, choose the requirements from: - FIA_UAU.1 Basic User Authentication D R A F T Identification and Authentication FIA_UAU - User Authentication 94/10/31 CCEB-94/083 Version 0.90 Page 31 of 246 - FIA_UAU.2 Single-use Authentication Mechanisms Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication FIA_UAU.7 Installable Authentication Mechanisms Elements: FIA_UAU.5.1 The TSF shall provide [ number ] different types of mechanisms to authenticate any user's claimed identity. FIA_UAU.5.2 The TSF shall, by default, use all of these mechanisms to authenticate any user's claimed identity before performing any other TSF- mediated actions on behalf of the user, with authentication being successful if and only if all mechanisms individually indicate successful authentication. FIA_UAU.6 Policy-based Authentication Mechanisms Hierarchical to: FIA_UAU.5 Component rationale and application notes User Application Notes 159 This component requires that a policy be defined which describes when each of the required authentication mechanisms shall be employed with respect to specific security attributes. Operations Assignment: 160 In FIA_UAU.6.1, define the actual number of required mechanisms. Selection: 161 In FIA_UAU.6.2, for each of the required authentication mechanisms, choose the requirements from: - FIA_UAU.1 Basic User Authentication - FIA_UAU.2 Single-use Authentication Mechanisms - FIA_UAU.7 Installable Authentication Mechanisms Refinement: 162 In FIA_UAU.6.2, define which mechanism will be used for which security attributes. D R A F T FIA_UAU - User Authentication Identification and Authentication Page 32 of 246 CCEB-94/083 Version 0.90 94/10/31 Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication FIA_UAU.7 Installable Authentication Mechanisms Elements: FIA_UAU.6.1 The TSF shall provide [ number ] different types of mechanisms to authenticate any user's claimed identity. FIA_UAU.6.2 The TSF shall enforce the use of separate authentication mechanisms for specific security attributes before performing any other TSF- mediated actions on behalf of the user, with authentication being successful if and only if all of the defined mechanisms individually indicate successful authentication. FIA_UAU.7 Installable Authentication Mechanisms Hierarchical to: no other components. Component rationale and application notes User Application Notes 163 This component is intended to allow the installation of additional authentication mechanisms, such as token-based cards, biometrics, or other trusted third-party mechanisms. Operations Selection: 164 In FIA_UAU.7.2, the PP or ST writer must specify whether the installable mechanism is to be in addition to, or as a replacement for, any existing authentication mechanism. Dependencies: FIA_UID.1 Basic User Identification FIA_AAA.1 Minimal User Authentication Attribute Administration Elements: FIA_UAU.7.1 The TSF shall provide an interface to an administrator for the incorporation of installable authentication mechanisms into the TSF. FIA_UAU.7.2 The TSF shall be able to use the installed authentication mechanism: a) in place of, or D R A F T Identification and Authentication FIA_ADP - User Authentication Data Protection 94/10/31 CCEB-94/083 Version 0.90 Page 33 of 246 b) in addition to an existing authentication mechanism. FIA_ADP User Authentication Data Protection Family behaviour 165 To establish the claimed identity of a user, the TOE will use information provided by the user, and known by the TOE to be associated with the user in question. This family defines the requirements to protect the user authentication data against unauthorised access or modification. It includes requirements to assure the integrity of, or prevent the unauthorised use of, authentication information. Threats 166 This family addresses the threat of unauthorised modification of the user's authentication data. 167 This family addresses the threat of unauthorised access to the user's authentication data stored in the TSF, to protect the confidentiality of this information. 168 This family addresses the threat of unauthorised access to the user's authentication data exchanged between the user and the TSF, to protect the confidentiality of this information. Other relevant families FTP_TRP Trusted Path FIA_ATP User Attribute Protection Access Control Policies Component levelling 169 The levelling of this family is based on an increased scope for the protection of user authentication data. 170 The first component, FIA_ADP.1Basic User Authentication Data Protection, provides protection of the authentication data only while it is stored on the TOE. 171 The second component, FIA_ADP.2Extended User Authentication Data Protection, provides additional protection of the authentication data while it is in transit between the user and the TSF. D R A F T FIA_ADP - User Authentication Data Protection Identification and Authentication Page 34 of 246 CCEB-94/083 Version 0.90 94/10/31 Application Notes Audit 172 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful attempts to access user authentication data. b) Basic: All attempts by an unauthorised user to access user authentication data. Documentation 173 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner is which the user authentication data is protected from unauthorised use, observation, modification and destruction while the authentication data is stored in the TSF. [ADV_FSP Functional specification] FIA_ADP.1 Basic User Authentication Data Protection Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_UAU.1 Basic User Authentication Elements: FIA_ADP.1.1 The TSF shall protect the stored authentication data from unauthorised use, observation, modification and destruction. FIA_ADP.2 Extended User Authentication Data Protection Hierarchical to: FIA_ADP.1 Component rationale and application notes User Application Notes 174 Protection of the authentication data while it is transit can be accomplished several ways, including trusted path (FTP_TRP Trusted Path), encryption, or use of an inter TSF trusted channel. D R A F T Identification and Authentication FIA_AAA - User Authentication Attribute 94/10/31 CCEB-94/083 Version 0.90 Page 35 of 246 Documentation 175 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the user authentication data is protected from unauthorised use, observation, modification and destruction at all times while it is in the TSF . [ADV_FSP Functional specification] Operations No permitted operation. Dependencies: FIA_UAU.1 Basic User Authentication Elements: FIA_ADP.2.1 The TSF shall protect the stored authentication data from unauthorised use, access, modification and destruction. FIA_ADP.2.2 The TSF shall protect the authentication data from unauthorised use, observation, modification and destruction at all times while the authentication data resides in the TSF . FIA_AAA User Authentication Attribute Administration Family behaviour 176 Authorisation to access the TOE is managed through the Identification and Authentication Policy. This family defines requirements for new authentication attributes to be attached, removed, or inspected by an authorised user. This family defines requirements for the set-up of any authentication security policy attributes. Threats 177 This family addresses the threat of access to the TOE by an unauthorised user. 178 This family addresses the threat of unauthorised modification of a user's authentication attributes. 179 This family addresses the threat of unauthorised modification of the authentication policy attributes. Other relevant families FIA_ATA User Attribute Administration D R A F T FIA_AAA - User Authentication Attribute Administration Identification and Page 36 of 246 CCEB-94/083 Version 0.90 94/10/31 FIA_UAU User Authentication FPT_TSA TOE Security Administration Component levelling 180 This family is levelled based on the definition of the user authorised to manage the authentication attributes. 181 In the first component, FIA_AAA.1 Minimal User Authentication Attribute Administration, only a security administrator is allowed to manage the data. 182 In the second component, FIA_AAA.2 Basic User Authentication Attribute Administration, users are allowed to manage their own authentication attributes, 183 In the third component, FIA_AAA.3 Role-based User Authentication Attribute Administration, the Authentication Administrator role is introduced to manage the authentication attributes for all users. Application Notes Audit 184 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of any TSF authentication attribute management mechanisms. b) Basic: Any attempts to use TSF authentication attribute management mechanisms. c) Basic: Identification of which user authentication attributes have been modified d) Detailed: With the exception of specific sensitive attribute data items (e.g., passwords, cryptographic keys), the new values of the authentication attributes must be captured. Documentation 185 The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the TSF authentication attribute administration mechanism. [ADV_FSP Functional specification] b) Guidance for users on using the TSF authentication attribute administration mechanism. [AGD_USR User guidance] D R A F T Identification and Authentication FIA_AAA - User Authentication Attribute 94/10/31 CCEB-94/083 Version 0.90 Page 37 of 246 c) Guidance on using the TSF authentication attribute administration mechanism. [AGD_ADM Administrator guidance] FIA_AAA.1 Minimal User Authentication Attribute Administration Hierarchical to: no other components. Component rationale and application notes 186 In this component, only security administrators are permitted to display or modify user authentication attributes. Operations No permitted operation. Dependencies: FPT_TSA.2 Separate Security Administrative Role FIA_ADP.1 Basic User Authentication Data Protection FIA_UAU.1 Basic User Authentication Elements: FIA_AAA.1.1 The TSF shall provide functions for displaying and modifying user authentication attributes. FIA_AAA.1.2 The TSF shall restrict use of these functions to security administrators. FIA_AAA.2 Basic User Authentication Attribute Administration Hierarchical to: FIA_AAA.1 Component rationale and application notes User Application Notes 187 This component can be used to permit users to view and modify some of their own authentication attributes (e.g., typically only passwords). Operations No permitted operation. Dependencies: FPT_TSA.2 Separate Security Administrative Role FIA_ADP.1 Basic User Authentication Data Protection FIA_UAU.1 Basic User Authentication D R A F T FIA_AAA - User Authentication Attribute Administration Identification and Page 38 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FIA_AAA.2.1 The TSF shall provide functions for displaying and modifying user authentication attributes. FIA_AAA.2.2 The TSF shall restrict full use of these functions to security administrators. FIA_AAA.2.3 The TSF shall allow users to display and modify their own user authentication attributes in accordance with the TSP. FIA_AAA.3 Role-based User Authentication Attribute Administration Hierarchical to: FIA_AAA.2 Component rationale and application notes User Application Notes 188 This component should be used when multiple security administrative roles are defined. 189 This component introduces the concept of a User Authentication Attribute Administrator. Operations No permitted operation. Dependencies: FIA_ADP.1 Basic User Authentication Data Protection FIA_UAU.1 Basic User Authentication FPT_TSA.3 Multiple Security Administrative Roles Elements: FIA_AAA.3.1 The TSF shall provide functions for displaying and modifying user authentication attributes. FIA_AAA.3.2 The TSF shall restrict full use of these functions to security administrators. FIA_AAA.3.3 The TSF shall allow users to display and modify their own user authentication attributes in accordance with the TSP. FIA_AAA.3.4 The TSF shall provide an Authentication Attribute Administrator Role which is limited to performing only those activities directly associated with authentication attribute administration. D R A F T Identification and Authentication FIA_SOS - Selection of Secrets 94/10/31 CCEB-94/083 Version 0.90 Page 39 of 246 FIA_SOS Selection of Secrets Family behaviour 190 This family defines requirements for mechanisms which enforce quality of secrets. For example, user supplied password checking, password generator output, etc. Threats 191 This family addresses the threat that secrets supplied to or generated by the TSF will in some way weaken the strength of the functions relying upon these secrets. 192 This family addresses the threat that secrets supplied to or generated for one purpose will accidentally or deliberately be used for a different purpose. Other relevant families FIA_UAU User Authentication Component levelling 193 There are two non-hierarchical components in this family. 194 FIA_SOS.1 Basic selection of Secrets requires the TSF to verify that secrets meet defined quality metrics. 195 FIA_SOS.2 TSF Generation of Secrets requires the TSF to be able to generate secrets that meet defined quality metrics. Application Notes User Application Notes Audit 196 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Rejection by the TSF of any tested secret. b) Basic: Rejection or acceptance by the TSF of any tested secret. c) Detailed: Identification of any changes to the defined quality metrics. D R A F T FIA_SOS - Selection of Secrets Identification and Authentication Page 40 of 246 CCEB-94/083 Version 0.90 94/10/31 FIA_SOS.1 Basic selection of Secrets Hierarchical to: no other components. Operations Refinement: 197 The PP or ST writer must provide a defined quality metric to be used in FIA_SOS.1.1 Dependencies: No dependencies. Elements: FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [ a defined quality metric ]. FIA_SOS.2 TSF Generation of Secrets Hierarchical to: no other components. Component rationale and application notes User Application Notes 198 Public information includes such things as publicly available information associated with a user (e.g., user name) and system dictionaries. Operations Refinement: 199 The PP or ST writer must provide a defined quality metric to be used in FIA_SOS.2.1. Dependencies: No dependencies. Elements: FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet [a defined quality metric]. D R A F T CCEB-94/083 94/10/31 Version 0.90 Page 41 of 246 Class FTP Trusted Path 200 Users often need to perform functions through direct interaction with the TSF. A trusted path ensures that a user is communicating directly with the TSF both at initial login and at later times during a user's session. Trusted path exchanges may be initiated by a user or the TSF. A user's response via the trusted path guarantees that untrusted applications cannot intercept or modify the user's response. 201 Absence of a trusted path may allow breaches of accountability or access control in environments where untrusted applications are used. These applications can intercept user-private information, such as passwords, and use it to impersonate other legitimate users. As a consequence, responsibility for any system actions cannot be reliably assigned to an accountable entity. Also, these applications could output erroneous information on an unsuspecting user's display, resulting in subsequent user actions that may be erroneous and may lead to a security breach. 202 The primary use of a trusted path is to ensure that authentication information is protected at all times when supplied by a user. Trusted Path | | 1 | - FTP_TRP < > 3 | 2 | | 1 | - FTP_ITP < > 3 | 2 | | - FTP_ITC - 1 Figure 2.3 - Trusted Path class decomposition D R A F T FTP_TRP - Trusted Path Trusted Path Page 42 of 246 CCEB-94/083 Version 0.90 94/10/31 FTP_TRP Trusted Path Family behaviour 203 This component defines the requirements to establish and maintain trusted communication to, from, or between human users and the assets protected by the TOE. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be initiated by a human user during an interaction with the TSF, or the TSF may establish communication with the human user input via a trusted path. Threats 204 The components in this family reduce the threats of an untrusted subject acting as a substitute for the TSF. 205 The components in this family address the threat of an untrusted subject acting as a substitute for a human user. 206 The components in this family reduce the threat of unauthorised discovery or modification of user-private data. Other relevant families 207 FTP_ITC Inter-TSF Trusted Channel 208 FTP_ITP Inter-TSF Trusted Path Component levelling 209 This family has been levelled based on the ability of either a user or the TSF to initiate a trusted path, and the capability of a trusted path to be established whenever a positive TSF-to-user connection is required. 210 The first component, FTP_TRP.1 Basic Trusted Path, requires that a trusted path for initial authentication and other security relevant events be initiated exclusively by the user. 211 The second component, FTP_TRP.2 Expanded-Use Trusted Path, requires that a trusted path for initial authentication and other security relevant events be initiated exclusively by the TSF. 212 The third component, FTP_TRP.3 User-TSF Initiated Trusted Path, requires that the trusted path be capable of being initiated by either the user or the TSF. D R A F T Trusted Path FTP_TRP - Trusted Path 94/10/31 CCEB-94/083 Version 0.90 Page 43 of 246 Application Notes Audit 213 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the trusted path functions. b) Basic: All attempted uses of the trusted path functions. c) Basic: Identification of the initiator and target of the trusted path. Documentation 214 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Information on how users are to use the trusted path [AGD_USR User guidance] FTP_TRP.1 Basic Trusted Path Hierarchical to: no other components. Component rationale and application notes 215 This component should be used when a trusted communication channel between an untrusted user and the TSF is required for initial authentication purposes and any additional services, and the channel is initiated exclusively by the user. Operations Assignment: 216 For FTP_TRP.1.3, the PP/ST author should specify any additional services for which a trusted path invokable solely by the user is required. Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication Elements: FTP_TRP.1.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and any user. D R A F T FTP_TRP - Trusted Path Trusted Path Page 44 of 246 CCEB-94/083 Version 0.90 94/10/31 FTP_TRP.1.2 The TSF shall provide users with the exclusive ability to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall use the trusted path for the following services: a) Initial authentication b) [Other services for which trusted path is required as specified by the PP/ST author] FTP_TRP.2 Expanded-Use Trusted Path Hierarchical to: no other components. Component rationale and application notes 217 This component should be used when a trusted communication channel between an untrusted user and the TSF is required for initial authentication purposes and any additional services, and the channel is initiated exclusively by the TSF. Operations Assignment: 218 For FTP_TRP.2.3, the PP/ST author should specify any additional services for which a trusted path invokable solely by the TSF is required. Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication Elements: FTP_TRP.2.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and any user. FTP_TRP.2.2 The TSF shall have the exclusive ability to initiate communication via the trusted path. FTP_TRP.2.3 The trusted path shall be used for the following TSF services: a) Initial authentication b) [Other services for which trusted path is required as specified by the PP/ST author] D R A F T Trusted Path FTP_TRP - Trusted Path 94/10/31 CCEB-94/083 Version 0.90 Page 45 of 246 FTP_TRP.3 User-TSF Initiated Trusted Path Hierarchical to: either FTP_TRP.1 or FTP_TRP.2. Component rationale and application notes 219 This component should be used when a trusted communication channel between an untrusted user and the TSF is required for all authentication activities, security relevant administration purposes and any additional services, and the channel is initiated by either the user or the TSF. 220 This component should be used when a trusted communication channel between an untrusted user and the TSF is required. This component addresses the threat of an untrusted subject acting as a substitute for the TSF during the initial identification and authentication, and when a positive TCB-to-user connection is required (e.g., change subject security level). Operations Assignment: 221 For FTP_TRP.3.4, the PP/ST author should specify any additional services for which a trusted path invokable by the user or the TSF is required. Dependencies: FIA_UID.1 Basic User Identification FIA_UAU.1 Basic User Authentication Elements: FTP_TRP.3.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and any user . FTP_TRP.3.2 The TSF shall have or provide to the users the ability to initiate communication via the trusted path. FTP_TRP.3.3 The TSF shall have the capability to uniquely identifying trusted path exchanges originating from the TSF and shall require positive confirmation from the untrusted subject. FTP_TRP.3.4 The trusted path shall be used for the following TSF services: a) All authentication activity. b) Security-relevant administrative actions. c) Changing the security-relevant attributes of an entity controlled by the TSF. D R A F T FTP_ITP - Inter-TSF Trusted Path Trusted Path Page 46 of 246 CCEB-94/083 Version 0.90 94/10/31 d) [Other services for which trusted path is required as specified by the PP/ST author] FTP_ITP Inter-TSF Trusted Path Family behaviour 222 This family defines the rules for the creation of a trusted path connection between a remote user and a TSF. For example, when a user on a remote machine needs to be authenticated by the TSF or a remote user needs to request downgrading of a file on the TSF. Threats 223 The components in this family address the following threats: 224 The threat that an untrusted machine user can act as a human user. 225 The threat of an untrusted subject acting as a substitute for the TSF. 226 The threat of an untrusted subject acting as a substitute for a human user. Other relevant families 227 FTP_ITC Inter-TSF Trusted Channel 228 FTP_TRP Trusted Path Component levelling 229 This family has been levelled based on the ability of either a user or the TSF to initiate a trusted path, and the capability of a trusted path to be established whenever a positive TSF-to-remote user connection is required. 230 The first component, FTP_ITP.1 Basic Inter-TSF Trusted Path, requires that a trusted path for initial authentication and other security relevant events be initiated exclusively by a remote user. 231 The second component, FTP_ITP.2 Expanded-Use Inter-TSF Trusted Path, requires that a trusted path for initial authentication and other security relevant events be initiated exclusively by the TSF. 232 The third component, FTP_ITP.3 Trusted Remote User-TSF Communication, requires that the trusted path be capable of being initiated by either a remote user or the TSF. D R A F T Trusted Path FTP_ITP - Inter-TSF Trusted Path 94/10/31 CCEB-94/083 Version 0.90 Page 47 of 246 Application Notes Audit 233 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the trusted path functions. b) Minimal: Identification of the initiator and target of the trusted path. c) Basic: All attempted uses of the trusted path functions. Documentation 234 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Information on how remote users are to use the trusted path [AGD_USR User guidance] FTP_ITP.1 Basic Inter-TSF Trusted Path Hierarchical to: no other components. Component rationale and application notes 235 This component should be used when a trusted communication channel between an untrusted remote user and the TSF is required for initial identification purposes and any additional services, and the channel is initiated exclusively by the remote user. Operations Assignment: 236 For FTP_ITP.1.3, the PP/ST author should specify any additional services for which a trusted path invokable solely by the user is required. Dependencies: FTP_TRP.1 Basic Trusted Path FTP_ITC.1 Inter-TSF Trusted Channel Elements: FTP_ITP.1.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and a remote user. D R A F T FTP_ITP - Inter-TSF Trusted Path Trusted Path Page 48 of 246 CCEB-94/083 Version 0.90 94/10/31 FTP_ITP.1.2 The TSF shall provide the remote users with the exclusive ability to initiate communication via the trusted path. FTP_ITP.1.3 The TSF shall use the trusted path for the following services: a) Initial authentication b) [Other services for which trusted path is required as specified by the PP/ST author] FTP_ITP.2 Expanded-Use Inter-TSF Trusted Path Hierarchical to: no other components. Component rationale and application notes 237 This component should be used when a trusted communication channel between an untrusted remote user and the TSF is required for initial identification purposes and any additional services, and the channel is initiated exclusively by the TSF. Operations Assignment: 238 For FTP_ITP.2.3, the PP/ST author should specify any additional services for which a trusted path invokable solely by the TSF is required. Dependencies: FTP_TRP.2 Expanded-Use Trusted Path FTP_ITC.1 Inter-TSF Trusted Channel Elements: FTP_ITP.2.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and a remote user. FTP_ITP.2.2 The TSF shall have the exclusive ability to initiate communication via the trusted path. FTP_ITP.2.3 The trusted path shall be used for the following TSF services: a) Initial authentication b) [Other services for which trusted path is required as specified by the PP/ST author] D R A F T Trusted Path FTP_ITP - Inter-TSF Trusted Path 94/10/31 CCEB-94/083 Version 0.90 Page 49 of 246 FTP_ITP.3 Trusted Remote User-TSF Communication Hierarchical to: either FTP_ITP.1 or FTP_TRP.2 Component rationale and application notes 239 This component should be used when a trusted communication channel between an untrusted remote user and the TSF is required for all authentication activities, security relevant administration purposes and any additional services, and the channel is initiated by either the user or the TSF. Operations Assignment: 240 For FTP_TRP.3.4, the PP/ST author should specify any additional services for which a trusted path invokable by the user or the TSF is required. Dependencies: FTP_TRP.3 User-TSF Initiated Trusted Path FTP_ITC.1 Inter-TSF Trusted Channel Elements: FTP_ITP.3.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication path between itself and a remote user . FTP_ITP.3.2 The TSF shall have or provide to the users the ability to initiate communication via the trusted path. FTP_ITP.3.3 The TSF shall have the capability to uniquely identifying trusted path exchanges originating from the TSF and shall require positive confirmation from the remote untrusted subject. FTP_ITP.3.4 The trusted path shall be used for the following TSF services: a) All authentication activity. b) Security-relevant administrative actions. c) Changing the security-relevant attributes of an entity controlled by the TSF. d) [Other services for which trusted path is required as specified by the PP/ST author] D R A F T FTP_ITC - Inter-TSF Trusted Channel Trusted Path Page 50 of 246 CCEB-94/083 Version 0.90 94/10/31 FTP_ITC Inter-TSF Trusted Channel Family behaviour 241 This component defines the rules for the creation of a trusted channel connection which goes between the TSF and other TSFs for the carrying out of security critical operations between TSFs. For example, when a user password database needs to be updated on one TSF by another TSF. Threats 242 This component addresses the threat of disclosure of TSF protected resources or their security attributes to a trojan horse or other malicious software. Other relevant families 243 FPT_ITC Inter-TSF Confidentiality of TSF Data 244 FPT_ITI Inter-TSF Integrity of TSF Data 245 FPT_ITA Inter-TSF Availability of TSF Data Component levelling 246 There is only one component in this family. 247 FTP_ITC.1 Inter-TSF Trusted Channel requires that the TSF provide mechanisms to enforce a trusted communication channel between two TSFs. Application Notes Audit 248 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the trusted channel functions. b) Minimal: Identification of the initiator and target of the trusted channel. c) Basic: All attempted uses of the trusted channel functions. Documentation 249 The indicated assurance documentation (if applicable) shall contain the indicated information: D R A F T Trusted Path FTP_ITC - Inter-TSF Trusted Channel 94/10/31 CCEB-94/083 Version 0.90 Page 51 of 246 a) Information on how administrators are to setup and configure the trusted channel [AGD_ADM Administrator guidance] FTP_ITC.1 Inter-TSF Trusted Channel Hierarchical to: no other components. Component rationale and application notes 250 This component should be used when a trusted communication channel between two TSFs is required. Operations Selection: 251 In FTP_ITC.1.2, for the [initiator] of the trusted channel, the PP/ST author should choose one from: - The local TSF - The remote TSF - Either the local or the remote TSF Assignment: 252 For FTP_ITC.1.3, the PP/ST author should specify any services for which a trusted channel is required. Selection: 253 In FTP_ITC.1.4, for the [attack] on the trusted channel, the PP/ST author should choose one or more from: - Disclosure, - Modification, - Delay in transit. Dependencies: FPT_ITC Inter-TSF Confidentiality of TSF Data FPT_ITI Inter-TSF Integrity of TSF Data Elements: FTP_ITC.1.1 The TSF shall provide a capability for a logically isolated and unmistakably distinguishable communication channel between itself and a remote TSF. FTP_ITC.1.2 The TSF shall provide the [initiator] the ability to initiate communication via the trusted channel. D R A F T FTP_ITC - Inter-TSF Trusted Channel Trusted Path Page 52 of 246 CCEB-94/083 Version 0.90 94/10/31 FTP_ITC.1.3 The trusted channel shall be used for the following TSF services: a) [Any services for which trusted channel is required as specified by the PP/ST author] FTP_ITC.1.4 The TSF shall protect data communicated through the trusted channel from unauthorised, undetectable or uncorrectable [attack]. D R A F T CCEB-94/083 94/10/31 Version 0.90 Page 53 of 246 Class FAU Security Audit 254 Security relevant activity is any activity defined by the TSP. Security auditing involves recognising, recording, storing, and analysing information related to security relevant activities. The resulting audit records can be examined to determine which security relevant activities took place and who (which user) was responsible for them. 255 While developing the security audit profile, the PP/ST author should take care to understand the inter-relationships among the audit families and components. The potential exists to specify a set of audit requirements that adhere to the family/ component dependencies lists, while at the same time resulting in a less than useful audit mechanism (e.g., an audit mechanism that requires all security relevant events to be audited but without the selectivity to control them on any reasonable basis - individual user or object). 256 CC audit families allow PP or ST writers the ability to define requirements for monitoring user activities and, in some cases, detecting real, potential or imminent violations of the TSP. The TOE's security audit functions are defined to help monitor the use of access rights by authorised users, and act as a deterrent against security violations. The requirements of the audit families refer to mechanisms that include audit data protection, record format and event selection, as well as to analysis tools, violation alarms, and real-time analysis. Audit data must be available in a useful format, that organises audit data into a human-readable format and/or delivers it to authorised users or processes acting on their behalf. D R A F T FAU_GEN - Security Audit Event Generation Security Audit Page 54 of 246 CCEB-94/083 Version 0.90 94/10/31 257 Security Audit | | - FAU_GEN - 1 - 2 - 3 | | - FAU_PRO - 1 - 2 | | 1 | - FAU_SEL < | 2 - 3 - 4 - 5 | | - FAU_PRP - 1 | | - FAU_PRA - 1 - 2 | | - FAU_ARP - 1 - 2 | | - FAU_STG - 1 - 2 | | - FAU_POP - TBD | | - FAU_POA - 1 - 2 | | - FAU_MGT - 1 - 2 Figure 2.4 - Security Audit class decomposition FAU_GEN Security Audit Event Generation Family behaviour 258 This family defines a mechanism for recording the occurrence of security relevant events that take place under TSF control. All other families within the security audit group depend on the existence of this family. 259 This family enumerates the types of events that must be auditable by the TSF, and identifies the minimum set of audit-related information that must be provided within various audit record types. 260 The actual list of auditable events is entirely dependent on the other functional families within the PP/ST. Each family definition must therefore include a list of its family-specific auditable events. Each auditable event in the list of auditable events specified in the functional family must correspond to one of the levels of audit event generation specified in this family (i.e., minimal, basic, detailed). This provides the D R A F T Security Audit FAU_GEN - Security Audit Event Generation 94/10/31 CCEB-94/083 Version 0.90 Page 55 of 246 PP/ST writer with information necessary to ensure that all appropriate auditable events are specified in the PP/ST. The following example (taken from family FIA_ATA User Attribute Administration) depicts how auditable events are to be specified in appropriate functional families: 261 "The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the user security attribute administration functions. b) Basic: All attempted uses of the user security attribute administration functions. c) Basic: Identification of which user security attributes have been modified. d) Detailed: With the exception of specific sensitive attribute data items (e.g., passwords, cryptographic keys), the new values of the attributes must be captured." 262 It should be observed that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation is desired, all auditable events identified as being both Minimal and Basic, except when the higher level event simply provides more detail than the lower level event, should be included in the PP/ST through the use of the appropriate assignment operation. When Detailed Audit Generation is desired, all identified auditable events (Minimal, Basic and Detailed) should be included in the PP/ST. Editor Note: This component is worded in the fashion that it is in order to avoid a massive dependency list on other functional components. Instead, each component has an AUDIT section in which the events to be audited for that functional area are listed. When the PP/ST author assembles the PP/ST, the items in the AUDIT area are used to complete the variable in this component. Thus, the specification of what is to be audited for a functional area is localised in that functional area. Threats 263 This family addresses the threats of security violations going undetected. Other relevant families No other relevant family. Component levelling 264 Family levelling is based on the granularity of events that must be auditable by the TOE. FAU_GEN.1 requires that the list of auditable events provided by the PP/ ST writer be auditable, and specifies the list of data that shall be recorded in D R A F T FAU_GEN - Security Audit Event Generation Security Audit Page 56 of 246 CCEB-94/083 Version 0.90 94/10/31 each record. FAU_GEN.1 is for use when I&A is not part of the TSP, and thus does not require that individual user identities be associated with audit events. At FAU_GEN.2 the audit record must associate events to individual user identities, thus adding a dependence on I&A. At FAU_GEN.3, events that, alone or in combination with other events, may indicate an imminent violation of the TSP are required to be added to the list of auditable events. Application Notes User Application Notes 265 The following are examples of the types of auditable events that should be defined within each PP/ST functional component: 1) Introduction of objects into a subject's (or user's) address space; deletion of objects. 2) Distribution or revocation of access rights and privileges; changes to subject or object security privileges. 3) Policy checks performed by the TSF as a result of a request by a subject; the use of privilege to bypass a policy check. 4) Use of Identification and Authentication mechanisms. 5) Actions taken by a computer operator, TOE administrator and/or security officer. Suppression of a TSF protection mechanism (e.g., suppression of human-readable labels). 6) Import/export of data from/to removable media (e.g., printed output, tapes, diskettes). Documentation 266 The indicated assurance documentation (if applicable) shall contain the indicated information: a) The list of auditable events and the audit record format [AGD_ADM Administrator guidance]. D R A F T Security Audit FAU_GEN - Security Audit Event Generation 94/10/31 CCEB-94/083 Version 0.90 Page 57 of 246 FAU_GEN.1 Minimal Audit Generation Hierarchical to: no other components. Component rationale and application notes User Application Notes 267 This component addresses the possible existence of audit functionality in the absence of individual user identities. Operations Assignment: 268 For FAU_GEN.1.1b, the PP/ST author should include a list of all actions called out for audit in the Audit sections of other functional components included in the PP/ST. Assignment: 269 For FAU_GEN.1.2, the PP/ST author should include a list of all information to be included in audit event records for events audited under FAU_GEN.1.1 included in the PP/ST. Dependencies No dependencies. Elements: FAU_GEN.1.1 The TSF shall be able to generate a record of the following auditable events: a) Shutdown of the audit functions. b) [Other auditable events as specified by the PP/ST author based on the other functional components included in the PP/ST.] FAU_GEN.1.2 The TSF shall record within each audit record the following information: date and time of the event, type of event, subject identity, and success or failure of the event. In addition the TSF shall be able to include the following information: c) [The list of required information for each audit events type shall be formulated by the PP/ST author based on the auditable event definitions included in the other functional components of the PP/ST.] D R A F T FAU_GEN - Security Audit Event Generation Security Audit Page 58 of 246 CCEB-94/083 Version 0.90 94/10/31 FAU_GEN.2 Basic Audit Generation Hierarchical to: FAU_GEN.1 Component rationale and application notes Operations Assignment: 270 For FAU_GEN.2.1b, the PP/ST author should include a list of all actions called out for audit in the Audit sections of other functional components included in the PP/ST. Assignment: 271 For FAU_GEN.2.2, the PP/ST author should include a list of all information to be included in audit event records for events audited under FAU_GEN.2.1 included in the PP/ST. Dependencies: FIA_UID.2 Unique Identification of Users Elements: FAU_GEN.2.1 The TSF shall be able to generate a record of the following auditable events: a) Shutdown of the audit functions. b) [Other auditable events as specified by the PP/ST author based on the other functional components included in the PP/ST.] FAU_GEN.2.2 The TSF shall record within each audit record the following information: date and time of the event, type of event, user responsible for the event , and success or failure of the event. In addition the TSF shall be able to include the following information: c) [The list of required information for each audit event type shall be formulated by the PP/ST author based on the auditable event definitions included in the other functional components of the PP/ST.] D R A F T Security Audit FAU_GEN - Security Audit Event Generation 94/10/31 CCEB-94/083 Version 0.90 Page 59 of 246 FAU_GEN.3 Detailed Audit Generation Hierarchical to: FAU_GEN.2 Component rationale and application notes Operations Assignment: 272 For FAU_GEN.3.1b, the PP/ST author should include a list of all actions called out for audit in the Audit sections of other functional components included in the PP/ST. Assignment: 273 For FAU_GEN.3.1c, the PP/ST author should identify the subset of events whose occurrence or accumulated occurrence is an indication of the immediate violation of the TSF. Assignment: 274 For FAU_GEN.3.2, the PP/ST author should include a list of all information to be included in audit event records for events audited under FAU_GEN.3.1 included in the PP/ST. Dependencies: FIA_UID.2 Unique Identification of Users Elements: FAU_GEN.3.1 The TSF shall be able to generate a record of the following auditable events: a) Shutdown of the audit mechanism. b) [Other auditable events as specified by the PP/ST author based on the other functional components included in the PP/ST.] c) [Events that may indicate the imminent violation of the TSP or whose accumulated occurrence (possibly with other events) may indicate an imminent security violation. This list shall be specified by the PP/ST author based on the other functional components included in the PP/ ST.] FAU_GEN.3.2 The TSF shall record within each audit record the following information: date and time of the event, type of event, user responsible for the event, and success or failure of the event. In addition the TSF shall be able to include the following information: D R A F T FAU_PRO - Security Audit Trail Protection Security Audit Page 60 of 246 CCEB-94/083 Version 0.90 94/10/31 d) [The list of required information for each audit event type shall be formulated by the PP/ST author based on the auditable event definitions included in the other functional components of the PP/ST.] FAU_PRO Security Audit Trail Protection Family behaviour 275 This family provides requirements to protect the audit trail from unauthorised modification, disclosure or destruction. This pertains to periods where the audit trail is exchanged between, or processed or stored within parts of a TOE. Threats 276 This family addresses the threats of modification and destruction of the audit trail, which could have the result of hindering a subsequent investigation of unauthorised actions. 277 This family addresses the threats of disclosure of audit trail to unauthorised users. Other relevant families No other relevant family. Component levelling 278 Family levelling is based on scope of the protection mechanisms as applied to the audit trail files and audit analysis tool output. At FAU_PRO.1, the requirements for audit trail protection apply specifically to the audit trail only. At FAU_PRO.2, the requirements for audit trail protection extend to include audit data formatted/translated by audit analysis tools. FAU_PRO.1 Basic Audit Trail Protection Hierarchical to: no other components. Component rationale and application notes 279 Under FAU_MGT.1 Administration of Audit, the authorised administrator is the audit administrator. Operations No permitted operation. D R A F T Security Audit FAU_SEL - Security Audit Event Selection 94/10/31 CCEB-94/083 Version 0.90 Page 61 of 246 Dependencies: FAU_GEN.1 Minimal Audit Generation FAU_MGT.1 Administration of Audit Elements: FAU_PRO.1.1 The TSF shall limit access to read, modify and destroy the audit trail to authorised administrators. FAU_PRO.2 Complete Audit Trail Protection Hierarchical to: FAU_PRO.1 Component rationale and application notes 280 In the previous component there is no assumption that audit tools exist to transform audit data output, and even if there were off-line tools to perform audit data analysis, they may require the data to be moved outside the TSF protection boundary. In this component, there is an additional requirement that audit data, in whatever form it is stored in or translated to, remains protected by the TSF. Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation FAU_MGT.1 Administration of Audit FAU_POA Security Audit Post-storage Analysis Elements: FAU_PRO.2.1 The TSF shall limit access to read, modify and destroy the audit trail and audit analysis tool output to authorised administrators. FAU_SEL Security Audit Event Selection Family behaviour 281 This family defines requirements to select and change the events to be audited and their defaults, during TOE operation, and requirements to be able to selectively audit the action of one or more users based on individual identity and/or TSP. The TSF should provide a capability to display, to an authorised user, the currently selected events and their defaults. This family ensures that it is possible to keep the audit trail from becoming so large it becomes useless. This family ensures appropriate granularity of the selectable security audit events. D R A F T FAU_SEL - Security Audit Event Selection Security Audit Page 62 of 246 CCEB-94/083 Version 0.90 94/10/31 Threats 282 This family addresses the threats of accumulation of audit data that could cause the TOE to be unable to meet its functional requirements. 283 This family addresses the threats of inappropriate cost or performance versus security trade-offs caused by inflexible audit event selection. Other relevant families No other relevant family. Component levelling 284 Levelling is based on the existence of individual user identities and on the configurability of the audit mechanism on a per-event basis, and whether configuration can be performed dynamically. 285 FAU_SEL.1 requires the ability to selectively audit based upon security attributes. This component is dependent on FAU_GEN.1 Minimal Audit Generation, and thus does not depend on I&A. 286 FAU_SEL.2 requires the ability to selectively audit based upon user identity. This component is dependent on FAU_GEN.2 Basic Audit Generation, and thus adds a dependence on I&A. 287 FAU_SEL.3 requires the ability to selectively audit based upon user identity and/or security attribute. 288 FAU_SEL.4 adds the requirement that the audit mechanism be configurable on a per-event basis. However, configurability could be performed off-line (e.g., at system configuration time), without the need for a TSF mechanism to perform this configuration. 289 FAU_SEL.5 requires runtime configurability of the audit mechanism and that the mechanism providing the selection capability must be part of the TSF. Application Notes User Application Notes 290 Up to component FAU_SEL.5 the mechanism(s) that provide the selective audit capability need not be part of the TSF, as long as they cannot be employed while the system is operating. The authorised administrator could, up to level FAU_SEL.5, be an operator with physical access to the TSF. Selective audit could be performed as a part of system initialisation before the system becomes operational. D R A F T Security Audit FAU_SEL - Security Audit Event Selection 94/10/31 CCEB-94/083 Version 0.90 Page 63 of 246 Audit 291 The following action(s) should be audited: a) All modifications to the audit configuration that occur while the audit collection mechanisms are operating shall be audited. FAU_SEL.1 Selective Audit by Attributes Only Hierarchical to: no other components. Component rationale and application notes 292 The existence of individual user identities is not assumed at this component. This would allow for component systems such as routers that may not support the notion of users. Note that selective audit could be provided prior to initialisation or after system shutdown. Operations Assignment: 293 For FAU_SEL.1.1, the PP/ST author should specify the minimum list of security attributes that audit selectivity is based upon. Dependencies: FAU_GEN.1 Minimal Audit Generation FAU_MGT.1 Administration of Audit Elements: FAU_SEL.1.1 The authorised administrator shall be able to selectively audit based on the following security attributes: a) Object identity b) [The list of additional attributes that must be capable of being selectively auditable shall be specified by the PP/ST author.] FAU_SEL.2 Selective Audit by Individuals Only Hierarchical to: no other components. Component rationale and application notes Dependencies: FAU_GEN.2 Basic Audit Generation FAU_MGT.1 Administration of Audit D R A F T FAU_SEL - Security Audit Event Selection Security Audit Page 64 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FAU_SEL.2.1 The TSF shall provide the authorised administrator with the ability to selectively audit the actions of one or more users based on individual identity. FAU_SEL.3 Selective Audit by Attributes and Individuals Hierarchical to: FAU_SEL.2 Component rationale and application notes Operations Assignment: 294 For FAU_SEL.3.2, the PP/ST author should specify the minimum list of attributes that must be capable of being selectively auditable. Dependencies: FAU_GEN.2 Basic Audit Generation FAU_MGT.1 Administration of Audit Elements: FAU_SEL.3.1 The TSF shall provide the authorised administrator with the ability to selectively audit the actions of one or more users based on individual identity. FAU_SEL.3.2 The TSF shall provide the authorised administrator with the ability to selectively audit based on the following security attributes: a) [The list of additional attributes that must be capable of being selectively auditable shall be specified by the PP/ST author.] FAU_SEL.4 Selective Audit Per-Event Hierarchical to: FAU_SEL.3 Component rationale and application notes Evaluator's application notes 295 The mechanism for selecting/updating the selection of the set of auditable events may be available either during normal operation of the TSF, or in an "off-line" configuration mode. D R A F T Security Audit FAU_SEL - Security Audit Event Selection 94/10/31 CCEB-94/083 Version 0.90 Page 65 of 246 Operations Assignment: 296 For FAU_SEL.4.2, the PP/ST author should specify the minimum list of attributes that must be capable of being selectively auditable. Dependencies: FAU_GEN.2 Basic Audit Generation FAU_MGT.1 Administration of Audit Elements: FAU_SEL.4.1 The TSF shall provide the authorised administrator with the ability to selectively audit the actions of one or more users based on individual identity. FAU_SEL.4.2 The TSF shall provide the authorised administrator with the ability to selectively audit based on the following security attributes: a) [The list of additional attributes that must be capable of being selectively auditable shall be specified by the PP/ST author.] FAU_SEL.4.3 A mechanism shall be provided with the capability to select on a per-event basis the events to be audited. FAU_SEL.4.4 Use of this mechanism shall be restricted to authorised administrators. FAU_SEL.5 Runtime Selective Audit Hierarchical to: FAU_SEL.4 Component rationale and application notes Evaluator's application notes 297 The mechanism to select or change the set of audited events must be available during TSF operation. Operations Assignment: 298 For FAU_SEL.5.2, the PP/ST author should specify the minimum list of attributes that must be capable of being selectively auditable. Dependencies: FAU_GEN.2 Basic Audit Generation FAU_MGT.1 Administration of Audit D R A F T FAU_PRP - Security Audit Pre-storage Processing Security Audit Page 66 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FAU_SEL.5.1 The TSF shall provide the authorised administrator with the ability to selectively audit the actions of one or more users based on individual identity. FAU_SEL.5.2 The TSF shall provide the authorised administrator with the ability to selectively audit based on the following security attributes: a) [The list of additional attributes that must be capable of being selectively auditable shall be specified by the PP/ST author.] FAU_SEL.5.3 The TSF shall provide a mechanism with the capability to select on a per-event basis the events to be audited. FAU_SEL.5.4 Use of this mechanism shall be restricted to authorised administrators. FAU_SEL.5.5 Changes made through this mechanism shall take affect immediately . FAU_SEL.5.6 The selective audit mechanisms shall be part of the TSF. FAU_PRP Security Audit Pre-storage Processing Family behaviour 299 This family defines requirements that the TSF provide the capability to transform the representation of a single security audit event into a useful and consistent format for its subsequent use. This format should be appropriate for its attempted use (e.g. transfer, storage, violation alarms, and real-time analysis). For violation alarms and the results of real-time analysis, audit data should be placed into a useful format for delivery to authorised users or processes acting on their behalf. Threats 300 This family addresses the threats of inconsistent interpretation of audit events between audit security functions and other security functions. Other relevant families No other relevant family. Component levelling 301 Only one component defined at this time. D R A F T Security Audit FAU_PRA - Security Audit Pre-storage Analysis 94/10/31 CCEB-94/083 Version 0.90 Page 67 of 246 Application Notes User Application Notes 302 This family addresses the threat of inconsistent interpretation of audit events from logs that have been transferred or stored for an extended period of time. In such cases, identifying users by process IDs or files by inodes would be of little value. Process IDs and inodes would only be of value on the host machine where the records were generated, and only for a limited period of time, until the inode numbers or process IDs were recycled. Evaluator's application notes 303 If the TSF boundary does not associate a symbolic name with an object, this requirement does not apply. FAU_PRP.1 Symbolic Name Association Hierarchical to: no other components. Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.2 Basic Audit Generation FIA_ATD.2 Basic User Attribute Definition Elements: FAU_PRP.1.1 The TSF shall be able to unambiguously associate an audit event to the symbolic name of the user responsible for the event and the symbolic name of the object accessed (if applicable). FAU_PRA Security Audit Pre-storage Analysis Family behaviour 304 This family defines requirements for analysis of a collection of security audit events, and for the decision of the operation (e.g. modification, dilation, combination) to be performed on this collection of events based on this analysis. 305 This analysis may work in support of intrusion detection, accumulation of security audit events, or automatic response to an imminent security violation. D R A F T FAU_PRA - Security Audit Pre-storage Analysis Security Audit Page 68 of 246 CCEB-94/083 Version 0.90 94/10/31 Threats 306 This family addresses the threats of auditor missing the significance of a sequence of seemingly uninteresting audit events. 307 This family addresses the threats of persistence of violations of TSP without detection. Other relevant families No other relevant family. Component levelling 308 Levelling is based on the sophistication of the audit monitoring tool. 309 At FAU_PRA.1 Imminent Violation Analysis, basic threshold detection is considered a sufficient monitoring device. 310 At FAU_PRA.2 Intrusion Detection Analysis, real-time intrusion detection technology is employed to identify sophisticated attacks and malicious behaviour. Application Notes Audit Documentation FAU_PRA.1 Imminent Violation Analysis Hierarchical to: no other components. Component rationale and application notes Operations Assignment: 311 For FAU_PRA.1.2, the PP/ST author should specify the subset of the audited event whose occurrence or accumulated occurrence may indicate an imminent violation of the TSF Dependencies: FAU_GEN.3 Detailed Audit Generation FAU_PRP.1 Symbolic Name Association FAU_ARP.1 Security Alarms D R A F T Security Audit FAU_PRA - Security Audit Pre-storage Analysis 94/10/31 CCEB-94/083 Version 0.90 Page 69 of 246 Elements: FAU_PRA.1.1 The TSF shall be able to monitor the occurrence or accumulation of the set of known auditable events that may indicate an imminent violation of the TSP. FAU_PRA.1.2 The set of known events that may indicate the imminent violation of the TSP shall include the following: a) [The list of events that may indicate imminent violations shall be formulated by the PP/ST author based on other functional components in the PP/ST.] FAU_PRA.2 Intrusion Detection Analysis Hierarchical to: FAU_PRA.1 Component rationale and application notes Operations Assignment: 312 For FAU_PRA.2.2, the PP/ST author should specify the subset of the audited event whose occurrence or accumulated occurrence may indicate an imminent violations of the TSF Dependencies: FAU_GEN.3 Detailed Audit Generation FAU_PRP.1 Symbolic Name Association Elements: FAU_PRA.2.1 The TSF shall be able to monitor the occurrence or accumulation of the set of known auditable events that may indicate an imminent violation of the TSP. FAU_PRA.2.2 The set of known events that may indicate the imminent violation of the TSP shall include the following: a) [The list of events that may indicate imminent violations as formulated by the PP/ST author based on other functional components in the PP/ST.] FAU_PRA.2.3 The TSF shall be able to perform real-time intrusion detection analysis in support of the TSP. Editor Note: The actual requirements for automated intrusion detection analysis have not yet been developed. D R A F T FAU_ARP - Security Audit Automatic Response Security Audit Page 70 of 246 CCEB-94/083 Version 0.90 94/10/31 FAU_ARP Security Audit Automatic Response Family behaviour 313 This family defines the requirements specifying the condition and the reaction to those conditions that should be taken by the TSF. 314 The type of reaction the TSF should take include for example generation of real time alarm, termination of the offending process, disabling of a service, disconnection or invalidation of a user. Threats 315 This family addresses the threats of undesirable acts (from a TSP perspective), continuing to occur. 316 This family addresses the threats that responsible parties may remain unaware of the occurrence of undesirable acts. Other relevant families No other relevant family. Component levelling 317 Levelling is based on whether pre-emption is used by the analysis tool when a security violation appears imminent. 318 At FAU_ARP.1, the tool need only be passive and have the ability to warn the administrator. 319 FAU_ARP.2 requires the TSF to take an active role in terminating intrusive behaviour. Application Notes User Application Notes 320 The term "appears imminent" is defined in FAU_PRA.1.1 (this requirement is repeated in FAU_PRA.2.1). Audit 321 The following action(s) should be audited: a) Notification of the administrator when a security violation appears imminent shall be an auditable event. D R A F T Security Audit FAU_ARP - Security Audit Automatic Response 94/10/31 CCEB-94/083 Version 0.90 Page 71 of 246 Documentation 322 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Recommendations for handling notifications generated by the TSF when a security violation appears imminent [AGD_ADM Administrator guidance]. FAU_ARP.1 Security Alarms Hierarchical to: no other components. Component rationale and application notes Operations No permitted operation. Dependencies: FAU_PRA.1 Imminent Violation Analysis FAU_MGT.1 Administration of Audit Elements: FAU_ARP.1.1 The TSF shall be able to immediately notify the administrator when a security violation appears imminent. FAU_ARP.2 Pre-emptive Response Hierarchical to: FAU_ARP.1 Component rationale and application notes Operations No permitted operation. Dependencies: FAU_PRA.1 Imminent Violation Analysis FAU_MGT.1 Administration of Audit Elements: FAU_ARP.2.1 The TSF shall be able to immediately notify the administrator when a security violation appears imminent. D R A F T FAU_STG - Security Audit Event Storage Security Audit Page 72 of 246 CCEB-94/083 Version 0.90 94/10/31 FAU_ARP.2.2 If the occurrence or accumulation of monitored security relevant events continues, the TSF shall be able to take the least disruptive action to terminate the recurrence of these events. FAU_STG Security Audit Event Storage Family behaviour 323 This family defines the requirement that the TSF should be able to create a persistent trail of security audit event for later use. Threats 324 This family addresses the threats of being unable to make a damage assessment based upon audit activity. Other relevant families No other relevant family. Component levelling 325 Levelling is based on whether the TSF takes action to prevent loss of audit data. At FAU_STG.1, conditions under which audit data loss due to system failure occurs must be enumerated by the developer. FAU_STG.2 adds the requirement that the TSF be capable of preventing audit data loss due to exhaustion of storage space. Application Notes Documentation 326 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Conditions under which loss of audit data due to system failure shall be enumerated and the potential number of audit events lost shall be documented [AGD_ADM Administrator guidance]. D R A F T Security Audit FAU_POP - Security Audit Post-storage Processing 94/10/31 CCEB-94/083 Version 0.90 Page 73 of 246 FAU_STG.1 Enumeration of Audit Data Loss Hierarchical to: no other components. Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation Elements: FAU_STG.1.1 Conditions under which loss of audit data due to system failure can occur shall be enumerated and the potential number of audit events lost shall be determined. FAU_STG.2 Prevention of Audit Data Loss Hierarchical to: FAU_STG.1 Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation Elements: FAU_STG.2.1 Conditions under which loss of audit data due to system failure can occur shall be enumerated and the potential number of audit events lost shall be determined. FAU_STG.2.2 In the event of audit storage exhaustion, the TSF shall be capable of preventing auditable actions from occurring. Actions from users authorised to control audit administration may be excluded. FAU_POP Security Audit Post-storage Processing Family behaviour 327 This family defines requirements that provide the TSF the capability to transform the representation of a single security audit event into a useful and consistent format for its subsequent use. This format should be appropriate for its attempted use (e.g. D R A F T FAU_POA - Security Audit Post-storage Analysis Security Audit Page 74 of 246 CCEB-94/083 Version 0.90 94/10/31 transfer, analysis, or review). Audit data should be placed into a useful format for delivery to authorised users or processes acting on their behalf. Threats 328 This family addresses the threats of inconsistent interpretation of audit events between audit security functions and other security functions. Other relevant families No other relevant family. FAU_POA Security Audit Post-storage Analysis Family behaviour 329 This family defines the requirements for audit review tools that should be available to authorised users to assist in the inspection and review of audit data. These tools should allow post-collection audit analysis that includes for example the ability to selectively review the actions of one or more users (e.g., identification, authentication, TOE entry, and access control actions); the actions performed on a specific object or TOE resource; all of a specified set of audited exceptions; and actions associated with a specific TSP attribute. Threats 330 This family addresses the threat that the meaning of security relevant events could not be determined. 331 This family addresses the threat of undetected security violation. 332 This family addresses the threat of an auditor missing the significance of a sequence of seemingly uninteresting audit events. Other relevant families No other relevant family. Component levelling 333 Family levelling is based on the functionality provided by the audit review tools. 334 FAU_POA.1 Audit Review requires audit "review" capability while 335 FAU_POA.2 Audit Analysis requires "analysis" capability. D R A F T Security Audit FAU_POA - Security Audit Post-storage Analysis 94/10/31 CCEB-94/083 Version 0.90 Page 75 of 246 Application Notes User Application Notes 336 The distinction between review and analysis is based on functionality. Review capability encompasses only the ability to view audit data and search on a single criterion. Analysis capability is more sophisticated and requires the ability to view audit data, perform searches based on multiple criteria with logical (and/or) relations, sort audit data, and filter audit data. FAU_POA.1 Audit Review Hierarchical to: no other components. Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation FAU_MGT.1 Administration of Audit Elements: FAU_POA.1.1 Post-storage audit review tools shall be made available to authorised administrators, and to users to whom the required authority has been delegated, to assist in the inspection of the audit trail. FAU_POA.1.2 Audit review tools shall, at a minimum, provide the ability to view audit data and to perform searches based on a single criterion. FAU_POA.2 Audit Analysis Hierarchical to: FAU_POA.1 Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation FAU_MGT.1 Administration of Audit D R A F T FAU_MGT - Security Audit Management Security Audit Page 76 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FAU_POA.2.1 Post-storage audit analysis tools shall be made available to authorised administrators, and to users to whom the required authority has been delegated, to assist in the analysis of the audit trail. FAU_POA.2.2 Audit analysis tools shall, at a minimum, provide the ability to view audit data, perform searches based on multiple criteria with logical (and/or) relations, sort audit data, and filter audit data. FAU_MGT Security Audit Management Family behaviour 337 This family defines requirements that pertain to defining the administrative interface for initially setting, changing, and reviewing the security audit attributes and parameters. 338 For example, requirements for: - Creation, destruction, and emptying of audit trails; use of warning points regarding the size of the audit data, and modification of the audit trail size; - Formatting and compressing of event records; - Displaying of formatted audit trail data; and - Maintaining the consistency of audit trail data after TOE failures and discontinuity of operation. 339 This family must include requirements defining authorised user of the capabilities. Threats 340 This family addresses the threat of inconsistency of setting up parameters or attributes, or incorrect use of the tools. 341 This family addresses the threat of uncontrolled modification or access of the security audit attributes. 342 This family addresses the threat of unauthorised modification or access of the security audit attributes D R A F T Security Audit FAU_MGT - Security Audit Management 94/10/31 CCEB-94/083 Version 0.90 Page 77 of 246 Other relevant families No other relevant family. Component levelling 343 Levelling is based on the separation of roles for audit administration. At FAU_MGT.1 audit administration is handled by the system administrator. At FAU_MGT.2, a separate audit administrator role is required. FAU_MGT.1 Administration of Audit Hierarchical to: no other components. Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation FPT_TSA.1 Basic Security Administration Elements: FAU_MGT.1.1 Administrative control over the audit mechanisms and access to audit data shall be restricted to authorised administrators and their delegates. FAU_MGT.2 Separate Audit Administration Hierarchical to: FAU_MGT.1 Component rationale and application notes Operations No permitted operation. Dependencies: FAU_GEN.1 Minimal Audit Generation FPT_TSA.3 Multiple Security Administrative Roles D R A F T FAU_MGT - Security Audit Management Security Audit Page 78 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FAU_MGT.2.1 Administrative control over the audit mechanisms and access to audit data shall be restricted to an audit administrator . D R A F T 102 CCEB-94/083 94/10/31 Version 0.90 Page 79 of 246 Class FTE TOE Entry 344 TOE Entry components specify functional requirements, over and above identification and authentication requirements, for controlling the establishment of a user's session. The establishment of a user's session typically consists of the creation of one or more subjects that perform operations in the TOE on behalf of the user. At the end of the TOE Entry procedure, provided the TOE Entry requirements are satisfied, the created subjects bear the attributes determined by the I&A functions. TOE Entry requirements can be specified in terms of attributes such as the user identity, group or role membership, confidentiality and integrity levels, time intervals, location, and mode of access. 345 The TOE Entry functions may include warnings about unauthorised attempts to gain access to the TOE. For example, it may display last login data so the user can determine whether the previous successful login was performed by the user and not by an intruder who successfully broke the user's password. The TOE entry functions may control: (1) multiple simultaneous user logins; (2) locking an interactive session during periods of user inactivity; (3) time intervals limiting authorised user access; and, (4) location or port of user session establishment. 346 TOE Entry functions can help counter threats of inadvertent, deliberate, or coerced access performed in an unauthorised manner by an authenticated user. For example, the location and time of user session establishment can be constrained in such a way that identified and authenticated users located in areas of high exposure (e.g., public areas) cannot display sensitive data, enter high-integrity commands, or operate outside working hours. Similarly, controlling the mode of session establishment helps ensure that identified and authenticated users cannot remotely start batch computations that would normally require the user's attendance. D R A F T FTE_TEB - TOE Entry Banners TOE Entry Page 80 of 246 CCEB-94/083 Version 0.90 94/10/31 347 TOE Entry | | - FTE_TEB - 1 - 2 | | - FTE_MCS - 1 - 2 | | - FTE_MTE - 1 | | - FTE_MDE - 1 | | - FTE_TME - 1 - 2 | | - FTE_LCE - 1 - 2 | | - FTE_SEH - 1 | | - FTE_SSL - 1 - 2 | | - FTE_TEM - 1 - 2 Figure 2.5 - TOE Entry class decomposition FTE_TEB TOE Entry Banners Family behaviour 348 This family defines requirements to display a configurable advisory warning message to users regarding the unauthorised use of the TOE. Threats 349 This family addresses the threat of a user unwittingly gaining unauthorised access to the TOE. 350 This family addresses the threat of misuse of the TOE due to the lack of awareness of policies, laws or regulations governing its use. D R A F T TOE Entry FTE_TEB - TOE Entry Banners 94/10/31 CCEB-94/083 Version 0.90 Page 81 of 246 Other relevant families No other relevant family. Component levelling 351 FTE_TEB components are levelled based on the functional coverage for a Security Administrator to modify a TOE default message. 352 The functions covered at FTE_TEB.1 Default TOE Entry Banners include a TOE Entry banner which is specified through the use a component assignment operation and is displayed by default without the capability for modification. 353 FTE_TEB.2 Configurable TOE Entry Banners extends the functional coverage of FTE_TEB.1 by requiring the ability for a Security Administrator to modify the existing default TOE Entry banner. Application Notes User Application Notes 354 FTE_TEB.1 provides banner protection by default, that can not be modified. FTE_TEB.2 provides the additional capability to specify site or organisation specific banners. Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Guidance [AGD_ADM Administrator guidance] on how to configure the TOE Entry banner message per the FTE_TEB.2 Configurable TOE Entry Banners component. FTE_TEB.1 Default TOE Entry Banners Hierarchical to: no other components. Operations Assignment : 355 The warning message may be assigned by a PP or ST writer, which will be displayed by default prior to TOE Entry. For example, the following message could be assigned: 356 "NOTICE: This is a private computer system. All users of this system are subject to having their activities audited. Anyone using this system consents to such auditing. All unauthorised entries or actions revealed D R A F T FTE_TEB - TOE Entry Banners TOE Entry Page 82 of 246 CCEB-94/083 Version 0.90 94/10/31 by this auditing can be used as evidence and may lead to criminal prosecutions." Dependencies: No dependencies. Elements: FTE_TEB.1.1 Upon initial contact with the TOE, the TSF shall display an advisory warning message to a user regarding unauthorised use of the TOE. FTE_TEB.1.2 The message displayed by the TSF shall indicate the possible consequences of failing to heed the warning. FTE_TEB.1.3 The TSF shall display the following advisory warning message: [ message ] FTE_TEB.2 Configurable TOE Entry Banners Hierarchical to: FTE_TEB.1 Operations Refinement : 357 The minimum or maximum size of the message may be specified. Assignment : 358 A default message may be specified.This warning message may be assigned by a PP or ST which will be displayed by default prior to TOE Entry. For example, the following message could be assigned: 359 "NOTICE: This is a private computer system. All users of this system are subject to having their activities audited. Anyone using this system consents to such auditing. All unauthorised entries or actions revealed by this auditing can be used as evidence and may lead to criminal prosecutions." Dependencies: FTE_TEM.1 Basic TOE Entry Management Elements: FTE_TEB.2.1 Prior to entering the TOE, the TSF shall display an advisory warning message to the user regarding unauthorised use of the TOE. FTE_TEB.2.2 The message displayed by the TSF shall indicate the possible consequences of failing to heed the warning. D R A F T TOE Entry FTE_MCS - Limitation on Multiple Concurrent Sessions 94/10/31 CCEB-94/083 Version 0.90 Page 83 of 246 FTE_TEB.2.3 The TSF shall, by default , display the following advisory warning message: [message] FTE_TEB.2.4 The warning message shall only be specifiable by a Security Administrator. FTE_MCS Limitation on Multiple Concurrent Sessions Family behaviour 360 This family defines requirements to place limit on the number of concurrent sessions of authorised users. Threats 361 This family addresses the threat of an authorised user being active on more than one session where proper monitoring or procedural measures cannot be adequately provided to support such actions. 362 This family addresses the threat of users exceeding some predefined resources limit Other relevant families 363 FTE_SSL Session Locking Component levelling 364 FTE_MCS components are levelled based on the functional coverage for the TOE to place limits on the number of concurrent sessions uniformally for all authorised users of the TOE or selectively based on user attributes. 365 The functional coverage at FTE_MCS.1 Basic Limitation on Multiple Concurrent Sessions includes limitations that apply to all authorised users of the TOE. 366 FTE_MCS.2 Per User Attribute Limitation on Multiple Concurrent Sessions extends the functional coverage of FTE_MCS.1 by requiring the ability for a Security Administrator to specify limitations based on an authorised user's security attributes. Application Notes Audit 367 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the limitation on multiple concurrent session mechanism. D R A F T FTE_MCS - Limitation on Multiple Concurrent Sessions TOE Entry Page 84 of 246 CCEB-94/083 Version 0.90 94/10/31 b) Basic: All attempts at establishment of an user session. c) Detail: Capture of the number of concurrent user sessions and the user security attribute(s). Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF places limits on the number of concurrent sessions (per user attribute for FTE_MCS.2) [AFS_SPC Functional Specification]. b) Guidance on how to specify the number of allowed concurrent sessions [AGD_ADM Administrator guidance]. FTE_MCS.1 Basic Limitation on Multiple Concurrent Sessions Hierarchical to: no other components. Component rationale and application notes 368 This component allows a Security Administrator to place limits on the number of concurrent sessions that users are able to invoke. This provides some control over the amount of resources that users are allowed to consume, and provides protection against actions that can not be properly monitored or where procedural measures can not be properly put in place. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FTE_TEM.1 Basic TOE Entry Management AFS_SPC.2 Informal Security Policy Model Elements: FTE_MCS.1.1 The TSF shall provide the capability to limit the number of concurrent login sessions for authorised users. FTE_MCS.1.2 The number of concurrent login sessions shall only be specifiable by a Security Administrator. D R A F T TOE Entry FTE_MTE - Method of Entry 94/10/31 CCEB-94/083 Version 0.90 Page 85 of 246 FTE_MCS.1.3 The TOE supplied default shall be a single login session for all authorised users. FTE_MCS.2 Per User Attribute Limitation on Multiple Concurrent Sessions Hierarchical to: FTE_MCS.1 Component rationale and application notes 369 This component provides the Security Administrator with additional capabilities over those of FTE_MCS.1 by allowing the refinement of the limits placed on the number of concurrent sessions that users are able to invoke. These refinements are in terms of a user's security attributes, such as a user's identity, or membership to a role. This providing additional control over the amount of resources that users are allowed to consume, and provides protection against actions that can not be properly monitored or where procedural measures can not be properly put in place. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition AFS_SPC.2 Informal Security Policy Model Elements: FTE_MCS.2.1 The TSF shall provide a capability to limit the number of login sessions on a per user attribute basis. FTE_MCS.2.2 The number of concurrent login sessions shall only be specifiable by a Security Administrator. FTE_MCS.2.3 The TOE supplied default shall be a single login sessions for all authorised users. FTE_MTE Method of Entry Family behaviour 370 This family defines requirements that will limit the security attributes a user may select and the subjects a user may be bound to, based upon how the user session is initiated (e.g. ftp, rpc, dial-up, local terminal, etc.). D R A F T FTE_MTE - Method of Entry TOE Entry Page 86 of 246 CCEB-94/083 Version 0.90 94/10/31 Threats 371 This family addresses the treat of a user gaining access to resources, privileges, or information that is not appropriate for a particular method of entry. 372 This family addresses the threat of the exposure of information in an environment for which it is not appropriate. Other relevant families 373 FTE_MDE Mode of Entry 374 FTE_TME Time of Entry 375 FTE_LCE Location of Entry 376 FTE_SSL Session Locking 377 FTE_MCS Limitation on Multiple Concurrent Sessions Component levelling 378 There is only one component in this family Application Notes Audit 379 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the method of entry mechanism. b) Basic: All attempts at selecting a user attribute based on method of entry. c) Detail: Capture of the values of each user security attribute and method of entry. Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF places limits on the security attributes that a user may select and the subjects a user may be bound to, based upon how the user session is initiated [AFS_SPC Functional Specification]. D R A F T TOE Entry FTE_MDE - Mode of Entry 94/10/31 CCEB-94/083 Version 0.90 Page 87 of 246 b) Guidance on how to specify limitations on the attributes that a user may select based the method of entry [AGD_ADM Administrator guidance]. FTE_MTE.1 Method of Entry Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition FTE_TEM.1 Basic TOE Entry Management AFS_SPC.2 Informal Security Policy Model Elements: FTE_MTE.1.1 The TSF shall provide the capability to limit the security attributes a user is allowed to select based upon how the user session is initiated. FTE_MTE.1.2 The TSF shall provide the capability to limit the subjects a user may be bound to based upon how the user session is initiated. FTE_MTE.1.3 Limitations shall be specifiable only by a Security Administrator. FTE_MDE Mode of Entry Family behaviour 380 This family defines requirements that will limit the establishment of user sessions to the TOE based on a user's security attributes. For example these attributes would allow or deny session establishment based on: - A user's identity - A user's clearance level - A user's integrity level - A user's membership in a role. Threats 381 This family addresses the threat of a user gaining access to information for which the user is not authorised. D R A F T FTE_MDE - Mode of Entry TOE Entry Page 88 of 246 CCEB-94/083 Version 0.90 94/10/31 382 This family addresses the threat of a user performing actions for which the user is not authorised. Other relevant families 383 FTE_MDE Mode of Entry 384 FTE_TME Time of Entry 385 FTE_LCE Location of Entry Component levelling 386 There is only one component in this family Application Notes User Application Notes 387 Although a user maybe authorised to passes a specific security attribute (i.e., a clearance level, or a membership in a role), the user identity/security attribute combination may not be recognised or meaningful to a specific TOE. This is particularly relevant in situations where authorisation may take place at a different location then where access checks are performed. Audit 388 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the mode of entry mechanism. b) Basic: All attempts at establishment of a user session based on mode of entry. c) Detail: Capture of the value of each user security attribute. Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF places limits on TOE Entry based on user selected attributes [AFS_SPC Functional Specification]. b) Guidance on how to specify limitations of TOE Entry based on a users selected user attributes [AGD_ADM Administrator guidance]. D R A F T TOE Entry FTE_TME - Time of Entry 94/10/31 CCEB-94/083 Version 0.90 Page 89 of 246 FTE_MDE.1 Mode of Entry Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition AFS_SPC.2 Informal Security Policy Model FTE_TEM.1 Basic TOE Entry Management Elements: FTE_MDE.1.1 The TSF shall establish a session only in accordance with the authenticated user's policy attributes. FTE_MDE.1.2 Conditions for session establishment shall be expressed in terms of users' attribute(s). FTE_MDE.1.3 If no explicit conditions are defined, the TSF shall use the default entry condition. FTE_MDE.1.4 Session establishment conditions shall be specifiable only by a Security Administrator. FTE_TME Time of Entry Family behaviour 389 This family defines requirements for the TSF to be capable of allowing or denying TOE access based on specified ranges of time. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. Threats 390 This family addresses the threat of an otherwise authorised user, gaining access to the TOE during a period of time when access to the TOE is not permitted. 391 This family addresses the threat of an authorised user gaining access to the TOE at a time where proper monitoring or procedural measures cannot be adequately provided to support entry. D R A F T FTE_TME - Time of Entry TOE Entry Page 90 of 246 CCEB-94/083 Version 0.90 94/10/31 Component levelling 392 FTE_TME components are levelled based on the functional coverage for the TOE to place limits on the time of entry, uniformally for all authorised users of the TOE or selectively based on a user's selected security attributes. 393 The functional coverage for FTE_TME.1 Basic Time of Entry includes limitations that apply to all authorised users of the TOE. 394 FTE_TME.2 Selective Time of Entry extends the functional coverage of FTE_TME.1 by requiring the ability for a Security Administrator to specify limitations based on an authorised user's security attributes Other relevant families 395 FTE_MDE Mode of Entry 396 FTE_MTE Method of Entry 397 FTE_MCS Limitation on Multiple Concurrent Sessions 398 FTE_LCE Location of Entry Application Notes Audit 399 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the time of entry mechanism. b) Basic: All attempts at establishment of a user session based on time of entry. c) Detail: Capture of the value of the time and the user security attribute(s) . Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF places limits on TOE Entry based on the time-of-day, day-of-week, or calendar dates [AFS_SPC Functional Specification]. b) Guidance on how to specify limitations of TOE Entry based on time_of_day, Day-of-week, or calendar dates [AGD_ADM Administrator guidance]. D R A F T TOE Entry FTE_TME - Time of Entry 94/10/31 CCEB-94/083 Version 0.90 Page 91 of 246 FTE_TME.1 Basic Time of Entry Hierarchical to: no other components. Component rationale and application notes 400 This component allows a Security Administrator to place limits on the time intervals that users are allowed entry to the TOE. This provides some protection against actions that could occur, at a time where proper monitoring or where proper procedural measures may not be in place. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication AFS_SPC.2 Informal Security Policy Model FTE_TEM.1 Basic TOE Entry Management Elements: FTE_TME.1.1 The TSF shall allow or deny TOE Entry based on specified ranges of time. FTE_TME.1.2 The TSF shall provide the capability to specify the ranges of time that control TOE entry using time-of-day, day-of-week, and calendar dates. FTE_TME.1.3 Entry conditions shall be specifiable only by a Security Administrator. FTE_TME.2 Selective Time of Entry Hierarchical to: FTE_TME.1 Component rationale and application notes 401 This component provides the Security Administrator with additional capabilities over those of FTE_TME.1 by allowing the further specification of the limits placed on TOE Entry conditions. These additional controls provide the capability to specify user security attributes in conjunction with time intervals thereby further narrowing the scope of entry. For example, Security Administrators could allow users in a specific role to enter the TOE after normal working hour, while prohibiting all others. 402 This component allows a Security Administrator to place limits on the time intervals that users are allowed entry to the TOE on an attribute by attribute basis. This provides additional protection over FTE_TME.1 compliant TOEs against D R A F T FTE_LCE - Location of Entry TOE Entry Page 92 of 246 CCEB-94/083 Version 0.90 94/10/31 actions that could occur, at a time where proper monitoring or where proper procedural measures may not be in place. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition AFS_SPC.2 Informal Security Policy Model Elements: FTE_TME.2.1 The TSF shall allow or deny TOE Entry based on specified ranges of time and the users selected security attributes. FTE_TME.2.2 Entry conditions using these ranges shall be specified using time-of-day, day-of week, and calendar dates. FTE_TME.2.3 Entry conditions shall be specifiable only by a Security Administrator. FTE_LCE Location of Entry Family behaviour 403 This family defines requirements for the TSF to be capable of allowing or denying TOE access based on location or port of entry. Other relevant families 404 FTE_MDE Mode of Entry 405 FTE_MTE Method of Entry 406 FTE_TME Time of Entry Threats 407 This family reduces the threat of an otherwise authorised user, gaining access to the TOE, via a location or port that is not permitted by the TSP. 408 This family reduces the threat that sensitive information will be exposed in an area where all users are not known to be authorised to observe the data. D R A F T TOE Entry FTE_LCE - Location of Entry 94/10/31 CCEB-94/083 Version 0.90 Page 93 of 246 Component levelling 409 FTE_LCE components are levelled based on the functional coverage for the TOE to place limits on the location of entry, uniformally for all authorised users of the TOE or selectively based on a user's security attributes. 410 The functional coverage for FTE_LCE.1 Basic Location of Entry includes limitations that are based a user's location or port of entry. 411 FTE_LCE.2 Extended Location of Entry extends the functional coverage of FTE_LCE.1 by requiring the ability for a Security Administrator to specify TOE entry limitations that are based on a combination of a user's selected security attributes and the location or port of entry. Application Notes Audit 412 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the location of entry mechanism. b) Basic: All attempts at establishment of a user session based on location of entry. c) Detail: Capture of the value of the location and the user security attribute(s). Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF places limits on TOE Entry based on a users location [AFS_SPC Functional Specification]. b) Guidance on how to specify limitations of TOE Entry, based on a user's location [AGD_ADM Administrator guidance]. FTE_LCE.1 Basic Location of Entry Hierarchical to: no other components. Component rationale and application notes 413 This component provides the capability for a Security Administrator to limit user entry to the TOE based on location. This component is of particular use in environments where dial-up facilities or network facilities are available. D R A F T FTE_LCE - Location of Entry TOE Entry Page 94 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition AFS_SPC.2 Informal Security Policy Model FTE_TEM.1 Basic TOE Entry Management Elements: FTE_LCE.1.1 The TSF shall allow or deny an authorised user to establish a session with the TOE based on location or port of entry. FTE_LCE.1.2 Session establishment conditions shall be specifiable only by a Security Administrator. FTE_LCE.2 Extended Location of Entry Hierarchical to: FTE_LCE.1 Component rationale and application notes 414 This component provides an enhanced capability for a Security Administrator to limit user entry to the TOE based on a user's location and security attribute. This component provides further protection that sensitive information will not be disclosed in uncontrolled areas. This component is of particular use in environments where dial-up or network facilities are available. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition AFS_SPC.2 Informal Security Policy Model Elements: FTE_LCE.2.1 The TSF shall allow or deny an authorised user to establish a session with the TOE based on the location or port of entry. D R A F T TOE Entry FTE_TEH - TOE Entry History 94/10/31 CCEB-94/083 Version 0.90 Page 95 of 246 FTE_LCE.2.2 The TSF shall provide a mechanism to further limit session establishment based on a per location per user security attribute basis. FTE_LCE.2.3 Session establishment conditions shall be specifiable only by a Security Administrator. FTE_TEH TOE Entry History Family behaviour 415 This family defines requirements for the TSF to display to a user, upon successful entry into the TOE, a history of successful and unsuccessful attempts to access his account. This history may include the date, time, means of access, and port of entry, of the last successful entry to the TOE, as well as the number of successful, and unsuccessful attempts to access the TOE since the last successful entry by the identified user. Threats 416 This family reduces the threat that a user is unable to detect successful or unsuccessful penetration of his/her account. Component levelling 417 There is only one component in this family. Other relevant families No other relevant family. Application Notes Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF displays the TOE Entry History message to the user [AFS_SPC Functional Specification]. b) Guidance to users on how to use and understand the information presented to them regarding TOE entry history [AGD_USR User guidance]. D R A F T FTE_SSL - Session Locking TOE Entry Page 96 of 246 CCEB-94/083 Version 0.90 94/10/31 FTE_TEH.1 TOE Entry History Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication Elements: FTE_TEH.1.1 Upon a user's successful entry to the TOE, the TSF shall display the following data to the user and shall not remove them without user intervention: FTE_TEH.1.2 The date, time, means of access and port of entry of the last successful entry to the TOE; and FTE_TEH.1.3 The number of successful, and unsuccessful attempts to access the TOE since the last entry by the identified user. FTE_SSL Session Locking Family behaviour 418 This family defines requirements for the TSF to prove the capability for user initiated locking and unlocking of interactive sessions (e.g., keyboard locking). Other relevant families 419 FTP_TRP Trusted Path Threats 420 The requirements of this family reduce the threat of unauthorised use of active terminals that have accidentally or deliberately been left unattended and active. Component levelling 421 Session Locking components are levelled based on the coverage of specific conditions. 422 The functions covered at FTE_SSL.1 Session Locking and Unlocking include system initiated locking after a specified period of time. D R A F T TOE Entry FTE_SSL - Session Locking 94/10/31 CCEB-94/083 Version 0.90 Page 97 of 246 423 FTE_SSL.2 User-initiated Locking extends the functional coverage of FTE_SSL.1 by requiring the explicit user ability to lock and unlock the user's own interactive sessions. Application Notes Audit 424 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the time of session locking mechanism. b) Basic: All attempts at unlocking a session. Documentation The indicated assurance documentation (if applicable) shall contain the following information: a) Specification of the manner in which the TSF locks or terminates a user session [AFS_SPC Functional Specification]. b) Guidance on how to specify the interval of user inactivity before locking or terminating the session, and guidance on how to unlock a session [AGD_ADM Administrator guidance]. c) Guidance to users on how lock and unlock a session [AGD_USR User guidance]. FTE_SSL.1 Session Locking and Unlocking Hierarchical to: no other components. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition FTE_TEM.1 Basic TOE Entry Management D R A F T FTE_TEM - TOE Entry Management TOE Entry Page 98 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FTE_SSL.1.1 The TSF shall provide a mechanism that either locks or terminates an interactive session after an administrator-specified interval of user inactivity. FTE_SSL.1.2 The default value for this interval shall be specified. FTE_SSL.2 User-initiated Locking Hierarchical to: FTE_SSL.1 Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FIA_ATD.1 Minimal User Attribute Definition Elements: FTE_SSL.2.1 The TSF shall provide a mechanism that either locks or terminates an interactive session after an administrator-specified interval of user inactivity. FTE_SSL.2.2 The default value for this interval shall be specified. FTE_SSL.2.3 The TSF shall provide a mechanism to allow user-initiated locking of the user's own interactive sessions that include: FTE_SSL.2.4 Clearing or over-writing display devices to make the current contents unreadable; FTE_SSL.2.5 Requiring user authentication prior to unlocking the session; FTE_SSL.2.6 Disabling any activity of the user's data entry/display devices other then unlocking the session. FTE_TEM TOE Entry Management Family behaviour 425 This component defines requirements that enable Security Administrators to display and modify system entry parameters for use in system entry control. This family defines requirements to specify, remove or inspect TOE Entry parameters by an administrator. This family defines requirements for the setup of any TOE Entry security policy. D R A F T TOE Entry FTE_TEM - TOE Entry Management 94/10/31 CCEB-94/083 Version 0.90 Page 99 of 246 Threats 426 This component addresses the threats of inconsistency of setting up parameters or attributes. 427 This component addresses the threats of uncontrolled modification or access of the TOE Entry parameters. 428 This component addresses the threats of unauthorised modification or access of the TOE Entry parameters. Component levelling 429 This family is levelled based on the definition of the user authorised to manage the TOE Entry parameters. 430 In the first component, FTE_TEM.1 Basic TOE Entry Management only a Security Administrator is allowed to manage entry parameters. 431 In the second component, FTE_TEM.2 Role-based TOE Entry Management, the TOE Entry Administration role is introduced to manage the entry parameters. Application Notes Audit 432 The following actions should be audited if FAU Security Audit is in the PP/ST: a) Minimal: Successful use of the TOE Entry Management mechanism. b) Basic: All attempts to use TOE Entry Management mechanism. c) Basic: Identification of which TOE Entry parameters have been modified. d) Detailed: Modification of existing system entry parameters for use in TOE Entry control. Also, the new values of the parameters must be captured. Documentation 433 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Guidance on how to use the TOE Entry Management mechanism [AGD_USR User guidance and AGD_ADM Administrator guidance]. b) Specification of the TSF provided TOE Entry Management mechanism [ADV_HLD High-level design, ADV_TIS TSF interface specification]. D R A F T FTE_TEM - TOE Entry Management TOE Entry Page 100 of 246 CCEB-94/083 Version 0.90 94/10/31 FTE_TEM.1 Basic TOE Entry Management Hierarchical to: no other components. Component rationale and application notes 434 For this component, Security Administrators are permitted to display or modify TOE Entry parameters. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FPT_TSA.1 Basic Security Administration Elements: FTE_TEM.1.1 The TSF shall provide a mechanism for authorised users to display and modify TOE Entry parameters. FTE_TEM.1.2 The TSF shall provide administrators with the capability for at least one of the following options: a) To list all the TSP entry parameters for a user. b) To list all the users associated with a parameter. FTE_TEM.1.3 The TSF shall restrict use of TOE Entry Management functions to a Security Administrator. FTE_TEM.2 Role-based TOE Entry Management Hierarchical to: FTE_MTE.1 Component rationale and application notes 435 This component should be used when multiple security administrative roles are defined.It introduces the concept of the authorised user being the TOE Entry Administrator. Operations No permitted operation. D R A F T TOE Entry FTE_TEM - TOE Entry Management 94/10/31 CCEB-94/083 Version 0.90 Page 101 of 246 Dependencies: FIA_UID.2 Unique Identification of Users FIA_UAU.1 Basic User Authentication FPT_TSA.3 Multiple Security Administrative Roles Elements: FTE_TEM.2.1 The TSF shall provide a mechanism for authorised users to display and modify TOE Entry parameters. FTE_TEM.2.2 The TSF shall provide administrators with the capability for at least one of the following options: a) To list all the TSP entry parameters for a user. b) To list all the users associated with a parameter. FTE_TEM.2.3 The TSF shall restrict use of these functions to a the TOE Entry Administrator role . FTE_TEM.2.4 The TSF shall provide an TOE Entry Administrator role which is limited to only performing those activities directly associated with TOE Entry parameter administration. D R A F T FTE_TEM - TOE Entry Management TOE Entry Page 102 of 246 CCEB-94/083 Version 0.90 94/10/31 D R A F T 172 CCEB-94/083 94/10/31 Version 0.90 Page 103 of 246 Class FDP User Data Protection 436 User Data Protection applies to the definition of access policies defined between users, subjects, objects, and information. The inclusion of those policies and mechanisms here does not preclude the use of these same mechanism to protect TSF information. Class organisation 437 The families in this class are organised in five groups: a) Forms of Data Protection: This includes FDP_ACC Access Control, FDP_IFC Information Flow Control, and FDP_RIP Residual Information Protection. Components in these families address the policies through which information protection goals are specified. b) Data Protection Mechanisms: This includes FDP_ACM Access Control Mechanisms and FDP_IFM Information Flow Control Mechanisms. Components in these families address mechanisms by which information and objects are protected and that implement the data protection policies. c) Security Attribute Management: This includes FDP_SAQ Security Attribute Query, FDP_SAM Security Attribute Modification, and FDP_SAI Security Attribute Initialisation. Components in these families address the behaviour of interfaces for managing the security attributes that control the data protection mechanisms. d) Off-line Storage and Communication: This includes FDP_ITC Import from Outside TSF Control and FDP_ETC Export to Outside TSF Control. Components in these families address the trustworthy transfer of information across the TSF's protection boundary. e) Inter-TSF Communication: This includes FDP_ITP Information Transfer Protection and FDP_SAT Security Attribute Transfer. Components in these families address communication between TSFs. The distinction between this and import/export is that for import/export, the other end of the communication need not be known, it merely has some required characteristics, whereas in inter-TSF communication, the two end points are assumed to be known and to some degree pre-configured to support the communication. D R A F T User Data Protection Page 104 of 246 CCEB-94/083 Version 0.90 94/10/31 User Data Protection | | 1 - 2 - 3 | - FDP_ACC < | 4 - 5 - 6 | | - FDP_IFC - 1 - 2 - 3 - 4 - 5 - 6 | | 1 - 2 | - FDP_RIP < | 3 - 4 | | 1 - 2 | / 3 - 4 | / 5 - 6 | - FDP_ACM < | \ 7 - 8 | \ 9 - 10 | 11 - 12 | | 2 | / 1 < | / 3 | / | / 5 | - FDP_IFM - 4 < | \ 6 | \ | \ 7 - 8 | | - FDP_SAQ - 1 - 2 | | 1 - 2 | - FDP_SAM < | 3 | | 1 - 2 - 3 | - FDP_SAI < | 4 V continued Figure 2.6 - User Data Protection class decomposition D R A F T User Data Protection 94/10/31 CCEB-94/083 Version 0.90 Page 105 of 246 ^ | - FDP_ITC - TBD | | - FDP_ITC - TBD | | 1 | - FDP_ITC < 3 | 2 < > 5 | 4 | | - FDP_ITC - 1 | | - FDP_ITC - 1 - 2 Figure 2.7 - User Data Protection class decomposition (cont.) Class Notes 438 This class is structured around types of control: access control, information flow control, and residual information protection. Each of these represents a fundamentally different intent on the part of the controlling authority. It avoids the traditional terminology of "mandatory" and "discretionary" access control, because these terms are often applied inconsistently outside the context of access controls for a file system. 439 This class also treats the traditional policy elements of confidentiality, integrity, and availability as aspects of control mechanisms, rather than the other way around. This structure appears to tit real systems more naturally, because most control mechanisms actually have elements of all three control policies. For example, a typical Access Control List (ACL) mechanism for file objects protects both against unauthorised read operations ("confidentiality") and unauthorised write operations ("integrity"). Arguably, it even provides "availability" by protecting against unauthorised destruction (overwriting or deleting a file). It introduces needless complication to characterise such a mechanism in terms of three "distinct" policies, the function and purpose of the ACL mechanism is clear, and the distinction by policy type is artificial and undesirable. 440 A final aspect of this class is that it specifies access controls in terms of "operations". An operation is defined as a specific type of access on a specific object type. Although information flow must ultimately be described in terms of "read" (flow into) and "write" (flow out of), access control need not be. In real systems, access control often involves higher-level abstractions such as "open a D R A F T User Data Protection Page 106 of 246 CCEB-94/083 Version 0.90 94/10/31 file", "mount a tape", "authorise a payment", "deliver a message", etc., rather than only the two operations that can be modelled as "read" and "write". 441 This class is not meant to be a complete taxonomy of control types: others can be imagined and can be added to this framework as warranted. Those included here are simply those for which our experience with actual systems gives us a basis for specifying. There may be other forms of intent which are not captured in the definitions here. Construction rules 442 The following construction rules are intended to provide guidelines on creating packages of components which characterise and provide useful security functional requirements for user data protection policies enforced by a TSF. Although they say package, this could be part of the construction of a PP or ST just as easily. 443 The following steps are performed to determine how this class is applied in the construction of a package describing the requirements for a security function which does access control: a) Identify the access control objectives for the package and an intended access control policy in terms of controlled operations and coverage of objects in the TOE b) If the TSF performs access control on a subset of objects, identify applicable components from FDP_ACC.1 and FDP_ACC.2, or, if the TSF performs access control on all objects, FDP_ACC.3. c) If the TSF performs a fixed protection policy on a subset of objects, identify applicable components from FDP_ACC.4, FDP_ACC.5, and FDP_ACC.6. d) Identify one or more access control mechanism components from the FDP_ACM family. e) Identify one or more security attribute management components from the FDP_SAQ, FDP_SAM, and FDP_SAI families. f) Identify any applicable components for residual information protection from the FDP_RIP family. g) Identify any applicable import or export components from the FDP_ITC and FDP_ETC families. h) Identify any applicable inter-TSF communication components from the FDP_ITP and FDP_SAT families. i) Craft an overall behaviour for the package and apply applicable operations to each component to tailor the behaviour of the component to the package behaviour. D R A F T User Data Protection FDP_ACC - Access Control 94/10/31 CCEB-94/083 Version 0.90 Page 107 of 246 444 The following steps are performed to determine how this class is applied in the construction of a package describing the requirements for a security function which enforces information flow controls: a) Identify the information flow control objectives for the package and an intended information flow control policy in terms controlled operations and coverage of the objects in the TOE. b) Identify an information flow control policy component from the FDP_IFC family. c) Identify one or more information flow control mechanism components from the FDP_IFM family. d) Identify one or more security attribute management components from the FDP_SAQ, FDP_SAM, and FDP_SAI families. e) Identify any applicable components for residual information protection from the FDP_RIP family. f) Identify any applicable import or export components from the FDP_ITC and FDP_ETC families. g) Identify any applicable inter-TSF communication components from the FDP_ITP and FDP_SAT families. h) Craft an overall behaviour for the package and apply applicable operations to each component to tailor the behaviour of the component to the package behaviour. FDP_ACC Access Control Family behaviour 445 This family defines the rules that permit operations to be controlled. It is based upon the concept that a user or subject may have authority to impose controls defining what other users or subjects may perform certain operations. Different degrees of control may be specified here, and this family may be applied multiple times to different subsets of operations, with different policies for each. This family includes both those forms of access control normally considered "user-specified" and those considered "Security Administrator-specified". 446 Examples of mechanisms that might satisfy this objective are: - Access Control Lists [ref. to Multics] - Access Profiles [ref. to IBM RACF] - Clark-Wilson TPs [ref. to Clark-Wilson paper] - Role-Based Access Controls [ref. to NIST specs] - POSIX set-ID Mechanism [ref. to P1003.1] D R A F T FDP_ACC - Access Control User Data Protection Page 108 of 246 CCEB-94/083 Version 0.90 94/10/31 447 This family is needed to specify the requirements for policies applied to operations and objects within the TOE. The distinctions among components permit the policy to be specified as completely as desired to satisfy the protection goals of the TOE. Because this family can be applied multiply to different subsets of operations and objects, it is flexible enough to accommodate real system implementations. Threats 448 This family addresses the risk that users will be unable to protect information for which they are responsible in accordance with their wishes. 449 This family addresses the risk that the TOE could be used in a way that protects the information it processes. 450 This family addresses the threat that a specified organisational security policy could be circumvented by unauthorised users. 451 This family addresses the threat that a violation of an organisation's security policy will go undetected by Security Administrators. Other relevant families 452 FDP_ACM Access Control Mechanisms 453 FDP_SAQ Security Attribute Query 454 FDP_SAM Security Attribute Modification 455 FDP_SAI Security Attribute Initialisation 456 FDP_ITC Import from Outside TSF Control 457 FDP_ETC Export to Outside TSF Control 458 FDP_ITP Information Transfer Protection 459 FDP_SAT Security Attribute Transfer 460 FPT_RVM Reference Mediation Component levelling 461 This family distinguishes two hierarchies of components based upon completeness of coverage for the access control policy (the first three) and completeness of protection for operations and objects not controlled by the policy (the last three). The requirements for coverage rely on the concept of "intended use"; that is, the way in which the system developer defines the object and the purpose it is intended to serve for users of the TSF. D R A F T User Data Protection FDP_ACC - Access Control 94/10/31 CCEB-94/083 Version 0.90 Page 109 of 246 462 The access control components are: 463 FDP_ACC.1 Subset Access Control requires that an access control policy be in place for a subset of the possible operations in the TOE. 464 FDP_ACC.2 Object Access Control requires that all of the operations be controlled for a specified set of the objects in the TOE. 465 FDP_ACC.3 Complete Access Control requires that all operations on all objects in the TOE which are intended use of sharing be controlled. 466 The fixed protection components are: 467 FDP_ACC.4 Subset Fixed Protection requires that a fixed protection policy be in place for a subset of the available operations in the TOE. 468 FDP_ACC.5 Object Fixed Protection requires that all of he operations be controlled for a specified set of the objects in the TOE. 469 FDP_ACC.6 Complete Fixed Protection requires that all of the operations on be controlled for all of the objects in the TOE which are not intended for sharing. Application Notes User Application Notes 470 An access control policy covers a well-defined set of operations. The policy's coverage may be "complete" with respect to some object or it may address only some of the operations that affect the object. A critical aspect of an access control policy is that it may be specified; that is, it is based upon some changeable attribute that determines who may perform an operation. 471 A fixed protection policy, in contrast to an access control policy, is one that is constant: it is a built-in property of the operation, object, or system and may not be changed. The TOE's fixed protection policy (to the extent that it is specified) describes how operations that are not part of the access control scheme are protected from unwanted use. 472 In general, it is not sensible to require an access control mechanism for "all objects". Even in a highly secure system, there are certain to be objects for which an access control mechanism (such as ACLs) is simply unnecessary. What is necessary is that all objects be protected in a manner appropriate for their intended use. The concept of "intended use" is used in these components to characterise the thoroughness of control. It is meant to capture the notion that the developer of the package gets to define the ways in which users are intended to control sharing of the objects they "own" or are responsible for. 473 The FDP_ACC.1 Subset Access Control component can stand alone, or be paired with FDP_ACC.4 Subset Fixed Protection or with FDP_ACC.5 Object Fixed D R A F T FDP_ACC - Access Control User Data Protection Page 110 of 246 CCEB-94/083 Version 0.90 94/10/31 Protection. Similarly, FDP_ACC.2 Object Access Control can sensibly be paired with FDP_ACC.4 Subset Fixed Protection or FDP_ACC.5 Object Fixed Protection, or can stand alone. This pairing provides coverage that is complete, but may not be appropriate with respect to the intended use of the protected objects. The FDP_ACC.3 Complete Access Control component can sensibly be paired with FDP_ACC.5 Object Fixed Protection or FDP_ACC.6 Complete Fixed Protection. The latter choice provides the most complete access control and appropriate protection coverage for all objects. Audit 474 The audit rules for this family are stated for this, the policy aspect, rather than for any related families (e.g. FDP_ACM, FDP_SAM, FDP_SAI) that implement the policy. 475 The following auditable actions should be considered if Security Audit is included in a PP/ST: a) Minimal: Decisions to permit a requested operation. b) Basic: Decisions to deny a requested operation. c) Detailed: The specific security attributes used in making an access check. Documentation 476 If AGD_USR User guidance or AGD_ADM Administrator guidance is applicable, either or both of these documents, as appropriate, shall provide guidance with respect to each access control policy satisfying an FDP_ACC component. Documentation shall be provided for end-users, Security Administrators, or both, as appropriate for the nature of the objects and operations controlled by the policy. 477 The guidance documentation shall describe the nature and scope of each access control policy and briefly describe the mechanisms that implement the policy (FDP_ACM), the security attributes that govern the policy (FDP_SAQ, FDP_SAM), the initialisation rules for those attributes (FDP_SAI), and (if any) the default mechanisms for those attributes (FDP_SAI). 478 The guidance documentation shall also provide guidance on the safe and effective use of the mechanisms. D R A F T User Data Protection FDP_ACC - Access Control 94/10/31 CCEB-94/083 Version 0.90 Page 111 of 246 FDP_ACC.1 Subset Access Control Hierarchical to: no other components. Component rationale and application notes User Application Notes 479 This component simply specifies that the policy cover some well-defined set of operations and places no constraints on any operations outside the set including operations on objects for which other operations are controlled. Documentation 480 The ADV_FSP Functional specification shall define the subset of operations controlled by the policy, describe the intended use of the operations and provide a detailed rationale for the scope of the subset. Operations Assignment: 481 In FDP_ACC.1.1, specify operations to which the requirements in this component are being applied. 482 In FDP_ACC.1.2, specify the list of degrees of flexibility which must be supported for each controlled operation. Dependencies: No dependencies. Elements: FDP_ACC.1.1 The TSF shall enforce an access control policy on the following operations: [List of operations to be protected] FDP_ACC.1.2 The TSF shall support the following degrees of flexibility in the controlling these operations: [The list of degrees of flexibility which must be supported] D R A F T FDP_ACC - Access Control User Data Protection Page 112 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ACC.2 Object Access Control Hierarchical to: FDP_ACC.1 Component rationale and application notes User Application Notes 483 This component specifies that the policy must cover all operations on an object if it covers any, but still permits the set of controlled objects to be chosen arbitrarily. Documentation 484 The ADV_FSP Functional specification shall define the subset of operations controlled by the policy, describe the intended use of the operations, and provide a detailed rationale for the scope of the subset and why this completely controls all access to the objects which are the targets of the operations. Operations Assignment: 485 In FDP_ACC.2.1, specify the objects to which the requirements in this component are being applied. 486 In FDP_ACC.2.3, specify the list of degrees of flexibility which must be supported for each controlled operation. Dependencies: No dependencies. Elements: FDP_ACC.2.1 The TSF shall apply an access control policy to the following objects : [List of objects to be protected] FDP_ACC.2.2 The TSF shall enforce an access control policy on all operations affecting these objects. FDP_ACC.2.3 The TSF shall support the following degrees of flexibility in controlling these operations: [The list of degrees of flexibility which must be supported] D R A F T User Data Protection FDP_ACC - Access Control 94/10/31 CCEB-94/083 Version 0.90 Page 113 of 246 FDP_ACC.3 Complete Access Control Hierarchical to: FDP_ACC.2 Component rationale and application notes User Application Notes 487 This component requires that all objects for which it is sensible have access control; that is, all objects whose intended use involves some control of sharing; shall be protected by an access control policy. Documentation 488 The AGD_ADM Administrator guidance shall define the subset of operations controlled by the policy, describe the intended use of the operations, and provide a detailed rationale for the scope of the subset. The rationale shall be sufficient to convince the evaluator that all objects intended for sharing have been protected by the access control. 489 The ADV_TIS TSF interface specification shall, if in the PP or ST, be used to provide evidence for the rationale that all of the objects intended for sharing have been protected by the access control. Operations 490 In FDP_ACC.3.3, insert the list of degrees of flexibility which must be supported for each operation for each object. Dependencies: No dependencies. Elements: FDP_ACC.3.1 The TSF shall apply an access control policy to all objects whose intended purpose is the sharing of information between subjects. FDP_ACC.3.2 The TSF shall enforce an access control policy on all operations affecting these objects. FDP_ACC.3.3 The TSF shall support the following degrees of flexibility in controlling these operations: [The list of degrees of flexibility which must be supported] D R A F T FDP_ACC - Access Control User Data Protection Page 114 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ACC.4 Subset Fixed Protection Hierarchical to: No other components. Component rationale and application notes User Application Notes 491 This component requires that a fixed protection policy be in place for a subset of the available operations on a subset of the objects in the TOE. 492 When building a package with this component and FDP_ACC.1, it is possible that some of the same objects could be protected by the policy in each component but that different operations will be controlled. Documentation 493 The ADV_FSP Functional specification shall define the subset of the possible operations in the TOE subject to this policy, describe the intended use of the operations, and provide a detailed rationale for the scope of the subset. Operations Assignment: 494 In FDP_ACC.4.1, specify the operations to which the requirements in this component apply. Dependencies: FDP_ACC.1 Subset Access Control Elements: FDP_ACC.4.1 The TSF shall enforce an fixed protection policy on the following operations: [List of operations to be protected] FDP_ACC.5 Object Fixed Protection Hierarchical to: FDP_ACC.4 Component rationale and application notes User Application Notes 495 This component requires that a fixed protection policy be in place for all operations on a subset of the objects in the TOE. D R A F T User Data Protection FDP_ACC - Access Control 94/10/31 CCEB-94/083 Version 0.90 Page 115 of 246 Documentation 496 The ADV_FSP Functional specification shall define the subset of the objects in the TOE subject to this policy, describe the intended use of the objects, and provide a detailed rationale for the scope of the subset. Operations Assignment: 497 In FDP_ACC.5.1, specify the objects to which the requirements in this component are being applied. Dependencies: FDP_ACC.1 Subset Access Control Elements: FDP_ACC.5.1 The TSF shall apply a fixed protection policy to the following objects: [List of objects to be protected] FDP_ACC.5.2 The TSF shall enforce an fixed protection policy on these objects with respect to all operations. FDP_ACC.6 Complete Fixed Protection Hierarchical to: FDP_ACC.5 Component rationale and application notes User Application Notes 498 This component requires that a fixed protection policy be in place for all operations on all of the objects in the TOE not protected by the access control policy defined in the FDP_ACC.3 dependency. Documentation 499 The ADV_FSP Functional specification shall define the subset of the objects in the TOE subject to this policy, describe the intended use of the objects, and provide a detailed rationale for the scope of the subset. Operations No permitted operation. Dependencies: FDP_ACC.3 Complete Access Control D R A F T FDP_IFC - Information Flow Control User Data Protection Page 116 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FDP_ACC.6.1 The TSF shall apply a fixed protection policy to all objects whose intended purpose is not the sharing of information between subjects. FDP_ACC.6.2 The TSF shall enforce an fixed protection policy on these objects with respect to all operations. FDP_IFC Information Flow Control Family behaviour 500 This family defines the rules that prevent the unauthorised flow of information between subjects. Examples of mechanisms that might satisfy this objective are: - Bell and La Padula Security model [ref. to B&L paper] - Biba Integrity model [ref. to Biba paper] - Assured Pipelines [ref. to LOCK paper] - Separation Kernel [ref. to Rushby paper] Rationale 501 This family is distinct from FDP_IFM Information Flow Control Mechanisms in order to separate policy from mechanism. The policies described by these components represent an ordered set of "goodness" of flow control, without requiring any specific control mechanisms or objectives. 502 An information flow control policy controls the flow of information between subjects, without regard to the operations they perform. This is much like traditional Mandatory Access Control mechanisms, except the requirements are policy independent, they allow the domain of flow control to be specified, and there is no requirement that the mechanism be based upon labels. The different strengths of the information flow control components also permit different degrees of exception to the policy. These policies must be applied over the whole TOE (to the degree permitted by the quality of specification) to provide real protection. User Application Notes 503 In this family, it is important to remember that the definition of objects is any resource which is encapsulated in any way by the TSF. A subject can only interact with objects and not with raw unencapsulated resources. Threats 504 This family addresses the threat that a subject can cause information to be disclosed or modified in violation of an organisation's security policy. 505 This family addresses the risk that violations of an organisation's security policy could go undetected. D R A F T User Data Protection FDP_IFC - Information Flow Control 94/10/31 CCEB-94/083 Version 0.90 Page 117 of 246 Other relevant families 506 FDP_IFM Information Flow Control Mechanisms 507 FDP_SAQ Security Attribute Query 508 FDP_SAM Security Attribute Modification 509 FDP_SAI Security Attribute Initialisation 510 FDP_ITC Import from Outside TSF Control 511 FDP_ETC Export to Outside TSF Control 512 FDP_ITP Information Transfer Protection 513 FDP_SAT Security Attribute Transfer 514 FPT_SEP Domain Separation 515 FPT_RVM Reference Mediation Component levelling 516 This family defines a hierarchy of six components to capture the degrees to which information flow may be controlled. Also, there is an explicit distinction between "control" and "limit": the former means to control, but imperfectly without specific knowledge of how imperfectly; the latter means to place specific limits. 517 The following three components permit arbitrary information flows as side-effects (i.e. covert channels) without any restrictions or analysis on these information flows. The validity of these components for a given environment is based upon the threats and the threat intensity. 518 Component FDP_IFC.1 Subset flow control requires only that a limited subset of the possible flows between subjects and a defined subset of the objects in the TOE be controlled. 519 Component FDP_IFC.2 Object Flow Control requires that all possible operations by subjects on the protected objects be controlled. 520 Component FDP_IFC.3 Specified Flow Control requires that all operations by subjects on all of objects in the TOE be protected by the information flow control policy. 521 The next three components provide for increasingly strict controls on the information flows which are possible through side-effects with the last component requiring that it be demonstrated that no such flows exist in the TOE. D R A F T FDP_IFC - Information Flow Control User Data Protection Page 118 of 246 CCEB-94/083 Version 0.90 94/10/31 522 Component FDP_IFC.4 Bounded Flow Control requires that limits for information flows through some sub-set of the observed side-effects should be bounded to certain bandwidths. 523 Component FDP_IFC.5 Complete Operation Flow Control requires that limits for information flows through all observed side-effects should be bounded to stated bandwidths. 524 Component FDP_IFC.6 Complete Flow Control requires elimination of covert channels. Application Notes Audit 525 The audit rules for this family are stated for this, the policy aspect, rather than for any related families (e.g. FDP_IFM, FDP_SAM, etc.) that implement the policy. 526 he following auditable actions should be considered if Security Audit is included in a PP/ST: a) Minimal: Decisions to permit a requested information flows. b) Basic: Decisions to deny a requested information flow. c) Basic: Use of operations in the TOE which do not support the information flow policy. d) Detailed: The specific security attributes used in making an information flow enforcement decision e) Detailed: Some specific subsets of the information which has flowed based upon policy goals (e.g. auditing of downgraded material). Documentation 527 AGD_USR User guidance and AGD_ADM Administrator guidance shall provide guidance with respect to each information flow control policy satisfying an FDP_IFC component. 528 The guidance documentation shall describe the nature and scope of each information flow control policy. It shall also provide guidance on the safe and effective use of the information flow security functions in the TSF. 529 The administrative guidance shall describe the rationale for the scope of each information flow control policy. D R A F T User Data Protection FDP_IFC - Information Flow Control 94/10/31 CCEB-94/083 Version 0.90 Page 119 of 246 FDP_IFC.1 Subset flow control Hierarchical to: No other components. Component rationale and application notes User Application Notes 530 This component requires that an information flow control policy apply to a subset of the possible operations in the TOE. It addresses the threat that users will violate the rules for information flow in normal operation (with respect to the protected subset of objects) of the TOE and in the absence of hostile intent. Operations Assignment: 531 In FDP_IFC.1.1, specify the list of operations in the TOE which are subject to the information flow policy. Dependencies: No dependencies. Elements: FDP_IFC.1.1 The TSF shall enforce an information flow policy for the following operations: [List of objects which are subject to the information flow policy] FDP_IFC.2 Object Flow Control Hierarchical to: FDP_IFC.1 Component rationale and application notes User Application Notes 532 This component requires only information controls between subjects and all operations on a subset of the objects in the TOE. It differs from FDP_IFC.1 in that it requires all operations on the protected objects to be subject to the information flow control policy. It should address the additional threat beyond FDP_IFC.1 that it protects against accidental violations of the flow control rules. Deliberate attempts to violate the rules can still be carried out by moving information through unprotected objects. D R A F T FDP_IFC - Information Flow Control User Data Protection Page 120 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations Assignment: 533 In FDP_IFC.2.1, specify the list of objects in the TOE which are subject to the information flow policy. Dependencies: No dependencies. Elements: FDP_IFC.2.1 The TSF shall enforce an information flow policy for the following objects: [List of objects which are subject to the information flow policy] FDP_IFC.2.2 The TSF shall apply the information flow policy to all operations by subjects on the protected objects. FDP_IFC.3 Specified Flow Control Hierarchical to: FDP_IFC.2 Component rationale and application notes User Application Notes 534 This component is stronger than FDP_IFC.2 Object Flow Control, in that all objects in the TOE must be protected for all operations, but only to the extent that the TSF specifications identify the objects and operations. It may still be possible that there are objects in the TOE which could not be identified from the specification (i.e. they are unknown) or that there are operations which can be carried out by a subject which are not carried out on an object but which allow a subject to take advantage of a side effect of the operation to create an information flow. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFC.3.1 The TSF shall enforce an information flow policy on all objects in the TOE . FDP_IFC.3.2 The TSF shall apply the information flow policy to all operations by subjects on the protected objects. D R A F T User Data Protection FDP_IFC - Information Flow Control 94/10/31 CCEB-94/083 Version 0.90 Page 121 of 246 FDP_IFC.4 Bounded Flow Control Hierarchical to: FDP_IFC.3 Component rationale and application notes User Application Notes 535 This is the first component to address covert channels. It requires that a covert channel analysis be carried out on the TOE and that a specified set of limits on some of the identified covert channels be applied. In general, this component should be used to limit covert channels which are "required by the specification," as removing these covert channels would require changing the specification and thus require changing other requirements for the TOE such as performance, user friendliness, etc. which may not always be possible or cost effective. Operations Assignment: 536 In FDP_IFC.4.3, identify a list of accepted covert channels and a maximum acceptable bandwidth for each. Dependencies: AVA_CCA.1 Storage channel analysis Elements: FDP_IFC.4.1 The TSF shall enforce an information flow policy on all objects in the TOE. FDP_IFC.4.2 The TSF shall apply the information flow policy to all operations by subjects on the protected objects. FDP_IFC.4.3 The TSF shall limit to the specified bandwidths the following identified information flows which are in violation of the objectives: [Fill in a list of accepted covert channels and a maximum bandwidth for each] D R A F T FDP_IFC - Information Flow Control User Data Protection Page 122 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_IFC.5 Complete Operation Flow Control Hierarchical to: FDP_IFC.4 Component rationale and application notes User Application Notes Operations Assignment: 537 In FDP_IFC.5.3, specify a maximum acceptable covert channel bandwidth which is allowed to exist in the TOE. Dependencies: AVA_CCA.2 Timing channel analysis Elements: FDP_IFC.5.1 The TSF shall enforce an information flow policy on all objects in the TOE. FDP_IFC.5.2 The TSF shall apply the information flow policy all operations by subjects on the protected objects. FDP_IFC.5.3 The TSF shall limit the total bandwidth of all identified covert channels to less than: [Fill in the maximum acceptable covert channel bandwidth] FDP_IFC.6 Complete Flow Control Hierarchical to: FDP_IFC.5 Component rationale and application notes User Application Notes 538 FDP_IFC.6 Complete Flow Control simply requires that no covert channels remain in the TOE at the conclusion of evaluation. While impractical and possibly impossible to implement in a general-purpose product, it may be meaningful for some specialised devices performing very simple functions which require that information only flow according to the specified policy. Operations No permitted operation. D R A F T User Data Protection FDP_RIP - Residual Information Protection 94/10/31 CCEB-94/083 Version 0.90 Page 123 of 246 Dependencies: AVA_CCA.3 Formal covert channel analysis Elements: FDP_IFC.6.1 The TSF shall enforce an information flow policy on all objects in the TOE. FDP_IFC.6.2 The TSF shall apply the information flow policy on all operations by subjects on the protected objects. FDP_IFC.6.3 No information flows which violate the information flow control policy shall exist in the TOE. FDP_RIP Residual Information Protection Family behaviour 539 This family addresses the need to ensure that deleted information is no longer accessible, and that newly-created objects do not contain information that should not be accessible. Rationale 540 This family requires protection for information that has been logically deleted or released, but may still be physically present within the TOE. The distinction between components is based upon the degree of coverage: the less strong components require coverage only for some objects, whereas the stronger components require that all objects be protected. 541 The residual information protection policy controls access to information that is not part of any currently defined or accessible object. In particular, this includes information that is part of objects based upon reusable resources in the TOE where destruction of the object does not necessarily equate to destruction of the resource or any contents of the resource. 542 These elements are stated in terms of the access control (FDP_ACC) and information flow control (FDP_IFC) policies in order to avoid creating a new definition for "forbidden" access. This is intended to permit implementations, for instance, that allow reuse of a "deleted" object by the same subject that deleted it, if the request is made before object's storage is reused. In addition, to the extent that cryptography would be sufficient to protect "live" information against unauthorised access under those policies, it is similarly possible to protect released or deleted information using cryptography. D R A F T FDP_RIP - Residual Information Protection User Data Protection Page 124 of 246 CCEB-94/083 Version 0.90 94/10/31 Threats 543 This family addresses the threat that a user or subject will receive information about another user's or subject's activities without proper authorisation. 544 This family addresses the threat that a user or subject will receive information about internal activities of the TSF without proper authorisation. 545 This family addresses the threat that deleted information will become accessible to unauthorised subjects. Other relevant families 546 The access and information flows permitted by this family's components are defined in terms of the policies in: 547 FDP_ACC Access Control 548 FDP_IFC Information Flow Control 549 FPT_SEP Domain Separation 550 FPT_RVM Reference Mediation Component levelling 551 There are four components defined by this family in two parallel hierarchicies.The first two deal with destruction of residual information at the time of deletion of the containing object. The second two deal with clearing the contents of any resources being used in the creation of a new object. 552 FDP_RIP.1 Subset Deletion Protection states requirements for the destruction of the information content of an object at the time of deletion, destruction or deallocation but allows the requirements to apply to only a subset of the objects in the TOE. 553 FDP_RIP.2 Full Deletion Protection requires that the residual information protection policy apply to all of the objects in the TOE. 554 FDP_RIP.3 Subset Creation Protection states requirements for the destruction of any information content of any resources being allocated to a defined subset of the newly created or re-initialised objects in the TOE. 555 FDP_RIP.4 Full Creation Protection requires that the TSF destroy any information content of any resources being allocated to any newly created or re-initialised object in the TOE. D R A F T User Data Protection FDP_RIP - Residual Information Protection 94/10/31 CCEB-94/083 Version 0.90 Page 125 of 246 Application Notes Audit 556 Residual information protection will probably be an inherent underlying policy which is not user accessible and may not have any security relevant events. The following are therefore guidelines for events which might be auditable predicated upon the existence of such events: a) Minimal: Enabling and/or disabling of the residual information protection. b) Basic: Use of any configuration tools provided for the administration of residual information protection mechanisms. c) Detailed: Any changes made to the configuration of the residual information protection mechanisms. FDP_RIP.1 Subset Deletion Protection Hierarchical to: No other components. Component rationale and application notes User Application Notes 557 This component is intended to allow the specification of requirements which mandate the protection of any information stored in some possible subset of the objects in the TOE upon the deletion, destruction or deallocation of the object or any part of the object. 558 This component is expressly useful in defining the residual information protection requirements for a package which is being applied to only a subset of the objects in a TOE. Operations Assignment: 559 In FDP_RIP.1.1, define the subset of the objects in the TOE to which the requirements of this component apply. Dependencies: No dependencies. Elements: FDP_RIP.1.1 The TSF shall enforce a residual information protection policy on the following objects: D R A F T FDP_RIP - Residual Information Protection User Data Protection Page 126 of 246 CCEB-94/083 Version 0.90 94/10/31 [List of the objects protected by the residual information protection policy] FDP_RIP.1.2 For each protected object, the TSF shall ensure that upon the deletion, destruction or deallocation of any part of the object that any information content of the part is protected from unauthorised release. FDP_RIP.2 Full Deletion Protection Hierarchical to: FDP_RIP.1 Component rationale and application notes User Application Notes 560 This component is intended to allow the specification of requirements which mandate the protection of any information stored in any object in the TOE upon the deletion, destruction or deallocation of the object or any part of the object. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_RIP.2.1 The TSF shall enforce residual information protection on all of the objects in the TOE. FDP_RIP.2.2 For each protected object, the TSF shall ensure that upon the deletion, destruction or deallocation of any part of the object that any information content of the part is protected from unauthorised release. FDP_RIP.3 Subset Creation Protection Hierarchical to: No other components. Component rationale and application notes User Application Notes 561 This component requires that for a subset of the objects in the TOE, the TSF will ensure that upon the creation or re-initialisation of any of these objects that there will be no information in the newly created or initialised object. 562 This component is expressly useful in the creation of a package which does not apply to all objects in the TOE. D R A F T User Data Protection FDP_RIP - Residual Information Protection 94/10/31 CCEB-94/083 Version 0.90 Page 127 of 246 Operations Assignment: 563 In FDP_RIP.3.1, define the subset of the objects in the TOE to which the requirements apply. Dependencies: No dependencies. Elements: FDP_RIP.3.1 The TSF shall enforce a residual information protection policy on the following objects: [List of the objects to be protected] FDP_RIP.3.2 For each protected object, the TSF shall ensure that upon the creation or re initialisation any part of the object, that there is no information content in the object which could lead to the recovery of any information which was previously protected by the TSF. FDP_RIP.4 Full Creation Protection Hierarchical to: FDP_RIP.3 Component rationale and application notes User Application Notes 564 This component requires that for of the objects protected under a data protection policy, the TSF will ensure that upon the creation or re- initialisation of any of these objects that there will be no information in the newly created or initialised object. Operations Assignment: 565 In FDP_RIP.4.1, define the data protection policies which are to be supported by this residual information protection. Dependencies: No dependencies. Elements: FDP_RIP.4.1 The TSF shall enforce residual information protection for all objects in the TOE. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 128 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_RIP.4.2 For each protected object, the TSF shall ensure that upon the creation or re initialisation any part of the object, that there is no information content in the object which could lead to the recovery of any information which was previously protected by the TSF. FDP_ACM Access Control Mechanisms Family behaviour 566 This family describes specific mechanisms that can implement the rules for access control. Examples of mechanisms that can satisfy these components include: - User/group/world permissions - Access control lists - Time-based access control specifications - Origin-based access control specifications - Owner-controlled access control attributes - Security Administrator-controlled access control attributes - Hierarchically controlled access control attributes - Hierarchical default access specifications - Per-subject default access specifications - Transferrable access control permissions Editor Note: There are other mechanisms that might be appropriate for inclusion in this family, but are not present in this version. Some of these are: Two-person control of operations, Sequence rules for operations and Exclusion controls. Rationale 567 A variety of acceptable access control mechanisms is provided by these components in order to support different environments and different control requirements. Threats 568 This family addresses the threat that information cannot be protected in a suitable manner. Other relevant families 569 The mechanisms in this component exist to support the policies of FDP_ACC Access Control. The cross-references for that family discuss additional family relationships. In addition: 570 FTE_MTE Method of Entry 571 FTE_MDE Mode of Entry 572 FTE_TME Time of Entry D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 129 of 246 573 FTE_LCE Location of Entry Component levelling 574 This family defines a set of six hierarchical component pairs., each describing aspects of an access control mechanism. These components may be taken in arbitrary combinations to implement a particular FDP_ACC Access Control policy. Within each pair, the first component only requires that at least one setting be possible for each operation. In the second component of each pair, it is required that arbitrary combinations of settings be possible for allowing and denying each operation. 575 The FDP_ACM.1 Single Identity-based Access Control and FDP_ACM.2 Multiple Identity-based Access Control all enforcement based upon the identity of a user responsible for the requested operation. 576 The FDP_ACM.3 Single Group-based Access Control and FDP_ACM.4 Multiple Group-based Access Control components allow enforcement based upon a group or groups of users for ease of setting and controlling access. 577 The FDP_ACM.5 Single Subject-based Access Control and FDP_ACM.6 Multiple Subject-based Access Control components allow enforcement based upon security attributes associated with a subject. 578 The FDP_ACM.7 Single Role-based Access Control and FDP_ACM.8 Multiple Role-based Access Control components allow enforcement based upon the role to which a user or subject is associated. 579 The FDP_ACM.9 Single Time-based Access Control and FDP_ACM.10 Multiple Time-based Access Control components allow enforcement based upon the time of a requested operation. 580 The FDP_ACM.11 Single Location-based Access Control and FDP_ACM.12 Single Location-based Access Control components allow enforcement based upon the location of a requested operation. Application Notes Audit 581 The following recommendations are provided for auditable events for the components in this family: a) Minimal: The security attributes used and the identity of any users, subjects and/or objects involved a successful mediation. b) Basic: The security attributes used and the identity of any users, subjects and/or objects involved an unsuccessful mediation. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 130 of 246 CCEB-94/083 Version 0.90 94/10/31 c) Basic: The identity of a user and/or subject making use of configuration interfaces for the mechanisms. d) Detailed: Any changes to security attributes used in mediation by the mechanisms and the user and/or subject responsible. e) Detailed: The identity of a user making changes to the configuration of any of the mechanisms and any changes made. Documentation 582 TBD FDP_ACM.1 Single Identity-based Access Control Hierarchical to: No other components. Component rationale and application notes User Application Notes 583 This component provides requriements for a mechanism which allows a single user identity to be associated with an operation for the purposes of access control. Operations No permitted operation. Dependencies: FIA_ATD.2 Basic User Attribute Definition Elements: FDP_ACM.1.1 The TSF shall provide an access control mechanism controlling at least a subset of the available operations in the TOE. FDP_ACM.1.2 The access control mechanism shall permit or deny operations based upon the identity of a user or the user on whose behalf a subject is operating. FDP_ACM.1.3 The access control mechanism shall permit designation of a single user permitted to perform an operation. D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 131 of 246 FDP_ACM.2 Multiple Identity-based Access Control Hierarchical to: FDP_ACM.1 Component rationale and application notes User Application Notes 584 This component provides requirements for a mechanism which allows a multiple user identities to be associated with an operation for the purposes of access control by both allowing and denying users access to operations. 585 The maximum number of users that must be specifiable for any given operation using this mechanism shall be defined and shall be consistent with the intended use of the mechanism and the objects and/or operations it controls. If specific requirements are needed to ensure that there is at least a minimum capability to support a certain number of specifiable users then a refinement should be used. Operations No permitted operation. Dependencies: FIA_ATD.2 Basic User Attribute Definition Elements: FDP_ACM.2.1 The TSF shall provide an access control mechanism controlling at least a subset of the available operations in the TOE. FDP_ACM.2.2 The access control mechanism shall permit or deny operations based upon the identity of a user or the user on whose behalf a subject is operating. FDP_ACM.2.3 The access control mechanism shall permit simultaneous designation of multiple users permitted to perform an operation. FDP_ACM.2.4 The access control mechanism shall permit simultaneous designation of multiple users forbidden to perform an operation. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 132 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ACM.3 Single Group-based Access Control Hierarchical to: No other components. Component rationale and application notes User Application Notes 586 This component provides requriements for a mechanisms which allow the grouping of users and which allow a single group of users to be associated with an operation for the purposes of access control. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition Elements: FDP_ACM.3.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.3.2 The TSF shall provide a mechanism for defining groups of users. FDP_ACM.3.3 The access control mechanism shall permit or deny operations based upon the group or groups associated with the user or the user on whose behalf a subject is operating. FDP_ACM.3.4 The access control mechanism shall permit designation of a single group permitted to perform an operation. FDP_ACM.4 Multiple Group-based Access Control Hierarchical to: FDP_ACM.3 Component rationale and application notes User Application Notes 587 This component provides requirements for mechanisms which allow users to be grouped and which allows a multiple groups of users to be associated with an operation of the purposes of granting or denying access. 588 The maximum number of definable groups, the maximum membership of a group and the maximum number of groups to which a user can concurrently be associated are left undefined here. These should be filled in by refinements if required. D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 133 of 246 589 The maximum number of groups that must be specifiable for any given operation using this mechanism shall be defined and shall be consistent with the intended use of the mechanism and the objects and/or operations it controls. If specific requirements are needed to ensure that there is at least a minimum capability to support a certain number of specifiable groups of users then a refinement should be used. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition Elements: FDP_ACM.4.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.4.2 The TSF shall provide a mechanism for defining groups of users. FDP_ACM.4.3 The access control mechanism shall permit or deny operations based upon the group or groups associated with the user or the user on whose behalf a subject is operating. FDP_ACM.4.4 The access control mechanism shall permit simultaneous designation of multiple groups permitted to perform an operation. FDP_ACM.4.5 The access control mechanism shall permit simultaneous designation of multiple groups forbidden to perform an operation. FDP_ACM.5 Single Subject-based Access Control Hierarchical to: No other components. Component rationale and application notes User Application Notes 590 This component provides requirements for an access control mechanism which permits or denies access to objects on the basis of a subject security attribute which is generally not derived from the user on behalf of whom the subject is acting. Examples of such attributes might be the name of the program image used in the creation of the subject, a security attribute assigned to the program image, etc. Operations No permitted operation. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 134 of 246 CCEB-94/083 Version 0.90 94/10/31 Dependencies: No dependencies. Elements: FDP_ACM.5.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.5.2 The TSF shall provide a means to define subject security attributes and associate subject security attributes with subjects. FDP_ACM.5.3 The access control mechanism shall permit or deny operations based on a subject security attribute of the requesting subject. FDP_ACM.5.4 The access control mechanism shall permit designation of a single subject security attribute which permits a subject to perform an operation on a object. FDP_ACM.6 Multiple Subject-based Access Control Hierarchical to: FDP_ACM.5 Component rationale and application notes User Application Notes 591 This component provides requirements for an access control mechanism which permits or denies access to objects on the basis of a subject security attribute which is generally not derived from the user on behalf of whom the subject is acting. Examples of such attributes might be the name of the program image used in the creation of the subject, a security attribute assigned to the program image, etc. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_ACM.6.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.6.2 The TSF shall provide a means to define subject security attributes and associate subject security attributes with subjects. FDP_ACM.6.3 The access control mechanism shall permit or deny operations based on a security attribute of the requesting subject. D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 135 of 246 FDP_ACM.6.4 The access control mechanism shall permit simultaneous designation of multiple subject security attributes which permit a subject to perform an operation. FDP_ACM.6.5 The access control mechanism shall permit simultaneous designation of multiple subject security attributes forbidding a subject permission to perform an operation. FDP_ACM.7 Single Role-based Access Control Hierarchical to: No other components. Component rationale and application notes User Application Notes 592 This component defines requriements for an access control mechanism which is based upon defined roles to which users can be assigned. 593 The maximum number of definable roles, the maximum size membership list of each role and the maximum number of roles a user can concurrently be acting in are left undefined here. These should be filled in by refinements if required. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition Elements: FDP_ACM.7.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.7.2 The TSF shall support a means for defining roles and assigning users to roles. FDP_ACM.7.3 The access control mechanism shall permit or deny operations based upon the role or roles associated with the user or the user on whose behalf a subject is operating. FDP_ACM.7.4 The access control mechanism shall permit designation of a single role permitted to perform an operation. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 136 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ACM.8 Multiple Role-based Access Control Hierarchical to: FDP_ACM.7 Component rationale and application notes User Application Notes 594 This component defines requriements for an access control mechanism which is based upon defined roles to which users can be assigned. 595 The maximum number of definable roles, the maximum size membership list of each role and the maximum number of roles a user can concurrently be acting in are left undefined here. These should be filled in by refinements if required. 596 The maximum number of roles that must be simultaneously specifiable for any given operation using this mechanism shall be defined and shall be consistent with the intended use of the mechanism and the objects and/or operations it controls. If specific requirements are needed to ensure that there is at least a minimum capability to support a certain number of specifiable roles then a refinement should be used. Operations No permitted operation. Dependencies: FIA_ATD.1 Minimal User Attribute Definition Elements: FDP_ACM.8.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.8.2 The TSF shall support a means through which users or subjects may be assigned specific roles. FDP_ACM.8.3 The access control mechanism shall permit or deny operations based upon the role or roles associated with the user or the user on whose behalf a subject is operating. FDP_ACM.8.4 The access control mechanism shall permit simultaneous designation of multiple roles permitted to perform an operation. FDP_ACM.8.5 The access control mechanism shall permit simultaneous designation of multiple roles forbidden to perform an operation. D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 137 of 246 FDP_ACM.9 Single Time-based Access Control Hierarchical to: No o the r components. Component rationale and application notes User Application Notes 597 The component defines requirements for a mechanism which enforces access control on the basis of a single window of time. For instance it could be used to specify that access will be granted only on Fridays or only during a certain calendar year. Operations Refinement: 598 In FDP_ACM.9.2, refine the requirements for time intervals to indicate whether the time intervals should be non-repeating (i.e. only occur one) or repeat daily, weekly, monthly, etc. Dependencies: No dependencies. Elements: FDP_ACM.9.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.9.2 The access control mechanism shall permit or deny operations based upon time intervals. FDP_ACM.9.3 The access control mechanism shall permit the designation of a single time interval during which the operation is permitted. FDP_ACM.10 Multiple Time-based Access Control Hierarchical to: FDP_ACM.9 Component rationale and application notes User Application Notes 599 The component defines requirements for a mechanism which enforces access control on the basis of a multiple windows of time. For instance, it could specify that access will be permitted during breakfast, lunch and dinner every day but that access will never be granted on Sunday. D R A F T FDP_ACM - Access Control Mechanisms User Data Protection Page 138 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations Refinement: 600 In FDP_ACM.10.2, refine the requirements for time intervals to indicate whether the time intervals should be non-repeating (i.e. only occur one) or repeat daily, weekly, monthly, etc. Dependencies: No dependencies. Elements: FDP_ACM.10.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.10.2 The access control mechanism shall permit or deny operations based upon time intervals. FDP_ACM.10.3 The access control mechanism shall permit the simultaneous designation of multiple time intervals during which the operation is permitted. FDP_ACM.10.4 The access control mechanism shall permit the simultaneous designation of multiple time intervals during which the operation is forbidden. FDP_ACM.11 Single Location-based Access Control Hierarchical to: No other components. Component rationale and application notes User Application Notes 601 This component defines requirements for an access control mechanism which grants or denies operations on the basis of location. The component does not explicitly say whether the location should be the location of the request for the operation, the location where the operation will be carried out, or both. If this needs to be clarified in a package it should be specified by a refinement. 602 How the TSF determines location is not specified but could be based upon internal tables to translate the logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc. Operations No permitted operation. Dependencies: No dependencies. D R A F T User Data Protection FDP_ACM - Access Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 139 of 246 Elements: FDP_ACM.11.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.11.2 The access control mechanism shall permit or deny operations based upon location of the requested operation. FDP_ACM.11.3 The access control mechanism shall permit the designation of a single location for which the operation is permitted. FDP_ACM.12 Single Location-based Access Control Hierarchical to: FDP_ACM.11 Component rationale and application notes User Application Notes 603 This component defines requirements for an access control mechanism which grants or denies operations on the basis of location. The component does not explicitly say whether the location should be the location of the request for the operation, the location where the operation will be carried out, or both. If this needs to be clarified in a package it should be specified by a refinement. 604 How the TSF determines location is not specified but could be based upon internal tables to translate the logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_ACM.12.1 The TSF shall provide an access control mechanism to control a subset of the available operations in the TOE. FDP_ACM.12.2 The access control mechanism shall permit or deny operations based upon location of the requested operation. FDP_ACM.12.3 The access control mechanism shall permit the simultaneous designation of multiple locations for which the operation is permitted. FDP_ACM.12.4 The access control mechanism shall permit the simultaneous designation of multiple locations for which the operation is forbidden. D R A F T FDP_IFM - Information Flow Control Mechanisms User Data Protection Page 140 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_IFM Information Flow Control Mechanisms Family behaviour 605 This family describes specific mechanisms that can implement the rules for information flow control. Rationale 606 In order to implement strong protection against disclosure or modification in the face of untrusted software, controls on information flow are required. Access controls alone are not sufficient because of the information flows implicit in controlled operations. Threats 607 This family addresses the threat that a TSF's information flow policy will be violated. Other relevant families 608 The mechanisms in this component exist to support the policies of FDP_IFC Information Flow Control. The cross-references for that family discuss additional family relationships. In addition: 609 FTE_MTE Method of Entry 610 FTE_MDE Mode of Entry 611 FTE_TME Time of Entry 612 FTE_LCE Location of Entry Component levelling 613 This family describes a set of components, each describing aspects of an information flow control mechanism. The first three components deal with mechanisms to support user based labels: 614 FDP_IFM.1 Single user-based labels requires that the TOE support labels associated with users and use these to determine whether a flow is valid. 615 FDP_IFM.2 Multiple user-based labels requires that user labels can be used to set up arbitrary combinations of allowed and forbidden information flows. 616 FDP_IFM.3 Lattice of user-based labels requires that the user labels be arranged into a lattice for provability of the information flows being single directional. D R A F T User Data Protection FDP_IFM - Information Flow Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 141 of 246 617 The next three components deal with mechanisms to support subject based labels: 618 FDP_IFM.4 Single subject-based labels requires that the TOE support labels associated with subjects and use these to determine whether a flow is valid. 619 FDP_IFM.5 Multiple user-based labels requires that subject labels can be used to set up arbitrary combinations of allowed and forbidden information flows. 620 FDP_IFM.3 Lattice of user-based labels requires that the subject labels be arranged into a lattice for provability of the information flows being single directional. 621 The final component two components deal with requriements for mechanisms to support configurable limitations on information flows in violation of the information flow control policy; 622 FDP_IFM.7 Specific Information Flow Limitation addresses adjustable limitations on specific flows which have been identified. 623 FDP_IFM.8 Global Information Flow Limitation requires that mechanism exist to support limiting all know information flows to some maximum aggregate bandwidth. Application Notes Audit 624 The following are guidelines on what should be auditable if Security Audit is specified in the PP/ST: a) Minimal: The identity of any user or subject responsible for a label change. b) Minimal: The identity of what has had its label changed and its new label value. c) Basic: Both the original and new label values after any label change. d) Basic: The identity of any user or subject making use of any configuration interfaces for the information flow control mechanisms such as defining new labels, changing the lattice or changing bandwidth limits. e) Detailed: Any changes made using configuration tools for the information flow control mechanisms. Documentation 625 TBD D R A F T FDP_IFM - Information Flow Control Mechanisms User Data Protection Page 142 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_IFM.1 Single user-based labels Hierarchical to: No other components. Component rationale and application notes User Application Notes 626 This component defines the requirements for a TOE which implements information flow controls on the basis of user labels. The relationship of user labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. 627 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFM.1.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. FDP_IFM.1.2 The information flow control mechanism shall permit or deny operations based upon user labels associated with users and subject acting on behalf of users. FDP_IFM.1.3 The information flow control mechanism shall permit the designation of a single user label associated with each protected operation. FDP_IFM.1.4 The information flow control mechansism shall permit the designation of a single user label for which an operation is permitted. FDP_IFM.2 Multiple user-based labels Hierarchical to: FDP_IFM.1 Component rationale and application notes User Application Notes 628 This component defines the requirements for a TOE which implements information flow controls on the basis of user labels. The relationship of user labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. D R A F T User Data Protection FDP_IFM - Information Flow Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 143 of 246 629 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. 630 The number of labels which can be simultaneously associated with an operation is not defined in this component. If there is a minimum required number then this should be indicated using a refinement. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFM.2.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. FDP_IFM.2.2 The information flow control mechanism shall permit or deny operations based upon user labels associated with users and subject acting on behalf of users. FDP_IFM.2.3 The information flow control mechanism shall permit the designation of a single user label associated with each protected operation. FDP_IFM.2.4 The information flow control mechansism shall permit the simultaneous designation of multiple user labels for which an operation is permitted. FDP_IFM.2.5 The information flow control mechansism shall permit the simultaneous designation of multiple user labels for which an operation is forbidden. FDP_IFM.3 Lattice of user-based labels Hierarchical to: FDP_IFM.1 Component rationale and application notes User Application Notes 631 This component defines the requirements for a TOE which implements information flow controls on the basis of user labels. The relationship of user labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. 632 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. D R A F T FDP_IFM - Information Flow Control Mechanisms User Data Protection Page 144 of 246 CCEB-94/083 Version 0.90 94/10/31 633 The user labels shall be arranged into a lattice to that a relationship called dominates can be used to determine valid information flows. How complete the mechansism of the TOE needs to be in supporting a given size of lattice or the defining criteria for the lattice should be defined as a refinement if needed. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFM.3.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. FDP_IFM.3.2 The information flow control mechanism shall permit or deny operations based upon user labels associated with users and subject acting on behalf of users. FDP_IFM.3.3 The information flow control mechanism shall permit the designation of a single user label associated with each protected operation. FDP_IFM.3.4 The information flow control mechanism shall provide a subject label lattice. FDP_IFM.3.5 The information flow control mechansism shall permit an operation only if information will flow only from lower a lower to equal or higher label in the user label lattice. FDP_IFM.4 Single subject-based labels Hierarchical to: No other components. Component rationale and application notes User Application Notes 634 This component defines the requirements for a TOE which implements information flow controls on the basis of subject labels. The relationship of subject labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. 635 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. Operations No permitted operation. D R A F T User Data Protection FDP_IFM - Information Flow Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 145 of 246 Dependencies: No dependencies. Elements: FDP_IFM.4.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. FDP_IFM.4.2 The information flow control mechanism shall permit or deny operations based upon subject labels. FDP_IFM.4.3 The information flow control mechanism shall permit the designation of a single subject label associated with each protected operation. FDP_IFM.4.4 The information flow control mechansism shall permit the designation of a single subject label for which an operation is permitted. FDP_IFM.5 Multiple user-based labels Hierarchical to: FDP_IFM.4 Component rationale and application notes User Application Notes 636 This component defines the requirements for a TOE which implements information flow controls on the basis of subject labels. The relationship of subject labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. 637 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. 638 The number of labels which can be simultaneously associated with an operation is not defined in this component. If there is a minimum required number then this should be indicated using a refinement. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFM.5.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. D R A F T FDP_IFM - Information Flow Control Mechanisms User Data Protection Page 146 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_IFM.5.2 The information flow control mechanism shall permit or deny operations based upon subject labels. FDP_IFM.5.3 The information flow control mechanism shall permit the designation of a single subject label associated with each protected operation. FDP_IFM.5.4 The information flow control mechansism shall permit the simultaneous designation of multiple subject labels for which an operation is permitted. FDP_IFM.5.5 The information flow control mechansism shall permit the simultaneous designation of multiple subject labels for which an operation is forbidden. FDP_IFM.6 Lattice of subject-based labels Hierarchical to: FDP_IFM.4 Component rationale and application notes User Application Notes 639 This component defines the requirements for a TOE which implements information flow controls on the basis of subject labels. The relationship of subject labels to any other labels should be defined in the FDP_IFC Information Flow Control policy. 640 The number of labels which must be supported by the TOE is not defined here. If there is a requirement to support at least some minimum set of labels then that should be indicated using a refinement. 641 The subject labels shall be arranged into a lattice so that a relationship called dominates can be used to determine valid information flows. How complete the mechansism of the TOE needs to be in supporting a given size of lattice or the defining criteria for the lattice should be defined as a refinement if needed. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_IFM.6.1 The TSF shall provide an information flow control mechanism to control a subset of the available operations in the TOE. FDP_IFM.6.2 The information flow control mechanism shall permit or deny operations based upon subject labels. D R A F T User Data Protection FDP_IFM - Information Flow Control Mechanisms 94/10/31 CCEB-94/083 Version 0.90 Page 147 of 246 FDP_IFM.6.3 The information flow control mechanism shall permit the designation of a single subject label associated with each protected operation. FDP_IFM.6.4 The information flow control mechanism shall provide a subject label lattice. FDP_IFM.6.5 The information flow control mechansism shall permit an operation only if information will flow only from lower a lower to equal or higher label in the subject label lattice. FDP_IFM.7 Specific Information Flow Limitation Hierarchical to: No other components. Component rationale and application notes User Application Notes 642 This component defines the requirements for a TOE which supports configurable mechanisms to limit information flows. The goal of this component is to allow authorised users to make trade-offs between limiting information flow bandwidths and other factors such as performance. Operations Assignment: 643 In FDP_IFM.7.1, fill in the list of information flows in violation of the information flow control policy for which there must be a configurable flow control limiting mechanism. Dependencies: AVA_CCA.1 Storage channel analysis Elements: FDP_IFM.7.1 The TSF shall provide mechanisms to allow an authorised user to configure maximum information flow bandwidths for the following informations flows in violation of the information flow control policy: [List of information flows to control] D R A F T FDP_SAQ - Security Attribute Query User Data Protection Page 148 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_IFM.8 Global Information Flow Limitation Hierarchical to: FDP_IFM.7 Component rationale and application notes User Application Notes 644 This component defines the requirements for a TOE which supports configurable mechanisms to limit information flows. The goal of this component is to allow authorised users to make trade-offs between limiting information flow bandwidths and other factors such as performance. Operations Assignment: 645 In FDP_IFM.8.1, fill in maximum total information flow bandwidth in violation of the information flow control policy to which must the TSF must be configurable. Dependencies: AVA_CCA.2 Timing channel analysis Elements: FDP_IFM.8.1 The TSF shall provide mechanisms to allow an authorised user to configure maximum information flow bandwidth in violation of the information flow control policy to the no more than the maximum total bandwidth: [Maximum total bandwidth] FDP_SAQ Security Attribute Query Family behaviour 646 This family defines the rules for viewing values of security attributes relevant to a user data protection policy. Each security function (e.g., FDP_ACM Access Control Mechanisms, FDP_IFM Information Flow Control Mechanisms), must include aspects that satisfy these components. 647 This family addresses the need for authorised users, and subjects operating on behalf of authorised users, to query security attributes. Threats 648 This family reduces the threat that the values of security attributes will not be known to authorised users. D R A F T User Data Protection FDP_SAQ - Security Attribute Query 94/10/31 CCEB-94/083 Version 0.90 Page 149 of 246 649 This family reduces the threat that the values of security attributes will be known to unauthorised users. Other relevant families 650 FPT_TSA TOE Security Administration 651 FIA_ATA User Attribute Administration Component levelling 652 This family specifies two hierarchical components concerning operations for viewing relevant security attributes of objects, subjects, and users. For each, the levelling is based upon the scope of the required functionality: 653 The first component, FDP_SAQ.1 Minimal Attribute Query allows for a choice in the way in which the relevant security attributes associated with an object, a user or a subject can be determined by an authorised user. 654 The second component, FDP_SAQ.2 Basic Attribute Query, increases the functionality by requiring two ways in which the relevant security attributes can be determined by an authorised user. 655 The rules applying to these functions may be different for different security attributes (e.g., an access control mechanism might be based upon both object ownership and an access control list, but the rules for changing ownership and the access control list may be different). Application Notes Audit 656 THe following guidelines on auditable events should be considered if Security Audit is included in the TOE: a) Minimal: The identity of a user successfully querying security attributes and the target of the query. b) Basic: The identity of a user unsuccessfully querying security attributes and the target of the query. D R A F T FDP_SAQ - Security Attribute Query User Data Protection Page 150 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_SAQ.1 Minimal Attribute Query Hierarchical to: No other components. Component rationale and application notes User Application Notes 657 In this component, it is acceptable to provide a mechanism to list all relevant security attributes associated with an object, user or subject or a mechanism to list all objects, users or subjects associated with a security attribute. Only one mechanism is required. Operations Selection: 658 In FDP_SAQ.1.2, the PP/ST author should define the query mode for the security attributes related to objects, users or subjects. Dependencies: No dependencies. Elements: FDP_SAQ.1.1 The TSF shall provide the ability for authorised users to display relevant security attributes. FDP_SAQ.1.2 The TSF shall provide at least one of the following options: a) To display all relevant security attributes for an object, user or subject. b) To display all the objects, users or subjects associated with a relevant security attribute. FDP_SAQ.2 Basic Attribute Query Hierarchical to: FDP_SAQ.1 Component rationale and application notes 659 This component differs from the previous component only in that it must be possible to determine both the relevant security attributes associated with a particular object, user or subject and it must be possible to determine which objects, users or subjects have a particular relevant security attribute. Operations No permitted operation. D R A F T User Data Protection FDP_SAM - Security Attribute Modification 94/10/31 CCEB-94/083 Version 0.90 Page 151 of 246 Dependencies: No dependencies. Elements: FDP_SAQ.2.1 The TSF shall provide the ability for authorised users to display relevant security attributes. FDP_SAQ.2.2 The TSF shall provide the following options: a) To display all relevant security attributes for an object, user or subject, and b) To display all the objects, users or subjects associated with a relevant security attribute. FDP_SAM Security Attribute Modification Family behaviour 660 This family defines the rules for setting and modifying values of security attributes relevant to a user data protection policy. Each security function must include aspects that satisfy these components. 661 This family addresses the need for authorised users, and subjects operating on behalf of users, to appropriately modify security attributes. Threats 662 This family addresses the threat that the values of relevant security attributes will be modified by unauthorised users. 663 This family addresses the threat that the values of relevant security attributes can not be modified by authorised users. 664 This family addresses the threat that relevant security attributes will be incorrectly modified. Other relevant families 665 FPT_TSA TOE Security Administration 666 FPT_TSU TOE Administrative Safe Use 667 FDP_SAI Security Attribute Initialisation 668 FIA_ATA User Attribute Administration D R A F T FDP_SAM - Security Attribute Modification User Data Protection Page 152 of 246 CCEB-94/083 Version 0.90 94/10/31 Component levelling 669 This family specifies three components concerning operations for modifying security-relevant attributes of objects, subjects, and users. 670 The first component, FDP_SAM.1 Minimal Attribute Modification, limits the modification of relevant security attributes associated with objects, users or subjects to only Security Administrators. 671 The second component, FDP_SAM.2 Basic Attribute Modification, increases the functionality by allowing the modification of relevant security attributes by any authorised user. 672 The third component, FDP_SAM.3 Safe Attribute Modification, requires that the TSF enforce rules on the acceptable settings of relevant security attributes. Editor's Note:Do we need to introduce components for "revocation" and when the revocation takes place? Currently this could be done with a refinement but is that sufficient? Application Notes User Application Notes 673 The rules of applying to these functions may be different for different attributes (e.g., an access control mechanism might be based both on object ownership and an access control list, but the rules for changing ownership and the access control list may be different). This should be specified by using refinements as required. Audit 674 THe following guidelines on auditable events should be considered if Security Audit is included in the TOE: a) Minimal: The identity of a user and./or subject successfully modifying security attributes and the target of the modification. b) Basic: The new values of modified security attributes. c) Basic: The identity of a user and/or subject unsuccessfully modifying security attributes, the target of the attempted modification and the attempted new value. D R A F T User Data Protection FDP_SAM - Security Attribute Modification 94/10/31 CCEB-94/083 Version 0.90 Page 153 of 246 FDP_SAM.1 Minimal Attribute Modification Hierarchical to: No other components. Component rationale and application notes User Application Notes 675 At this level, only a Security Administrator can modify the relevant security attributes for objects, users and subjects. Operations No permitted operation. Dependencies: FPT_TSA.2 Separate Security Administrative Role Elements: FDP_SAM.1.1 The TSF shall limit the ability to modify relevant security attributes of objects, subjects, and users to a Security Administrator. FDP_SAM.2 Basic Attribute Modification Hierarchical to: FDP_SAM.1 Component rationale and application notes User Application Notes 676 At this level, authorised users and Security Administrator can modify the security attributes for objects, users and subjects. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_SAM.2.1 The TSF shall limit the ability to modify relevant security attributes of objects, subjects, and users to authorised users. D R A F T FDP_SAI - Security Attribute Initialisation User Data Protection Page 154 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_SAM.3 Safe Attribute Modification Hierarchical to: No other components. Component rationale and application notes User Application Notes 677 This component should be used in those situations where the PP/ST author wants to ensure that administrative restrictions are checked whenever possible. It addresses the threat of the unskilled administrative user providing out-of-range values through the administrative interface. Operations No permitted operation. Dependencies: FDP_SAM.1 Minimal Attribute Modification Elements: FDP_SAM.3.1 The TSF shall enforce any enforceable checks of legal input values for the relevant security attributes. FDP_SAI Security Attribute Initialisation Family behaviour 678 This family defines the rules for the initial values of relevant security attributes for objects, users, and subjects. These rules address the need for objects, users or subjects to be protected appropriately by default. Threats 679 This family addresses the threat that relevant security attributes will be set incorrectly. 680 This family addresses the threat that relevant security attributes will be set incompletely. 681 This family addresses the threat that newly-created subjects, objects or users will be inadequately or inappropriately protected. Other relevant families 682 FDP_SAM Security Attribute Modification D R A F T User Data Protection FDP_SAI - Security Attribute Initialisation 94/10/31 CCEB-94/083 Version 0.90 Page 155 of 246 683 FPT_TSA TOE Security Administration 684 FPT_TSU TOE Administrative Safe Use 685 FIA_ATA User Attribute Administration Component levelling 686 There are four components in this family providing for the default protection of objects. The components are levelled based upon increased functionality. 687 The first component, FDP_SAI.1 Static Attribute Initialisation, requires that the TSF provide default values for relevant security attributes but that no mechanisms need to be provided to modify these defaults. 688 The second component, FDP_SAI.2 Minimal Attribute Initialisation, requires that the default values be modifiable by a Security Administrator. 689 The third component, FDP_SAI.3 Basic Attribute Initialisation, requires that the default values be modifiable by authorised users. 690 The fourth component, FDP_SAI.4 Safe Attribute Initialisation, requires that the TSF enforce rules on the acceptable settings of default values. FDP_SAI.1 Static Attribute Initialisation Hierarchical to: No other components. Component rationale and application notes User Application Notes 691 This component requires that the TSF provide default values for relevant security attributes but that no mechanism need be supported for changing these defaults. It may still be possible for a new user, subject or operation to have different attributes at creation if a mechanism exists to specify the permissions at time of creation. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_SAI.1.1 The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. D R A F T FDP_SAI - Security Attribute Initialisation User Data Protection Page 156 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_SAI.1.2 In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user or subject is newly created. FDP_SAI.1.3 The TSF shall control any functions for specifying initial values in accordance with all the TSF's protection policies. FDP_SAI.2 Minimal Attribute Initialisation Hierarchical to: FDP_SAI.1 Component rationale and application notes User Application Notes 692 This component requires that there exist an interface for a security administrator to change the default values. Operations No permitted operation. Dependencies: FPT_TSA.2 Separate Security Administrative Role Elements: FDP_SAI.2.1 The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.2.2 In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user or subject is newly created. FDP_SAI.2.3 The TSF shall control any functions for specifying initial values in accordance with all the TSF's protection policies. FDP_SAI.2.4 The TSF shall provide functions for modifying default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.2.5 The TSF shall limit the ability to modify default values to a Security Administrator. D R A F T User Data Protection FDP_SAI - Security Attribute Initialisation 94/10/31 CCEB-94/083 Version 0.90 Page 157 of 246 FDP_SAI.3 Basic Attribute Initialisation Hierarchical to: FDP_SAI.2 Component rationale and application notes User Application Notes 693 This component requires that the TOE support more flexible designation of which users can change initial values of security attributes. Some may still be limited to security administrators and some may be allowed to "owning" users, etc. Operations No permitted operation. Dependencies: No dependencies. Elements: FDP_SAI.3.1 The TSF shall provide well-defined default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.3.2 In the absence of any overriding initial values, the TSF shall apply these default attributes when an object, user or subject is newly created. FDP_SAI.3.3 The TSF shall control any functions for specifying initial values in accordance with all the TSF's protection policies. FDP_SAI.3.4 The TSF shall provide functions for modifying default values for relevant security attributes that are used to control the data protection mechanisms. FDP_SAI.3.5 The TSF shall limit the ability to modify default values to authorised users . FDP_SAI.4 Safe Attribute Initialisation Hierarchical to: No other components. Component rationale and application notes User Application Notes 694 This component should be used in those situations where the PP/ST author wants to ensure that "safety" restrictions are checked whenever possible. It addresses the threat of the unskilled users providing out-of- range values for instance. 695 D R A F T FDP_ITC - Import from Outside TSF Control User Data Protection Page 158 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations No permitted operation. Dependencies: FDP_SAI.1 Static Attribute Initialisation Elements: FDP_SAI.4.1 The TSF shall enforce any enforceable checks of legal input values for the relevant default or initial security attributes. FDP_ITC Import from Outside TSF Control Family behaviour 696 This family defines the mechanisms for introduction of information into the TOE such that it has appropriate security attributes and is appropriately protected. It is concerned with limitations on importation, the form of the information (e.g., human-entered, machine-readable), determination of desired security attributes, and interpretation of security attributes associated with the information. Threats 697 This family addresses the threat that information will be introduced into the TOE with incorrect security attributes or inadequate protection. 698 This family addresses the threat that information will be imported in violation of an import control policy. Other relevant families 699 The mechanisms in this component exist to support the policies of FDP_ACC Access Control and FDP_IFC Information Flow Control. The cross references for those families discuss additional family relationships. Application Notes User Application Notes 700 This family, and the corresponding Export family, address how the TOE deals with information outside its control. A variety of activities might be involved here: Typing at a keyboard, importing the keyed-in information; Reading a screen, exporting the displayed information; Requesting a printout, exporting a printed representation; D R A F T User Data Protection FDP_ETC - Export to Outside TSF Control 94/10/31 CCEB-94/083 Version 0.90 Page 159 of 246 Transferring information to an unformatted medium, without including any security attributes, and physically marking the medium to indicate it contents; Transferring information, including security attributes, to a medium and handling it to ensure that the attributes are protected; Transferring information, including security attributes, to a medium using a cryptographic sealing technique to protect the association of information and security attributes; Transmitting information over a communication channel similarly to the above three cases, except that there is no "physical marking" or "handling" procedure for the channel; the channel may be manually connected (by actions outside the TSF) or created/connected under the TSF's control; Receiving information from an unformatted medium or communication channel; Receiving information with associated security attributes. FDP_ETC Export to Outside TSF Control Family behaviour 701 This family defines mechanisms for exporting information from the TOE such that its security attributes and protection can be preserved. It is concerned with limitations on export, the form of the information (e.g., machine-readable, human readable), user specification of security attributes, and association of security attributes with the exported information. Threats 702 This family addresses the threat that information will be exported without proper indication of its security attributes and protection characteristics. 703 This addresses the threat that information will be exported in violation of an export control policy. Other relevant families 704 The mechanisms in this component exist to support the policies of FDP_ACC Access Control and FDP_IFC Information Flow Control. The cross references for those families discuss additional family relationships. D R A F T FDP_ETC - Export to Outside TSF Control User Data Protection Page 160 of 246 CCEB-94/083 Version 0.90 94/10/31 Application Notes User Application Notes 705 This family, and the corresponding Import family, address how the TOE deals with information outside its control. A variety of activities might be involved here: Typing at a keyboard, importing the keyed-in information; Reading a screen, exporting the displayed information; Requesting a printout, exporting a printed representation; Transferring information to an unformatted medium, without including any security attributes, and physically marking the medium to indicate it contents; Transferring information, including security attributes, to a medium and handling it to ensure that the attributes are protected; Transferring information, including security attributes, to a medium using a cryptographic sealing technique to protect the association of information and security attributes; Transmitting information over a communication channel similarly to the above three cases, except that there is no "physical marking" or "handling" procedure for the channel; the channel may be manually connected (by actions outside the TSF) or created/connected under the TSF's control; Receiving information from an unformatted medium or communication channel; Receiving information with associated security attributes; Mechanisms for exporting information shall be controlled; The TSF shall maintain security attributes for export mechanisms (e.g., communication channels); The user shall communicate with the TSF to specify the security attributes of an export mechanism, where that is not known to the TSF; The security attributes of export mechanisms (e.g., communication channels) shall be used to constrain the information exported thereto; The security attributes associated with exported information shall be exported in an unambiguous manner in conjunction with the information. D R A F T User Data Protection FDP_ITP - Information Transfer Protection 94/10/31 CCEB-94/083 Version 0.90 Page 161 of 246 FDP_ITP Information Transfer Protection Family behaviour 706 This family defines the mechanisms for protecting user information in transit between two TSFs. It is concerned with ensuring that information is not modified or disclosed without authorisation, and with ensuring that the transmission takes place successfully. Threats 707 This family addresses the threat that unauthorised modification of information in transit between two TSFs will go undetected. 708 This family addresses the threat that unauthorised modification of information in transit between two TSFs will go uncorrected. 709 This family addresses the threat that information will be disclosed to an unauthorised destination while in transit between two TSFs. Other relevant families 710 The mechanisms in this component exist to support the policies of FDP_ACC Access Control and FDP_IFC Information Flow Control. The cross- references for those families discuss additional family relationships. Component levelling 711 The first component addresses disclosure: 712 In Documentation , the goal is to provide protection from disclosure of a defined list of user data. 713 The next four components address the integrity and availability of user data transmitted between TSFs. The second and third compounds are both hierarchical to the first and the last component is hierarchical to the first three. 714 The FDP_ITP.2 Basic Data Exchange Integrity component addresses detection of modifications of the user data transmitted. 715 The FDP_ITP.3 Enhanced Data Exchange Integrity component addresses in addition attempts to introduce old data or remove data from the data stream used in transmission. 716 The FDP_ITP.4 Basic Data Exchange Integrity and Recovery component addresses recovery by the TSF of the original user data after modification in transit. D R A F T FDP_ITP - Information Transfer Protection User Data Protection Page 162 of 246 CCEB-94/083 Version 0.90 94/10/31 717 The FDP_ITP.5 Reliable Data Exchange Integrity component addresses both the concepts introduced in FDP_ITP.3 Enhanced Data Exchange Integrity and FDP_ITP.4 Basic Data Exchange Integrity and Recovery. Application Notes Audit 718 If the TOE contains Security Audit, the following guidelines should be considered for inclusion in the auditable events: a) Minimal: The identity of any user or subject using the data exchange mechanisms. b) Minimal: Whether any modifications to transmitted data were detected if they were not also corrected. c) Basic: The identity of any user or subject attempting to use the data exchange mechanisms but who is unauthorised to do so. d) Basic: A reference to the names or other indexing information useful in identifying what was transmitted or received. This could include security attributes associated with the information. e) Basic: Whether any modifications to data were corrected. f) Basic: Any identified attempts to block transmission of user data. g) Detailed: The types and or effects of any detected modifications of transmitted data. h) Detailed: Partial or complete content of data transmitted. 719 There are very few suggested auditable events above for disclosure as it is difficult if not impossible for the TOE to determine when disclosure has occurred. Documentation 720 The documentation provided for AGD_USR User guidance and AGD_ADM Administrator guidance should detail the configuration, use and degree of protection provided by any user data exchange protection mechanisms provided by the TSF. D R A F T User Data Protection FDP_ITP - Information Transfer Protection 94/10/31 CCEB-94/083 Version 0.90 Page 163 of 246 FDP_ITP.1 Basic Data Exchange Confidentiality Hierarchical to: No other components. Component rationale and application notes User Application Notes 721 The TSF has the ability to protect from disclosure some user data which is exchanged. Operations Assignment: 722 In FDP_ITP.2.1, insert the list of protected data can be received. 723 In FDP_ITP.2.2, insert the list of data for which protection should be established at transmission. 724 In FDP_ITP.2.3, insert the list of authorised user and/or subjects. Dependencies: No dependencies. Elements: FDP_ITP.1.1 The TSF shall be able to receive the following data as a protected transmission: [The list of data for which protected data can be received] FDP_ITP.1.2 The TSF shall be able to establish protection of the following data from unauthorised disclosure during transmission: [The list of data to be protected for sending] FDP_ITP.1.3 The TSF shall allow the following users and/or subjects to make use of the data exchange integrity mechanism: [The list of authorised users and/or subjects] D R A F T FDP_ITP - Information Transfer Protection User Data Protection Page 164 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ITP.2 Basic Data Exchange Integrity Hierarchical to: No other components. Component rationale and application notes User Application Notes 725 The TSF has the ability to detect modifications of some data which is exchanged, if a user sending the data chooses to have it protected and if the receiving user chooses to check for modifications. Operations Assignment: 726 In FDP_ITP.2.1, insert the list of data for which modifications can be detected. 727 In FDP_ITP.2.2, insert the list of data for which protection should be established at transmission. 728 In FDP_ITP.2.3, insert the list of authorised user and/or subjects. Dependencies: No dependencies. Elements: FDP_ITP.2.1 The TSF shall be able to detect any unauthorised modifications to any of the following data received from another TSF which supports the protection of data it sends: [The list of data for which modifications can be detected] FDP_ITP.2.2 The TSF shall be able to establish protection of the following data so that a receiving TSF will be able to detect any unauthorised modifications: [The list of data to be protected for sending] FDP_ITP.2.3 The TSF shall allow the following users and/or subjects to make use of the data exchange integrity mechanism: [The list of authorised users and/or subjects] D R A F T User Data Protection FDP_ITP - Information Transfer Protection 94/10/31 CCEB-94/083 Version 0.90 Page 165 of 246 FDP_ITP.3 Enhanced Data Exchange Integrity Hierarchical to: FDP_ITP.2 Component rationale and application notes User Application Notes 729 The TSF has the ability to detect modifications, deletions or replications of some data which is exchanged, if a user sending the data chooses to have it protected and if the receiving user chooses to check for modifications. Operations Assignment: 730 In FDP_ITP.3.1, insert the list of data for which modifications , deletions and insertions can be detected. 731 In FDP_ITP.3.2, insert the list of data for which protection should be established at transmission. 732 In FDP_ITP.3.3, insert the list of authorised user and/or subjects. Dependencies: No dependencies. Elements: FDP_ITP.3.1 The TSF shall be able to detect any unauthorised modifications , deletions or replications to any of the following data received from another TSF which supports the protection of data it sends: [The list of data for which modifications can be detected] FDP_ITP.3.2 The TSF establish protection of the following data so that a receiving TSF will be able to detect any unauthorised modifications , deletions or replications : [The list of data to be protected for sending] FDP_ITP.3.3 The TSF shall allow the following users and/or subjects to make use of the data exchange integrity mechanism: [The list of authorised users and/or subjects] D R A F T FDP_ITP - Information Transfer Protection User Data Protection Page 166 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_ITP.4 Basic Data Exchange Integrity and Recovery Hierarchical to: FDP_ITP.2 Component rationale and application notes 733 The TSF has the ability to detect modifications of some data which is exchanged, if a user sending the data chooses to have it protected and if the receiving user chooses to check for modifications. In addition, the TSF has some ability to recover or determine the original data even after modifications. Operations Assignment: 734 In FDP_ITP.4.1, insert the list of data for which modifications can be detected. 735 In FDP_ITP.4.2, insert the list of data for which protection should be established at transmission. 736 In FDP_ITP.4.3, insert the list of authorised users and/or subjects. 737 In FDP_ITP.4.4, insert the list of recoverable modifications. Dependencies: No dependencies. Elements: FDP_ITP.4.1 The TSF shall be able to detect any unauthorised modifications to any of the following data received from another TSF which supports the protection of data it sends: [The list of data for which modifications can be detected] FDP_ITP.4.2 The TSF establish protection of the following data so that a receiving TSF will be able to detect any unauthorised modifications: [The list of data to be protected for sending] FDP_ITP.4.3 The TSF shall allow the following users and/or subjects to make use of the data exchange integrity mechanism: [The list of authorised users and/or subjects] FDP_ITP.4.4 For the following unauthorised modifications of the protected data, the TSF shall be able to recover the original data: D R A F T User Data Protection FDP_ITP - Information Transfer Protection 94/10/31 CCEB-94/083 Version 0.90 Page 167 of 246 [The list of recoverable modifications] FDP_ITP.5 Reliable Data Exchange Integrity Hierarchical to: FDP_ITP.3, FDP_ITP.4 Component rationale and application notes User Application Notes 738 The TSF has the ability to detect modifications, deletions or replications of some data which is exchanged, if a user sending the data chooses to have it protected and if the receiving user chooses to check for modifications. In addition, the TSF has some ability to recover or determine the original data even after modifications. Operations Assignment: 739 In FDP_ITP.5.1, insert the list of data for which modifications , deletions or replications can be detected. 740 In FDP_ITP.5.2, insert the list of data for which protection should be established at transmission. 741 In FDP_ITP.5.3, insert the list of authorised users and/or subjects. 742 In FDP_ITP.5.4, insert the list of recoverable modifications, deletions and replications. Dependencies: No dependencies. Elements: FDP_ITP.5.1 The TSF shall be able to detect any unauthorised modifications , deletions or replications to any of the following data received from another TSF which supports the protection of data it sends: [The list of data for which modifications , deletions or replications can be detected] FDP_ITP.5.2 The TSF establish protection of the following data so that a receiving TSF will be able to detect any unauthorised modifications , deletions or replications : [The list of data to be protected for sending] FDP_ITP.5.3 The TSF shall allow the following users and/or subjects to make use of the data exchange integrity mechanism: D R A F T FDP_SAC - Security Attribute Consistency User Data Protection Page 168 of 246 CCEB-94/083 Version 0.90 94/10/31 [The list of authorised users and/or subjects] FDP_ITP.5.4 For the following unauthorised modifications, deletions or replications of the protected data, the TSF shall be able to recover the original data: [The list of recoverable modifications, deletions and replications] FDP_SAC Security Attribute Consistency Family behaviour 743 The security attributes associated with an access control or information flow control policy could need to be transmitted to a another TSF. This family defines the requirements to enforce a the enforcement of a consistent mapping of any relevant user security attributes transmitted between different TSFs. Threats 744 This family addresses the threats of inconsistency of interpretation between TSFs of the security attributes used in an information flow control or access control policy. Other relevant families 745 FDP_ACC Access Control 746 FDP_IFC Information Flow Control 747 FDP_SAT Security Attribute Transfer 748 FIA_ATC User Attribute Consistency Component levelling 749 There is only one component in this family. 750 FDP_SAC.1 Security Attribute Consistency between TSFs, requires that the TSF provide mechanisms to provide consistency of attributes between TSFs. Application Notes User Application Notes 751 The component in this family is intended to provide requirements for automated support for security attribute consistency. It is also possible that wholly procedural means could be used to produce security attribute consistency but they are not provided for here. D R A F T User Data Protection FDP_SAC - Security Attribute Consistency 94/10/31 CCEB-94/083 Version 0.90 Page 169 of 246 Audit 752 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of security attribute consistency mechanisms. b) Basic: Any use of the security attribute consistency mechanisms. c) Basic: Identification of which security attributes have been interpreted. d) Detailed: Capture of the actual values of each security attribute. Documentation 753 The ADV_FSP Functional specification assurance documentation shall contain a specification of the manner in which the TSF maintains consistency of security attributes between TSFs. FDP_SAC.1 Security Attribute Consistency between TSFs Hierarchical to: no other components. Component rationale and application notes User Application Notes 754 The TSF is responsible maintaining the consistency of attributes associated with users that are common between two or more security domains. Operations Assignment: 755 In FDP_SAC.1.1, define the security attributes which must able to be consistently mapped between TSFs. Dependencies: No dependencies. Elements: FDP_SAC.1.1 The TSF shall provide the capability to allow the consistent interpretation the following security attributes between the TSF and another similarly equipped TSF: [List of the security attributes to be mapped between TSFs] D R A F T FDP_SAT - Security Attribute Transfer User Data Protection Page 170 of 246 CCEB-94/083 Version 0.90 94/10/31 FDP_SAT Security Attribute Transfer Family behaviour 756 This family defines the requirements for reliably transferring security attributes associated with user data between TSFs. Threats 757 This addresses the threat that information will be protected incorrectly after being transmitted from one TSF to another due to modification of its security attributes during transmission. Other relevant families 758 This family does not define requirements for the correct interpretation of these security attributes; those requirements are defined in FDP_SAC. 759 Likewise, this family does not define requirements for the protection of user data; those requirements are in FDP_ITP. 760 The mechanisms in this component exist to support the policies of FDP_ACC Access Control and FDP_IFC Information Flow Control. The cross- references for those families discuss additional family relationships. Component levelling 761 The first component, FDP_SAT.1 Basic Security Attribute Transfer, requires only that modification of security attributes be detectable and that modified attributes be rejected along with any associated user data. 762 The second component, FDP_SAT.2 Reliable Security Attribute Transfer, additionally requires that the TSF be able to attempt to recover the original attributes before rejecting the attributes and user data. Application Notes Audit 763 The following suggested auditable activities should be considered if FAU Security Audit is included in the PP/ST: a) Minimal: Detection of modified security attributes. b) Basic: Corrections to modified security attributes. c) Detailed: The types and/or effects of any detected modifications of transmitted security attributes. D R A F T User Data Protection FDP_SAT - Security Attribute Transfer 94/10/31 CCEB-94/083 Version 0.90 Page 171 of 246 FDP_SAT.1 Basic Security Attribute Transfer Hierarchical to: No other components. Component rationale and application notes User Application Notes 764 The TSF has the ability to detect modifications to security attributes transmitted in association with user data. If any modifications are detected then the user data will be rejected. Operations Assignment: 765 In FDP_SAT.1.1, insert the list of user data for which protected security attributes should be transmitted and the list of which security attributes should be protected in transmission. Dependencies: No dependencies. Elements: FDP_SAT.1.1 The TSF shall be able to detect any unauthorised modifications to the security attributes transmitted in association with the following user data: [The list of user data and the associated protected security attributes] FDP_SAT.1.2 The TSF shall, upon detection of any modifications of the security attributes associated with the received user data, reject the user data. FDP_SAT.2 Reliable Security Attribute Transfer Hierarchical to: FDP_SAT.1 Component rationale and application notes User Application Notes 766 The TSF has the ability to detect modifications to security attributes transmitted in association with user data. If any modifications are detected the TSF will attempt to correct the modifications before rejecting the user data if the modifications could not be reversed. D R A F T FDP_SAT - Security Attribute Transfer User Data Protection Page 172 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations Assignment: 767 In FDP_SAT.1.1, insert the list of user data for which protected security attributes should be transmitted and the list of which security attributes should be protected in transmission. 768 In FDP_ITP.5.4, insert the list of recoverable modifications. Dependencies: No dependencies. Elements: FDP_SAT.2.1 The TSF shall be able to detect any unauthorised modifications to the security attributes transmitted in association with the following user data: [The list of user data and the associated protected security attributes] FDP_SAT.2.2 The TSF shall be able to attempt to recover the original unmodified security attributes after detecting any of the following modifications: [The list of recoverable modifications of protected security attributes] FDP_SAT.2.3 The TSF shall, upon detection of any unrecoverable modifications of the security attributes associated with the received user data, reject the user data. D R A F T 182 CCEB-94/083 94/10/31 Version 0.90 Page 173 of 182 Class FRU Resource Utilisation Editor Note: Text is needed as an introduction to this class. Resource Utilization | | 2 | - FRU_RSA - 1 < > 4 - 5 | 3 | | - FRU_PRS - 1 - 2 - 3 | | - FRU_FLT - 1 - 2 Figure 2.8 - Resource Utilisation class decomposition FRU_RSA Resource Allocation Family behaviour 769 The requirements of this family provide controls that prevent one or more subjects from having the ability to monopolise resources within the TSF boundary in an unauthorised manner. 770 The requirements of this family allow the TSF to control the use of resources within the TSF Boundary by subjects such that unauthorised denial of service will not take place. Denial-of-service protection can be provided by containing resource allocations in time and space. 771 Resource allocation rules may allow the creation of quotas or other means of defining limits on the amount of resource space or time that may be allocated on behalf of a specific user, process, or task. These rules may, for example: - Provide for object quotas that constrain the number and/or size of objects a specific user may allocate. D R A F T FRU_RSA - Resource Allocation Resource Utilisation Page 174 of 246 CCEB-94/083 Version 0.90 94/10/31 - Control the allocation/deallocation of preassigned resource blocks where these blocks are defined under the control of the TSF. 772 In general, these mechanisms will be implemented through the use of attributes assigned to subjects and resources. Threats 773 The components in this family reduces the threats of denial of service attacks based upon consuming a disproportionate share of resources. 774 The components in this family reduces the threats of denial of service attacks based upon consuming of unauthorised shares of resources. Other relevant families 775 FRU_PRS Priority of Service. 776 FDP_IFC Information Flow Control Component levelling 777 The components in this family are levelled in a hierarchical manner on the basis of the coverage of the TOE resources which are protected and upon the granularity of control available over these resources. 778 FRU_RSA.1 Simple Quotas is intended to provide a rating to quota mechanisms which only apply to some of the shareable resources in the TOE and associated with a user or possibly assigned to groups of users as applicable to the TOE. 779 FRU_RSA.2 Complete Quotas is intended to provide a rating to quota mechanisms which applies to all of the shareable resources in the TOE and associated with a user or possibly assigned to groups of users as applicable to the TOE. 780 FRU_RSA.3 Individual Quotas is intended to provide a rating to quota mechanisms which only apply to some of the shareable resources in the TOE to the granularity of the single user. 781 FRU_RSA.4 Complete Individual Quotas is intended to provide a rating to quota mechanisms apply to all shareable resources to the granularity of the single user. 782 FRU_RSA.5 Complete Resource Control is intended to provide a rating to quota mechanisms which ensure that no other users of the TOE can deny a single user to their minimum quota of resources. D R A F T Resource Utilisation FRU_RSA - Resource Allocation 94/10/31 CCEB-94/083 Version 0.90 Page 175 of 246 Application Notes Audit 783 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Rejection of allocation operation based on use of the resource allocation functions. b) Basic: All attempted uses of the resource allocation functions. Documentation 784 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Information on how users are to use the Resource allocation [AGD_USR User guidance] b) Information on how administrators are to setup and configure the resource allocation [AGD_ADM Administrator guidance] FRU_RSA.1 Simple Quotas Hierarchical to: no other components. Component rationale and application notes 785 This component is intended to provide a rating to quota mechanisms which only apply to some of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user or a process, or possibly assigned to groups of users or processes as applicable to the TOE. Operations Assignment: 786 For FRU_RSA.1.1, the PP/ST writer should specify the list of [defined resources] for which resource allocation is required (e.g. resources such as processes, disk space, memory, bandwidth). Dependencies: FIA_UID.1 Basic User Identification D R A F T FRU_RSA - Resource Allocation Resource Utilisation Page 176 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FRU_RSA.1.1 The TSF shall enforce quotas limiting the maximum quantity of each [defined resource] which a subject or defined group of subjects can use at any one time or over a given period of time. FRU_RSA.1.2 For each controlled resource, there shall be an administrative interface allowing an authorised user to set the resource allocation limits. FRU_RSA.2 Complete Quotas Hierarchical to: FRU_RSA.1 Component rationale and application notes 787 This component is intended to provide a rating to quota mechanisms which applies to all of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user or a process, or possibly assigned to groups of users or processes as applicable to the TOE. Operations No permitted operation. Dependencies: FIA_UID.1 Basic User Identification Elements: FRU_RSA.2.1 The TSF shall enforce quotas limiting the maximum quantity of all of the shareable TOE resources, which a subject or defined group of subjects can use at any one time or over a given period of time. FRU_RSA.2.2 For each controlled resource, there shall be an administrative interface allowing an authorised user to set the resource limits for each defined resource. FRU_RSA.3 Individual Quotas Hierarchical to: FRU_RSA.1 Component rationale and application notes 788 This component is intended to provide a rating to quota mechanisms which only apply to some of the shareable resources in the TOE. In addition, this component levies the requirements against each user and there must be a mechanism for the setting of unique quota values for each user. D R A F T Resource Utilisation FRU_RSA - Resource Allocation 94/10/31 CCEB-94/083 Version 0.90 Page 177 of 246 Operations Assignment: 789 For FRU_RSA.3.1, the PP/ST author should specify the list of [defined resources] for which resource allocation is required (e.g. resources such as processes, disk space, memory, bandwidth). Dependencies: FIA_UID.2 Unique Identification of Users Elements: FRU_RSA.3.1 The TSF shall enforce quotas limiting the maximum quantity of each [defined resource] which a user can use at any one time or over a given period of time. FRU_RSA.3.2 For each controlled resource, there shall be an administrative interface allowing an authorised user to set the resource allocation limits to the granularity of the single user. FRU_RSA.4 Complete Individual Quotas Hierarchical to: either FRU_RSA.2 or FRU_RSA.3 Component rationale and application notes 790 This component is intended to provide a rating to quota mechanisms apply to all shareable resources to the granularity of the single user. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users Elements: FRU_RSA.4.1 The TSF shall enforce quotas limiting the maximum quantity of each all of the shareable TOE resources, which a user can use at any one time or over a given period of time. FRU_RSA.4.2 For each controlled resource, there shall be an administrative interface allowing an authorised user to set the resource allocation limits to the granularity of the single user. D R A F T FRU_PRS - Priority of Service Resource Utilisation Page 178 of 246 CCEB-94/083 Version 0.90 94/10/31 FRU_RSA.5 Complete Resource Control Hierarchical to: FRU_RSA.4 Component rationale and application notes 791 This component is intended to provide a rating to quota mechanisms which ensure that no other users of the TOE can deny a single user to their minimum quota of resources. Operations No permitted operation. Dependencies: FIA_UID.2 Unique Identification of Users Elements: FRU_RSA.5.1 The TSF shall enforce quotas limiting the maximum quantity of each all of the shareable TOE resources, which a user can use at any one time or over a given period of time. FRU_RSA.5.2 For each controlled resource, there shall be an administrative interface allowing an authorised user to set the resource allocation limits to the granularity of the single user. FRU_RSA.5.3 For all of the shareable TOE resources, the TSF shall enforce quotas limiting the use of TOE resources by other users to ensure that any single user can always get access to their minimum allocation of these resources. FRU_PRS Priority of Service Family behaviour 792 The requirements of this family allow the TSF to control the use of resources within the TSF Boundary by users and subjects such that high priority tasks within the TSC will always be accomplished without interference or delay due to low priority tasks. Threats 793 The components in this family reduces the threat that low priority work could interrupt, delay or stop high priority work from occurring. Other relevant families 794 FRU_RSA Resource Allocation D R A F T Resource Utilisation FRU_PRS - Priority of Service 94/10/31 CCEB-94/083 Version 0.90 Page 179 of 246 795 FDP_IFC Information Flow Control Component levelling 796 These components are levelled on the basis of the coverage of resources which are controlled and whether the priority mechanism is passive (i.e. first come, first served) or pre-emptive. 797 FRU_PRS.1 Limited Priority of Service provides priorities for subject's use of only a limited subset of the TOE resources with a passive priority mechanism. 798 FRU_PRS.2 Passive Priority of Service provides priorities for subject's use of all of the shareable TOE resources with a passive priority mechanism. 799 FRU_PRS.3 Pre-emptive Priority of Service provides priorities for subject's use of all of the shareable TOE resources and with a pre-emptive priority mechanism. Application Notes Audit 800 The following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Rejection of allocation operation based on use of the priority of service functions. b) Basic: All attempted uses of the priority of service functions. Documentation 801 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Information on how users are to use the priority of service functions [AGD_USR User guidance] b) Information on how administrators are to setup and configure the priority of service [AGD_ADM Administrator guidance] D R A F T FRU_PRS - Priority of Service Resource Utilisation Page 180 of 246 CCEB-94/083 Version 0.90 94/10/31 FRU_PRS.1 Limited Priority of Service Hierarchical to: no other components. Component rationale and application notes 802 Provides priorities for subject's use of only a limited subset of the TOE resources but will not pre-emptively reclaim resources from lower priority subjects to meet the needs of higher priority subjects. Operations Assignment: 803 For FRU_RSA.1.2, the PP/ST writer should specify the list of [defined resources] for which the TSF enforces priority of service (e.g. resources such as processes, disk space, memory, bandwidth). Dependencies: No dependencies. Elements: FRU_PRS.1.1 The TSF shall provide an administrative interface allowing an authorised user to assign a priority of service with each subject in the TSF. Or: The TSF shall associate a priority with each subject in the TSF, as assigned by an authorised user. FRU_PRS.1.2 The TSF shall ensure that the subjects with the highest priority get access to each [defined resource] before any subjects with lower priority. FRU_PRS.2 Passive Priority of Service Hierarchical to: FRU_PRS.1 Component rationale and application notes 804 Provides priorities for subject's use of all of the shareable TOE resources but will not pre-emptively reclaim resources from lower priority subjects to meet the needs of higher priority subjects. Operations No permitted operation. Dependencies: No dependencies. D R A F T Resource Utilisation FRU_PRS - Priority of Service 94/10/31 CCEB-94/083 Version 0.90 Page 181 of 246 Elements: FRU_PRS.2.1 The TSF shall provide an administrative interface allowing an authorised user to assign a priority of service with each subject in the TSF. FRU_PRS.2.2 The TSF shall ensure that the subjects with the highest priority get access to all shareable TOE resources before any subjects with lower priority. FRU_PRS.3 Pre-emptive Priority of Service Hierarchical to: FRU_PRS.2 Component rationale and application notes 805 Provides priorities for subject's use of all of the shareable TOE resources and allows priorities to be set which pre-empt the use by low- priority subjects when they are requested by high-priority subjects for a subset of resources. Audit 806 In addition, the following actions should be audited if FAU Security Audit is included in the PP/ST: a) Minimal: Successful use of the pre-emptive priority of service functions. b) Basic: All attempted uses of the pre-emptive priority of service functions. Operations Assignment: 807 For FRU_PRS.3.4, the PP/ST writer should specify the list of [defined resources] for which the TSF enforces pre-emptive priority of service (e.g. resources such as processes, disk space, memory, bandwidth). Dependencies: No dependencies. Elements: FRU_PRS.3.1 The TSF shall provide an administrative interface allowing an authorised user to assign a priority of service with each subject in the TSF. FRU_PRS.3.2 The TSF shall ensure that the subjects with the highest priority get access to all shareable TOE resources before any subjects with lower priority. FRU_PRS.3.3 The TSF shall allow an authorised user to assign the priority or priorities at which a subject is able to pre-empt resource use by other lower- priority subjects. D R A F T FRU_FLT - Fault Tolerance Resource Utilisation Page 182 of 246 CCEB-94/083 Version 0.90 94/10/31 FRU_PRS.3.4 For each [defined resource] the TSF shall pre-empt their use by low-priority subjects when a subject which has a pre-emptive priority needs the resource and it cannot be allocated in any other less disruptive manner. FRU_FLT Fault Tolerance Family behaviour 808 The requirements of this family ensure that the TOE will continue correct operation and continue enforcement of its TSP even in the event of failures. Threats 809 The components in this family addresses the threats of attacks based upon human induced hardware failures. Other relevant families 810 FPT_RCV Trusted Recovery 811 FPT_SWM TSF Software Modification 812 FPT_FLS Fail-safe Component levelling 813 These components are levelled on the basis of the coverage of failures. 814 FRU_FLT.1 Limited Fault Tolerance requires the TOE to continue correct operation and correct TSP enforcement in the event of a subset of failures. 815 FRU_FLT.2 Fault Tolerance requires the TOE to continue correct operation and correct TSP enforcement in the event of all failures. FRU_FLT.1 Limited Fault Tolerance Component rationale and application notes 816 TBD FRU_FLT.2 Fault Tolerance Component rationale and application notes 817 TBD D R A F T 228 CCEB-94/083 94/10/31 Version 0.90 Page 183 of 228 Class FPT Protection of the Trusted Security Functions 818 This family contains the functional requirements that pertain to protecting the security functions and mechanisms themselves. This class also contains requirements that address the general administration and management (i.e., administration and management concerns not addressed in other functional classes) of the TOE. Protection of the Trusted Security Functions | | - FPT_SEP - 1 - 2 | | - FPT_TSA - 1 - 2 - 3 - 4 | | - FPT_TSM - 1 - 2 | | - FPT_TSU - 1 - 2 | | - FPT_RCV - 1 - 2 - 3 | | - FPT_RVM - 1 - 2 - 3 - 4 | | - FPT_ITC - TBD | | - FPT_ITI - TBD | | - FPT_ITA - TBD | | - FPT_SWM - TBD | | - FPT_TST - TBD | | - FPT_AMT - 1 - 2 - 3 | | - FPT_FLS - TBD | | - FPT_PHP - 1 - 2 - 3 Figure 2.9 - Protection of the Trusted Security Functions class decomposition D R A F T FPT_SEP - Domain Separation Protection of the Trusted Security Functions Page 184 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_SEP Domain Separation Family behaviour 819 The elements of this family ensure that at least one domain is available for the TSF's own execution, and that the TSF is protected from external interference and tampering (e.g., by modification of TSF code or data structures) by unprivileged subjects. Satisfying the requirements of this family makes the TSF self-protecting and, therefore, an unprivileged subject cannot modify or damage the TSF. 820 This family requires, for example, that: a) The resources of the domain and those of entities external to the domain are separated such that the domain-external entities cannot observe or modify domain-internal data structures or code; b) The transfers between domains are controlled such that arbitrary entry to or return from the protected domain is not possible; and, c) The user or application parameters passed to the protected domain by addresses are validated with respect to the protected domain's address space, and those passed by value are validated with respect to the values expected by the protected domain. Threats 821 This family addresses the threat of unauthorised observation and/or modification of the TSF's internal code or data. 822 Further, it addresses the threat that the non reference validation mechanism (non-RVM) portions of the TSF can violate the TSP. Other relevant families 823 FPT_RVM Reference Mediation 824 ADV_INT TSF internals Component levelling 825 This family has been levelled based on the number of available domains. 826 The first component, FPT_SEP.1 TSF Domain Separation, provides two domains: one for the TSF, and one for entities external to the TSF. 827 The second component, FPT_SEP.2 Separate Reference Validation Mechanism (RVM) Domain, is dependent on the presence of an RVM; if one is present, it must be implemented in a domain distinct from that of the remainder of the TSF. D R A F T Protection of the Trusted Security Functions FPT_SEP - Domain Separation 94/10/31 CCEB-94/083 Version 0.90 Page 185 of 246 Application Notes User Application Notes 828 This family is needed whenever confidence is required that the TSF has not been subverted. Documentation 829 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Description of the architecture and design of the domain separation mechanism [Architectural Design, Detailed Design] FPT_SEP.1 TSF Domain Separation Hierarchical to: no other components. Component rationale and application notes Rationale 830 Without a separate domain for the TSF, there can be no assurance that the TSF has not been subjected to any tampering attacks. Operations No permitted operation. Dependencies: No dependencies. Elements: FPT_SEP.1.1 The TSF shall maintain a domain for its own execution that protects it from interference and tampering (e.g., modification or unauthorised observation of the TSF's code and data structures) by subjects external to the TSF. D R A F T FPT_SEP - Domain Separation Protection of the Trusted Security Functions Page 186 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_SEP.2 Separate Reference Validation Mechanism (RVM) Domain Hierarchical to: FPT_SEP.1 Component rationale and application notes Rationale 831 The most important functions provided by a TSF is the RVM. In order to ensure that it has the characteristics of an RVM, in particular tamperproofness, it must be in a domain distinct from the remainder of the TSF. User Application Notes 832 This component is intended to be used in conjunction with component FPT_RVM.4 of the Reference Mediation family. Documentation 833 In addition to the documentation requirements applicable to all components in the FPT_SEP family, the following assurance documentation, if applicable, shall contain the indicated information: a) A description of how the TSF satisfies the requirements of a reference validation mechanism. [ADV_HLD High-level design] Operations No permitted operation. Dependencies: FPT_RVM.4 Separate Reference Validation Mechanism Elements: FPT_SEP.2.1 The RVM of the TSF shall maintain a domain for its own execution that protects it from interference and tampering (e.g., modification or unauthorised observation of the RVM 's code and data structures) by the non- RVM portion of the TSF and by subjects external to the TSF. FPT_SEP.2.2 The RVM portion of the TSF shall provide a distinct domain for the execution of the non-RVM portion of the TSF that protects the non-RVM portion of the TSF from interference and tampering (e.g., modification or unauthorised observation of the TSF's non-RVM code and data structures) by subjects external to the TSF. D R A F T Protection of the Trusted Security Functions FPT_TSA - TOE Security 94/10/31 CCEB-94/083 Version 0.90 Page 187 of 246 FPT_TSA TOE Security Administration Family behaviour 834 The TSF includes security administration families to allow administrative users to control the secure operation of the TOE, and to restrict the accessibility of security management functions to authorised users. At higher levels of this family, the administrative function is subdivided into distinct roles. Threats 835 This family addresses the threat of abuse of the TSF by those entities external to the TOE upon which the TOE's security depends (e.g., administrators, operators). Other relevant families 836 Component levelling 837 This family has been levelled based on the granularity of the division and restriction of the security administration function. 838 The first component, FPT_TSA.1 Basic Security Administration, requires that sufficient functions be available through the TSF to securely install, configure, and mange to the TOE; and that these functions be identified and accessible to authorised users only. 839 The second component, FPT_TSA.2 Separate Security Administrative Role, elaborates on this by establishing a distinct administrative role to which these functions are restricted; explict action is required to assume this role. 840 The third component, FPT_TSA.3 Multiple Security Administrative Roles, provides further restrictions on the administrator by dividing the security relevant TSF functions into multiple administrative roles (for example, administrator and operator, auditor, account administrator). 841 The last component, FPT_TSA.4 Well-Defined Administrative Roles, further restricts each of the administrative roles by limiting the functions available in an administrative role to the minimal set required to act in that role. 842 Note that this family does not address restrictions on non-security- relevant administrative actions, as they do not affect the TSF. D R A F T FPT_TSA - TOE Security Administration Protection of the Trusted Security Page 188 of 246 CCEB-94/083 Version 0.90 94/10/31 Application Notes User Application Notes 843 This family addresses the general administration of TSF administrative actions. The requirements for administration for each policy (be it user data protection, accountability, or audit) are provided by families in each of the corresponding classes. Audit 844 The following actions of this component should be audited if FAU_GEN Security Audit Event Generation is included in the PP/ST: a) Use of a security-relevant administrative function. Documentation 845 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Specification of the security-relevant administrative functions in the TSF [ADV_FSP Functional specification] FPT_TSA.1 Basic Security Administration Hierarchical to: no other components. Component rationale and application notes User Application Notes 846 This component addresses threats from unauthorised users inappropriately invoking security-relevant administrative TSF functions. It should be used when minimal protection of security management functions is required. This minimal protection is achieved by explicitly associating security-relevant administrative functions with specifically authorised users. 847 This component requires that an attribute be maintained as part of the user's identification information that identifies whether the user is authorised to use security-relevant administrative functions. Evaluator's application notes 848 It is acceptable for many of the security administration functions to be available only in a maintenance or off-line mode. 849 For FPT_TSA.1.1 and FPT_TSA.1.2, the security-relevant functions must minimally include all functions necessary to securely manage a given TOE, even if D R A F T Protection of the Trusted Security Functions FPT_TSA - TOE Security 94/10/31 CCEB-94/083 Version 0.90 Page 189 of 246 those functions are not explicitly listed in the requirement. The TOE developer must define and justify that all such functions are included. 850 For FPT_TSA.1.3, the TSF must provide some explicit mechanism to identify the users that are authorised to use security-relevant functions. A TOE that claims that all users are authorised to use security-relevant administrative functions is not acceptable. Rationale 851 At a minimum, the TSF must provide the ability to associate security- relevant functions with specifically authorised users, or there can be no assurance that security management is controlled. Operations Assignment: 852 In FPT_TSA.1.2, the PP/ST author should list any specific security relevant administrative functions considered minimally acceptable for this requirement. These minimal functions will depend on the other components included in the profile, but can include functions such as audit log maintenance, user authentication data management, and system initialisation and configuration. Dependencies: FIA_UID.1 Basic User Identification FIA_ATD User Attribute Definition FIA_ATA User Attribute Administration AGD_ADM.1 Administration guidance Elements: FPT_TSA.1.1 All security-relevant administrative functions shall be identified. FPT_TSA.1.2 The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: [The list of services to be minimally supplied should be identified here] FPT_TSA.1.3 Use of the security-relevant administrative functions shall be restricted to authorised users. FPT_TSA.1.4 The TSF shall be capable of distinguishing the set of users authorised for administrative functions from the set of all users of the TOE. D R A F T FPT_TSA - TOE Security Administration Protection of the Trusted Security Page 190 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_TSA.2 Separate Security Administrative Role Hierarchical to: FPT_TSA.1 Component rationale and application notes User Application Notes 853 This component is intended for use in TOEs that do not require any fine-grained controls other than a distinction between administrative and non- administrative users. There is not a requirement for a non-security-relevant administrator role, although such a division is recommended. Actions taken by a non-security-relevant administrator can have no affect on the TSF (by definition); hence they are beyond the scope of this component. 854 This component addresses the threat of damage resulting from unprivileged users performing administrative functions. It also addresses the threat that inadequate mechanisms have been provided to securely administer the TSF. 855 This component requires that an attribute be maintained as part of the user's identification information that identifies whether the user is authorised to assume the security administrative role. Audit 856 In addition to the audit required for all components in this family, the following actions of this component should also be audited if FAU_GEN Security Audit Event Generation is included in the PP/ST: a) Explicit requests to assume the security administrative role Evaluator's application notes 857 It is acceptable for many of the security administration functions to be available only in a maintenance or off-line mode. 858 For FPT_TSA.2.1 and FPT_TSA.2.2, the security-relevant functions must minimally include all functions necessary to securely manage a given TOE, even if those functions are not explicitly listed in the requirement. The TOE developer must define and justify that all such functions are included. 859 For FPT_TSA.2.3, the TSF must provide some explicit mechanism to identify the users that are authorised to use security-relevant functions. A TOE that claims that all users are authorised to use security-relevant administrative functions is not acceptable. Rationale 860 In situations where security administration is appropriate, it is also appropriate to ensure that users do not have access to administrative functions. D R A F T Protection of the Trusted Security Functions FPT_TSA - TOE Security 94/10/31 CCEB-94/083 Version 0.90 Page 191 of 246 Operations Assignment: 861 In FPT_TSA.2.2, the profile writer should list any specific security- relevant administrative functions considered minimally acceptable for this requirement. These minimal functions will depend on the other components included in the profile, but can include functions such as audit log maintenance, user authentication data management, and system initialisation and configuration. Dependencies: FIA_UID.1 Basic User Identification FIA_ATD User Attribute Definition FIA_ATA User Attribute Administration AGD_ADM.1 Administration guidance Elements: FPT_TSA.2.1 All security-relevant administrative functions shall be identified. FPT_TSA.2.2 The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: [The list of services to be minimally supplied should be identified by the profile writer] FPT_TSA.2.3 Use of the security-relevant administrative functions shall be restricted to a security administrative role that has clearly-defined boundaries . FPT_TSA.2.4 Only authorised users may be allowed to assume the security administrative role. FPT_TSA.2.5 An explicit request shall be made to the TSF in order for an authorised user to assume the security administrative role. FPT_TSA.3 Multiple Security Administrative Roles Hierarchical to: FPT_TSA.2 Component rationale and application notes User Application Notes 862 This component should be used when fine-grained administrative roles are necessary. The nature of the roles may be as simple or as complex as is necessary. A simple definition might be distinguishing between routine operator functions D R A F T FPT_TSA - TOE Security Administration Protection of the Trusted Security Page 192 of 246 CCEB-94/083 Version 0.90 94/10/31 (such as backup and restore) and other administration actions, such as audit analysis or account administration. Alternatively, it might be complex, with a distinct administrative user for each category of policy supported on the TSF; for example, account administrator, auditor, confidentiality-policy administrator. 863 In addition to addressing the threat of damage resulting from unprivileged users performing administrative functions, this component addresses the threat of administrative users abusing their authority by taking actions outside their assigned functional responsibilities. 864 This component requires that an attribute be maintained as part of the user's identification information that identifies the security administrative roles (if any) that the user is authorised to assume. Audit 865 In addition to the audit required for all components in this family, the following actions of this component should also be audited if FAU_GEN Security Audit Event Generation is included in the PP/ST: a) Explicit requests to assume a security administrative role Documentation 866 In addition to the documentation requirements applicable to all components in this family, the following assurance documentation, if applicable, shall contain the indicated information: a) Any administrative roles specifically designed into the TSF [ADV_FSP Functional specification] Evaluator's application notes 867 It is acceptable for many of the security administration functions to be available only in a maintenance or off-line mode. 868 For FPT_TSA.3.1 and FPT_TSA.3.2, the security-relevant functions must minimally include all functions necessary to securely manage a given TOE, even if those functions are not explicitly listed in the requirement. The TOE developer must define and justify that all such functions are included. 869 For FPT_TSA.3.5, the TSF must provide some explicit mechanism to identify the users that are authorised to use security-relevant functions. A TOE that claims that all users are authorised to use security-relevant administrative functions is not acceptable. 870 For FPT_TSA.3.6, the TSF must provide some explicit mechanism to identify the users that are authorised to use security-relevant functions and the roles for which they are authorised. A TOE that claims that all users are authorised for all security relevant administrative roles is not acceptable. D R A F T Protection of the Trusted Security Functions FPT_TSA - TOE Security 94/10/31 CCEB-94/083 Version 0.90 Page 193 of 246 Operations Assignment: 871 In FPT_TSA.3.2, the profile writer should list any specific security- relevant administrative functions considered minimally acceptable for this requirement. These minimal functions will depend on the other components included in the profile, but can include functions such as audit log maintenance, user authentication data management, and system initialisation and configuration. Assignment: 872 In FPT_TSA.3.3, the profile writer should list all security-relevant administrator roles defined for this product. The roles selected will depend on other components included in the profile, but can include roles such as operator, account administrator, auditor, TSP administrator, and system manager. Dependencies: FIA_UID.1 Basic User Identification FIA_ATD User Attribute Definition FIA_ATA User Attribute Administration AGD_ADM.1 Administration guidance Elements: FPT_TSA.3.1 All security-relevant administrative functions shall be identified. FPT_TSA.3.2 The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: [The list of services to be minimally supplied should be identified by the profile writer] FPT_TSA.3.3 The set of security administrative roles shall be defined, and shall minimally include the following: [The set of defined roles to be minimally supported should be identified by the profile writer.] FPT_TSA.3.4 Each security-relevant administrative function shall be assigned to at least one security administrative role. FPT_TSA.3.5 Use of a security-relevant administrative function shall be restricted to the security administrative role (s) authorised to use that function . D R A F T FPT_TSA - TOE Security Administration Protection of the Trusted Security Page 194 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_TSA.3.6 Users shall be allowed to assume only those security administrative roles for which they have been authorised. FPT_TSA.3.7 An explicit request to assume a specific security administrative role shall be made to the TSF in order for an authorised user to assume that security administrative role. FPT_TSA.4 Well-Defined Administrative Roles Hierarchical to: FPT_TSA.3 Component rationale and application notes User Application Notes 873 This component should be used when well-defined roles are required. Users assuming these roles are restricted by the TSF to only those functions required to perform those roles. As this restriction requires administrative roles to communicate only with the TSF, a dependency on Trusted Path is introduced. 874 This component addresses the threat of damage resulting from unprivileged users and from administrative users abusing their authority by taking actions outside their assigned functional responsibilities. It also addresses the threat that inadequate mechanisms have been provided to securely administer the TSF. 875 This component requires that an attribute be maintained as part of the user's identification information that identifies the security administrative roles (if any) that the user is authorised to assume. Audit 876 In addition to the audit required for all components in this family, the following actions of this component should also be audited if FAU_GEN Security Audit Event Generation is included in the PP/ST: a) Explicit requests to assume a security administrative role Documentation 877 In addition to the documentation requirements applicable to all components in this family, the following assurance documentation, if applicable, shall contain the indicated information: a) Any administrative roles specifically designed into the TSF [ADV_FSP Functional specification] Evaluator's application notes 878 It is acceptable for many of the security administration functions to be available only in a maintenance or off-line mode. D R A F T Protection of the Trusted Security Functions FPT_TSA - TOE Security 94/10/31 CCEB-94/083 Version 0.90 Page 195 of 246 879 For FPT_TSA.4.1, the security-relevant administrative functions must minimally include all functions necessary to securely manage a given TOE, even if those functions are not explicitly listed in the requirement. The TOE developer must define and justify that all such functions are included. 880 For FPT_TSA.4.3, it is anticipated that most security-relevant functions will be assigned to only one role. However, there may be selected common utilities that will be accessible to multiple roles (for example, electronic mail capabilities to notify users). Functions available to more than one role will require justification. 881 For FPT_TSA.4.5, the TSF must provide some explicit mechanism to identify the users that are authorised to use security-relevant functions and the roles for which they are authorised. A TOE that claims that all users are authorised for all security relevant administrative roles is not acceptable. Operations Assignment: 882 In FPT_TSA.4.2, the profile writer should list any specific security- relevant administrative functions considered minimally acceptable for this requirement. These minimal functions will depend on the other components included in the profile, but can include functions such as audit log maintenance, user authentication data management, and system initialisation and configuration. Assignment: 883 In FPT_TSA.4.3, the profile writer should list all security-relevant administrator roles defined for this product. The roles selected will depend on other components included in the profile, but can include roles such as operator, account administrator, auditor, TSP administrator, and system manager. Dependencies: FIA_UID.1 Basic User Identification AGD_ADM.1 Administration guidance FTP_TRP.2 Expanded-Use Trusted Path Elements: FPT_TSA.4.1 All security-relevant administrative functions shall be identified. FPT_TSA.4.2 The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the TSF; minimally, this set shall include the following services: [The list of services to be minimally supplied should be identified by the profile writer] D R A F T FPT_TSM - TOE Security ManagementProtection of the Trusted Security Functions Page 196 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_TSA.4.3 The set of security administrative roles shall be defined, and shall minimally include the following: [The set of defined roles to be minimally supported should be identified by the profile writer.] FPT_TSA.4.4 Each security-relevant administrative function shall be assigned to a security administrative role. FPT_TSA.4.5 Use of a security-relevant administrative function shall be restricted to the security administrative role(s) authorised to use that function. FPT_TSA.4.6 Users shall be allowed to assume only those security administrative roles for which they have been authorised. FPT_TSA.4.7 An explicit request shall be made to the TSF in order for an authorised user to assume the security administrative role. FPT_TSA.4.8 The functions assigned to each security administrative user role shall maximally include only those functions strictly required to perform that role effectively. FPT_TSM TOE Security Management Family behaviour 884 The TSF of a TOE should provide security management functions to enable administrative users to set up and control the secure operation of the product. These administrative functions typically fall into a number of different categories: a) Management functions that relate to control over the specific TSP enforced by the TOE. For example, definition and update of per-user policy attributes (such as user clearance), known system access control labels, control and management of user groups. b) Management functions that relate to accountability and authentication controls enforced by the TOE. For example, definition and update of user security characteristics (e.g., unique identifiers associated with user names, user accounts, system entry parameters) or auditing system controls (e.g., selection of audit events, management of audit trails, audit trail analysis, and audit report generation). c) Management functions that relate to controls over availability. For example, definition and update of availability parameters or resource quotas. d) Management functions that relate to general installation and configuration. For example, TOE configuration, manual recovery, installation of TOE security fixes (if any), repair and reinstallation of hardware. D R A F T Protection of the Trusted Security FunctionsFPT_TSM - TOE Security Management 94/10/31 CCEB-94/083 Version 0.90 Page 197 of 246 e) Management functions that relate to routine control and maintenance of TOE resources. For example, enabling and disabling peripheral devices, mounting of removable storage media, backup and recovery of user and system objects. 885 The first three categories of these functions are specific to the type of policy included in the PP/ST. Accordingly, the families that address these functions are included in the policy-specific groups. The latter two categories, however, are much more independent of policy, are addressed by this family. 886 Note that all of these functions need to be present in a TOE, depending on the families included in the PP or ST. It is the responsibility of the PP/ST author to ensure that adequate functions will be provided to manage the system in a secure fashion. Threats 887 The security management functions included in this family address the threat that inadequate functions have been provided to administer the system. 888 These functions also address the threat of external disaster, by requiring backup and restoration capabilities. These capabilities should be complemented by adequate procedural controls that address storage of backups. Other relevant families 889 FPT_RCV Trusted Recovery 890 FIA_ATA User Attribute Administration 891 FIA_AAA User Authentication Attribute Administration 892 FAU_MGT Security Audit Management 893 FIA_ATA User Attribute Administration 894 FDP_IFC Information Flow Control 895 FTE_TEM TOE Entry Management 896 FPT_SWM TSF Software Modification 897 AGD_ADM Administrator guidance Component levelling 898 This family is levelled based on the coverage of the management functions. D R A F T FPT_TSM - TOE Security ManagementProtection of the Trusted Security Functions Page 198 of 246 CCEB-94/083 Version 0.90 94/10/31 899 FPT_TSM.1 Partial Management Functions allows management operations to apply to defined subsets of configuration options, peripheral devices, and system and user objects. 900 At FPT_TSM.2 Full Management Functions, coverage is widened to include all configuration options, peripheral devices, and system and user objects. FPT_TSM.1 Partial Management Functions Hierarchical to: no other components. Component rationale and application notes User Application Notes 901 This component should be used when full flexibility of management is not required. It addresses the threat that inadequate capabilities have been provided to the administrator for system management, and partially addresses the threat of external disaster by providing backup capabilities. 902 For FPT_TSM.1.1, it is the responsibility of the PP/ST author to identify the significant TSF configuration parameters that must be settable by the administrator. Determination of any additional parameters that may be settable by the administrator is up to the developer. 903 For FPT_TSM.1.2, it is the responsibility of the PP/ST author to identify the minimal set of peripherals that must be capable of being enabled or disabled by the administrator. Determination of any additional peripherals that are capable of being enabled or disabled by the administrator is up to the developer. 904 For FPT_TSM.1.3, it is the responsibility of the PP/ST author to identify the significant system and user objects that must be capable of being backed up and restored. Determination of any additional system and user objects that are capable of being backed-up or restored is up to the developer. Evaluator's application notes 905 The developer is allowed to include additional items in any of the sets subject to assignment. Rationale 906 In most cases, full flexibility of management will not be required. When that is the situation, it is appropriate to use this component. D R A F T Protection of the Trusted Security FunctionsFPT_TSM - TOE Security Management 94/10/31 CCEB-94/083 Version 0.90 Page 199 of 246 Operations Assignment: 907 For FPT_TSM.1.1, the PP/ST author must identify any significant TSF configuration parameters that must be settable by the administrator. Assignment: 908 For FPT_TSM.1.2, the PP/ST author must identify any additional functions for control and maintenance of system resources that must be provided. Assignment: 909 For FPT_TSM.1.2, the PP/ST author must identify any specific peripherals that must be have the capability of being enabled or disabled by the administrator. Assignment: 910 For FPT_TSM.1.3, the PP/ST author must specify the types or specific system and user objects that must be capable of being backed-up and restored. Dependencies: FPT_TSA.1 Basic Security Administration Elements: FPT_TSM.1.1 The TSF shall provide administrative functions that allow setting and updating the following TSF configuration parameters: [Minimal set of settable TSF configuration parameters, specified by the PP/ST author] FPT_TSM.1.2 The TSF shall provide administrative functions for control and maintenance of system resources. These functions shall minimally include the following: a) Functions that allow enabling and disabling the following set of peripheral devices: - [List of peripheral devices that can be enabled/disabled by the administrator.] b) Functions that allow system start-up and shutdown c) [Other functions as determined by the PP/ST author] D R A F T FPT_TSM - TOE Security ManagementProtection of the Trusted Security Functions Page 200 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_TSM.1.3 The TSF shall provide administrative functions that are capable of backing-up and restoring the following system and user objects: [List of types or specific system and user objects that must be capable of being backed-up and restored] FPT_TSM.1.4 When restoring a system or user object from backup media, the TSF shall restore the object without loss of TSP-relevant object attributes. FPT_TSM.1.5 The TSF shall provide administrative functions to determine if the TSF is in a secure initial state. FPT_TSM.2 Full Management Functions Hierarchical to: FPT_TSM.1 Component rationale and application notes User Application Notes 911 This component should be used when full flexibility of management functions and complete preparation for disaster is required. This component addresses the threat that inadequate capabilities have been provided to the administrator for system management, and also the threat of external disaster by providing backup capabilities. 912 For FPT_TSM.2.3, it is the responsibility of the PP/ST author to identify the significant system and user objects that must be capable of being backed up and restored. Determination of any additional system and user objects that are capable of being backed-up or restored is up to the developer. Operations Assignment: 913 For FPT_TSM.2.2, the PP/ST author must identify any additional functions for control and maintenance of system resources that must be provided. Assignment: 914 For FPT_TSM.2.3, the PP/ST author must specify the types or specific system and user objects that must be capable of being backed-up and restored. Dependencies: FPT_TSA.1 Basic Security Administration D R A F T Protection of the Trusted Security Functions FPT_TSU - TOE Administrative Safe 94/10/31 CCEB-94/083 Version 0.90 Page 201 of 246 Elements: FPT_TSM.2.1 The TSF shall provide administrative functions that allow setting and updating all of the TSF's configuration parameters. FPT_TSM.2.2 The TSF shall provide administrative functions for control and maintenance of system resources. These functions shall minimally include the following: a) Functions that allow enabling and disabling all peripheral devices b) Functions that allow system start-up and shutdown c) [Other functions as determined by the PP/ST author] FPT_TSM.2.3 The TSF shall provide administrative functions that are capable of backing-up and restoring the following system and user objects: [List of types or specific system and user objects that must be capable of being backed-up and restored] FPT_TSM.2.4 When restoring a system or user object from backup media, the TSF shall restore the object without loss of TSP-relevant object attributes. FPT_TSM.2.5 The TSF shall provide administrative functions to determine if the TSF is in a secure state. FPT_TSU TOE Administrative Safe Use Family behaviour 915 The elements of this family address general characteristics of TSF administrative interfaces that reduce the likelihood that an unskilled administrative user will use a TSF interface in an insecure manner. To some extent, these components address ease of use of the administrative function; however, ease of use is a subjective measure that cannot be measured or evaluated. Threats 916 This family addresses the threat that an unskilled administrative user will use a TSF interface in an insecure manner. Other relevant families 917 FPT_FLS Fail-safe Component levelling 918 This family is levelled based upon the amount of protection from unskilled administrative users provided. D R A F T FPT_TSU - TOE Administrative Safe Use Protection of the Trusted Security Page 202 of 246 CCEB-94/083 Version 0.90 94/10/31 919 The first component, FPT_TSU.1 Enforcement of Administrative Guidance, simply requires that the TSF enforce any bounds restrictions described in the Administrative Guidance. 920 The second component, FPT_TSU.2 Safe Administrative Defaults, additionally requires that the TSF provide specific interfaces and options with fail-safe defaults. Application Notes Evaluator's application notes 921 Not all statements of legal or sensible values called out in Administrator Guidance can be checked or enforced by software. Some checks require knowledge beyond semantics and border on the realm of fuzzy logic and artificial intelligence. The judgement of whether a check of legal input value is enforceable must be left up to the skill of the evaluators. Documentation 922 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Any range constraints or specification of valid input values to be accepted by security relevant administrator commands. [AGD_ADM Administrator guidance] FPT_TSU.1 Enforcement of Administrative Guidance Hierarchical to: no other components. Component rationale and application notes User Application Notes 923 This component should be used in those situations where the PP/ST author wants to ensure that administrative restrictions are checked whenever possible. It addresses the threat of the unskilled administrative user providing out-of-range values through the administrative interface. Rationale 924 This component addresses problems that may result from boundary conditions being violated. Operations No permitted operation. D R A F T Protection of the Trusted Security Functions FPT_TSU - TOE Administrative Safe 94/10/31 CCEB-94/083 Version 0.90 Page 203 of 246 Dependencies: FPT_TSA.1 Basic Security Administration AGD_ADM.1 Administration guidance Elements: FPT_TSU.1.1 The security relevant administrative functions of the TSF shall enforce any enforceable checks of legal input values described in the Administrative Guidance. FPT_TSU.2 Safe Administrative Defaults Hierarchical to: FPT_TSU.1 Component rationale and application notes User Application Notes 925 This component should be used whenever there is the risk of unskilled administrators. It addresses the threat of the unskilled administrative user by not only enforcing bounds restrictions, but by reducing the need to guess parameters for selected commands (as defaults are provided). 926 It is the responsibility of the developer to determine the value for each default parameter in the absence of guidance elsewhere in the PP/ST. Evaluator's application notes 927 A default for a parameter is a value that is used for that parameter when null input is provided for that parameter through the TSF interface. For example: typing to a prompt; giving 0 or a null pointer through a function call. 928 A safe default is a default value that, if used, will not compromise the TSP of the TSF. Operations Assignment: 929 For FPT_TSM.2.1, the PP/ST author shall specify the situations in which defaults must be available. Dependencies: FPT_TSA.1 Basic Security Administration AGD_ADM.1 Administration guidance D R A F T FPT_RCV - Trusted Recovery Protection of the Trusted Security Functions Page 204 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FPT_TSU.2.1 The security relevant administrative functions of the TSF shall enforce any enforceable checks of legal input values described in the Administrative Guidance. FPT_TSU.2.2 Safe default options shall be provided in the following cases for security parameters of administrative TSF interfaces: [Specific cases in which defaults must be provided] FPT_RCV Trusted Recovery Family behaviour 930 The requirements of this family ensure that the TSF can determine that the TOE is started-up without protection compromise and can recover without protection compromise after discontinuity of operations. Satisfying the requirements of this family establishes that the initial and recovered states of the TSF satisfy the requirements. This family is important because the start-up state of the TSF determines the protection of subsequent states. 931 Recovery components reconstruct the TSF secure states or prevent transitions to insecure states as a direct response to occurrences of expected failures, discontinuity of operation or start-up. Failures that must be generally anticipated include the following: a) Unmaskable action failures that always result in a system crash (e.g., persistent inconsistency of critical system tables, uncontrolled transfers within the TSF code caused by transient failures of hardware or firmware, power failures, processor failures). b) Non-volatile media failures causing part or all of the media representing the TSF objects to become inaccessible or corrupt (e.g., disk head crash, persistent read/write failure caused by misaligned disk heads, worn-out magnetic coating, dust on the disk surface). c) Discontinuity of operation caused by erroneous administrative action or lack of timely administrative action (e.g., unexpected shutdowns by turning off power, ignoring the exhaustion of critical resources, inadequate installed configuration). 932 Mechanisms designed to detect exceptional conditions during operation fall under TSF Software Modification, TSF Self-Test, Fail-Safe, and other areas that address the concept of "Software Safety". D R A F T Protection of the Trusted Security Functions FPT_RCV - Trusted Recovery 94/10/31 CCEB-94/083 Version 0.90 Page 205 of 246 Threats 933 This family addresses the threats of protection compromise after restart resulting from the TOE entering an insecure state due to failure of some component after completion of system initialisation. 934 This family also addresses the threat of corruption of protection- critical TSF structures on non-volatile media. Other relevant families 935 FRU_FLT Fault Tolerance 936 FPT_FLS Fail-safe 937 FPT_TST TSF Self Test 938 FPT_SWM TSF Software Modification Component levelling 939 This family has been levelled based on the amount of human intervention required to return the system to a secure state, as well as the quality of that secure state. 940 The first component, FPT_RCV.1 Manual Recovery, allows a TOE to provide only mechanism that involve human intervention to return to a secure state. 941 The second component, FPT_RCV.2 Automated Recovery, provides, for at least one type of service discontinuity, recovery to a secure state without human intervention; recovery for other discontinuities may require human intervention. 942 The last component, FPT_RCV.3 Automated Recovery without Undo Loss, also provides for automated recovery, but strengthens the requirements by disallowing undue loss of protected objects. Application Notes Evaluator's application notes 943 Throughout this family, the phrase "Secure State" is used. This refers to the state as might be present immediately after a system "boot" (i.e., after generation, configuration, and initialisation), as opposed to the most recent secure state at the time of discontinuity. The phrase is used in contrast to the phrase "Secure Initial State", which is felt to apply to the state of the system only after the initial system generation and configuration. D R A F T FPT_RCV - Trusted Recovery Protection of the Trusted Security Functions Page 206 of 246 CCEB-94/083 Version 0.90 94/10/31 Documentation 944 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Identification of what constitutes a secure state [ADV_FSP Functional specification] FPT_RCV.1 Manual Recovery Hierarchical to: no other components. Component rationale and application notes User Application Notes 945 This component is intended for use in TOEs that do not require unattended recovery to a secure state. The requirements of this component reduce the threat of protection compromise resulting from an attended TOE returning to an insecure state after recovery from a failure or other discontinuity. Documentation 946 In addition to the documentation requirements applicable to all components in this family, the following assurance documentation, if applicable, shall contain the indicated information: a) Identification of the failures and service discontinuities for which (1) recovery is possible, and (2) recovery is not possible and reinstallation of the TSF is required [ADV_HLD High-level design] b) Manual procedures to be followed to recover the secure initial state. [AGD_ADM Administrator guidance] Rationale 947 In the hierarchy of trusted recovery, recovery that requires only manual intervention is the least desirable, for it precludes the use of the system in an unattended fashion. Operations No permitted operation. Dependencies: FPT_TSA TOE Security Administration AGD_ADM.1 Administration guidance ADV_FSP.2 Informal security policy model ADV_HLD.1 Informal high-level design D R A F T Protection of the Trusted Security Functions FPT_RCV - Trusted Recovery 94/10/31 CCEB-94/083 Version 0.90 Page 207 of 246 Elements: FPT_RCV.1.1 After a failure or service discontinuity that results in loss of a secure state, the TSF shall either recover or enter a maintenance mode where the capability to return the TOE to a secure state is provided. FPT_RCV.1.2 Administrative functions for returning the TSF to a secure state shall be defined. FPT_RCV.1.3 The TSF shall provide administrative functions that determine the integrity of TSF data structures on non-volatile media. FPT_RCV.1.4 In the case of failure of TSF data structures on non-volatile media, these functions shall, if recovery is possible, allow recovery of the TSF data structures without violating the TSP. FPT_RCV.2 Automated Recovery Hierarchical to: FPT_RCV.1 Component rationale and application notes User Application Notes 948 The component FPT_RCV.2 extends the feature coverage of FPT_RCV.1 by requiring that there be at least one automated method of recovery from failure or service discontinuity. It addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity. Documentation 949 In addition to the documentation requirements applicable to all components in this family, the following assurance documentation, if applicable, shall contain the indicated information: a) Identification of the failures and service discontinuities for which (1) recovery is possible, and (2) recovery is not possible and reinstallation of the TSF is required [ADV_HLD High-level design] b) Manual procedures to be followed to recover the secure initial state. [AGD_ADM Administrator guidance] Evaluator's application notes 950 For FPT_RCV.2.1, it is the responsibility of the developer of the TSF to determine the set of recoverable failures and service discontinuities. 951 It is assumed that the evaluators will verify the robustness of the automated recovery mechanisms. D R A F T FPT_RCV - Trusted Recovery Protection of the Trusted Security Functions Page 208 of 246 CCEB-94/083 Version 0.90 94/10/31 Rationale 952 Automated recovery is considered to be more useful than manual recovery, as it allows the machine to operate in an unattended fashion. Operations Assignment: 953 For FPT_RCV.2.1, the PP/ST author must specify the defined set of specific cases for which automated recovery must be possible. Dependencies: FPT_TSA TOE Security Administration AGD_ADM.1 Administration guidance ADV_FSP.2 Informal security policy model ADV_HLD.1 Informal high-level design Elements: FPT_RCV.2.1 For a [ defined set ] of the recoverable failures and service discontinuities that result in loss of a secure state, the TSF shall be able to return to a secure state using automated procedures. FPT_RCV.2.2 When automated recovery after a failure or service discontinuity that results in loss of a secure state is not possible, the TSF shall enter a maintenance mode where the capability to return the TOE to a secure state is provided. FPT_RCV.2.3 Administrative functions for returning the TSF to a secure state shall be defined. FPT_RCV.2.4 The TSF shall provide administrative functions that determine the integrity of TSF data structures on non-volatile media. FPT_RCV.2.5 In the case of failure or TSF data structures on non-volatile media, these functions shall, if recovery is possible, allow recovery of the TSF data structures without violating the TSP. FPT_RCV.3 Automated Recovery without Undo Loss Hierarchical to: FPT_RCV.2 Component rationale and application notes User Application Notes 954 The component FPT_RCV.3 extends the feature coverage of FPT_RCV.2 by requiring that there not be undue loss of user or system objects. At FPT_RCV.2, the automated recovery mechanisms could conceivably recover by deleting all objects D R A F T Protection of the Trusted Security Functions FPT_RCV - Trusted Recovery 94/10/31 CCEB-94/083 Version 0.90 Page 209 of 246 and returning the TSF to a known, pristine state. This type of drastic automated recovery is precluded in FPT_RCV.3. 955 This component addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity with a large loss of user or system objects. Documentation 956 In addition to the documentation requirements applicable to all components in this family, the following assurance documentation, if applicable, shall contain the indicated information: a) Identification of the failures and service discontinuities for which (1) recovery is possible, and (2) recovery is not possible and reinstallation of the TSF is required [ADV_HLD High-level design] b) The approach taken to determine the objects that were or were not capable of being recovered. [ADV_HLD High-level design] c) Manual procedures to be followed to recover the secure initial state. [AGD_ADM Administrator guidance] Evaluator's application notes 957 It is assumed that the evaluators will verify the robustness of the automated recovery mechanisms. Rationale 958 Automated recovery is considered to be more useful than manual recovery, but it runs the risk of losing a substantial number of objects. Preventing undue loss of objects provides additional utility to the recovery effort. Operations Assignment: 959 For FPT_RCV.3.1, the PP/ST author must specify the defined set of specific cases for which automated recovery must be possible. Assignment: 960 For FPT_RCV.3.4, it is the responsibility of the PP/ST author to provide the quantification. Dependencies: FPT_TSA TOE Security Administration AGD_ADM.1 Administration guidance D R A F T FPT_RVM - Reference Mediation Protection of the Trusted Security Functions Page 210 of 246 CCEB-94/083 Version 0.90 94/10/31 ADV_FSP.2 Informal security policy model ADV_HLD.1 Informal high-level design Elements: FPT_RCV.3.1 For a [ defined set ] of the recoverable failures and service discontinuities, the TSF shall be able to return to a secure initial state using automated procedures. FPT_RCV.3.2 When automated recovery after a failure or service discontinuity that results in loss of a secure initial state is not possible, the TSF shall enter a maintenance mode where the capability to return the TOE to a secure initial state is provided. FPT_RCV.3.3 Administrative functions for returning the TSF to a secure initial state shall be defined. FPT_RCV.3.4 The automated or manual functions shall ensure that the secure initial state is restored without exceeding the following quantification for loss of system or user objects: [Quantification to be supplied by the PP/ST author] FPT_RCV.3.5 An authorised user shall have the capability of determining the objects that were or were not capable of being recovered. FPT_RCV.3.6 The TSF shall provide administrative functions that determine the integrity of TSF data structures on non-volatile media. FPT_RCV.3.7 In the case of failure or TSF data structures on non-volatile media, these functions shall, if recovery is possible, allow recovery of the TSF data structures without violating the TSP. FPT_RVM Reference Mediation Family behaviour 961 The requirements of this family ensure that all references issued by subjects external to the TSF (i.e., untrusted subjects) to the objects of the TOE are validated by the TSF in accordance with the TSP. Satisfying the requirements of this family establishes complete reference mediation (i.e., a reference by a subject external to the TSF cannot circumvent the TSP). 962 Functions that implement a security policy provide effective protection against unauthorised operation if and only if all references issued by subjects are validated by the appropriate security policy enforcement functions before being allowed to succeed. Should such references be incorrectly mediated, or not mediated at all, policy enforcement may be incorrect, incomplete, or absent, despite correct and complete policy implementation. This may allow untrusted subjects to bypass the security policy in a variety of unauthorised ways (e.g., bypass certain access checks D R A F T Protection of the Trusted Security Functions FPT_RVM - Reference Mediation 94/10/31 CCEB-94/083 Version 0.90 Page 211 of 246 for a subset of the objects and subjects, bypass all checks for a type of object whose protection was assumed by applications, retain access rights beyond their intended expiration time, or bypass audit). Threats 963 This family counters threats from illicit or errant software, or from unauthorised users attempting to bypass security policy enforcement. Other relevant families 964 FPT_SEP Domain Separation 965 ADV_HLD High-level design Component levelling 966 This family is levelled based upon the completeness and scope of reference mediation. All components require that the security attributes of controlled objects, resources, and services also be protected. 967 The first component, FPT_RVM.1 Mediation of a Defined Set of Objects, allows the TSF to mediate references to a defined subset of the objects covered by the TSP. 968 The second component, FPT_RVM.2 Mediation of All Objects, extends mediation to include all objects, resources, and services. 969 The third component, FPT_RVM.3 Mediation of All Objects and Attributes, extends reference mediation to include all object attributes, not just security attributes. 970 The last component, FPT_RVM.4 Separate Reference Validation Mechanism, separates and protects the reference mediation functions from the remainder of the TSF. FPT_RVM.1 Mediation of a Defined Set of Objects Hierarchical to: no other components. Component rationale and application notes User Application Notes 971 This component should be used only for very low risk environments, where the principal objective is protect against accidental user error, errant programs, or user browsing. It protects against accidental violations of the TSP, and against naive penetration attempts. D R A F T FPT_RVM - Reference Mediation Protection of the Trusted Security Functions Page 212 of 246 CCEB-94/083 Version 0.90 94/10/31 Documentation 972 The indicated assurance documentation (if applicable) shall contain the indicated information: a) The set of objects covered by the TSP [Functional Specification (Security Policy); User Guidance] Evaluator's application notes 973 For FPT_RVM.1.1, the TOE developer may choose the subset of objects covered by the TSP that are protected by a given TOE. 974 For FPT_RVM.1.2, mediation need include only security-related attributes (i.e., those attributes whose manipulation and/or viewing can effect security policy enforcement). Examples may include access control lists, ownership attributes, etc. Rationale 975 For pragmatic reasons, in low-threat environments where benign accidents or unsophisticated users are the principal concern, it may be acceptable to only protect a subset of objects covered by the TSP. However, such subsetting greatly minimises protection from even low probability threats. Operations No permitted operation. Dependencies: FPT_SEP.1 TSF Domain Separation ADV_FSP.2 Informal security policy model Elements: FPT_RVM.1.1 A defined set of objects (and their associated security attributes) within the scope of the TSP shall be protected by the TSF. FPT_RVM.1.2 The TSF shall mediate all references by subjects external to the TSF to the objects (and their associated security attributes) protected by the TSF. FPT_RVM.1.3 Reference mediation shall ensure that all TSP enforcement functions are invoked before a reference to an object (or an associated security attribute) protected by the TSF is allowed to succeed. D R A F T Protection of the Trusted Security Functions FPT_RVM - Reference Mediation 94/10/31 CCEB-94/083 Version 0.90 Page 213 of 246 FPT_RVM.2 Mediation of All Objects Hierarchical to: FPT_RVM.1 Component rationale and application notes User Application Notes 976 Component FPT_RVM.2 provides protection against malicious users, and from errant or relatively unsophisticated illicit programs. This component does not protect against information flow attacks. However, it does protect against accidental violations of the TSP, and against modest penetration attempts. Evaluator's application notes 977 For FPT_RVM.2.2, mediation need only include security-related attributes (i.e., those attributes whose manipulation and/or viewing can effect security policy enforcement). Examples may include access control lists, ownership attributes, etc. Operations No permitted operation. Dependencies: FPT_SEP.1 TSF Domain Separation ADV_FSP.2 Informal security policy model Elements: FPT_RVM.2.1 All objects (and their associated security attributes) within the scope of the TSP shall be protected by the TSF. FPT_RVM.2.2 The TSF shall mediate all references by subjects external to the TSF to all objects (and their associated security attributes) protected by the TSF. FPT_RVM.2.3 Reference mediation shall ensure that all TSP enforcement functions are invoked before a reference to an object (or an associated security attribute) protected by the TSF is allowed to succeed. D R A F T FPT_RVM - Reference Mediation Protection of the Trusted Security Functions Page 214 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_RVM.3 Mediation of All Objects and Attributes Hierarchical to: FPT_RVM.2 Component rationale and application notes User Application Notes 978 Component FPT_RVM.3 protects objects from all threats external to the TSF. This is also the minimum required component for protection against information flow attacks. It protects against intentional attempts to violate security policy mediation, including attempts to illicitly communicate via object attributes (e.g., covert channels). Evaluator's application notes 979 For FPT_RVM.3.2, mediation must include all attributes associated with protected objects, not just security attributes. Rationale 980 Some threats (e.g., covert channels) can violate the TSP by the ability to view and influence values of what otherwise would be considered security irrelevant attributes (e.g., date modified, size, name). This component includes these attributes within the reference mediation of the TSF to protect against these additional threats. Operations No permitted operation. Dependencies: FPT_SEP.1 TSF Domain Separation ADV_FSP.2 Informal security policy model Elements: FPT_RVM.3.1 All objects ( and all associated attributes ) within the scope of the TSP shall be protected by the TSF. FPT_RVM.3.2 The TSF shall mediate all references by subjects external to the TSF to all objects ( including all associated attributes) protected by the TSF. FPT_RVM.3.3 Reference mediation shall ensure that all TSP enforcement functions are invoked before a reference to an object (or any associated attribute ) protected by the TSF is allowed to succeed. D R A F T Protection of the Trusted Security Functions FPT_RVM - Reference Mediation 94/10/31 CCEB-94/083 Version 0.90 Page 215 of 246 FPT_RVM.4 Separate Reference Validation Mechanism Hierarchical to: FPT_RVM.3 Component rationale and application notes User Application Notes 981 Component FPT_RVM.4 protects objects from all threats external to the reference validation mechanism (RVM). This component should be chosen over FPT_RVM.3 for large and complex TOEs (e.g., operating systems), where the TSF can be expected to be relatively large, yet there is still a need for high- assurance reference mediation. 982 This component protects against intentional attempts to violate security policy mediation, including attempts to illicitly communicate via object attributes (e.g., covert channels). It also protects against errors in the non-mediation portions of the TSF. Evaluator's application notes 983 For FPT_RVM.4.2, mediation must include all attributes associated with protected objects. 984 For FPT_RVM.4.3, the non-RVM portion of the TSF must also be subject to RVM mediation (though the RVM policies may allow for privileges or other special authorisations). Rationale 985 In complex TOEs, the features and mechanisms needed within the TSF can be quite large, and possible complex, especially those features needed to support secure administration and operation. Nonetheless, the central reference mediation features need not be complex, and can be segregated from the remainder of the TSF in order to allow greater understanding and simplicity of the TSP enforcement mechanisms. Operations No permitted operation. Dependencies: FPT_SEP.2 Separate Reference Validation Mechanism (RVM) Domain ADV_FSP.2 Informal security policy model Elements: FPT_RVM.4.1 The TSF shall include a reference validation mechanism (RVM) that protects all objects (and all associated attribute) within the scope of the TSP. D R A F T FPT_ITC - Inter-TSF Confidentiality of TSF Data Protection of the Trusted Security Page 216 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_RVM.4.2 The RVM shall mediate all references by subjects external to the RVM to all objects (including all associated attributes) protected by the RVM . FPT_RVM.4.3 The RVM shall be logically distinct from the remainder of the TSF, and shall include only those functions needed to isolate and protect objects. FPT_RVM.4.4 The RVM shall ensure that all TSP enforcement functions are invoked before a reference to an object (or any associated attribute) protected by the TSF is allowed to succeed. FPT_ITC Inter-TSF Confidentiality of TSF Data Family behaviour 986 This family defines the rules for the protection from unauthorised disclosure of TSF data moving between the TSF and another TSF. This data could be TSF critical data such as passwords or keys. Threats 987 This family addresses the threat of unauthorised access to the TSF or to TSF protected resources due to disclosure of TSF critical data. Other relevant families 988 FPT_SEP Domain Separation 989 FPT_ITI Inter-TSF Integrity of TSF Data 990 FPT_ITA Inter-TSF Availability of TSF Data FPT_ITI Inter-TSF Integrity of TSF Data Family behaviour 991 This family defines the rules for the protection from unauthorised and undetectable modification of TSF data moving between the TSF and another TSF. This data could, for example, be TSF critical data such as passwords or keys or TSF executable code. Threats 992 This family addresses the threat of unauthorised access to the TSF or to TSF protected resources due to undetected and unauthorised modification of TSF data. D R A F T Protection of the Trusted Security Functions FPT_ITA - Inter-TSF Availability of 94/10/31 CCEB-94/083 Version 0.90 Page 217 of 246 Other relevant families 993 FPT_SEP Domain Separation 994 FPT_ITA Inter-TSF Availability of TSF Data 995 FPT_ITC Inter-TSF Confidentiality of TSF Data FPT_ITA Inter-TSF Availability of TSF Data 996 This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and another TSF. This data could be TSF critical data such as passwords or keys or TSF executable code. Threats 997 This family addresses the threat that outside intervention can interfere with TSF data moving between TSFs resulting in it not being available as required. Other relevant families 998 FPT_SEP Domain Separation 999 FPT_ITI Inter-TSF Integrity of TSF Data 1000 FPT_ITC Inter-TSF Confidentiality of TSF Data FPT_SWM TSF Software Modification Family behaviour 1001 The requirements of this family are needed to detect the corruption of TSF code and data structures by various failures that do not necessarily stop the TOE's operation (which would be handled by other families). These checks must be performed because these failures may not necessarily be prevented. Such failures can occur either because of unforeseen failure modes and associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate physical protection. Threats 1002 This family addresses the threats of attacks based upon modifying the TSF in non-fatal way. 1003 This family addresses the threats of some attacks based upon TSF design errors that result in the TSF modifying itself inadvertently. D R A F T FPT_TST - TSF Self Test Protection of the Trusted Security Functions Page 218 of 246 CCEB-94/083 Version 0.90 94/10/31 Other relevant families 1004 FPT_FLS Fail-safe 1005 FRU_FLT Fault Tolerance 1006 FPT_RCV Trusted Recovery 1007 FPT_PHP TSF Physical Protection FPT_TST TSF Self Test Family behaviour 1008 The family defines the requirements for the definition of self-testing of the TSF with respect to some expected correct operation. Examples are calls to enforcement functions, sample math operations on a critical component, etc. These tests can be carried out either in some maintenance state, at start-up, on-line, or continuously. The actions to be taken by the TOE as the result of self testing are defined in other families. Threats 1009 This family addresses the threat that an internal failure of the TSF will go undetected resulting in some form of TSP violation. 1010 This family addresses the threat that an internal inconsistency of the TOE will go undetected resulting in some form of TSP violation. Other relevant families 1011 FPT_AMT Underlying Abstract Machine Test 1012 FPT_RCV Trusted Recovery 1013 FPT_FLS Fail-safe 1014 FRU_FLT Fault Tolerance 1015 FPT_SEP Domain Separation 1016 FPT_SWM TSF Software Modification 1017 FPT_PHP TSF Physical Protection D R A F T Protection of the Trusted Security Functions FPT_AMT - Underlying Abstract 94/10/31 CCEB-94/083 Version 0.90 Page 219 of 246 FPT_AMT Underlying Abstract Machine Test Family behaviour 1018 This family defines the requirements for the TSF's testing of security assumptions made about the underlying abstract machine upon which the TSF relies. Examples could be testing hardware page protection, sample packets across a network to ensure receipt, etc. These tests can be carried out either in some maintenance state, at start-up, on-line, or continuously. The actions to be taken by the TOE as the result of self testing are defined in other families. Threats 1019 This family addresses the threat that an internal failure of the underlying abstract machine will go undetected by the TSF resulting in some form of TSP violation. Other relevant families 1020 FPT_RCV Trusted Recovery 1021 FPT_FLS Fail-safe 1022 FRU_FLT Fault Tolerance 1023 FPT_SEP Domain Separation 1024 FPT_SWM TSF Software Modification 1025 FPT_PHP TSF Physical Protection Component levelling 1026 This family is levelled based on the frequency and availability of the tests of the underlying abstract machine: 1027 The first component, FPT_AMT.1 Periodic Abstract Machine Testing, provides the ability to periodically test the underlying abstract machine. These tests may be performed during normal operation, in a maintenance mode, or offline. 1028 The second component, FPT_AMT.2 Abstract Machine Testing During Start- Up, provides for both human-invoked periodic tests and TSF-invoked testing during start-up. 1029 The last component, FPT_AMT.3 Abstract Machine Testing During Normal Operation, provides for periodic testing of the underlying abstract machine by the TSF during normal operation, as well as human-invoked periodic tests and TSF-invoked testing during start-up. D R A F T FPT_AMT - Underlying Abstract Machine Test Protection of the Trusted Security Page 220 of 246 CCEB-94/083 Version 0.90 94/10/31 Application Notes User Application Notes 1030 The term "underlying abstract machine" typically refers to the hardware components upon which the TSF software functions have been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine. Evaluator's application notes 1031 The tests of the underlying abstract machine should be sufficient to test all of the protection-relevant characters of the underlying abstract machine upon which the TSF relies. Audit 1032 None in addition to that required for security administrative functions, if the periodic tests are invoked by the administrator during normal operation. Documentation 1033 The indicated assurance documentation (if applicable) shall contain the indicated information: a) A description of the product features that can be used to periodically validate the correct operation of the underlying abstract machine. b) A description of the coverage and use of the underlying abstract machine tests. [Administrative Guidance] FPT_AMT.1 Periodic Abstract Machine Testing Hierarchical to: no other components. Component rationale and application notes User Application Notes 1034 This component provides support for the periodic testing of the critical protection relevant functions of the underlying abstract machine by requiring the ability to periodically invoke testing functions. Evaluator's application notes 1035 It is acceptable for the functions that are available for periodic testing to be available only in an offline or maintenance mode. D R A F T Protection of the Trusted Security Functions FPT_AMT - Underlying Abstract 94/10/31 CCEB-94/083 Version 0.90 Page 221 of 246 Operations No permitted operation. Dependencies: No dependencies. Elements: FPT_AMT.1.1 The TSF shall provide functions that can be used to periodically validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. FPT_AMT.2 Abstract Machine Testing During Start-Up Hierarchical to: FPT_AMT.1 Component rationale and application notes User Application Notes 1036 This component provides adds to the support for the periodic testing of the critical protection-relevant functions of the underlying abstract machine by calling for not only the ability to periodically invoke the tests, but to have tests executed as part of the TSF start-up mechanism. Evaluator's application notes 1037 It is acceptable for the functions that are available for periodic testing to be available only in an offline or maintenance mode. Operations No permitted operation. Dependencies: No dependencies. Elements: FPT_AMT.2.1 The TSF shall provide functions that can be used to periodically validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. FPT_AMT.2.2 The TSF shall run a suite of self tests during initial start-up in order to validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. D R A F T FPT_FLS - Fail-safe Protection of the Trusted Security Functions Page 222 of 246 CCEB-94/083 Version 0.90 94/10/31 FPT_AMT.3 Abstract Machine Testing During Normal Operation Hierarchical to: FPT_AMT.2 Component rationale and application notes User Application Notes 1038 This component adds to the support for the periodic testing of the critical protection-relevant functions of the underlying abstract machine by calling for not only the ability to periodically invoke the tests and have the tests executed as part of the TSF start-up mechanism, but to have the TSF periodically perform the tests during normal operation. Evaluator's application notes 1039 It is acceptable for the functions that are available to the administrator for periodic testing to be available only in an offline or maintenance mode. Operations No permitted operation. Dependencies: No dependencies. Elements: FPT_AMT.3.1 The TSF shall provide functions that can be used to periodically validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. FPT_AMT.3.2 The TSF shall run a suite of self tests during initial start-up and periodically during normal operation in order to validate the correct operation of the protection-relevant functions provided by the TSF's underlying abstract machine. FPT_FLS Fail-safe Family behaviour 1040 The requirements of this family ensure that the TOE will not violate its TSP in the event of any hardware failures. Threats 1041 This family addresses the threats of attacks based upon any human induced hardware failure. D R A F T Protection of the Trusted Security Functions FPT_PHP - TSF Physical Protection 94/10/31 CCEB-94/083 Version 0.90 Page 223 of 246 Other relevant families 1042 FRU_RSA Resource Allocation 1043 FRU_PRS Priority of Service 1044 FPT_RCV Trusted Recovery 1045 FPT_SWM TSF Software Modification 1046 FRU_FLT Fault Tolerance FPT_PHP TSF Physical Protection Family behaviour 1047 TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to the deterrence of , and resistance to, unauthorised physical use, modification, or substitution of the TSF. 1048 The requirements of components in this family ensure that the TSF is either protected from physical tampering and interference, or operates in a protected environment. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is measurable based on defined work factors. Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This component also provides requirements regarding how the TSF must respond to physical tampering attempts. Threats 1049 This family addresses the threats of undetected use, modification, substitution, or analysis of the physical representation of the TSF. 1050 This family addresses only physical tampering resulting from human actions. Other relevant families 1051 FPT_RCV Trusted Recovery 1052 FRU_FLT Fault Tolerance 1053 ADO_DEL Delivery 1054 FPT_SEP Domain Separation D R A F T FPT_PHP - TSF Physical Protection Protection of the Trusted Security Functions Page 224 of 246 CCEB-94/083 Version 0.90 94/10/31 Component levelling 1055 This family is levelled based upon the scope of the protection features provided, the ease of detection of tampering, and the degree to which physical threats are resisted. 1056 The first component, FPT_PHP.1 Passive Detection of Physical Attack, provides for features that indicate when a TSF physical device or element is subject to tampering. However, notification of a tampering attack is not automatic; an administrator must invoke a security administrative function to determining if tampering has occurred. 1057 The second component, FPT_PHP.2 Notification of Physical Attack, provides for automatic notification of tampering attacks for an identified subset of physical penetrations. 1058 The third component, FPT_PHP.3 Resistance to Physical Attack, provides for features that prevent or resist physical tampering with TSF devices and elements. Application Notes Evaluator's application notes 1059 Evaluators should review the administrator guidance and design documentation to ensure that all physically distinct devices and elements within the TSF's perimeter are described. Audit 1060 Although there is not an explicit requirement to audit when a physical attack is detected, or an administrator is notified of an attack, this is solely because there is the potential that the detection and alarm mechanisms may be implemented completely in hardware, below the level of interaction with an audit subsystem (for example, a hardware-based detection system based on breaking a circuit and lighting an LED if the circuit is broken when a button is pressed by the administrator). Nevertheless, a PP/ST author may determine that for a particular anticipated threat environment there is a need to audit physical attacks. If this is the case, the PP/ST author should include in the list of audit events appropriate requirements. Note that inclusion of these requirements may have implications on the hardware design and its interface to the software. Documentation 1061 The indicated assurance documentation (if applicable) shall contain the indicated information: a) Identification of the TSF's physical perimeter. [AGD_ADM Administrator guidance] D R A F T Protection of the Trusted Security Functions FPT_PHP - TSF Physical Protection 94/10/31 CCEB-94/083 Version 0.90 Page 225 of 246 b) The physically distinct devices and elements within the TSF's physical perimeter. [AGD_ADM Administrator guidance] FPT_PHP.1 Passive Detection of Physical Attack Hierarchical to: no other components. Component rationale and application notes User Application Notes 1062 Component FPT_PHP.1 should be used when threats from unauthorised physical tampering with TOE components are not countered by procedural methods. It addresses the threat of undetected actual physical tampering with the TSF. Operations No permitted operation. Dependencies: AGD_ADM.1 Administration guidance FPT_TSA TOE Security Administration Elements: FPT_PHP.1.1 The TOE shall include features that provide unambiguous detection of physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements. FPT_PHP.1.2 The TSF shall provide security administrative functions that indicate whether physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements has been detected. FPT_PHP.2 Notification of Physical Attack Hierarchical to: FPT_PHP.1 Component rationale and application notes User Application Notes 1063 Component FPT_PHP.2 should be used when threats from unauthorised physical tampering with TOE components are not countered by procedural methods, and it is required that designated individuals be notified of physical attacks. It addresses the threat that physical tampering with TSF elements, although detected, may go unnoticed. D R A F T FPT_PHP - TSF Physical Protection Protection of the Trusted Security Functions Page 226 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations Assignment: 1064 For FPT_PHP.2.3, the PP/ST author must identify the following: 1) The type of administrative user that is to be notified when tampering is detected. They may vary depending on the particular security administration component included in the PP/ST. 2) The list of physical devices/elements for which active detection of physical tampering is required. Dependencies: AGD_ADM.1 Administration guidance FPT_TSA TOE Security Administration Elements: FPT_PHP.2.1 The TOE shall include features that provide unambiguous detection of physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements. FPT_PHP.2.2 The TSF shall provide security administrative functions that indicate whether physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements has been detected. FPT_PHP.2.3 For the following subset of the TOE's physical devices and elements, the TSF shall monitor the physical devices and elements and notify [a designated user] when physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements has been detected: [List of devices/elements for which active detection is required]. FPT_PHP.3 Resistance to Physical Attack Hierarchical to: FPT_PHP.2 Component rationale and application notes User Application Notes 1065 This component should be used when TSF devices and elements are expected to operate in an environment where observation, analysis, or modification of the internals of a TSF device or element itself is a threat. This component partially addresses the threat of the TSF violating the TSP as the result of an actual physical attack, by providing increased resistance to attack. D R A F T Protection of the Trusted Security Functions FPT_PHP - TSF Physical Protection 94/10/31 CCEB-94/083 Version 0.90 Page 227 of 246 Evaluator Notes 1066 The determination of acceptable work load factors is by its very nature somewhat qualitative, and cannot always be evaluated in a reasonable time or in a repeatable fashion. Evaluator judgement will be required to determine if a particular attack scenario resistance mechanism would require the indicated level of effort. Rationale 1067 For some forms of attack, it is necessary that the TOE not only detect the attack, but actually resist the attack or delay the attacker. Operations Assignment: 1068 For FPT_PHP.3.3, the PP/ST author must identify the following: 1) The type of administrative user that is to be notified when tampering is detected. They may vary depending on the particular security administration component included in the PP/ST. 2) The list of physical devices/elements for which active detection of physical tampering is required. Assignment: 1069 For FPT_PHP.3.4, the PP/ST author must specify both the devices/elements for which the TSF must resist physical tampering attacks, and the specific attack scenario that must be countered. This list may be applied to a defined subset of the TSF physical devices and elements based on considerations such as technology limitations and relative physical exposure of the device. Such subsetting must be clearly defined and justified. Refinement: 1070 The specific TSP(s) of relevance may be listed in FPT_PHP.3.4. Refinement: 1071 FPT_PHP.3.4 may include specific acceptance criteria for the work factor parameters. Dependencies: AGD_ADM.1 Administration guidance FPT_TSA.1 Basic Security Administration ADV_FSP.2 Informal security policy model D R A F T FPT_PHP - TSF Physical Protection Protection of the Trusted Security Functions Page 228 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FPT_PHP.3.1 The physical perimeter of the TSF shall be defined, and each physically distinct device and element within the TSF's physical perimeter shall be identified. FPT_PHP.3.2 The TOE shall include features that provide unambiguous detection of physical tampering (i.e., unauthorised physical access or modification) to the TOE's physical devices and elements. FPT_PHP.3.3 For the following subset of the TOE's physical devices and elements, the TSF shall monitor the physical devices and elements and notify [a designated user] when physical tampering (i.e., unauthorised physical access or modification) to the TSF's physical devices and elements has been detected: [List of devices/elements for which active detection is required]. FPT_PHP.3.4 For the following subset of the TOE's physical devices and elements, the TOE shall include features that resist identified physical tampering attacks to the TOE's physical devices and elements: [List of for which resistance to attack is required]. D R A F T 234 CCEB-94/083 94/10/31 Version 0.90 Page 229 of 234 Class FPR Privacy Editor Note: This class has outlines for families which were proposed for inclusion in the CC. It has been found that these families are in fact closer to statements of top level security objectives (TLSO) which would translate to many divergent requirements to be levied against the TOE. It is therefore planned that these families will eventually be integrated into the other classes, families and components within the CC. No actual components are provided for the family outlines provided in this class. Privacy | | - FPR_UNO - | | - FPR_AMO - | | - FPR_PSE - | | - FPR_UNL - Figure 2.10 - Privacy class decomposition FPR_UNO Unobservability Family behaviour: 1072 Unobservability ensure an entity may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. Threats 1073 This family reduces threats of malicious observations of use of a resource or service. D R A F T FPR_UNO - Unobservability Privacy Page 230 of 246 CCEB-94/083 Version 0.90 94/10/31 1074 This family reduces the threat of communication profiling (traffic analysis) by other entities than the communicating parties. Other relevant families 1075 FPR_ANO Anonymity 1076 FPR_PSE Pseudonymity Component levelling 1077 Sample levelling is based on specification of the other entities against whom the TSF is able to protect observability of the entity using a resource or service. 1078 The TSF shall ensure that a single non security administrator, working in isolation, is unable to observe the use of a resource or service by another entity. 1079 The TSF shall ensure that some, even all, non security administrators , working in collaboration , are unable to observe the use of a resource or service by another entity. 1080 The TSF shall ensure that some, even all, non security administrators and one or more, but not all, security administrators , working in collaboration, are unable to observe the use of a resource or service by another entity. 1081 The TSF shall ensure that all other entities, including security administrators , working in collaboration, are unable to observe the use of a resource or service by another entity. Application Notes 1082 Possible applications include privacy enhanced electronic mail and electronic voting. 1083 Examples for valuable assets are the information, who is communicating with whom, at which time and from which place. 1084 Examples for attackers are malicious system operators or entities, who smuggle malicious parts, e.g. Trojan Horses into systems, they do not operate but want to get information about. Several countries, consider the protection of communications unobservability as essential for the protection of constitutional rights. D R A F T Privacy FPR_ANO - Anonymity 94/10/31 CCEB-94/083 Version 0.90 Page 231 of 246 FPR_ANO Anonymity Family behaviour 1085 Anonymity ensures that an entity may use a resource or service without disclosing its identity. Threats 1086 This family reduces threats of usage profiling by other than the resource or service using parties. 1087 This family reduces threats of disclosure of identity or other information leading to the disclosure of identity, of an entity using a resource or service. Component levelling 1088 Sample levelling is based on specification of the other entities against whom the TSF is able to protect identity of the entity using a resource or service. 1089 The TSF shall ensure that a single non security administrator, working in isolation, is unable to determine the identity of another entity that is using a resource or service. 1090 The TSF shall ensure that some, even all, non security administrators , working in collaboration , are unable to determine the identity of another entity that is using a resource or service. 1091 The TSF shall ensure that some, even all, non security administrators and one or more, but not all, security administrators , working in collaboration, are unable to determine the identity of another entity that is using a resource or service. 1092 The TSF shall ensure that all other entities, including security administrators , working in collaboration, are unable to determine the identity of another entity that is using a resource or service. Application Notes 1093 Possible applications include the ability to make enquiries of a confidential nature to public databases 1094 Examples for valuable assets are information on the kind of the information the user asked for, the time and mode of usage and especially the identity of the user. 1095 Examples for attackers are providers, system operators, communication partners and entities, who smuggle malicious parts, e.g. Trojan Horses into systems, they do not operate but want to get information about. All of these attackers can investigate e.g. which users used which services and misuse this information. D R A F T FPR_PSE - Pseudonymity Privacy Page 232 of 246 CCEB-94/083 Version 0.90 94/10/31 FPR_PSE Pseudonymity Family behaviour 1096 Pseudonymity ensures that an entity may use a resource or service without disclosing its identity, but can still be accountable for that use. Threats 1097 This family reduces threats of usage profiling by other than the resource or service using parties. 1098 This family reduces threats of disclosure of identity or other information leading to the disclosure of identity, of an entity using a resource or service, especially when danger of such a disclosure arises with need of authorisation. Component levelling 1099 Sample levelling is based on specification of the other entities by whom is the entity using a resource or service held accountable, although not identifiable, under the TSF service. 1100 The TSF shall ensure that an entity using a resource or service, but not disclosing its identity, is able to be held accountable for that use by any security administrator. 1101 The TSF shall ensure that an entity using a resource or service, but not disclosing its identity, is able to be held accountable for that use by the service or resource provider . 1102 The TSF shall ensure that an entity using a resource or service, but not disclosing its identity, is able to be held accountable for that use by the service or resource provider, only if this is a security administrator . Application Notes 1103 Possible applications include the ability to charge a caller for premium rate telephone services without disclosing his or her identity, or to be charged for the anonymous use of an electronic payment system. 1104 Examples for valuable assets are informations on the kind of the information the user asked for, the time and of usage and especially the identity of the user and the payment information. 1105 Examples for attackers are providers, system operators, communication partners and entities, who smuggle malicious parts, e.g. Trojan Horses into systems, they do not operate but want to get information about. All of these attackers can investigate e.g. which users used which services and misuse this information. Additionally to Anonymity services Pseudonymity Services contain methods for authorisation D R A F T Privacy FPR_UNL - Unlinkability 94/10/31 CCEB-94/083 Version 0.90 Page 233 of 246 without identification, especially for anonymous payment ("Digital Cash"). This helps providers to get their payment in a secure way while maintaining customers anonymity. FPR_UNL Unlinkability Family behaviour 1106 Unlinkability ensures that an entity may make multiple uses of resources or services without others being able to link these uses together. Threats 1107 This family reduces threats of usage profiling by other than the resource or service using parties. 1108 This family reduces threats of malicious investigation of multiple uses of resources or services. Component levelling 1109 Sample levelling is based on specification of the other entities against whom the TSF is able to protect linkability of resources' or services' uses by the entity using these resources or services. 1110 The TSF shall ensure that a single non security administrator, working in isolation, is unable to link together multiple uses of resources or services by another entity. 1111 The TSF shall ensure that some, even all, non security administrators , working in collaboration , are unable to link together multiple uses of resources or services by another entity. 1112 The TSF shall ensure that some, even all, non security administrators and one or more, but not all, security administrators , working in collaboration, are unable to link together multiple uses of resources or services by another entity. 1113 The TSF shall ensure that all other entities, including security administrators , working in collaboration, are unable to link together multiple uses of resources or services by another entity. Application Notes 1114 Possible applications include the ability to make multiple use of a pseudonym without creating a usage pattern that might disclose the user's identity. 1115 Examples for valuable assets are informations on the kind of the information the user asked for, the time and of usage and especially the identity of the user. D R A F T FPR_UNL - Unlinkability Privacy Page 234 of 246 CCEB-94/083 Version 0.90 94/10/31 1116 Examples for attackers are providers, system operators, communication partners and entities, who smuggle malicious parts, e.g. Trojan Horses into systems, they do not operate but want to get information about. All of these attackers can investigate e.g. which users used which services and misuse this information. Unlinkability protects users from linkages, which could be drawn between several actions of a customer. An example is a series of phone calls made by an anonymous customer to different partners, where the combination of the partner's identities might disclose the identity of the customer. D R A F T 242 CCEB-94/083 94/10/31 Version 0.90 Page 235 of 242 Class FTE Communication Editor Note: This class defines families and components related to trusted communications. It is felt that they will be moved to more appropriate places in the CC at a future date. Editor Note: The family FCO_DEI which was previously in this class is now in the FDP_ITP family in the User Data Protection class. Communication | | - FCO_NRO - 1 - 2 - 3 | | - FCO_NRR - 1 - 2 - 3 Figure 2.11 - Communication class decomposition FTE_NRO Non-Repudiation of Origin Family behaviour 1117 Non-repudiation of origin ensures that the sender of data during data exchange cannot successfully falsely deny sending the data or its contents, by providing proof of origin. The TOE should provide TSF ensuring that an entity that receives data during data exchange is provided with proof of the origin of the data. Threats 1118 This family reduces the threats of successful denial of having sent data during data exchange. Other relevant families 1119 FTE_NRR Non-Repudiation of Receipt D R A F T FTE_NRO - Non-Repudiation of Origin Communication Page 236 of 246 CCEB-94/083 Version 0.90 94/10/31 1120 FDP_ITP Information Transfer Protection 1121 FDP_SAT Security Attribute Transfer Component levelling 1122 This family contains three components: 1123 FTE_NRO.1 Selective Proof of Origin requires only that a callable TSF function exist for creating and verifying proof of origin. 1124 FTE_NRO.2 Enforced Proof of Origin requires that the TSF always mark certain user data for proof of origin. 1125 FTE_NRO.3 Indefinite Proof of Origin requires that the proof origin be able to be verified at any time after the user data was marked regardless of other changes to the TSF configuration. FTE_NRO.1 Selective Proof of Origin Hierarchical to: No other components. Component rationale and application notes User Application Notes 1126 Operations Assignment: 1127 In FTE_NRO.1.1, identify the list of user data types which can be marked for proof of origin by the originator. 1128 In FTE_NRO.1.2, identify the list of user data types which can be checked for proof of origin by the recipient. Dependencies: No dependencies. Elements: FTE_NRO.1.1 The TSF shall provide to a user a callable capability to provide proof of origin for the following user data: [List of user data which can be provided with proof of origin] D R A F T Communication FTE_NRO - Non-Repudiation of Origin 94/10/31 CCEB-94/083 Version 0.90 Page 237 of 246 FTE_NRO.1.2 The TSF shall provide a capability for a user to verify proof of origin on the following data if it has been marked for proof of origin: [List of user data which can be verified for proof of origin] FTE_NRO.2 Enforced Proof of Origin Hierarchical to: FTE_NRO.1 Component rationale and application notes User Application Notes 1129 Operations Assignment: 1130 In FTE_NRO.2.1, identify the list of user data types which can be marked for proof of origin by the originator. 1131 In FTE_NRO.2.2, identify the list of user data types which are always marked for proof of origin of the originator. 1132 In FTE_NRO.2.3, identify the list of user data types which can be checked for proof of origin by the recipient. Dependencies: No dependencies. Elements: FTE_NRO.2.1 The TSF shall provide to a user a callable capability to provide proof of origin for the following user data: [List of user data which can be provided with proof of origin] FTE_NRO.2.2 The TSF shall always associate a proof of origin with the following user data: [List of user data always associated with a proof of origin] FTE_NRO.2.3 The TSF shall provide a capability for a user to verify proof of origin on the following user data if it has been marked for proof of origin: [List of user data which can be verified for proof of origin] D R A F T FTE_NRR - Non-Repudiation of Receipt Communication Page 238 of 246 CCEB-94/083 Version 0.90 94/10/31 FTE_NRO.3 Indefinite Proof of Origin Hierarchical to: FTE_NRO.2 Component rationale and application notes User Application Notes 1133 Operations Assignment: 1134 In FTE_NRO.3.1, identify the list of user data types which can be marked for proof of origin by the originator. 1135 In FTE_NRO.3.2, identify the list of user data types which are always marked for proof of origin of the originator. 1136 In FTE_NRO.3.3, identify the list of user data types which can be checked for proof of origin by the recipient. Dependencies: No dependencies. Elements: FTE_NRO.3.1 The TSF shall provide to a user a callable capability to provide proof of origin for the following user data: [List of user data which can be provided with proof of origin] FTE_NRO.3.2 The TSF shall always associate a proof of origin with the following user data: [List of user data always associated with a proof of origin] FTE_NRO.3.3 The TSF shall provide a capability for a user to verify proof of origin on the following user data at any time after it has been marked for proof of origin: [List of user data which can be verified for proof of origin] FTE_NRR Non-Repudiation of Receipt Family behaviour 1137 Non-repudiation of receipt ensures that the recipient of data during data exchange cannot successfully falsely deny receiving the data or its contents, by providing D R A F T Communication FTE_NRR - Non-Repudiation of Receipt 94/10/31 CCEB-94/083 Version 0.90 Page 239 of 246 proof of delivery. The TOE should provide TSF ensuring that an entity that sends data during data exchange is provided with proof of the delivery of the data. Threats 1138 This family reduces the threats of denial of receiving certain data during data exchange. Other relevant families 1139 FTE_NRO Non-Repudiation of Origin 1140 FDP_ITP Information Transfer Protection 1141 FDP_SAT Security Attribute Transfer Component levelling 1142 This family contains three components: 1143 FTE_NRR.1 Selective Proof of Receipt requires only that a callable TSF function exist for creating and verifying proof of receipt. 1144 FTE_NRR.2 Providing of Basic Proof of Receipt requires that the TSF always mark certain user data for proof of receipt. 1145 FTE_NRR.3 Indefinite Proof of Receipt requires that the proof receipt be able to be verified at any time after the user data was marked regardless of other changes to the TSF configuration. Application Notes Audit 1146 FTE_NRR.1 Selective Proof of Receipt Hierarchical to: No other components. Component rationale and application notes User Application Notes 1147 D R A F T FTE_NRR - Non-Repudiation of Receipt Communication Page 240 of 246 CCEB-94/083 Version 0.90 94/10/31 Operations Assignment: 1148 In FTE_NRR.1.1, identify the list of user data types which can be marked for proof of receipt by the recipient. 1149 In FTE_NRR.1.2, identify the list of user data types which can be checked for proof of origin by the originator. Dependencies: No dependencies. Elements: FTE_NRR.1.1 The TSF shall provide to a recipient user a callable capability to provide proof of receipt for the following user data: [List of user data which can be provided with proof of receipt] FTE_NRR.1.2 The TSF shall provide a capability for a user to verify proof of receipt on the following data if it has been marked for proof of receipt: [List of user data which can be verified for proof of receipt] FTE_NRR.2 Providing of Basic Proof of Receipt Hierarchical to: FTE_NRR.1 Component rationale and application notes User Application Notes 1150 Operations Assignment: 1151 In FTE_NRR.2.1, identify the list of user data types which can be marked for proof of receipt by the recipient. 1152 In FTE_NRR.2.2, identify the list of user data types which can be for which a proof of receipt can be required. 1153 In FTE_NRR.2.3, identify the list of user data types which can be checked for proof of origin by the originator. D R A F T Communication FTE_NRR - Non-Repudiation of Receipt 94/10/31 CCEB-94/083 Version 0.90 Page 241 of 246 Dependencies: No dependencies. Elements: FTE_NRR.2.1 The TSF shall provide to a recipient user a callable capability to provide proof of receipt for the following user data: [List of user data which can be provided with proof of receipt] FTE_NRR.2.2 The TSF shall provide to an originating user a callable capability to require a proof of receipt for the following user data: [List of user data for which a proof of receipt can be required] FTE_NRR.2.3 The TSF shall provide a capability for a user to verify proof of receipt on the following data if it has been marked for proof of receipt: [List of user data which can be verified for proof of receipt] FTE_NRR.3 Indefinite Proof of Receipt Hierarchical to: FTE_NRR.2 Component rationale and application notes User Application Notes 1154 Operations Operations Assignment: 1155 In FTE_NRR.2.1, identify the list of user data types which can be marked for proof of receipt by the recipient. 1156 In FTE_NRR.2.2, identify the list of user data types which can be for which a proof of receipt can be required. 1157 In FTE_NRR.2.3, identify the list of user data types which can be checked for proof of origin by the originator. Dependencies: No dependencies. D R A F T FTE_NRR - Non-Repudiation of Receipt Communication Page 242 of 246 CCEB-94/083 Version 0.90 94/10/31 Elements: FTE_NRR.3.1 The TSF shall provide to a recipient user a callable capability to provide proof of receipt for the following user data: [List of user data which can be provided with proof of receipt] FTE_NRR.3.2 The TSF shall provide to an originating user a callable capability to require a proof of receipt for the following user data: [List of user data for which a proof of receipt can be required] FTE_NRR.3.3 The TSF shall provide a capability for a user to verify proof of receipt on the following data at any time after it has been marked for proof of receipt: [List of user data which can be verified for proof of receipt] D R A F T 244 CCEB-94/083 94/10/31 Version 0.90 Page 243 of 246 Chapter 3 Predefined functional packages Editor Note: In the next issue of the CC this annex will contain agreed functional packages based upon functional requirements from the source criteria documents (ITSEC, CTCPEC, FC / TCSEC). D R A F T 3 - Predefined functional packages CCEB-94/083 Page 244 of 246 Version 0.90 94/10/31 D R A F T CCEB-94/083 A - Relationship of CC predefined functional packages to ITSEC, 94/10/31 Version 0.90 Page 245 of 246 Annex A Relationship of CC predefined functional packages to ITSEC, CTCPEC, FC / TCSEC (informative) Editor Note: In the next issue of the CC this annex will provide a mapping of the predefined CC functional packages with the functional requirements from the source criteria documents (ITSEC, CTCPEC, FC / TCSEC). D R A F T A - Relationship of CC predefined functional packages to ITSEC, CTCPEC, FC / Page 246 of 246 Version 0.90 94/10/31