NAP-14.15, Top Secret Restricted Data Information Group Protection Profile

NNSA Policy Letter: NAP-14.15 Date: August 9, 2006 TITLE: Top Secret Restricted Data Information Group Protection Profile 1. OBJECTIVE. Establish requirements for the protection of National Nuclear Security Administration (NNSA) Nuclear Weapon Data that is classified as Top Secret Restricted Data when information systems are used to collect, create, process, transmit, store, and disseminate this information. 2. APPLICABILITY. This NNSA Policy (NAP) applies to all entities, Federal or contractors, which collect, create, process, transmit, store, and disseminate NNSA information. a. NNSA Elements. NNSA Headquarters Organizations, Service Center, Site Offices, NNSA contractors, and subcontractors are, hereafter, referred to as NNSA elements. b. Information System. This NAP applies to any information system that collects, creates, processes, transmits, stores, and disseminates unclassified or classified NNSA information. This NAP applies to any information system life cycle, including the development of new information systems, the incorporation of information systems into an infrastructure, the incorporation of information systems outside the infrastructure, the development of prototype information systems, the reconfiguration or upgrade of existing systems, and legacy systems. In this document, the term(s) "information system," Target of Evaluation (TOE), or "system" are used to mean any information system or network that is used to collect, create, process, transmit, store, or disseminate data owned by, for, or on behalf of NNSA or DOE. c. Deviations. Deviations from the requirements prescribed in this NAP must be processed in accordance with Chapter E of Attachment 1 to NAP-14.1-B, NNSA Cyber Security Program. d. Site/Facility Management Contractors. Except for the exclusions in paragraph 2.e, the Contractor Requirements Document (CRD) Attachment 1, sets forth requirements of this NAP that will apply to site/facility management contractors whose contract includes the CRD. NAP 14.15 2 (1) The CRD must be included in site/facility management contracts that provide access to NNSA information systems and automated access to NNSA information. (2) The CRD does not automatically apply to other than site/facility management contractors. Any application of requirements of this Policy to other than site/facility management contractors will be communicated separately. (3) As the laws, regulations, and DOE and NNSA directives clause of site/facility management contracts states, regardless of the performer of the work, site/facility management contractors with the CRD incorporated into their contracts are responsible for compliance with the requirements of the CRD. (4) Affected site/facility management contractors are responsible for flowing down the requirements of this CRD to subcontracts at any tier to the extent necessary to ensure the site/facility management contractors’ compliance with the requirements. (5) Contractors must not flow down requirements to subcontractors unnecessarily or imprudently. That is, contractors will--- (a) Ensure that they and their subcontractors comply with the requirements of the CRD; and (b) Incur only costs that would be incurred by a prudent person in the conduct of competitive business.

e. Exclusion. The Deputy Administrator for Naval Reactors shall, in accordance with the responsibilities and authorities assigned by Executive Order 12344 (set forth in Public Law 106-65 of October 5, 1999 [50 U.S.C. 2406]) and to ensure consistency throughout the joint Navy and DOE Organization of the Naval Reactors Propulsion Program, implement and oversee all requirements and practices pertaining to this policy for activities under the Deputy Administrator’s cognizance. f. Implementation. A plan for the implementation of this NAP must be completed within 60 days after issuance of this NAP. 3. CANCELLATIONS. None. 4. RESPONSIBILITIES. Roles and responsibilities for all activities in the NNSA PCSP are described in NAP 14.1-B, NNSA Cyber Security Program. 5. REQUIREMENTS. The attached Protection Profile (PP) defines the requirements for protecting NNSA information in the Top Secret Restricted Data Information Group and the information systems used to collect, create, process, transmit, store, and disseminate this information. NAP 14.15 3 6. CONTACT. Questions concerning this NAP should be directed to the NNSA Cyber Security Program Manager, through the cognizant Cyber Security Office Manager, at 301-903-2425. 7. DEFINITIONS. See NAP 14.1-B, Appendix 3. BY ORDER OF THE ADMINISTRATOR: Linton Brooks Administrator Attachments NAP 14.15 4 This page intentionally blank. NAP 14.15 ATTACHMENT 1-1 ATTACHMENT 1 CONTRACTOR REQUIREMENTS DOCUMENT This Contractor Requirements Document (CRD) establishes the requirements for National Nuclear Security Administration contractors, with access to NNSA and DOE information systems. Contractors must comply with the requirements listed in the CRD. The contractor will ensure that it and its subcontractors cost-effectively comply with the requirements of this CRD. Regardless of the performer of the work, the contractor is responsible for complying with and flowing down the requirements of this CRD to subcontractors at any tier to the extent necessary to ensure the contractor’s compliance with the requirements. In doing so, the contractor must not unnecessarily or imprudently flow down requirements to subcontractors. That is, the contractor will ensure that it and its subcontractors comply with the requirements of this CRD and incur only those costs that would be incurred by a prudent person in the conduct of competitive business. REQUIREMENTS. 1. A plan for the implementation of this CRD must be completed within 60 days after inclusion of this CRD in the contract. 2. The contractor shall implement the Protection Profile (PP) in Appendix 1 for protecting NNSA information in the Top Secret Restricted Data (TSRD) Information Group and the information systems used to collect, create, process, transmit, store, and disseminate this information. 3. The contractor shall implement the deviations provisions listed in Chapter E of Attachment 1 to NAP 14.1-B, NNSA Cyber Security Program, to deviate from the requirements of this CRD. NAP 14.15 ATTACHMENT 1 - 1 2 This page intentionally blank. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X APPENDIX 1 National Nuclear Security Administration PROTECTION PROFILE FOR THE TOP SECRET RESTRICTED DATA INFORMATION GROUP TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X i i Version Revision Date Description/ Change TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X i i i Foreword

This publication, “NNSA Protection Profile for Top Secret Restricted Data Information Group,” is issued by the Department of Energy/National Nuclear Security Administration as part its Program Secretarial Office Cyber Security Program to promulgate protection standards for information. The base set of requirements used in this protection profile is taken from the “Common Criteria for Information Technology Security Evaluations, Version 2.0.” Further information about the Common Criteria can be found on the Internet at http://www.commoncriteriaportal.org/. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X iv Table of Contents 1. PP INTRODUCTION..............................................................................................................................................1 1.1 PP IDENTIFICATION ..............................................................................................................................................1 1.2 PP OVERVIEW ......................................................................................................................................................1 1.3 STRENGTH OF ENVIRONMENT...............................................................................................................................2 1.4 CONVENTIONS......................................................................................................................................................2 1.5 TERMS ..................................................................................................................................................................2 2. TOE DESCRIPTION...............................................................................................................................................3 3. SECURITY ENVIRONMENT ...............................................................................................................................4 3.1 SECURITY USAGE ASSUMPTIONS..........................................................................................................................4 3.1.1 Physical Assumptions ...................................................................................................................................4 3.1.2 Personnel Assumptions.................................................................................................................................4 3.1.3 Connectivity Assumptions.............................................................................................................................5 3.2 THREATS...............................................................................................................................................................5 3.2.1 TOE Threats .................................................................................................................................................5 3.2.2 Non-TOE Threats .........................................................................................................................................8 3.3 ORGANIZATIONAL SECURITY POLICIES ..............................................................................................................10 4. SECURITY OBJECTIVES...................................................................................................................................14

4.1 SECURITY OBJECTIVES FOR THE TOE.................................................................................................................14 4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT.................................................................................................19 5. IT SECURITY REQUIREMENTS ......................................................................................................................25 5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS...................................................................................................25 5.1.1 FAU_ARP.1 Security alarms......................................................................................................................25 5.1.2 FAU_GEN.1 Audit data generation ...........................................................................................................25 5.1.3 FAU_GEN.2 User identity association.......................................................................................................27 5.1.4 FAU_SAA.2 Profile based anomaly detection............................................................................................27 5.1.5 FAU_SAA.4 Complex attack heuristics ......................................................................................................27 5.1.6 FAU_SAR.1 Audit review...........................................................................................................................28 5.1.7 FAU_SAR.2 Restricted Audit Review .....................................................................................................28 5.1.8 FAU_SAR.3 Selectable audit review ......................................................................................................29 5.1.9 FAU_SEL.1 Selective Audit ....................................................................................................................29 5.1.10 FAU_STG.2 Guarantees of audit data availability..................................................................................29 5.1.11 FAU_STG.3 Action in case of possible audit data loss............................................................................30 5.1.12 FAU_STG.4 Prevention of audit data loss ...............................................................................................30 TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X v

5.1.13 FCO_NRO.1 Selective proof of origin......................................................................................................30 5.1.14 FCO_NRR.1 Selective proof of receipt.....................................................................................................31 5.1.15 FCS_CKM.4 Cryptographic key destruction............................................................................................31 5.1.16 FCS_COP.1 Cryptographic operation.....................................................................................................31 5.1.17 FDP_ACC.2 Complete access control .....................................................................................................31 5.1.18 FDP_ACF.1 Security attribute based access control...............................................................................32 5.1.19 FDP_DAU.1 Basic data authentication ...................................................................................................34 5.1.20 FDP_ETC.1 Export of User Data Without Security Attributes ................................................................34 5.1.21 FDP_ETC.2 Export of user data with security attributes ........................................................................35 5.1.22 FDP_IFC.1 Subset information flow control ...........................................................................................36 5.1.23 FDP_IFF.2 Hierarchical security attributes............................................................................................36 5.1.24 FDP_ITC.1 Import of user data without security attributes ....................................................................38 5.1.25 FDP_ITC.2 Import of user data with security attributes..........................................................................39 5.1.26 FDP_RIP.2 Full residual information protection ....................................................................................40 5.1.27 FDP_SDI.2 Stored data integrity monitoring and action.........................................................................40 5.1.28 FIA_AFL.1 Authentication failure handling.............................................................................................41 5.1.29 FIA_ATD.1 User attribute definition........................................................................................................41 5.1.30 FIA_SOS.1 Verification of secrets ............................................................................................................42 5.1.31 FIA_UAU.2 User Authentication before any action.................................................................................42 5.1.32 FIA_UAU.5 Multiple authentication mechanisms....................................................................................42 5.1.33 FIA_UAU.6 Re-authenticating .................................................................................................................42 5.1.34 FIA_UAU.7 Protected authentication feedback.......................................................................................42 5.1.35 FIA_UID.1 Timing of identification.........................................................................................................43 5.1.36 FIA_UID.2 User identification before any action....................................................................................43 5.1.37 FIA_USB.1 User-Subject Binding ............................................................................................................43

5.1.38 FMT_MOF.1 Management of security functions behavior......................................................................44 5.1.39 FMT_MSA.1 Management of security attributes......................................................................................44 5.1.40 FMT_MSA.2 Secure security attributes....................................................................................................45 5.1.41 FMT_MSA.3 Static attribute initialization ...............................................................................................45 5.1.42 FMT_MTD.1 Management of TSF data...................................................................................................45 5.1.43 FMT_REV.1 Revocation ...........................................................................................................................47 5.1.44 FMT_SMR.2 Restrictions on security roles..............................................................................................48 5.1.45 FPT_AMT.1 Abstract machine testing .....................................................................................................48 5.1.46 FPT_ITC.1 Inter-TSF confidentiality during transmission......................................................................49 5.1.47 FPT_ITT.1 Basic internal TSF data transfer protection..........................................................................49 5.1.48 FPT_RCV.2 Automated recovery.............................................................................................................49 5.1.49 FPT_RPL.1 Replay detection ...................................................................................................................50 TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X vi 5.1.50 FPT_RVM.1 Non-bypassability of the TSF ..............................................................................................50 5.1.51 FPT_SEP.3 Complete reference monitor...............................................................................................50 5.1.52 FPT_STM.1 Reliable time stamps............................................................................................................50 5.1.53 FPT_TST.1 TSF testing ............................................................................................................................51 5.1.54 FRU_RSA.2 Minimum and maximum quotas...........................................................................................51 5.1.55 FTA_MCS.1 Basic limitation on multiple concurrent sessions................................................................51 5.1.56 FTA_SSL.1 TSF-initiated session locking ................................................................................................52 5.1.57 FTA_SSL.2 User-initiated locking............................................................................................................52 5.1.58 FTA_SSL.3 TSF-initiated termination ......................................................................................................52 5.1.59 FTA_TAB.1 Default TOE access banners................................................................................................52 5.1.60 FTA_TAH.1 TOE access history..............................................................................................................53 5.1.61 FTA_TSE.1 TOE session establishment...................................................................................................53 5.1.62 FTP_TRP.1 Trusted Path.........................................................................................................................53

5.2 TOE SECURITY ASSURANCE REQUIREMENTS ....................................................................................................53 5.2.1 Configuration Management........................................................................................................................53 5.2.2 Delivery and Operation..............................................................................................................................55 5.2.3 Development...............................................................................................................................................57 5.2.4 Guidance Documents..................................................................................................................................60 5.2.5 Life Cycle Support......................................................................................................................................62 5.2.6 Assurance Maintenance..............................................................................................................................64 5.2.7 Tests............................................................................................................................................................67 5.2.8 Vulnerability Assessment............................................................................................................................69 5.3 SECURITY REQUIREMENTS FOR THE IT ENVIRONMENT ......................................................................................72 5.3.1 ENV_AMA.1 Malicious Access...................................................................................................................72 5.3.2 ENV_AVA.1 Information Availability.........................................................................................................73 5.3.3 ENV_ATH.1 Management of User Identifiers and Authenticators.............................................................73 5.3.4 ENV_CLR.1 Clearing .................................................................................................................................73 5.3.5 ENV_CVT.1 Covert Channels ....................................................................................................................74 5.3.6 ENV_EXM.3 Sophisticated Hardware and Software Examination............................................................74 5.3.7 ENV_EXM.4 Bypass of Software Controls.................................................................................................74 5.3.8 ENV_FOR.1 Forensics ...............................................................................................................................74 5.3.9 ENV_IDS.1 Intrusion Detection .................................................................................................................74 5.3.10 ENV_IDS.2 Advanced Intrusion Detection...............................................................................................75 5.3.11 ENV_INT.1 TOE Interface .......................................................................................................................75 5.3.12 ENV_MRK.1 Marking ..............................................................................................................................75 5.3.13 ENV_NON.1 Non-TOE Access.................................................................................................................76 5.3.14 ENV_NOT.1 User Notification .................................................................................................................76

TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X vii 5.3.15 ENV_NTK.1 Need-To-Know.....................................................................................................................76 5.3.16 ENV_PHY.3 Physical Security and Environmental Protection............................................................76 5.3.17 ENV_PRO.1 Information Protection........................................................................................................76 5.3.18 ENV_RCV.1 System Recovery..................................................................................................................77 5.3.19 ENV_REV.1 Media and Component Review ............................................................................................77 5.3.20 ENV_RGT.1 User Access Rights and Privileges ......................................................................................77 5.3.21 ENV_ROL.1 Security Roles ......................................................................................................................77 5.3.22 ENV_ROL.2 Security Roles ......................................................................................................................77 5.3.23 ENV_TNG.1 User Training......................................................................................................................77 5.3.24 ENV_UCL.1 User Clearance - Q.............................................................................................................78 6. PP APPLICATION NOTES .................................................................................................................................78 7. RATIONALE..........................................................................................................................................................79 7.1 SECURITY OBJECTIVES RATIONALE....................................................................................................................79 7.2 SECURITY REQUIREMENTS RATIONALE............................................................................................................104 TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 1 1. PP INTRODUCTION The Top Secret Restricted Data Information Group1 Protection Profile, hereafter called TSRDPP, specifies a set of security functional and assurance requirements for the National Nuclear Security Administration (NNSA) Top Secret Restricted Data Information Group and the information technology (IT) products used to store, process, disseminate information in this Information Group. This section contains document management and overview information necessary to describe the Protection Profile (PP) for use in the National Nuclear Security Administration (NNSA). The PP identification provides the labeling and descriptive information necessary to identify, catalogue, register, and cross-reference a PP. The PP overview summarizes the profile in narrative form and provides sufficient information for a potential user to determine whether the PP is of interest. The overview can also be used as a standalone abstract for PP catalogues and registers. The conventions section provides an explanation of how this document is organized and the terms section gives a basic definition of terms that are specific to this PP. 1.1 PP Identification Title: NNSA Protection Profile for Top Secret Restricted Data Information Group (TSRDPP)

Keywords: access control, discretionary access control, general-purpose operating system, information protection, labels, mandatory access control 1.2 PP Overview TSRDPP-conformant environments, systems, and products support access controls that are capable of enforcing access limitations on individual users and data objects. Specifically, two classes of access control mechanisms are provided: those that allow individual users to specify how resources (e.g., files, directories) under their control are to be shared; and those that enforce limitations on sharing among users. The latter is implemented by the use of security markings (i.e., “labels”). TSRDPP -conformant products also provide an audit capability that records the security-relevant events that occur within the system. The TSRDPP provides for a level of protection that is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The TSRDPP does not fully address the threats posed by malicious system development or administrative personnel. These threats must be mitigated by other technical and non-technical measures. The TSRDPP is generally applicable to distributed systems but does not address the security requirements that arise specifically out of the need to distribute the resources within a network. 1 Top Secret Restricted Data -- Information that is classified as Top Secret and identified as Restricted Data or Formerly Restricted Data and is related to nuclear weapons. This information is further marked with a Sigma category. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 2 1.3 Strength of Environment The strength of environment is based on the NNSA consequences of loss minimums in the NNSA PCSP and the threats from the NNSA Cyber Risk Assessment. The assurance requirements and the minimum strength of function were chosen to be consistent with that level of risk. The TSRDPP is for a generalized environment with a moderate level of risk to the assets. The assurance requirements and the minimum strength of function were chosen to be consistent with that level of risk. The assurance level is NNSA AL 4 and the minimum strength of function is SOF-medium. 1.4 Conventions This document is organized based on Annex B of Part 1 of the Common Criteria. There are several deviations in the organization of this profile. First, rather than being a separate section, the application notes have been integrated with requirements and indicated as notes. Likewise, the rationale has been integrated where appropriate. For each component, an application note may appear. Application notes document guidance for how the requirement should be applied. For additional guidance, the CC itself should be consulted. 1.5 Terms This profile uses the following terms that are described in this section to aid in the application of the requirements: • User • Authenticated User • Administrator • Discretionary Access Control (DAC) Policy • Mandatory Access Control (MAC) Policy • Sensitivity Label • Security Attribute • Security Level • Mediation • Access • Authorization • Category A user is an individual who attempts to invoke a service offered by the Target of Evaluation (TOE). An authenticated user is a user who has been properly identified and authenticated. These users are considered to be legitimate users of the TOE.

An administrator is an authenticated user who has been granted the authority to manage the TOE. These users are expected to use this authority only in the manner prescribed by the guidance given them. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 3 Whether a user is granted a requested action is determined by the TOE Security Policy (TSP), specified in this protection profile as having two components: Discretionary Access Control (DAC) and Mandatory Access Control (MAC). These policies comprise a set of rules used to mediate user access to TOE protected objects. The DAC Policy can be characterized as a policy that allows users and authorized administrators to control access to objects on the basis of individual user identity or membership in a group (e.g., Use Control Group). The MAC Policy is a set of rules that determines access based upon the sensitivity (e.g., TSRD Sigma 1, SRD Sigma 14, TS-NSI, etc.) of the information being accessed and the access authority (e.g., clearance, formal need-to-know, etc.) of the user attempting to access that information. The sensitivity of the information and the access rights of the user are typically identified by sensitivity labels. These sensitivity labels are encoded as security levels that are created by combining a hierarchical classification ranking (e.g., Top Secret, Secret, Confidential, Unclassified Mandatory, etc) with one of the non-hierarchical categories (e.g., Restricted Data Sigma 5, Restricted Data Sigma 1-13&15, Restricted Data Sigma14, Formerly Restricted Data, National Security Information, Project A, personnel, etc.) to represent the sensitivity label of the object or access authorities of the user/ subject. The sensitivity label of the user/subject is compared with the sensitivity label of the object. Access is granted or denied based on the DAC and MAC policies. Security attributes are information that the TOE associates with each user, subject, and/or object that is used for the enforcement of the TSP. These security attributes include subject sensitivity labels (defined in terms of security levels), object sensitivity labels (defined in terms of security levels), user identity, group memberships, authentication data, etc. The Mandatory Access Control Policy is the basic policy that a TSRDPP-conformant TOE enforces over users and resources. 2. TOE DESCRIPTION The TSRDPP defines a set of security requirements to be levied on TOEs. These TOEs include information systems that contain general-purpose operating systems, such as workstations, mainframes, or personal computers. These systems can be comprised of a single host or a set of cooperating hosts in a distributed system. Such systems permit one or more processors along with peripherals and storage devices to be used by multiple users to perform a variety of functions requiring controlled, shared access to the information stored on the system. Such installations are typical of personal, work group, or enterprise computing systems accessed by users local to, or with otherwise protected access to, the computer systems. The TSRDPP is applicable to TOEs that provide facilities for online interaction with users, as well as TOEs that provide for batch processing. The protection profile is also generally applicable to TOEs incorporating network functions but contains no network-specific requirements. Networking is covered only to the extent to which the TOE can be considered to be part of a centrally managed system that meets a common set of security requirements.

The TSRDPP supports multiple security levels as well as user-defined sharing of information. The TSRDPP assumes that responsibility for the safeguarding of the data protected by the TOEs security functions (TSF) can be delegated to the TOE users. All objects (e.g., data, system TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 4 resources) that can be accessed by users are identified and are under the control of the TOE. The data are stored in objects, and the TSF can associate with each controlled object a description of the access rights to that object as well as the label that identifies the sensitivity of the information within the object. All individual users are assigned a unique identifier. This identifier supports individual accountability. The TSF authenticates the claimed identity of the user before allowing the user to perform any actions that require TSF mediation, other than actions that aid an authorized user in gaining access to the TOE. 3. SECURITY ENVIRONMENT 3.1 Security Usage Assumptions This section describes the security aspects of the environment in which the TOE will be, or is intended to be, used. This includes information about the physical, personnel, and connectivity aspects of the environment. A TSRDPP-conformant TOE is assured to provide effective security measures in a cooperative non-hostile environment only if it is installed, managed, and used correctly. The operational environment must be managed in accordance with assurance requirements documentation for delivery, operation, and user/administrator guidance. The following specific conditions are assumed to exist in an environment where TSRDPP-conformant TOEs are employed. 3.1.1 Physical Assumptions TSRDPP-conformant TOEs are intended for application in user areas that have physical control and monitoring. It is assumed that the following physical conditions will exist. A.LOCATE The TOE components will be located within controlled access facilities that will prevent unauthorized physical access. A.PROTECT The TOE hardware and software critical to security policy enforcement will be protected from unauthorized physical modification. 3.1.2 Personnel Assumptions It is assumed that the following personnel conditions will exist. A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 5 A.TRAINED_ADM The system administrative personnel will follow and abide by the instructions provided by the administrator documentation. A.COOP Users possess the necessary authorization to access at least some of the information managed by the TOE, and most users are expected to act in a benign manner. 3.1.3 Connectivity Assumptions The TSRDPP contains no explicit network or distributed system requirements. However, it is assumed that the following connectivity conditions exist. A.PEER Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints or that the TOE is isolated by appropriate barriers, such as controlled interfaces, firewalls, etc. PP-conformant TOEs are applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements that address connectivity to external systems or the communications links to such systems. A Controlled Interface may be necessary to preserve this assumption.

A.CONNECT All connections to peripheral devices reside within the controlled access facilities. PP-conformant TOEs only address security concerns related to the manipulation of the TOE through its authorized access points. Internal communication paths to access points, such as terminals, are assumed to be adequately protected. 3.2 Threats These threats are addressed by TSRDPP compliant TOEs. The threat agents are either human users or external IT entities not authorized to use the TOE itself. The assets that are subject to attack are the information residing on the TOE itself. 3.2.1 TOE Threats T.ABUSE_ADMIN System administrator abuse of privileges T.ABUSE_OTHER Compromise by authorized activities T.ABUSE_USER Abuse of authorized user privileges TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 6 T.ACCESS_MALICIOUS Unauthorized access by an authenticated user for malicious purposes T.ACCESS_TOE Unauthorized access by authorized user T.ACCESS_UNDETECTED Undetected perpetrator access T.ADMIN_ERROR System administrator error or omission T.ATTACK_OTHER Unauthorized action by perpetrator T.AUDIT_CONFIDENTIALITY_TOE Loss of audit trail confidentiality T.AUDIT_CORRUPTED_TOE Corruption of audit trail T.AUTHENTICATION_NETWORK Unauthenticated communications between client and server T.CAPTURE Eavesdropping T.CONFIGURATION_ADMI N Inadequate configuration management T.COVERT_OTHER Covert channel use T.CRASH System crash T.DELETE_UNINTENTIONAL Unintentional user deletion or destruction T.DENY_OTHER Denial of participation in information transfer T.EAVESDROPPING Unauthorized monitoring of networks or information systems T.ENTRY_OTHER Inappropriate access by authorized user T.ENTRY_TOE Attack by unauthorized malicious user T.ERROR_USER User errors T.EXPORT_OTHER Improper export of data T.FLAWED_CODE Flawed or incorrectly implemented software T.FLAW_USER Exploitation of known flaws T.IMPERSON_OTHER Impersonation of authorized user T.INSTALL Insecure delivery or installation TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 7 T.INTEGRITY_OTHER Compromise of data integrity T.INTENTIONAL_DISCLOSURE Intentional disclosure of data or software T.LINK_OTHER Analysis of observed activity T.LOSS_SOFTWARE Unintentional loss of software or application T.MALICIOUS_CODE Malicious code T.MASQUERADE_AUTHORIZED_USER Masquerade of authorized user T.MODIFY_OTHER Unauthorized modification or destruction of data T.NON_REPUDIATION_RECEIVE Repudiation by authorized receiver T.NON_REPUDIATION_SEND Repudiation by authorized sender T.NON_REPUDIATION_TRANSACTION Repudiation of authorized transaction T.OBSERVE_OTHER Unauthorized observation of legitimate activities T.OBSERVE_TOE Misplaced/incorrect belief in secure operation T.OPERATE Improper operation of system T.PHYSICAL_ATTACK Physical attack on system components and data T.RECORD_EVENT_TOE Failure to record security significant events T.REPLAY Replay T.SABOTAGE_DATA/SOFTWARE Intentional damage to data or system software T.SECRET_OTHER Exposure of data to authorized user without need-to-know T.SIGNAL_SYSTEM_DEVELOPER Emanations T.SOCIAL_ENGINEERING Social engineering attacks TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 8 T.SPOOFING Spoofing of user identities, system components, and data T.SPRINGBOARD Use of information system to mount attacks on other systems T.STEGANOGRAPHY Steganographic exfiltration

T.SYSTEM_CORRUPTED Intentional corruption of the system security state to enable future insecurities T.TAMPER Tampering with protection relevant system components T.TOE_CORRUPTED Corruption of system security status T.TRACEABLE_TOE Unable to trace events to users or processes T.TRAPDOOR_BENIGN_ADMIN Benign trapdoor installed by system administrator T.TRAPDOOR_MALICIOUS_CODE Malicious trapdoor provided by developer T.UNAUTHORIZED_MALICIOUS_SOFTWARE Unauthorized malicious software installed by user T.UNINTENTIONAL_DISCLOSURE Unintentional disclosure of data or software T.UNINTENTIONAL_MALICIOUS_SOFTWARE Unintentional malicious software installed by user 3.2.2 Non-TOE Threats T.ACCESS_MALICIOUS Unauthorized access by an authenticated user for malicious purposes T.ACCESS_NON_TECHNICAL Unauthorized access by authenticated user through non- technical means T.ACCESS_NON_TOE Unauthorized access by authenticated user through other assets T.ADMIN_ERROR System administrator error or omission T.ATTACK_OTHER Unauthorized action by perpetrator TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 9 T.AUDIT_CONFIDENTIALITY_NON_TOE Unauthorized disclosure of non-TOE audit trails T.AUDIT_CORRUPTED_NON_TOE Corruption of other system/network and manual audit trails T.CAPTURE Eavesdropping T.CRASH System crash T.EAVESDROPPING Unauthorized monitoring of networks or information systems T.ENTRY_NON_TECHNICAL Unauthenticated user gains access through non-technical means T.ENTRY_NON_TOE Unauthenticated user gains unauthorized access to other assets T.ENTRY_SOPHISTICATED Unauthenticated user gains access to other assets T.EXPORT_OTHER Improper export of data T.IMPERSON_OTHER Impersonation of authorized user T.INSTALL Insecure delivery or installation T.INTENTIONAL_DISCLOSURE Intentional disclosure of data or software T.LINK_OTHER Analysis of observed activity T.MAINTENANCE Poor Maintenance T.MALICIOUS_CODE Malicious code T.MASQUERADE_AUTHORIZED_USER Masquerade of authorized user T.MODIFY_OTHER Unauthorized modification or destruction of data T.NON_TOE_CORRUPTED Corruption of system security status T.OBSERVE_NON_TOE Misplaced/incorrect belief in secure operation of the security support structure T.OBSERVE_OTHER Unauthorized observation of legitimate activities TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 10 T.OPERATE Improper operation of system T.PHYSICAL Unauthorized hardware change T.PHYSICAL_ATTACK Physical attack on system components and data T.RECORD_EVENT_NON_TOE Failure to record security significant events on other assets T.SABOTAGE_DATA/SOFTWARE Intentional damage to data or system software T.SIGNAL_SYSTEM_DEVELOPER Emanations T.SOCIAL_ENGINEERING Social engineering attacks T.SPOOFING Spoofing of user identities, system components, and data T.SYSTEM_CORRUPTED Intentional corruption of the system security state to enable future insecurities T.TAMPER Tampering with protection relevant system components T.TRACEABLE_NON_TOE Unable to trace events to other systems users or environmental causes T.TRAPDOOR_BENIGN_ADMIN Benign trapdoor installed by system administrator T.UNINTENTIONAL_DISCLOSURE Unintentional disclosure of data or software T.UNINTENTIONAL_MALICIOUS_SOFTWARE Unintentional malicious software installed by user 3.3 Organizational Security Policies P.ACCOUNTABILITY Users are held accountable for their actions, and actions taken on their behalf, on the information system.

P.ALT_INFRASTRUCT Information system users have, based on mission need, continuing access to the information system hardware and software assets. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 11 P.AUTH_MGMT The process of generating, issuing, and using authenticators is managed in accordance with NNSA and site policies. P.COMPOSITION The security of an information system or network composed of individual information systems is equal to or greater than that of any individual system in the combined system. P.CONFIG_MGMT Protection features of a system are maintained during development, modification, and maintenance of the hardware, firmware, and software components. P.CONOPS Continuity of operations planning is applied to applications, data, and information systems. P.CREDENTIAL_PROTECTION Authentication credentials shall be protected to prevent unauthorized access, modification, or destruction. This policy requires that the individuals and IT entities that use the credentials adequately protect them. The information system supports this policy by restricting access to credentials, and protecting the credentials as they are transmitted over the network during the domain authentication process and through the trusted path between the credential reader and other information system components. P.CRYPTOGRAPHY Cryptographic services that are used to ensure information confidentiality, privacy, or integrity shall meet the criteria of the appropriate robustness (strength of mechanism and assurance) based on the value of information to be protected and the threat environment. P.DATA_ASSURANCE Modification of data is permitted only by authorized personnel. P.DATA_AVAILABILITY User and information system data are available or restorable to meet mission availability requirements P.DENY_ACCESS System resources are controlled to ensure access to information sources cannot be denied to authorized users. P.DUE_CARE The information and information system resources are implemented and operated in a manner that represents due care and diligence with respect to risks to the information and the organization. P.FILE_REVIEW An automated or administrative classification and sensitivity review is performed before release on all communications and files to be electronically transmitted TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 12 beyond the system boundary or to an interconnected system under the same management control and the same security policy constraints. P.FORENSICS Information needed for penetration reconstruction and analyzing ongoing or past cyber attacks and failures is identified, collected, and preserved in accordance with NNSA and site policies. P.IDS The information system is protected from unauthorized attempts to attack or penetrate the information system. P.INFO_FLOW Information flow between information system components is controlled in accordance with established policies. P.KNOWN All NNSA multi-user information systems, desktops, and laptops – excluding those information systems intended to provide public access (e. g., public web servers) – must have and use a mechanism that authenticates the identity of each person before providing access to any information system, application, service, or resource. P.LEAST_PRIV Privileges granted to information system users (including privileged users) are the most restrictive (least privilege) required for performance of authorized tasks.

P.MALICIOUS_CODE The information system is protected from hardware, software, and firmware designed to adversely impact the confidentiality, integrity, and availability of the system and information assets. P.MEDIA_MARKING All removable media components of the information system and output inside the system boundary are appropriately marked with the level and category of the highest information sensitivity of information that the system is accredited to operate or marked in accordance with a classification review or information sensitivity review by authorized personnel. P.MEDIA_REVIEW All media (paper, disks, zip drives, removable disk drives, etc.) are reviewed for classification and sensitivity and properly marked before release outside the system boundary. P.MONITORING All user activities, and activities on behalf of the user, are monitored and reviewed for activities that are detrimental to the confidentiality, integrity, or availability of the information or information system. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 13 P.NTK Access to data in information system resources is limited to users with the need-to-know for the information, regardless of the form of the information. Access rights to specific data objects are determined by object attributes, user identity, user attributes, and environmental conditions as defined by the security policy. P.PERSONNEL All users (including privileged users) are cleared or have appropriate background reviews according to NNSA and DOE policies for the highest level of information sensitivity; have formal access approval and an authorized need-to-know for the information to which he/she is allowed access. P.PHYSICAL The information and information system resources (including media) are physically protected according to the sensitivity of the information processed, stored, or transmitted by the components. P.PROTCTD_DOMAIN The information system security functions maintain a separate protected security domain for their own execution. To protect them from interference and tampering by other system activities and users, the components necessary for enforcing security policies shall be maintained within a separate security domain that. P.RESIDUAL_DATA All internal information system resources are cleared before reallocation of the resource to a different user. P.RISKASSESS Identification of system and environment vulnerabilities and an assessment of their impact on the system’s security are regularly performed. P.ROLE_SEPARATION Security roles and responsibilities are distributed to preclude any one individual from adversely affecting operations or the integrity of the system. P.SESSION_CTL User access to a system is determined by the authenticated user’s access profile. P.STRONG_AUTHENTICATION All users shall be authenticated by two-factor strong authentication mechanisms prior to being granted access to systems and the information and resources managed by those systems. P.SURVIVE The system in conjunction with its environment must be resilient to insecurity, resisting the insecurity, and/or providing the means to detect an insecurity and recover from it. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 14 P.SYS_ASSURANCE The information system’s security policy is maintained in the environment of distributed systems even if the systems are interconnected via an insecure networking medium (wire-lines, fiber, Internet, wireless, etc.).

P.SYS_RECOVERY Controlled or trusted secure system recovery occurs in the event of an information system failure. P.SYS_TESTING Certification and post-accreditation testing is applied to the information system in accordance with PCSP and DAA requirements. P.TRAINING All users are trained to understand applicable system use policies, the proper use of systems, and the vulnerabilities inherent to those systems. This policy ensures that all users are properly instructed on policies and procedures for using the system, as well as being able to acknowledge all threats and vulnerabilities that may impact system processing. P.TRUSTED_USER All users shall abide by designated policies and the conduct stated in those policies. In this context, “users” include user includes both users of systems that interface with the TOE, the administrators of the TOE, and the administrators of systems that interface with the TOE. This policy covers use and adherence to policies, procedures, system, admin, and user documentation associated with the TOE and all systems that interface with the TOE. P.UNIQUE_ID Every authorized user of an information system is uniquely identified. P.WARNING_BANNER All authorized users are notified that they are subject to being monitored, recorded, and audited through the use of an NNSA-approved warning text. Positive acknowledgement by the user is required before granting access to system resources. P.WFA Waste, Fraud, and Abuse is detected or prevented and reported accordance with DOE O 221.1, Reporting Waste Fraud, and Abuse to the Office of IG. 4. SECURITY OBJECTIVES 4.1 Security Objectives for the TOE O.ACCESS_HISTORY The information system user is notified upon successful logon of a) the date and time of the user’s last logon, b) the location of the user (as can best be determined) at last TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 15 logon, and c) the number of unsuccessful logon attempts using this user ID since the last successful logon. A positive action by the user is required to remove the notice. O.ACCESS_MALICIOUS Environmental controls are required to sufficiently mitigate (deterrence, detection, and response) the threat of malicious actions by authenticated users. Information system controls will help in achieving this objective but will not be sufficient. O.AUDIT_AUTOMATED_REVIEW Audit analysis and reporting of auditable events using automated tools must be scheduled and performed. O.AUDIT_BASIC The following activities must be recorded: • Successful use of the user security attribute administration functions. • All attempted uses of the user security attribute administration functions. • Identification of which user security attributes have been modified. With the exception of specific sensitive attribute data items (e.g., passwords, cryptographic keys); new values of the attributes should be captured. • Successful and unsuccessful logons and logoffs. • Unsuccessful access to security relevant files including creating, opening, closing, modifying, and deleting those files. • Changes in user authenticators. • Blocking or blacklisting user IDs, terminals, or access ports. • Denial of access for excessive logon attempts. • Starting and ending times for each access to the system O.AUDIT_CONTINUOUS_MONITORING Auditing must include the continuous, online monitoring of auditable events. The system must notify an authorized person when imminent violations of security policies are detected.

TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 16 O.AUDIT_FAILURE An alternate audit capability or system shutdown must occur in the event of audit failure or when the audit trail exceeds 80% of capacity. O.AUDIT_PROTECTION The contents of audit trails must be protected against unauthorized access, modification, or deletion. O.AUDIT_REVIEW A process shall be put in place for review of user activities and activities on behalf of the user on the TOE to detect and report actual or attempted circumvention of the TOE Security Functions (TSF). O.AUDIT_SELECTED_EVENTS The audit trail must include records of– (a) Privileged activities at the system console (either physical or logical consoles) and other system- level accesses by privileged users and (b) The creation, deletion, or changes in security labels. O.AUTHENT_EXPOSE The clear text display or exposure of any authenticator is only provided to the identified user during generation, issuance, storage, or use. O.AUTHORIZATION The TOE must ensure that only authorized users gain access to the information and TOE resources. The TOE must ensure for all actions under its control, except for a well-defined set of allowed actions, that all users are identified and authenticated before being granted access to subjects and objects. O.CREDENTIAL_PROTECTION Authentication credentials shall be protected from unauthorized access during creation, use, and handling. O.DATA_CHANGES_DETERRED Unauthorized changes to data in the information system are detected, deterred, and reported. O.DETECT_HOST_BASIC The information system environment (i.e., online) must provide the ability to detect low level (i.e., using methods readily available on the Internet to attack known vulnerabilities) attacks and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.DETECT_HOST_SOPHISTICATED TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 17 The information system environment (i.e., online), must provide the ability to detect sophisticated attacks and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.ENTRY_TOE The information system must prevent logical entry to the information system using unsophisticated, technical methods by persons without authority for such access. O.FULL_RESIDUAL_PROTECTION The information system must ensure that all non-media resources contain no residual data before being assigned, allocated, or reallocated. O.ID_DISABLE User TOE access is disabled when the user leaves the sponsoring organization, Access Authorization is terminated, loses authorized access (for cause, changes in organization, etc), or upon TOE detection of attempts to bypass security. O.ID_REMOVAL Prior to reuse of a user identifier, all previous access rights and privileges (including file accesses for that user identifier) are removed from the TOE O.INFO_FLOW The information system and information system environment must ensure that any information flow control policies are enforced between system components and at the system external interfaces. O.INTEGRITY_LOW The TOE will require user identification and authentication to validate the authority of the user for any changes to data. O.MALICIOUS_CODE The TOE must have the capability to detect and eliminate malicious code. Procedures to detect and deter incidents caused by malicious code are employed.

O.MANAGE_TOE The information system must provide all the functions and facilities necessary to support the authorized administrators that are responsible for the management of information system security. O.NTK_NNSA Access rights to specific data objects are determined by object attributes assigned to that object, user identity, user attributes, and any formal access rights or privileges that NNSA has established for the data. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 18 O.ORIGIN_PROOF A subject receiving information during a data exchange is provided evidence of the origin of the information. O.RECEIPT_PROOF A subject transmitting information during a data exchange is provided evidence of the receipt of the information. O.RECOVERY_SECURE Information system recovery occurs in a secure trusted manner. O.REPLAY The information system must detect and deter replay of entities, such as messages and service requests and responses. O.RESIDUAL_PROTECTION The information system must ensure that identified resources contain no residual data before being assigned, allocated, or reallocated. O.RESOURCE_USAGE The information system provides the capability to control a defined set of system resources (e. g., memory, and disk space) such that no one user can deny another user access to the resources. O.ROLE_SYS_ADM_and_CSSO The same person does not perform the functions of the CSSO and the system administrator. O.ROLES_OTHER_SECURITY Other roles involved with security administration, such as DBMS administration, are not performed by the same people performing the CSSO and system administrator roles. O.SEC_FUNC_MANAGEMENT The information system restricts management of information system security functions to authorized users. O.SESSION_ESTABLISHMENT The information system controls the establishment of sessions (a) by denying access after multiple (maximum of five) consecutive unsuccessful attempts on the same user ID; (b) by limiting the number of access attempts in a specified time period, (c) by use of a time-delay control system, or (d) by other such methods, subject to approval by the DAA O.SUBJECT_DOMAIN_SEPARATION The information system enforces domain separation for all information system subjects. O.TRANS_SEC_CLASS Information protection is required whenever classified information is to be transmitted, carried to, or carried through areas or components where individuals not TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 19 authorized to have access to the information may have unescorted physical or uncontrolled electronic access to the information or communications media (e. g., outside the system perimeter). One or more of the following must be used. • Information distributed only within an area approved for open storage of the information • National Security Agency (NSA)-approved encryption mechanisms appropriate for the encryption of classified information • Protected Transmission System • Trusted courier O.TRUSTED_PATH_COMMO The information system provides a trusted path between itself and the user for all communications. O.TSF_DOMAIN_SEPARATION The information system maintains a domain for its own execution that protects it from external interference and tampering (e. g., by reading or modifying its code and data structures). O.USER_INACTIVITY The information system must detect an interval of user inactivity, such as no keyboard entries, and disable any future user activity until the user reestablishes the correct identity with a valid authenticator.

O.USER_LOCKING The information system provides user initiated self-locking of interactive sessions. To unlock a user-locked session, the user must provide the correct identity with a valid authenticator. O.WARNING_BANNER All authorized users are notified that they are subject to being monitored, recorded, and audited through the use of an NNSA-approved warning text and positive acknowledgement by the user is required before granting the user access to system resources. 4.2 Security Objectives for the Environment O.ACCESS Each user’s access rights and privileges are authorized prior to the user's first access to the TOE. O.ACCESS_AUTH_Q All users (including privileged users) shall possess, at a minimum, a current "Q" Access Authorization prior to their first access to the TOE TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 20 O.ACCESS_FORMAL Prior to the first access to information, each user’s need-to- know is formally authorized by management or the data owner-steward through a position description or written access list. O.ACCESS_MALICIOUS Environmental controls are required to sufficiently mitigate (i.e., deterrence, detection, and response) the threat of malicious actions by authenticated users. Information system controls will help in achieving this objective but are not sufficient alone. O.AUDIT_PROTECTION The contents of audit trails must be protected against unauthorized access, modification, or deletion. O.AUTHORIZE_NON_TOE The IT other than the information system must provide the ability to specify and manage user and system process access rights to individual processing resources and data elements under its control, supporting the organization’s security policy for access control. O.AVAILABILITY_LOW Resources are provided to allow the information system user to perform data backup at the user’s discretion. O.CLEARING The information system components and removable media are cleared before the items can be reused in another system environment with the same or different accreditation level as the original system components or removable media. O.COVERT_CHANNEL_REVIEW The information system must be reviewed to identify obvious covert channels with a bandwidth greater than 1,000 bytes per second O.CREDENTIAL_PROTECTION Authentication credentials shall be protected from unauthorized access during creation, use, and handling. O.DATA_BACKUP_BASIC User and information system data are available or restorable to meet mission availability requirements. Periodic checking of backup inventory and testing of the ability to restore information are accomplished to validate mission availability requirements are met. O.DETECT_EXTERNAL_BASIC The site environment (i.e., online) must provide the ability to detect low level (i.e., using methods readily available on the Internet to attack known vulnerabilities) attacks on the hosts and networks from outside the site and the results of such attacks (e.g., corrupted system state), including TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 21 measures to detect and respond to unauthorized attempts to penetrate or deny use. O.DETECT_EXTERNAL_SOPHISTICATED The site environment (i.e., online) must provide the ability to detect sophisticated attacks on the hosts and networks from outside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use.

O.DETECT_NETWORK_BASIC The network environment (i.e., online) must provide the ability to detect low level (i.e., using methods readily available on the Internet to attack known vulnerabilities) attacks on the network and its components and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.DETECT_NETWORK_SOPHISTICATED The network environment (i.e., online) must provide the ability to detect sophisticated attacks on the network and its components and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.DETECT_SITE_BASIC The site environment (i.e., physical) must provide the ability to detect low level (i.e., using readily available methods to attack known vulnerabilities) attacks on the hosts and networks from inside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.DETECT_SITE_SOPHISTICATED The site environment (i.e., physical) must provide the ability to detect sophisticated attacks on the hosts and networks from inside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. O.ENTRY_NON_TECHNICAL The information system environment must provide sufficient protection against non-technical attacks by other than authenticated users. User training and awareness will provide a major part of achieving this objective. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 22 O.ENTRY_NON_TOE For resources not controlled by the information system, IT other than the information system must prevent logical entry using unsophisticated, technical methods by persons without authority for such access. O.FORENSICS_PROC Procedures are established and documented to ensure the identification, collection, and preservation of data needed to analyze penetration reconstruction, on-going cyber attacks, and/or failures O.HARDWARE_EXAM_COMPREHENSIVE Information system hardware components are examined for security impacts to the information system before use. In addition, the hardware review will validate the chip sets and boards are from the manufacturer and using the manufacturer diagnostics confirm they function as expected. O.ID_DISABLE User TOE access is disabled when the user leaves the sponsoring organization, Access Authorization is terminated or lost (for cause, changes in organization, etc), or upon TOE detection of attempts to bypass security. O.ID_REMOVAL Prior to reuse of a user identifier, all previous access rights and privileges (including file accesses for that user identifier) are removed from the TOE O.ID_REVALIDATION User access, contact information, rights, and privileges, including sponsor, Access Authorization, need-to-know, means for offline contact, and mailing address, are validated annually. O.INFO_FLOW The information system and information system environment must ensure that any information flow control policies are enforced between system components and at the system external interfaces. O.MARK_COMPONENT Each host, visual display, and output device will be marked with the sensitivity label (level) of the most sensitive information group the system is accredited to process, store, or transmit.

O.MARK_OUTPUT All system output and removable media are appropriately marked with the level and category of the highest information sensitivity of the information groups the system is accredited to operate with, or marked in with the sensitivity label for the information. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 23 O.MEDIA_REVIEW All media (paper, disks, zip drives, removable disk drives, etc.) are reviewed for classification and sensitivity and properly marked before release outside the system boundary. O.NETWORK_INTERFACE The developers of the information system must ensure the information system security is not affected by the characteristics of the network(s) to which the information system is interfaced. O.PHY_CLASSIFIED Systems containing classified Top Secret (TS) information may be protected in one of the following ways: constantly attended or under the control of a person that possesses proper Access Authorization, formal access approval, and need to know; in a locked General Services Administration (GSA) approved container with supplemental controls; or in a vault or vault-type room. Specific criteria are defined in DOE orders. Systems containing classified Secret information shall be protected in one of the following ways: constantly attended or under the control of a person that possesses proper Access Authorization, formal access approval, and need to know; in a locked GSA approved container; or in a vault or vault-type room. Systems containing classified Confidential information shall be stored in manner authorized for Secret or a GSA approved security container. O.PHYSICAL Physical attack that might compromise IT security on those parts of the information system critical to security is deterred and detected, primarily via prevention within the limits of COTS technology. O.PHYSICAL_PROTECTION The individuals responsible for the information system must ensure that the environment is capable of physically protecting the information system by signaling the occurrence of fire, flood, power loss, and environmental control failures that might adversely affect information system operations. O.RECOVERY_SECURE Information system recovery occurs in a secure trusted manner. O.REPLAY The information system must detect and deter replay of entities, such as messages and service requests and responses. O.ROLE_SYS_ADM_and_CSSO The same person does not perform the functions of the CSSO and the system administrator. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 24 O.ROLES_OTHER_SECURITY Other roles involved with security administration, such as DBMS administration, are not performed by the same people performing the CSSO and system administrator roles. O.ROLES_TWO_PERSON The CSSO and system administrator are present when audit parameters or audit file contents are modified. O.SANITIZATION All information system components and removable media are sanitized, using approved NNSA procedures, prior to release for use at a lower classification level, at a lower level of consequence, or outside the information system boundary. O.SOFTWARE_EXAM_COMPREHENSIVE Software is examined to determine if the software conforms to the security relevant controls as documented by the developer. The examination will also determine if the controls can be bypassed or subverted O.TRAINING All users are trained to understand applicable information system-use policies, the approved use of the information system, and the vulnerabilities inherent in the operation of the information system.

O.TRANS_SEC_CLASS Information protection is required whenever classified information is to be transmitted, carried to, or carried through areas or components where individuals not authorized to have access to the information may have unescorted physical or uncontrolled electronic access to the information or communications media (e. g., outside the system perimeter). One or more of the following must be used • Information distributed only within an area approved for open storage of the information • National Security Agency (NSA)-approved encryption mechanisms appropriate for the encryption of classified information • Protected Transmission System • Trusted courier O.UNESCORT_ACCESS_CLASSIFIED Access controls ensure that personnel granted unescorted physical access to information, the information system or TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 25 human readable media have the appropriate security clearance, access approvals and need-to-know. O.WARNING_BANNER All authorized users are notified that they are subject to being monitored, recorded, and audited through the use of an NNSA approved warning text and positive acknowledgement by the user is required before granting the user access to system resources. 5. IT SECURITY REQUIREMENTS This section defines the functional requirements for the TOE. Functional requirements components in this profile were drawn from Part 2 of the Common Criteria (CC). Some functional requirements are extensions to those found in the CC. CC-defined operations for assignment, selection, and refinement were used to tailor the requirements to the level of detail necessary to meet the stated security objectives. These operations are indicated through the use of underlined (assignments and selections) and italicized (refinements) text. All required operations not performed within this profile are clearly identified and described such that they can be correctly performed upon instantiation of the PP into a Security Target (ST) specification. NOTE: Where italicized items are listed in an assignment or selection clause in one of the following components, the ST developer must address the component and provide the information identified in the italicized clause. If the assignment or selection clause is not italicized, the item is mandatory and must be addressed in the ST. 5.1 TOE Security Functional Requirements 5.1.1 FAU_ARP.1 Security alarms 5.1.1.1 FAU_ARP.1.1 The TSF shall take [assignment: list of the least disruptive actions] upon detection of a potential security violation. Application Note: The ST must state the actions taken by the TOE when a potential security violation, such as detection of malicious code is identified, or a successful or unsuccessful intrusion occurs. 5.1.2 FAU_GEN.1 Audit data generation 5.1.2.1 FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: (a) Start-up and shutdown of the audit functions; (b) All auditable events for the basic level of audit; and (c) [assignment: The events listed below: TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 26 § Successful use of the user security attribute administration functions; § All attempted uses of the user security attribute administration functions; § Identification of which user security attributes have been modified. § Successful and unsuccessful logons and logoffs; § Unsuccessful access to security relevant files including

creating, opening, closing, modifying, and deleting those files; § Changes in user authenticators; § Blocking or blacklisting user Ids, terminals, or access ports; § Denial of access for excessive logon attempts; § System accesses by privileged users; § Privileged activities at the system console (either physical or logical consoles) and other system- level accesses by privileged users; § Starting and ending times for each access to the system; and § The creation, deletion, or changes in security labels. (d) other security relevant events]. Application Note: In some situations, it is possible that some events cannot be automatically generated, usually because the audit functions were not operational at the time of the event. Such events should be documented in administrative guidance, along with recommendations on how manual auditing should be established to cover these events. The "basic" level of auditing was selected as best representing the "mainstream" of contemporary audit practices used in the target environments. 5.1.2.2 FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: (a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; (b) The sensitivity labels of subjects, objects, or information involved; (c) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, (d) [assignment: source host identity, and other audit relevant information] TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 27 Application Note: In some situations, it is possible that some events cannot be automatically generated, usually because the audit functions are not operational at the time of the event. Such events should be documented in the Administrative Guidance, along with recommendation on how manual auditing should be established to cover these events. The source host identity is the identity of a TOE component or another TOE that initiated or attempted to initiate activity with the TOE/TOE component covered by the ST. The identity may be recorded in terms of IP address, DNS name, certificate, or some other unique identifier. 5.1.3 FAU_GEN.2 User identity association 5.1.3.1 FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user that caused the event. Application Note: There are some auditable events that may not be associated with a user, such as failed login attempts. It is acceptable that such events do not include a user identity. In the case of failed login attempts, it is also acceptable not to record the attempted identity when it could be misdirected authentication data (for example, when the user may have been out-of-sync and typed a password in place of a user identifier). 5.1.4 FAU_SAA.2 Profile based anomaly detection 5.1.4.1 FAU_SAA.2.1 The TSF shall be able to maintain profiles of systems usage, where an individual profile represents the historical patterns of usage performed by the members of [assignment: single users and/or group account and the profile target group]. 5.1.4.2 FAU_SAA.2.2 The TSF shall be able to maintain a suspicious rating associated with each user whose activity is recorded in the profile, where the suspicious rating represents the degree to which the user’s current activity is found inconsistent with the established patterns of usage represented in the profile.

5.1.4.3 FAU_SAA.2.3 The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold condition [assignment: conditions under which anomalous activity is reported by the TSF]. Application Note: The ST must describe the auditable events that are known or suspected to indicate a potential security violation. 5.1.5 FAU_SAA.4 Complex attack heuristics 5.1.5.1 FAU_SAA.4.1 The TSF shall be able to maintain an internal representation of the following event sequences of known intrusion scenarios [assignment: list of sequences of system events whose occurrence are representative of known penetration scenarios] and the following signature events [assignment: a subset of system events] that may indicate a potential violation of the TSP. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 28 Application Note: The ST must describe or reference documentation of known or suspected system events and penetration scenarios that may indicate a potential security violation. The specific manner of implementation is TOE-dependent and can be achieved through the use of intrusion detection software on the TOE or in the local area network where the TOE is located. 5.1.5.2 FAU_SAA.4.2 The TSF shall be able to compare the signature events and event sequences against the record of system activity discernible from an examination of [assignment: the information to be used to determine system activity]. Application Note: See Application Note for FAU_SAA.4.1. 5.1.5.3 FAU_SAA.4.3 The TSF shall be able to indicate an imminent violation of the TSP when system activity is found to match a signature event or event sequence that indicates a potential violation of the TSP. Application Note: See Application Note for FAU_SAA.4.1. 5.1.6 FAU_SAR.1 Audit review 5.1.6.1 FAU_SAR.1.1 The TSF shall provide [assignment: Computer System Security Officers (CSSO) and authorized system administrators] with the capability to read all audit information from the audit records. Application Note: The minimum information that must be recorded is the same that is required in FAU_GEN.1.1. To fulfill this requirement, the system administrator must have a tool available that allows access to the audit trail for assessment purposes. Exactly what “tool” is provided is an implementation decision, but it must allow the CSSO and/or administrator to make effective use of the information presented. This requirement is closely tied to FAU_SAR.3 and FAU_SEL.1. It is expected that a single tool will exist within the TSF that will satisfy all of these requirements. 5.1.6.2 FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. 5.1.7 FAU_SAR.2 Restricted Audit Review 5.1.7.1 FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been granted explicit read-access. Application Note: By default, CSSOs and authorized system administrators may be considered to have been granted read access to the audit records. The TSF may provide a mechanism that allows other users to also read audit records. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 29 5.1.8 FAU_SAR.3 Selectable audit review 5.1.8.1 FAU_SAR.3.1 The TSF shall provide the ability to perform [selection: searches, sorting] of audit data based on [assignment: the following attributes: (a) User identity; (b) Subject sensitivity label;

(c) Object sensitivity label; (d) Source host identity; (e) list of additional attributes that audit selectivity is based upon]. Application Note: The ST must state the additional attributes that audit selectivity may be based upon (e. g., object identity, type of event), if any. 5.1.9 FAU_SEL.1 Selective Audit 5.1.9.1 FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes: (a) [selection: User identity, source host identity, and event type; (b) [assignment: Subject sensitivity label; Object sensitivity label; and (c) list of additional attributes that audit selectivity is based upon]. Application Note: The ST must state the additional attributes that audit selectivity may be based upon (e. g., object identity, type of event), if any. 5.1.10 FAU_STG.2 Guarantees of audit data availability 5.1.10.1 FAU_STG.2.1 The TSF shall protect the stored audit records from unauthorized deletion. 5.1.10.2 FAU_STG.2.2 The TSF shall be able to [selection: prevent] modifications to the audit records. Application Note: On many systems, to reduce the performance impact of audit generation, audit records will be temporarily buffered in memory before they are written to disk. In these cases, it is likely that some of these records will be lost if the operation of the TOE is interrupted by hardware or power failures. The developer needs to document what the likely loss will be and show that it has been minimized. 5.1.10.3 FAU_STG.2.3 The TSF shall ensure that [assignment: all audit records already written to media, i.e., not in memory buffers,] will be maintained TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 30 when the following conditions occur: [selection: audit storage exhaustion, failure, and attack]. 5.1.11 FAU_STG.3 Action in case of possible audit data loss 5.1.11.1 FAU_STG.3.1 The TSF shall [assignment: generate an alarm to the CSSO or authorized system administrator] if the audit trail exceeds [assignment: 80% of capacity.] Application Note: For this component, an "alarm" is to be interpreted as any clear indication to the administrator that the pre-defined limit has been exceeded. The ST author must state the pre-defined limit that triggers generation of the alarm. The limit can be stated as an absolute value or as a value that represents a percentage of audit trail capacity (e. g., audit trail 80% full). If the limit is adjustable by the authorized administrator, the ST should also incorporate an FMT requirement to manage this function. 5.1.12 FAU_STG.4 Prevention of audit data loss 5.1.12.1 FAU_STG.4.1 The TSF shall [assignment: be able to prevent auditable events, except those taken by the CSSO or authorized system administrator,] and [assignment: record auditable events created by the CSSO or authorized administrator and other actions to be taken in case of audit storage failure] if the audit trail is full. Application Note: The selection of "preventing auditable actions if audit storage is exhausted" is minimal functionality; providing a range of configurable choices (e. g., ignoring auditable actions and/or changing to a degraded mode) is allowable, as long as "preventing" is one of the choices. If configurable, then FMT_ MOF.1 should be incorporated into the ST. 5.1.13 FCO_NRO.1 Selective proof of origin

5.1.13.1 FCO_NRO.1.1 The TSF shall be able to generate evidence of origin for transmitted [assignment: e-mail, files, and list of information types] at the request of the [selection: originator, recipient, [assignment: and CSSO]]. 5.1.13.2 FCO_NRO.1.2 The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies. 5.1.13.3 FCO_NRO.1.3 The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin]. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 31 5.1.14 FCO_NRR.1 Selective proof of receipt 5.1.14.1 FCO_NRR.1.1 The TSF shall be able to generate evidence of receipt for received [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: and CSSO]]. 5.1.14.2 FCO_NRR.1.2 The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies. 5.1.14.3 FCO_NRR.1.3 The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of receipt]. 5.1.15 FCS_CKM.4 Cryptographic key destruction 5.1.15.1 FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: cryptographic key destruction method] that meets the following: [assignment: list of standards]. Application Note: If cryptographic keys are used the ST implementation, the method and standard used to destroy these keys must be documented. If cryptographic keys are not used, this should be stated in the implementation note. 5.1.16 FCS_COP.1 Cryptographic operation 5.1.16.1 FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. Application Note: If cryptographic keys are used, the ST implementation note must identify how the cryptography is utilized and describe the key standards. If cryptographic keys are not used, this should be stated in the implementation note. 5.1.17 FDP_ACC.2 Complete access control 5.1.17.1 FDP_ACC.2.1 The TSF shall enforce the [assignment: Discretionary Access Control (DAC) as the access control SFP] on [assignment: list of subjects and objects] and all operations among subjects and objects covered by the access control SFP. . TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 32 Application Note: For most systems, there is only one type of subject, usually called a process or task, that needs to be specified in the ST. Named objects are objects used to share information among subjects acting on the behalf of different users and for which access to the object can be specified by a name or other identity. Any object that meets this criterion but is not controlled by the DAC policy must be justified.

The list of operations covers all operations between the above two lists. It may consist of a sublist for each subject-named object pair. Each operation must specify which type of access right is needed to perform the operation (for example, read access or write access). 5.1.17.2 FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by an access control SFP. 5.1.18 FDP_ACF.1 Security attribute based access control 5.1.18.1 FDP_ACF.1.1 The TSF shall enforce the [assignment: Discretionary Access Control Policy] to objects based on [assignment: the following: (a) The user identity and group membership(s) associated with a subject; and (b) List access control attributes. The attributes must provide permission attributes with: 1. the ability to associate allowed or denied operations with one or more user identities; 2. the ability to associate allowed or denied operations with one or more group identities; and 3. defaults for allowed or denied operations]. 5.1.18.2 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: a set of rules specifying the Mandatory Access Control policy, where: (a) For each operation there shall be a rule, or rules, that use the permission attributes where the user identity of the subject matches a user identity specified in the access control attributes of the object; (b) For each operation there shall be a rule, or rules, that use the permission attributes where the group membership of the subject TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 33 matches a group identity specified in the access control attributes of the object; and (c) For each operation there shall be a rule, or rules, which use the default permission attributes specified in the access control attributes of the object when neither a user identity nor group identity matches]. Application Note: A TOE that conforms to this PP is required to implement a MAC policy, but the rules that govern the policy may vary between TOEs. Those rules must be specified in the ST. In completing the rule assignment above, the resulting mechanism must be able to specify access rules that apply to at least any single user. This single user may have a special status such as the owner of the object. The mechanism must also support specifying access to the membership of at least any single group. Conformant implementations include self/group/public controls and access control lists. A MAC policy may cover rules on accessing public objects (i.e., objects that are readable to all authorized users but can only be altered by the TSF or authorized administrators). Specification of these rules should be covered under FDP_ACF.1.3 and FDP_ACF.1.4. A MAC policy may include exceptions to the basic policy for access by authorized administrators or other forms of special authorization. These rules should be covered under FDP_ACF.1.3. The ST must list the attributes that are used by the MAC policy for access decisions. These attributes may include permission bits, access control lists, and object ownership. A single set of access control attributes may be associated with multiple objects, such as all objects stored on a single floppy disk. The association may also be indirectly bound to the object, such as access control attributes being associated with the name of the object rather than directly to the object itself.

5.1.18.3 FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]. 5.1.18.4 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]. Application Note: A TOE that conforms to this PP is required to implement a MAC policy, but the rules that govern the policy may vary between TOE components. Those rules need to be specified in the ST. In completing the rule assignment above, the resulting mechanism must be able to specify access rules that apply to at least any single user. This single user may have a special status, such as the owner of the object. The mechanism must also support specifying access to the membership of at least any single group. Conformant implementations include self/group/public controls and access control lists. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 34 A MAC policy may cover rules on accessing public objects (i.e. objects that are readable to all authorized users but can only be altered by the TSF or authorized administrators). Specification of these rules should be covered under 5.1.18.3 and 5.1.18.4 . A MAC policy may include exceptions to the basic policy for access by authorized administrators or other forms of special authorization. These rules should be covered under 5.1.18.3 . The ST must list the attributes used by the MAC policy for access decisions. These attributes may include permission bits, access control lists, and object ownership. A single set of access control attributes may be associated with multiple objects, such as all objects stored on a single floppy disk. The association may also be indirectly bound to the object, such as access control attributes being associated with the name of the object rather than directly to the object itself. 5.1.19 FDP_DAU.1 Basic data authentication 5.1.19.1 FDP_DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of [assignment: list of objects or information types]. 5.1.19.2 FDP_DAU.1.2 The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information. 5.1.20 FDP_ETC.1 Export of User Data Without Security Attributes 5.1.20.1 FDP_ETC.1.1 The TSF shall enforce the [assignment: Mandatory Access Control Policy] when exporting user data, controlled under the MAC policy, outside the TSC. 5.1.20.2 FDP_ETC.1.2 The TSF shall export the user data without the user data’s associated security attributes. Application Note: A TOE conforming to this PP must provide protections to data exported outside the control of the TSC via any communications mechanisms that do not provide security attributes along with the actual data. The device or mechanism used to export information must have security attributes that correspond to those of the information being exported. The ability to export information must be allowed under the existing rules that establish the MAC policy of the TOE. Human-readable hardcopy output must be properly marked with appropriate labels on the top and bottom of pages and on the banner pages at the beginning and end of each output. The ST author must explicitly state the procedures under which this will be accomplished (e. g., use of pre-labeled paper is allowable).

The ST author must also explicitly state the rules under which authorized users can designate the security attributes of the mechanisms or devices used to export data without security attributes. The ST author must also make it clear that mechanisms or TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 35 devices used to export data without security attributes cannot also be used to export data with security attributes unless this change in state can only be done manually and is audited. Single-level Input/Output devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. 5.1.21 FDP_ETC.2 Export of user data with security attributes 5.1.21.1 FDP_ETC.2.1 The TSF shall enforce the [assignment: Mandatory Access Control Policy] when exporting user data, controlled under the MAC policy, outside the TSC. 5.1.21.2 FDP_ETC.2.2 The TSF shall export the user data with the user data’s associated security attributes. 5.1.21.3 FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously associated with the exported user data. 5.1.21.4 FDP_ETC.2.4 The TSF shall enforce the following rules when user data are exported from the TSC: [assignment: (a) When data are exported in a human-readable or printable form: i. The authorized administrator shall be able to specify the printable label that is assigned to the sensitivity label associated with the data. ii. Each print job shall be marked at the beginning and end with the printable label assigned to the “least upper bound” sensitivity label of all the data exported in the print job. iii. Each page of printed output shall be marked with the printable label assigned to the “least upper bound” sensitivity label of all the data exported to the page. By default this marking shall appear on both the top and bottom of each printed page. (b) Devices used to export data with security attributes cannot be used to export data without security attributes unless the change in device state is performed manually and is auditable; (c) Devices used to export data with security attributes shall completely and unambiguously associate the security attributes with the corresponding data; and (d) additional exportation control rules]. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 36 Application Note: The ST author may establish rules that control the export of information from the TSC. These rules must reflect the nature of both the object types and the actual object security attributes. In all cases, the TOE must export the security attributes with the corresponding information. A TOE conforming to this PP must only use protocols to export data with security attributes that provide unambiguous pairings of security attributes and the information being exported. Further, the ST author must make it clear that the mechanisms or devices used to export data with security attributes cannot be used to export data without security attributes unless this change in state can only be done manually and is audited. In addition, the security attributes must be exported to the same mechanism or device as the information. Also, any change in the security attributes settings of a device must be audited.

Explicit rules must exist in the ST for the export of information that represents hardcopy output. The rules must capture the requirements for printing labels on the first and last pages, top and bottom of pages, etc.; any overriding of printed labels must be audited. Further, the ST must make certain that the external form of the security attributes must accurately and unambiguously represent the internal label. 5.1.22 FDP_IFC.1 Subset information flow control 5.1.22.1 FDP_IFC.1.1 The TSF shall enforce the [assignment: Mandatory Access Control (MAC) Security Function Policy (SFP)] on [assignment: subjects, objects, and all operations among subjects and objects covered by the SFP]. Application Note: For most systems, there is only one type of subject, usually called a process or task, that must be specified in the ST. Named objects are used to share information among subjects acting on the behalf of different users and for which access can be specified by a name or other identity. Any object that meets this criterion but is not controlled by the DAC policy must be justified. The ST author must also explicitly list the objects that exist in the TOE. This list must include storage objects. Objects should include data storage resources as well as input/ output devices, etc. The operations listed in the ST among subjects and objects must explicitly define all relationships between subjects and objects in the TOE and must be consistent with the list of objects defined in the earlier assignment. A subject is an entity within the TSC that causes operations to be performed. 5.1.23 FDP_IFF.2 Hierarchical security attributes 5.1.23.1 FDP_IFF.2.1 The TSF shall enforce the [assignment: Mandatory Access Control Policy] based on the following types of subject and information security attributes: [assignment: TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 37 (a) The sensitivity label of the subject; and (b) The sensitivity label of the object containing the information. (c) Sensitivity label of subjects and objects shall consist of the following: i. A hierarchical level and ii. A set of non- hierarchical categories]. 5.1.23.2 FDP_IFF.2.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules, based on the ordering relationships between security attributes hold: [assignment: (a) If the sensitivity label of the subject is greater than or equal to the sensitivity label of the object, then the flow of information from the object to the subject is permitted (a read operation); (b) If the sensitivity label of the object is greater than or equal to the sensitivity label of the subject; then the flow of information from the subject to the object is permitted (a write operation); (c) If the sensitivity label of subject A is greater than or equal to the sensitivity label of subject B; then the flow of information from subject B to subject A is permitted]. 5.1.23.3 FDP_IFF.2.3 The TSF shall enforce the [assignment: additional information flow control SFP rules]. 5.1.23.4 FDP_IFF.2.4 The TSF shall provide the following [assignment: list of additional SFP capabilities]. 5.1.23.5 FDP_IFF.2.5 The TSF shall explicitly authorize an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorize information flows].

5.1.23.6 FDP_IFF.2.6 The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows]. 5.1.23.7 FDP_IFF.2.7 The TSF shall enforce the following relationships for any two valid sensitivity labels: (a) There exists an ordering function that, given two valid sensitivity labels, determines if the sensitivity labels are equal, if one sensitivity label is greater than the other, or if the sensitivity labels are incomparable; and TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 38 (b) Sensitivity labels are equal if the hierarchical levels of both labels are equal and the non-hierarchically category sets are equal. (c) Sensitivity label A is greater than sensitivity label B if one of the following conditions exists: • If the hierarchical level of A is greater than the hierarchical level of B, and the non-hierarchical category set of A is equal to the non-hierarchical category set of B. • If the hierarchical level of A is equal to the hierarchical level of B, and the non-hierarchical category set of A is a proper superset of the nonhierarchical category set of B. • If the hierarchical level of A is greater than the hierarchical level of B, and the non-hierarchical category set of A is a proper superset of the nonhierarchical category set of B. (d) Sensitivity labels are incomparable if they are not equal and neither label is greater than the other. (e) There exists a “least upper bound” in the set of sensitivity labels, such that, given any two valid sensitivity labels, there is a valid sensitivity label that is greater than or equal to the two valid sensitivity labels; and (f) There exists a “greatest lower bound” in the set of the sensitivity labels, such that, given any two valid sensitivity labels, there is a valid sensitivity label that is not greater than the two valid sensitivity labels. Application Note: The terms “security attribute” and “information flow control security attribute” refer to the sensitivity labels of subjects and objects. A TOE conforming to this PP should support at least 16 site-definable hierarchical levels and 64 site- definable non-hierarchical categories. The implementation of sensitivity labels does not need to store labels in a format that has the components of the label explicitly instantiated but may use some form of tag that maps to a level and category set. 5.1.24 FDP_ITC.1 Import of user data without security attributes 5.1.24.1 FDP_ITC.1.1 The TSF shall enforce the [assignment: Mandatory Access Control Policy] when importing user data, controlled under the SFP [MAC policy], from outside the TSC. 5.1.24.2 FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data when imported from outside the TSC. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 39 5.1.24.3 FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data controlled under the SFP (MAC policy) from outside the TSC: [assignment: (a) Devices used to import data without security attributes cannot be used to import data with security attributes unless the change in device state is performed manually and is auditable. (b) additional importation control rules].

Application Note: The TOE conforming to this PP must provide protections for data imported from outside the control of the TSC via functions that do not provide reliable security attributes along with the actual data. The imported data must be assigned a sensitivity label that will be used to enforce the MAC policy. Further, the ability for a subject to import information must be controlled under the existing rules that establish the MAC policy of the TOE. The ST author must explicitly state the rules under which authorized users can designate the security attributes of the mechanisms or devices used to import data without security attributes; any attribute change must be audited. The ST author must also make it clear that mechanisms or devices used to import data without security attributes cannot also be used to import data with security attributes unless this change in state can only be done manually and is audited. 5.1.25 FDP_ITC.2 Import of user data with security attributes 5.1.25.1 FDP_ITC.2.1 The TSF shall enforce the [assignment: Mandatory Access Control Policy] when importing user data, controlled under the SFP (MAC policy), from outside the TSC. 5.1.25.2 FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported user data. 5.1.25.3 FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous association between security attributes and the user data received. 5.1.25.4 FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. 5.1.25.5 FDP_ITC.2.5 The TSF shall enforce the following rules when importing user data controlled under the MAC policy from outside the TSC: [assignment: (a) Devices used to import data with security attributes cannot be used to import data without security attributes unless the change in device state is performed manually and is auditable; TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 40 (b) additional importation control rules]. Application Note: The ST author must provide for the protection of data imported from outside the control of the TSC via any mechanisms that provide security attributes along with the information being imported. The security attributes received along with the data must accurately represent the security attributes of the data with which they are associated. The ST author must make it clear that the mechanism or device used to import data with security attributes cannot be used to import data without security attributes unless this change in state can only be done manually and is audited. Also, any change in the security attributes of a device must be audited. 5.1.26 FDP_RIP.2 Full residual information protection 5.1.26.1 FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [assignment: allocation of the resource to] all objects. Application Note: This requirement applies to all resources governed by or used by the TSF; it includes resources used to store data and attributes. It also includes the encrypted representation of information. Clearing the information content store of resources on de-allocation from objects is sufficient to satisfy this requirement, if unallocated resources will not accumulate new information until they are allocated again. 5.1.27 FDP_SDI.2 Stored data integrity monitoring and action

5.1.27.1 FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for [assignment: unauthorized modification and unauthorized deletion] on all objects, based on the following attributes: [assignment: user data attributes]. Application Note: The ST must describe the user data attributes (i.e. file names, directory names, sizes, etc.) that will be used in the detection of unauthorized activities on the data. 5.1.27.2 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: enter a description of the error in the audit log and issue an alarm]. Application Note: For this component, an "alarm" is to be interpreted as any clear indication to the administrator that a data integrity error has been detected. The ST must state the conditions that trigger generation of the alarm. . TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 41 5.1.28 FIA_AFL.1 Authentication failure handling 5.1.28.1 FIA_AFL.1.1 The TSF shall detect when [assignment: five (5) consecutive] unsuccessful authentication attempts occur related to [assignment: list of authentication events]. Application Note: The ST must state the authentication events that will be monitored for 5 consecutive unsuccessful authentication attempts. The ST should also identify any authentication activities that are not monitored for unsuccessful authentication attempts. 5.1.28.2 FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment: list of actions]. 5.1.29 FIA_ATD.1 User attribute definition 5.1.29.1 FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [assignment: (a) User Identifier; (b) Group Memberships; (c) Authentication Data; (d) User Clearances; (e) Security-relevant Roles; (f) The user identity which is associated with auditable events; (g) The user identity or identities which are used to enforce the Discretionary Access Control policy; (h) The sensitivity label used to enforce the Mandatory Access Control policy which consists of; • A set of hierarchical level; and • A set of non-hierarchical categories. (i) The group membership or memberships used to enforce the Discretionary Access Control policy; and (j) other user security attributes]. Application Note: The specified attributes are those that are required by the TSF to enforce the DAC and MAC policies, the generation of audit records, and proper TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 42 identification and authentication of users. The user identity must be uniquely associated with a single user. Group membership may be expressed in a number of ways: a list per user specifying to which groups the user belongs, a list per group that includes which users are members, or implicit association between certain user identities and certain groups. A TOE may have two forms of user and group identities, a text form and a numeric form. In these cases there must be unique mapping between the representations. 5.1.30 FIA_SOS.1 Verification of secrets 5.1.30.1 FIA_ SOS.1 The TSF shall provide a mechanism to verify that secrets meet [assignment: the P.STRONG_AUTHENTICATION policy]. Application Note: The method of authentication is unspecified by this PP but must be specified in a ST. The method used must be shown to implement the P.STRONG_AUTHENTICATION policy. If a password mechanism is used, the mechanism must comply with NNSA password policies. The strength of whatever mechanism implemented must be subjected to strength of function analysis. (See AVA_SOF.1)

5.1.31 FIA_UAU.2 User Authentication before any action 5.1.31.1 FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 5.1.32 FIA_UAU.5 Multiple authentication mechanisms 5.1.32.1 FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authentication mechanisms] to support user authentication. 5.1.32.2 FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to the [assignment: rules describing how the multiple authentication mechanisms provide authentication]. 5.1.33 FIA_UAU.6 Re-authenticating 5.1.33.1 FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [assignment: of unlocking as a result of FAU_SSL.2, list of conditions under which re-authentication is required]. 5.1.34 FIA_UAU.7 Protected authentication feedback 5.1.34.1 FIA_UAU.7.1 The TSF shall provide only [assignment: obscured feedback] to the user while the authentication is in progress. Application Note: Obscured feedback implies the TSF does not produce a visible display of any authentication data entered by a user, such as through a keyboard (e. g., TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 43 echo the password on the terminal). It is acceptable that some indication of progress be returned instead, such as a “period” returned for each character sent. Some forms of input, such as card input-based batch jobs, may contain human-readable user passwords. The administrative and user guidance documentation must explain the risks in placing passwords on such input and must suggest procedures to mitigate that risk. 5.1.35 FIA_UID.1 Timing of identification 5.1.35.1 FIA_UID.1.1 The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed before the user is identified. 5.1.35.2 FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on the behalf of that user. Application Note: The ST must specify the actions that are allowed to an unidentified user. The allowed actions should be limited to those things that aid an authorized user in gaining access to the TOE, such as help facilities or the ability to send messages to authorized administrators. The method of identification is unspecified by this PP but should be specified in a ST, and it should specify how this relates to user identifiers maintained by the TSF. 5.1.36 FIA_UID.2 User identification before any action 5.1.36.1 FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other TSF mediated actions on behalf of that user. 5.1.37 FIA_USB.1 User-Subject Binding 5.1.37.1 FIA_USB.1.1a The TSF shall associate the appropriate user security attributes with subjects acting on the behalf of that user. Application Note: User security attributes are defined in Section 5.1.29. (FIA_ATD.1) 5.1.37.2 FIA_USB.1.1b The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on behalf of that user: (a) The sensitivity label associated with a subject shall be within the clearance range of the user; (b) [assignment: initial association rules]. 5.1.37.3 FIA_USB.1.1c The TSF shall enforce the rules governing changes to the user security attributes associated with subjects acting on behalf of that user.

Application Note: The DAC policy and audit generation require that each subject acting on behalf of users have a user identity associated with the subject. This identity is normally the one used at the time of identification to the system. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 44 The DAC policy enforced by the TSF may include provisions for making access decisions based on a user identity which differs from the one used during identification. The ST must state, in the implementation note for this Security Functional Requirement (FIA_USB.1.1c), how this alternate identity is associated with a subject and justify why the individual user associated with this alternate identity is not compromised by the mechanism used to implement it. Depending on the TSF implementation of group membership, the associations between a subject and groups may be explicit at the time of identification or implicit in a relationship between user and group identifiers. The ST must specify this association. Like user identification, an alternate group mechanism may exist, and parallel requirements apply. 5.1.38 FMT_MOF.1 Management of security functions behavior 5.1.38.1 FMT_MOF.1.1The TSF shall restrict the ability to [selection: determine the behavior of, disable, enable, modify the behavior of] the functions [assignment: list of functions] to [assignment: CSSOs and authorized system administrators]. Application Note: The ST must state the restrictions and functions applied to the management of TOE security functions by the CSSO and authorized system administrators. 5.1.39 FMT_MSA.1 Management of security attributes 5.1.39.1 FMT_MSA.1.1a The TS F shall enforce the [assignment: Discretionary Access Control Policy] to restrict the ability to [selection: modify] the security attributes [assignment: associated with a named object] to [assignment: the authorized users and authorized administrators]. 5.1.39.2 FMT_MSA.1.1b The TSF shall enforce the [assignment: Mandatory Access Control Policy] to restrict the ability to [selection: modify] the security attributes [assignment: sensitivity label associated with an object containing user data] to [assignment: the CSSO and users designated by the CSSO to make Authorized Derivative Classification decisions]. Application Note: The information system must immediately notify the user of each change in the security level or compartment associated with that user during an interactive session. A user must be able to query the information system as desired for a display of the user’s complete sensitivity label. The ST must state the components of the access rights that may be modified and any restrictions for a type of authorized user and the components of access rights the user is allowed to modify. The ability to modify access rights must be restricted soa user having access rights to a named object does not have the ability to modify those access TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 45 rights unless granted the right to do so. This restriction may be explicit, based on the object ownership, or based on a set of object hierarchy rules. Data in a TOE is categorized as either user data or TSF data. User data are information stored in IT resources that can be operated upon by users in accordance with the TSP and upon which the TSF places no special meaning. For example, the content of an electronic mail message or word processing document file is user data. The modification of sensitivity labels of objects that are identified as IT resources (e.g., printers, etc.) falls under the purview of the CSSO.

5.1.40 FMT_MSA.2 Secure security attributes 5.1.40.1 FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes. 5.1.41 FMT_MSA.3 Static attribute initialization 5.1.41.1 FMT_MSA.3.1a The TSF shall enforce the [assignment: Discretionary Access Control Policy] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP (DAC Policy). 5.1.41.2 FMT_MSA.3.1b The TSF shall enforce the [assignment: Mandatory Access Control Policy] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP (MAC Policy). 5.1.41.3 FMT_MSA.3.2 The TSF shall allow the [assignment: the authorized identified roles] to specify alternative initial values to override the default values when an object or information is created. Application Note: A TOE conforming to this PP must provide protection by default for all objects at creation time. This may be done through the enforcing of a restrictive default access control on newly created objects or by requiring the user to explicitly specify the desired access controls on the object at its creation. In either case, there shall be no window of vulnerability through which unauthorized access may be gained to newly created objects. 5.1.42 FMT_MTD.1 Management of TSF data 5.1.42.1 FMT_MTD.1.1a The TSF shall restrict the ability to [selection: create, delete, and clear, [assignment: other operations]] the [assignment: audit trail] to [assignment: CSSOs and authorized system administrators]. Application Note: The selection of “create, delete, and clear” functions for audit trail management reflects common management functions. These functions should be considered generic; any other audit administration functions that are critical to the management of a particular audit mechanism implementation should be specified in the ST. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 46 5.1.42.2 FMT_MTD.1.1b The TSF shall restrict the ability to [selection: modify] the [assignment: authentication data] to [assignment: the following: (a) CSSOs; (b) authorized system administrators; and (c) users authorized to modify their own authentication data. Application Note: User authentication data refers to information that users must provide to authenticate themselves to the TSF. Examples include passwords, personal identification numbers, and fingerprint profiles. User authentication data does not include the user’s identity. The ST must specify the authentication mechanism that uses authentication data to verify user identity. This component does not require that any user be authorized to modify his/her own authentication information; it only states that it is permissible. Requests to modify authentication data do not require reauthentication of the requester’s identity. 5.1.42.3 FMT_MTD.1.1c The TS F shall restrict the ability to [selection: modify [assignment: or observe]] the [assignment: set of audited events] to [assignment: CSSOs and authorized system administrators]. Application Note: The set of audited events identified in the assignment is a subset of the events that will be audited by the TSF. The term set is used loosely here and refers to the total collection of possible ways to control which audit records get generated; this could be by type of record, identity of user, identity of object, etc.

It is an important aspect of audit that users are not able to effect which of their actions are audited, and, therefore, must not have control over or knowledge of the selection of an event for auditing. 5.1.42.4 FMT_MTD.1.1d The TSF shall restrict the ability to [selection: modify] the [assignment: TSF representation of time] to the [assignment: CSSOs and authorized system administrators]. 5.1.42.5 FMT_MTD.1.1e The TSF shall restrict the ability to [selection: initialize [assignment: and modify]] the [assignment: user and subject security attributes, other than authentication data,] to [assignment: authorized administrators]. Application Note: This component only applies to security attributes that are used to maintain the TSP. Other user attributes may be specified in the ST, but control of those attributes is not within the scope of this PP. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 47 5.1.43 FMT_REV.1 Revocation 5.1.43.1 FMT_REV.1.1a The TSF shall restrict the ability to revoke security attributes associated with the [selection: users and subjects] within the TSC to [assignment: CSSOs and authorized system administrators]. 5.1.43.2 FMT_REV.1.1b The TSF shall restrict the ability to revoke security attributes associated with [selection: objects] within the TSC to [assignment: users authorized to modify the security attributes by the Discretionary Access Control policy]. Application Note: The DAC policy may include immediate revocation (e. g., Multics immediately revokes access to segments) or delayed revocation (e. g., most UNIX systems do not revoke access to already opened files). The DAC access rights are considered to have been revoked when all subsequent access control decisions by the TSF use the new access control information. It is not required that every operation on an object make an explicit access control decision as long as a previous access control decision was made to permit that operation. It is sufficient that the developer clearly documents in guidance documentation how revocation is enforced. Many security-relevant authorizations could have serious consequences if misused, so an immediate revocation method must exist, although it need not be the usual method (e. g., The usual method may be editing the trusted users profile, but the change doesn't take effect until the user logs off and logs back on. The method for immediate revocation might be to edit the trusted users profile and "force" the trusted user to log off.). The immediate method must be specified in the ST and administrator guidance. In a distributed environment, the developer must provide a description of how the "immediate" aspect of this requirement is met. 5.1.43.3 FMT_REV.1.2 The TSF shall enforce the rules: [assignment: (a) For access rights associated with an object when an access check is made; (b) For immediate revocation of security-relevant authorizations; (c) Of the Mandatory Access Control policy (FDP_IFC.1) on all future operations; and (d) list of other revocation rules concerning users]. Application Note: Many security-relevant authorizations could have serious consequences if misused, so an immediate revocation method must exist, although it need not be the usual method (e. g., The usual method may be editing the trusted users profile, but the change doesn't take effect until the user logs off and logs back on. The method for immediate revocation might be to edit the trusted users profile and "force" the trusted user to log off.). The immediate method must be specified in the ST and administrator guidance. In a distributed environment, the developer must provide a description of how the "immediate" aspect of this requirement is met.

TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 48 5.1.44 FMT_SMR.2 Restrictions on security roles 5.1.44.1 FMT_SMR.2.1 The TSF shall maintain the roles: [assignment: (a) CSSO; (b) authorized system administrator; (c) users authorized by the Discretionary Access Control Policy to modify object security attributes; (d) users authorized to modify their own authentication data; and (e) other roles]. Application Note: The ST must identify any other security-relevant roles supported by the TOE. 5.1.44.2 FMT_SMR.2.2 The TSF shall be able to associate users with roles. Application Note: A TOE conforming to this PP only needs to support a single administrative role, referred to as the authorized system administrator. If a TOE implements multiple independent roles, the ST should refine the use of the term “authorized administrators” to specify which roles fulfill which requirements. This PP specifies a number of functions that are required of or restricted to an authorized administrator, but there may be additional functions that are specific to the TOE, including any that would undermine the proper operation of the TSF. Examples of functions include: ability to access certain system resources like tape drives or vector processors, ability to manipulate the printer queues, and ability to run real-time programs. 5.1.44.3 FMT_SMR.2.3 The TSF shall ensure that the conditions [assignment: conditions for the different roles] are satisfied. Application Note: If conditions or restrictions are applied to the different security- relevant roles supported by the TOE, the conditions or restrictions must be stated in the ST. 5.1.45 FPT_AMT.1 Abstract machine testing 5.1.45.1 FPT_AMT.1.1 The TSF shall run a suite of tests [selection: during initial start- up, periodically during normal operation, or at the request of an authorized administrator] to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF. Application Note: In general, this component refers to the proper operation of the hardware platform on which a TOE is running. The test suite needs to cover only aspects of the hardware on which the TSF relies to implement required functions, TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 49 including domain separation. If a failure of some aspect of the hardware would not result in the TSF compromising the functions it performs, then testing of that aspect is not required. 5.1.46 FPT_ITC.1 Inter-TSF confidentiality during transmission 5.1.46.1 FPT_ITC.1.1 The TSF shall protect all TSF data transmitted from the TSF to a remote trusted IT product from unauthorized disclosure during transmission. Application Note: Examples of TSF data are: passwords, cryptographic keys, audit data, or TSF executable code. Note the TSF can only take action at each TOE component and depends on the TSF at the remote IT/ TOE to protect the TSF data upon receipt of the data. The ST must describe how one or more of the following protects the data. • Information distributed only within an area approved for open storage of the information • National Security Agency (NSA)-approved encryption mechanisms appropriate for the encryption of classified information • Protected Transmission System • Trusted courier 5.1.47 FPT_ITT.1 Basic internal TSF data transfer protection 5.1.47.1 FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure] when it is transmitted between separate parts (TOE components) of the TOE.

Application Note: Examples of TSF data are: passwords, cryptographic keys, audit data, or TSF executable code. The ST must describe how the TSF data are protected when the TOE consists of networked TOE components when there is TSF data transfer. If there is no TSF data transferred, this should be stated in the ST. Methods used under FPT_ITC.1 may be used. 5.1.48 FPT_RCV.2 Automated recovery 5.1.48.1 FPT_RCV.2.1 When automated recovery from a failure or service discontinuity is not possible, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided. 5.1.48.2 FPT_RCV.2.2 For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to a secure state using automated procedures. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 50 5.1.49 FPT_RPL.1 Replay detection 5.1.49.1 FPT_RPL.1.1 The TSF shall detect replay for the following entities: [assignment: list of identified entities]. 5.1.49.2 FPT_RPL.1.2 The TSF shall perform [assignment: list of specific actions] when replay is detected. 5.1.50 FPT_RVM.1 Non-bypassability of the TSF 5.1.50.1 FPT_RVM.1.1 The TSF shall ensure that the TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. Application Note: This element does not imply that there must be a reference monitor. Rather, the TSF must validate all actions between subjects and objects that require policy enforcement. 5.1.51 FPT_SEP.3 Complete reference monitor 5.1.51.1 FPT_SEP.3.1 The unisolated portion of the TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. 5.1.51.2 FPT_SEP.3.2 The TSF shall enforce separation between the security domains of subjects in the TSC. 5.1.51.3 FPT_SEP.3.3 The TSF shall maintain the part of the TSF that enforces the access control and/or information flow control SFPs in a security domain for its own execution that protects them from interference and tampering by the remainder of the TSF and by subjects untrusted with respect to the TSP. Application Note: This component does not imply a particular implementation of a TOE. The implementation needs to exhibit properties that the code and the data upon which TSF relies are not alterable in ways that would compromise the TSF and that observation of TSF data would not result in failure of the TSF to perform its job. This could be done either by hardware mechanisms or hardware architecture. Possible implementations include multi-state CPUs that support multiple task spaces and independent nodes within a distributed architecture. The second element can also be met in a variety of ways also, including CPU support for separate address spaces or separate hardware components, or software. The latter is likely in layered application, such as a graphic user interface system that maintains separate subjects. 5.1.52 FPT_STM.1 Reliable time stamps 5.1.52.1 FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 51 Application Note: The generation of audit records depends on having a correct date and time. The ST needs to specify the degree of accuracy required to maintain useful information for audit records. 5.1.53 FPT_TST.1 TSF testing

5.1.53.1 FPT_TST.1.1 The TSF shall run a suite of self-tests [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the conditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of the TSF. Application Note: In general, this component refers to the proper operation of the TSF. The test suite needs to cover only aspects of the required functions of the TSF, including domain separation. 5.1.53.2 FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of TSF data. 5.1.53.3 FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code. 5.1.54 FRU_RSA.2 Minimum and maximum quotas 5.1.54.1 FRU_RSA.2.1 The TSF shall enforce maximum quotas of the following resources [assignment: controlled resources] that [selection: individual user, defined group of users, subjects] can use [selection: simultaneously, over a specified period of time]. Application Note: The ST must identify the TOE resources that will be managed on the basis of quotas, the quota for each resource, and the criteria for enforcing the quotas. 5.1.54.2 FRU_RSA.2.2 The TSF shall ensure the provision of minimum quantity of each [assignment: controlled resource] that is available for [selection: an individual user, defined group of users, subjects] to use [selection: simultaneously, over a specified period of time] Application Note: The ST must identify the TOE resources that will be managed on the basis of guaranteed access and the criteria for enforcing the guarantee. 5.1.55 FTA_MCS.1 Basic limitation on multiple concurrent sessions 5.1.55.1 FTA_MCS.1.1 The TSF shall restrict the maximum number of concurrent sessions that belong to the same user. 5.1.55.2 FTA_MCS.1.2 The TSF shall enforce, by default, a limit of [assignment: one (1)] sessions per user. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 52 5.1.56 FTA_SSL.1 TSF-initiated session locking 5.1.56.1 FTA_SSL.1.1 The TSF shall lock an interactive session after [assignment: time interval of user inactivity] by: (a) Clearing or overwriting display devices, making the current contents unreadable; (b) Disabling any activity of the user’s data access/display devices other than unlocking the session. 5.1.56.2 FTA_SSL.1.2 The TSF shall require the following events to occur prior to unlocking the session: [assignment: events to occur]. Application Note: The ST must identify the events, if any (such as user authentication) necessary to unlock a session. 5.1.57 FTA_SSL.2 User-initiated locking 5.1.57.1 FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user’s own interactive session, by: (a) Clearing or overwriting display devices, making the current contents unreadable; (b) Disabling any activity of the user’s data access/display devices other than unlocking the session. 5.1.57.2 FTA_SSL.2.2 The TSF shall require the following events to occur prior to unlocking the session: [assignment: events to occur]. Application Note: The ST must identify the events, if any (such as user authentication) necessary to unlock a session. 5.1.58 FTA_SSL.3 TSF-initiated termination 5.1.58.1 FTA_SSL.3.1 The TSF shall terminate an interactive session after a [assignment: time interval of user inactivity]. 5.1.59 FTA_TAB.1 Default TOE access banners

5.1.59.1 FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning message regarding unauthorized use of the TOE. Application Note: The warning banner must comply with the NNSA PCSP minimum banner or use an alternative banner wording approved by the organization’s General Counsel. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 53 5.1.60 FTA_TAH.1 TOE access history 5.1.60.1 FTA_TAH.1.1 Upon successful session establishment, the TSF shall display the [selection: date, time, method, and location] of the last successful session establishment to the user. 5.1.60.2 FTA_TAH.1.2 Upon successful session establishment, the TSF shall display the [selection: date, time, method, location] of the last unsuccessful attempt to session establishment and the number of unsuccessful attempts since the last successful session establishment. 5.1.60.3 FTA_TAH.1.3 The TSF shall not erase the access history information from the user interface without giving the user an opportunity to review the information. 5.1.61 FTA_TSE.1 TOE session establishment 5.1.61.1 FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [assignment: attributes]. 5.1.62 FTP_TRP.1 Trusted Path 5.1.62.1 FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection: remote, local] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification or disclosure. 5.1.62.2 FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to initiate communication via the trusted path. 5.1.62.3 FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initial user authentication, [assignment: other services for which trusted path is required]]. 5.2 TOE Security Assurance Requirements The following detailed assurance component requirements from a developer, content, and evaluator perspective. Also included are Application Notes: 5.2.1 Configuration Management 5.2.1.1 ACM_AUT.1 Partial CM Automation 5.2.1.1.1 Developer action elements ACM_AUT.1.1D The developer shall use a CM system. ACM_AUT.1.2D The developer shall provide a CM plan. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 54 5.2.1.1.2 Content and presentation of evidence elements ACM_AUT.1.1C The CM system shall provide an automated means by which only authorized changes are made to the TOE implementation representation. ACM_AUT.1.2C The CM system shall provide an automated means to support the generation of the TOE. ACM_AUT.1.3C The CM plan shall describe the automated tools used in the CM system. ACM_AUT.1.4C The CM plan shall describe how the automated tools are used in the CM system. 5.2.1.1.3 Evaluator action elements ACM_AUT.1.1E The evaluator shall confirm that the information provided meets all the requirements for the content and presentation of evidence. 5.2.1.2 ACM_CAP.4 Generation Support and Acceptance Procedures 5.2.1.2.1 Developer action elements ACM_CAP.4.1D The developer shall provide a reference for the TOE. ACM_CAP.4.2D The developer shall use a Configuration Management (CM) System. ACM_CAP.4.3D The developer shall provide CM documentation. 5.2.1.2.2 Content and presentation of evidence elements ACM_CAP.4.1C The reference for the TOE shall be unique to each version of the TOE. ACM_CAP.4.2C The TOE shall be labeled with its reference.

ACM_CAP.4.3C The CM documentation shall include a configuration list, a CM plan, and an acceptance plan. ACM_CAP.4.4C The configuration list shall describe the configuration items that comprise the TOE. ACM_CAP.4.5C The CM documentation shall describe the method used to uniquely identify the configuration items. ACM_CAP.4.6C The CM system shall uniquely identify all configuration items. ACM_CAP.4.7C The CM shall describe how the CM system is used. ACM_CAP.4.8C The evidence shall demonstrate that the CM system is operating in accordance with the CM plan. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 55 ACM_CAP.4.9C The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system. ACM_CAP.4.10C The CM system shall provide measures such that only authorized changes are made to the configuration items. ACM_CAP.4.11C The CM system shall support the generation of the TOE. ACM_CAP.4.12C The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. 5.2.1.2.3 Evaluator action elements ACM_CAP.4.1E The evaluator shall confirm that the information provided meets all the requirements for the content and presentation of evidence. Application Note: This component provides three things. First, it requires that the TOE is identifiable, using identifiers such as version and part numbers, to ensure that the correct installation is made. Second, it requires that the pieces used to produce the TOE are identified, and, third, it requires that the production of the TOE be done in a controlled manner. 5.2.1.3 ACM_SCP.2 Problem Tracking CM Coverage 5.2.1.3.1 Developer action elements ACM_SCP.2.1D The developer shall provide CM documentation. 5.2.1.3.2 Content and presentation of evidence elements ACM_SCP.2.1C The CM documentation shall show that the CM system, as a minimum, tracks the following: The TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, CM documentation, and security flaws. ACM_SCP.2.2C The CM documentation shall describe how the configuration items are tracked by the CM system 5.2.1.3.3 Evaluator action elements ACM_SCP.2.1E The evaluator shall confirm that the information provided meets all the requirements for the content and presentation of evidence. 5.2.2 Delivery and Operation 5.2.2.1 ADO_DEL.1 Delivery Procedures TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 56 5.2.2.1.1 Developer action elements ADO_DEL.1.1D The developer shall document procedures for delivery of the TOE or parts of it to the user. ADO_DEL.1.2D The developer shall use the delivery procedures. 5.2.2.1.2 Content and presentation of evidence elements ADO_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the user’s site. 5.2.2.1.3 Evaluator action elements ADO_DEL.1.1E The evaluator shall confirm that the information provided meets all the requirements for the content and presentation of evidence. Application Note: The delivery procedures for the TOE can vary greatly and range from a shrink-wrapped box from a retail outlet to delivery by a field engineer. As such, there may be opportunities for third parties to tamper with the TOE delivery process. To avoid these instances, the developer should provide proven procedures or mechanisms that mitigate the threat.

5.2.2.2 ADO_IGS.1 Installation, generation, and startup procedures 5.2.2.2.1 Developer action elements ADO_IGS.1.1D The developer shall document procedures necessary for the secure installation, generation, and startup of the TOE. 5.2.2.2.2 Content and presentation of evidence elements ADO_IGS.1.1C The documentation shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.2.2.3 Evaluator action elements ADO_IGS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADO_IGS.1.2E The evaluator shall determine that the installation, generation and startup procedures result in a secure configuration. Application Note: The required documentation depends how the TOE is generated and installed. For example, the generation of the TOE from source code may be done at the development site, in which case the required documentation would be considered part of the design documentation. On the other hand, if the TOE administrator generates some part of the TOE, it would be part of the administrative guidance. Similar circumstances would apply to both installation and startup procedures. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 57 5.2.3 Development 5.2.3.1 ADV_FSP.1 Informal Functional Specification 5.2.3.1.1 Developer action elements ADV_FSP.1.1D The developer shall provide a functional specification. 5.2.3.1.2 Content and presentation of evidence elements ADV_FSP.1.1C The functional specification shall describe the TSF and its external interfaces using an informal style ADV_FSP.1.2C The functional specification shall be internally consistent. ADV_FSP.1.3C The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions, and error messages as appropriate. ADV_FSP.1.4C The functional specification shall completely represent the TSF. 5.2.3.1.3 Evaluator action elements ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all the requirements for content and presentation of evidence. ADV_FSP.1.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. Application Note: This component requires that the design documentation include a complete external description of the TSF. In particular, it needs to address the mechanisms used to meet the functional requirements of the PP. Other areas should be addressed to the degree that they affect the functional requirements. 5.2.3.2 ADV_HLD.2 Security enforcing high-level design 5.2.3.2.1 Developer action elements ADV_HLD.2.1D The developer shall provide the high level design of the TSF. 5.2.3.2.2 Content and presentation of evidence elements ADV_HLD.2.1C The presentation of the high-level design shall be informal. ADV_HLD.2.2C The high-level design shall be internally consistent. ADV_HLD.2.3C The high-level design shall describe the structure of the TSF in terms of subsystems. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 58 ADV_HLD.2.4C The high-level design shall the security functionality provided by each subsystem of the TSF. ADV_HLD.2.5C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.

ADV_HLD.2.6C The high-level design shall identify all interfaces to the subsystems of the TSF. ADV_HLD.2.2C The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. ADV_HLD.2.7C The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing details of effects, exceptions, and error messages, as appropriate. ADV_HLD.2.8C The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems. 5.2.3.2.3 Evaluator action elements ADV_HLD.2.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. ADV_HLD.2.2E The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements. Application Note: This component requires that the design documentation include a breakdown of the TSF at a very coarse grain. Both the developer and evaluator need to carefully choose how a subsystem is defined for a particular TOE. There must be a balance between subsystems being too large (that is, difficult to understand the functions of a single subsystem) and subsystems that are so small that their fit into the system as a whole is difficult to understand. Having different groups of developers maintain different pieces of the TSF can aid in making these choices. Furthermore, the presentation need only be informal. This means that the interfaces between subsystems need be presented in general terms of how they interact, not to the level pf presenting a programming interface specification between them. 5.2.3.3 ADV_IMP.1 Subset of the Implementation of the TSF 5.2.3.3.1 Developer action elements ADV_IMP.1.1D The developer shall provide the implementation representation for a selected subset of the TSF. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 59 5.2.3.3.2 Content and presentation of evidence elements ADV_IMP.1.1C The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions. ADV_IMP.1.2C The implementation representation shall be internally consistent. 5.2.3.3.3 Evaluator action elements ADV_IMP.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. ADV_IMP.1.2E The evaluator shall determine that the least abstract TSF representation provided is an accurate and complete instantiation of the TOE security functional requirements. 5.2.3.4 ADV_RCR.1 Informal correspondence demonstration 5.2.3.4.1 Developer action elements ADV_RCR.1.1D The developer shall provide an analysis of the correspondence between all adjacent pairs of the TSF representations that are provided. 5.2.3.4.2 Content and presentation of evidence elements ADV_RCR.1.1C For each adjacent pair of the provided TSF representations, the analysis shall demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract representation. 5.2.3.4.3 Evaluator action elements ADV_RCR.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. Application Note: For the PP, this ensures that the functional specifications and high- level design are consistent.

5.2.3.5 ADV_SPM.1 Informal TOE Security Policy Model 5.2.3.5.1 Developer action elements ADV_SPM.1.1D The developer shall provide a TSP model. ADV_SPM.1.2D The developer shall demonstrate correspondence between the functional specification and the TSP model. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 60 5.2.3.5.2 Content and presentation of evidence elements ADV_SPM.1.1C The TSP model shall be informal. ADV_SPM.1.2C The TSP model shall describe the rules and characteristics of all po0licies of the TSP that can be modeled. ADV_SPM.1.3C The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all policies of the TSP that can be modeled. ADV_SPM.1.4C The demonstration of correspondence between the TSP model and the functional specification shall show that all of the security functions in the functional specification are consistent and complete with respect to the TSP model. 5.2.3.5.3 Evaluator action elements ADV_SPM.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. 5.2.4 Guidance Documents 5.2.4.1 AGD_ADM.1 Administrator Guidance 5.2.4.1.1 Developer action elements AGD_ADM.1.1D The developer shall provide administrator guidance addressed to system administrative personnel. 5.2.4.1.2 Content and presentation of evidence elements AGD_ADM.1.1C The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE. AGD_ADM.1.2C The administrator guidance shall describe how to administer the TOE in a secure manner. AGD_ADM.1.3C The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment. AGD_ADM.1.4C The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure operation of the TOE. AGD_ADM.1.5C The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate. AGD_ADM.1.6C The administrator guidance shall describe each type of security relevant event relative to the administrative function that need to be TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 61 performed, including changing the security characteristics of entities under the control of the TSF. AGD_ADM.1.7C The administrator guidance shall describe be consistent with all other documentation supplied for evaluation. AGD_ADM.1.8C The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator. 5.2.4.1.3 Evaluator action elements AGD_ADM.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. Application Note: The content required by this component is quite comprehensive and broadly stated. In particular, the content must address any of the mechanisms and functions provided to the administrator to meet the functional requirements of the PP. It should also contain warnings about actions that may typically be done by administrators that should not be done on this specific TOE. This may include activating certain features or installing certain software that would compromise the TSF. 5.2.4.2 AGD_USR.1 User Guidance 5.2.4.2.1 Developer action elements

AGD_USR.1.1D The developer shall provide user guidance 5.2.4.2.2 Content and presentation of evidence elements AGD_USR.1.1C The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE. AGD_USR.1.2C The user guidance shall describe the use of user-accessible security functions provided by the TOE. AGD_USR.1.3C The user guidance shall contain warnings about user accessible functions and privileges that should be controlled in a secure processing environment. AGD_USR.1.4C The user guidance shall clearly present all user responsibilities necessary for the secure operation of the TOE, including those related to assumptions regarding user behavior found in the statement of the TOE security environment. Note: this includes the securing of media, passwords, and etc. AGD_USR.1.5C The user guidance shall be consistent with all other documentation supplied for evaluation. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 62 AGD_USR.1.6C The user guidance shall describe all security requirements for the IT environment that are relevant to the user. 5.2.4.2.3 Evaluator action elements AGD_USR.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. Application Note: The content required by this component is quite comprehensive and broadly stated. In particular, the content must address any of the mechanisms and functions provided to the user to meet the functional requirements of the PP. It should also contain warnings about actions that may typically be done by users that should not be done on this specific TOE. 5.2.5 Life Cycle Support 5.2.5.1 ALC_DVS.1 Identification of security measures 5.2.5.1.1 Developer action elements ALC_DVS.1.1D The developer shall produce development security documentation. 5.2.5.1.2 Content and presentation of evidence elements ALC_DVS.1.1C The development security documentation shall describe all physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. ALC_DVS.1.2C The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE. 5.2.5.1.3 Evaluator action elements ALC_DVS.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. ALC_DVS.1.2E The evaluator shall confirm that the security measures are being applied 5.2.5.2 ALC_FLR.3 Systematic Flaw Remediation 5.2.5.2.1 Developer action elements ALC_FLR.3.1D The developer shall document the flaw remediation procedures. ALC_FLR.3.2D The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for correction of those flaws. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 63 ALC_FLR.3.3D The developer shall designate one or more specific points of contact for user reports and inquiries about security issues involving the TOE. 5.2.5.2.2 Content and presentation of evidence elements ALC_FLR.3.1C The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

ALC_FLR.3.2C The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided as well as the status of finding a correction to the flaw. ALC_FLR.3.3C The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. ALC_FLR.3.4C The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections, and guidance on corrective actions to TOE users. ALC_FLR.3.5C The flaw remediation procedures documentation shall describe a means by which the developer receives from the TOE users reports and inquiries of suspected security flaws in the TOE. ALC_FLR.3.6C The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the correction issued to TOE users. ALC_FLR.3.7C The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. ALC_FLR.3.8C The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. ALC_FLR.3.9C The flaw remediation procedures shall include a procedure requiring timely responses for the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw. ALC_FLR.3.10C The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections. ALC_FLR.3.11C The flaw remediation guidance shall identify the specific points of contact for all reports and inquiries about security issues involving the TOE. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 64 5.2.5.2.3 Evaluator action elements ALC_FLR.3.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. 5.2.5.3 ALC_LCD.1 Developer Defined Life Cycle Model 5.2.5.3.1 Developer action elements ALC_LCD.1.1D The developer shall establish a life-cycle model to be used in the development and maintenance of then TOE. ALC_LCD.1.2D The developer shall provide life-cycle definition documentation. 5.2.5.3.2 Content and presentation of evidence elements ALC_LCD.1.1C The life-cycle definition documentation shall describe the model used to develop and maintain the TOE. ALC_LCD.1.2C The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. 5.2.5.3.3 Evaluator action elements ALC_LCD.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. 5.2.6 Assurance Maintenance 5.2.6.1 AMA_AMP.1Assurance maintenance plan 5.2.6.1.1 Developer action elements: AMA_AMP.1.1D The developer shall provide an AM Plan. 5.2.6.1.2 Content and presentation of evidence elements: AMA_AMP.1.1C The AM Plan shall contain or reference a brief description of the TOE, including the security functionality it provides. AMA_AMP.1.2C The AM Plan shall identify the certified version of the TOE, and shall reference the evaluation results. AMA_AMP.1.3C The AM Plan shall reference the TOE component categorization report for the certified version of the TOE. AMA_AMP.1.4C The AM Plan shall define the scope of changes to the TOE that are covered by the plan.

TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 65 AMA_AMP.1.5C The AM Plan shall describe the TOE life-cycle, and shall identify the current plans for any new releases of the TOE, together with a brief description of any planned changes that are likely to have a significant security impact. AMA_AMP.1.6C The AM Plan shall describe the assurance maintenance cycle, stating and justifying the planned schedule of AM audits and the target date of the next reevaluation of the TOE. AMA_AMP.1.7C The AM Plan shall identify the individual(s) who will assume the role of developer security analyst for the TOE. AMA_AMP.1.8C The AM Plan shall describe how the developer security analyst role will ensure that the procedures documented or referenced in the AM Plan are followed. AMA_AMP.1.9C The AM Plan shall describe how the developer security analyst role will ensure that all developer actions involved in the analysis of the security impact of changes affecting the TOE are performed correctly. AMA_AMP.1.10C The AM Plan shall justify why the identified developer security analyst(s) have sufficient familiarity with the security target, functional specification, and (where appropriate) high-level design of the TOE, and with the evaluation results and all applicable assurance requirements for the certified version of the TOE. AMA_AMP.1.11C The AM Plan shall describe or reference the procedures to be applied to maintain the assurance in the TOE, which, at a minimum, shall include the procedures for configuration management, maintenance of assurance evidence, performance of the analysis of the security impact of changes affecting the TOE, and flaw remediation. 5.2.6.1.3 Evaluator action elements: AMA_AMP.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AMA_AMP.1.2E The evaluator shall confirm that the proposed schedules for AM audits and reevaluation of the TOE are acceptable and consistent with the proposed changes to the TOE. 5.2.6.2 AMA_EVD.1 Evidence of maintenance process 5.2.6.2.1 Developer action elements: AMA_EVD.1.1D The developer security analyst shall provide AM documentation for the current version of the TOE. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 66 5.2.6.2.2 Content and presentation of evidence elements: AMA_EVD.1.1C The AM documentation shall include a configuration list and a list of identified vulnerabilities in the TOE. AMA_EVD.1.2C The configuration list shall describe the configuration items that comprise the current version of the TOE. AMA_EVD.1.3C The AM documentation shall provide evidence that the procedures documented or referenced in the AM Plan are being followed. AMA_EVD.1.4C The list of identified vulnerabilities in the current version of the TOE shall show, for each vulnerability, that the vulnerability cannot be exploited in the intended environment for the TOE. 5.2.6.2.3 Evaluator action elements: AMA_EVD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AMA_EVD.1.2E The evaluator shall confirm that the procedures documented or referenced in the AM Plan are being followed. AMA_EVD.1.3E The evaluator shall confirm that the security impact analysis for the current version of the TOE is consistent with the configuration list.

AMA_EVD.1.4E The evaluator shall confirm that all changes documented in the security impact analysis for the current version of the TOE are within the scope of changes covered by the AM Plan. AMA_EVD.1.5E The evaluator shall confirm that functional testing has been performed on the current version of the TOE to a degree commensurate with the level of assurance being maintained. 5.2.6.3 AMA_SIA.1 Sampling of security impact analysis 5.2.6.3.1 Developer action elements: AMA_SIA.1.1D The developer security analyst shall, for the current version of the TOE, provide a security impact analysis that covers all changes affecting the TOE as compared with the certified version. 5.2.6.3.2 Content and presentation of evidence elements: AMA_SIA.1.1C The security impact analysis shall identify the certified TOE from which the current version of the TOE was derived. AMA_SIA.1.2C The security impact analysis shall identify all new and modified TOE components that are categorized as TSP-enforcing. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 67 AMA_SIA.1.3C The security impact analysis shall, for each change affecting the security target or TSF representations, briefly describe the change and any effects it has on lower representation levels. AMA_SIA.1.4C The security impact analysis shall, for each change affecting the security target or TSF representations, identify all IT security functions and all TOE components categorized as TSP-enforcing that are affected by the change. AMA_SIA.1.5C The security impact analysis shall, for each change that results in a modification of the implementation representation of the TSF or the IT environment, identify the test evidence that shows, to the required level of assurance, that the TSF continues to be correctly implemented following the change. AMA_SIA.1.6C The security impact analysis shall, for each applicable assurance requirement in the configuration management (ACM), life-cycle support (ALC), delivery and operation (ADO) and guidance documents (AGD) assurance classes, identify any evaluation deliverables that have changed, and provide a brief description of each change and its impact on assurance. AMA_SIA.1.7C The security impact analysis shall, for each applicable assurance requirement in the vulnerability assessment (AVA) assurance class, identify which evaluation deliverables have changed and which have not, and give reasons for the decision taken as to whether or not to update the deliverable. 5.2.6.3.3 Evaluator action elements: AMA_SIA.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AMA_SIA.1.2E The evaluator shall check, by sampling, that the security impact analysis documents changes to an appropriate level of detail, together with appropriate justifications that assurance has been maintained in the current version of the TOE. 5.2.7 Tests 5.2.7.1 ATE_COV.2 Analysis of coverage 5.2.7.1.1 Developer action elements ATE_COV.2.1D The developer shall provide an analysis of test coverage. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 68 5.2.7.1.2 Content and presentation of evidence elements ATE_COV.2.1C The analysis of test coverage shall demonstrate the correspondence between the test identified in the test documentation and the TSF as described in the functional specification.

ATE_COV.2.2C The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the functional specification and the tests identified in the test documentation is complete. 5.2.7.1.3 Evaluator action elements ATE_COV.2.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. 5.2.7.2 ATE_DPT.1 Testing: High-Level Design 5.2.7.2.1 Developer action elements ATE_DPT.1.1D The developer shall provide the analysis of the depth of testing. 5.2.7.2.2 Content and presentation of evidence elements ATE_DPT.1.1C The depth analysis shall demonstrate that the test identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design. 5.2.7.2.3 Evaluator action elements ATE_DPT.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. Application Note: While the high-level design is used as the basis for testing, it is not required that internal interfaces between systems are tested. 5.2.7.3 ATE_FUN.1 Functional Testing 5.2.7.3.1 Developer action elements ATE_FUN.1.1D The developer shall test the TSF and document the results. ATE_FUN.1.2D The developer shall provide test documentation. 5.2.7.3.2 Content and presentation of evidence elements ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure descriptions, expected test results, and the actual test results. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 69 ATE_FUN.1.2C The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed. ATE_FUN.1.3C The test procedures shall identify the test to be performed and describe the scenarios for testing each security function. The scenarios shall include any ordering dependencies on the results of other tests. ATE_FUN.1.4C The expected test results shall show the anticipated outputs from a successful execution of the tests. ATE_FUN.1.5C The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified. 5.2.7.3.3 Evaluator action elements ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. 5.2.7.4 ATE_IND.2 Independent testing – Sample 5.2.7.4.1 Developer action elements ATE_IND.2.1D The developer shall provide the TOE for testing. 5.2.7.4.2 Content and presentation of evidence elements ATE_IND.2.1C The TOE shall be suitable for testing. ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in the developer’s functional testing of the TSF. 5.2.7.4.3 Evaluator action elements ATE_IND.2.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. ATE_IND.2.2E The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified. ATE_IND.2.1E The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. Application Note: The choice of the subset to be tested and the sample of tests executed by the evaluator is entirely at the discretion of the evaluator. 5.2.8 Vulnerability Assessment

5.2.8.1 AVA_MSU.2 Validation of Analysis TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 70 5.2.8.1.1 Developer action elements AVA_MSU.2.1D The developer shall provide guidance documentation. AVA_MSU.2.2D The developer shall document an analysis of the guidance documentation. 5.2.8.1.2 Content and presentation of evidence elements AVA_MSU.2.1C The guidance documentation shall identify all possible mode of operation of the TOE (including operation following failure or operational error), their consequences. and implications for maintaining secure operations. AVA_MSU.2.2C The guidance documentation shall be complete, clear, consistent, and reasonable. AVA_MSU.2.3C The guidance documentation shall list all assumptions about the intended environment. AVA_MSU.2.4C The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls). AVA_MSU.2.5C The analysis documentation shall demonstrate that the guidance documentation is complete. 5.2.8.1.3 Evaluator action elements AVA_MSU.2.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. AVA_MSU.2.2E The evaluator shall repeat all configuration and installation procedures, and other procedures selectively, to confirm that the TOE can be configured and used securely using only the supplied guidance documentation. AVA_MSU.2.3E The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected. AVA_MSU.2.4E The evaluator shall confirm that the analysis documentation shows that guidance is provided for secure operation in all modes of operation of the TOE. Application Note: This requirement can be approached as testing by the evaluator to ensure that the guidance documents are correct. The content elements primarily reinforce the guidance requirements themselves. 5.2.8.2 AVA_SOF.1 Strength of TOE security function evaluation TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 71 5.2.8.2.1 Developer action elements AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim. 5.2.8.2.2 Content and presentation of evidence elements AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim. the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ ST. AVA_SOF.1.2C For each mechanism with specific strength of TOE security function claim. the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST. 5.2.8.2.3 Evaluator action elements AVA_SOF.1.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. AVA_SOF.1.2E The evaluator shall confirm that the strength claims are correct. Application Note: The requirement applies to the authentication mechanism and any other mechanism that relies on its strength to ensure confidentiality and/ or integrity (e.g., encryption). 5.2.8.3 AVA_VLA.2 Independent vulnerability analysis 5.2.8.3.1 Developer action elements AVA_VLA.2.1D The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user can violate the TSP.

AVA_VLA.2.2D The developer shall document the disposition of identified vulnerabilities. 5.2.8.3.2 Content and presentation of evidence elements AVA_VLA.2.1C The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. AVA_VLA.2.2C The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 72 5.2.8.3.3 Evaluator action elements AVA_VLA.2.1E The evaluator shall confirm that the information provided meets all requirements for the content and presentation of evidence. AVA_VLA.2.2E The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identified vulnerabilities have been addressed. AVA_VLA.2.3E The evaluator shall perform an independent vulnerabilities analysis. AVA_VLA.2.4E The evaluator shall perform independent penetration testing based on the independent vulnerability analysis to determine the exploitability of additional identified vulnerabilities in the intended environment. AVA_VLA.2.5E The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a low attack potential. Application Note: The evaluator should consider the following with respect to the search for obvious flaws. • Dependencies among functional components and potential inconsistencies in the strength of unction among independent functions. • Potential inconsistencies between the TSP and the functional specification. • Potential gaps or inconsistencies in the high-level design and potentially invalid assumptions about supporting hardware, software, or firmware required by the TSF. • Potential gaps in the administrator guidance that enable the administrator to fail: a) to make effective use of TSF functions, b) to understand or take actions that need to be performed, c) to install and/or configure the TOE correctly, or d) to avoid unintended interactions among security functions. In particular, failure to describe all security parameters under the administrator’s control and the effects of settings of those parameters. • Potential gaps in user guidance that enable the user to fail to control functions and privileges as required to maintain a secure processing environment. Potential presence in the user guidance of information that facilitates exploitation of vulnerabilities. • Open literature (e.g., CERT advisories, bug-trac mailing lists, etc.) that contains information on vulnerabilities on the TSF should be consulted. 5.3 Security Requirements for the IT Environment 5.3.1 ENV_AMA.1 Malicious Access 5.3.1.1 ENV_AMA.1.1 Environmental controls are implemented to detect, deter, and respond to malicious actions by authenticated users. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 73 Application Note: Intrusion detection by other components does not include electronic mail or electronic mail attachments that may execute malicious code upon opening. 5.3.2 ENV_AVA.1 Information Availability 5.3.2.1 ENV_AVA.1.1 Capabilities and resources are provided to allow the information system user to perform data backup at the user’s discretion. 5.3.2.2 ENV_AVA.1.2 User and information system data are available or restorable to meet mission availability requirements. Periodic checking of backup inventory and testing of the ability to restore information is accomplished to validate mission availability requirements are met.

5.3.3 ENV_ATH.1 Management of User Identifiers and Authenticators 5.3.3.1 ENV_ATH.1.1 Authentication credentials shall be protected from unauthorized access during creation, use, and handling. 5.3.3.2 ENV_ATH.1.2 Authenticated user TOE access is disabled when the user leaves the sponsoring organization, Access Authorization is terminated, loses authorized access (for cause, changes in organization, etc), or upon TOE detection of attempts to bypass security. 5.3.3.3 ENV_ATH.1.3 Prior to reuse of an authenticated user identifier, all previous access rights and privileges (including file accesses for that user identifier) are removed from the TOE. 5.3.3.4 ENV_ATH.1.4 Authenticated user access, contact information, rights, and privileges, to include sponsor, Access Authorization, need-to- know, means for off line contact, mailing address, are validated annually. 5.3.4 ENV_CLR.1 Clearing 5.3.4.1 ENV_CLR.1.1 The information system components and removable media are cleared before the items can be reused in another system environment with the same or different accreditation level as the original system components or removable media. 5.3.4.2 ENV_CLR.1.2 All information system components and removable media are sanitized, using approved NNSA procedures, prior to release for use at a lower classification level, at a lower level of consequence, or outside the information system boundary. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 74 5.3.5 ENV_CVT.1 Covert Channels 5.3.5.1 ENV_CVT.1.1 The information system must be reviewed to identify obvious covert channels with a bandwidth greater than 1,000 bytes per second. 5.3.6 ENV_EXM.3 Sophisticated Hardware and Software Examination 5.3.6.1 ENV_EXM.3.1 Information system hardware components are examined for security impacts to the information system before use. In addition, the hardware review will validate that the chip sets and boards are from the manufacturer and using the manufacturer diagnostics confirm they function as expected. 5.3.6.2 ENV_EXM.3.2 Software is examined to determine if the software conforms to the security-relevant controls as documented by the developer and contains no malicious code. 5.3.7 ENV_EXM.4 Bypass of Software Controls 5.3.7.1 ENV_EXM.4.1 The examination will also determine if the controls can be bypassed or subverted. 5.3.8 ENV_FOR.1 Forensics 5.3.8.1 ENV_FOR.1.1 Procedures are established and documented to ensure the identification, collection, and preservation of data needed to analyze penetration reconstruction, on-going cyber attacks and/or failures 5.3.9 ENV_IDS.1 Intrusion Detection 5.3.9.1 ENV_IDS.1.1 The site and network (when applicable) environment provides the ability to detect low level (i.e., using methods readily available on the Internet to attack known vulnerabilities) attacks on the hosts and networks from outside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. 5.3.9.2 ENV_IDS.1.2 The site and network (when applicable) environment provides the ability to detect low level (i.e., using readily available methods to attack known vulnerabilities) attacks on the hosts and networks from inside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use.

5.3.9.3 ENV_IDS.1.3 The network (when applicable) environment provides the ability to detect low level (i.e., using methods readily available on the Internet to attack known vulnerabilities) attacks on the network TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 75 and its components and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. 5.3.10 ENV_IDS.2 Advanced Intrusion Detection 5.3.10.1 ENV_IDS.2.1 Where applicable, the network environment provides the ability to detect sophisticated attacks on the hosts and networks from outside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use; 5.3.10.2 ENV_IDS.2.2 Where applicable, the network environment provides the ability to detect sophisticated attacks on the hosts and networks from inside the site and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. 5.3.10.3 ENV_IDS.2.3 Where applicable, the network environment provides the ability to detect sophisticated attacks on the network and its components, and the results of such attacks (e.g., corrupted system state), including measures to detect and respond to unauthorized attempts to penetrate or deny use. 5.3.11 ENV_INT.1 TOE Interface 5.3.11.1 ENV_INT.1.1 The information system environment must ensure that any information flow control policies are enforced at the system (TOE) external interfaces. 5.3.11.2 ENV_INT.1.2 The developers of the information system must ensure that the information system security is not adversely affected by the characteristics of the network(s) to which the information system is interfaced. 5.3.12 ENV_MRK.1 Marking 5.3.12.1 ENV_MRK.1.1 Each host, visual display, and output device will be marked with the sensitivity label (level) of the most sensitive information group the system is accredited to process, store, or transmit. 5.3.12.2 ENV_MRK.1.2 All system output and removable media are appropriately marked with the level of the highest information sensitivity of the information groups the system is accredited to operate with or marked with the sensitivity label for the information. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 76 5.3.13 ENV_NON.1 Non-TOE Access 5.3.13.1 ENV_NON.1.1 The electronic environment in which the TOE resides (e.g. IT other than the information system) must provide the ability to specify and manage user access rights to the TOE processing and data resources (i.e. access authorization through the network), supporting the organization’s security policy for access control. 5.3.13.2 ENV_NON.1.2 For resources not controlled by the information system, IT other than the information system must prevent logical entry using unsophisticated technical methods by persons without authority for such access. 5.3.14 ENV_NOT.1 User Notification 5.3.14.1 ENV_NOT.1.1 All users are notified that they are subject to being monitored, recorded, and audited through the use of an NNSA-approved warning text and positive acknowledgement by the user is required before granting the user access to system resources. 5.3.15 ENV_NTK.1 Need-To-Know 5.3.15.1 ENV_NTK.1.1 Prior to their first access to information, each user’s need-to-know (Sigma access) is formally authorized by management or the data owner/steward.

5.3.16 ENV_PHY.3 Physical Security and Environmental Protection 5.3.16.1 ENV_PHY.3.1 Access controls ensure that personnel granted unescorted physical access to the information, the information system, or human readable media have the appropriate formal access approvals and need-to-know. 5.3.16.2 ENV_PHY3.2 Physical attack that might compromise IT security on those parts of the information system critical to security is deterred and detected. 5.3.16.3 ENV_PHY3.3 Systems containing [assignment: Top Secret Restricted Data] shall, as a minimum, be protected by at least one of the following [assignment: constantly attended or under the control of a person that possesses proper authorization, formal access approval, and need to know; in a manner described for Top Secret information; or in a manner to preclude unauthorized disclosure]. 5.3.17 ENV_PRO.1 Information Protection 5.3.17.1 ENV_PRO.1.1 Information protection is required whenever [assignment: Top Secret Restricted Data] is to be transmitted, carried to, or carried through areas or components where individuals not authorized to TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 77 have access to the information may have unescorted physical or uncontrolled electronic access to the information or communications media (e. g., outside the system perimeter). One or more of [assignment: information distributed only within an area approved for open storage of the information; National Security Agency (NSA) - approved Type I encryption mechanisms; DOE/NNSA approved encryption mechanisms; or NNSA approved protected transmission systems]. 5.3.18 ENV_RCV.1 System Recovery 5.3.18.1 ENV_RCV.1.1 All remote terminal access must be monitored when used for system recovery operations. 5.3.19 ENV_REV.1 Media and Component Review 5.3.19.1 ENV_REV.1.1 All media (paper, disks, zip drives, removable disk drives, etc.) are reviewed for sensitivity and properly marked before release outside the system boundary. 5.3.20 ENV_RGT.1 User Access Rights and Privileges 5.3.20.1 ENV_RGT.1.1 Each user’s access rights and privileges are authorized, prior to the user's first access to the TOE. 5.3.21 ENV_ROL.1 Security Roles 5.3.21.1 ENV_ROL1.1 Other roles involved with security administration, such as DBMS administration, are not performed by the same people performing the CSSO and system administrator roles. 5.3.21.2 ENV_ROL.1.2 The same person does not perform the functions of the CSSO and the system administrator. 5.3.22 ENV_ROL.2 Security Roles 5.3.22.1 ENV_ROL.2.1 The information system shall maintain the CSSO and system administrator roles and shall be able to associate specific users with the roles. 5.3.22.2 ENV_ROL.2.2 The CSSO and system administrator are present when audit parameters or audit file contents are modified. 5.3.23 ENV_TNG.1 User Training 5.3.23.1 ENV_TNG.1.1 All authenticated users are trained to understand applicable information system-use policies, the approved use of the information system, and the vulnerabilities inherent in the operation of the information system, and their cyber security responsibilities. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 78 5.3.24 ENV_UCL.1 User Clearance - Q 5.3.24.1 ENV_UCL.1.1 All users (including privileged users) shall, at a minimum, possess a current [selection: "Q" Access Authorization] prior to their first access to the TOE. 6. PP APPLICATION NOTES

Whether a user is granted a requested action is determined by the TOE Security Policy (TSP), specified in this profile as having two components: Discretionary Access Control (DAC) and Mandatory Access Control (MAC). These policies comprise the set of rules used to mediate user access to TOE protected objects. The DAC Policy can be characterized as a policy that allows authorized users and authorized administrators to control access to objects on the basis of individual user identity or membership in a group (e.g., Project A). The MAC Policy is a set of rules that determines access based upon the sensitivity (e.g., SECRET) or category (e.g., PERSONNEL, MEDICAL) of the information being accessed and the access authority of the user attempting to access that information. The sensitivity of the information and the access rights of the user are identified by specific markings, referred to as sensitivity labels. The combination of a hierarchical classification and a set of non-hierarchical categories that represents the sensitivity of information is known as the security level. When the DAC and MAC policy rules are invoked, the TOE is said to be mediating access to TOE protected objects. In order for an access request to succeed, both the DAC and MAC checks must succeed; access is denied if either access check fails. The DAC and MAC policy consists of two types of rules: those that apply to the behavior of authorized users (termed “access rules”) and those that apply to the behavior of authorized administrators (termed “authorization rules”). If an authorized user is granted a request to operate on an object, the user is said to have access to that object. There are numerous types of access; typical ones include read access and write access, which allow the reading and writing of objects respectively. If an authorized administrator is granted a requested service, the user is said to have authorization to the requested service or object. As for access, there are numerous possible authorizations. Typical authorizations include auditor authorization that allows an administrator to view audit records and execute audit tools and DAC override authorization that allows an administrator to override object access controls to administer the system. TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 79 7. RATIONALE 7.1 Security Objectives Rationale Table 1. Policies, Threats, and Assumptions by Objective Objective Name Threat Policy Assumptions O.ACCESS T.ABUSE_OTHER, T.ACCESS_TOE, T.ACCESS_UNDETECTED, T.ACCESS_MALICIOUS, T.ACCESS_NON_TOE, T.AUDIT_CONFIDENTIALITY_NO N_TOE, T.ATTACK_OTHER, T.ENTRY_TOE, T.ENTRY_SOPHISTICATED, T.ERROR_USER, T.IMPERSON_OTHER, T.MASQUERADE_AUTHORIZED_ USER, T.SPOOFING, T.SPRINGBOARD, T.STEGANOGRAPHY P.PERSONNEL, P.AUTH_MGT, P.NTK A.COOP O.ACCESS_AUTH_Q T.STEGANOGRAPHY P.PERSONNEL, P.AUTH_MGT, P.NTK O.ACCESS_FORMAL T.ABUSE_OTHER, T.ACCESS_TOE, T.ACCESS_UNDETECTED, T.ACCESS_MALICIOUS, T.ATTACK_OTHER, T.AUDIT_CONFIDENTIALITY_NO N_TOE, T.ENTRY_TOE, T.ENTRY_SOPHISTICATED, T.ERROR_USER, T.IMPERSON_OTHER, T.MASQUERADE_AUTHORIZED_ USER, T.SPOOFING, T.STEGANOGRAPHY P.PERSONNEL, P.AUTH_MGT, P.NTK A.COOP TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 80 Objective Name Threat Policy Assumptions O.ACCESS_HISTORY T.ACCESS_UNDETECTED, T.ACCESS_MALICIOUS, T.ATTACK_OTHER, T.ENTRY_TOE, T.ENTRY_SOPHISTICATED, T.IMPERSON_OTHER, T.MASQUERADE_AUTHORIZED_ USER, T.SPOOFING P.ACCOUNTABILITY, P.MONITORING O.ACCESS_MALICIOUS T.ACCESS_TOE, T.ACCESS_MALICIOUS, T.ATTACK_OTHER, T.IMPERSON_OTHER, T.MASQUERADE_AUTHORIZED_ USER, T.PHYSICAL, T.SPOOFING, T.SYSTEM_CORRUPTED, T.TOE_CORRUPTED P.PERSONNEL, P.AUTH_MGT, P.NTK A.COOP TOP SECRET RESTRICTED DATA PROTECTION PROFILE VERSION X.X 81 Objective Name Threat Policy Assumptions O.AUDIT_AUTOMATED_REVIEW T.ABUSE_ADMIN, T.ABUSE_OTHER, T.ACCESS_TOE, T.ACCESS_UNDETECTED, T.ACCESS_MALICIOUS, T.ACCESS_NON_TECHNICAL, T.ATTACK_OTHER, T.AUDIT_CONFIDENTIALITY_TO E, T.ENTRY_