**COTS Compartmentalized Operations Protection Profile -- Operating
Systems**

**(CCOPP-OS)**

**DRAFT**

**Version 0.4**

**May 22, 2005**

**Sponsored by:**

**Prepared by:**

**PreVal Specialist, Inc.**

This document is consistent with the

Common Criteria for Information Technology Security Evaluation

Version 2.2

+----------------------------------------------------------------------+
| Interpretations Incorporated (as applicable)                         |
+----------------------------------------------------------------------+
| NIAP & CCIMB                                                         |
+----------------------------------------------------------------------+
| All approved posted to                                               |
|                                                                      |
| <http://www.commoncriteriaportal.org/public/expert/index.php?menu=2> |
|                                                                      |
| as of 12/31/03                                                       |
+----------------------------------------------------------------------+

[]{#__RefHeading___Toc102926309 .anchor}TABLE OF CONTENTS

SECTION PAGE

[TABLE OF CONTENTS ii](#__RefHeading___Toc102926309)

[TABLE OF TABLES v](#__RefHeading___Toc102926310)

[1. INTRODUCTION 1](#introduction)

[1.1 Identification 1](#identification)

[1.2 overview 1](#overview)

[2. TOE DESCRIPTION 5](#toe-description)

[2.1 Product class 5](#product-class)

[2.2 OPerational Environment 5](#operational-environment)

[2.3 required security functionality
6](#required-security-functionality)

[3. Security environment 7](#security-environment)

[3.1 INTRODUCTION 7](#introduction-1)

[3.2 Secure Usage Assumptions 8](#secure-usage-assumptions)

[3.3 ORGANIZATIONAL security policies
12](#organizational-security-policies)

[3.4 Threats to security 14](#threats-to-security)

[3.4.1 Threats environment addresses 17](#threats-environment-addresses)

[3.4.2 Threats TOE addresses 19](#threats-toe-addresses)

[3.4.3 Threats TOE and Environment jointly address
22](#threats-toe-and-environment-jointly-address)

[3.5 General assurance need 23](#general-assurance-need)

[4. security objectives 24](#security-objectives)

[4.1 Environmental security objectives
24](#environmental-security-objectives)

[4.2 TOE security objectives 26](#toe-security-objectives)

[4.3 Joint TOE/Environment security objectives
28](#joint-toeenvironment-security-objectives)

[5. Functional Security REQUIREMENTS
30](#functional-security-requirements)

[5.1 AUDIT (FAU) 35](#audit-fau)

[5.1.1 FAU_GEN.1-CCOPP AUDIT DATA GENERATION
35](#fau_gen.1-ccopp-audit-data-generation)

[5.1.2 FAU_GEN.2-CCOPP User identity generation
35](#fau_gen.2-ccopp-user-identity-generation)

[5.1.3 FAU_SAR.1 Audit review 35](#fau_sar.1-audit-review)

[5.1.4 FAU_SAR.2 Restricted audit review
36](#fau_sar.2-restricted-audit-review)

[5.1.5 FAU_SAR.3 Selectable audit review
36](#fau_sar.3-selectable-audit-review)

[5.1.6 FAU_SEL.1-CCOPP Selective audit
36](#fau_sel.1-ccopp-selective-audit)

[5.1.7 FAU_STG.1-CCOPP Protected audit trail storage
37](#fau_stg.1-ccopp-protected-audit-trail-storage)

[5.1.8 FAU_STG.3-CCOPP Action in case of possible audit data loss
37](#fau_stg.3-ccopp-action-in-case-of-possible-audit-data-loss)

[5.1.9 FAU_STG.4-CCOPP Prevention of audit data loss
38](#fau_stg.4-ccopp-prevention-of-audit-data-loss)

[5.2 User Data Protection (fdp) 38](#user-data-protection-fdp)

[5.2.1 FDP_ACC.1-CCOPP Subset access control
38](#fdp_acc.1-ccopp-subset-access-control)

[5.2.2 FDP_ACF.1-CCOPP Security attribute based access control
38](#fdp_acf.1-ccopp-security-attribute-based-access-control)

[5.2.3 FDP_ETC.1-CCOPP Export of user data without security attributes
40](#fdp_etc.1-ccopp-export-of-user-data-without-security-attributes)

[5.2.4 FDP_IFC.2-CCOPP Complete information flow control
40](#fdp_ifc.2-ccopp-complete-information-flow-control)

[5.2.5 FDP_IFF.1-CCOPP Simple security attributes
41](#fdp_iff.1-ccopp-simple-security-attributes)

[5.2.6 FDP_ITC.1-CCOPP Import of user data without security attributes
42](#fdp_itc.1-ccopp-import-of-user-data-without-security-attributes)

[5.2.7 FDP_RIP.2-1-CCOPP Object residual information protection
42](#fdp_rip.2-1-ccopp-object-residual-information-protection)

[5.2.8 FDP_RIP.2-2-CCOPP Subject residual information protection
43](#fdp_rip.2-2-ccopp-subject-residual-information-protection)

[5.2.9 FDP_UCT.1-CCOPP Basic data exchange confidentiality
43](#fdp_uct.1-ccopp-basic-data-exchange-confidentiality)

[5.2.10 FDP_UIT.1-CCOPP Data exchange integrity
43](#fdp_uit.1-ccopp-data-exchange-integrity)

[5.3 Identification and Authentication (FIA)
44](#identification-and-authentication-fia)

[5.3.1 FIA_AFL.1-CCOPP Authentication failure handling
44](#fia_afl.1-ccopp-authentication-failure-handling)

[5.3.2 FIA_ATD.1-CCOPP User attribute definition
44](#fia_atd.1-ccopp-user-attribute-definition)

[5.3.3 FIA_SOS.1-CCOPP Verification of secrets
45](#fia_sos.1-ccopp-verification-of-secrets)

[5.3.4 FIA_UAU.2-CCOPP User authentication before any action
46](#fia_uau.2-ccopp-user-authentication-before-any-action)

[5.3.5 FIA_UAU.5-CCOPP Multiple authentication mechanisms
46](#fia_uau.5-ccopp-multiple-authentication-mechanisms)

[5.3.6 FIA_UAU.6-CCOPP Re-authentication
46](#fia_uau.6-ccopp-re-authentication)

[5.3.7 FIA_UAU.7-CCOPP Protected authentication feedback
46](#fia_uau.7-ccopp-protected-authentication-feedback)

[5.3.8 FIA_UID.2-CCOPP User identification before any action
47](#fia_uid.2-ccopp-user-identification-before-any-action)

[5.3.9 FIA_USB.1-1- User-subject binding
47](#fia_usb.1-1--user-subject-binding)

[5.4 Security management (fmt) 48](#security-management-fmt)

[5.4.1 FMT_MOF.1 Management of security functions behavior
48](#fmt_mof.1-management-of-security-functions-behavior)

[5.4.2 FMT_MSA.1-1- CCOPP Management of security attributes
49](#fmt_msa.1-1--ccopp-management-of-security-attributes)

[5.4.3 FMT_MSA.1-2- CCOPP Management of security attributes
49](#fmt_msa.1-2--ccopp-management-of-security-attributes)

[5.4.4 FMT_MSA.3-CCOPP Static attribute initialization
49](#fmt_msa.3-ccopp-static-attribute-initialization)

[5.4.5 FMT_MTD.1-1-CCOPP Management of Audit Trail
50](#fmt_mtd.1-1-ccopp-management-of-audit-trail)

[5.4.6 FMT_MTD.1-2-CCOPP Management of Audited Events
50](#fmt_mtd.1-2-ccopp-management-of-audited-events)

[5.4.7 FMT_MTD.1-3-CCOPP Management of User Attributes
50](#fmt_mtd.1-3-ccopp-management-of-user-attributes)

[5.4.8 FMT_MTD.1-4-CCOPP Management of Authentication Data
51](#fmt_mtd.1-4-ccopp-management-of-authentication-data)

[5.4.9 FMT_REV.1-1-CCOPP Revocation of User Attributes
51](#fmt_rev.1-1-ccopp-revocation-of-user-attributes)

[5.4.10 FMT_REV.1-2-CCOPP Revocation of Object Attributes
51](#fmt_rev.1-2-ccopp-revocation-of-object-attributes)

[5.4.11 FMT_SAE.1-CCOPP Time-limited authorization
52](#fmt_sae.1-ccopp-time-limited-authorization)

[5.4.12 FMT_SMF.1 Specification of management functions
53](#fmt_smf.1-specification-of-management-functions)

[5.4.13 FMT_SMR.2-CCOPP Security roles
53](#fmt_smr.2-ccopp-security-roles)

[5.5 Protection of TOE Security (FPT)
54](#protection-of-toe-security-fpt)

[5.5.1 FPT_AMT.1-CCOPP Abstract machine testing
54](#fpt_amt.1-ccopp-abstract-machine-testing)

[5.5.2 FPT_FLS.1-CCOPP Failure with preservation of secure state
54](#fpt_fls.1-ccopp-failure-with-preservation-of-secure-state)

[5.5.3 FPT_ITC.1-CCOPP Inter-TSF confidentiality during transmission
54](#fpt_itc.1-ccopp-inter-tsf-confidentiality-during-transmission)

[5.5.4 FPT_ITI.1-CCOPP Inter-TSF detection of modification
55](#fpt_iti.1-ccopp-inter-tsf-detection-of-modification)

[5.5.5 FPT_RCV.2-CCOPP Recovery from Failure
56](#fpt_rcv.2-ccopp-recovery-from-failure)

[5.5.6 FPT_RCV.4 Function recovery 56](#fpt_rcv.4-function-recovery)

[5.5.7 FPT_RVM.1-CCOPP Non-bypassability of the TSP
56](#fpt_rvm.1-ccopp-non-bypassability-of-the-tsp)

[5.5.8 FPT_SEP.1-CCOPP TSF domain separation
57](#fpt_sep.1-ccopp-tsf-domain-separation)

[5.5.9 FPT_STM.1-CCOPP Reliable Time Stamps
57](#fpt_stm.1-ccopp-reliable-time-stamps)

[5.5.10 FPT_TST.1-CCOPP TSF testing 57](#fpt_tst.1-ccopp-tsf-testing)

[5.6 Resource utilization (fru) 58](#resource-utilization-fru)

[5.6.1 FRU_PRS.1 Limited priority of service
58](#fru_prs.1-limited-priority-of-service)

[5.6.2 FRU_RSA.1-CCOPP Maximum quotas
58](#fru_rsa.1-ccopp-maximum-quotas)

[5.7 TOE Access (FTA) 59](#toe-access-fta)

[5.7.1 FTA_LSA.1-CCOPP Limitation on scope of selectable attributes
59](#fta_lsa.1-ccopp-limitation-on-scope-of-selectable-attributes)

[5.7.2 FTA_MCS.1-CCOPP Basic limitation on multiple concurrent sessions
59](#fta_mcs.1-ccopp-basic-limitation-on-multiple-concurrent-sessions)

[5.7.3 FTA_TAB.1-CCOPP Default TOE access banners
59](#fta_tab.1-ccopp-default-toe-access-banners)

[5.7.4 FTA_TAH.1 TOE access history 60](#fta_tah.1-toe-access-history)

[5.7.5 FTA_TSE.1-CCOPP TOE session establishment
60](#fta_tse.1-ccopp-toe-session-establishment)

[5.8 functional requirements - IT Environment
60](#functional-requirements---it-environment)

[5.9 non-it Environmental Functional Requirements
61](#non-it-environmental-functional-requirements)

[5.10 Strength of function (SOF) 63](#strength-of-function-sof)

[5.10.1 Minimum SOF Requirement 63](#minimum-sof-requirement)

[5.10.2 Specific SOF Requirements -- TOE
63](#specific-sof-requirements-toe)

[5.11 Assurance Requirements 63](#assurance-requirements)

[6. rationale -- To Be Completed 65](#rationale-to-be-completed)

[6.1 Security Objectives Rationale 65](#security-objectives-rationale)

[6.1.1 Complete Coverage -- Environmental (Non-IT) Assumptions
66](#complete-coverage-environmental-non-it-assumptions)

[6.1.2 Complete Coverage -- Threats 66](#complete-coverage-threats)

[6.1.3 Complete Coverage -- Policy 66](#complete-coverage-policy)

[6.2 Security Requirements Rationale
68](#security-requirements-rationale)

[6.2.1 Security Functional Requirements cover Security Objectives
68](#security-functional-requirements-cover-security-objectives)

[6.2.2 Internal Consistency of Requirements
70](#internal-consistency-of-requirements)

[6.2.3 Satisfaction of Dependencies 71](#satisfaction-of-dependencies)

[6.2.4 Rationale for Assurance Level 71](#rationale-for-assurance-level)

[6.2.5 Rationale for SOF Rating 71](#rationale-for-sof-rating)

[6.3 PP claims RATIONALE 71](#pp-claims-rationale)

[Appendix A: ACRONYMS 72](#appendix-a-acronyms)

[Appendix b -- REFERENCES 73](#appendix-b-references)

[]{#__RefHeading___Toc102926310 .anchor}TABLE OF TABLES

TABLE PAGE

[Table 3.2-1 -- Security assumptions - TOE
8](#__RefHeading___Toc102926553)

[Table 3.2-2 -- Security assumptions -- Physical
9](#__RefHeading___Toc102926554)

[Table 3.3-1 -- Security policies 12](#__RefHeading___Toc102926555)

[Table 3.4-1 -- Security threats addressed by TOE's Environment
15](#__RefHeading___Toc102926556)

[Table 3.4-2 -- Security threats addressed by TOE
16](#__RefHeading___Toc102926557)

[Table 3.4-3 -- Security threats addressed Jointly by TOE and
Environment 17](#__RefHeading___Toc102926558)

[Table 4-1 -- Environmental Security Objectives
24](#__RefHeading___Toc102926559)

[Table 4-2 -- TOE Security Objectives 26](#__RefHeading___Toc102926560)

[Table 4-3 -- Joint TOE/Environment Security Objectives
29](#__RefHeading___Toc102926561)

[Table 5-1 -- Functional Components - TOE
30](#__RefHeading___Toc102926562)

[Table 5-2 -- Functional Components - IT Environment
60](#__RefHeading___Toc102926563)

[Table 5.3 -- EAL-4 Assurance Components
64](#__RefHeading___Toc102926564)

[Table 6‑1 --Threats and Policies to Objectives
65](#__RefHeading___Toc102926565)

[Table 6‑2 Non-IT Security Objectives to Environment Assumptions
66](#__RefHeading___Toc102926566)

[Table 6‑3 Threats to Security Objectives
66](#__RefHeading___Toc102926567)

[Table 6‑4 Security Policies to Objectives
67](#__RefHeading___Toc102926568)

[Table 6‑5 Objectives to SFRs 68](#__RefHeading___Toc102926569)

# INTRODUCTION 

## Identification 

Title: CCOPP-OS -- COTS Compartmentalized Operations Protection
Profile - Operating Systems

Assurance level: EAL4

CC Conformance Claims: Part 2 Conformant, Part 3 Conformant

Registration: \<To be filled in upon registration\>

Keywords: Protection Profile, Commercial, COTS, Compartmentalized Mode,
Compartmentalized Operations, operating system, compartmentalized,
access control, information protection, role based, role-based,
discretionary, mandatory, separation of duties, non-discretionary.

## overview 

**Purpose**

The purpose of CCOPP-OS is to define, and specify the requirements
necessary to solve, the security problem that organizations encounter
when trying to implement readily available operating systems (perhaps
with add-on packages) to handle compartmentalized environments working
within the same operating system.

This PP has been developed using guidance from \[CSPP-OS\], with many
thanks to Gary Stoneburner, formerly of NIST and now at APL, for his
efforts.

This PP also is a superset of both \[CAPP\] and \[RBAC\], which have
been incorporated into this document. It also contains much of the
\[LSPP\]. We wish to offer many thanks to NSA.

Compartmentalization is expected to be accomplished with label-based
access rules (restrictions), not compartment labels.

**Scope**

[Type of system]{.underline}: CCOPP-OS provides the requirements
necessary to specify needs for operating systems in both stand-alone and
distributed multi-user compartmentalized mode information systems.

[Type of access]{.underline}: CCOPP-OS recognizes two forms of
legitimate Compartmentalized User access; namely Public Access and
Authenticated Users.

A.  **Public Access users** do not have a unique identifier and are not
    authenticated prior to access. An example is access to information
    on a publicly accessible web page. Such users have legitimate
    access, but are differentiated from "authenticated users".

B.  **Authenticated users**:

    1.  Are uniquely identifiable by the system,

    2.  Utilize highly-controlled privileges which are access rights
        associated with each process that control the capabilities of
        the process.

    3.  Have legitimate access beyond publicly available information,
        and are

    4.  Authenticated prior to being granted such access (DAC).

[Types of control]{.underline}:

A.  **Compartmentalization:** allows or denies access to resources by
    Access control mechanisms that "label" access restrictions to the
    information (MAC) , and

B.  **Role-Based Access Control:** is a mechanism to map users to the
    permitted operations, by associating subjects to roles to
    operations.

[Nature of use]{.underline}: CCOPP conformant operating systems are
suitable for the protection of information in real-world environments.

-   CCOPP-OS compliant Operating Systems are suitable for specifying the
    baseline protection requirements for information in environments
    where all authenticated users are either (1) trusted to not
    maliciously attempt to circumvent nor by-pass access controls or (2)
    lack the motivation or capability for sophisticated penetration
    attempts. Public access is allowed with environmental controls over
    and beyond the OS supplied security mechanisms.

-   The Mandatory Access Control (MAC) policy is a set of rules that
    determines access based upon the category or compartment (e.g.,
    PERSONNEL, MEDICAL) of the subject and a label based access rule
    (also called label-based restrictions) on each object (e.g., READ
    from MEDICAL compartment, READ/WRITE from PERSONNEL compartment).
    The label based rule may be derived from the attributes of the
    object or environmental factors. Without loss of generality, this
    document assumes that the access rules of objects are represented as
    a set of (compartment-name, access-mode) pairs.

-   A CCOPP conformant system shall support at least two site-definable
    compartments. It shall also support at least two access modes for
    one or more objects under TOE control.

[Key Assumptions]{.underline}: Key assumptions that apply for CCOPP-OS
compliant OSs are --

-   The Target of Evaluation (TOE, the OS for which requirements are
    being specified) is comprised of CSPP-CONFORMANT Security Functional
    Requirements (SFRs), CAPP-CONFORMANT Security Functional
    Requirements (SFRs), RBAC-CONFORMANT as well as Compartmentalized
    Access Control SFRs from the Labeled Security Protection Profile
    (LSPP), all of which are considered to be CCOPP CONFORMANT

-   Authenticated users recognize the need for a secure IT environment

-   Authenticated users can be reasonably trusted to correctly apply the
    organization's security policies in their discretionary actions

-   Competent security administration is performed

-   Business/mission process automation is implemented with due regard
    for what can not be expected of a CCOPP-OS compliant OS.

**Summary of CCOPP-OS Requirements**

Systems incorporating the Compartmentalized Operations operating systems
(OSs) achieve the advantages such products offer. CCOPP-OS identifies a
cost-effective, security baseline for systems built from the CCOPP-OS,
ensuring that reasonable security expectations are achieved.

[Assurance]{.underline}: CCOPP-OS assurances have been selected to
provide the level of confidence resulting from (1) existing best
practices for OS development and (2) an easily-identified process for
third-party evaluation. This equates, in summary, to OS technical
countermeasures that -

-   are sufficient for controlling a community of authenticated users

-   can provide protection against relatively sophisticated, technical
    attacks

-   can not be expected to provide sufficient protection against
    extremely sophisticated, technical attacks (to include
    denial-of-service)

[Functionality]{.underline}: The CCOPP-OS operating system addresses
these user needs -

-   enforcing an access control policy between active entities
    (subjects) and passive objects based on subject identity and allowed
    actions

-   providing support for controlling access based upon environmental
    constraints such as time-of-day and port-of-entry

-   resistance to resource depletion by providing resource allocation
    features

-   providing mechanisms to detect insecurities

-   providing mechanisms for trusted recovery in the event of most
    system failures or detected insecurities

-   supporting these capabilities in a distributed system connected via
    an untrusted network

-   provide the label-based controls appropriate for protecting
    controlled information (such as company proprietary,
    privacy-related, or federally controlled) in environments containing
    authenticated users who are not allowed access to such information.
    This can be as mundane as personnel or medical information, as
    sophisticated as the new design for a product or process, or simply
    information that the government requires to be protected from view
    by more than a few people.

CCOPP-OS compliant OSs are [not]{.underline} expected to --

-   totally protect against malicious abuse of authorized privileges

-   adequately protect against sophisticated attacks (to include denial
    of service)

-   provide sufficient protection against installation, operation, or
    administration errors

# TOE DESCRIPTION 

The Target of Evaluation (TOE) in a common criteria protection profile
is the information technology component or system for which requirements
are to be specified. This section, TOE Description, describes the
CCOPP-OS in terms of the targets of evaluation (TOEs) covered. These
TOEs are identified by class of product, the operational environment,
and the required security functionality.

## Product class 

CCOPP-OS covers Compartmentalized Operations operating systems in both
stand-alone and networked environments. The TOEs covered by this PP
permit one or more processors and attached peripheral and storage
devices to be used by users to perform a variety of functions requiring
controlled, shared access to processing capability and information.

The TOE will provide user services directly or serve as a platform for
networked applications and will support protected communications across
an untrusted network.

The TOE may consist of a standard operating system with add-on packages
to increase the base functionality.

## OPerational Environment

The TOE supports the active entities of human users and software
processes. Human users, in conjunction with system processes, are
accountable for all system activities. The TOE generates processes that
act on behalf of either a specific human user or a uniquely identifiable
system process. A process requests and consumes resources on behalf of
its unique, associated user or system process. In a networked
environment, a process may invoke another process on a different system.

The TOE is intended for use in both stand-alone and networked
environment and will support one or more types of communication and
protocols, such as:

-   Synchronous process communication; e.g., remote procedure calls
    (RPC)

-   Asynchronous process communication; e.g., message passing using user
    datagram protocol (UDP)

-   Network management protocols; e.g., simple network management
    protocol (SNMP)

A compliant TOE will support --

-   Users with networked access to the TOE across an untrusted network
    (that is, mechanisms operating within the TOE cooperate with
    mechanisms in other components to securely exchange information
    across an untrusted network)

-   Several users executing tasks on the same system concurrently

-   Sharing resources, such as printer and mass storage, across a
    network

## required security functionality 

CCOPP-OS specifies the requirements for an operating system with the
security functionality listed below.

-   Executing the access control policy of the imposed IT security
    policy

-   Assigning a unique identifier to each authenticated user

-   Assigning a unique identifier to each system process, including
    those not running on behalf of a human user (e.g., processes started
    at system bootup like the Unix "inetd")

-   Authenticating the claimed user identity before allowing any user to
    perform any actions other than a well-defined set of operations
    (e.g., reading from a public web site)

-   Auditing in support of individual accountability and detection of
    and response to insecurity

-   Enabling access authorization management; i.e., the initialization,
    assignment, and modification of access rights (e.g. read, write,
    execute) to data objects with respect to (1) active entity name or
    group membership and (2) environmental constraints such as
    port-of-entry.

-   Resource allocation features providing a measure of resistance to
    resource depletion

-   Mechanisms for detecting some insecurities

-   System recovery features providing a measure of survivability in the
    face of system failures and insecurities

-   Automated support to help in the verification of secure delivery,
    installation, operation, and administration

# Security environment 

## INTRODUCTION 

This section identifies the following:

-   significant assumptions about the operational environment for
    CCOPP-OS compliant OSs

-   organizational security policies for which CCOPP-OS compliant OSs
    are appropriate

-   IT-related threats to the organization countered by the information
    technology in the notional information system of which compliant OSs
    are a part

-   threats requiring either reliance on environmental controls to
    provide sufficient protection or explicit risk acceptance

-   general description of the assurance required for CCOPP-OS

By providing the information describe above, this section gives the
basis for the security objectives described in section 4 and hence the
specific security requirements listed in sections 5 and 6.

## Secure Usage Assumptions 

The specific conditions listed below are key assumptions. These
assumptions include both practical realities considered in the
development of security requirements for CCOPP-OS compliant OSs and
essential environmental constraints on the use of compliant TOEs.

The references to "sophisticated" are meant as references to users,
whether they be authenticated or not ("hacker").

There are two broad categories of users with respect to these
assumptions and threats:

-   The first category are persons who possess little technical skills,
    do not have access to sophisticated attack tools, have some rights
    of access, and are mostly trusted not to attempt to maliciously
    subvert the system nor maliciously exploit the information stored
    thereon. Users in this category may be motivated by curiosity to
    gain access to information for which they have no authorization.

-   The second category of users is technically skilled or has access to
    sophisticated attack tools and some may attempt to bypass system
    controls as a technical challenge or as a result of curiosity. CCOPP
    compliant components and systems would generally be used in
    environments where these users are highly trusted not to attempt to
    maliciously subvert the system nor to maliciously exploit the
    information stored thereon, or are restricted from gaining access by
    non-OS means.

[]{#__RefHeading___Toc102926553 .anchor}Table 3.2-1 -- Security
assumptions - TOE

  -----------------------------------------------------------------------------------
  **Name**                  **Assumption**                    **Discussion**
  ------------------------- --------------------------------- -----------------------
  A.COTS                    The TOE is constructed from       This assumption is a
                            near-term achievable, commercial  key driver in
                            off the shelf information         determining the nature
                            technology.                       of the expectations
                                                              toward, and hence the
                                                              requirements are placed
                                                              upon the TOE.

  A.MALICIOUS-INSIDER       The TOE is not expected to be     It is not reasonable to
                            able to sufficiently mitigate the expect near-term COTS
                            risks resulting from malicious    products to provide
                            abuse of authorized privileges.   sufficient protection
                                                              against the malicious
                                                              actions of authorized
                                                              individuals.

  A. LABELS                 The TOE will provide label-based  It is an assumption,
                            access controls.                  based upon currently
                                                              available technology
                                                              and current common
                                                              practice that label
                                                              based access controls
                                                              will be included in
                                                              near-term COTS.

  A.COMPARTMENTALIZATION    Procedures exist for establishing It is an essential
                            the compartment label of all      element of CCOPP that
                            information imported into the     Role Based Access
                            system,                           Control principles and
                                                              other means of labeling
                                                              will ensure that users
                                                              can only access that
                                                              information for which
                                                              they have the privilege
                                                              to see.

  A.CONNECT                 All connections to peripheral     Connectivity, which
                            devices reside within the         will be handled in the
                            controlled access facilities.     Policy section as
                            CCOPP/CAPP/LSPP/RBAC-CONFORMANT   networking is assumed
                            TOEs only address security        to be the
                            concerns related to the           responsibility of other
                            manipulation of the TOE through   devices or programs,
                            its authorized access points.     not by the TOE.
                            Internal communication paths to   
                            access points such as terminals   
                            are assumed to be adequately      
                            protected.                        

  A.COOP                    Authorized users possess the      Cooperation in a normal
                            necessary authorization to access environment is a
                            at least some of the information  necessary and expected
                            managed by the TOE and are        situation.
                            expected to act in a cooperating  
                            manner in a benign environment.   

  A.SOPHISTICATED-ATTACK    The TOE is not expected to be     It is not reasonable to
                            able to sufficiently mitigate     expect near-term
                            risks resulting from application  achievable COTS to be
                            of sophisticated attack methods.  able to resist
                                                              sophisticated
                                                              (published or
                                                              unpublished
                                                              well-developed)
                                                              attacks.
  -----------------------------------------------------------------------------------

[]{#__RefHeading___Toc102926554 .anchor}Table 3.2-2 -- Security
assumptions -- Physical

  ------------------------------------------------------------------------
  **Name**             **Assumption**             **Discussion**
  -------------------- -------------------------- ------------------------
  A.ASSET              It is assumed that the     This is fully explained
                       value of the stored assets in the assumption
                       merits moderately          statement itself.
                       intensive penetration or   
                       masquerading attacks. It   
                       is also assumed that       
                       physical controls in place 
                       would alert the system     
                       authorities to the         
                       physical presence of       
                       attackers within the       
                       controlled space.          

  A.LOCATE             The processing resources   It is essential to
                       of the TOE will be located protect the machines
                       within controlled access   from physical attack.
                       facilities which will      
                       prevent unauthorized       
                       physical access.           

  A.PEER               Any other systems with     This is essential to
                       which the TOE communicates ensure that the TOE is
                       are assumed to be under    compatible and fully
                       the same management        functional within all
                       control and operate under  product that makes up
                       the same security policy   the SYSTEM.
                       constraints.               
                       CAPP-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      
                       which address the need to  
                       trust external systems or  
                       the communications links   
                       to such systems.           

  A.PROTECT            The TOE hardware and       It is essential to
                       software critical to       ensure that no
                       security policy            unauthorized changes are
                       enforcement will be        made to the TOE hardware
                       protected from             or software.
                       unauthorized physical      
                       modification.              
  ------------------------------------------------------------------------

**Table 3.2-3 -- Security assumptions -- Personnel**

  -------------------- ------------------------ --------------------------
  **Name**             **Assumption**           **Discussion**

  A.ACCESS             Rights for users to gain This is fully explained in
                       access and perform       the assumption statement
                       operations on            itself.
                       information are based on 
                       their membership in one  
                       or more roles. These     
                       roles are granted to the 
                       users by the TOE         
                       Administrator. These     
                       roles accurately reflect 
                       the users' job function, 
                       responsibilities,        
                       qualifications, and/or   
                       competencies within the  
                       enterprise.              

  A..ADMIN             The security features of It is essential that
                       the TOE are competently  security administration be
                       administered on an       both competent and
                       on-going basis.          on-going.

  A.MANAGE             There will be one or     It is essential that the
                       more competent           security of the
                       individuals assigned to  information be managed in
                       manage the TOE and the   an efficient and secure
                       security of the          manner.
                       information it contains. 

  A.NO_EVIL_ADMIN      The System               It is essential that the
                       administrative personnel administrative personnel
                       are not careless,        be trusted, as the TOE can
                       willfully negligent or   not protect against this
                       hostile, and will follow type or attack.
                       and abide by the         
                       instructions provided by 
                       the administrative       
                       documentation.           

  A.OWNER              A limited set of users   This is fully explained in
                       is given the rights to   the assumption statement
                       "create new data         itself.
                       objects" and they become 
                       owners for those data    
                       objects. The             
                       organization is the      
                       owner of the rest of the 
                       information under the    
                       control of TOE.          

  A.USER-NEED          Authenticated users      It is essential that the
                       recognize the need for a authenticated users
                       secure IT environment.   appreciate the need for
                                                security. Otherwise they
                                                are likely to try and
                                                circumvent it.

  A.USER-TRUST         Authenticated users are  Authenticated users will
                       generally trusted to     have a fair amount of
                       perform discretionary    discretion with CCOPP-OS
                       actions in accordance    systems and must therefore
                       with security policies.  be trusted. However, this
                                                "trust" is not absolute,
                                                and hence the phrase
                                                "generally trusted".
  -------------------- ------------------------ --------------------------

##   {#section .unnumbered}

## ORGANIZATIONAL security policies 

The organizational security policies discussed below are addressed by
the notional system containing CCOPP-OS compliant OSs.

[]{#__RefHeading___Toc102926555 .anchor}Table 3.3-1 -- Security policies

+---------------------+------------------+-----------------------------+
| **Name**            | **Policy**       | **Discussion**              |
+=====================+==================+=============================+
| P.ACCESS            | Access rights to | CCOPP-OS supports           |
|                     | specific data    | organizational policies     |
|                     | objects are      | which grant or deny access  |
|                     | determined by    | to objects using rules      |
|                     | object           | driven by attributes of the |
|                     | attributes       | user (such as user          |
|                     | assigned to that | identity, group, etc.),     |
|                     | object, user     | attributes of the object    |
|                     | identity, user   | (such as permission bits),  |
|                     | attributes, and  | type of access (such as     |
|                     | environmental    | read or write), and         |
|                     | conditions as    | environmental conditions    |
|                     | defined by the   | (such as time-of-day).      |
|                     | security policy. |                             |
+---------------------+------------------+-----------------------------+
| P.ACCOUNTABILITY    | Users must be    | CCOPP-OS supports           |
|                     | held accountable | organizational policies     |
|                     | for              | requiring that users are    |
|                     | s                | held accountable for their  |
|                     | ecurity-relevant | actions, facilitating       |
|                     | actions.         | after-the-fact              |
|                     |                  | investigations and          |
|                     |                  | providing some deterrence   |
|                     |                  | to improper actions. Also   |
|                     |                  | Per CAPP/LSPP/RBAC          |
+---------------------+------------------+-----------------------------+
| P.AUTHORIZED_USER   | Only those users | It is an essential element  |
|                     | who have been    | of RBAC that users be       |
|                     | authorized to    | authorized before accessing |
|                     | access the       | information/systems.        |
|                     | information      |                             |
|                     | within the       |                             |
|                     | system may       |                             |
|                     | access the       |                             |
|                     | system.          |                             |
+---------------------+------------------+-----------------------------+
| P.C                 | The system must  | This is well-defined in the |
| OMPARTMENTALIZATION | limit the access | description.                |
|                     | OF SUBJECTS to   |                             |
|                     | OBJECTS based on |                             |
|                     | the compartment  |                             |
|                     | label of the     |                             |
|                     | subject and the  |                             |
|                     | label based      |                             |
|                     | access           |                             |
|                     | restrictions of  |                             |
|                     | the object. The  |                             |
|                     | access rules     |                             |
|                     | enforced prevent |                             |
|                     | a subject from   |                             |
|                     | accessing        |                             |
|                     | information to   |                             |
|                     | which it is not  |                             |
|                     | authorized.      |                             |
+---------------------+------------------+-----------------------------+
| P.COMPLY            | The              | The organization will meet  |
|                     | implementation   | all requirements imposed    |
|                     | and use of the   | upon it from the outside;   |
|                     | organization's   | for example: government     |
|                     | IT systems must  | regulations, national and   |
|                     | comply with all  | local laws, and contractual |
|                     | applicable laws, | agreements.                 |
|                     | regulations, and |                             |
|                     | contractual      |                             |
|                     | agreements       |                             |
|                     | imposed on the   |                             |
|                     | organization.    |                             |
+---------------------+------------------+-----------------------------+
| P.DUE-CARE          | The              | It is important that the    |
|                     | organization's   | level of security afforded  |
|                     | IT systems must  | the IT system be in         |
|                     | be implemented   | accordance with what is     |
|                     | and operated in  | generally considered        |
|                     | a manner that    | adequate within the         |
|                     | represents due   | business or government      |
|                     | care and         | sector in which the         |
|                     | diligence with   | organization is placed.     |
|                     | respect to risks |                             |
|                     | to the           |                             |
|                     | organization.    |                             |
+---------------------+------------------+-----------------------------+
| P.INFO-FLOW         | Information flow | CCOPP includes information  |
|                     | between IT       | flow control as this is     |
|                     | components must  | needed in many              |
|                     | be in accordance | environments. While this    |
|                     | with established | might not be implemented by |
|                     | information flow | mechanisms within the       |
|                     | policies.        | CCOPP-OS TOE, the IT        |
|                     |                  | system, of which the TOE is |
|                     |                  | a part, will likely have to |
|                     |                  | meet this policy.           |
+---------------------+------------------+-----------------------------+
| P.KNOWN             | Except for a     | Beyond a well-defined set   |
|                     | well-defined set | of actions such as read     |
|                     | of allowed       | access to a public          |
|                     | operations,      | web-server, there is a      |
|                     | users of the TOE | finite community of known,  |
|                     | must be          | authenticated users who are |
|                     | identified and   | authenticated before being  |
|                     | authenticated    | allowed access.             |
|                     | before TOE       |                             |
|                     | access can be    |                             |
|                     | granted.         |                             |
+---------------------+------------------+-----------------------------+
| P.NEED_TO_KNOW      | The system must  | The method for              |
|                     | limit the access | compartmentalization of     |
|                     | to, modification | information is made based   |
|                     | of, and          | on criteria set forth by    |
|                     | destruction of   | the organization. This is   |
|                     | the information  | usually done on a basis of  |
|                     | in protected     | relative value to the       |
|                     | resources to     | organization and its        |
|                     | those authorized | interest to limit           |
|                     | users which have | dissemination of that       |
|                     | a "need to know" | information. The            |
|                     | for that         | determination of            |
|                     | information.     | compartmentalization of     |
|                     |                  | information is outside the  |
|                     |                  | scope of the IT system; the |
|                     |                  | IT system is only expected  |
|                     |                  | to enforce the              |
|                     |                  | compartmentalization rules, |
|                     |                  | not determine               |
|                     |                  | compartmentalization        |
+---------------------+------------------+-----------------------------+
| P.NETWORK           | The              | Since CCOPP-OS systems will |
|                     | organization's   | likely be interconnected    |
|                     | IT security      | across untrusted            |
|                     | policy must be   | networking, this policy     |
|                     | maintained in    | statement will have a       |
|                     | the environment  | significant impact on       |
|                     | of distributed   | CCOPP-OS requirement        |
|                     | systems          | definition.                 |
|                     | interconnected   |                             |
|                     | via insecure     |                             |
|                     | networking.      |                             |
+---------------------+------------------+-----------------------------+
| P.PHYSICAL          | The processing   | A TOE will not be able to   |
|                     | resources of the | meet its security           |
|                     | TOE that **must  | requirements unless at      |
|                     | be physically    | least a minimum degree of   |
|                     | protected** in   | physical security is        |
|                     | order to ensure  | provided.                   |
|                     | that security    |                             |
|                     | objectives are   |                             |
|                     | met will be      |                             |
|                     | located within   |                             |
|                     | controlled       |                             |
|                     | access           |                             |
|                     | facilities that  |                             |
|                     | mitigate         |                             |
|                     | unauthorized,    |                             |
|                     | physical access. |                             |
+---------------------+------------------+-----------------------------+
| P.SURVIVE           | The IT system,   | CCOPP-OS systems will       |
|                     | in conjunction   | provide a measure of this   |
|                     | with its         | resilience through          |
|                     | environment,     | functionality and           |
|                     | must be          | assurances that resist,     |
|                     | resilient to     | detect, and recover from    |
|                     | insecurity,      | insecurities.               |
|                     | resisting the    |                             |
|                     | insecurity       | For sophisticated attacks,  |
|                     | and/or providing | a large portion of this     |
|                     | the means to     | resilience is provided by   |
|                     | detect an        | the TOE environment.        |
|                     | insecurity and   |                             |
|                     | recover from it. |                             |
+---------------------+------------------+-----------------------------+
| P.TRAINING          | Authenticated    | Once granted legitimate     |
|                     | users of the     | access, authenticated users |
|                     | system must be   | are expected to use IT      |
|                     | adequately       | resources and information   |
|                     | trained,         | only in accordance with the |
|                     | enabling them to | organizational security     |
|                     | (1) effectively  | policy. In order for this   |
|                     | implement        | to be possible, these users |
|                     | organizational   | must be adequately trained  |
|                     | security         | both to understand the      |
|                     | policies with    | purpose and need for        |
|                     | respect to their | security controls and to be |
|                     | discretionary    | able to make security       |
|                     | actions and (2)  | decisions with respect to   |
|                     | support the need | their discretionary         |
|                     | for              | actions.                    |
|                     | n                |                             |
|                     | on-discretionary |                             |
|                     | controls         |                             |
|                     | implemented to   |                             |
|                     | enforce these    |                             |
|                     | policies.        |                             |
+---------------------+------------------+-----------------------------+
| P.USAGE             | The              | CCOPP-OS systems in         |
|                     | organization's   | conjunction with its        |
|                     | IT resources     | environment and user trust, |
|                     | must be used for | ensure that the             |
|                     | only for         | organization's information  |
|                     | authorized       | technology is not used for  |
|                     | purposes. (This  | unauthorized purposes.      |
|                     | Policy will be   |                             |
|                     | addressed by     |                             |
|                     | written          |                             |
|                     | Corporate        |                             |
|                     | Polices, not by  |                             |
|                     | the TOE).        |                             |
+---------------------+------------------+-----------------------------+

## Threats to security 

The technical countermeasures of systems comprised of near-term COTS are
required to counter threats which may be broadly categorized as -

-   the threat of unsophisticated, malicious attacks from individuals
    other than authenticated users

-   the threat of authenticated users attempting, non-maliciously to
    gain unauthorized access or to perform an unauthorized operation.
    Such attempts may be performed to "get the job done", out of
    curiosity, as a challenge, or as a result of an error.

Other threats that can affect system security must be dealt with in
conjunction with controls provided by the operating environment or risk
accepted.

The threats facing near-term COTS systems and CCOPP-OS compliant OSs in
particular, are listed in Tables 3.4-1 through 3.4-3 and discussed
further in sections 3.4.1 through 3.4.3.

[]{#__RefHeading___Toc102926556 .anchor}Table 3.4-1 -- Security threats
addressed by TOE's Environment

  ----------------------------------- ------------------- ------------------- ---------------------------------------------
  T.E.ACCESS-NON-TECHNICAL                                                    An authenticated user may gain non-malicious,
                                                                              unauthorized access using non-technical
                                                                              means.

  T.E.ACCESS-Non-TOE                  An authenticated                        
                                      user may gain                           
                                      unauthorized,                           
                                      non-malicious                           
                                      access to a                             
                                      resource or to                          
                                      information not                         
                                      directly controlled                     
                                      by the TOE via user                     
                                      error, system                           
                                      error, or an                            
                                      unsophisticated,                        
                                      technical attack.                       

  T.E.AUDIT-CONFIDENTIALITY-Non-TOE   For audit trails                        
                                      not under control                       
                                      of the TOE, records                     
                                      of security events                      
                                      may be disclosed to                     
                                      unauthorized                            
                                      individuals or                          
                                      processes.                              

  T.E.AUDIT-CORRUPTED-Non-TOE         For audit trails                        
                                      not under control                       
                                      of the TOE, records                     
                                      of security events                      
                                      may be subjected to                     
                                      unauthorized                            
                                      modification or                         
                                      destruction.                            

  T.E.DENIAL-Non-TOE                  The IT (other than                      
                                      the TOE) may be                         
                                      subjected to an                         
                                      unsophisticated,                        
                                      denial-of-service                       
                                      attack.                                 

  T.E.DENIAL-SOPHISTICATED                                                    The system may be subjected to a
                                                                              sophisticated, denial-of-service attack.

  T.E.ENTRY-NON-TECHNICAL                                                     An individual, other than an authenticated
                                                                              user, may gain access to processing resources
                                                                              or information using non-technical means.

  T.E.EENTRY-Non-TOE                                      An individual other 
                                                          than an             
                                                          authenticated user  
                                                          may gain            
                                                          unauthorized,       
                                                          malicious access to 
                                                          processing          
                                                          resources or        
                                                          information not     
                                                          controlled by the   
                                                          TOE via an          
                                                          unsophisticated,    
                                                          technical attack.   

  T.E.ENTRY-SOPHISTICATED                                                     An individual, other than an authenticated
                                                                              user, may gain access to processing resources
                                                                              or information using a sophisticated,
                                                                              technical attack.

  T.E.OBSERVE-Non-TOE                                     Events occur in     
                                                          operation of IT     
                                                          (other than the     
                                                          TOE) that           
                                                          compromise IT       
                                                          security; but that  
                                                          IT, due to flaws in 
                                                          its specification,  
                                                          design, or          
                                                          implementation, may 
                                                          lead a competent    
                                                          user or security    
                                                          administrator to    
                                                          believe that the    
                                                          system is still     
                                                          secure.             

  T.E.PHYSICAL                                                                Security-critical parts of the system may be
                                                                              subjected to a physical attack that may
                                                                              compromise security.

  T.E.RECORD-EVENT-Non-TOE                                Security relevant   
                                                          events not under    
                                                          control of the TOE  
                                                          may not be          
                                                          recorded.           

  T.E.TRACEABLE-Non-TOE                                   Security relevant   
                                                          events not under    
                                                          control of the TOE  
                                                          may not be          
                                                          traceable to the    
                                                          user or system      
                                                          process/processes   
                                                          associated with the 
                                                          event.              
  ----------------------------------- ------------------- ------------------- ---------------------------------------------

[]{#__RefHeading___Toc102926557 .anchor}Table 3.4-2 -- Security threats
addressed by TOE

  -----------------------------------------------------------------------
  **Name**                    **Threat**
  --------------------------- -------------------------------------------
  T.ACCESS                    An authenticated user may gain
                              unauthorized, non-malicious access to the
                              TOE or a resource or to information
                              directly controlled by the TOE via user
                              error, system error, or an unsophisticated,
                              technical attack.

  T.AUDIT-CONFIDENTIALITY     For audit trails under control of the TOE,
                              records of security events may be disclosed
                              to unauthorized individuals or processes.

  T.AUDIT-CORRUPTED           For audit trails under control of the TOE,
                              records of security events may be subjected
                              to unauthorized modification or
                              destruction.

  T.CRASH                     The secure state of the TOE could be
                              compromised in the event of a system crash.

  T.DENIAL                    The TOE may be subjected to an
                              unsophisticated, denial-of-service attack.

  T.ENTRY                     An individual other than an authenticated
                              user may gain unauthorized, malicious
                              access to TOE controlled processing
                              resources or information via an
                              unsophisticated, technical attack. Also Per
                              RBAC

  T.OBSERVE                   Events occur in TOE operation that
                              compromise IT security but the TOE, due to
                              flaws in its specification, design, or
                              implementation, may lead a competent user
                              or security administrator to believe that
                              the system is still secure.

  T.RECORD-EVENT              Security relevant events controlled by the
                              TOE may not be recorded.

  T.RESOURCES                 The shared, internal TOE resources may
                              become exhausted due to system error or
                              non-malicious user actions.

  T.TOE-CORRUPTED             The security state of the TOE, as a result
                              of a lower-grade attack, may be
                              intentionally corrupted to enable future
                              insecurities.

  T.TRACEABLE                 Security relevant events controlled by the
                              TOE may not be traceable to the user or
                              system process/processes associated with
                              the event.
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc102926558 .anchor}Table 3.4-3 -- Security threats
addressed Jointly by TOE and Environment

  ----------------------- ------------- -----------------------------------------------
  T.ACCESS-MALICIOUS                    An authenticated user may obtain unauthorized
                                        access for malicious purposes.

  T.ADMIN-ERROR                         The security of the system may be reduced or
                                        defeated due to errors or omissions in the
                                        administration of the security features of the
                                        system.

  T.CRASH-SYSTEM          The secure    
                          state of the  
                          system could  
                          be            
                          compromised   
                          in the event  
                          of a system   
                          crash.        

  T.INSTALL                             The system may be delivered or installed in a
                                        manner that undermines security.

  T.OPERATE                             Security failures may occur because of improper
                                        operation of the system; e.g., the abuse of
                                        authorized privileges. Also Per RBAC

  T.ROLEDEV                             The development and assignment of user roles
                                        may be done in a manner that undermines
                                        security. Per RBAC

  T.SYSTEM-CORRUPTED                    The security state of the system, as a result
                                        of another threat, may be intentionally
                                        corrupted to enable future insecurities.
  ----------------------- ------------- -----------------------------------------------

###  {#section-1 .unnumbered}

### Threats environment addresses 

The threats discussed below must be countered but are not addressed by
the technical countermeasures within the CCOPP-OS compliant TOE. Such
threats must therefore, be addressed by the operating environment. Note
that a measure of explicit risk acceptance is frequently a viable
option.

**T.E.ACCESS-NON-TECHNICAL:** An authenticated user may gain
non-malicious, unauthorized access using non-technical means.

The use of non-technical attack means; for example, social engineering
or dumpster diving; is beyond the scope of TOE protections and must be
addressed by the environment.

**T.E.ACCESS-Non-TOE:** An authenticated user may gain unauthorized,
non-malicious access to a resource or to information [not]{.underline}
controlled by the TOE via user error, system error, or an
unsophisticated, technical attack.

An authenticated user is someone who is (1) uniquely identifiable by the
system, (2) has legitimate access beyond publicly available information,
and (3) is authenticated prior to being granted such access.

By virtue of having access, the threat posed from authenticated users is
inherently greater than that posed from unauthorized individuals. CCOPP
systems are expected to have only the assurances necessary to cover the
threat of non-malicious actions by authenticated users; i.e., sufficient
confidence in light of the fact that only non-malicious actions are
covered.

There are two broad categories of users with respect to this threat:

-   The first category are persons who possess little technical skills,
    do not have access to sophisticated attack tools, have some rights
    of access, and are mostly trusted not to attempt to maliciously
    subvert the system nor maliciously exploit the information stored
    thereon. Users in this category may be motivated by curiosity to
    gain access to information for which they have no authorization.

-   The second category of users is technically skilled or has access to
    sophisticated attack tools and some may attempt to bypass system
    controls as a technical challenge or as a result of curiosity. CCOPP
    compliant components and systems would generally be used in
    environments where these users are highly trusted not to attempt to
    maliciously subvert the system nor to maliciously exploit the
    information stored thereon.

**T.E.AUDIT-CONFIDENTIALITY-Non-TOE:** Records of security events
[not]{.underline} under control of the TOE may be disclosed to
unauthorized individuals or processes.

System security depends in part on the ability of the system to detect
and report the occurrence of security relevant events, to determine the
identity of those responsible for such events, and to protect the event
records from unauthorized access, modification, or destruction.

**T.EAUDIT-CORRUPTED-Non-TOE:** Records of security events
[not]{.underline} under control of the TOE may be subjected to
unauthorized modification or destruction.

**T.E.DENIAL-Non-TOE:** The IT other than the TOE may be subjected to an
unsophisticated, denial-of-service attack.

The IT in the TOE environment is expected to be able to withstand
unsophisticated denial-of-service attacks.

**T.E.DENIAL-SOPHISTICATED:** The system may be subjected to a
sophisticated, denial-of-service attack.

A system built from near-term COTS is not expected to be capable of
resisting sophisticated attacks. Therefore, such a system must rely on
protections provided by its non-IT environment to maintain availability
in the face of such threats.

**T.E.ENTRY-NON-TECHNICAL:** An individual, other than an authenticated
user, may gain access to processing resources or information using
non-technical means.

**T.E.ENTRY-Non-TOE:** An individual other than an authenticated user
may gain unauthorized, malicious access to processing resources or
information [not]{.underline} controlled by the TOE via an
unsophisticated, technical attack.

The mechanisms and assurances of a near-term COTS system will resist
low-grade technical attacks. (Resistance to higher-grade attacks, when
such resistance is required, must be provide by the system's operational
environment.)

**T.E.ENTRY-SOPHISTICATED:** An individual, other than an authenticated
user, may gain access to processing resources or information using a
sophisticated, technical attack.

A system built from near-term COTS is not expected to protect itself
against sophisticated, technical attacks. Therefore, this threat is
largely addressed by the system's operational environment.

**T.E.OBSERVE-Non-TOE:** Events occur in operation of IT other than the
TOE that compromise security but the IT, due to flaws in its
specification, design, or implementation, may lead a competent user or
security administrator to believe that the system is still secure.

This is the threat of an administrator or user not detecting a security
problem because of errors or omissions in the IT's human interface. The
IT is then used in a manner which is insecure but which the
administrator or user reasonably, but incorrectly, believes to be
secure.

**T.E.PHYSICAL**: Security-critical parts of the system may be subjected
to a physical attack that may compromise security.

The security offered by CCOPP can be assured only to the extent that the
hardware and software relied upon to enforce the security policy is
physically protected from unauthorized physical modification and from
technical attacks at the hardware level. Examples of such attacks are
using electromagnetic pulse weapons, intercepting radiated electronic
emissions, and passive monitoring or active attacking of physical
transmission medium (e.g., coax, twisted-pair, or fiber optic cable).

**T.E.RECORD-EVENT-Non-TOE:** Security relevant events which IT other
than the TOE is expected to record may not be recorded.

**T.E.TRACEABLE-Non-TOE:** Due to the IT other than the TOE, security
relevant events may not be traceable to the user or system process
associated with the event.

###  {#section-2 .unnumbered}

### Threats TOE addresses

Technical countermeasures within the CCOPP-OS compliant TOE address the
threats discussed below.

**T.ACCESS:** An authenticated user may gain unauthorized, non-malicious
access to a resource or to information controlled by the TOE via user
error, system error, or an unsophisticated, technical attack.

An authenticated user is someone who is (1) uniquely identifiable by the
system, (2) has legitimate access beyond publicly available information,
and (3) is authenticated prior to being granted such access.

By virtue of having access, the threat posed from authenticated users is
inherently greater than that posed from unauthorized individuals.
CCOPP-OS operating systems are required to have only the assurances
necessary to cover the threat of non-malicious actions by authenticated
users; i.e., sufficient confidence in light of the fact that only
non-malicious actions are covered.

There are two broad categories of users with respect to this threat:

-   The first category are persons who possess little technical skills,
    do not have access to sophisticated attack tools, and, because they
    have some rights of access, are mostly trusted not to attempt to
    maliciously subvert the system nor maliciously exploit the
    information stored thereon. Users in this category may be motivated
    by curiosity to gain access to information for which they have no
    authorization.

-   The second category of users is technically skilled or has access to
    sophisticated attack tools and some may attempt to bypass system
    controls as a technical challenge or as a result of curiosity.
    CCOPP-OS compliant operating systems would generally be used in
    environments where these users are highly trusted not to attempt to
    maliciously subvert the system nor to maliciously exploit the
    information stored thereon.

**T.AUDIT-CONFIDENTIALITY:** Records of security events under control of
the TOE may be disclosed to unauthorized individuals or processes.

TOE security depends in part on the ability of the TOE to detect and
report the occurrence of security relevant events, to determine the
identity of those responsible for such events, and to protect the event
records from unauthorized access, modification, or destruction.

**T.AUDIT-CORRUPTED:** Records of security events under control of the
TOE may be subjected to unauthorized modification or destruction.

**T.CRASH**: The secure state of the TOE could be compromised in the
event of a system crash.

For the TOE to protect the information it controls, it must remain in a
secure state, including after recovery from a system failure or
discontinuity of service.

System crash can occur with inadequate mechanisms for secure recovery.
Data objects and audit information may be modified or lost and system
software may be corrupted.

**T.DENIAL:** The TOE may be subjected to an unsophisticated,
denial-of-service attack.

The TOE must be able to withstand unsophisticated denial-of-service
attacks.

**T.ENTRY:** An individual other than an authenticated user may gain
unauthorized, malicious access to processing resources or information
controlled by the TOE via an unsophisticated, technical attack.

The mechanisms and assurances of a TOE compliant with this PP will
resist low-grade technical attacks. (Resistance to higher-grade attacks,
when such resistance is required, must be provide by the TOE operational
environment.)

**T.OBSERVE:** Events occur in TOE operation that compromise IT security
but the TOE, due to flaws in its specification, design, or
implementation, may lead a competent user or security administrator to
believe that the system is still secure.

This is the threat of an administrator or user not detecting a security
problem because of errors or omissions in the TOE's human interface. The
TOE is then used in a manner which is insecure but which the
administrator or user reasonably, but incorrectly, believes to be
secure.

**T.RECORD-EVENT:** Security relevant events which the TOE is expected
to record may not be recorded.

**T.RESOURCES:** The shared, internal TOE resources may become exhausted
due to system error or non-malicious user actions.

System availability depends partly on the availability of shared
resources.

**T.TOE-CORRUPTED:** The security state of the TOE, as a result of a
lower-grade attack, may be intentionally corrupted to enable future
insecurities.

System security depends to a large degree on the integrity of the
hardware and software implementing the security functionality. If this
is intentionally corrupted, the TOE will be unable to maintain a secure
state.

**T.TRACEABLE:** Due to the TOE, security relevant events may not be
traceable to the user or system process associated with the event.

### Threats TOE and Environment jointly address

These threats are addressed by a combination of technical controls
within the TOE and environmental controls (both technical and
non-technical).

**T.ACCESS-MALICIOUS:** An authenticated user may obtain unauthorized
access for malicious purposes.

CCOPP-OS functionality and assurances are sufficient mitigation for
non-malicious actions by authenticated users. The greater risk from
malicious actions by authenticated users must be addressed in
conjunction with the environment.

**T.ADMIN-ERROR:** The system security may be reduced or defeated due to
errors or omissions in the administration of the security features of
the TOE or other IT.

Authenticated users or external threat agents may, through accidental
discovery or directed search, discover inadequacies in the security
administration of the TOE, or other IT, which permit them to gain
unauthorized access.

**T.CRASH-SYSTEM**: The secure state of the system could be compromised
in the event of a system crash.

For the IT to protect the information it controls, it must remain in a
secure state, including after recovery from a system failure or
discontinuity of service. System crash can occur with inadequate
mechanisms for secure recovery. User data objects and audit information
may be modified or lost and system or application software may
corrupted.

The TOE is unable to ensure recovery for IT other than itself. However,
the TOE, as the underlying operating system, is expected to cooperate
with its environment in accomplishing this recovery.

**T.INSTALL:** The system may be delivered or installed in a manner that
undermines security.

The system security is predicated upon the IT being initially
established in a secure state. That includes assurance that the TOE
delivered is that which was evaluated and that the TOE, and other IT, is
subsequently installed properly.

The TOE will be expected to provide significant support toward its own
installation and toward the installation of other IT. However, due to
the nature of the problem, significant support from the TOE's
environment will be required in addressing this threat.

**T.OPERATE:** Security failures may occur because of improper
operation; e.g., the abuse of authorized privileges.

The system security can be assured only to the extent that the TOE, and
other IT, is operated correctly by system administrators and
authenticated users in accordance with security policy. The TOE will
provide mechanisms that help mitigate this threat with respect to TOE
operation and perhaps the operation of other IT. Additionally, specific
environmental controls are still required for both the TOE and for other
IT.

**T.ROLEDEV** The development and assignment of user roles may be done
in a manner that undermines security.

In general, roles could be developed which have an incorrect or improper
combination of authorizations to perform operations on objects. In
addition, users could be assigned to roles that are incommensurate with
their duties, giving them either too much or too little scope of
authorization.

A particular concern arises in that users could be assigned conflicting
roles with respect to 'separation of duties'. An individual user could
be authorized to perform multiple operations on data objects that
represent the parts of a transaction that should be separated among
different individuals.

**T.SYSTEM-CORRUPTED:** The security state of the system, as a result of
corruption of IT other than the TOE or as a result of a higher-grade
attack, may be intentionally corrupted to enable future insecurities.

System security depends to a large degree on the integrity of the
hardware and software implementing the security functionality. If this
is intentionally corrupted, the IT will be unable to maintain a secure
state. As an underlying operating system, the TOE will provide part of
the protection for the system with respect to lower-grade threats. The
TOE can only partially protect against higher-grade threats and may be
able to only partially protect IT other than the TOE itself from
lower-grade attacks. (See T.TOE-CORRPUTED for corruption of the TOE by
lower-grade attacks.)

## General assurance need 

CCOPP-OS compliant TOEs are targeted for near-term achievable,
cost-effective, Compartmentalized Operations security. In keeping with
this target, the general level of assurance for CCOPP-OS must:

-   be consistent with current best commercial practice for IT
    development, and

-   enable evaluated products that are competitive against non-evaluated
    products with respect to functionality, performance, cost, and
    time-to-market

In keeping with these requirements, the general level of assurance
needed for CCOPP-OS is EAL4 to include vendor actions within the scope
of current best commercial practice.

#  security objectives 

## Environmental security objectives

Addressing some policies and threats is beyond the capabilities of the
CCOPP-OS compliant TOEs. This results in the environmental objectives
listed in Table 4-1. The TOE does not contribute significantly to
meeting these objectives.

The purpose of the environmental objectives (in conjunction with the
Joint objectives) is to state what is expected of the TOE's environment
in terms of risk mitigation or explicit risk acceptance.

[]{#__RefHeading___Toc102926559 .anchor}Table 4-1 -- Environmental
Security Objectives

+----------------------------------------------+-----------------------+
| **Environmental Security Objective**         | **Corresponding       |
|                                              | Threat or Policy**    |
+==============================================+=======================+
| **O.E.ACCESS-NON-TECHNICAL:** The TOE        | T                     |
| environment must provide sufficient          | .ACCESS-NON-TECHNICAL |
| protection against non-technical attacks by  |                       |
| authenticated users for non-malicious        | P.ACCESS              |
| purposes. This will be accomplished          |                       |
| primarily via prevention with a goal of high |                       |
| effectiveness. Personnel security and user   |                       |
| training and awareness will provide a major  |                       |
| part of achieving this objective.            |                       |
+----------------------------------------------+-----------------------+
| **O.E.ACCESS-Non-TOE:** The IT other than    | P.ACCESS              |
| the TOE must provide public access and       |                       |
| access by authenticated users to the         |                       |
| resources and actions for which they have    |                       |
| been authorized and over which the TOE does  |                       |
| not exercise control. The focus is on        |                       |
| prevention with a high degree of             |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.E.ACCOUNTABILITY-Non-TOE**: The IT other | P.ACCOUNTABILITY      |
| than the TOE must ensure, for actions under  |                       |
| its control or knowledge, that all users can | T.TRACEABLE-Non-TOE   |
| subsequently be held accountable for their   |                       |
| security relevant actions. This is expected  | T                     |
| with a high degree of effectiveness.         | .RECORD-EVENT-Non-TOE |
|                                              |                       |
|                                              | T.AU                  |
|                                              | DIT-CORRUPTED-Non-TOE |
|                                              |                       |
|                                              | T.AUDIT-CO            |
|                                              | NFIDENTIALITY-Non-TOE |
+----------------------------------------------+-----------------------+
| **O.E.AUTHORIZATION-Non-TOE:** The IT other  | P.ACCESS              |
| than the TOE 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. This is  |                       |
| expected with a high degree of               |                       |
| effectiveness.                               |                       |
|                                              |                       |
| NOTE: This includes initializing, specifying |                       |
| and managing (1) object security attributes, |                       |
| (2) active entity identity and security      |                       |
| attributes, and (3) security relevant        |                       |
| environmental conditions.                    |                       |
+----------------------------------------------+-----------------------+
| **O.E.AVAILABLE-Non-TOE:** The IT other than | P.SURVIVE             |
| the TOE must protect itself from             |                       |
| unsophisticated, denial-of-service attacks.  | T.DENIAL-Non-TOE      |
| This is a combination of prevention and      |                       |
| detect and recover with a high degree of     |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.E.BYPASS-Non-TOE:** For access not       | T.ACCESS-Non-TOE      |
| controlled by the TOE, IT other than the TOE |                       |
| must prevent errant or non-malicious,        |                       |
| authorized software or users from bypassing  |                       |
| or circumventing security policy             |                       |
| enforcement. This will be accomplished with  |                       |
| high effectiveness.                          |                       |
|                                              |                       |
| NOTE: This objective is limited to           |                       |
| 'non-malicious' because IT controls in the   |                       |
| notional CCOPP system are not expected to    |                       |
| provide sufficient mitigation for the        |                       |
| greater negative impact that 'malicious'     |                       |
| implies.                                     |                       |
+----------------------------------------------+-----------------------+
| **O.E.CONNECT** Those responsible for the    | T.ACCESS              |
| TOE must ensure that no connections to       |                       |
| outside systems or users undermine the       | P.ACCESS              |
| security of IT assets.                       |                       |
+----------------------------------------------+-----------------------+
| **O.E.CREDEN:** Those responsible for the    | P.NEED_TO_KNOW        |
| TOE must ensure that all access credentials, |                       |
| such as passwords or other authentication    |                       |
| information, are protected by the users in a |                       |
| manner which maintains IT security           |                       |
| objectives.                                  |                       |
+----------------------------------------------+-----------------------+
| **O.E.DENIAL-SOPHISTICATED:** The TOE        | P.SURVIVE             |
| environment must maintain system             |                       |
| availability in the face of sophisticated    | T                     |
| denial-of-service attacks. The focus is on   | .DENIAL-SOPHISTICATED |
| detection and response with a goal of        |                       |
| moderate effectiveness.                      |                       |
+----------------------------------------------+-----------------------+
| **O.E.DETECT-SOPHISTICATED:** The TOE        | P.SURVIVE             |
| environment must provide the ability to      |                       |
| detect sophisticated attacks and the results | T.SYSTEM-CORRUPTED    |
| of such attacks (e.g., corrupted system      |                       |
| state). The goal is for moderate             |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.E.ENTRY-NON-TECHNICAL:** The TOE         | T.ENTRY-NON-TECHNICAL |
| environment must provide sufficient          |                       |
| protection against non-technical attacks by  |                       |
| other than authenticated users. This will be |                       |
| accomplished primarily via prevention with a |                       |
| goal of high effectiveness. User training    |                       |
| and awareness will provide a major part of   |                       |
| achieving this objective.                    |                       |
+----------------------------------------------+-----------------------+
| **O.E.ENTRY-Non-TOE:** For resources not     | P.USAGE               |
| controlled by the TOE, IT other than the TOE |                       |
| must prevent logical entry using             | T.ENTRY-Non-TOE       |
| unsophisticated, technical methods, by       |                       |
| persons without authority for such access.   |                       |
| This is clearly a prevent focus and is to be |                       |
| achieved with a high degree of               |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.E.ENTRY-SOPHISTICATED:** The TOE         | T.ENTRY-SOPHISTICATED |
| environment must sufficiently mitigate the   |                       |
| threat of an individual (other than an       |                       |
| authenticated user) gaining unauthorized     |                       |
| access via sophisticated, technical attack.  |                       |
| This will be accomplished by focusing on     |                       |
| detection and response with a goal of        |                       |
| moderate effectiveness.                      |                       |
+----------------------------------------------+-----------------------+
| **O.E.INFO-FLOW:** The TOE environment must  | P.INFO-FLOW           |
| ensure that any information flow control     |                       |
| policies are enforced - (1) between system   |                       |
| components and (2) at the system external    |                       |
| interfaces. This will be accomplished by     |                       |
| preventing unauthorized flows with high      |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.E.KNOWN-Non-TOE:** The IT other than the | P.KNOWN               |
| TOE must ensure that, for all actions under  |                       |
| its control and except for a well-defined    |                       |
| set of allowed actions, all users are        |                       |
| identified and authenticated before being    |                       |
| granted access. This is expected with a high |                       |
| degree of effectiveness.                     |                       |
+----------------------------------------------+-----------------------+
| **O.E.OBSERVE-Non-TOE**: The IT other than   | T.OBSERVE-Non-TOE     |
| the TOE must ensure that its security status |                       |
| is not misrepresented to the administrator   |                       |
| or user. This is a combination of prevent    |                       |
| and detect and, considering the potentially  |                       |
| large number of possible failure modes, is   |                       |
| to be achieved with a moderate, verses high, |                       |
| degree of effectiveness.                     |                       |
+----------------------------------------------+-----------------------+

## TOE security objectives

While the environment contributes to the satisfaction of nearly all
objectives, those listed here are satisfied by the TOE with only generic
environmental support such as user training.

Table 4-2 gives the security objectives to be met by CCOPP-OS compliant
TOEs.

[]{#__RefHeading___Toc102926560 .anchor}Table 4-2 -- TOE Security
Objectives

+----------------------------------------------+-----------------------+
| **TOE Security Objective**                   | **Corresponding       |
|                                              | Threat or Policy**    |
+==============================================+=======================+
| **O.ACCESS:** The TOE must provide public    | P.ACCESS              |
| access and access by authenticated users to  |                       |
| those TOE resources and actions for which    |                       |
| they have been authorized. This will be      |                       |
| accomplished with high effectiveness.        |                       |
+----------------------------------------------+-----------------------+
| **O.ACCOUNTABILITY**: The TOE must ensure,   | P.ACCOUNTABILITY      |
| for actions under its control or knowledge,  |                       |
| that all TOE users can subsequently be held  | T.TRACEABLE           |
| accountable for their security relevant      |                       |
| actions. This will be done with moderate     | T.RECORD-EVENT        |
| effectiveness, in that it is anticipated     |                       |
| that individual accountability might not be  | T.AUDIT-CORRUPTED     |
| achieved for some actions.                   |                       |
|                                              | T.                    |
|                                              | AUDIT-CONFIDENTIALITY |
+----------------------------------------------+-----------------------+
| **O.AUDITING:** The TSF must record the      | P.ACCOUNTABILITY      |
| security relevant actions of users of the    |                       |
| TOE. The TSF must present this information   |                       |
| to authorized administrators. (Also RBAC     |                       |
| O.AUDIT)                                     |                       |
+----------------------------------------------+-----------------------+
| **O.AUTHORIZATION:** The TOE must provide    | P.ACCESS              |
| the ability to specify and manage user and   |                       |
| system process access rights to individual   | P.AUTHORIZED_USER     |
| processing resources and data elements under |                       |
| its control, supporting the organization's   |                       |
| security policy for access control. This     |                       |
| will be accomplished with high               |                       |
| effectiveness.                               |                       |
|                                              |                       |
| NOTE: This includes initializing, specifying |                       |
| and managing (1) object security attributes, |                       |
| (2) active entity identity and security      |                       |
| attributes, and (3) security relevant        |                       |
| environmental conditions.                    |                       |
+----------------------------------------------+-----------------------+
| **O.AVAILABLE:** The TOE must protect itself | P.SURVIVE             |
| from unsophisticated, denial-of-service      |                       |
| attacks. This will include a combination of  | T.DENIAL              |
| protection and detection with high           |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.BYPASS:** The TOE must prevent errant or | T.ACCESS              |
| non-malicious, authorized software or users  |                       |
| from bypassing or circumventing TOE security |                       |
| policy enforcement. This will be             |                       |
| accomplished with high effectiveness.        |                       |
+----------------------------------------------+-----------------------+
| **O.CONNECT** Those responsible for the TOE  | T.ACCESS              |
| must ensure that no connections to outside   |                       |
| systems or users undermine the security of   | P.ACCESS              |
| IT assets.                                   |                       |
+----------------------------------------------+-----------------------+
| **O.CREDEN:** Those responsible for the TOE  | P.NEED_TO_KNOW        |
| must ensure that all access credentials,     |                       |
| such as passwords or other authentication    |                       |
| information, are protected by the users in a |                       |
| manner which maintains IT security           |                       |
| objectives.                                  |                       |
+----------------------------------------------+-----------------------+
| **O.DETECT:** The TOE must enable the        | P.SURVIVE             |
| detection of TOE specific insecurities. The  |                       |
| goal is high effectiveness for lower grade   | T.TOE-CORRUPTED       |
| attacks.                                     |                       |
+----------------------------------------------+-----------------------+
| **O.DISCRETIONARY_ACCESS:** The TSF must     | P.AUTHORIZED_USER     |
| control access to resources based on         |                       |
| identity of users. The TSF must allow        |                       |
| authorized users to specify which resources  |                       |
| may be accessed by which users.              |                       |
+----------------------------------------------+-----------------------+
| **O.DUTY** The TOE must provide the          | P.NEED_TO_KNOW        |
| capability of enforcing 'separation of       |                       |
| duties', so that no single user has to be    | T.OPERATE             |
| granted the right to perform all operations  |                       |
| on important information.                    | T.ROLEDEV             |
+----------------------------------------------+-----------------------+
| **O.ENFORCEMENT:** The TSF must be designed  | P.ACCOUNTABILITY      |
| and implemented in a manner which ensures    |                       |
| that the organizational policies are         |                       |
| enforced in the target environment.          |                       |
+----------------------------------------------+-----------------------+
| **O.ENTRY:** The TOE must prevent logical    | P.USAGE               |
| entry to the TOE using unsophisticated,      |                       |
| technical methods, by persons without        | T.ENTRY               |
| authority for such access. This will be      |                       |
| accomplished with high effectiveness.        |                       |
+----------------------------------------------+-----------------------+
| **O.INSTALL:** Those responsible for the TOE | P.ACCOUNTABILITY      |
| must ensure that the TOE is delivered,       |                       |
| installed, managed, and operated in a manner |                       |
| which maintains IT security objectives.      |                       |
+----------------------------------------------+-----------------------+
| **O.KNOWN:** The TOE must ensure that, for   | P.KNOWN T.ENTRY       |
| all actions under its control and except for |                       |
| a well-defined set of allowed actions, all   |                       |
| users are identified and authenticated       |                       |
| before being granted access. This will be    |                       |
| accomplished with high effectiveness.        |                       |
+----------------------------------------------+-----------------------+
| **O.MANDATORY_ACCESS:** The TSF must control | P                     |
| access to resources based upon the           | .COMPARTMENTALIZATION |
| compartment of the information being         |                       |
| accessed.                                    |                       |
+----------------------------------------------+-----------------------+
| **O.OBSERVE**: The TOE must ensure that its  | T.OBSERVE             |
| security status is not misrepresented to the |                       |
| administrator or user. This is a combination |                       |
| of prevent and detect and, considering the   |                       |
| potentially large number of possible failure |                       |
| modes, is to be achieved with a moderate,    |                       |
| verses high, degree of effectiveness.        |                       |
+----------------------------------------------+-----------------------+
| **O.RECOVER:** The TOE must provide for      | P.SURVIVE             |
| recovery to a secure state following a       |                       |
| system failure, discontinuity of service, or | T.CRASH               |
| detection of an insecurity. This will be     |                       |
| accomplished with a high effectiveness for   |                       |
| specified failures and a low effectiveness   |                       |
| for failures in general.                     |                       |
+----------------------------------------------+-----------------------+
| **O.RESOURCES:** The TOE must protect itself | P.SURVIVE             |
| from user or system errors that result in    |                       |
| shared resource exhaustion. This will be     | T.RESOURCES           |
| accomplished via protection with high        |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.RESIDUAL_INFORMATION:** The TSF must     | P.NEED_TO_KNOW        |
| ensure that any information contained in a   |                       |
| protected resource is never revealed when    |                       |
| the resource is reused.                      |                       |
+----------------------------------------------+-----------------------+
| **O.PHYSICAL:** Those responsible for the    | P.PHYSICAL            |
| TOE must ensure that those parts of the TOE  |                       |
| critical to security policy are protected    | T.PHYSICAL            |
| from physical attack that might compromise   |                       |
| IT security. This will be accomplished       |                       |
| primarily via prevention with a goal of high |                       |
| effectiveness.                               |                       |
+----------------------------------------------+-----------------------+
| **O.ROLE** The TOE must prevent users from   | T.ROLEDEV             |
| gaining access to and performing operations  |                       |
| on its resources/objects unless they have    |                       |
| been granted access by the resource/object   |                       |
| owner or they have been assigned to a role   |                       |
| (by an authorized administrator) which       |                       |
| permits those operations.                    |                       |
+----------------------------------------------+-----------------------+

## Joint TOE/Environment security objectives 

The objectives listed here fall into one or more of the following
categories:

a.  The TOE and its environment together satisfy the objective as
    follows:

    1.  TOE - contributes in a significant manner and

    2.  Environment - contribution is specific to this objective; i.e.,
        not the result of a general contribution such as user training.

b.  At the level of abstraction of this PP either:

    1.  It is not possible to accurately determine the split between TOE
        and environmental contribution, or

    2.  Multiple, compliant solutions are feasible resulting in
        different mixes of TOE and environmental contributions

[]{#__RefHeading___Toc102926561 .anchor}Table 4-3 -- Joint
TOE/Environment Security Objectives

+-----------------------------------------------+----------------------+
| **Joint Security Objective**                  | **Corresponding      |
|                                               | Threat or Policy**   |
+-----------------------------------------------+----------------------+
| **O.ACCESS-MALICIOUS:** The TOE controls will | T.ACCESS-MALICIOUS   |
| help in achieving this objective, but will    |                      |
| not be sufficient. Additional, environmental  |                      |
| controls are required to sufficiently         |                      |
| mitigate the threat of malicious actions by   |                      |
| authenticated users. This will be             |                      |
| accomplished by focusing on deterrence,       |                      |
| detection, and response with a goal of        |                      |
| moderate effectiveness.                       |                      |
+-----------------------------------------------+----------------------+
| **O.COMPLY:** The TOE environment, in         | P.COMPLY             |
| conjunction with controls implemented by the  |                      |
| TOE, must support full compliance with        |                      |
| applicable laws, regulations, and contractual |                      |
| agreements. This will be accomplished via     |                      |
| some technical controls, yet with a focus on  |                      |
| non-technical controls to achieve this        |                      |
| objective with high effectiveness.            |                      |
+-----------------------------------------------+----------------------+
| **O.DETECT-SYSTEM:** The TOE, in conjunction  | P.SURVIVE            |
| with other IT in the system, must enable the  |                      |
| detection of system insecurities. The goal is | T.SYSTEM-CORRUPTED   |
| high effectiveness for lower grade attacks.   |                      |
+-----------------------------------------------+----------------------+
| **O.DUE-CARE:** The TOE environment, in       | P.DUE-CARE           |
| conjunction with the TOE itself, must be      |                      |
| implemented and operated in a manner that     |                      |
| clearly demonstrates due-care and diligence   |                      |
| with respect to IT-related risks to the       |                      |
| organization. This will be accomplished via a |                      |
| combination of technical and non-technical    |                      |
| controls to achieve this objective with high  |                      |
| effectiveness.                                |                      |
+-----------------------------------------------+----------------------+
| **O.MANAGE:** The TSF must provide all the    | P.ACCOUNTABILITY     |
| functions and facilities necessary to support |                      |
| the authorized administrators, who are then   | T.ADMIN-ERROR        |
| responsible for the management of TOE         |                      |
| security.                                     |                      |
+-----------------------------------------------+----------------------+
| **O.NETWORK:** The system must be able to     | P.NETWORK            |
| meet its security objectives in a distributed |                      |
| environment. This will be accomplished with   | #########Clarify     |
| high effectiveness.                           |                      |
|                                               |                      |
| Note: One mechanism that could help in        |                      |
| addressing this objective is trusted path.    |                      |
| However, COTS operating systems do not        |                      |
| typically provide a trusted path between user |                      |
| and system and hence CCOPP-OS does not        |                      |
| require that the TOE provide it. Instead,     |                      |
| when the TOE does not provide a trusted path, |                      |
| the protection that would have been provided  |                      |
| by a trusted path is addressed by a           |                      |
| combination of environmental controls such as |                      |
| add-on IT packages, non-technical controls    |                      |
| (physical, procedural, personnel), and risk   |                      |
| acceptance.                                   |                      |
+-----------------------------------------------+----------------------+
| **O.OPERATE**: Those responsible for the      | T.INSTALL            |
| system (in conjunction with mechanisms        |                      |
| provided by the TOE) must ensure that the     | T.OPERATE            |
| system is delivered, installed, and operated  |                      |
| in a manner which maintains IT security. This | P.TRAINING           |
| will be accomplished with moderate            |                      |
| effectiveness.                                |                      |
+-----------------------------------------------+----------------------+
| **O.RECOVER-SYSTEM:** The system must provide | P.SURVIVE            |
| for recovery to a secure state following a    |                      |
| system failure, discontinuity of service, or  | T.CRASH-SYSTEM       |
| detection of an insecurity. This will be      |                      |
| accomplished with some prevention and a       |                      |
| majority of detect and respond, with high     |                      |
| effectiveness for specified failures. For     |                      |
| general failure, this will be accomplished    |                      |
| with low effectiveness.                       |                      |
+-----------------------------------------------+----------------------+

# Functional Security REQUIREMENTS

This section contains the functional requirements that must be satisfied
by the notional CCOPP system. These requirements consist of functional
components from Part 2 of the CC, in some cases with modifications.

Table 5-1 lists the functional requirements CCOPP-OS compliant TOEs. All
functional and assurance dependencies associated with the components in
Table 5-1 have been satisfied.

Appendix B contains the explicit functional requirements that are
summarized here.

[]{#__RefHeading___Toc102926562 .anchor}Table 5-1 -- Functional
Components - TOE

+----+--------+-------------------+--------------+--------------------+
|    | CC     | Name              | > Auditable  | > Objectives       |
|    | Com    |                   | > event      | > function helps   |
|    | ponent |                   |              | > address          |
+====+========+===================+==============+====================+
| 5  | **     | Audit data        | Start-up and | O.ACCOUNTABILITY   |
| .1 | FAU**\ | Generation        | shutdown of  |                    |
| .1 | _GEN.1 |                   | the audit    | O.Recover          |
|    | -CCOPP |                   | functions    |                    |
|    |        |                   |              | O.Recover-system   |
|    |        |                   |              |                    |
|    |        |                   |              | O.Detect           |
|    |        |                   |              |                    |
|    |        |                   |              | O.DETECT-SYSTEM    |
|    |        |                   |              |                    |
|    |        |                   |              | o.operate          |
|    |        |                   |              |                    |
|    |        |                   |              | o.manage           |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | User Identity     | None         | o.ACCOUNTABILITY   |
| .1 | _GEN.2 | Generation        |              |                    |
| .2 | -CCOPP |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Audit Review      | Reading      | Required           |
| .1 | _SAR.1 |                   |              | dependency for:    |
| .3 |        |                   |              |                    |
|    |        |                   |              | FAU_SAR.2          |
|    |        |                   |              |                    |
|    |        |                   |              | FAU_SAR.3          |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Restricted Audit  | Unsuccessful | O.bypasS           |
| .1 | _SAR.2 | Review            | attempts to  |                    |
| .4 |        |                   | read         |                    |
|    |        |                   | information  |                    |
|    |        |                   | from the     |                    |
|    |        |                   | audit        |                    |
|    |        |                   | records      |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Selectable Audit  | None         | o.ACCOUNTABILITY   |
| .1 | _SAR.3 | Review            |              |                    |
| .5 |        |                   |              | o.recoveR          |
|    |        |                   |              |                    |
|    |        |                   |              | O.Recover-system   |
|    |        |                   |              |                    |
|    |        |                   |              | o.detecT\          |
|    |        |                   |              | O.DETECT-SYSTEM    |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.operate          |
|    |        |                   |              |                    |
|    |        |                   |              | o.manage           |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Selective Audit   | All          | o.due-care         |
| .1 | _SEL.1 |                   | m            |                    |
| .6 | -CCOPP |                   | odifications | o.detect\          |
|    |        |                   | to the audit | O.DETECT-SYSTEM    |
|    |        |                   | c            |                    |
|    |        |                   | onfiguration | o.manage           |
|    |        |                   | that occur   |                    |
|    |        |                   | while the    | o.operate          |
|    |        |                   | audit        |                    |
|    |        |                   | collection   | o.comply           |
|    |        |                   | functions    |                    |
|    |        |                   | are          |                    |
|    |        |                   | operating    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Protected audit   | None         | o.detect\          |
| .1 | _STG.1 | trail storage     |              | O.DETECT-SYSTEM    |
| .7 | -CCOPP |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
|    |        |                   |              |                    |
|    |        |                   |              | o.ACCOUNTABILITY   |
|    |        |                   |              |                    |
|    |        |                   |              | o.bypass           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Action in case of | Actions      | o.ACCOUNTABILITY   |
| .1 | _STG.3 | Possible Audit    | taken due to |                    |
| .8 | -CCOPP | Data Loss         | exceeding of | o.due-care         |
|    |        |                   | a threshold  |                    |
|    |        |                   |              | o.manage           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FAU    | Prevention of     | Actions      | O.DETECT-SYSTEM    |
| .1 | _STG.4 | audit data loss   | taken due to | o.due-care         |
| .9 | -CCOPP |                   | the audit    |                    |
|    |        |                   | storage      | o.comply           |
|    |        |                   | failure      |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Subset Access     | None         | o.access\          |
| .2 | FDP**\ | Control           |              | o.access-malicious |
| .1 | _ACC.1 |                   |              |                    |
|    | -CCOPP |                   |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
|    |        |                   |              |                    |
|    |        |                   |              | o.available        |
|    |        |                   |              |                    |
|    |        |                   |              | o.resources        |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Security          | All requests | o.access\          |
| .2 | _ACF.1 | Attribute Based   | to perform   | o.access-malicious |
| .2 | -CCOPP | Access Control    | an operation |                    |
|    |        |                   | on an object | o.entry            |
|    |        |                   | covered by   |                    |
|    |        |                   | the sfp      | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
|    |        |                   |              |                    |
|    |        |                   |              | o.available        |
|    |        |                   |              |                    |
|    |        |                   |              | o.resources        |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Export Of User    | All attempts | o.bypass           |
| .2 | _ETC.1 | Data Without      | to export    |                    |
| .3 | -CCOPP | Security          | information  | o.due-care         |
|    |        | Attributes        |              |                    |
|    |        |                   |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | o.available        |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Complete          | None         | O.MANDATORY_ACCESS |
| .2 | _IFC.2 | Information Flow  |              |                    |
| .4 | -CCOPP | Control           |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Simple Security   | None         | O.MANDATORY_ACCESS |
| .2 | _IFF.1 | Attributes        |              |                    |
| .5 | -CCOPP |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Import Of User    | All attempts | o.network          |
| .2 | _ITC.1 | Data Without      | to import    |                    |
| .6 | -CCOPP | Security          | user data,   |                    |
|    |        | Attributes        | including    |                    |
|    |        |                   | any security |                    |
|    |        |                   | attributes   |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP_R  | Object Residual   | None         | o.bypass           |
| .2 | IP.2-1 | Information       |              |                    |
| .7 | -CCOPP | Protection        |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | O.Re               |
|    |        |                   |              | sidual_Information |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP_R  | Subject Residual  | None         | o.bypass           |
| .2 | IP.2-2 | Information       |              |                    |
| .8 | -CCOPP | Protection        |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | O.Re               |
|    |        |                   |              | sidual_Information |
+----+--------+-------------------+--------------+--------------------+
| 5  | FDP    | Basic Data        | All attempts | o.network          |
| .2 | _UCT.1 | Exchange          | to exchange  |                    |
| .9 | -CCOPP | Confidentiality   | user data,   |                    |
|    |        |                   | including    |                    |
|    |        |                   | any security |                    |
|    |        |                   | attributes   |                    |
+----+--------+-------------------+--------------+--------------------+
| 5. | FDP    | Data Exchange     | All attempts | o.network          |
| 2. | _UIT.1 | Integrity         | to exchange  |                    |
| 10 | -CCOPP |                   | information  |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Authentication    | All failures | o.detect\          |
| .3 | FIA**\ | Failure Handling  | in           | O.DETECT-SYSTEM    |
| .1 | _AFL.1 |                   | au           |                    |
|    | -CCOPP |                   | thentication | o.entry            |
|    |        |                   | and exchange |                    |
|    |        |                   |              | o.bypass           |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | User Attribute    | None         | O.AUTHORIZATION    |
| .3 | _ATD.1 | Definition        |              |                    |
| .2 | -CCOPP |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | Verification of   | Rejection or | o.bypass           |
| .3 | _SOS.1 | Secrets           | acceptance   |                    |
| .3 | -CCOPP |                   | by the TSF   | o.due-care         |
|    |        |                   | of any       |                    |
|    |        |                   | tested       | o.comply           |
|    |        |                   | secret       |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | User              | All use of   | o.known            |
| .3 | _UAU.2 | Authentication    | the          |                    |
| .4 | -CCOPP | Before Any Action | au           |                    |
|    |        |                   | thentication |                    |
|    |        |                   | mechanism    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | Multiple          | None         | o.network          |
| .3 | _UAU.5 | authentication    |              |                    |
| .5 |        | mechanisms        |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | Re-authentication | All use of   | o.bypass           |
| .3 | _UAU.6 |                   | the          |                    |
| .6 |        |                   | au           |                    |
|    |        |                   | thentication |                    |
|    |        |                   | mechanism    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | Protected         | None         | o.bypass           |
| .3 | _UAU.7 | Authentication    |              |                    |
| .7 | -CCOPP | Feedback          |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | User              | All use of   | o.known            |
| .3 | _UID.2 | Identification    | the          |                    |
| .8 | -CCOPP | Before Any Action | au           |                    |
|    |        |                   | thentication |                    |
|    |        |                   | mechanism,   |                    |
|    |        |                   | including    |                    |
|    |        |                   | the identity |                    |
|    |        |                   | provided     |                    |
|    |        |                   | during       |                    |
|    |        |                   | *successful* |                    |
|    |        |                   | attempts.    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FIA    | User-Subject      | Success and  | o.access\          |
| .3 | _USB.1 | Binding           | failure of   | o.access-malicious |
| .9 | -CCOPP |                   | binding user |                    |
|    |        |                   | security     | o.due-care         |
|    |        |                   | attributes   |                    |
|    |        |                   | to a subject | o.bypass           |
|    |        |                   | (e.g.        |                    |
|    |        |                   | success and  |                    |
|    |        |                   | failure to   |                    |
|    |        |                   | create a     |                    |
|    |        |                   | subject).    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Management Of     | Success and  | o.manage           |
| .4 | FMT**\ | Security          | failure of   |                    |
| .1 | _MOF.1 | Functions         | management   | o.due-care         |
|    |        | Behavior          | behavior.    |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT    | Management Of     | All          | o.manage           |
| .4 | _MSA.1 | Security          | m            |                    |
| .2 | -CCOPP | Attributes        | odifications | o.due-care         |
|    |        | (Includes         | of the       |                    |
|    |        | Iteration)        | values of    | O.AUTHORIZATION    |
|    |        |                   | security     |                    |
|    |        |                   | attributes   |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_   | Static attribute  | M            | o.manage           |
| .4 | MSA.3- | initialization    | odifications |                    |
| .3 | CCOPP  |                   | of the       | o.due-care         |
|    |        |                   | default      |                    |
|    |        |                   | settings of  | O.AUTHORIZATION    |
|    |        |                   | permissive   |                    |
|    |        |                   | or           |                    |
|    |        |                   | restrictive  |                    |
|    |        |                   | rules. All   |                    |
|    |        |                   | m            |                    |
|    |        |                   | odifications |                    |
|    |        |                   | of the       |                    |
|    |        |                   | initial      |                    |
|    |        |                   | value of     |                    |
|    |        |                   | security     |                    |
|    |        |                   | attributes.  |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_MT | Management of     | All          | o.manage           |
| .4 | D.1-1- | Audit Trail       | m            |                    |
| .4 | CCOPP  |                   | odifications | o.due-care         |
|    |        |                   | to the       |                    |
|    |        |                   | values of    | O.AUTHORIZATION    |
|    |        |                   | the audit    |                    |
|    |        |                   | Trail.       |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_MT | Management of     | All          | o.manage           |
| .4 | D.1-2- | Audited Events    | m            |                    |
| .5 | CCOPP  |                   | odifications | o.due-care         |
|    |        |                   | to the       |                    |
|    |        |                   | values of    | O.AUTHORIZATION    |
|    |        |                   | the audited  |                    |
|    |        |                   | events..     |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_MT | Management of     | All          | o.manage           |
| .4 | D.1-3- | User Attributes   | m            |                    |
| .6 | CCOPP  |                   | odifications | o.due-care         |
|    |        |                   | to the       |                    |
|    |        |                   | values of    | O.AUTHORIZATION    |
|    |        |                   | the user     |                    |
|    |        |                   | attributes.  |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_MT | Management of     | All          | o.manage           |
| .4 | D.1-4- | Authentication    | m            |                    |
| .7 | CCOPP  | Data              | odifications | o.due-care         |
|    |        |                   | to the       |                    |
|    |        |                   | values of    | O.AUTHORIZATION    |
|    |        |                   | the          |                    |
|    |        |                   | au           |                    |
|    |        |                   | thentication |                    |
|    |        |                   | data         |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_RE | Revocation of     | All attempts | O.manage           |
| .4 | V.1-1- | User Attributes   | to revoke    |                    |
| .8 | CCOPP  |                   | user         | o.discretionary\_  |
|    |        |                   | attributes   |                    |
|    |        |                   |              | access             |
+----+--------+-------------------+--------------+--------------------+
| 5  | FMT_RE | Revocation of     | All attempts | O.manage           |
| .4 | V.1-2- | Object Attributes | to revoke    |                    |
| .9 | CCOPP  |                   | object       | o.discretionary\_  |
|    |        |                   | attributes   |                    |
|    |        |                   |              | access             |
+----+--------+-------------------+--------------+--------------------+
| 5. | FMT    | Time-Limited      | All attempts | o.access\          |
| 4. | _SAE.1 | Authorization     | to change    | o.access-malicious |
| 10 | -CCOPP |                   | limits       |                    |
|    |        |                   |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | O.AUTHORIZATION    |
|    |        |                   |              |                    |
|    |        |                   |              | o.manage           |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5. | FMT    | Specification of  | None         | o.manage           |
| 4. | _SMF.1 | management        |              |                    |
| 11 |        | functions         |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5. | FMT    | Security Roles    | Every use of | o.manage           |
| 4. | _SMR.2 |                   | the rights   |                    |
| 12 | -CCOPP |                   | of a role    | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Abstract Machine  | Execution of | Required           |
| .5 | FPT**\ | Testing           | the tests of | dependency for:    |
| .1 | _AMT.1 |                   | the          |                    |
|    | -CCOPP |                   | underlying   | FPT_TST.1          |
|    |        |                   | machine and  |                    |
|    |        |                   | the results  |                    |
|    |        |                   | of the       |                    |
|    |        |                   | tests.       |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Failure with      |              | o.recover          |
| .5 | _FLS.1 | preservation of   |              |                    |
| .2 | -CCOPP | secure state      |              | O.Recover-system   |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Inter-TSF         |              | o.network          |
| .5 | _ITC.1 | Confidentiality   |              |                    |
| .3 | -CCOPP | During            |              |                    |
|    |        | Transmission      |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Inter-TSF         |              | o.network          |
| .5 | _ITI.1 | detection of      |              |                    |
| .4 | -CCOPP | modification      |              |                    |
|    |        |                   |              |                    |
|    |        | (operations --    |              |                    |
|    |        | TBD)              |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Recovery from     |              | o.recover          |
| .5 | _RCV.2 | Failure           |              |                    |
| .5 | -CCOPP |                   |              | O.Recover-system   |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Function recovery |              | o.rECOVER_fUNCTION |
| .5 | _RCV.4 |                   |              |                    |
| .6 |        |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Non-Bypassability | None         | o.bypass           |
| .5 | _RVM.1 | of the TSP        |              |                    |
| .7 | -CCOPP |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | TSF Domain        | None         | o.bypass           |
| .5 | _SEP.1 | Separation        |              |                    |
| .8 | -CCOPP |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | FPT    | Reliable Time     | Changes to   | o.auditing         |
| .5 | _STM.1 | Stamps            | the time     |                    |
| .9 | -CCOPP |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5. | FPT    | TSF Testing       |              | o.detect\          |
| 5. | _TST.1 |                   |              | O.DETECT-SYSTEM    |
| 10 | -CCOPP |                   |              |                    |
|    |        |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Limited Priority  |              | o.resources        |
| .6 | FRU**\ | of Service        |              |                    |
| .1 | _PRS.1 |                   |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | FRU    | Maximum quotas    |              | o.resources        |
| .6 | _RSA.1 |                   |              |                    |
| .2 | -CCOPP | (operations --    |              |                    |
|    |        | TBD)              |              |                    |
+----+--------+-------------------+--------------+--------------------+
| 5  | **     | Limitation on     |              | o.access\          |
| .7 | FTA**\ | scope of          |              | o.access-malicious |
| .1 | _LSA.1 | selectable        |              |                    |
|    | -CCOPP | attributes        |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | FTA    | Basic limitation  |              | o.access\          |
| .7 | _MCS.1 | on multiple       |              | o.access-malicious |
| .2 | -CCOPP | concurrent        |              |                    |
|    |        | session           |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
+----+--------+-------------------+--------------+--------------------+
| 5  | FTA    | Default TOE       |              | o.entry            |
| .7 | _TAB.1 | access banners    |              |                    |
| .3 | -CCOPP |                   |              | o.ACCOUNTABILITY   |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FTA    | TOE access        |              | o.observe          |
| .7 | _TAH.1 | history           |              |                    |
| .4 |        |                   |              | o.entry            |
|    |        |                   |              |                    |
|    |        |                   |              | o.bypass           |
|    |        |                   |              |                    |
|    |        |                   |              | o.due-care         |
|    |        |                   |              |                    |
|    |        |                   |              | o.comply           |
+----+--------+-------------------+--------------+--------------------+
| 5  | FTA    | TOE session       |              | o.access\          |
| .7 | _TSE.1 | establishment     |              | o.access-malicious |
| .8 | -CCOPP |                   |              |                    |
|    |        |                   |              | o.entry            |
+----+--------+-------------------+--------------+--------------------+

## AUDIT (FAU) 

### FAU_GEN.1-CCOPP AUDIT DATA GENERATION

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the
auditable events listed in column "Auditable Event" of Table5- 1
(Functional Components -TOE). This includes all auditable events for the
basic level of audit, except FIA_UID.1's user identity during failures

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 compartment labels of subjects, objects, or information
involved; and

c\) The additional information specified in the "Auditable Events "
column of Table 5-1.

Dependencies: FPT_STM.1

**CCOPP Application Note:** For some situations it is possible that some
events cannot be automatically generated. This is usually due to the
audit functions not being operational at the time these events occur.
Such events need to be documented in the Administrative Guidance, along
with recommendation on how manual auditing should be established to
cover these events.

### FAU_GEN.2-CCOPP User identity generation 

Dependencies: FAU_GEN.1-CCOPP, FIA_UID.1

**FAU_GEN.2.1**-CCOPP For audit events resulting from actions of
identified users, the TSF shall be able to associate each auditable
event with the individual identity of the user [or system
process]{.underline} that caused the event.

**Refinement:** See text of FAU_GEN.2.1-CCOPP

### FAU_SAR.1 Audit review

Dependencies: FAU_GEN.1-CCOPP

FAU_SAR.1.1 The TSF shall provide authorized administrators with the
capability to read all audit information from the audit records:

FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable
for the user to interpret the information.

**CCOPP Application Note:** The minimum information which must be
provided is the same that which is required to be recorded in 5.1.1. The
intent of this requirement is that there exist tools for administrators
to be able to access the audit trail in order to assess it. Exactly what
manner is provided is an implementation decision, but it needs to be
done in a way which allows the administrator to make effective use of
the information presented. This requirement is closely tied to 5.1.5 and
5.1.6. It is expected that a single tool will exist within the TSF which
will satisfy all of these requirements.

### FAU_SAR.2 Restricted audit review

Dependencies: FAU_SAR.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.

**CCOPP Application Note**: By default, authorized administrators may be
considered to have been granted read access to the audit records. The
TSF may provide a mechanism which allows other users to also read audit
records.

### FAU_SAR.3 Selectable audit review

Dependencies: FAU_SAR.1

FAU_SAR.3.1 The TSF shall provide the ability to perform \[selection:
searches, sorting\] of audit data based on the following attributes:

> a\) User identity;
>
> b\) Subject compartment label;
>
> c\) Object compartment label;
>
> d\) \[assignment: list of additional attributes that audit selectivity
> is based upon\]

**CCOPP 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.

**Refinement:** See text of FAU_SAR.3.1

### FAU_SEL.1-CCOPP Selective audit

Dependencies: FAU_GEN.1-CCOPP

FMT_MTD.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\) User identity;
>
> b\) Subject compartment label;
>
> c\) Object compartment label;
>
> d\) \[assignment: list of additional attributes that audit selectivity
> is based upon\].

**CCOPP 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.

### FAU_STG.1-CCOPP Protected audit trail storage 

Dependencies: FAU_GEN.1-CCOPP

FAU_STG.1.1-CCOPP: The TSF shall protect the stored audit records in the
audit trail from unauthorized deletion.

FAU_STG.1.2-CCOPP: The TSF shall be able to \[**selection:** prevent
[and]{.underline} detect\] unauthorized modifications to the audit
records in the audit trail.

**Refinement:** See text in FAU_STG.1.2-CCOPP

**CCOPP Application Note:** On many systems, in order 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 possible that some of these records will be lost if the
operation of the TOE is interrupted by hardware or power failures.

### FAU_STG.3-CCOPP Action in case of possible audit data loss

Dependencies: FAU_STG.1-CCOPP

FAU_STG.3.1 The TSF shall take \[**assignment:** the action to notify an
identified user or console of the possible audit data loss\] if the
audit trail exceeds \[**assignment:** an authorized user selectable,
pre-defined limit\].

**CCOPP 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 75% full). If the
limit is adjustable by the authorized administrator, the ST should also
incorporate an FMT requirement to manage this function.

### FAU_STG.4-CCOPP Prevention of audit data loss

Hierarchical to: FAU_STG.3

**FAU_STG.4.1** The TSF shall be able to prevent auditable events,
except those taken by the authorized administrator, and \[assignment:
other actions to be taken in case of audit storage failure\] if the
audit trail is full.

Dependencies: FAU_STG.1-CCOPP

**CCOPP 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.

## User Data Protection (fdp) 

### FDP_ACC.1-CCOPP Subset access control

Dependencies: FDP_ACF.1-CCOPP

FDP_ACC.1.1: The TSF shall enforce the Discretionary Access Control
Policy on \[assignment: list of subjects\] acting on the behalf of
users, \[assignment: list of named objects\] and all operations among
subjects and objects covered by the DAC policy.

**CCOPP Application Note:** For most systems there is only one type of
subject, usually called a process or task, which needs to be specified
in the ST.

Named objects are those objects which are 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 needs to specify which type of access right is needed to
perform the operation; for example read access or write access.

### FDP_ACF.1-CCOPP Security attribute based access control

Dependencies: FDP_ACC.1, FMT_MSA.3-CCOPP

FDP_ACF.1.1-The TSF shall enforce the [Discretionary Access Control
Policy]{.underline} to objects based on [the following]{.underline}:

> a\) [The user identity and group membership(s) associated with a
> subject; and]{.underline}
>
> b\) [The following access control attributes associated with an
> object:]{.underline}
>
> [\[assignment: List access control attributes. The attributes must
> provide permission attributes with:]{.underline}
>
> i\) the ability to associate allowed or denied operations with one or
> more user identities;
>
> ii\) the ability to associate allowed or denied operations with one or
> more group identities; and
>
> iii\) defaults for allowed or denied operations.\]

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 Discretionary Access Control
policy, where:

> i\) 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;
>
> ii\) For each operation there shall be a rule, or rules, that use the
> permission attributes where the group membership of the subject
> matches a group identity specified in the access control attributes of
> the object; and
>
> iii\) For each operation there shall be a rule, or rules, that use the
> default permission attributes specified in the access control
> attributes of the object when neither a user identity or group
> identity matches.\]

FDP_ACF.1.3: The TSF shall explicitly authorize access of subjects to
objects based in the following additional rules: \[assignment: rules,
based on security attributes, that explicitly authorize access of
subjects to objects\].

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\].

**CCOPP Application Note:** A CCOPP conformant TOE is required to
implement a DAC policy, but the rules which govern the policy may vary
between TOEs; 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 which 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 DAC policy may cover rules on accessing public objects; i.e., objects
which are readable to all authorized users, but which can only be
altered by the TSF or authorized administrators.

A DAC policy may include exceptions to the basic policy for access by
authorized administrators or other forms of special authorization.

The ST must list the attributes which are used by the DAC 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.

### FDP_ETC.1-CCOPP Export of user data without security attributes

Dependencies: FDP_ACC.1 or- FDP_IFC.1

FDP_ETC.1.1: The TSF shall enforce the [Mandatory Access Control
Policy]{.underline} when exporting

*unlabeled* user data, controlled under the *MAC policy*, outside the
TSC.

FDP_ETC.1.2: The TSF shall export the *unlabeled* user data without the
user data's associated security attributes.

FDP_ETC.1.3 The TSF shall enforce the following rules when *unlabeled
user* data is exported from the TSC:

> a\) Devices used export data without security attributes cannot be
> used to export data with security attributes unless the change in
> device state is performed manually and is auditable;
>
> b\) \[assignment: additional exportation control rules\].

**CCOPP Application Note:** A CCOPP-conformant TOE 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, itself, 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.

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.

Single-level Input/Output devices and single-level communication
channels are not required to maintain the compartment labels of the
information they process.

### FDP_IFC.2-CCOPP Complete information flow control 

Hierarchical to: FDP_IFC.1

**FDP_IFC.2.1-CCOPP** The TSF shall enforce the [Mandatory Access
Control Policy]{.underline} on \[[assignment: subjects\], \[assignment:
objects]{.underline}\], [and all operations among subjects and objects
covered by the MAC policy.]{.underline}

**CCOPP Application Note:** For most systems there is only one type of
subject, usually called a process or task, which needs to be specified
in the ST.

Named objects are those objects which are 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 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.

**FDP_IFC.2.2** The TSF shall ensure that all operations that cause any
information in the TSC to flow to and from any subject in the TSC are
covered by an information flow control SFP.

Dependencies: **FDP_IFF.1 Simple security attributes**

### FDP_IFF.1-CCOPP Simple security attributes 

**FDP_IFF.1.1** The TSF shall enforce the \[assignment: *[Mandatory
Access Control Policy]{.underline}*\] based on the following types of
subject and information security attributes:

\[assignment:

*a) The compartmental label of the subject; and*

*b) The compartmental label of the object containing the information.*

The compartmental label of the subject shall be a single
non-hierarchical category. The label-based restriction of the object
shall be an access rule that dictates how subjects in each compartment
may access the object.

**CCOPP Application Note**: A CCOPP-conformant system may allow a
subject to have multiple labels simultaneously.

**FDP_IFF.1.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: The access rules of the object
include the pair (compartment-of-the-subject, the-access-mode).\]

**FDP_IFF.1.3** The TSF shall enforce the \[assignment: *additional
information flow control SFP rules*\].

**FDP_IFF.1.4** The TSF shall provide the following \[assignment: *list
of additional SFP capabilities*\]

**FDP_IFF.1.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*\].

**FDP_IFF.1.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*\].

Dependencies:

> FDP_IFC.1 Subset information flow control
>
> FMT_MSA.3 Static attribute initialisation

### FDP_ITC.1-CCOPP Import of user data without security attributes

Dependencies: FDP_ACC.1 or/and FDP_IFC.1, FMT_MSA.3-CCOPP

FDP_ITC.1.1: The TSF shall enforce the \[**assignment:** *[Mandatory
Access Control Policy]{.underline}*\] when importing user data,
controlled under the *MAC policy*, from outside the TSC.

FDP_ITC.1.2: The TSF shall ignore the security attributes associated
with the *unlabeled* user data when imported from outside the TSC.

FDP_ITC.1.3 The TSF shall enforce the following rules when importing
*unlabeled* user data controlled under the *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\) \[assignment: additional importation control rules\].

**CCOPP Application Note:** The CCOPP-conformant TOE 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 compartment 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; and 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.

### FDP_RIP.2-1-CCOPP Object residual information protection

Hierarchical to: **FDP_RIP.1**

**FDP_RIP.2.1** The TSF shall ensure that any previous information
content of a resource is made unavailable upon the [allocation of the
resource]{.underline} to all objects.

Dependencies: No dependencies

**CCOPP 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.

### FDP_RIP.2-2-CCOPP Subject residual information protection

Hierarchical to: **FDP_RIP.1**

**FDP_RIP.2.1** The TSF shall ensure that any previous information
content of a resource is made

unavailable upon the [allocation of the resource]{.underline} to all
subjects.

Dependencies: No dependencies

**CCOPP 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

###  FDP_UCT.1-CCOPP Basic data exchange confidentiality

Dependencies: FTP_ITC.1-CCOPP or FTP_TRP.1-CCOPP, FDP_ACC.1

FDP_UCT.1.1: The TSF shall [support the enforcement of]{.underline} the
\[**assignment:** CCOPP access control SFP\] to be able to
\[**selection:** transmit and receive\] objects in a manner protected
from unauthorized disclosure.

**Refinement:** See text in FDP_UCT.1.1

### FDP_UIT.1-CCOPP Data exchange integrity

Dependencies: FTP_ITC.1-CCOPP or FTP_TRP.1-CCOPP, FDP_ACC.1

FDP_UIT.1.1: The TSF shall [support the enforcement of]{.underline} the
\[**assignment:** CCOPP access control SFP\] to be able to
\[**selection:** transmit [and]{.underline} receive\] user data in a
manner protected from \[**selection:** modification, deletion,
insertion, [and]{.underline} replay\] errors.

FDP_UIT.1.2: The TSF shall be able to determine on receipt of user data,
whether \[**selection:** modification, deletion, insertion,
[or]{.underline} replay\] has occurred.

**Refinement:** See text in FDP_UIT.1.1 and FDP_UIT.1.2

## Identification and Authentication (FIA)

### FIA_AFL.1-CCOPP Authentication failure handling

Dependencies: FIA_UAU.1

FIA_AFL.1.1 The TSF shall detect when \[selection: \[assignment:
positive integer number\], "an administrator configurable positive
integer within \[assignment: range of ***[acceptable
values\]"\]]{.underline}* unsuccessful authentication attempts occur
related to \[assignment: *list of authentication events*\].**

FIA_AFL.1.2 When **the defined number of unsuccessful authentication
attempts has been met or surpassed, the TSF shall \[assignment: *list of
actions*\].**

### FIA_ATD.1-CCOPP User attribute definition

Dependencies: None

FIA_ATD.1.1 The TSF shall maintain the following list of security
attributes belonging to individual users: \[**assignment:**

> a\) [User Identifier;]{.underline}
>
> [b) Group Memberships;]{.underline}
>
> [c) Authentication Data;]{.underline}
>
> [d Security-relevant Roles; and]{.underline}
>
> [e) \[assignment: other user security attributes]{.underline}\].

**CCOPP Application Note:** The specified attributes are those that are
required by the TSF to enforce the DAC policy, the generation of audit
records, and proper identification and authentication of users. The user
identity must be uniquely associated with a single individual 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 which
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.

### FIA_SOS.1-CCOPP Verification of secrets

Dependencies: None

FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets
meet the following:

a\) For each attempt to use the authentication mechanism, the
probability that a random attempt will succeed is less than one in
1,000,000;

b\) For multiple attempts to use the authentication mechanism during a
one minute period, the probability that a random attempt during that
minute will succeed is less than one in 100,000; and

c\) Any feedback given during an attempt to use the authentication
mechanism will not reduce the probability below the above metrics.

**CCOPP Application Note:** The method of authentication is unspecified
by the CCOPP, but must be specified in a ST. The method which is used
must be shown to have low probability that authentication data can be
forged or guessed. For example, if a password mechanism is used a set of
metrics needs to be specified and may include such things as minimum
length of the password, maximum lifetime of a password, and the
subjecting of possible passwords to dictionary attacks. The strength of
whatever mechanism implemented must be subjected to a trength of
function analysis.

**CCOPP Application note:** Elements for security quality metric related
to passwords include:

a.  Passwords shall not be reusable by the same user identifier for a
    period of time that can be set by an authorized user.

b.  The TSF shall not indicate to the user if he/she has chosen a
    password already associated with another user.

c.  The TSF shall, by default, prohibit the use of null passwords during
    normal operation.

d.  The TSF shall provide an algorithm for ensuring the complexity of
    user-entered passwords that meets the following requirements:

    i.  Passwords shall meet an authorized user specifiable minimum
        length requirement. The default minimum length shall be eight
        characters.

    ii. The password complexity-checking algorithm shall be modifiable
        by the TSF. The default algorithm shall require passwords to
        include at least one alphabetic character, one numeric
        character, and one special character.

    iii. The TSF should provide a protected mechanism that allows
         systems to specify a list of excluded passwords (e.g., company
         acronyms, common surnames).

    iv. The TSF should prevent users from selecting a password that
        matches any of those on the list of excluded passwords.

### FIA_UAU.2-CCOPP User authentication before any action

Dependencies: FIA_UID.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.

**CCOPP Application Note:** This is hierarchical to FIA_UAU.1-CCOPP, and
is more restrictive, so accomplishes the requirements of CCOPP.

### FIA_UAU.5-CCOPP Multiple authentication mechanisms

Dependencies: None

FIA_UAU.5.1 The TSF shall provide [support for]{.underline}
\[**assignment:** the required use of authentication mechanisms other
than only passwords, based upon access parameters such as time of day,
port of entry, and user privilege\] to support user authentication.

FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity
according to the \[**assignment:** parameters for selecting
authenticators required, these parameters are to be specifiable by an
explicitly specified set of users, enforcing least privilege on the
basis of the following ST selection: *\[**ST selection:** explicitly
authorized security administrators, security administrator roles,
both\]*\]. [The ST rationale shall provide a basic justification for the
selection made, indicating how it supports enforcement of least
privilege.]{.underline}

**Refinement:** See text in FIA_UAU.5.1 and FIA_UAU.5.2

### FIA_UAU.6-CCOPP Re-authentication

Dependencies: None

FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions
\[**assignment:** re-establishing a session following session locking,
request to change authentication secrets, and the following ST supplied
conditions specific to the ST design: *\[**ST assignment:** as required
by PP, list of other, ST specific conditions under which
re-authentication is required\]*\]. [The ST rationale shall provide a
basic justification for the assignment made, including a "null" list,
showing why it is complete.]{.underline}

**Refinement:** See text in FIA_UAU.6.1

### FIA_UAU.7-CCOPP Protected authentication feedback

Dependencies: FIA_UAU.1

FIA_UAU.7.1 The TSF shall provide only obscured feedback to the user
while the authentication is in progress.

**CCOPP 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., 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 Administrator and User Guidance
documentation for the product must explain the risks in placing
passwords on such input and must suggest procedures to mitigate that
risk.

### FIA_UID.2-CCOPP User identification before any action

Dependencies: None

FIA_UID.2.1 The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on behalf of
that user.

**CCOPP Application Note:** This is hierarchical to FIA_UID.1-CCOPP, and
is more restrictive, so accomplishes the requirements of CCOPP.

### FIA_USB.1-1- User-subject binding

Dependencies: FIA_ATD.1

The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user:

> The user identity which is associated with auditable events,
>
> The user identity or identities which are used to enforce the
> Discretionary Access Control Policy;
>
> The group membership or memberships used to enforce the Discretionary
> Access Control Policy, and
>
> The current working directory

**FIA_USB.1-2- User-subject binding**

The TSF shall enforce the following rules on the initial association of
user security attributes with subjects acting on the behalf of a user:

> The user identity which is associated with auditable events is set to
> the user's Audit Identity;
>
> The user identity or identities which are used to enforce the
> Discretionary Access Control Policy are set to the User Identifier;
>
> The real and effective group identities used to enforce the
> Discretionary Access Control Policy are set to the user's primary
> Group Membership;
>
> The group access list used to enforce the Discretionary Access Control
> Policy are set to the user's supplementary Group Memberships;
>
> The current working directory is set to the user's home directory.

**FIA_USB.1-3- User-subject binding**

The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of a
user:

> An authorized administrator acting as super user (with an effective
> user identity equal to zero) shall be able to change the user
> identities and group memberships of a subject acting on his behalf to
> that of another valid user (the *su()* command);
>
> A subject's effective user identity is changed to the owner of a file
> executed with its set-user-identity permission bit enabled;
>
> A subject's effective group identity is changed to the owning group of
> a file executed with its set-group-identity permission bit enabled.

## Security management (fmt)

### FMT_MOF.1 Management of security functions behavior

Dependencies:

**FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

Hierarchical to: No other components.

**FMT_MOF.1.1** The 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: *the
authorized identified **roles*****\].**

### FMT_MSA.1-1- CCOPP Management of security attributes

Dependencies**: FDP_ACC.1 or FDP_IFC.1,**

**FMT_SMR.1**

FMT_MSA.1.1 The TSF shall enforce the [Discretionary Access Control
Policy]{.underline} to restrict the ability to [modify]{.underline} the
[access control attributes associated with a named object]{.underline}
to \[assignment:

the authorized users\].

### FMT_MSA.1-2- CCOPP Management of security attributes

Dependencies: **FDP_ACC.1 or FDP_IFC.1,**

**FMT_SMR.1**

FMT_MSA.1.2 The TSF shall enforce the [Mandatory Access Control
Policy]{.underline} to restrict the ability to [modify]{.underline} the
[compartment label associated with an object]{.underline} to
\[assignment: the authorized identified roles\].

**CCOPP Application Note**: The ST must state the components of the
access rights that may be modified, and must state any restrictions that
may exist for a type of authorized user and the components of the access
rights that the user is allowed to modify.

The ability to modify access rights must be restricted in that a user
having access rights to a named object does not have the ability to
modify those access 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 rules.

### FMT_MSA.3-CCOPP Static attribute initialization

Dependencies: - **FMT_MSA.1,**

**FMT_SMR.1**

FMT_MSA.3.1: The TSF shall enforce the [Discretionary Access Control
Policy]{.underline} to provide [restrictive]{.underline} default values
for security attributes that are used to enforce the [Discretionary
Access Control Policy.]{.underline}

FMT_MSA.3.2 The TSF shall enforce the [Mandatory Access Control
Policy]{.underline} to provide [restrictive]{.underline} default values
for security attributes that are used to enforce the [Mandatory
Access]{.underline}

[Control Policy.]{.underline}

FMT_MSA.3.3 The TSF shall allow the \[assignment: authorized identified
roles\] to specify alternative initial values to override the default
values when an object or information is created.

**CCOPP Application Note:** A CCOPP-conformant TOE 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.

### FMT_MTD.1-1-CCOPP Management of Audit Trail

Dependencies: **FMT_SMR.1**

FMT_MTD.1.1 The TSF shall restrict the ability to [create, delete, and
clear]{.underline} [the audit trail]{.underline} to [authorized
administrators]{.underline}.

**Refinement:** See text in FMT_MTD.1.1

**CCOPP Application Note:** The selection of "[create, delete, and
clear]{.underline}" 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.

### FMT_MTD.1-2-CCOPP Management of Audited Events

FMT_MTD.1.1 The TSF shall restrict the ability to modify or observe the
set of audited events to authorized administrators.

**CCOPP Application Note**: The set of audited events are the subset of
auditable events which 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 not be able to affect
which of their actions are audited, and therefore must not have control
over or knowledge of the selection of an event for auditing.

### FMT_MTD.1-3-CCOPP Management of User Attributes

FMT_MTD.1.1 The TSF shall restrict the ability to [initialize and
modify]{.underline} the [user security attributes, other than
authentication data]{.underline}, to [authorized
administrators]{.underline}.

**CCOPP Application Note:** This component only applies to security
attributes which are used to maintain the TSP. Other user attributes may
be specified in the ST, but control of those attributes are not within
the scope of the CCOPP.

### FMT_MTD.1-4-CCOPP Management of Authentication Data

FMT_MTD.1.1 The TSF shall restrict the ability to
[initialize]{.underline} the [authentication data]{.underline} to
[authorized administrators]{.underline}.

FMT_MTD.1.2 The TSF shall restrict the ability to [modify]{.underline}
the [authentication data]{.underline} to [the following:]{.underline}

> a\) authorized administrators; and
>
> b\) users authorized to modify their own authentication data

**CCOPP 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
makes use of the user authentication data to verify a user's identity.

This component does not require that any user be authorized to modify
their own authentication information; it only states that it is
permissible.

### FMT_REV.1-1-CCOPP Revocation of User Attributes

Hierarchical to: No other components.

FMT_REV.1.1 The TSF shall restrict the ability to revoke security
attributes associated with the [users]{.underline} within the TSC to
[authorized administrators]{.underline}.

FMT_REV.1.2 The TSF shall enforce the rules \[assignment

> a[) The immediate revocation of security-relevant authorizations;
> and]{.underline}
>
> [b) \[assignment: list of other revocation rules concerning
> users\].]{.underline}

**CCOPP Application Note:** Many security-relevant authorizations could
have serious consequences if misused, so a n immediate revocation method
must exist, although it need not be the usual method (e.g., The usual
method may be editing the trusted user's 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 user's profile and
"force" the trusted user to log off.). The immediate method must be
specified in the ST and in administrator guidance. In a distributed
environment the developer must provide a description of how the
"immediate" aspect of this requirement is met.

**Dependencies**: FMT_SMR.1 Security roles

### FMT_REV.1-2-CCOPP Revocation of Object Attributes

FMT_REV.1.1 The TSF shall restrict the ability to revoke security
attributes associated with [objects]{.underline} within the TSC to
[users authorized to modify the security attributes by the Discretionary
Access Control or Mandatory Access Control policies.]{.underline}

FMT_REV.1.2 The TSF shall enforce the rules:

> [a) The access rights associated with an object shall be enforced when
> an access check is made;]{.underline}
>
> [b) The rules of the Mandatory Access Control policy are enforced on
> all future operations; and]{.underline}
>
> [c) \[assignment: list of other revocation rules concerning
> objects\].]{.underline}

**CCOPP 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.

### FMT_SAE.1-CCOPP Time-limited authorization

Dependencies: FMT_SMR.1, FMT_STM.1

FMT_SAE.1.1 The TSF shall restrict the ability to specify an expiration
time for \[**assignment:** user account and authenticators and *\[**ST
assignment:** as required by PP, list of ST specific security attributes
for which expiration is to be supported\]*\] to \[**assignment:** an
explicitly specified set of users, enforcing least privilege on the
basis of the following ST selection: *\[**ST selection:** security
administrators, security administrator roles, both\]*\].

FMT_SAE.1.2 For each of these security attributes, TSF shall be able to
\[**assignment:** for user account - disable account and require
administrator action to re-enable, for authenticators - require owner of
authenticator to establish a new value before proceeding with
authenticated action\] and *\[**ST assignment:** as required by PP, list
of ST specific actions to be taken for each ST specific security
attribute\]* after the expiration time for the indicated security
attribute has passed.

**CCOPP Application Note:** The ST rationale shall provide a basic
justification for the assignment made, to include a "null" assignment,
showing that it is a complete list with respect to the attributes which
must be restricted to enforce secure operation.

The ST rationale shall also provide a basic justification for the
selection made in 1.1, indicating how it enforces least privilege.

The ST rationale shall provide a basic justification for the assignment
made in 1.2, to include "null", showing that it is sufficient to enable
secure operation.

**Refinement:** See text in FMT_SAE.1.1 and FMT_SAE.1.2

### FMT_SMF.1 Specification of management functions

Hierarchical to: No other components

FMT_SMF.1 The TSF shall be capable of performing the following security
management functions: \[assignment: *list of security management
functions to be provided by the TSF*\].

Dependencies: No Dependencies

### FMT_SMR.2-CCOPP Security roles 

Dependencies: FIA_UID.1

FMT_SMR.2.1 The TSF shall maintain the roles \[**assignment:**

> a[) authorized administrator;]{.underline}
>
> [b) users authorized by the Discretionary Access Control Policy to
> modify object security attributes;]{.underline}
>
> [c) users authorized by the Mandatory Access Control Policy to modify
> object security attributes;]{.underline}
>
> [d) users authorized to modify their own authentication data;
> and]{.underline}
>
> [e) \[assignment: other roles\]]{.underline}

FMT_SMR.2.2 The TSF shall be able to associate users with roles.

FMT_SMR.2.3 The TSF shall ensure that the conditions \[assignment:
*conditions for the different roles*\] are satisfied.

**Refinement:** See text in FMT_SMR.2.1

**CCOPP Application Note**: A CCOPP-conformant TOE only needs to support
a single administrative role, referred to as the authorized
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.

The CCOPP specifies a number of functions which are required of or
restricted to an authorized administrator, but there may be additional
functions which are specific to the TOE. This would include any
additional function which 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, ability to run real-time programs, and the
overriding of compartment labels on printed output.

## Protection of TOE Security (FPT)

### FPT_AMT.1-CCOPP Abstract machine testing

Dependencies: None

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.

**Refinement**: See text in FPT_AMT.1.1

**CCOPP 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, 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.

### FPT_FLS.1-CCOPP Failure with preservation of secure state

Dependencies: ADV_SPM.1

FPT_FLS.1.1 The TSF shall preserve a secure state when the following
types of failures occur: \[**assignment:** those indicated in the
following ST assignment: *\[**ST assignment:** list of TSF failures for
which the ST is able to preserve a secure state\]*\].

**CCOPP Application Note:** As the purpose of this requirement is to
make the list of recoverable failures explicit, not to mandate specific
failures, the ST rationale does not need to show completeness. However,
the ST rationale does need to provide a basic justification for the
claim that the ST will preserve a secure state for each failure type
listed.

**Refinement:** See text in FPT_FLS.1.1

### FPT_ITC.1-CCOPP Inter-TSF confidentiality during transmission

Dependencies: None

FPT_ITC.1.1-CCOPP The TSF shall [support the protection of]{.underline}
\[**extension:** authentication information\] transmitted from the TSF
to a remote trusted IT product from unauthorized disclosure during
transmission.

**Refinement:** See text of FPT_ITC.1.1-CCOPP

**Extension:** See text of FPT_ITC.1.1-CCOPP

### FPT_ITI.1-CCOPP Inter-TSF detection of modification

Dependencies: None

FPT_ITI.1.1-CCOPP The TSF shall [support]{.underline} the capability to
detect modification of \[**extension:** security state information that
is critical to maintaining a secure state among distributed systems as
identified in *\[**ST assignment:** list of TSF data requiring such
protection\]*\] data during transmission between TSF and a remote
trusted IT product within the following metric: *\[**ST assignment**: a
defined modification metric or metrics\]*. \[**extension:** The first ST
assignment may be a 'null' list if the ST rationale shows that meeting
FPT_ITI.1.2 is sufficient to maintain secure operation.\]

**CCOPP Application Note:** The ST rationale shall provide a basic
justification, showing that the first ST assignment is complete and that
the metric, or metrics, called out in the second assignment are
sufficient. It is acceptable to protect all data, rather than selecting
specific data elements.

FPT_ITI.1.2-CCOPP The TSF shall [support]{.underline} the capability to
verify the integrity of \[***extension:*** security state information
that is critical to maintaining a secure state among distributed systems
as identified in *\[**ST assignment:** list of TSF data requiring such
protection\]*\] transmitted between the TSF and a remote trusted IT
product and perform \[**assignment:** automatic retransmission of data
lacking integrity, with the capability to audit this action in a
statistical manner\] if modifications are detected.

**CCOPP Application Note:** The ST rationale shall provide a basic
justification, showing that the ST assignment is complete. It is
acceptable to protect all data, rather than selecting specific data
elements.

**Refinement:** See text in FPT_ITI.1.1-CCOPP and FPT_ITI.1.2-CCOPP

**Extension:** See text in FPT_ITI.1.1-CCOPP and FPT_ITI.1.2-CCOPP

### FPT_RCV.2-CCOPP Recovery from Failure

Dependencies: ADV_SPM.1, AGD_ADM.1, FPT_TST.1

FPT_RCV.2.1-CCOPP For \[**assignment:** those failures indicated in the
following ST assignment: *\[**ST assignment:** as required by PP, list
of ST specific types of TSF failures\]*\], the TSF shall ensure the
return of the TOE to a secure state using automated procedures.

**CCOPP Application Note:** As the purpose here is to ensure that the
choice is made explicit, the ST rationale does not need to justify
completeness, but does need to provide a basic justification for the
claim that the ST will automatically recover from the failure types
listed.

FPT_RCV.2.2-CCOPP 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.

**Refinement:** See text in FPT_RCV.2.1-CCOPP

### FPT_RCV.4 Function recovery

**Hierarchical to:** No other components.

FPT_RCV.4.1 The TSF shall ensure that \[assignment: *list of SFs and
failure scenarios*\] have the property that the SF either completes
successfully, or for the indicated failure scenarios, recovers to a
consistent and secure state.

**Dependencies:**

ADV_SPM.1 Informal TOE security policy model

### FPT_RVM.1-CCOPP Non-bypassability of the TSP

Dependencies: None

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.

**Refinement:** See text in FPT_RVM.1.1

**CCOPP Application Note:** This element does not imply that there must
be a reference monitor. Rather this requires that the TSF validates all
actions between subjects and objects that require policy enforcement.

### FPT_SEP.1-CCOPP TSF domain separation

Dependencies: None

FPT_SEP.1.1 The TSF shall maintain a security domain for its own
execution that protects it from interference and tampering by untrusted
subjects.

FPT_SEP.1.2 The TSF shall enforce separation between the security
domains of subjects in the TSC.

**Refinement:** See text in FPT_SEP.1.1

**CCOPP 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
CPU's which 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, separate hardware components,
or entirely in software. The latter is likely in layered application
such as a graphic user interface system which maintains separate
subjects.

### FPT_STM.1-CCOPP Reliable Time Stamps

FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for
its own use.

**CCOPP Application Note**: The generation of audit records depends on
having a correct date and time. The ST needs to specify the degree of
accuracy that must be maintained in order to maintain useful information
for audit records.

### FPT_TST.1-CCOPP TSF testing

Dependencies: FPT_AMT.1

FPT_TST.1.1 The TSF shall run a suite of self tests \[**selection:**
during initial start-up [and]{.underline} at the request of [explicitly
authorized security administrator(s) or security administrator
role(s)]{.underline}\] \[**assignment:** "null"\] to demonstrate the
correct operation of the TSF.

FPT_TST.1.2 The TSF shall provide authorized users with the capability
to verify the integrity of TSF data.

FPT_TST.1.3 The TSF shall provide authorized users with the capability
to verify the integrity of stored TSF executable code.

**Refinement:** See text in FPT_TST.1.1

## Resource utilization (fru)

### FRU_PRS.1 Limited priority of service

**Hierarchical to:** No other components.

FRU_PRS.1.1 The TSF shall assign a priority to each subject in the TSF.

FRU_PRS.1.2 The TSF shall ensure that each access to \[assignment:
*controlled resources*\] shall be mediated on the basis of the subject's
assigned priority.

**Dependencies**: No dependencies

### FRU_RSA.1-CCOPP Maximum quotas

Dependencies: None

FRU_RSA.1.1-CCOPP The TSF shall enforce maximum quotas of the following
resources: \[**assignment:** all OS-controlled, multi-user or
multi-process resources such as memory, disk space, and inter-processor
communications paths\] that *\[**ST selection:** an individual user, a
defined group of users, subjects\]* can use *\[**ST selection:**
simultaneously, over a specified period of time\]*.

**CCOPP Application Note**: The ST rationale must show that the list of
resources for which maximum quotas is enforced is sufficiently complete
to accomplish protection against resource exhaustion, to the extent that
the OS is capable of doing so. Also the ST rationale must give, for both
ST selections, the reasoning for the choices made and stating why the
choices support the goal of protecting against denial-of-service.

**Refinement:** See text in FRU_RSA.1.1-CCOPP

## TOE Access (FTA) 

### FTA_LSA.1-CCOPP Limitation on scope of selectable attributes

Dependencies: None

FTA_LSA.1.1 The TSF shall [provide the capability to]{.underline}
restrict the scope of [these]{.underline} session security
attributes[:]{.underline} \[**assignment:** user role, specific user
capabilities, and any *\[**ST assignment:** ST specific session security
attributes\]*\], based on \[**assignment:** user identity, point of
entry, time of day, day of week, and any *\[**ST assignment:**
attributes specific to the ST design\]*\].

**CCOPP Application Note**: The ST rationale shall provide a basic
justification, showing that the ST specific assignments are sufficient
to restrict the security critical attributes.

**Refinement:** See text in FTA_LSA.1.1

### FTA_MCS.1-CCOPP Basic limitation on multiple concurrent sessions

Dependencies: FIA_UID.1

FTA_MCS.1.1-CCOPP The TSF shall \[**extension:** enable an authorized
user to specify whether or not to\] restrict the maximum number of
concurrent sessions that belong to the same user.

FTA_MCS.1.2 [If the TOE is to restrict the maximum number of concurrent
sessions]{.underline}, the TSF shall enforce \[**assignment:** an
authorized user selected maximum number of\] sessions per user.

**Refinement:** See text in FTA_MCS.1.2

**Extension:** See text in FTA_MCS.1.1-CCOPP

### FTA_TAB.1-CCOPP Default TOE access banners

Dependencies: None

FTA_TAB.1.1 Before establishing a user session, the TSF shall display an
advisory warning message regarding unauthorized use of the TOE.

**Extension**:

> FTA_TAB.1-CCOPP.2 The TSF shall provide the capability for an
> authorized user to specify and subsequently modify the contents of
> this warning message.

### FTA_TAH.1 TOE access history

Dependencies: None

FTA_TAH.1.1 Upon successful session establishment, the TSF shall display
the \[**selection:** date, time, method, location\] of the last
successful session establishment to the user.

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.

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.

**Refinement:** See text in FTA_TAH.1.1 and FTA_TAH.1.2

### FTA_TSE.1-CCOPP TOE session establishment

Dependencies: None

FTA_TSE.1.1 The TSF shall be able to deny session establishment based on
*the default active role set for the user being empty*.

##  functional requirements - IT Environment

This section describes what is known about the functional requirements
that the IT in the environment surrounding the TOE must provide in order
for the environmental and joint security objectives to be met. For an
operating system this equates to requirements placed upon the underlying
hardware/firmware platform.

[]{#__RefHeading___Toc102926563 .anchor}Table 5-2 -- Functional
Components - IT Environment

+-----+------------+------------------------------+--------------------+
| >   | CC         | Name                         | > Objectives       |
| SFR | Component  |                              | > function helps   |
| >   |            |                              | > address          |
| Num |            |                              |                    |
| ber |            |                              |                    |
+=====+============+==============================+====================+
| 5.  | FAU_S      | Protected audit trail        | o.detect-system    |
| 1.7 | TG.1-CCOPP | storage                      |                    |
|     |            |                              | o.due-care         |
|     |            |                              |                    |
|     |            |                              | o.comply           |
|     |            |                              |                    |
|     |            |                              | o.ACCO             |
|     |            |                              | UNTABILITY-non-TOE |
|     |            |                              |                    |
|     |            |                              | o.bypass-non-TOE   |
+-----+------------+------------------------------+--------------------+
| 5.  | FDP_ACC.1  | Subset Access Control        | o.access-non-toe   |
| 2.1 |            |                              |                    |
|     |            |                              | o.entry-non-toe    |
|     |            |                              |                    |
|     |            |                              | o.due-care         |
|     |            |                              |                    |
|     |            |                              | o.comply           |
|     |            |                              |                    |
|     |            |                              | o                  |
|     |            |                              | .available-non-toe |
+-----+------------+------------------------------+--------------------+
| 5.  | F          | Subset Residual Information  | o.bypass-non-toe   |
| 2.7 | DP_RIP.2-1 | protection                   |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | F          | Subset Residual Information  | o.bypass-non-toe   |
| 2.8 | DP_RIP.2-2 | protection                   |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | FIA_UAU.2  | Timing of authentication     | o.known-non-toe    |
| 3.4 |            |                              |                    |
+-----+------------+------------------------------+--------------------+
| 5.  | FIA_UAU.6  | Re-authenticating            | o.bypass-non-toe   |
| 3.6 |            |                              |                    |
+-----+------------+------------------------------+--------------------+
| 5.  | FIA_UAU.7  | Protected authentication     | o.bypass-non-toe   |
| 3.7 |            | feedback                     |                    |
+-----+------------+------------------------------+--------------------+
| 5.  | FMT_MOF.1  | Management of security       | o.manage           |
| 4.1 |            | functions behavior           |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | FMT_M      | Static attribute             | o.manage           |
| 4.3 | SA.3-CCOPP | initialization               |                    |
|     |            |                              | o.due-care         |
|     |            |                              |                    |
|     |            |                              | O.AUT              |
|     |            |                              | HORIZATION-non-toe |
+-----+------------+------------------------------+--------------------+
| 5.  | F          | Management of Audit Trail    | o.manage           |
| 4.4 | MT_MTD.1-1 |                              |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | F          | Management of Audited Events | o.manage           |
| 4.5 | MT_MTD.1-2 |                              |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | FPT_AMT.1  | Abstract Machine Testing     | Required           |
| 5.1 |            |                              | dependency for:    |
|     |            |                              |                    |
|     |            |                              | FPT_TST.1          |
+-----+------------+------------------------------+--------------------+
| 5.  | FPT_R      | Recovery from Failure        | o.recover-system   |
| 5.5 | CV.2-CCOPP |                              |                    |
+-----+------------+------------------------------+--------------------+
| 5.  | FPT_RVM.1  | Non-Bypassability of the TSP | o.bypass-non-toe   |
| 5.7 |            |                              |                    |
+-----+------------+------------------------------+--------------------+
| 5.  | FPT_SEP.1  | TSF Domain Separation        | o.bypass-non-toe   |
| 5.8 |            |                              |                    |
|     |            |                              | o.due-care         |
+-----+------------+------------------------------+--------------------+
| 5.  | FTA_TAH.1  | TOE access history           | o.observe-non-toe  |
| 7.4 |            |                              |                    |
|     |            |                              | o.entry-non-toe    |
|     |            |                              |                    |
|     |            |                              | o.bypass-non-toe   |
|     |            |                              |                    |
|     |            |                              | o.due-care         |
|     |            |                              |                    |
|     |            |                              | o.comply           |
+-----+------------+------------------------------+--------------------+

## non-it Environmental Functional Requirements

The environment is required to satisfy the secure usage assumptions in
Section 3.2, meet all of the environmental security objectives outlined
in section 4.1, and support the objectives in section 4.3. The specific,
non-IT functional requirements are not identified in this PP. The
higher-level objective statements are considered sufficient for
determining the adequacy of non-IT environmental support.

The following objectives are covered, almost exclusively, by non-IT
environmental controls:

O.ACCESS-NON-TECHNICAL

O.DENIAL-SOPHISTICATED

O.DETECT-SOPHISTICATED

O.ENTRY-NON-TECHNICAL

O.ENTRY-SOPHISTICATED

O.PHYSICAL

The following objectives receive significant coverage by non-IT
environmental controls:

O.ACCESS-MALICIOUS

O.COMPLY

O.DUE-CARE

O.MANAGE

O.OPERATE

## Strength of function (SOF)

This section is required by the Common Criteria and specifies the
strength of function necessary to accomplish the intent of this PP on
probabilistic events, in this case Passwords.

### Minimum SOF Requirement

The appropriate minimum SOF level is **MEDIUM**.

### Specific SOF Requirements -- TOE

  ------- ------------- ------------------------------ ---------------------
  5.3.3   FIA_SOS.1     Verification of Secrets        FIPS PUB 112

  ------- ------------- ------------------------------ ---------------------

## Assurance Requirements 

The assurance requirements for CCOPP-OS are met by EAL4. EAL4 stresses
assurance through vendor actions that are within the bounds of current
best-commercial-practice. EAL4 provides, primarily via review of vendor
supplied evidence, independent confirmation that these actions have been
competently performed. EAL4 also includes the following independent,
third-party analysis: (1) confirmation of system generation and
installation procedures, (2) verification that the system security state
is not misrepresented; (3) verification of a sample of the vendor
functional testing; (4) searching for obvious vulnerabilities; and (5)
independent functional testing.

The assurance components for EAL4 are summarized in Table 5-3.

[]{#__RefHeading___Toc102926564 .anchor}Table 5.3 -- EAL-4 Assurance
Components

![](media/image1.png){width="5.729166666666667in"
height="4.822916666666667in"}

# rationale -- To Be Completed

This chapter provides the rationale for the selection, creation, and use
of the security policies, objectives, and components. Section 6.1
provides the rationale for the existence of the security objectives
based upon the stated security assumptions and policies while Section
6.2 provides the lower-level rationale for the existence of functional
and assurance components based upon the stated security objectives.
Section6.3 provides an analysis that map given security objectives to
components as well as mapping given components to security objectives.
In providing a mapping for the components and objectives, assurance is
gained that the objectives were entirely met. This is further detailed
in Tables Error: Reference source not found and Table 6-1.

##  Security Objectives Rationale

The description of security objectives for the TOE and its environment
in Chapter 4, plus the description of the TOE security environment in
Chapter 3 are fully compliant with \[CAPP\] AND \[RBAC\]. The security
objectives rationale presented in \[CAPP\] Section 7.2.2, with the
addition of the following tables satisfies the Objectives Rationale.

[]{#__RefHeading___Toc102926565 .anchor}Table 6‑1 --Threats and Policies
to Objectives

<table>
<colgroup>
<col style="width: 25%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 7%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 7%" />
<col style="width: 5%" />
</colgroup>
<tbody>
<tr class="odd">
<td><strong>OBJECTIVES</strong></td>
<td rowspan="2"><blockquote>
<p><strong>O.ACCOUNT</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.ADMIN</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.AUDIT/ING</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.AUTHORIZATION</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.DISCRETIONARY-</strong></p>
<p><strong>ACCESS</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.DUTY</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.ENFORCEMENT</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.ENTRY</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.HIERCHICAL</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.KNOWN</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.MANAGE</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.RESIDUAL_</strong></p>
<p><strong>INFORMATION</strong></p>
</blockquote></td>
<td rowspan="2"><blockquote>
<p><strong>O.ROLE</strong></p>
</blockquote></td>
</tr>
<tr class="even">
<td><strong>Threats and Policies</strong></td>
</tr>
<tr class="odd">
<td>T.ACCESS</td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
</tr>
<tr class="even">
<td>T.ENTRY</td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>T.OPERATE</td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>T.ROLEDEV</td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>P.ACCESS</td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>P.ACCOUNTABILITY</td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>P.AUTHORIZED_USER</td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>P.NEED_TO_KNOW</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>*</strong></td>
<td><strong>*</strong></td>
<td></td>
</tr>
</tbody>
</table>

### Complete Coverage -- Environmental (Non-IT) Assumptions

This section provides evidence demonstrating coverage of the Non-IT
security objectives by the environmental assumptions. The following
table shows this assumption to objective mapping.

[]{#__RefHeading___Toc102926566 .anchor}Table 6‑2 Non-IT Security
Objectives to Environment Assumptions

+-----------------------------------+----------------------------------+
| Non IT Security Objectives        | Environmental Assumptions        |
+-----------------------------------+----------------------------------+
| O.CONNECT(RBAC)                   | A.CONNECT                        |
+-----------------------------------+----------------------------------+
| O.INSTALL(RBAC &CAPP)             | A.MANAGE                         |
|                                   |                                  |
|                                   | A.NO_EVIL_ADM                    |
|                                   |                                  |
|                                   | A.PEER                           |
+-----------------------------------+----------------------------------+
| O.PHYSICAL(RBAC &CAPP)            | A.LOCATE                         |
|                                   |                                  |
|                                   | A.PROTECT                        |
|                                   |                                  |
|                                   | A.CONNECT                        |
+-----------------------------------+----------------------------------+
| O.CREDEN(CAPP)                    | A.COOP                           |
+-----------------------------------+----------------------------------+

### Complete Coverage -- Threats

The CAPP TOE security objectives have been derived exclusively from
statements of organizational security policy, and therefore, there are
no explicitly defined CAPP threats countered by this ST.

The following are the Threats defined in the RBAC PP, with the T.OPERATE
and T.ROLEDEV handled by the inclusion of the CAPP PP and its inclusion
in HP-UX 11i v2.

[]{#__RefHeading___Toc102926567 .anchor}Table 6‑3 Threats to Security
Objectives

+----------------------------------+-----------------------------------+
| Threats                          | Security Objectives               |
+----------------------------------+-----------------------------------+
| T.ACCESS                         | O.ACCOUNT                         |
|                                  |                                   |
|                                  | O.ADMIN                           |
+----------------------------------+-----------------------------------+
| T.ENTRY                          | O.AUDIT                           |
|                                  |                                   |
|                                  | O.DUTY                            |
+----------------------------------+-----------------------------------+
| T.OPERATE                        | O.AUTHORIZATION                   |
|                                  |                                   |
|                                  | O.MANAGE                          |
+----------------------------------+-----------------------------------+
| T.ROLEDEV                        | O.ROLE                            |
+----------------------------------+-----------------------------------+

.

### Complete Coverage -- Policy

This section provides evidence demonstrating coverage of the
Organizational Security Policy by both the IT and Non-IT security
objectives. The following table shows this objective to policy mapping,
and the table is followed by a discussion of the coverage for each
Security Policy.

[]{#__RefHeading___Toc102926568 .anchor}Table 6‑4 Security Policies to
Objectives

+----------------------------------+-----------------------------------+
| Organizational Security Policies | Security Objectives               |
+----------------------------------+-----------------------------------+
| P.ACCESS                         | O.ACCOUNT                         |
|                                  |                                   |
|                                  | O.ADMIN                           |
|                                  |                                   |
|                                  | O.ENTRY                           |
+----------------------------------+-----------------------------------+
| P.AUTHORIZED_USERS               | O.AUTHORIZATION                   |
|                                  |                                   |
|                                  | O.MANAGE                          |
|                                  |                                   |
|                                  | O.ENFORCEMENT                     |
+----------------------------------+-----------------------------------+
| P.NEED_TO_KNOW                   | O.DISCRETIONARY_ACCESS            |
|                                  |                                   |
|                                  | O.RESIDUAL_INFORMATION            |
|                                  |                                   |
|                                  | O.MANAGE                          |
|                                  |                                   |
|                                  | O.ENFORCEMENT                     |
+----------------------------------+-----------------------------------+
| P.ACCOUNTABILITY                 | O.AUDITING                        |
|                                  |                                   |
|                                  | O.MANAGE                          |
|                                  |                                   |
|                                  | O.ENFORCEMENT                     |
+----------------------------------+-----------------------------------+

The following discussion provides detailed evidence of coverage for each
statement of organizational security policy:

**P.ACCESS**

Access rights to specific data objectives are determined by the owner of
the object, the role of the subject attempting access, and the implicit
and explicit access rights to the object granted to the role of object
owner. \[RBAC\]

This policy is implemented by O.ACCOUNT; O.ADMIN controls the access
rights, and O.ENTRY.

**P.AUTHORIZED_USERS**

Only those users who have been authorized to access the information
within the system may access the system.

This policy is implemented by the O.AUTHORIZATION objective. The
O.MANAGE supports this policy by requiring authorized administrators to
be able to manage the functions and O.ENFORCEMENT ensures that functions
are invoked and operate correctly.

**P.NEED_TO_KNOW**

The system must limit the access to, modification of, and destruction of
the information in protected resources to those authorized users which
have a "need to know" for that information.

This policy is implemented by the O.DISCRETIONARY_ACCESS objective. The
O.RESIDUAL_INFORMATION objective ensures that information will not be
given to users which do not have a need to know, when resources are
reused. The O.MANAGE supports this policy by requiring authorized
administrator be able to manage the functions and O.ENFORCEMENT ensures
that functions are invoked and operate correctly.

**P.ACCOUNTABILITY**

The users of the system shall be held accountable for their actions
within the system.

This policy is implemented by the O.AUDITING objective by requiring that
actions are recorded in an audit trail. The O.MANAGE supports this
policy by requiring authorized administrator be able to manage the
functions and O.ENFORCEMENT ensures that functions are invoked and
operate correctly.

## Security Requirements Rationale

This ST as a whole provides evidence supporting the combined internal
consistency and completeness of the functional components that comprise
the ST against the CAPP and RBAC. Although there is no Rationale Section
within the RBAC, the Rationale for \[CAPP\] plus the additional
information provided in this section plus other tables accomplishes the
requirements.

### Security Functional Requirements cover Security Objectives

The security functional requirements in this ST are derived directly
from \[CAPP\] and \[RBAC\], with the security objectives that agree with
Chapter 4 identified in Table 5.1 and the following table. Therefore,
the rationale for Complete Coverage in CAPP section 7.2.2, with the
amended table below, satisfy the rationale and is not repeated here.

+-------------------------------------+--------------------------------+
| []{#__RefHeading___Toc102926569     |                                |
| .anchor}Table 6‑5 Objectives to     |                                |
| SFRs                                |                                |
+=====================================+================================+
| **Security Objectives\              | **Security Functional          |
| **                                  | Requirements**                 |
+-------------------------------------+--------------------------------+
| O.ACCOUNT                           | FIA_ATD.1                      |
|                                     |                                |
|                                     | FIA_SOS.1                      |
|                                     |                                |
|                                     | FIA_UAU.2                      |
|                                     |                                |
|                                     | FIA_UAU.7                      |
|                                     |                                |
|                                     | FIA_UID.1                      |
|                                     |                                |
|                                     | FMT_MSA.2                      |
|                                     |                                |
|                                     | FMT_MTD.1-1/5                  |
+-------------------------------------+--------------------------------+
| O.ADMIN                             | FAU_GEN.1                      |
|                                     |                                |
|                                     | FAU_GEN.2                      |
|                                     |                                |
|                                     | FAU_SAR.1                      |
|                                     |                                |
|                                     | FAU_SAR.2                      |
|                                     |                                |
|                                     | FAU_SAR.3                      |
|                                     |                                |
|                                     | FAU_SEL1                       |
|                                     |                                |
|                                     | FAU_STG.1                      |
|                                     |                                |
|                                     | FIA_USB.1                      |
|                                     |                                |
|                                     | FMT_MTD.1-1                    |
|                                     |                                |
|                                     | FMT_MTD.1-2                    |
|                                     |                                |
|                                     | FMT_MTD.1-5                    |
|                                     |                                |
|                                     | FPT_STM.1                      |
+-------------------------------------+--------------------------------+
| O.AUTHORIZATION                     | FDP_ACC.1                      |
|                                     |                                |
|                                     | FDP_ACF.1                      |
|                                     |                                |
|                                     | FIA_ATD.1                      |
|                                     |                                |
|                                     | FMT_MSA.1-2                    |
|                                     |                                |
|                                     | FMT_MSA.2                      |
|                                     |                                |
|                                     | FMT_MSA.3                      |
|                                     |                                |
|                                     | FMT_MTD.1-5                    |
+-------------------------------------+--------------------------------+
| O.AUDIT                             | FAU_GEN.1                      |
|                                     |                                |
|                                     | FAU_GEN.2                      |
|                                     |                                |
|                                     | FAU_SAR.1                      |
|                                     |                                |
|                                     | FAU_SAR.2                      |
|                                     |                                |
|                                     | FAU_SAR.3                      |
|                                     |                                |
|                                     | FAU_SELl.1                     |
|                                     |                                |
|                                     | FAU_STG.1                      |
|                                     |                                |
|                                     | FAU_STG.3                      |
|                                     |                                |
|                                     | FAU_STG.4                      |
|                                     |                                |
|                                     | FIA_USB.1                      |
|                                     |                                |
|                                     | FMT_MTD.1-1                    |
|                                     |                                |
|                                     | FMT_MTD.1-2                    |
|                                     |                                |
|                                     | FPT_STM.1                      |
+-------------------------------------+--------------------------------+
| O.DISCRETIONARY_ACCESS              | FDP_ACC.1                      |
|                                     |                                |
|                                     | FDP_ACF.1                      |
|                                     |                                |
|                                     | FIA_ATD.1                      |
|                                     |                                |
|                                     | FIA_USB.1                      |
|                                     |                                |
|                                     | FMT_MSA.1                      |
|                                     |                                |
|                                     | FMT_MSA.3                      |
|                                     |                                |
|                                     | FMT_REV.1                      |
+-------------------------------------+--------------------------------+
| O.DUTY                              |                                |
+-------------------------------------+--------------------------------+
| O.ENFORCEMENT                       | FPT_AMT.1                      |
|                                     |                                |
|                                     | FPT_RVM.1                      |
|                                     |                                |
|                                     | FPT_SEP.1                      |
+-------------------------------------+--------------------------------+
| O.ENTRY                             | FDP_ACC.1                      |
|                                     |                                |
|                                     | FDP_ACF.1                      |
|                                     |                                |
|                                     | FPT_AMT.1                      |
|                                     |                                |
|                                     | FPT_RVM.1                      |
|                                     |                                |
|                                     | FPT_FLS.1                      |
|                                     |                                |
|                                     | FPT_SEP.1                      |
|                                     |                                |
|                                     | FTA_LSA.1                      |
|                                     |                                |
|                                     | FTA_TSE.1                      |
+-------------------------------------+--------------------------------+
| O.HIERCHICAL                        | FMT_MSA.2                      |
+-------------------------------------+--------------------------------+
| O.KNOWN                             | FIA_UID.2                      |
+-------------------------------------+--------------------------------+
| O.MANAGE                            | FAU_SAR.1                      |
|                                     |                                |
|                                     | FAU_SAR.3                      |
|                                     |                                |
|                                     | FAU_SEL.1                      |
|                                     |                                |
|                                     | FAU_STG.1                      |
|                                     |                                |
|                                     | FAU_STG.3                      |
|                                     |                                |
|                                     | FA8_STG.4                      |
|                                     |                                |
|                                     | FMT_MTD.1-1                    |
|                                     |                                |
|                                     | FMT_MTD.1-2                    |
|                                     |                                |
|                                     | FMT_MTD.1-3                    |
|                                     |                                |
|                                     | FMT_MTD.1-4                    |
|                                     |                                |
|                                     | FMT_REV.1                      |
|                                     |                                |
|                                     | FMT_SMF.1                      |
|                                     |                                |
|                                     | FMT_SMR.1                      |
+-------------------------------------+--------------------------------+
| O.RESIDUAL_INFORMATION              | FDP_RIP.2-1                    |
|                                     |                                |
|                                     | FDP_RIP.2-2                    |
+-------------------------------------+--------------------------------+
| O.ROLE                              | FIA_UID.2                      |
|                                     |                                |
|                                     | FIA_USB.1                      |
|                                     |                                |
|                                     | FPT_RCV.4                      |
+-------------------------------------+--------------------------------+

### Internal Consistency of Requirements

This section describes the mutual support and internal consistency of
the components selected for this security target. These properties are
discussed for both functional and assurance components.

The functional components were selected from pre-defined CC components.
The use of component refinement was accomplished in accordance with CC
guidelines.

Assignment, selection, and refinement operations were carried out among
components using consistent computer security terminology. This helps to
avoid the ambiguity associated with interpretations of meanings of terms
between related components.

Multiple instantiation of identical or hierarchically-related components
were used where necessary to clearly state the required functionality
that must exist in a TOE conformant with these profiles.

###  Satisfaction of Dependencies

The security functional requirement of the TOE comply with \[CAPP\] &
\[RBAC\] with no augmentation except for the addition of the dependency
for FMT_SMF.1 which is levied on FMT_MSA.1 and FMT_MTD.1. The dependency
satisfaction is documented in each appropriate SFR in Chapter 5.

### Rationale for Assurance Level

This security target has been developed for a generalized environment
with a moderate level of risk to the assets. It is intended that
products used in these environments will be generally available, without
modification to meet the security needs of the environment. As such it
was determined the Evaluation Assurance Level 4 was the most
appropriate.

### Rationale for SOF Rating

The strength of function rating of SOF-medium is consistent with the
EAL-4 requirements. SFR FIA_SOS.1 describes how we meet the SOF by
providing a 'one off' probability of guessing the password to 1 in
1,000,000.

##  PP claims RATIONALE

The objectives used in this ST are from \[CAPP\] and \[RBAC\], and the
only change is to use the single Objective AUDIT/ING instead of two
AUDIT and AUDITING as they had the same meaning in both PPs.

The SFRs used in this ST are derived from \[CAPP\] and \[RBAC\], and the
required assignments and selections for each are each displayed in
Chapter 5.

#  

# Appendix A: ACRONYMS 

  ------------ ----------------------------------------------------------
  **CC**       Common Criteria \[for IT Security Evaluation\]

  **COTS**     Commercial Off The Shelf

  **DAC**      Discretionary Access Control

  **EAL**      Evaluation Assurance Level

  **IT**       Information Technology

  **MAC**      Mandatory Access Control

  **NIST**     National Institute of Standards and Technology

  **PP**       Protection Profile

  **RBAC**     Role Based Access Control

  **SF**       Security Function

  **SFP**      Security Function Policy

  **ST**       Security Target

  **TOE**      Target of Evaluation

  **TSC**      TSF Scope of Control

  **TSF**      TOE Security Functions

  **TSP**      TOE Security Policy
  ------------ ----------------------------------------------------------

# Appendix b -- REFERENCES

\[CAPP\] *Controlled Access Protection Profile,* version 1.d*,* 8
October 1999

\[CC-V2.2\] *Common Criteria for Information Technology Security
Evaluation*, 31 December 2003.

\[CCOPP-OS-R\] *COTS Compartmentalized Operations Protection Profile --
Rationale,* version .03I, 8 October 2004

\[CSPP\] *Guidance for COTS Security Protection Profiles*, version 0.4,
February 2001

\[CSPP-OS\] *COTS Security Protection Profile - Operating Systems*,
version 1.0, January 2003

\[LSPP\] *Labeled Security Protection Profile,* version 1.b, 8 October
1999

\[RBAC\] *Role Based Access Control Protection Profile,* Version 1.0,
July 30, 1998

#