Security Objectives

Identifier	AC_Admin_Limit
Descriptive Name	Limitation of administrative access control
Description	Design administrative functions in such a way that administrators do not automatically have access to user objects, except for necessary exceptions. For an accounts administrator, the necessary exceptions include allocation and de-allocation of storage. For an audit administrator, the necessary exceptions include observation of audited actions. In general, the exceptions tend to be role specific.
Selection Guidance
Implementation Application
Editorial	Objective Parameter: When applying the general objective to specific attacks, the general objective needs to be refined, to state what the necessary exceptions are for a particular role.
Implementing Components FDP_ACC.1 - Subset access control FDP_ACF.1 - Security attribute based access control
Identifier	AC_Label_Export
Descriptive Name	Object security attributes and exportation
Description	Provide object security attributes in exported data with moderate to high effectiveness. The attributes are those associated with specific security function policies.
Selection Guidance
Implementation Application
Editorial	Allocation: TOE This objective has been implemented using FDP_ACC and FDP_ACF. An alternate implementation using FDP_IFC and FDP_IFF is also possible.
Implementing Components FDP_ACC.1 - Subset access control `Component Application Editorial` - Effectiveness depends on accuracy of stored security attributes, on user compliance with procedural constraints on the use of output devices, and on correct functioning of TSF access control mechanisms. FDP_ACF.1 - Security attribute based access control FDP_ETC.2 - Export of user data with security attributes `Component Application` - Apply using attributes relevant to labeling on export. `Component Application Rationale` - Apply using attributes relevant to labeling on export.
Identifier	Access_History
Descriptive Name	Access history for user session
Description	Display information related to the most recent successful and unsuccessful attempts to establish a user session, once a user successfully establishes a user session.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components FTA_TAH.1 - TOE access history
Identifier	Adm_Limits_Bindings
Descriptive Name	Limit an administrator's ability to modify user-subject bindings
Description	Limit the administrator from modification of user-subject bindings in an effort to deter users acting without accountability.
Selection Guidance	If the ability to modify or disable user-subject bindings is not constrained, the system will not be able to maintain accurate audit information. An unauthorized user should not be able to use a subject without being identified in an audit trail.
Implementation Application	Choose FIA_USB.1, FIA_UAU.2, and FMT_MTD.1 to implement the objective.
Editorial	<specific objective> FIA_UAU.2 must be used in conjunction with FIA_USB.1 to ensure that the user is authenticated prior to having a subject act on their behalf. This would assist in limiting the possibility of an unauthorized user from invoking a subject's use.
Implementing Components FIA_UAU.2 - User authentication before any action FIA_USB.1 - User-subject binding FMT_MTD.1 - Management of TSF data
Identifier	Adm_User_Att_Mod
Descriptive Name	Limit administrator's modification of user attributes
Description	Deter the administrator from maliciously modifying users' attributes. Such modifications could allow unauthorized user actions or denial of service to a legitimate user.
Selection Guidance
Implementation Application	Choose FIA_ATD.1, FIA_UAU.2, and FMT_MSA.1 to implement the objective.
Editorial	<specific objective> Consider using the O.Audit_Account objective in conjunction with this objective. FIA_UAU.2 needs to be used in conjunction with FIA_ATD.1 so a malicious administrator can not masquerade as the authorized user, thus gaining the ability to change the user's attributes.
Implementing Components FIA_ATD.1 - User attribute definition `Component Application` - Refine to specify which user attributes should not be modified by an administrator, in order to protect a user from a malicious or error-prone administrator. `Component Application Rationale` - Refine to specify which user attributes should not be modified by an administrator, in order to protect a user from a malicious or error-prone administrator. FIA_UAU.2 - User authentication before any action `Component Application` - Apply this component to the authentication of the administrator prior to allowing legitimate modification of user attributes. `Component Application Rationale` - Apply this component to the authentication of the administrator prior to allowing legitimate modification of user attributes. FMT_MSA.1 - Management of security attributes `Component Application` - The administrators should be excluded from modification of user defined attributes. `Component Application Rationale` - The administrators should be excluded from modification of user defined attributes.
Identifier	Admin_Code_Val
Descriptive Name	Administrative validation of executables
Description	Validate executable objects prior to allowing execution. Validation needs to be done by someone with an expertise to recognize malicious code and the authority and means to prevent its execution.
Selection Guidance
Implementation Application	Choose FDP_ACC.1, FDP_AFF.1, FDP_ACC.1, FMT_MSA.1, and FPT_TST.1 to implement the objective.
Editorial	<specific objective> The access control mechanism could be implemented with FDP_IFF and FDP_IFC. The user data integrity component could be supplemented with TSF data integrity. Identification and authentication may need to be addressed.
Implementing Components FDP_ACC.1 - Subset access control FDP_ACF.1 - Security attribute based access control FDP_SDI.1 - Stored data integrity monitoring FMT_MSA.1 - Management of security attributes FPT_TST.1 - TSF testing
Identifier	Admin_Code_Val_Sten
Descriptive Name	Software validation for absence of steganography
Description	Validate exported objects for absence of steganographic content prior to allowing exportation. Validation needs to be done by someone with an expertise to recognize hidden content and the authority and means to prevent its export.
Selection Guidance
Implementation Application	Choose FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, and FMT_SMR.1 to implement the objective.
Editorial	<specific objective><looks generic> This objective is dependent on the O.Admin_Code_Val objective. Use O.Admin_Code_Val_Sten to counter the steganographic smuggling attack.
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: software control policy List of subjects, objects, and operations covered by the SFP: all potentially executable objects `Component Application Rationale` - Access control SFP: software control policy List of subjects, objects, and operations covered by the SFP: all potentially executable objects FDP_ACF.1 - Security attribute based access control `Component Application` - Access control SFP: software control policy Security attributes: subject attribute value of "installer;" object attribute values "executable" and "installer program" Rules governing access: Rules that explicitly authorise access: only an "installer" subject can make an object "executable" Rules that explicitly deny access: subjects that are not "installer" subjects can not run "installer program" object `Component Application Rationale` - Access control SFP: software control policy Security attributes: subject attribute value of "installer;" object attribute values "executable" and "installer program" Rules governing access: Rules that explicitly authorise access: only an "installer" subject can make an object "executable" Rules that explicitly deny access: subjects that are not "installer" subjects can not run "installer program" object FMT_MSA.1 - Management of security attributes `Component Application` - SFP: software control policy. Ability: set. Attributes: executable, installer. Role: sanitization-control officer. `Component Application Rationale` - SFP: software control policy. Ability: set. Attributes: executable, installer. Role: sanitization-control officer. FMT_MSA.3 - Static attribute initialisation `Component Application` - SFP: software control policy. Default attribute values: restrictive. `Component Application Rationale` - SFP: software control policy. Default attribute values: restrictive. FMT_SMR.1 - Security roles `Component Application` - The authorised identified role: sanitization-control officer `Component Application Rationale` - The authorised identified role: sanitization-control officer
Identifier	Admin_Guidance
Descriptive Name	Administrator guidance documentation
Description	Deter administrator errors by providing adequate administrator guidance.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components AGD_ADM.1 - Administrator guidance
Identifier	Apply_Code_Fixes
Descriptive Name	Apply patches to fix the code
Description	Apply patches to fix the code when vulnerabilities in code allow unauthorized and undiscovered access.
Selection Guidance	This objective should be used when a code fix is prepared for a vulnerability in security-relevant code.
Implementation Application	Any of the ALC_FLR components may be used when implementing this objective, with resultant differences in effectiveness of the objective. Currently, the implementing components apply primarily to the TOE environment. However, the PP author may wish to also consider requirements for the TSF to actively support maintenance via safe installation programs and/or TOE version control mechanisms.
Editorial	<specific objective>
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Administrators in the TSF-maintenance role have a responsibility to modify the security behavior of the system by applying developer-supplied code fixes according to developer-specified procedures. TSF-maintenance administrators shall make sure that security attributes are properly maintained and upgraded as code fixes are applied. `Component Application Rationale` - Administrators in the TSF-maintenance role have a responsibility to modify the security behavior of the system by applying developer-supplied code fixes according to developer-specified procedures. TSF-maintenance administrators shall make sure that security attributes are properly maintained and upgraded as code fixes are applied. ALC_FLR.1 - Basic flaw remediation ALC_FLR.2 - Flaw reporting procedures ALC_FLR.3 - Systematic flaw remediation FMT_MOF.1 - Management of security functions behaviour `Component Application` - Create a TSF-maintenance role with the ability to modify the behavior of arbitrary TSF functions. `Component Application Rationale` - Create a TSF-maintenance role with the ability to modify the behavior of arbitrary TSF functions. FMT_MSA.1 - Management of security attributes `Component Application` - Security policies enforced by the TSF need to allow necessary maintenance of security attributes by TSF-maintenance administrators. `Component Application Rationale` - Security policies enforced by the TSF need to allow necessary maintenance of security attributes by TSF-maintenance administrators.
Identifier	Atomic_Functions
Descriptive Name	Complete security functions or recover to previous state
Description	Recover automatically to a consistent, secure state if a security function does not complete successfully in the presence of certain types of failures.
Selection Guidance	This objective is relevant when a system failure can occur during the processing of a security function, corrupting TSF data and leading to an insecure state. This function provides both recovery and prevention features. These features are intrinsic in that for identified SFs and failure scenarios, the SF automatically recovers to a secure state, and prevents the subsequent vulnerabilities that would occur as a result of operating in an insecure state. The types and number of functions that the TOE implements atomically will determine the costs to provide this protection; however, there are many scenarios where this mechanism is extremely effective and relatively inexpensive to implement.
Implementation Application	Choose FPT_RCV.4 to implement the objective.
Editorial	$
Implementing Components FPT_RCV.4 - Function recovery `Component Application` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the reguirement can be evaluated. This definition can be provided through the associated dependecy on ADV_SPM.1. `Component Application Rationale` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the reguirement can be evaluated. This definition can be provided through the associated dependecy on ADV_SPM.1.
Identifier	Aud_Sys_Entry_Parms
Descriptive Name	Audit changes of system entry parameters
Description	Deter an administrator from changing system entry parameters to allow an unauthorized user access to organizational assets to which they are forbidden.
Selection Guidance	This objective is required if an administrator could allow an unauthorized user the ability to take advantage of the system entry parameters to gain unauthorized access. This objective is relevant for systems that include functionality such as that specified by FIA_AFL.1.
Implementation Application
Editorial	<specific objective><looks generic><audit>
Implementing Components FAU_GEN.1 - Audit data generation `Component Application` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. Other auditable events: modification of system entry parameters Other audit-relevant information: the values of new system entry parameters `Component Application Rationale` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. Other auditable events: modification of system entry parameters Other audit-relevant information: the values of new system entry parameters `Component Application Editorial` - The person being audited in this case should be different than the person controlling the audit records. FMT_MTD.1 - Management of TSF data `Component Application` - System entry parameters must be specified. `Component Application Rationale` - System entry parameters must be specified. FMT_MTD.2 - Management of limits on TSF data FMT_MTD.3 - Secure TSF data
Identifier	Audit_Account
Descriptive Name	Auditing for user accountability
Description	Provide information about past user behavior to an authorized user through system mechanisms. Specifically, during any specified time interval, the system is able to report to a user acting in an identified audit role selected auditable actions that a user has performed, and as a result, what auditable objects were affected and what auditable information was received by that user.
Selection Guidance	Audit mechanisms can be used for several different legitimate purposes. This use addresses user accountability. Effectiveness: low-to-moderate, depending on the threat being countered and the integrity of the audit mechanism. Dependent Objectives: O.I&A_User. This objective contains several implicit parameters: the audit role, the auditable actions, the audited objects, and auditable information passed to the user.
Implementation Application
Editorial	<specific objective> TOE Requirement: FMT_SMR.1
Implementing Components FAU_GEN.1 - Audit data generation `Component Application` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. The intent of this objective strongly implies that a level above "not specified" should be chosen, to ensure that some level of auditing is performed for security-relevant components. The exact level chosen will depend on higher-level goals for system-wide auditing. Depending on these goals, any of the defined levels could be appropriate. Other auditable events: additional security-relevant events as defined with respect to specific system applications Other audit-relevant information: security-relevant information associated with security-relevent events `Component Application Rationale` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. The intent of this objective strongly implies that a level above "not specified" should be chosen, to ensure that some level of auditing is performed for security-relevant components. The exact level chosen will depend on higher-level goals for system-wide auditing. Depending on these goals, any of the defined levels could be appropriate. Other auditable events: additional security-relevant events as defined with respect to specific system applications Other audit-relevant information: security-relevant information associated with security-relevent events FAU_GEN.2 - User identity association FAU_SAR.3 - Selectable audit review `Component Application` - Selection: searches Criteria with logical relations: user identity and time of event Refine: Only users acting in the identified audit role may perform these searches. `Component Application Rationale` - Selection: searches Criteria with logical relations: user identity and time of event Refine: Only users acting in the identified audit role may perform these searches. FAU_SEL.1 - Selective audit `Component Application` - Selection: user identity List of additional attributes that audit selectivity is based upon: specified time intervals `Component Application Rationale` - Selection: user identity List of additional attributes that audit selectivity is based upon: specified time intervals FMT_MOF.1 - Management of security functions behaviour `Component Application` - Ability: Enable or disable. Functions: Review audit data. Roles: Audit Administration role. `Component Application Rationale` - Ability: Enable or disable. Functions: Review audit data. Roles: Audit Administration role. FMT_SMR.1 - Security roles `Component Application` - Create an Audit Administration role `Component Application Rationale` - Create an Audit Administration role
Identifier	Audit_Admin_Role
Descriptive Name	Audit-administration role duties
Description	Deter modification or destruction of audit data through the creation of an audit-administration role.
Selection Guidance	This objective prevents modification or destruction of audit data by limiting possible threat sources.
Implementation Application	--- Only the audit administrator can control the audit trail, per FMT_SMR.2 and FMT_MTD.1. Necessary audit data to implicate attacks by other administrators is delivered, per FAU_STG.2. The audit administrator has no conflict of interest in effectively using such data and will do so, per refinement of AGD_ADM.1.
Editorial	<specific objective> Dependent Objectives: O.I&A_User.
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - The Audit administrator is responsible for guiding the TOE in the collection of needed audit data, for seeing that the audit data is properly stored and protected, and for reviewing collected audit data. Roles are assigned so that an audit administrator does not have any other administrative roles. `Component Application Rationale` - The Audit administrator is responsible for guiding the TOE in the collection of needed audit data, for seeing that the audit data is properly stored and protected, and for reviewing collected audit data. Roles are assigned so that an audit administrator does not have any other administrative roles. FAU_STG.2 - Guarantees of audit data availability `Component Application` - Note that FAU_STG.3 may be used in place of FAU_STG.2. `Component Application Rationale` - Note that FAU_STG.3 may be used in place of FAU_STG.2. FMT_MTD.1 - Management of TSF data `Component Application` - Abilities: to manage. Role: Audit Administration. Data: audit data. `Component Application Rationale` - Abilities: to manage. Role: Audit Administration. Data: audit data. FMT_SMR.2 - Restrictions on security roles `Component Application` - The authorised identified role: Create an Audit Administration role that does not overlap other administrative roles. Conditions for the different roles: No user ID may be associated with both the Audit Administration role and some other administrative role. `Component Application Rationale` - The authorised identified role: Create an Audit Administration role that does not overlap other administrative roles. Conditions for the different roles: No user ID may be associated with both the Audit Administration role and some other administrative role.
Identifier	Audit_Deter_Misuse
Descriptive Name	Audit system access to deter misuse
Description	Audit system access to discover system misuse and provide a potential deterrent by warning the user.
Selection Guidance	If a hacker can get in to a system without administrator knowledge then this objective should be considered as a means to discover the access and implement additional access control measures (e.g., access control lists on routers). Also, it might be considered to let the users know that their access is being monitored and recorded for deterrence measures.
Implementation Application
Editorial	<specific objective> In some cases, the same objective may be implemented in several different ways. This is true, e.g., of the I&A objective.
Implementing Components FAU_GEN.2 - User identity association `Component Application` - The TSF shall record within each audit record the information that is identifies successful and unsuccessful access to the system. `Component Application Rationale` - The TSF shall record within each audit record the information that is identifies successful and unsuccessful access to the system. FTA_TAB.1 - Default TOE access banners `Component Application` - The TOE should display to the user a message that indicates their access is being recorded as a deterrent to hackers or unauthorized users. `Component Application Rationale` - The TOE should display to the user a message that indicates their access is being recorded as a deterrent to hackers or unauthorized users.
Identifier	Audit_Gen_User
Descriptive Name	Individual accountability
Description	Provide individual accountability for audited events. Uniquely identify each user so that auditable actions can be traced to a user.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FAU_GEN.2 - User identity association FIA_UID.1 - Timing of identification
Identifier	Audit_Generation
Descriptive Name	Audit records with identity
Description	Record in audit records: date and time of action, location of the action, and the entity responsible for the action.
Selection Guidance
Implementation Application
Editorial	<specific objective>>
Implementing Components FAU_GEN.1 - Audit data generation `Component Application` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. `Component Application Rationale` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety.
Identifier	Audit_Loss_Respond
Descriptive Name	Respond to possible loss of stored audit records
Description	Respond to possible loss of audit records when audit trail storage is full or nearly full.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components FAU_STG.3 - Action in case of possible audit data loss FAU_STG.4 - Prevention of audit data loss
Identifier	Audit_Protect
Descriptive Name	Protect stored audit records
Description	Protect audit records against unauthorized access, modification, or deletion to ensure accountability of user actions.
Selection Guidance	$
Implementation Application	There are two variants of this objective (choose one): [Basic]: Choose FAU_STG.1. [Availability]: Choose FAU_STG.2.
Editorial	<generic objective>
Implementing Components FAU_STG.1 - Protected audit trail storage `Component Application` - Select prevent. `Component Application Rationale` - Select prevent. FAU_STG.2 - Guarantees of audit data availability `Component Application` - Select prevent and, at a minimum, select attack. `Component Application Rationale` - Select prevent and, at a minimum, select attack.
Identifier	Audit_Unusual_User
Descriptive Name	Audit unusual user activity
Description	Audit unusual user activity.
Selection Guidance
Implementation Application
Editorial	<specific objective><audit>
Implementing Components FAU_GEN.1 - Audit data generation `Component Application` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. `Component Application Rationale` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. FAU_SAA.2 - Profile based anomaly detection `Component Application Editorial` - Consider other components in FAU_SAA. Some preventive mechanisms (e.g. FTA_TSE.1) are useful for discovering unusual activities.
Identifier	Change_Control_Users
Descriptive Name	User notification of data content changes
Description	Notify users of changes to data content in order to make any adjustments to their own data.
Selection Guidance
Implementation Application
Editorial	<specific objective><make generic>
Implementing Components FDP_DAU.1 - Basic data authentication FDP_DAU.2 - Data authentication with identity of guarantor
Identifier	Clean_Obj_Recovery
Descriptive Name	Object and data recovery free from malicious code
Description	Recover to a viable state after malicious code is introduced and damage occurs, removing the malicious code as part of the process.
Selection Guidance	The term "clean" is used here to refer to absence of malicious code, e.g., a virus or worm.
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ETC.2 - Export of user data with security attributes `Component Application` - Apply this in such a way as to make sure data needed for backup is reliably exported and marked to prevent confusing it with invalid backup data. In the case of an intelligent remote backup device, this coponent may also be applied to control information used to retrieve backup data, to prevent spoofing. `Component Application Rationale` - Apply this in such a way as to make sure data needed for backup is reliably exported and marked to prevent confusing it with invalid backup data. In the case of an intelligent remote backup device, this coponent may also be applied to control information used to retrieve backup data, to prevent spoofing. FDP_ITC.1 - Import of user data without security attributes `Component Application` - Apply this in such a way as to make sure that the restored backup data is not corrupted. `Component Application Rationale` - Apply this in such a way as to make sure that the restored backup data is not corrupted. FDP_ROL.1 - Basic rollback `Component Application` - Apply this component to cover operations that may corrupt an object. For example, operations performed by malicious code that has been accidentally loaded onto a system. `Component Application Rationale` - Apply this component to cover operations that may corrupt an object. For example, operations performed by malicious code that has been accidentally loaded onto a system. FMT_MOF.1 - Management of security functions behaviour `Component Application` - Restrict the use of rollback facilities to an appropriate administrative role. `Component Application Rationale` - Restrict the use of rollback facilities to an appropriate administrative role. FPT_TST.1 - TSF testing `Component Application` - Specify restoration of TSF code and data as onditions under which self test should occur, in order to check that the TSF has been restored properly. `Component Application Rationale` - Specify restoration of TSF code and data as onditions under which self test should occur, in order to check that the TSF has been restored properly.
Identifier	Code_Signing
Descriptive Name	Code signing and verification
Description	Check verification of signed downloaded code prior to execution. A well-known example is checking digital signatures on signed Java applets.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ETC.2 - Export of user data with security attributes `Component Application` - Environment: Apply FDP_ETC.2 to require signatures on code exported by the developer. `Component Application Rationale` - Environment: Apply FDP_ETC.2 to require signatures on code exported by the developer. FDP_ITC.2 - Import of user data with security attributes `Component Application` - Apply this component to require checking of digital signatures on imported code. `Component Application Rationale` - Apply this component to require checking of digital signatures on imported code. FDP_UIT.1 - Data exchange integrity `Component Application` - Allocation: FDP_UIT.1.2 is for the TOE; FDP_UIT.1.1 is for the Environment. Apply this element to specify that the digital signature process is effective; i.e. prevents spoofing or masquerading. `Component Application Rationale` - Allocation: FDP_UIT.1.2 is for the TOE; FDP_UIT.1.1 is for the Environment. Apply this element to specify that the digital signature process is effective; i.e. prevents spoofing or masquerading. FIA_UAU.1 - Timing of authentication
Identifier	Comm_Line_Protection
Descriptive Name	Physical protection of the communications line
Description	Protect communications lines from physical tampering.
Selection Guidance
Implementation Application
Editorial	<specific objective><apply generic>
Implementing Components FPT_PHP.1 - Passive detection of physical attack
Identifier	Comm_Trusted_Channel
Descriptive Name	Trusted channel to remote trusted system
Description	Provide a communications channel between the system and a remote trusted system for the performance of security-critical operations.
Selection Guidance
Implementation Application
Editorial	<specific objective><apply generic>
Implementing Components FTP_ITC.1 - Inter-TSF trusted channel `Component Application` - It will be specified through this component's operations whether the local, remote, or both the local and remote shall be capable of establishing the trusted channel. `Component Application Rationale` - It will be specified through this component's operations whether the local, remote, or both the local and remote shall be capable of establishing the trusted channel.
Identifier	Config_Management
Descriptive Name	Implement operational configuration management
Description	Implement a configuration management plan. Implement configuration management to assure storage integrity, identification of system connectivity (software, hardware, and firmware), and identification of system components (software, hardware, and firmware).
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FMT_MOF.1 - Management of security functions behaviour `Component Application` - Apply this component in such a way as to achieve operational configuration management. Use as a model for this, the corresponding configuration management requirements for the development environment, e.g. ACM_AUT.1. `Component Application Rationale` - Apply this component in such a way as to achieve operational configuration management. Use as a model for this, the corresponding configuration management requirements for the development environment, e.g. ACM_AUT.1. FMT_MTD.1 - Management of TSF data `Component Application` - Apply this component in such a way as to achieve operational configuration management. Use as a model for this, the corresponding configuration management requirements for the development environment, e.g. ACM_AUT.1. `Component Application Rationale` - Apply this component in such a way as to achieve operational configuration management. Use as a model for this, the corresponding configuration management requirements for the development environment, e.g. ACM_AUT.1.
Identifier	Correct_Operation
Descriptive Name	Verify correct operation as designed
Description	Provide the ability for the authorized user to verify that the system operates as designed.
Selection Guidance
Implementation Application	To ensure that tests in FPT_TST.1 are reliable, select EAL2 or greater assurance.
Editorial	<specific objective><too simple?>
Implementing Components FPT_TST.1 - TSF testing `Component Application` - Refine this component by specifying that correctness means the TSF operates as designed. `Component Application Rationale` - Refine this component by specifying that correctness means the TSF operates as designed. `Component Application Editorial` - For further ideas on how to do this, consult the Part 2: Annexes of the CC, section J16.
Identifier	Crypto_AC
Descriptive Name	Cryptographic access control policy
Description	Restrict user access to cryptographic IT assets in accordance with a specified user access control policy.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Identify a policy for the protection of cryptographic assets, including cryptographic keys. Cover all operations between subjects and cryptographic assets. `Component Application Rationale` - Identify a policy for the protection of cryptographic assets, including cryptographic keys. Cover all operations between subjects and cryptographic assets. FDP_ACF.1 - Security attribute based access control `Component Application` - Specify attributes for objects, such as the object’s function (e.g., whether it is encrypted), associated roles, user ownership, and validity period (if appropriate). For the special case of cryptographic keys, specify additional attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption). Specify rules governing access to cryptographic assets, including rules governing the allowed use of cryptographic operations on relevant objects (e.g., plaintext, ciphertext, red or black cryptographic keys). `Component Application Rationale` - Specify attributes for objects, such as the object’s function (e.g., whether it is encrypted), associated roles, user ownership, and validity period (if appropriate). For the special case of cryptographic keys, specify additional attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption). Specify rules governing access to cryptographic assets, including rules governing the allowed use of cryptographic operations on relevant objects (e.g., plaintext, ciphertext, red or black cryptographic keys).
Identifier	Crypto_Comm_Channel
Descriptive Name	Encrypted communications channel
Description	Provide secure session establishment between the system and remote systems using encryption functions.
Selection Guidance	This objective assumes authorization for the local system to communicate with specific remote systems and compatible cryptographic support from those remote systems. These assumptions may require additional requirements to be levied on the local and/or remote systems. This components associated with this objective might be considered as a specific implementation of other secure channel requirements. It is likely that all the components specified for this objective must be provided by the system in order to implement a robust solution. The set of associated components is preventive.
Implementation Application	Application of the cryptographic components will vary depending on the session protocol, not all components are relevant to all protocols.
Editorial	<specific objective> This objective differs from O.Data_Exchange_Conf in that the encryption function for this objective is required to establish the session. That is, some of the lower-level protocol headers may themselves be encrypted.
Implementing Components FCS_CKM.1 - Cryptographic key generation FCS_CKM.2 - Cryptographic key distribution FCS_CKM.3 - Cryptographic key access FCS_CKM.4 - Cryptographic key destruction FCS_COP.1 - Cryptographic operation
Identifier	Crypto_Data_Sep
Descriptive Name	Separation of cryptographic data
Description	Provide complete separation between plaintext and encrypted data and between data and keys. This requires separate channels and separate storage areas. The only place any data can pass between the plaintext and encrypted data modules is in the cryptographic engine. There should be no way for plaintext keys to reach either data module and no way for data to enter the key handling module. Eencrypted keys can be handled as encrypted data, but with limited user access.
Selection Guidance
Implementation Application	Choose ADV_INT.1, FPT_SEP.2, and FDP_IFF.3; apply using a technical policy on separation of encrypted and plaintext data (sometimes referred to as red-black separation).
Editorial
Implementing Components ADV_INT.1 - Modularity `Component Application` - Refine to specify red data, black data, and key handling modules in the cryptographic engine. It must be obvious from the design that the only data flow between the red data module and the black data module is through encryption or decryption. It should also be apparent that no red keys can find their way into the data module. `Component Application Rationale` - Refine to specify red data, black data, and key handling modules in the cryptographic engine. It must be obvious from the design that the only data flow between the red data module and the black data module is through encryption or decryption. It should also be apparent that no red keys can find their way into the data module. FDP_IFF.3 - Limited illicit information flows `Component Application` - Specify data flow policies concerning red/black data separation and data/key separation. `Component Application Rationale` - Specify data flow policies concerning red/black data separation and data/key separation. FPT_SEP.2 - SFP domain separation `Component Application` - Specify policies concerning red/black data separation and data/key separation. `Component Application Rationale` - Specify policies concerning red/black data separation and data/key separation.
Identifier	Crypto_Dsgn_Impl
Descriptive Name	Cryptographic Design and Implementation
Description	Minimize or even eliminate design and implementation errors in the cryptographic modules and functions.
Selection Guidance	The PP/ST should demonstrate that the TOE provides at least a high level architecture appropriate to implement the claimed cryptographic functional requirements. Demonstration that lower levels of design correctly implement the highest design level may also be appropriate.
Implementation Application
Editorial
Implementing Components ADV_HLD.1 - Descriptive high-level design `Component Application` - Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain. `Component Application Rationale` - Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain. ADV_HLD.2 - Security enforcing high-level design `Component Application` - Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain. Require distinguishing the cryptographic boundary of the TOE from the overall TOE boundary. `Component Application Rationale` - Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain. Require distinguishing the cryptographic boundary of the TOE from the overall TOE boundary. ADV_LLD.1 - Descriptive low-level design `Component Application` - Require a description of the internal workings of the cryptographic TSF in terms of modules and their interrelationships and dependencies. `Component Application Rationale` - Require a description of the internal workings of the cryptographic TSF in terms of modules and their interrelationships and dependencies. ADV_RCR.1 - Informal correspondence demonstration `Component Application` - Require demonstration of the correspondence between various representations of the cryptographic design. `Component Application Rationale` - Require demonstration of the correspondence between various representations of the cryptographic design. ALC_TAT.2 - Compliance with implementation standards `Component Application` - Require that the development of cryptographic functional desin be performed in accordance with a defined implementation standard (e.g. coding standard). `Component Application Rationale` - Require that the development of cryptographic functional desin be performed in accordance with a defined implementation standard (e.g. coding standard).
Identifier	Crypto_Import_Export
Descriptive Name	Cryptographic import, export, and inter-TSF transfer
Description	Protect cryptographic data assets when they are being transmitted to and from the TOE, either through intervening untrusted components or directly to/from human users.
Selection Guidance	Cryptographic assets that may need protection include cryptographic keys that are unencrypted or are weakly encrypted with a password, cryptographic security parameters, and plaintext authentication data.
Implementation Application	Three different implementations may achieve the intent of this objective (and combinations are possible): 1. Use FTP_TRP.1 and/or FTP_TRC.1 to specify trusted paths and channels for communicating cryptographic assets. 2. Require a separate physical port for input and output of such information; use FDP_ETC.1 and FDP_ITC.1 for this. 3. Require security labeling of cryptographic data; in this case, use FDP_ETC.2 and FDP_ITC.2 instead. All three implementations assume user cognizance. Specify this using AGD_ADM.1 and/or AGD_USR.1.
Editorial
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Instruct administrators on the sensitivity of cryptographic assets and on the importance of not mix them with other information. `Component Application Rationale` - Instruct administrators on the sensitivity of cryptographic assets and on the importance of not mix them with other information. AGD_USR.1 - User guidance `Component Application` - Instruct users on the sensitivity of cryptographic assets and on the importance of not mix them with other information. `Component Application Rationale` - Instruct users on the sensitivity of cryptographic assets and on the importance of not mix them with other information. FDP_ETC.1 - Export of user data without security attributes `Component Application` - Specify constraints on I/O devices to facilitate separation of cryptographic assets and to protect them from improper distribution. `Component Application Rationale` - Specify constraints on I/O devices to facilitate separation of cryptographic assets and to protect them from improper distribution. FDP_ETC.2 - Export of user data with security attributes `Component Application` - Specify constraints on I/O devices to protect them from improper distribution. Specify labels to facilitate separation of cryptographic assets from other assets. `Component Application Rationale` - Specify constraints on I/O devices to protect them from improper distribution. Specify labels to facilitate separation of cryptographic assets from other assets. FDP_ITC.1 - Import of user data without security attributes `Component Application` - Specify constraints to avoid loading of weakened or corrupted cryptographic assets. `Component Application Rationale` - Specify constraints to avoid loading of weakened or corrupted cryptographic assets. FDP_ITC.2 - Import of user data with security attributes `Component Application` - Specify constraints to avoid loading of weakened or corrupted cryptographic assets. `Component Application Rationale` - Specify constraints to avoid loading of weakened or corrupted cryptographic assets. FTP_ITC.1 - Inter-TSF trusted channel `Component Application` - Use to facilitate protected communication of cryptographic assets. `Component Application Rationale` - Use to facilitate protected communication of cryptographic assets. FTP_TRP.1 - Trusted path `Component Application` - Use to facilitate protected communication of cryptographic assets. `Component Application Rationale` - Use to facilitate protected communication of cryptographic assets.
Identifier	Crypto_Key_Man
Descriptive Name	Cryptographic Key Management
Description	Fully define cryptographic components, functions, and interfaces. Ensure appropriate protection for cryptographic keys throughout their lifecycle, covering generation, distribution, storage, use, and destruction.
Selection Guidance	If cryptographic functions are supported, then their management and protection needs to be clearly specified.
Implementation Application	Cryptographic function may be specified either directly via functional requirements or indirectly via assurance requirements. Directly specify key management using components of the FCS_CKM family, with the following additions, depending on the nature of the keys: protection of stored user keys: use FDP_ACC and FDP_ACF, refine AVA_VLA.1 user key attributes: use FMT_MSA, FDP_ACC, and FDP_ACF. user key entry: use FDP_ITC. protection of stored TSF keys: use FPT_SEP. TSF key entry: use FMT_MTD. Alternatively or additionally, require the TOE developer to specify cryptographic key management by using ADV_FSP and ADV_SPM.
Editorial	Cryptographic function includes not only key management but cryptographic operation -- see O.Crypto_Operation.
Implementing Components ADV_FSP.1 - Informal functional specification `Component Application` - Require a high level description of the user-visible interface and behaviour of the cryptographic components of the TSF. `Component Application Rationale` - Require a high level description of the user-visible interface and behaviour of the cryptographic components of the TSF. ADV_SPM.1 - Informal TOE security policy model `Component Application` - Include if there is a requirement for security policy model. `Component Application Rationale` - Include if there is a requirement for security policy model. AVA_VLA.1 - Developer vulnerability analysis `Component Application` - Check for ways to evade cryptographic access control policy. Specifically, consider ways for unauthorized personnel to recover plaintext cryptographic keys and authentication data (e.g., from audit records, temporary objects, free storage areas). `Component Application Rationale` - Check for ways to evade cryptographic access control policy. Specifically, consider ways for unauthorized personnel to recover plaintext cryptographic keys and authentication data (e.g., from audit records, temporary objects, free storage areas). `Component Application Editorial` - The CC does not provide a means to specify, e.g., what should NOT be audited. Indeed, it is difficult to cast a purely functional requirement along these lines. A plain-text key or user password could accidently enter the audit trail for many reasons having little to do with the TSF design. For example, a user might accidentally enter a password in place of a user ID, as the user is likely to be thinking about both during an I&A session. FCS_CKM.1 - Cryptographic key generation `Component Application` - Allocate to the TOE if the TOE performs key generation. `Component Application Rationale` - Allocate to the TOE if the TOE performs key generation. FCS_CKM.2 - Cryptographic key distribution `Component Application` - Allocate to the TOE if the TOE performs key distibution. `Component Application Rationale` - Allocate to the TOE if the TOE performs key distibution. FCS_CKM.3 - Cryptographic key access `Component Application` - Allocate to the TOE if the TOE performs any cryptographic operations. Besides access for use by cryptographic operations, backup, archiving, escrow and recovery may need to be dealt with. `Component Application Rationale` - Allocate to the TOE if the TOE performs any cryptographic operations. Besides access for use by cryptographic operations, backup, archiving, escrow and recovery may need to be dealt with. FCS_CKM.4 - Cryptographic key destruction `Component Application` - Allocate to the TOE if the TOE performs any cryptographic operations. `Component Application Rationale` - Allocate to the TOE if the TOE performs any cryptographic operations. FDP_ACC.1 - Subset access control `Component Application` - Specify an access control policy for protection of cryptographic keys. `Component Application Rationale` - Specify an access control policy for protection of cryptographic keys. `Component Application Editorial` - The Crypto Guidance paper CSWG-97/02 suggests using FDP_ACC, FDP_ACF, and/or FPT_SEP to protect user and TSF keys in storage. Obviuosly, FDP_ACC.1 can be refined to require access control be accomplished by encrypting all keys in storage. Also FCS_COP.1.1 requires that the TSF shall perform an Assigned list of cryptographic operations. Encryption of keys while in storage should be included in this Assignment. However, this seems a backhanded way to state an important requirement, a requirement that should have its own CC Component. FDP_ACF.1 - Security attribute based access control `Component Application` - Using the access control policy for protection of cryptographic keys, require that the TSF store keys in encrypted form and protect them from unauthorized use. `Component Application Rationale` - Using the access control policy for protection of cryptographic keys, require that the TSF store keys in encrypted form and protect them from unauthorized use. FDP_ITC.1 - Import of user data without security attributes `Component Application` - Use the access control policy for protection of cryptographic keys to control key entry. Specify, e.g., whether keys are to be entered in unencrypted, encrypted, or split-knowledge forms. `Component Application Rationale` - Use the access control policy for protection of cryptographic keys to control key entry. Specify, e.g., whether keys are to be entered in unencrypted, encrypted, or split-knowledge forms. FMT_MSA.1 - Management of security attributes `Component Application` - Specify management of cryptographic key attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption). `Component Application Rationale` - Specify management of cryptographic key attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption). FMT_MTD.1 - Management of TSF data `Component Application` - Cover import/entry of TSF cryptographic keys, key escrow (if relevant), key generation, etc. `Component Application Rationale` - Cover import/entry of TSF cryptographic keys, key escrow (if relevant), key generation, etc. FPT_SEP.1 - TSF domain separation `Component Application` - Require separation of domains to protect stored cryptographic keys. `Component Application Rationale` - Require separation of domains to protect stored cryptographic keys.
Identifier	Crypto_Manage_Roles
Descriptive Name	Management of cryptographic roles
Description	Provide one or more roles to manage cryptographic assets and attributes.
Selection Guidance	Choose in order to limit dangers resulting from widespread access to the control of cryptographic assets.
Implementation Application
Editorial
Implementing Components FMT_SMR.1 - Security roles `Component Application` - Identify roles for managing cryptographic capabilities, e.g., Cryptgraphic Account Manager, System Security Officer, Certification Authority Manager, Registration Authority Manager, Cryptography User. Associate privileges and responsibilities with these roles using other components in class FMT, as appropriate. `Component Application Rationale` - Identify roles for managing cryptographic capabilities, e.g., Cryptgraphic Account Manager, System Security Officer, Certification Authority Manager, Registration Authority Manager, Cryptography User. Associate privileges and responsibilities with these roles using other components in class FMT, as appropriate.
Identifier	Crypto_Modular_Dsgn
Descriptive Name	Cryptographic Modular Design
Description	Prevent errors in one part of the TOE from influencing other parts, especially cryptographic parts. To this end, noncryptographic I/O paths must be well defined and logically independent of circuitry and processes performing key generation, manual key entry, key zeroising, and similar key-related operations.
Selection Guidance
Implementation Application	--- This objective helps insure that the TOE is designed using sound engineering principles and, hence, that data is accessed only by the components of the TOE that need it. The low-level design requirements that support this objective can be used to ensure that the inputs, outputs, plaintexts, and ciphertexts are accessed only by components of the TOE that need them.
Editorial
Implementing Components ADV_FSP.1 - Informal functional specification `Component Application` - Require specification of the presentation of syntax and semantics of all extenal cryptographic TSF interfaces. Require evidence deomonstrating that the cryptographic functions in the TSF are completely represented. `Component Application Rationale` - Require specification of the presentation of syntax and semantics of all extenal cryptographic TSF interfaces. Require evidence deomonstrating that the cryptographic functions in the TSF are completely represented. ADV_HLD.1 - Descriptive high-level design `Component Application` - Require a high level design for the cryptographic functions in the TSF. `Component Application Rationale` - Require a high level design for the cryptographic functions in the TSF. ADV_INT.1 - Modularity `Component Application` - Require that cryptographic data is accessed only by the components of the TOE that need it. `Component Application Rationale` - Require that cryptographic data is accessed only by the components of the TOE that need it. ADV_LLD.1 - Descriptive low-level design `Component Application` - Ensure that the cryptographic inputs, outputs, plaintext, and cyphertext are accessed only by the components of the TOE that need them. `Component Application Rationale` - Ensure that the cryptographic inputs, outputs, plaintext, and cyphertext are accessed only by the components of the TOE that need them.
Identifier	Crypto_Operation
Descriptive Name	Cryptographic function definition
Description	Cryptographic components, functions, and interfaces shall be fully defined.
Selection Guidance	If cryptographic functions are supported, then the definition of the cryptographic functionality should be clearly present, as should definitions of the cryptographic and physical/logical boundaries.
Implementation Application	Cryptographic function may be specified either directly via functional requirements or indirectly via assurance requirements. Directly specify cryptographic operations using components of the FCS_COP family. Alternatively or additionally, require the TOE developer to specify cryptographic operation by using ADV_FSP and ADV_SPM.
Editorial	Cryptographic function includes key management as well as cryptographic operation -- see O.Crypto_Key_Man.
Implementing Components ADV_FSP.1 - Informal functional specification `Component Application` - Require a high level description of the user-visible interface and behaviour of the cryptographic components of the TSF. `Component Application Rationale` - Require a high level description of the user-visible interface and behaviour of the cryptographic components of the TSF. ADV_SPM.1 - Informal TOE security policy model `Component Application` - Include if there is a requirement for security policy model. `Component Application Rationale` - Include if there is a requirement for security policy model. FCS_COP.1 - Cryptographic operation `Component Application` - Include if the TOE performs any perform the cryptographic operations. Note that encryption of keys while in storage is one of the cryptographic operations that must be listed. `Component Application Rationale` - Include if the TOE performs any perform the cryptographic operations. Note that encryption of keys while in storage is one of the cryptographic operations that must be listed.
Identifier	Crypto_Self_Test
Descriptive Name	Cryptographic self test
Description	Provide the ability to verify that the cryptographic functions operate as designed.
Selection Guidance	Select this objective if O.Secure_State is specialized to protect cryptographic operation. (Implicit from the need to preserve a secure state when cryptographic errors occur, is the need for functionality to detect when such errors occur.)
Implementation Application
Editorial
Implementing Components FDP_SDI.1 - Stored data integrity monitoring `Component Application` - Apply so as to detect cryptographic data integrity errors. `Component Application Rationale` - Apply so as to detect cryptographic data integrity errors. FPT_AMT.1 - Abstract machine testing `Component Application` - Apply to testing the cryptographic portion of the underlying abstract state machine. `Component Application Rationale` - Apply to testing the cryptographic portion of the underlying abstract state machine. FPT_TST.1 - TSF testing `Component Application` - Refine to cover tests to ensure that the cryptographic functions are operating correctly. Tests conducted during start-up and/or periodically may include known-answer tests of cryptographic operations, as well as statistical tests on random number generators. Additional tests may involve generation of private / public key pairs, pair-wise consistency tests of encryption and decryption, key-entry tests, and key integrity tests. `Component Application Rationale` - Refine to cover tests to ensure that the cryptographic functions are operating correctly. Tests conducted during start-up and/or periodically may include known-answer tests of cryptographic operations, as well as statistical tests on random number generators. Additional tests may involve generation of private / public key pairs, pair-wise consistency tests of encryption and decryption, key-entry tests, and key integrity tests.
Identifier	Crypto_Test_Reqs
Descriptive Name	Test cryptographic functionality
Description	Test cryptographic operation and key management.
Selection Guidance
Implementation Application	Testing requirements should be selected based on the sensitivity of the application and vulnerability of the TOE to attack. In particular, greater depth of testing may provide better assurance of correct function, and may well be feasible, as cryptographic functions are often fairly simple and modular.
Editorial	Temporary stand-in for ATE_FUN.1
Implementing Components ATE_COV.1 - Evidence of coverage ATE_DPT.1 - Testing: high-level design ATE_DPT.2 - Testing: low-level design ATE_FUN.1 - Functional testing ATE_IND.1 - Independent testing - conformance AVA_VLA.1 - Developer vulnerability analysis `Component Application` - Provide independent testing of cryptographic functionality. `Component Application Rationale` - Provide independent testing of cryptographic functionality.
Identifier	Data_Exchange_Conf
Descriptive Name	Enforce data exchange confidentiality
Description	Protect user data confidentiality when exchanging data with a remote system.
Selection Guidance	This objective can support several types of data exchange policies, including those that do not allow communications between the local system and specific remote sites, as well as those that constrain the types of information that can be sent over communications lines.
Implementation Application
Editorial	<specific objective><apply generic>
Implementing Components FCS_COP.1 - Cryptographic operation `Component Application` - Complete this component's operations in a manner compatible with the associated FCS_CKM components. List of cryptographic operations: a function for encrypting and/or decrypting user data that is exported and/or imported `Component Application Rationale` - Complete this component's operations in a manner compatible with the associated FCS_CKM components. List of cryptographic operations: a function for encrypting and/or decrypting user data that is exported and/or imported
Identifier	Data_Export_Control
Descriptive Name	Control user data exportation
Description	Impose information control policies that do not allow export of specified data and/or export to specified locations.
Selection Guidance	This objective is relevant when exporting user data is considered to be a sensitive operation. Data exportation may exist in many forms, including printing, removable media storage, sending e-mail, and/or transferring files to an external network via network protocols.
Implementation Application	There are two variants of this objective (choose one): [Unmarked]: Choose FDP_ETC.1. [Marked]: Choose FDP_ETC.2. The choice of whether to export data with or without security attributes will depend on several considerations. The predominant considerations are the potential and actual uses of the security attributes in the destination environment. The less potential for use in the destination environment, the less motivation to mark exported data with security attributes, even if such attributes are maintained internally. --- The [Unmarked] variant applies a policy enforcement to the export of user data, but does not require security attributes to be associated with the exported data itself. The term "unmarked" indicates that the data is not associated with any security attributes whatsoever, avoiding possible misconceptions that might be implied by the term "unlabeled." The [Marked] variant applies policy enforcement to the export of user data. In addition, the implementation provides security attributes that are associated, with moderate to high effectiveness, with instances of exported data. The attributes are those associated with specific security function policies. The term "marked" indicates that the security attributes may not actually represent security labels in its common usage.
Editorial	<generic objective> This objective has been implemented using FDP_ACC and FDP_ACF. An alternate implementation using FDP_IFC and FDP_IFF is also possible.
Implementing Components FDP_ETC.1 - Export of user data without security attributes FDP_ETC.2 - Export of user data with security attributes
Identifier	Data_Imp_Exp_Control
Descriptive Name	Data import/export to/from system control
Description	Protect data from being sent to erroneous places and more places external to the system than allowed by the organization's security policy. Conversely the import of data into the system should be protected from illicit information or information not allowed by the organization's security policy.
Selection Guidance	This objective is relevant in the following scenarios: 1. When a user has the ability to give out information that could cause an outsider to send data that is not deemed acceptable by the organization's policy or from a location unacceptable by the organization's policy this objective should be considered (e.g. adult only web sites). 2. When a user has the ability to send data to inappropriate locations or to more locations than the organization's policy allows this objective should be considered. 3. When a hacker can flood the system (TOE) with illicit data, import control should be enforced.
Implementation Application
Editorial
Implementing Components FDP_ETC.2 - Export of user data with security attributes FDP_IFC.1 - Subset information flow control FDP_IFF.1 - Simple security attributes FDP_ITC.2 - Import of user data with security attributes
Identifier	EMSEC_Design
Descriptive Name	Provide physical emanations security
Description	Design and build the system in such a way as to control the production of intelligible emanations within specified limits.
Selection Guidance	Select this objective when there is a need to control intelligible emanations before they leave the TOE itself.
Implementation Application	$
Editorial	[assignment: specified limit]. This objective is a minor variant of O.IntelEman_Control.
Implementing Components FPT_PHP_EMSEC_Design - Physical Emanations Security `Component Application` - Types of emanations: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives. `Component Application Rationale` - Types of emanations: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Identifier	Encryption_Access
Descriptive Name	Protection of ciphertext
Description	Deter cryptoanalysis of ciphertext by denying unauthorized access to encrypted objects.
Selection Guidance
Implementation Application
Editorial	Hierarchical to: O.Robust_Encryption
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: ciphertext protection List of subjects, objects, and operations covered by the SFP: all operations between all subjects and encrypted objects `Component Application Rationale` - Access control SFP: ciphertext protection List of subjects, objects, and operations covered by the SFP: all operations between all subjects and encrypted objects FDP_ACF.1 - Security attribute based access control `Component Application` - Access control SFP: ciphertext protection Security attributes: attributes telling which objects are encrypted Rules governing access: the only operations that may be performed on encrypted objects are encryption, deletion, and perhaps digital signature; only subjects that are trusted to properly handle ciphertext can perform these operations `Component Application Rationale` - Access control SFP: ciphertext protection Security attributes: attributes telling which objects are encrypted Rules governing access: the only operations that may be performed on encrypted objects are encryption, deletion, and perhaps digital signature; only subjects that are trusted to properly handle ciphertext can perform these operations FDP_ETC.2 - Export of user data with security attributes `Component Application` - SFP(s): ciphertext protection Additional exportation control rules: ciphertext exported from the TOE shall be doubly encrypted Attributes: minimal information needed to unwrap the doubly encrypted object. `Component Application Rationale` - SFP(s): ciphertext protection Additional exportation control rules: ciphertext exported from the TOE shall be doubly encrypted Attributes: minimal information needed to unwrap the doubly encrypted object.
Identifier	Encryption_Prohibit
Descriptive Name	Protection of corresponding plaintext-ciphertext pairs
Description	Prohibit the transmission of a ciphertext message over any network where the corresponding plaintext might be available. Include cryptographic padding (i.e., random plaintext) to hide the correspondence between segments of real ciphertext and their known plaintexts.
Selection Guidance
Implementation Application
Editorial	<specific objective><apply generics> Hierarchical to: O.Robust_Encryption This objective is implemented via an access-control policy.
Implementing Components FCS_COP.1 - Cryptographic operation `Component Application` - Note: to get the desired effect, it may be necessary to apply this requirement several times for different kinds of ciphertext (e.g., singly and doubly encrypted text). Complete this component's operations in a manner compatible with the associated FCS_CKM components. Refinement: The algorithm to be built or used in such a way that plain text is padded with random text prior to encryption. `Component Application Rationale` - Note: to get the desired effect, it may be necessary to apply this requirement several times for different kinds of ciphertext (e.g., singly and doubly encrypted text). Complete this component's operations in a manner compatible with the associated FCS_CKM components. Refinement: The algorithm to be built or used in such a way that plain text is padded with random text prior to encryption. FDP_IFC.1 - Subset information flow control `Component Application` - Information flow control SFP: plaintext-ciphertext correspondence List of subjects, information, and operations: data that is or will be encrypted; subjects that handle such information. Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found. `Component Application Rationale` - Information flow control SFP: plaintext-ciphertext correspondence List of subjects, information, and operations: data that is or will be encrypted; subjects that handle such information. Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found. FDP_IFF.1 - Simple security attributes `Component Application` - SFP: plaintext-ciphertext correspondence. Attributes: whether an object is encrypted, whether its sensitivity merits encryption, location (e.g., whether it on a network, in a particular computer), and for each location, whether it is for ciphertext, for encryption-worthy plaintext, or neither. Rules: encryption-worthy plaintext may only reside in locations designated as encryption worthy; ciphertext may only reside in locations designated as ciphertext worthy. Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found. `Component Application Rationale` - SFP: plaintext-ciphertext correspondence. Attributes: whether an object is encrypted, whether its sensitivity merits encryption, location (e.g., whether it on a network, in a particular computer), and for each location, whether it is for ciphertext, for encryption-worthy plaintext, or neither. Rules: encryption-worthy plaintext may only reside in locations designated as encryption worthy; ciphertext may only reside in locations designated as ciphertext worthy. Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found.
Identifier	Export_Control
Descriptive Name	Sanitize data objects containing hidden or unused data
Description	Sanitize data objects that may contain hidden data when they are exported from the TOE in order to inhibit steganographic smuggling.
Selection Guidance
Implementation Application
Editorial	Dependencies: O.Admin_Code_Val_Sten
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: an export-sanitization policy List of subjects, objects, and operations covered by the SFP: objects that may contain hidden data. `Component Application Rationale` - Access control SFP: an export-sanitization policy List of subjects, objects, and operations covered by the SFP: objects that may contain hidden data. FDP_ETC.1 - Export of user data without security attributes `Component Application` - SFP(s): export sanitization. Rule: Apply the sanitization function specified by the sanitization control officer to each exported message, according to its message type. `Component Application Rationale` - SFP(s): export sanitization. Rule: Apply the sanitization function specified by the sanitization control officer to each exported message, according to its message type.
Identifier	External_Labels
Descriptive Name	Label or mark information for external systems
Description	Label or mark information for external systems to prevent the exchange of inappropriate data between systems.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_ETC.2 - Export of user data with security attributes FDP_ITC.2 - Import of user data with security attributes
Identifier	Fail_Secure
Descriptive Name	Preservation of secure state for failures in critical components
Description	Preserve the secure state of the system in the event of a secure component failure.
Selection Guidance	This objective is relevant if the TOE needs to continue some form of operation in the presence of failures. The scope of the identified failures for which the system will fail secure will, in general, directly impact the feasibility and cost of implementing this protection feature.
Implementation Application	Choose FPT_FLS.1 to implement this objective. --- This objective applies to the secure state of the system in its entirety.
Editorial	$
Implementing Components FPT_FLS.1 - Failure with preservation of secure state `Component Application` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. `Component Application Rationale` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1.
Identifier	Fault_Tolerance
Descriptive Name	Provide fault tolerant operations for critical components
Description	Provide fault tolerant operations for critical components and continue to operate in the presence of specific failures in one or more system components.
Selection Guidance	This objective enhances the availability and/or integrity of some or all of the TOE's capabilities. These may be functional capabilities and need not be a part of the TSF, itself. The scope of the identified failures for which the system provides fault tolerance will, in general, directly impact the feasibility and cost of implementing this protection feature.
Implementation Application	There are two variants of this objective (choose one): [Basic]: Choose FRU_FLT.1 [Resistant]: Choose FRU_FLT.2 Choose the [Basic] variant if only some system capabilities need to be fault tolerant to some failures. Choose the [Resistant] variant if all system capabilities need to be fault tolerant to some failures. In general, the [Resistant] variant is much more difficult to implement than the [Basic] variant. --- However, the TSF must guarantee that tolerance (e.g., continuing operation) of the TSF in the presence of the identified failures does not at the expense of the TSF's secure state (see FPT_FLS.1). The types of failures and the related TOE capabilities listed in this component should be strongly correlated with the resultant risk, otherwise the degree of protection provided may be inadequate or not cost effective.
Editorial	$
Implementing Components FRU_FLT.1 - Degraded fault tolerance FRU_FLT.2 - Limited fault tolerance `Component Application` - List the types of failures to which all TOE capabilities are fault tolerant. `Component Application Rationale` - List the types of failures to which all TOE capabilities are fault tolerant.
Identifier	General_Integ_Checks
Descriptive Name	Periodically check integrity
Description	Provide periodic integrity checks on both system and user data.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_SDI.1 - Stored data integrity monitoring `Component Application Editorial` - TOE Requirement. FPT_TST.1 - TSF testing
Identifier	Guarantee_Audit_Stg
Descriptive Name	Guarantee the availability of audit storage space
Description	Maintain audit data and guarantee space for that data.
Selection Guidance	Should user or hacker unauthorized actions potentially cause processes to exceed storage limitations, guaranteeing audit storage space should eliminate service shutdown associated with running out of audit storage space.
Implementation Application
Editorial	<generic objective - may require specialization for use in countering particular attacks>
Implementing Components FAU_STG.2 - Guarantees of audit data availability FAU_STG.3 - Action in case of possible audit data loss
Identifier	Hack_Limit_Sessions
Descriptive Name	Limit sessions to outside users
Description	Limit the number of sessions available to outside users. A hacker can initiate multiple communication sessions that could cause an overload on resources, for example, half open session starts as is seen in "SYN flood" attacks.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Include guidance for the security administrator to reflect the organization's policy for limiting hacker sessions. For example, this guidance would give the administrator information for setting thresholds to counter a "SYN flood" attack. `Component Application Rationale` - Include guidance for the security administrator to reflect the organization's policy for limiting hacker sessions. For example, this guidance would give the administrator information for setting thresholds to counter a "SYN flood" attack. FMT_MSA.1 - Management of security attributes `Component Application` - Apply this component to SFP's dealing with communications ports. For example, the TSF may prevent creation of ports or redirect suspected hacker traffic to a harmless destination for analysis. `Component Application Rationale` - Apply this component to SFP's dealing with communications ports. For example, the TSF may prevent creation of ports or redirect suspected hacker traffic to a harmless destination for analysis. FTA_MCS.2 - Per user attribute limitation on multiple concurrent sessions `Component Application` - Rules for the number of maximum concurrent sessions: The rules might link detected anomalies for a user to concurrent session limits for that user. If the user is discovered to be a hacker then the number of session might potentially be zero. If sending hacker traffic to a "fish bowl" to observe hacker activity then limits may be more than zero but less than an amount that puts a resource burden against legitimate users and services. `Component Application Rationale` - Rules for the number of maximum concurrent sessions: The rules might link detected anomalies for a user to concurrent session limits for that user. If the user is discovered to be a hacker then the number of session might potentially be zero. If sending hacker traffic to a "fish bowl" to observe hacker activity then limits may be more than zero but less than an amount that puts a resource burden against legitimate users and services. FTA_TSE.1 - TOE session establishment `Component Application` - Relevant attributes may be an individual identity, a host identity, a location, or time of day. `Component Application Rationale` - Relevant attributes may be an individual identity, a host identity, a location, or time of day.
Identifier	Hack_Traffic_Control
Descriptive Name	Control hacker communication traffic
Description	Control (e.g. reroute or discard) hacker communication traffic to prevent potential damage.
Selection Guidance	Various kinds of hacker attacks can be detected or prevented by rerouting or discarding suspected hacker traffic. By rerouting hacker communication traffic predictive analysis can be performed to discover potential future hacker attacks.
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_IFC.1 - Subset information flow control `Component Application` - Information flow control SFP: discard policy of hacker traffic `Component Application Rationale` - Information flow control SFP: discard policy of hacker traffic FDP_IFF.1 - Simple security attributes `Component Application` - The TSF shall enforce hacker traffic control in accordance with the hacker traffic control policy. `Component Application Rationale` - The TSF shall enforce hacker traffic control in accordance with the hacker traffic control policy.
Identifier	I&A_Domain
Descriptive Name	Identify and authenticate a user to support accountability
Description	Provide the basic I&A functions that will support user accountability.
Selection Guidance
Implementation Application	Choose FIA_UID.1, FIA_UAU.2, FIA_UAU.7, FIA_ATD.1, FIA_USB.1, and FTA_TAB.1 to implement the objective.
Editorial
Implementing Components FIA_ATD.1 - User attribute definition FIA_UAU.2 - User authentication before any action FIA_UAU.7 - Protected authentication feedback `Component Application` - The list of feedback to the user should be "no meaningful feedback." An specific implementation (e.g., displaying an asterisk for each letter the user types in) that conveys no meaningful feedback is an acceptable refinement of the intent expressed here. `Component Application Rationale` - The list of feedback to the user should be "no meaningful feedback." An specific implementation (e.g., displaying an asterisk for each letter the user types in) that conveys no meaningful feedback is an acceptable refinement of the intent expressed here. FIA_UID.1 - Timing of identification `Component Application` - The TSF shall allow only the display of the TOE's access banner (see FTA_TAB.1) on behalf of the user before the user is identified. `Component Application Rationale` - The TSF shall allow only the display of the TOE's access banner (see FTA_TAB.1) on behalf of the user before the user is identified. FIA_USB.1 - User-subject binding FTA_TAB.1 - Default TOE access banners
Identifier	I&A_Transaction
Descriptive Name	Transaction identification and authentication
Description	Associate each transaction between a user and a system/application with a unique transaction ID, allowing events associated with a given transaction to be distinguished from other events involving the user and/or system/application.
Selection Guidance	Select this objective when it is necessary to recognize when two or more events belong to the same transaction.
Implementation Application
Editorial
Implementing Components FDP_DAU.1 - Basic data authentication `Component Application` - Apply using the events in a transaction as objects. Refine by requiring that authentication involve correct assignment of a transaction identity. `Component Application Rationale` - Apply using the events in a transaction as objects. Refine by requiring that authentication involve correct assignment of a transaction identity.
Identifier	I&A_User
Descriptive Name	Identify and authenticate each user
Description	Uniquely identify and authenticate each user of the system.
Selection Guidance
Implementation Application
Editorial	<specific objective><too simple - just "I" - no "A">
Implementing Components FIA_UID.1 - Timing of identification
Identifier	I&A_User_Action
Descriptive Name	User-action identification and authentication
Description	Associate each user-requested action with the user who requested the action.
Selection Guidance
Implementation Application	$
Editorial	Dependent Objectives: O.Trusted_Path and/or O.Trusted_Channel Treatment of this objective is incomplete. There are a good many more I&A strategies than presented here.
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - The Accounts Administrator shall ensure that each authorized user is assigned a unique user identifier and related authentication data sufficient for user identification and authentication. `Component Application Rationale` - The Accounts Administrator shall ensure that each authorized user is assigned a unique user identifier and related authentication data sufficient for user identification and authentication. AGD_USR.1 - User guidance `Component Application` - Users are responsible for actions required to ensure successful authentication, including protection of any personal authentication data. `Component Application Rationale` - Users are responsible for actions required to ensure successful authentication, including protection of any personal authentication data. FIA_UAU.2 - User authentication before any action FIA_UID.2 - User identification before any action FIA_USB.1 - User-subject binding FMT_MOF.1 - Management of security functions behaviour `Component Application` - Role: Accounts Administrator. Ability: maintenance. Functions: maintain valid user accounts and associate them with authorized users and related authentication data. `Component Application Rationale` - Role: Accounts Administrator. Ability: maintenance. Functions: maintain valid user accounts and associate them with authorized users and related authentication data.
Identifier	Identify_Unusual_Act
Descriptive Name	Identify unusual user activity
Description	Identify unusual user activity on the system.
Selection Guidance	In addition to heuristics aimed at identifying unusual activities, there are a wide variety of preventive measures that can help identify unusual activities as a side effect. For example, suppose that the ability to login is restricted (e.g., via FTA_LSA.1, FTA_MCS.1). Users who attempt to evade these restrictions may be identified, and the need to enforce these restrictions may be evidence of unusual activity by such users.
Implementation Application
Editorial	<specific objective><too simple - may have been changed>
Implementing Components FTA_TSE.1 - TOE session establishment
Identifier	Info_Flow_Control
Descriptive Name	System enforced information flow
Description	Enforce an information flow policy whereby users are constrained from allowing access to information they control, regardless of their intent (e.g., mandatory access control). This lattice property of security attributes is commonly associated with the U.S. DoD implementations of Mandatory Access Control (MAC).
Selection Guidance
Implementation Application	Four variants of this objective exist (choose one). [Subset-Simple] Choose FDP_IFC.1 and FDP_IFF.1. [Subset-Lattice] Choose FDP_IFC.1 and FDP_IFF.2. [Complete-Simple] Choose FDP_IFC.2 and FDP_IFF.1. [Complete-Lattice] Choose FDP_IFC.2 and FDP_IFF.2. Each of the four variants has an FDP_IFC component to define the policy and an FDP_IFF component to describe how the policy is to be enforced. FDP_IFC.1 and FDP_IFC.2 differ in the scope of the information flow policy. FDP_IFF.1 and FDP_IFF.2 differ in the scope of the information flow policy and the structure of the security attributes used. In the latter case, the attribute values must be partially-ordered in a relationship called a "lattice."
Editorial	<generic objective>
Implementing Components FDP_IFC.1 - Subset information flow control FDP_IFC.2 - Complete information flow control FDP_IFF.1 - Simple security attributes FDP_IFF.2 - Hierarchical security attributes
Identifier	Info_Flow_Ctrl_Admin
Descriptive Name	Provide information flow control administration
Description	Manage information flow control policy and functions to allow only specified administrators to have the ability to manipulate the information flow control.
Selection Guidance	This objective is relevant when an administrator could cause misdirected traffic.
Implementation Application
Editorial
Implementing Components FDP_IFC.1 - Subset information flow control `Component Application` - This component should be implemented to provide a policy that would eliminate an administrator from redirecting traffic to an unauthorized location. `Component Application Rationale` - This component should be implemented to provide a policy that would eliminate an administrator from redirecting traffic to an unauthorized location. FDP_IFF.1 - Simple security attributes `Component Application` - This component should implement the information flow to authorized location only. `Component Application Rationale` - This component should implement the information flow to authorized location only. FMT_MOF.1 - Management of security functions behaviour `Component Application` - This management function should be implemented to assure that the Information Flow Control Policy and Information Flow Control Functions can not be bypassed by an administrator attempting to redirect traffic to an unauthorized location. `Component Application Rationale` - This management function should be implemented to assure that the Information Flow Control Policy and Information Flow Control Functions can not be bypassed by an administrator attempting to redirect traffic to an unauthorized location. FMT_SMR.1 - Security roles `Component Application` - This management function should be implemented to assure that the Information Flow Control Policy and Information Flow Control Functions can not be bypassed by an administrator attempting to redirect traffic to an unauthorized location. `Component Application Rationale` - This management function should be implemented to assure that the Information Flow Control Policy and Information Flow Control Functions can not be bypassed by an administrator attempting to redirect traffic to an unauthorized location.
Identifier	Input_Inspection
Descriptive Name	Require inspection for absence of malicious code.
Description	Require inspection of downloads/transfers.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - List of subjects, objects, and operations covered by the SFP: downloaded, executable objects `Component Application Rationale` - List of subjects, objects, and operations covered by the SFP: downloaded, executable objects FDP_ACF.1 - Security attribute based access control `Component Application` - Use this component to specify downloaded executables as a class of objects to be covered by security function requirements. `Component Application Rationale` - Use this component to specify downloaded executables as a class of objects to be covered by security function requirements. FDP_ITC.1 - Import of user data without security attributes `Component Application` - Provide an importation control rule requiring inspection of downloads. `Component Application Rationale` - Provide an importation control rule requiring inspection of downloads.
Identifier	Integ_Data_Mark_Exp
Descriptive Name	Data marking integrity export
Description	Ensure that data markings are included with data that is exported to another trusted product.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_ETC.2 - Export of user data with security attributes
Identifier	Integ_Sys_Data_Ext
Descriptive Name	Integrity of system data transferred externally
Description	Ensure the integrity of system data exchanged externally with another trusted product by using a protocol for data transfer that will permit error detection and correction. This includes detecting and possibly correcting errors in data received and encoding outgoing data to make it possible for the receiver to detect and possibly correct errors. The method for detecting and correcting errors is based on some method (protocol) that is agreed upon by participating parties.
Selection Guidance
Implementation Application
Editorial	[See O.ZSys_Data_Integ_Exch]
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification FPT_ITI.2 - Inter-TSF detection and correction of modification
Identifier	Integ_Sys_Data_Int
Descriptive Name	Integrity of system data transferred internally
Description	Ensure the integrity of system data transferred internally.
Selection Guidance
Implementation Application	Two variants of this objective can be implemented: [CASE-A] Choose FPT_ITT.1 and FPT_SSP.1. [CASE-B] Choose FPT_ITT.1 and FPT_SSP.2. FPT_SSP.1: This component is recommended when the system is distributed. This requirement provides simple acknowledgement by the data recipient. FPT_SSP.2: This component is recommended when the system is distributed. This requirement provides mutual acknowledgement of the data exchange.
Editorial	<generic objective>
Implementing Components FPT_ITT.1 - Basic internal TSF data transfer protection FPT_SSP.1 - Simple trusted acknowledgement FPT_SSP.2 - Mutual trusted acknowledgement
Identifier	Integ_User_Data_Int
Descriptive Name	Protect user data during internal transfer
Description	Ensure the integrity of user data transferred internally within the system.
Selection Guidance
Implementation Application
Editorial	<specific objective><re-do as generic><wrong ID/words - not the integrity components from this family>
Implementing Components FDP_ITT.1 - Basic internal transfer protection FDP_ITT.2 - Transmission separation by attribute
Identifier	Integrity_Attr_Exch
Descriptive Name	Correct attribute exchange with another trusted product
Description	Ensure that the system correctly exchanges security-attribute information with another trusted IT product.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FPT_TDC.1 - Inter-TSF basic TSF data consistency
Identifier	Integrity_Data/SW
Descriptive Name	Integrity protection for user data and software
Description	Provide integrity protection for user data and software.
Selection Guidance
Implementation Application
Editorial	<specific objective><re-do as generic>
Implementing Components FDP_SDI.1 - Stored data integrity monitoring FDP_SDI.2 - Stored data integrity monitoring and action
Identifier	Integrity_Data_Rep
Descriptive Name	Integrity of system data replication
Description	Ensure that when system data replication occurs across the system the data is consistent for each replication.
Selection Guidance	This objective is relevant to a distributed system as well as standalone systems. Ensure that data updates are consistent when one or more parts of a distributed system are not available.
Implementation Application
Editorial	<specific objective>
Implementing Components FPT_TRC.1 - Internal TSF consistency
Identifier	Integrity_Practice
Descriptive Name	Operational integrity system function testing
Description	Provide system functional tests to periodically test the integrity of the hardware and code running system functions.
Selection Guidance
Implementation Application
Editorial	<specific objective>duplicate?>
Implementing Components FPT_AMT.1 - Abstract machine testing FPT_TST.1 - TSF testing
Identifier	IntelEman_Contain
Descriptive Name	Emanations containment
Description	Confine system-produced intelligible emanations to within a specified limit.
Selection Guidance	Select when there is a need to control intelligible emanations in the TOE environment.
Implementation Application	This objective should be allocated to the TOE environment.
Editorial	[assignment: specified limit]
Implementing Components F_PhysEnv_Cnf.1 - Emanations Security `Component Application` - Type of emissions: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives. `Component Application Rationale` - Type of emissions: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Identifier	IntelEman_Control
Descriptive Name	Emanations control
Description	Limit system-produced intelligible emanations to within a specified limit.
Selection Guidance	Select when there is a need to control intelligible emanations before the leave the TOE itself.
Implementation Application	$
Editorial	[assignment: specified limit]. This objective is a minor variant of O.EMSEC_Design.
Implementing Components FPT_PHP_EMSEC_Design - Physical Emanations Security `Component Application` - Types of emissions: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives. `Component Application Rationale` - Types of emissions: intelligible Limits: sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Identifier	InterferEman_Control
Descriptive Name	Emissions interference control
Description	Limit system-produced electromagnetic emanations to within a specified limit.
Selection Guidance	Select when there is danger that the emanations from the TOE may interfere with surrounding equipment.
Implementation Application	$
Editorial	This objective is hierarchical to the O.IntelEman_Control objective.
Implementing Components FDP_ACF.1 - Security attribute based access control `Component Application` - Specify attributes and rules that will (a) constrain subjects that are likely to be malicious from executing code in general, and/or (b) constrain the operations that may be performed on objects (and potentially damage them) to only authorized subjects. `Component Application Rationale` - Specify attributes and rules that will (a) constrain subjects that are likely to be malicious from executing code in general, and/or (b) constrain the operations that may be performed on objects (and potentially damage them) to only authorized subjects. FPT_PHP_EMSEC_Design - Physical Emanations Security `Component Application` - Types of emissions: electromagnetic emissions from TOE and cables. Limits: specify to establish a well-defined limit for emanations. `Component Application Rationale` - Types of emissions: electromagnetic emissions from TOE and cables. Limits: specify to establish a well-defined limit for emanations.
Identifier	Isolate_Executables
Descriptive Name	Isolate untrusted executables
Description	Run executable code in a protected domain where the code's potential errors or malicious code will not significantly impact other system functions of other valid users of the system.
Selection Guidance	For example, in the case of Java applets the protected domain is referred to as a "sandbox".
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - List the objects containing data to be protected by this application of access controls. Ensure that "write" and "delete" (or other damaging) operations are specified for the types of data to be protected. Specified subjects will be those constrained by this application of access controls. `Component Application Rationale` - List the objects containing data to be protected by this application of access controls. Ensure that "write" and "delete" (or other damaging) operations are specified for the types of data to be protected. Specified subjects will be those constrained by this application of access controls. FDP_ACF.1 - Security attribute based access control `Component Application` - Specify attributes and rules that will (a) constrain subjects that are likely to be malicious from executing code in general, and/or (b) constrain the operations that may be performed on objects (and potentially damage them) to only authorized subjects. `Component Application Rationale` - Specify attributes and rules that will (a) constrain subjects that are likely to be malicious from executing code in general, and/or (b) constrain the operations that may be performed on objects (and potentially damage them) to only authorized subjects. FMT_MSA.3 - Static attribute initialisation FPT_SEP.1 - TSF domain separation
Identifier	Lifecycle_Security
Descriptive Name	Lifecycle security
Description	Provide tools, techniques, and security employed during the development phase. Detect and resolve flaws during the operational phase. Provide safe destruction techniques.
Selection Guidance
Implementation Application
Editorial	<specific objective> This objective is dependent on O.Config_Management.
Implementing Components ALC_DVS.1 - Identification of security measures ALC_FLR.1 - Basic flaw remediation ALC_LCD.1 - Developer defined life-cycle model ALC_TAT.1 - Well-defined development tools
Identifier	Limit_Actions_Auth
Descriptive Name	Restrict actions before authentication
Description	Restrict the actions a user may perform before the TOE verifies the identity of the user.
Selection Guidance
Implementation Application
Editorial	<specific objective><just "A" - no "I">
Implementing Components FIA_UAU.1 - Timing of authentication FIA_UAU.2 - User authentication before any action
Identifier	Limit_Comm_Sessions
Descriptive Name	Limit the number of user initiated communication sessions
Description	Provide mechanisms to limit the number of sessions that the user can initiate, if the user initiates multiple sessions that exceed the processors ability to perform in a reliable and efficient manner. These sessions could ether be communication (TCP/IP) sessions or user login sessions.
Selection Guidance	This objective is relevant if the processor can not effectively handle many concurrent sessions. If the processor time and memory are in abundance and will potentially never be overtaxed by multiple concurrent sessions then this objective might not be necessary.
Implementation Application
Editorial	<specific objective><could be generic><close to duplicate of O.Limit_Mult_Sessions>
Implementing Components FTA_MCS.1 - Basic limitation on multiple concurrent sessions `Component Application` - The system should limit the number of multiple sessions to the amount that is expected to maximize any resource utilization. `Component Application Rationale` - The system should limit the number of multiple sessions to the amount that is expected to maximize any resource utilization. FTA_MCS.2 - Per user attribute limitation on multiple concurrent sessions FTA_TSE.1 - TOE session establishment
Identifier	Limit_Mult_Sessions
Descriptive Name	Limit multiple sessions
Description	Provide the capability to limit the number of sessions that a user may have open at one time.
Selection Guidance
Implementation Application
Editorial	<specific objective><redo as generic>
Implementing Components FTA_MCS.1 - Basic limitation on multiple concurrent sessions FTA_MCS.2 - Per user attribute limitation on multiple concurrent sessions
Identifier	Limit_ObserveRoles
Descriptive Name	Limit observation of service usage to authorized users
Description	Provide authorized users with the capability to observe the usage of specified services or resources as necessary to perform their duties.
Selection Guidance	When observation of service or resource usage is limited, choose this objective to mandate which authorized users are exempted from those limitations.
Implementation Application	Choose FPR_UNO.4 to implement the objective.
Editorial	<generic objective>
Implementing Components FPR_UNO.4 - Authorised user observability `Component Application` - List the authorized users that are allowed, given their duties, to observe the use of each service or resource that is protected under this objective. `Component Application Rationale` - List the authorized users that are allowed, given their duties, to observe the use of each service or resource that is protected under this objective.
Identifier	Maintain_Sec_Domain
Descriptive Name	Maintain security domain
Description	Maintain at least one security domain for system (TOE) execution to protect the TOE from interference and tampering.
Selection Guidance
Implementation Application
Editorial	GOAL: Prevent
Implementing Components FPT_SEP.1 - TSF domain separation FPT_SEP.2 - SFP domain separation FPT_SEP.3 - Complete reference monitor
Identifier	Maintenance_Access
Descriptive Name	Controlled access by maintenance personnel
Description	Control access to the system by maintenance personnel who troubleshoot the system and perform system updates.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FMT_MOF.1 - Management of security functions behaviour `Component Application` - Abilities: enable, disable. Functions: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance Administrator. `Component Application Rationale` - Abilities: enable, disable. Functions: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance Administrator. FMT_SMR.1 - Security roles `Component Application` - The authorised identified role: Maintenance Administrator `Component Application Rationale` - The authorised identified role: Maintenance Administrator
Identifier	Maintenance_Recover
Descriptive Name	Expiration of maintenance privileges
Description	Terminate maintenance user system access privilege automatically after expiration of assigned timed interval.
Selection Guidance
Implementation Application
Editorial	<specific objective> Hierarchical to: O.Prvlg_IF_Status
Implementing Components FMT_SAE.1 - Time-limited authorisation `Component Application` - Attributes: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance Administrator `Component Application Rationale` - Attributes: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance Administrator
Identifier	Malicious_Code
Descriptive Name	Procedures for preventing malicious code
Description	Incorporate malicious code prevention procedures and mechanisms.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ITC.1 - Import of user data without security attributes FPT_AMT.1 - Abstract machine testing FPT_PHP.1 - Passive detection of physical attack FPT_TST.1 - TSF testing
Identifier	Manage_Res_Sec_Attr
Descriptive Name	Manage resource security attributes
Description	Provide management on resource security attributes.
Selection Guidance	If a user had the capability to modify attributes of any given resource to the extent that a legitimate user does not have access to that resource this objective should be considered. Examples or relevant resources include data files, communication resources, and other system objects.
Implementation Application
Editorial	<specific objective> A user can modify or add attributes of a resource, which would deny access to the resource for other legitimate users (e.g. - change drive share password). It is paramount that the resource be protected against any user that would cause a denial of a resource based on an attribute modification or addition.
Implementing Components AGD_USR.1 - User guidance `Component Application` - Provide guidance to the user that would define the level of security attribute modification they are allowed and what the ramifications are for violating that policy. `Component Application Rationale` - Provide guidance to the user that would define the level of security attribute modification they are allowed and what the ramifications are for violating that policy. FAU_GEN.1 - Audit data generation `Component Application` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. Maintain an audit trail of resource security attribute modifications or additions. `Component Application Rationale` - Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. Maintain an audit trail of resource security attribute modifications or additions. FMT_MSA.1 - Management of security attributes `Component Application Editorial` - Provide management of the resource attributes that would deny any given user to modify those attributes which would deny legitimate access to the resource.
Identifier	Manage_TSF_Data
Descriptive Name	Manage security-critical data to avoid storage space being exceeded
Description	Manage security-critical (TSF) data to ensure that the size of the data does not exceed the space allocated for storage of the data.
Selection Guidance	Should storage space be limited and a potential exist for a user's unauthorized action cause the storage limits to be exceeded, then specific management of the storage space may be critical. Therefore, management of the storage space is needed.
Implementation Application
Editorial	<specific objective>
Implementing Components FMT_MTD.2 - Management of limits on TSF data `Component Application` - FMT_MTD.2.1/If data storage can be exceeded, the roles of who can modify limits on TSF data should be defined. FMT_MTD2.2/If data storage can be exceeded, the actions required upon storage limits being exceeded should be defined. `Component Application Rationale` - FMT_MTD.2.1/If data storage can be exceeded, the roles of who can modify limits on TSF data should be defined. FMT_MTD2.2/If data storage can be exceeded, the actions required upon storage limits being exceeded should be defined.
Identifier	No_Residual_Info
Descriptive Name	Eliminate residual information
Description	Ensure there is no "object reuse;" i.e., ensure that there is no residual information in some information containers or system resources upon their reallocation to different users.
Selection Guidance
Implementation Application	Select one of FDP_RIP.1 or FDP_RIP.2 to specify the scope of protection against disclosure of residual information.
Editorial	<generic objective>
Implementing Components FDP_RIP.1 - Subset residual information protection `Component Application Editorial` - Select one of FDP_RIP.1 or FDP_RIP.2 to specify the scope of protection against disclosure of residual information. FDP_RIP.2 - Full residual information protection
Identifier	NonRepud_Assess_Recd
Descriptive Name	Non-repudiation support for received information by a nonlocal sender's TSF
Description	Support nonrepudiation for received information by supporting remote handling of nonrepudiation evidence if needed.
Selection Guidance	Use this objective to help ensure that the recipient of a message cannot successfully deny receiving the message from its sender. Complete the operations in a component from the FCO_NRR family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was received. Specify whether the TOE or a remote trusted product requests such evidence.
Implementation Application
Editorial	Objective is stated as if the TOE were remote.
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that remote third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. `Component Application Rationale` - In the event that remote third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. AGD_USR.1 - User guidance `Component Application` - In the event that senders are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. `Component Application Rationale` - In the event that senders are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. FCO_NRR.1 - Selective proof of receipt `Component Application` - Information types: possibly none, as evidence is generated by the receiving TSF. Requestors, recipients of evidence: specify originator, recipient, or third parties. Attributes, Information fields: those supported by the receiving TSF. Limitations on evidence of receipt: TSF must rely on receiving TSF to supply evidence of receipt. `Component Application Rationale` - Information types: possibly none, as evidence is generated by the receiving TSF. Requestors, recipients of evidence: specify originator, recipient, or third parties. Attributes, Information fields: those supported by the receiving TSF. Limitations on evidence of receipt: TSF must rely on receiving TSF to supply evidence of receipt. `Component Application Editorial` - FCO_NRR.2 isn't appropriate here, as it says more about generation of evidence than the TOE is able to enforce. FMT_MOF.1 - Management of security functions behaviour `Component Application` - In the case where nonlocal third parties are involved in handling nonrepudiation evidence, provide identified roles for those parties. `Component Application Rationale` - In the case where nonlocal third parties are involved in handling nonrepudiation evidence, provide identified roles for those parties.
Identifier	NonRepud_Assess_Sent
Descriptive Name	Non-repudiation support for sent information by the nonlocal receiving TSF.
Description	Support nonrepudiation for sent information by supporting remote handling of nonrepudiation evidence if needed.
Selection Guidance	Use this objective to ensure that the sender of a message cannot successfully deny sending the message. Complete the operations in a component from the FCO_NRO family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was sent. Specify whether the TOE or a remote trusted product requests such evidence.
Implementation Application
Editorial	Objective is stated as if the TOE were remote.
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that nonrepudiation evidence is handled by remote third parties, provide documentation on the responsibilities of those who handle this evidence. `Component Application Rationale` - In the event that nonrepudiation evidence is handled by remote third parties, provide documentation on the responsibilities of those who handle this evidence. AGD_USR.1 - User guidance `Component Application` - In the event that nonrepudiation evidence is handled by the message recipient, provide user documentation on the use of nonrepudiation features. `Component Application Rationale` - In the event that nonrepudiation evidence is handled by the message recipient, provide user documentation on the use of nonrepudiation features. FCO_NRO.1 - Selective proof of origin `Component Application` - Transmitted information types: possibly none, as the TOE must rely on the sending TSF for generated evidence. Requestors, Recipients of evidence: specify originator, recipient, or third parties. Attributes, information fields: those supported by the sending TSF. Limitations on the evidence of origin: The TOE must rely on the sending TSF for evidence of message generation. `Component Application Rationale` - Transmitted information types: possibly none, as the TOE must rely on the sending TSF for generated evidence. Requestors, Recipients of evidence: specify originator, recipient, or third parties. Attributes, information fields: those supported by the sending TSF. Limitations on the evidence of origin: The TOE must rely on the sending TSF for evidence of message generation. `Component Application Editorial` - FCO_NRO.2 isn't appropriate here, as it says more about generation of evidence than the TOE is able to enforce. FMT_MOF.1 - Management of security functions behaviour `Component Application` - If nonrepudiation is handled by remote third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions. `Component Application Rationale` - If nonrepudiation is handled by remote third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions.
Identifier	NonRepud_Gen_Recd
Descriptive Name	Non-repudiation support for received information by the recipient's TSF
Description	Prevent a receiving user from avoiding accountability for receiving a message by providing evidence that the user received the message.
Selection Guidance	Use this objective to ensure that the recipient of a message cannot successfully deny receiving the message. Complete the operations in a component from the FCO_NRR family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was received. Specify whether the TOE or a remote trusted product requests such evidence.
Implementation Application	The objective has multiple implementations. Using FCO_NRR.2 is a special case of using FCO_NRR.1 and may be stronger. FMT_MOF.1 and AGD_ADM.1 are needed if threat countering is to be performed by third parties using the same system as the recipient.
Editorial
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. `Component Application Rationale` - In the event that third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. FCO_NRR.1 - Selective proof of receipt `Component Application` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FCO_NRR.2 - Enforced proof of receipt `Component Application` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FMT_MOF.1 - Management of security functions behaviour `Component Application` - In the event that third parties are involved in enforcing nonrepudiation, provide identified roles for these parties. `Component Application Rationale` - In the event that third parties are involved in enforcing nonrepudiation, provide identified roles for these parties.
Identifier	NonRepud_Gen_Sent
Descriptive Name	Non-repudiation support for sent information by the sender's TSF.
Description	Prevent a user from avoiding accountability for sending a message to a recipient at a different site by providing evidence that the user sent the message.
Selection Guidance	Use this objective to ensure that the sender of a message cannot successfully deny sending the message. Complete the operations in a component from the FCO_NRO family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was sent. Specify whether the TOE or a remote trusted product requests such evidence.
Implementation Application	The objective has multiple implementations. Using FCO_NRO.2 is a special case of using FCO_NRO.1 and may be stronger. FMT_MOF.1 and AGD_ADM.1 are needed only if threat countering is to be performed by third parties (i.e., people other than the recipient).
Editorial
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that nonrepudiation evidence is handled by third parties at the sender's system, provide documentation on the responsibilities of those who handle this evidence. `Component Application Rationale` - In the event that nonrepudiation evidence is handled by third parties at the sender's system, provide documentation on the responsibilities of those who handle this evidence. FCO_NRO.1 - Selective proof of origin `Component Application` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FCO_NRO.2 - Enforced proof of origin `Component Application` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FMT_MOF.1 - Management of security functions behaviour `Component Application` - If nonrepudiation is handled by third parties at the sender's system, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who use the nonrepudiation functions. `Component Application Rationale` - If nonrepudiation is handled by third parties at the sender's system, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who use the nonrepudiation functions.
Identifier	NonRepud_Locals_Rcvd
Descriptive Name	Non-repudiation for received information, local users
Description	Prevent user from avoiding accountability for receiving a message from another user on the same system by providing evidence that the user received the message.
Selection Guidance	Use this objective to ensure that the recipient of a message cannot successfully deny receiving the message.
Implementation Application	The objective has multiple implementations. Using FCO_NRR.2 is a special case of using FCO_NRR.1 and may be stronger. FMT_MOF.1 is needed only if threat countering is to be performed by third parties (i.e., people other than the sender). Impose additional requirements, e.g., FDP_ITT.1 in order to strengthen nonrepudiation by ruling out the possibility that the message received differs from the message that was sent.
Editorial
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. `Component Application Rationale` - In the event that third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. AGD_USR.1 - User guidance `Component Application` - In the event that senders are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. `Component Application Rationale` - In the event that senders are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions. FCO_NRR.1 - Selective proof of receipt `Component Application` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FCO_NRR.2 - Enforced proof of receipt `Component Application` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FDP_ITT.1 - Basic internal transfer protection `Component Application` - Enforce an SFP that prevents modification of user data. (However, note that this requirement, on the one hand, applies to all data rather than just nonrepudiation data, and on the other, applies only to data transmitted between separate parts of the TOE – some alteration may be needed.) `Component Application Rationale` - Enforce an SFP that prevents modification of user data. (However, note that this requirement, on the one hand, applies to all data rather than just nonrepudiation data, and on the other, applies only to data transmitted between separate parts of the TOE – some alteration may be needed.) FMT_MOF.1 - Management of security functions behaviour `Component Application` - Provide identified roles for the parties who determine the use of nonrepudiation functions. `Component Application Rationale` - Provide identified roles for the parties who determine the use of nonrepudiation functions.
Identifier	NonRepud_Locals_Sent
Descriptive Name	Non-repudiation for sent information, local users
Description	Prevent user from avoiding accountability for sending a message to another user on the same system by providing evidence that the user sent the message.
Selection Guidance	Use this objective to ensure that the sender of a message cannot successfully deny sending the message. Complete the operations in a component from the FCO_NRO family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was sent. Specify whether the TOE or a remote trusted product requests such evidence.
Implementation Application	The objective has multiple implementations. Using FCO_NRO.2 is a special case of using FCO_NRO.1 and may be stronger. FMT_MOF.1 is needed only if threat countering is to be performed by third parties (i.e., people other than the recipient). FDP_ITT.1 strengthens nonrepudiation by ruling out the possibility that a different message is received than was sent.
Editorial
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - In the event that nonrepudiation evidence is handled by third parties, provide user documentation on the responsibilities of those who handle this evidence. `Component Application Rationale` - In the event that nonrepudiation evidence is handled by third parties, provide user documentation on the responsibilities of those who handle this evidence. AGD_USR.1 - User guidance `Component Application` - In the event that nonrepudiation evidence is handled by the message recipient, provide user documentation on the use of nonrepudiation features. `Component Application Rationale` - In the event that nonrepudiation evidence is handled by the message recipient, provide user documentation on the use of nonrepudiation features. FCO_NRO.1 - Selective proof of origin `Component Application` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FCO_NRO.2 - Enforced proof of origin `Component Application` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. `Component Application Rationale` - List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided. FDP_ITT.1 - Basic internal transfer protection `Component Application` - Enforce an SFP that prevents modification of user data. (However, note that this requirement, on the one hand, applies to all data rather than just nonrepudiation data, and on the other, applies only to data transmitted between separate parts of the TOE – some alteration may be needed.) `Component Application Rationale` - Enforce an SFP that prevents modification of user data. (However, note that this requirement, on the one hand, applies to all data rather than just nonrepudiation data, and on the other, applies only to data transmitted between separate parts of the TOE – some alteration may be needed.) FMT_MOF.1 - Management of security functions behaviour `Component Application` - If nonrepudiation is handled by third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions. `Component Application Rationale` - If nonrepudiation is handled by third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions.
Identifier	NonRepudiate_Recd
Descriptive Name	Non-repudiation for received information
Description	Provide evidence that a user received information.
Selection Guidance	This objective is relevant when a user must be held accountable for having received information that has been delivered to that user (e.g., a message).
Implementation Application	Choose either FCO_NRR.1 or FCO_NRR.2 (but not both) for each application of this objective. ---- FCO_NRR.1: Choose this component when the application requiring evidence of receipt does not always require the evidence, but when one or more of the parties may selectively invoke the generation of evidence on a case-by-case basis. ---- FCO_NRR.2: Choose this component when the application requiring evidence of receipt must always generate the evidence.
Editorial	<generic objective>
Implementing Components FCO_NRR.1 - Selective proof of receipt FCO_NRR.2 - Enforced proof of receipt
Identifier	NonRepudiate_Sent
Descriptive Name	Non-repudiation for sent information
Description	Provide evidence that a user sent information.
Selection Guidance	This objective is relevant when a user must be held accountable for having sent a specific instance of information (e.g., a message).
Implementation Application	Choose either FCO_NRO.1 or FCO_NRO.2 (but not both) for each application of this objective. ---- FCO_NRO.1: Choose this component when the application requiring evidence of origin does not always require the evidence, but when one or more of the parties may selectively invoke the generation of evidence on a case-by-case basis. ---- FCO_NRO.2: Choose this component when the application requiring evidence of origin must always generate the evidence.
Editorial	<generic objective>
Implementing Components FCO_NRO.1 - Selective proof of origin FCO_NRO.2 - Enforced proof of origin
Identifier	Obj_Attr_Integrity
Descriptive Name	Basic object attribute integrity
Description	Maintain object security attributes with moderate to high accuracy (under the guidance of qualified users).
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: attribute-management policy List of subjects, objects, and operations covered by the SFP: those objects covered by other SFPs; attribute-maintenance operations, characterized by their ability to modify security attributes incorrectly; those subjects capable of applying attribute-maintenance operations, referred to as attribute-maintenance subjects `Component Application Rationale` - Access control SFP: attribute-management policy List of subjects, objects, and operations covered by the SFP: those objects covered by other SFPs; attribute-maintenance operations, characterized by their ability to modify security attributes incorrectly; those subjects capable of applying attribute-maintenance operations, referred to as attribute-maintenance subjects FDP_ACF.1 - Security attribute based access control `Component Application` - Access control SFP: attribute management Security attributes: object owner (a.k.a. object-attribute manager) Rules governing access: only an object owner may apply attribute-maintenance operations to that object, and only via attribute-maintenance subjects acting on that user's behalf; all attribute-maintenance subjects are certified to reflect user intent when modifying object attributes. `Component Application Rationale` - Access control SFP: attribute management Security attributes: object owner (a.k.a. object-attribute manager) Rules governing access: only an object owner may apply attribute-maintenance operations to that object, and only via attribute-maintenance subjects acting on that user's behalf; all attribute-maintenance subjects are certified to reflect user intent when modifying object attributes. FMT_MSA.1 - Management of security attributes `Component Application` - Role: data security administrator. Ability: change_default, modify, delete attributes. `Component Application Rationale` - Role: data security administrator. Ability: change_default, modify, delete attributes. FMT_MSA.2 - Secure security attributes FMT_MSA.3 - Static attribute initialisation `Component Application` - Policy: attribute-management. Default values: safe values - determined separately for each attribute per its associated SFP. Roles authorized to specify initial values for object data and attributes: TOE developer and/or the TOE data security administrator. `Component Application Rationale` - Policy: attribute-management. Default values: safe values - determined separately for each attribute per its associated SFP. Roles authorized to specify initial values for object data and attributes: TOE developer and/or the TOE data security administrator. FMT_SMR.1 - Security roles `Component Application` - The authorised identified role: data security administrator. `Component Application Rationale` - The authorised identified role: data security administrator.
Identifier	Obj_Protection
Descriptive Name	Object domain protection
Description	Require domain protection for objects. Specify object classes (domains), user groups, and operation classes. Use these to specify which operations may be performed on which objects by which users. Basically this controls what users can do in a given group.
Selection Guidance	This differs from traditional access control policy. In traditional access control policies there is a separate object class for each object, and there are just three operation classes: read, write, and execute.
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - List of subjects, objects, and operations covered by the SFP: any modifications to trusted objects must be by trusted subjects `Component Application Rationale` - List of subjects, objects, and operations covered by the SFP: any modifications to trusted objects must be by trusted subjects FDP_ACF.1 - Security attribute based access control `Component Application` - Limit ability to modify trusted objects to a trusted role `Component Application Rationale` - Limit ability to modify trusted objects to a trusted role FMT_MSA.3 - Static attribute initialisation `Component Application` - Create a trusted role for the maintenance of trusted objects. `Component Application Rationale` - Create a trusted role for the maintenance of trusted objects.
Identifier	Permit_Aliases
Descriptive Name	Permit users to use services under aliases
Description	Permit some users to maintain partial anonymity when using specified services or resources by means of aliases.
Selection Guidance	The intent of this objective is to ensure that a user may use a service or resource without disclosing the user's identity, but can still be accountable for that use. This objective allows subject activity to be tracked without necessarily associating subjects with users.
Implementation Application	There are three variants of this objective (choose one): [Basic]: Choose FPR_PSE.1 [Reversible]: Choose FPR_PSE.2. [Reusable]: Choose FPR_PSE.3. --- The [Reversible] and [Reusable] variants add limited accountability to the [Basic] variant.
Editorial	<generic objective>
Implementing Components FPR_PSE.1 - Pseudonymity FPR_PSE.2 - Reversible pseudonymity FPR_PSE.3 - Alias pseudonymity
Identifier	Permit_Anonymity
Descriptive Name	Permit users to use services anonymously
Description	Permit some users to maintain anonymity when using specified services or resources.
Selection Guidance	The intent of this objective is to ensure that a user may use a service or resource without disclosing the user's identity. This objective can be used to ensure that the system provides some services anonymously for some users.
Implementation Application	There are two variants of this objective (choose one): [Basic]: Choose FPR_ANO.1. [Enhanced]: Choose FPR_ANO.2.
Editorial	<generic objective>
Implementing Components FPR_ANO.1 - Anonymity FPR_ANO.2 - Anonymity without soliciting information
Identifier	Prevent_AskPrivInfo
Descriptive Name	Prevent system from collecting user privacy information
Description	Provide some services or resources to specified users without soliciting from the user information that is relevant to the user's privacy.
Selection Guidance	The intent of this objective is to permit users to use services without being observed by preventing the IT system or product from soliciting information that might be used to compromise users' privacy.
Implementation Application	Choose FPR_UNO.3 to implement the objective.
Editorial	<generic objective>
Implementing Components FPR_UNO.3 - Unobservability without soliciting information
Identifier	Prevent_Link
Descriptive Name	Prevent linking of multiple service use
Description	Ensure that a user may make multiple uses of a service or resource without other specified users being able to link these uses together.
Selection Guidance	The intent of this objective is to protect the user identity against the use of profiling of operations.
Implementation Application	Choose FPR_UNL.1 to implement the objective.
Editorial	$
Implementing Components FPR_UNL.1 - Unlinkability
Identifier	Prevent_Observe
Descriptive Name	Prevent observation of service use
Description	Ensure that a user may use a service or resource without other specified users being able to observe that the service or resource is being used.
Selection Guidance	This objective is relevant when the system (TOE) is required to protect the privacy of users.
Implementation Application	There are two variants of this objective (choose one): [Basic]: Choose FPR_UNO.1. [Distribution]: Choose FPR_UNO.2. --- FPR_UNO.2 is generally more effective than FPR_UNO.1 given appropriate implementation.
Editorial	<generic objective>
Implementing Components FPR_UNO.1 - Unobservability FPR_UNO.2 - Allocation of information impacting unobservability
Identifier	Priority_Of_Service
Descriptive Name	Provide priority of service
Description	Control access to resources so that lower-priority activities do not unduly interfere with or delay higher-priority activities.
Selection Guidance	This objective is needed when a potential exists for a shareable resource to be overburdened. Note that any user and any threat agent potentially overloads resources.
Implementation Application	FRU_PRS.1 applied on a specific resource should provide protection for critical subjects and services that require that specific resource. FRU_PRS.2 applied against all resources should provide higher reliability for critical subject(s) and service(s) to receive the resources that they require. The specific source (threat agent and method of attack) should be used as a guide to determine the usage of the requirements used to apply priority of service to the resource being overloaded or impacted.
Editorial	<generic objective>
Implementing Components FRU_PRS.1 - Limited priority of service `Component Application` - The resource(s) and subject(s) related to the detailed attack should be identified as the resource upon which priority of service is enforced. `Component Application Rationale` - The resource(s) and subject(s) related to the detailed attack should be identified as the resource upon which priority of service is enforced. FRU_PRS.2 - Full priority of service `Component Application` - All sharable resources should be subjected to priority of service as the specific resource being attacked may effect other sharable resources. `Component Application Rationale` - All sharable resources should be subjected to priority of service as the specific resource being attacked may effect other sharable resources.
Identifier	Prvlg_IF_Status
Descriptive Name	Privileged-interface status
Description	Provide capability for an administrator to determine the use status of all privileged interfaces. This would include interfaces used by maintenance personnel.
Selection Guidance
Implementation Application
Editorial	<specific objective> Hierarchical to: O.Maintenance_Access
Implementing Components FMT_MTD.1 - Management of TSF data `Component Application` - Ability: query. TSF data: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance administrator `Component Application Rationale` - Ability: query. TSF data: Vendor access privileges (e.g., use of "Trap doors"). Role: Maintenance administrator
Identifier	Rcv_MsgMod_ID
Descriptive Name	Identify message modification in messages received
Description	The TSF recognizes changes to messages that occurred in transit, including insertion of spurious messages and deletion or replay of legitimate messages.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_UIT.1 - Data exchange integrity `Component Application` - TOE: Specify received Environment: Specify sent `Component Application Rationale` - TOE: Specify received Environment: Specify sent
Identifier	Rcv_MsgMod_Rcvr
Descriptive Name	Recovery from modification of received messages
Description	The TSF detects and corrects changes in messages received from a remote trusted site.
Selection Guidance	Choose FDP_UIT.1 and either FDP_UIT.2 or FDP_UIT.3. FDP_UIT.3 provides less dependence on the environment.
Implementation Application
Editorial	Hierarchical to: O.Rcv_MsgMod_ID_Loc
Implementing Components FDP_UIT.1 - Data exchange integrity `Component Application` - TOE: specify receive messages Environment: Specify send messages. If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the environment to include retransmission of damaged messages. `Component Application Rationale` - TOE: specify receive messages Environment: Specify send messages. If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the environment to include retransmission of damaged messages. FDP_UIT.2 - Source data exchange recovery FDP_UIT.3 - Destination data exchange recovery
Identifier	React_Discovered_Atk
Descriptive Name	React to discovered attacks
Description	Implement automated notification or other reactions to the TSF-discovered attacks in an effort to identify attacks and to create an attack deterrent.
Selection Guidance	This objective is relevant if actions that the organization deems essential also pose a potential attack that could be exploited. Of particular interest for discovering attacks would be application of mapped components to failures in the following functions: FIA_AFL.1, FPT_RPL.1, FTA_LSA.1, FDP_IFF.1, FDP_ACF.1.
Implementation Application
Editorial	<specific objective>
Implementing Components AGD_ADM.1 - Administrator guidance FAU_ARP.1 - Security alarms FAU_SAA.1 - Potential violation analysis
Identifier	Reference_Monitor
Descriptive Name	Provide reference monitor
Description	Always invoke mechanisms that enforce security policies (i.e., as for a traditional reference monitor).
Selection Guidance
Implementation Application
Editorial	GOAL: Prevent
Implementing Components FPT_RVM.1 - Non-bypassability of the TSP
Identifier	Remote_Execution
Descriptive Name	Disable remote execution
Description	Disable a remote entity's ability to execute local code.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_ACC.1 - Subset access control FDP_ACF.1 - Security attribute based access control
Identifier	Resource_Quotas
Descriptive Name	Resource quotas for users and services
Description	Use resource quotas to limit user and service use of system resources to a level that will prevent degradation or denial of service to other critical users and services.
Selection Guidance	If resources are subject to overload due to a subject or service using more than it's share of the resource this objective should be used. This is relevant for a potential user misuse or hacker Denial of Service attack. Both component choices are preventative, although they may also facilitate detection and/or recovery features. FRU_RSA.1 is a simpler form of quota mechanism use. FRU_RSA.2 builds on the functionality of FRU_RSA.1 with the additional of minimum use quotas, which is important availability and guaranteed service considerations. In general, FRU_RSA.2 would be much more difficult to ensure than FRU_RSA.1.
Implementation Application
Editorial	<generic objective>
Implementing Components FRU_RSA.1 - Maximum quotas `Component Application` - A maximum resource quota should be applied toward the threat agent causing the resource overload. `Component Application Rationale` - A maximum resource quota should be applied toward the threat agent causing the resource overload. FRU_RSA.2 - Minimum and maximum quotas `Component Application` - Should services require minimum resources to operate, both minimum and maximum quotas should be set so the threat agent invoking a service that potentially overloads a resource does not overload that resource and critical services have enough resources to operate. `Component Application Rationale` - Should services require minimum resources to operate, both minimum and maximum quotas should be set so the threat agent invoking a service that potentially overloads a resource does not overload that resource and critical services have enough resources to operate.
Identifier	Robust_Encryption
Descriptive Name	Robust encryption
Description	Produce cipher text that cannot be decrypted without either massive computational power or knowledge of the encryption key through robust encryption techniques.
Selection Guidance	This objective captures the PP authors' preferences for encryption techniques. Evaluation of the objective does not cover inherent strength of encryption.
Implementation Application
Editorial	<specific objective> This objective might better be listed as, or accompanied by an assumption regarding what passes for sufficiently strong encryption. Larger keys make encryption more difficult. The degree of redundancy in the associated plaintext and the size of the plaintext may have bearing here as well. Frequent key replacement minimizes the damage done by an attacker who discovers a key.
Implementing Components FCS_CKM.1 - Cryptographic key generation `Component Application` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. `Component Application Rationale` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. FCS_CKM.2 - Cryptographic key distribution `Component Application` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. `Component Application Rationale` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. FCS_CKM.3 - Cryptographic key access `Component Application` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. `Component Application Rationale` - Complete this component's operations in a manner compatible with the associated FCS_COP.1 component. FCS_COP.1 - Cryptographic operation `Component Application` - Complete this component's operations in a manner compatible with the associated FCS_CKM components. List of cryptographic operations: general encryption function `Component Application Rationale` - Complete this component's operations in a manner compatible with the associated FCS_CKM components. List of cryptographic operations: general encryption function
Identifier	Rollback
Descriptive Name	Rollback
Description	Recover from user operations by undoing some user operations (i.e., "rolling back") to restore a previous known state.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components FDP_ROL.1 - Basic rollback FDP_ROL.2 - Advanced rollback
Identifier	Screen_Lock
Descriptive Name	User screen locking
Description	Provide a screen lock function to prevent an unauthorized user from using an unattended computer where a valid user has an active session.
Selection Guidance
Implementation Application
Editorial	<generic objective><missing third component in family - separate objective>
Implementing Components FTA_SSL.1 - TSF-initiated session locking FTA_SSL.2 - User-initiated locking
Identifier	Secure_Configuration
Descriptive Name	Security-relevant configuration management
Description	Manage and update system security policy data and enforcement functions, and other security-relevant configuration data, in accordance with organizational security policies.
Selection Guidance
Implementation Application	All the FMT components here are preventive and enable secure configuration management. FMT_MTD.1 will almost always be required to satisfy this objective, as it provides the capability for system administrators to manage the configuration of the system. FMT_MOF.1 will be relevant for those functions whose behavior is determined by configuration data (e.g., security policy enforcement). AGD_ADM.1 is required to support either of the FMT components.
Editorial	<specific objective>
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Administrative guidance will need to describe configuration options and to perform secure modifications to configuration data. `Component Application Rationale` - Administrative guidance will need to describe configuration options and to perform secure modifications to configuration data. FMT_MOF.1 - Management of security functions behaviour `Component Application` - All TSF functions whose behavior is determined by configuration data should be specified, along with permitted operations and those roles that the system will allow to perform those operations. `Component Application Rationale` - All TSF functions whose behavior is determined by configuration data should be specified, along with permitted operations and those roles that the system will allow to perform those operations. FMT_MTD.1 - Management of TSF data `Component Application` - All TSF data that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations. `Component Application Rationale` - All TSF data that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations.
Identifier	Secure_State
Descriptive Name	Protect and maintain secure system state
Description	Maintain and recover to a secure state without security compromise after system error or other interruption of system operation.
Selection Guidance	There are tradeoffs between functions that fail secure and those in which failures can be recovered from securely.
Implementation Application	In applying this objective, provide a secure state definition that captures the notion of being able to enforce the TSP. If the TSP isn't conveniently described in terms of a secure-state model, the PP author may wish to introduce a CC-extending component that recasts FPT_RCV to accommodate the PP's TSP description.
Editorial	<specific objective><redo as generic combo>
Implementing Components FPT_FLS.1 - Failure with preservation of secure state FPT_RCV.1 - Manual recovery FPT_RCV.2 - Automated recovery FPT_RCV.3 - Automated recovery without undue loss FPT_RCV.4 - Function recovery
Identifier	Security_Attr_Mgt
Descriptive Name	Manage security attributes
Description	Manage the initialization of, values for, and allowable operations on security attributes.
Selection Guidance
Implementation Application	Three variants of this objective exist (choose any): [Restrict]: Choose FMT_MSA.1. [Secure]: Choose FMT_MSA.2. [Init]: Choose FMT_MSA.3.
Editorial	<generic objective><redo formulation>
Implementing Components FMT_MSA.1 - Management of security attributes FMT_MSA.2 - Secure security attributes FMT_MSA.3 - Static attribute initialisation
Identifier	Security_Data_Mgt
Descriptive Name	Manage security-critical data
Description	Manage the initialization of, limits on, and allowable operations on security-critical data.
Selection Guidance
Implementation Application	Three variants of this objective exist (choose any): [Restrict]: Choose FMT_MTD.1. [Limits]: Choose FMT_MTD.2. [Secure]: Choose FMT_MTD.3.
Editorial	<generic>
Implementing Components FMT_MTD.1 - Management of TSF data FMT_MTD.2 - Management of limits on TSF data FMT_MTD.3 - Secure TSF data
Identifier	Security_Func_Mgt
Descriptive Name	Manage behavior of security functions
Description	Provide management mechanisms for security mechanisms.
Selection Guidance
Implementation Application	Choose FMT_MOF.1 to implement this objective.
Editorial	<generic objective><redo formulation>
Implementing Components FMT_MOF.1 - Management of security functions behaviour
Identifier	Security_Roles
Descriptive Name	Security roles
Description	Maintain security-relevant roles and the association of users with those roles.
Selection Guidance	Select this objective whenever it is necessary to define one or more security roles.
Implementation Application	Two variants of this objective exist. [Basic] Choose FMT_SMR.1. This variation provides the basic capability to define different roles among users of the system. [Restricted] Choose FMT_SMR.2. This variation provides the additional capability of placing constraints on use of the defined roles within the system.
Editorial
Implementing Components FMT_SMR.1 - Security roles FMT_SMR.2 - Restrictions on security roles
Identifier	Session_Termination
Descriptive Name	System terminates session for inactivity
Description	System terminates a session after a given interval of inactivity.
Selection Guidance	$
Implementation Application	Choose FTA_SSL.3 to implement the objective.
Editorial
Implementing Components FTA_SSL.3 - TSF-initiated termination
Identifier	Snt_MsgMod_ID
Descriptive Name	Identify message modification in messages sent
Description	The TSF supports recognition of changes to transmitted messages that occurred in transit, including insertion of spurious messages and deletion or replay of legitimate messages.
Selection Guidance
Implementation Application
Editorial
Implementing Components FDP_UIT.1 - Data exchange integrity `Component Application` - TOE: Specify received Environment: Specify sent `Component Application Rationale` - TOE: Specify received Environment: Specify sent
Identifier	Snt_MsgMod_Rcvr
Descriptive Name	Support recovery from modification of sent messages
Description	The TSF supports detection and correction changes in messages sent to a remote trusted site.
Selection Guidance	Choose FDP_UIT.1 and either FDP_UIT.2 or FDP_UIT.3. FDP_UIT.3 provides less dependence on the environment.
Implementation Application
Editorial	Hierarchical to: O.Rcv_MsgMod_ID_Loc
Implementing Components FDP_UIT.1 - Data exchange integrity `Component Application` - Environment: specify receive messages TOE: Specify send messages. If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the TOE to include retransmission of damaged messages. `Component Application Rationale` - Environment: specify receive messages TOE: Specify send messages. If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the TOE to include retransmission of damaged messages. FDP_UIT.2 - Source data exchange recovery `Component Application` - Allocate to the Environment. `Component Application Rationale` - Allocate to the Environment. FDP_UIT.3 - Destination data exchange recovery `Component Application` - Allocate to the Encvironment. `Component Application Rationale` - Allocate to the Encvironment.
Identifier	Source_Code_Exam
Descriptive Name	Examine the source code for developer flaws
Description	Examine for accidental or deliberate flaws in code made by the developer. The accidental flaws could be lack of engineering detail or bad design. Where the deliberate flaws would include building trapdoors for later entry as an example.
Selection Guidance	This objective will not fully ensure that code is not flawed in some manner. The flaws may not be noticed until actual execution of the code.
Implementation Application
Editorial	<specific objective> This objective would be a non-IT objective where code examination would most likely require a human to look at the code.
Implementing Components ADV_IMP.1 - Subset of the implementation of the TSF `Component Application` - Refine: The evaluators need to identify a subset of the source code for examination. `Component Application Rationale` - Refine: The evaluators need to identify a subset of the source code for examination. ADV_LLD.1 - Descriptive low-level design ADV_RCR.1 - Informal correspondence demonstration
Identifier	Storage_Integrity
Descriptive Name	Storage integrity
Description	Provide integrity for data.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_SDI.1 - Stored data integrity monitoring
Identifier	Sys_Access_Banners
Descriptive Name	System access banners
Description	Inform the user of the possibility of the system monitoring his actions, and that misuse of the system may result in criminal or civil penalties.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components FTA_TAB.1 - Default TOE access banners
Identifier	Sys_Assur_HW/SW/FW
Descriptive Name	Validation of security function
Description	Ensure that security-relevant software, hardware, and firmware are correctly functioning through features and procedures.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components ATE_FUN.1 - Functional testing FPT_TST.1 - TSF testing
Identifier	Sys_Backup_Procs
Descriptive Name	System backup procedures
Description	Provide backup procedures to ensure that the system can be reconstructed.
Selection Guidance
Implementation Application
Editorial	<specific objective><duplicate?><redo as call to generic?>
Implementing Components FPT_RCV.1 - Manual recovery FPT_RCV.2 - Automated recovery FPT_RCV.3 - Automated recovery without undue loss
Identifier	Sys_Backup_Restore
Descriptive Name	Frequent backups to prevent minimal loss
Description	Provide through frequent backups, restoration of security-relevant changes to the system between backup and restore, and restoration of the security-relevant system state (e.g. access control list) without destruction of other system data.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FMT_MOF.1 - Management of security functions behaviour `Component Application` - Apply this component in such a way as to address frequency of system backup and restoration. `Component Application Rationale` - Apply this component in such a way as to address frequency of system backup and restoration. FMT_MTD.1 - Management of TSF data `Component Application` - Apply this component in such a way as to address frequency of system backup and restoration. `Component Application Rationale` - Apply this component in such a way as to address frequency of system backup and restoration.
Identifier	Sys_Backup_Storage
Descriptive Name	Sufficient backup storage and effective restoration
Description	Provide sufficient backup storage and effective restoration to ensure that the system can be recreated.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FMT_MOF.1 - Management of security functions behaviour `Component Application` - Apply this component in such a way as to achieve operational system backup and restoration. `Component Application Rationale` - Apply this component in such a way as to achieve operational system backup and restoration. FMT_MTD.1 - Management of TSF data `Component Application` - Apply this component in such a way as to achieve operational system backup and restoration. `Component Application Rationale` - Apply this component in such a way as to achieve operational system backup and restoration.
Identifier	Sys_Backup_Verify
Descriptive Name	Detect modifications of backup hardware, firmware, software
Description	Detect modifications to backup hardware, firmware, and software.
Selection Guidance
Implementation Application	The component FPT_PHP.1 would be used to provide the physical protection of the backup hardware, firmware, and software. The components FPT_TST.1 and FPT_AMT.1 would be used to test whether the secure state of the backup hardware, firmware, and software is maintained and restored if necessary.
Editorial	<specific objective>
Implementing Components FPT_AMT.1 - Abstract machine testing FPT_PHP.1 - Passive detection of physical attack FPT_TST.1 - TSF testing
Identifier	Sys_Self_Protection
Descriptive Name	Protection of system security function
Description	Protect the system security functions through technical features.
Selection Guidance
Implementation Application
Editorial	<generic objective><for generic, missing 3rd component>
Implementing Components FPT_SEP.1 - TSF domain separation FPT_SEP.2 - SFP domain separation
Identifier	Tamper_ID
Descriptive Name	Tamper detection
Description	Provide system features that detect physical tampering of a system component, and use those features to limit security breaches.
Selection Guidance	O.Tamper_ID provides capabilities to detect physical attacks against specified parts of the TOE.
Implementation Application	Two variations of this objective exist (choose one). [Detect] This variation provides basic capabilities to detect physical tampering attacks. It relies more on user responsibility to follow procedures for identifying and acting upon detected physical tampering attacks. [Notify] This variant increases TOE responsibility and decreases user responsibility, because the TSF alerts a designated individual when it has been tampered with.
Editorial	<generic objective> The O.Tamper_Resistance objective may also be relevant.
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Explain how to detect and report physical tampering or errors. At least for the [Detect] variant of Tamper_ID, also explain when to look (e.g., periodically, when a user suspects tampering, when an unexpected error or specific type of breach has occurred, when a user may have violated responsibilities for the physical protection of the TOE). `Component Application Rationale` - Explain how to detect and report physical tampering or errors. At least for the [Detect] variant of Tamper_ID, also explain when to look (e.g., periodically, when a user suspects tampering, when an unexpected error or specific type of breach has occurred, when a user may have violated responsibilities for the physical protection of the TOE). AGD_USR.1 - User guidance `Component Application` - Explain how to detect and report physical tampering or errors. At least for the [Detect] variant of Tamper_ID, also explain when to look (e.g., periodically, when a user suspects tampering, when an unexpected error or specific type of breach has occurred, when a user may have violated responsibilities for the physical protection of the TOE). `Component Application Rationale` - Explain how to detect and report physical tampering or errors. At least for the [Detect] variant of Tamper_ID, also explain when to look (e.g., periodically, when a user suspects tampering, when an unexpected error or specific type of breach has occurred, when a user may have violated responsibilities for the physical protection of the TOE). FPT_PHP.1 - Passive detection of physical attack `Component Application` - Environment: Some capability to determine when a physical tampering attack has occurred must be provided, but it is not necessary for the TOE to provide this functionality. The method provided should be supported by appropriate documentation. `Component Application Rationale` - Environment: Some capability to determine when a physical tampering attack has occurred must be provided, but it is not necessary for the TOE to provide this functionality. The method provided should be supported by appropriate documentation. FPT_PHP.2 - Notification of physical attack `Component Application` - List of TSF devices/elements for which active detection is required: list those devices and elements for which active detection is critical Designated user/role: list those individuals that are most appropriate for responding to physical attacks against the identified devices `Component Application Rationale` - List of TSF devices/elements for which active detection is required: list those devices and elements for which active detection is critical Designated user/role: list those individuals that are most appropriate for responding to physical attacks against the identified devices
Identifier	Tamper_Resistance
Descriptive Name	Tamper resistance
Description	Prevent or resist physical tampering with specified system devices and components.
Selection Guidance	O.Tamper_Resistance provides capabilities to automatically respond to physical attacks against specified parts of the TOE, thereby resisting such attacks. The automatic response may take varying forms, but generally involves direct actions (e.g., shutting a system down) rather than notification actions. Should the environment lend itself to being vulnerable to physical attack and resources are ultimately critical then this objective should be considered. For example, communications resources can be jeopardized through a physical attack.
Implementation Application	[FPT_PHP.3] Provides automatic response to physical attacks against resources deemed critical, thereby resisting those attacks.
Editorial	<generic objective>
Implementing Components FPT_PHP.3 - Resistance to physical attack
Identifier	Trusted_DS_Recov
Descriptive Name	Trusted distributed system recovery
Description	Ensure that a replaced failed component when re-integrated into the system will recover such that it will not cause errors or security breaches in other parts of the system.
Selection Guidance
Implementation Application	Select one of FPT_RCV.1, FPT_RCV.2, or FPT_RCV.3. FPT_RCV.4 may be used to augment any of these other components.
Editorial
Implementing Components FPT_RCV.1 - Manual recovery `Component Application` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. `Component Application Rationale` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. FPT_RCV.2 - Automated recovery `Component Application` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. Specify those failures for which normal operation may continue while in a maintenance mode. `Component Application Rationale` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. Specify those failures for which normal operation may continue while in a maintenance mode. FPT_RCV.3 - Automated recovery without undue loss `Component Application` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. Specify those failures for which normal operation may continue while in a maintenance mode. Finally, specify limits on the amount of damage that may occur when various failures occur. `Component Application Rationale` - Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases. Specify those failures for which normal operation may continue while in a maintenance mode. Finally, specify limits on the amount of damage that may occur when various failures occur. FPT_RCV.4 - Function recovery
Identifier	Trusted_Path
Descriptive Name	Provide a trusted path
Description	Provide a trusted path between the user and the system. Execution of a user-requested action must be made via a trusted path with the following properties: * The path is logically distinct from, and cannot be confused with other communication paths (by either the user or the system). * The path provides assured identification of its end points.
Selection Guidance	By definition, trusted-path threats are those that interfere with the trusted path objective. However, trusted-path threats are also masquerade threats because I&A depends on trusted path. Use the trusted-path objective for all trusted communication between the user and the TSF. trusted path for information exchanged via the path. It doesn't matter who initiates the trusted path since by definition, its presence cannot be faked.
Implementation Application
Editorial	<generic done as specific?> This component is relevant when a user or administrator might use another IT device to attempt to gain TSF security attribute information that they are not authorized to access.
Implementing Components FTP_TRP.1 - Trusted path `Component Application Editorial` - It doesn't matter who initiates the trusted path since, by definition, its presence cannot be faked. In many environments, trusted path is more of a concern for remote users than for local users.
Identifier	Trusted_Path&Channel
Descriptive Name	Trusted path and channel
Description	Provide a trusted path to security-critical (TSF) data in which both end points have assured identities. For the remote user, there needs to be a trusted channel as well.
Selection Guidance
Implementation Application
Editorial	This is a TOE objective.
Implementing Components FTP_ITC.1 - Inter-TSF trusted channel FTP_TRP.1 - Trusted path
Identifier	Trusted_Recovery
Descriptive Name	Trusted recovery of security functionality
Description	Recovery to a secure state, without security compromise, after a discontinuity of operations.
Selection Guidance	This objective is relevant when system failures could result in insecure states that, when the system returns to operational mode (or continues to operate), could lead to security compromises. This objective is primarily related to recovery, although it might also be thought of as preventive in the sense of preventing additional losses incurred by running the TOE in an insecure state.
Implementation Application	There are three variants of this objective (choose one): [Manual]: Choose FPT_RCV.1 [Automated]: Choose FPT_RCV.2 [Quantified]: Choose FPT_RCV.3 The [Manual] variant should be chosen when manual procedures for recovery are acceptable. The [Automated] variant should be chosen when the TOE must recover from some failure scenarios without human intervention. The [Quantified] variant should be chosen following the same criteria as for the Automated variant, but in addition there is a strong need to limit the loss of TSF data during failure scenarios to strictly defined limits, and/or to be able to determine exactly what TSF data could not be restored. --- For the [Manual] variant, failure scenarios should have a relatively infrequent occurrence and longer "down times" must be acceptable. The [Automated] variant is justified when: (a) there is a higher risk from failure scenarios, (b) it is less acceptable for the TOE to occasionally transit from an operational mode to a manual mode, and (c) it is less feasible for human operators to intervene.
Editorial	$
Implementing Components FPT_RCV.1 - Manual recovery `Component Application` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. `Component Application Rationale` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. FPT_RCV.2 - Automated recovery `Component Application` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. `Component Application Rationale` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. FPT_RCV.3 - Automated recovery without undue loss `Component Application` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1. `Component Application Rationale` - To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1.
Identifier	Trusted_Recovery_Doc
Descriptive Name	Documentation of untrusted data recovery
Description	Provide trusted recovery to ensure that data cannot be lost or misplaced. Any circumstances which can cause untrusted recovery to be documented with mitigating procedures established.
Selection Guidance
Implementation Application
Editorial	<generic objective>
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - Provide administrative guidance to allow the administrators to determine when recovery fails. `Component Application Rationale` - Provide administrative guidance to allow the administrators to determine when recovery fails.
Identifier	TSF_Mod_Limit
Descriptive Name	Limit administrator's modification of security-critical code or data
Description	Limit the malicious modification of security-critical (TSF) code and data to include specific system code to prevent the system security protection capabilities from being diminished or weakened.
Selection Guidance
Implementation Application	All the components should be applied within the context of restricting which administrators can modify TSF code and data, and how they can perform those modifications.
Editorial	<specific objective>
Implementing Components FMT_MSA.2 - Secure security attributes `Component Application` - Provide a set of secure security attributes levels to allow administrators the ability to modify only specific TSF code or data. `Component Application Rationale` - Provide a set of secure security attributes levels to allow administrators the ability to modify only specific TSF code or data. `Component Application Editorial` - Specific code modification by an administrator must be eliminated by some means to disallow the weakening of the TSF. This could be accomplished through specified levels of secure attributes. FMT_MTD.1 - Management of TSF data `Component Application` - FMT_MTD.1 should be used to specify those who have access to TSF data. `Component Application Rationale` - FMT_MTD.1 should be used to specify those who have access to TSF data. FMT_MTD.2 - Management of limits on TSF data `Component Application` - FMT_MTD.2 should be used to limit TSF modification to administratively necessary actions. `Component Application Rationale` - FMT_MTD.2 should be used to limit TSF modification to administratively necessary actions. FMT_MTD.3 - Secure TSF data FMT_SMR.2 - Restrictions on security roles `Component Application` - The administrator must be limited on the security roles for modifying specific TSF code and data. A separation of administrative functions to multiple administrators with cross checking would be an alternative. `Component Application Rationale` - The administrator must be limited on the security roles for modifying specific TSF code and data. A separation of administrative functions to multiple administrators with cross checking would be an alternative.
Identifier	TSF_Rcv_Err_ID_Loc
Descriptive Name	Local detection of received security-critical data modified in transit
Description	Identification by the system (TOE) of modification of security-critical (TSF) data occurring in transit from a remote trusted site must occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for received messages (must be compatible with that used by the remote site). Action if modification of imported data is detected: Specify any desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. (The modification metric for sent TSF data must be compatible with that used by the TOE.) Action if modification of exported data is detected: none necessary. `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for received messages (must be compatible with that used by the remote site). Action if modification of imported data is detected: Specify any desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. (The modification metric for sent TSF data must be compatible with that used by the TOE.) Action if modification of exported data is detected: none necessary.
Identifier	TSF_Rcv_Err_ID_Rem
Descriptive Name	Remote detection of received security-critical data modified in transit
Description	Identification by the remote site of the modification of security-critical (TSF) data occurring in transit from the remote site must occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Hierarchical to: O.TSF_Rcv_Err_ID_Loc Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the remote site.) Action if modification of imported data is detected: Specify notification of the remote site, and any other desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the remote site by the remote site): Specify desired action. `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the remote site.) Action if modification of imported data is detected: Specify notification of the remote site, and any other desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the remote site by the remote site): Specify desired action.
Identifier	TSF_Rcv_Err_Rcvr_Loc
Descriptive Name	Local correction of received security-critical data that is modified in transit
Description	Identification and correction of modification of security-critical (TSF) data occurring in transit from a remote site by the system shall occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. `Component Application Rationale` - For the Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. FPT_ITI.2 - Inter-TSF detection and correction of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the Environment.) Action if modification of imported data is detected: Specify any desired responses to be made by the TOE. Modifications to be made: Specify correction algorithm. `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the Environment.) Action if modification of imported data is detected: Specify any desired responses to be made by the TOE. Modifications to be made: Specify correction algorithm.
Identifier	TSF_Rcv_Err_Rcvr_Rem
Descriptive Name	Remote correction of security-critical data that is received by the system and modified in transit
Description	Identification and modification of security-critical (TSF) data occurring in transit to the system (TOE) by a remote trusted site must occur, and the remote site shall be able to recover by transmitting a correct version.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Hierarchical to: O.TSF_Rcv_Err_ID_Rem Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the remote site.) Action if modification of imported data is detected: Specify notification of the remote site, and any other desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the remote site by the TOE): Retransmission (for adaptive protocols, a more robust encoding might be used for the retransmission). Defined modification metric: any `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the remote site.) Action if modification of imported data is detected: Specify notification of the remote site, and any other desired responses made by the TSF. For the IT Environment: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the remote site by the TOE): Retransmission (for adaptive protocols, a more robust encoding might be used for the retransmission). Defined modification metric: any
Identifier	TSF_Snd_Err_ID_Loc
Descriptive Name	Local detection of sent security-critical data modified in transit
Description	Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the TSF must occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Hierarchical to: O.TSF_Snd_Err_ID_Rem Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Notify the remote site. This may be either automated or manual. In the latter case, there needs to be an administrative role for maintaining TSF data integrity. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify notification of the TOE, and any other desired responses made by the remote site. Defined modification metric: Action to be taken: `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Notify the remote site. This may be either automated or manual. In the latter case, there needs to be an administrative role for maintaining TSF data integrity. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify notification of the TOE, and any other desired responses made by the remote site. Defined modification metric: Action to be taken:
Identifier	TSF_Snd_Err_ID_Rem
Descriptive Name	Remote detection of sent security-critical data modified in transit.
Description	Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the remote site must occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify any desired responses made by the remote site. Defined modification metric: Action to be taken: `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify any desired responses made by the remote site. Defined modification metric: Action to be taken:
Identifier	TSF_Snd_Err_Rcvr_Loc
Descriptive Name	Local Correction of sent security-critical data modified in transit
Description	Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the remote site must occur, and shall be able to recover by retransmitting a correct version.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Hierarchical to: O.TSF_Snd_Err_ID_Rem Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Retransmission; for adaptive protocols specify improved strength of encoding. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify notification of the TOE, and any other desired responses made by the remote site. Defined modification metric: Action to be taken: `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Retransmission; for adaptive protocols specify improved strength of encoding. For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify notification of the TOE, and any other desired responses made by the remote site. Defined modification metric: Action to be taken:
Identifier	TSF_Snd_Err_Rcvr_Rem
Descriptive Name	Remote correction of sent security-critical data modified in transit
Description	Identification and correction of modification of security-critical (TSF) data occurring in transit to the remote site by the remote site must occur.
Selection Guidance	Effectiveness depends heavily on strength of function.
Implementation Application
Editorial	Hierarchical to: O.TSF_Snd_Err_ID_Rem Effectiveness depends heavily on strength of function.
Implementing Components FPT_ITI.1 - Inter-TSF detection of modification `Component Application` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. `Component Application Rationale` - For the TOE: Modification metric: specify desired strength of function for exported data. Action if modification of exported data is detected: not necessary. FPT_ITI.2 - Inter-TSF detection and correction of modification `Component Application` - For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify any desired responses to be made by the remote site. Modifications to be made: Specify correction algorithm. `Component Application Rationale` - For the IT Environment: Modification metric: specify desired strength of function for received messages. (The modification metric for received TSF data must be compatible with that used by the TOE.) Action if modification of imported data is detected: Specify any desired responses to be made by the remote site. Modifications to be made: Specify correction algorithm.
Identifier	User_Attributes
Descriptive Name	Maintain user attributes
Description	Maintain a set of security attributes (which may include group membership, clearance, access rights, etc.) associated with individual users in addition to user identity.
Selection Guidance
Implementation Application
Editorial	<specific objective?>
Implementing Components FIA_ATD.1 - User attribute definition FMT_MSA.1 - Management of security attributes
Identifier	User_Auth_Enhanced
Descriptive Name	Enhanced user authentication
Description	Execute enhanced measures to ensure that either user authentication data cannot be stolen or when it is stolen, it cannot be used to gain access to the system.
Selection Guidance
Implementation Application	Both FIA_UAU.3 and FIA_UAU.4 can be either preventive, detective, or both. However, the latter component could only provide detection with the aid of appropriate auditing functions. These components can be selected individually for specific types of protection, or jointly to provide supplemental protection.
Editorial	<specific objective>
Implementing Components FIA_UAU.3 - Unforgeable authentication `Component Application` - The type of mechanism (either preventive, detective, or both) will be specified through the provided operations. `Component Application Rationale` - The type of mechanism (either preventive, detective, or both) will be specified through the provided operations. FIA_UAU.4 - Single-use authentication mechanisms `Component Application` - Single-use authentication will be associated with specific authentication mechanisms through available operations for this component. `Component Application Rationale` - Single-use authentication will be associated with specific authentication mechanisms through available operations for this component.
Identifier	User_Auth_Management
Descriptive Name	User authorization management
Description	Manage and update user authorization and privilege data in accordance with organizational security and personnel policies.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components AGD_ADM.1 - Administrator guidance `Component Application` - The administrator must be provided guidance on how to properly adjust a user's authorization status. `Component Application Rationale` - The administrator must be provided guidance on how to properly adjust a user's authorization status. AGD_USR.1 - User guidance FMT_MSA.1 - Management of security attributes `Component Application` - All user security attributes that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations. `Component Application Rationale` - All user security attributes that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations. FMT_REV.1 - Revocation `Component Application` - This component provides users and or administrators with the capability to revoke attributes for users (or possibly the resources they may access), as specified. `Component Application Rationale` - This component provides users and or administrators with the capability to revoke attributes for users (or possibly the resources they may access), as specified. FMT_SAE.1 - Time-limited authorisation `Component Application` - Specify security attributes that the system will expire after a certain amount of time. `Component Application Rationale` - Specify security attributes that the system will expire after a certain amount of time.
Identifier	User_Auth_Multiple
Descriptive Name	Require multiple authentication mechanisms
Description	Invoke multiple authentication mechanisms, which will provide confidence that the user is who they say they are.
Selection Guidance	This objective can require simultaneous or sequential use of the multiple authentication mechanisms. Simultaneous, multiple use of authentication mechanisms is considered a stronger form of use.
Implementation Application	Choose FIA_UAU.5 and FMT_MOF.1 to implement the objective.
Editorial	<specific objective>
Implementing Components FIA_UAU.5 - Multiple authentication mechanisms `Component Application` - List of multiple authentication mechanisms: list all authentication mechanisms `Component Application Rationale` - List of multiple authentication mechanisms: list all authentication mechanisms FMT_MOF.1 - Management of security functions behaviour `Component Application` - The TSF shall restrict the ability to disable, modify the behavior of authentication mechanisms to authorized administrators. `Component Application Rationale` - The TSF shall restrict the ability to disable, modify the behavior of authentication mechanisms to authorized administrators.
Identifier	User_Conf_Prevention
Descriptive Name	Basic confidentiality-breach prevention
Description	Prevent unauthorized export of confidential information from the TOE with moderate effectiveness.
Selection Guidance
Implementation Application	This objective is implemented in terms of a technical security policy, which is referred to as the observation-control policy. This observation-control policy may be cast as either an access control or information-flow policy. When cast as an access control policy, use the components from FDP_ACC and FDP_ACF. When cast as an information flow policy, use the components from FDP_IFC and FDP_IFF. In both cases, use of FDP_ETC is required to meet this objective.
Editorial	<specific objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: observation-control policy List of subjects, objects, and operations covered by the SFP: all objects that may hold sensitive information, including I/O devices; subjects capable of reading sensitive information `Component Application Rationale` - Access control SFP: observation-control policy List of subjects, objects, and operations covered by the SFP: all objects that may hold sensitive information, including I/O devices; subjects capable of reading sensitive information FDP_ACF.1 - Security attribute based access control FDP_ETC.1 - Export of user data without security attributes FDP_IFC.1 - Subset information flow control `Component Application` - Information flow control SFP: an observation-control policy List of subjects, information, and operations: all subjects that may read or hold sensitive information, including I/O device drivers; confidential information governed by the observation-control policy, including information handled via I/O devices; all relevant operations. `Component Application Rationale` - Information flow control SFP: an observation-control policy List of subjects, information, and operations: all subjects that may read or hold sensitive information, including I/O device drivers; confidential information governed by the observation-control policy, including information handled via I/O devices; all relevant operations. FDP_IFF.1 - Simple security attributes `Component Application` - Information flow control SFP: the above observation-control policy The minimum number and type of security attributes: readership attributes denoting a set of allowed readers or a set of allowed roles For each operation, the security attribute-based relationship that must hold: Additional information flow control SFP rules: a subject may observe or receive information only if it is acting on behalf of a user possessing the information's readership attributes; a subject may transmit or send information only if the readership of the information contains the readership of all the information that the subject has acquired `Component Application Rationale` - Information flow control SFP: the above observation-control policy The minimum number and type of security attributes: readership attributes denoting a set of allowed readers or a set of allowed roles For each operation, the security attribute-based relationship that must hold: Additional information flow control SFP rules: a subject may observe or receive information only if it is acting on behalf of a user possessing the information's readership attributes; a subject may transmit or send information only if the readership of the information contains the readership of all the information that the subject has acquired
Identifier	User_Data_Dial-in
Descriptive Name	Protection of user-session data
Description	Allow dial-in access through secure mechanisms only.
Selection Guidance
Implementation Application
Editorial	<specific objective>
Implementing Components FDP_IFC.1 - Subset information flow control FTA_TSE.1 - TOE session establishment
Identifier	User_Data_Integrity
Descriptive Name	Integrity protection of stored user data
Description	Provide appropriate integrity protection for stored user data.
Selection Guidance
Implementation Application
Editorial	<specific or generic?><duplicate?>
Implementing Components FDP_SDI.1 - Stored data integrity monitoring
Identifier	User_Data_Transfer
Descriptive Name	Protection of transmitted user data
Description	Provide the ability to have physically protected communications lines, intrusion detection for communications lines, and/or need-to-know isolation for communications lines.
Selection Guidance
Implementation Application
Editorial	<specific objective?> This objective depends on the O.Identify_Unusual_Act objective for intrusion detection.
Implementing Components FDP_ITT.1 - Basic internal transfer protection
Identifier	User_Defined_AC
Descriptive Name	User-defined access control
Description	Enforce an access control policy whereby users may determine who may access information they control.
Selection Guidance	An essential aspect of this form of access control is the idea that "owners" or "managers" of information will make decisions about who can access the data they own or control. An example of this form of access control is commonly called Discretionary Access Control (DAC), which originated within the U.S. government. Although DAC is a very prevalent form of access control in existence today, there are many variations in its implementation. Examples of DAC-like implementations include access control lists and UNIX permission bits.
Implementation Application	Two variants of this objective can be implemented: [Subset] Choose FDP_ACC.1 and FDP_ACF.1. This variant allows subsets within the system to be constrained by the defined controls while others need not be. Subsets are defined by specific data types, users, and/or operations, or combinations thereof. This variant provides flexibility at the expense of more comprehensive and consistent protection. [Complete] Choose FDP_ACC.2 and FDP.ACF.1. This variant provides access control between all users, data types, and operations on the system, although the exact controls that must be applied need not be identical. For example, the controls placed on "public" files need not be equivalent with those placed on "project" files. This variant attempts to provide comprehensive and consistent protection but generally requires much more rigor to implement.
Editorial	<generic objective>
Implementing Components FDP_ACC.1 - Subset access control `Component Application` - Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined below in terms of subjects, objects, and operations) applies. Other component specified throughout the PP will use this identifier as a means to associate applicability. In particular, the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier. List of subjects, objects, and operations covered by the SFP: List the specific subjects, objects, and operations that are within the scope of this policy. `Component Application Rationale` - Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined below in terms of subjects, objects, and operations) applies. Other component specified throughout the PP will use this identifier as a means to associate applicability. In particular, the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier. List of subjects, objects, and operations covered by the SFP: List the specific subjects, objects, and operations that are within the scope of this policy. `Component Application Editorial` - <WORKED EXAMPLE> FDP_ACC.2 - Complete access control `Component Application` - Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined in terms of subjects and objects, below) applies. Other component specified throughout the PP will use this identifier as a means to associate applicability. In particular, the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier. List of subjects and objects: List the specific subjects and objects that are within the scope of this policy. `Component Application Rationale` - Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined in terms of subjects and objects, below) applies. Other component specified throughout the PP will use this identifier as a means to associate applicability. In particular, the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier. List of subjects and objects: List the specific subjects and objects that are within the scope of this policy. `Component Application Editorial` - <WORKED EXAMPLE> FDP_ACF.1 - Security attribute based access control `Component Application` - Access control SFP: Name the associated access control policy (as identified within the dependent FDP_ACC component) that are applicable for the attributes, rules, etc. specified below. Security attributes: List the attributes here that must be used to support enforcement of the rules listed below. Rules governing access: List the rules that express the intent and scope of that policy component. Rules that explicitly authorize access: List the rules that demonstrate conditions (e.g., specific security attribute values) that result in an explicit "grant" authorization. Be sure to avoid and/or clarify any contradictions or ambiguities that may result between an explicit "grant" rule and an explicit "deny" rule. `Component Application Rationale` - Access control SFP: Name the associated access control policy (as identified within the dependent FDP_ACC component) that are applicable for the attributes, rules, etc. specified below. Security attributes: List the attributes here that must be used to support enforcement of the rules listed below. Rules governing access: List the rules that express the intent and scope of that policy component. Rules that explicitly authorize access: List the rules that demonstrate conditions (e.g., specific security attribute values) that result in an explicit "grant" authorization. Be sure to avoid and/or clarify any contradictions or ambiguities that may result between an explicit "grant" rule and an explicit "deny" rule. `Component Application Editorial` - <WORKED EXAMPLE>
Identifier	User_Guidance
Descriptive Name	User guidance documentation
Description	Provide documentation for the general user.
Selection Guidance	Deter or prevent user errors by providing adequate user guidance.
Implementation Application
Editorial	<generic objective>
Implementing Components AGD_USR.1 - User guidance `Component Application` - Associated information must appear in User Guidance documentation. `Component Application Rationale` - Associated information must appear in User Guidance documentation.