U.S. DEPARTMENT OF COMMERCE 

Donald L. Evans, Secretary 

TECHNOLOGY ADMINISTRATION 

Phillip J. Bond, Under Secretary 

of Commerce for Technology 

NATIONAL INSTITUTE OF 

STANDARDS AND TECHNOLOGY 

Arden L. Bement, Jr., Director 

COTS Security Protection Profile - Operating Systems (CSPP-OS) 

(Worked Example Applying Guidance of NISTIR-6462, CSPP) 

Version 1.0 

Gary Stoneburner 

U.S. DEPARTMENT OF 

COMMERCE 

Technology Administration 

National Institutes of Standards and 

Technology 

Gaithersburg, MD 20899 

April 2003 

NISTIR 6985
Reports on Computer Systems Technology 

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the 

Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, 

proof of concept implementations, and technical analyses to advance the development and productive 

use of information technology. ITL’s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective security and privacy of 

sensitive unclassified information in Federal computer systems. This NIST Interagency Report 

(NISTIR) reports on ITL’s research, guidance, and outreach efforts in computer security, and its 

collaborative activities with industry, government, and academic organizations. 

Certain commercial entities, equipment, or materials may be identified in this document in order 

to describe an experimental procedure or concept adequately. Such identification is not intended 

to imply recommendation or endorsement by the National Institute of Standards and Technology, 

nor is it intended to imply that the entities, materials, or equipment are necessarily the best 

available for the purpose. 

National Institute of Standards and Technology Interagency Report 6985 

Natl. Inst. Stand. Technol. NISTIR-6985, 171 pages (April 2003) 
Authority

This document has been developed by NIST in furtherance of its statutory responsibilities (under 

the Computer Security Act of 1987 and the Information Technology Management Reform Act of 

1996, specifically 15 U.S.C. 278 g-3(a)(5)). This is not a guideline within the meaning of (15 

U.S.C. 278 g-3 (a)(3)). 

 This document is recommended for use by Federal organizations which process sensitive 

information,1

 and is consistent with the requirements of OMB Circular A-130, Appendix III. 

The recommendations herein are not mandatory and binding standards. This document may be 

used by non-governmental organizations on a voluntary basis. It is not subject to copyright. 

Nothing in this document should be taken to contradict standards and guidelines made 

mandatory and binding upon Federal agencies by the Secretary of Commerce under his statutory 

authority. Nor should these recommendations be interpreted as altering or superseding the 

existing authorities of the Secretary of Commerce, the Director of the Office of Management and 

Budget, or any other Federal official. 

Purpose

The purpose of this document is to provide a worked example of the guidance in NISTIR-6462 

for the development of Common Criteria Protection Profiles for commercial off the shelf 

(COTS) information technology. 

Audience

The intended audience consists of those individuals and organizations in both government and 

private sectors who are tasked with the responsibility to develop or review Protection Profiles. 

Presentation

This document is presented as a protection profile, followed by a rationale that is structured as a 

separate document. This format was selected to facilitate using this guidance as a template for 

the development of Protection Profiles. 

 

1

 The Computer Security Act defines the term “sensitive information” as: any information, the loss, misuse, or 

unauthorized access to or modification of which could adversely affect the national interest or the conduct of federal 

programs, or the privacy to which individuals are entitled under section 552a of title 5, United States Code (the 

Privacy Act), but which has not been specifically authorized under criteria established by an Executive Order or an 

Act of Congress to be kept secret in the interest of national defense or foreign policy. 
COTS Security Protection Profile – Operating Systems 

(CSPP-OS) 

Version 1.0 

April 23, 2003 

Put your Organization’s name and address here 

This document is consistent with the 

Common Criteria for Information Technology Security Evaluation 

Version 2.1 

Interpretations Incorporated (as applicable) 

NIAP CCIMB 

All approved posted to 

http://niap.nist.gov/cc-scheme

as of 1/15/03 

(347, 350, 352, 375, 381, 389, 393, 395, 405, 406, 

407, 409, 410, 411, 412, 414, 415, 416, 417, 418, 

420, 421, 422, 423, 424, 425, 426, 427, 429, 459) 

Note: Intent of I-0407 and I-0429 have been 

incorporated without renaming affected components 

All Final posted to 

www.commoncriteria.org 

as of 1/15/03 

(3,4,6,8,9,13,16,19,24,27, 31, 32, 33, 37, 43, 49, 51, 

55, 58, 64, 65, 67, 74, 75, 84, 85, 95, 98, 116, 120, 

127, 128, 133, 138) 
CSPP-OS ii Ver 1.0 – 4/23/03 

TABLE OF CONTENTS 

SECTION PAGE 

1. INTRODUCTION.............................................................................................................................. 1

1.1 IDENTIFICATION...........................................................................................................................1

1.2 OVERVIEW....................................................................................................................................1

2. TOE DESCRIPTION......................................................................................................................... 4

2.1 PRODUCT CLASS ..........................................................................................................................4

2.2 OPERATIONAL ENVIRONMENT ....................................................................................................4

2.3 REQUIRED SECURITY FUNCTIONALITY.........................................................................................5

3. SECURITY ENVIRONMENT ......................................................................................................... 6

3.1 INTRODUCTION.......................................................................................................................6

3.2 SECURE USAGE ASSUMPTIONS....................................................................................................7

3.3 ORGANIZATIONAL SECURITY POLICIES .................................................................................8

3.4 THREATS TO SECURITY..............................................................................................................10

3.4.1 Threats environment addresses .............................................................................................14

3.4.2 Threats TOE addresses..........................................................................................................17

3.4.3 Threats TOE and Environment jointly address .....................................................................19

3.5 GENERAL ASSURANCE NEED .....................................................................................................21

4. SECURITY OBJECTIVES............................................................................................................. 22

4.1 ENVIRONMENTAL SECURITY OBJECTIVES .................................................................................22

4.2 TOE SECURITY OBJECTIVES ......................................................................................................25

4.3 JOINT TOE/ENVIRONMENT SECURITY OBJECTIVES...................................................................27

5. FUNCTIONAL SECURITY REQUIREMENTS.......................................................................... 29

5.1 FUNCTIONAL REQUIREMENTS - TOE ........................................................................................29

5.2 FUNCTIONAL REQUIREMENTS - IT ENVIRONMENT....................................................................34

5.3 NON-IT ENVIRONMENTAL FUNCTIONAL REQUIREMENTS .........................................................35

5.4 STRENGTH OF FUNCTION (SOF) ................................................................................................36

5.4.1 Minimum SOF Requirement.................................................................................................36

5.4.2 Specific SOF Requirements - TOE .......................................................................................36

5.4.3 Specific SOF Metrics - IT Environment ...............................................................................38

6. ASSURANCE REQUIREMENTS.................................................................................................. 39

7. APPLICATION NOTES ................................................................................................................. 42

7.1 EVALUATION SCOPE, DEPTH, AND RIGOR..................................................................................42

8. RATIONALE.................................................................................................................................... 42

9. REFERENCES ................................................................................................................................. 42

A. APPENDIX A: ACRONYMS........................................................................................................ A1

B. APPENDIX B: TOE FUNCTIONAL REQUIREMENT DETAILS ..........................................B1

B.1 COMMON SYNTAX .................................................................................................................... B1

B.2 CSPP ACCESS CONTROL SECURITY FUNCTION POLICY (SFP) ................................................ B1

B.2.1 Discretionary Access Control............................................................................................... B1

B.2.2 Non-discretionary Access Controls...................................................................................... B2

B.2.3 CSPP Access Control Precedence Rules.............................................................................. B2

B.3 AUDIT (FAU) ............................................................................................................................. B3

B.3.1 FAU_GEN.1-CSPP Audit data generation .......................................................................... B3

B.3.2 FAU_GEN.2-NIAP-0410 User identity generation ............................................................. B3
CSPP-OS iii Ver 1.0 – 4/23/03 

B.3.3 FAU_SAR.1 Audit review ................................................................................................... B4

B.3.4 FAU_SAR.2 Restricted audit review ................................................................................... B4

B.3.5 FAU_SAR.3 Selectable audit review................................................................................... B4

B.3.6 FAU_SEL.1-CSPP Selective audit....................................................................................... B4

B.3.7 FAU_STG.1-NIAP-0423 Protected audit trail storage ........................................................ B5

B.3.8 FAU_STG.3 Action in case of possible audit data loss ....................................................... B5

B.4 USER DATA PROTECTION (FDP)................................................................................................ B5

B.4.1 FDP_ACC.1 Subset access control ...................................................................................... B5

B.4.2 FDP_ACF.1-CSPP Security attribute based access control ................................................. B6

B.4.3 FDP_ETC.1-CSPP Export of user data without security attributes ..................................... B6

B.4.4 FDP_ITC.1 Import of user data without security attributes................................................. B7

B.4.5 FDP_RIP.1 Subset residual information protection ............................................................. B7

B.4.6 FDP_UCT.1 Basic data exchange confidentiality................................................................ B7

B.4.7 FDP_UIT.1 Data exchange integrity.................................................................................... B8

B.5 IDENTIFICATION AND AUTHENTICATION (FIA)........................................................................ B8

B.5.1 FIA_AFL.1-NIAP-0425 Authentication failure handling.................................................... B8

B.5.2 FIA_ATD.1 User attribute definition................................................................................... B9

B.5.3 FIA_SOS.1 Verification of secrets....................................................................................... B9

B.5.4 FIA_UAU.1 Timing of authentication ............................................................................... B10

B.5.5 FIA_UAU.5 Multiple authentication mechanisms............................................................. B10

B.5.6 FIA_UAU.6 Re -authentication ......................................................................................... B10

B.5.7 FIA_UAU.7 Protected authentication feedback................................................................. B11

B.5.8 FIA_UID.1 Timing of identification.................................................................................. B11

B.5.9 FIA_USB.1-NIAP-0415 User-subject binding .................................................................. B11

B.6 SECURITY MANAGEMENT (FMT) ............................................................................................. B12

B.6.1 FMT_MOF.1 Management of security functions behavior ............................................... B12

B.6.2 FMT_MSA.1 Management of security attributes .............................................................. B12

B.6.3 FMT_MSA.3-NIAP-0409 Static attribute initialization..................................................... B13

B.6.4 FMT_MTD.1 Management of TSF data ............................................................................ B13

B.6.5 FMT_SAE.1 Time-limited authorization ........................................................................... B13

B.6.6 FMT_SMR.1 Security roles ............................................................................................... B14

B.7 PROTECTION OF TRUSTED SECURITY (FPT)........................................................................... B14

B.7.1 FPT_AMT.1 Abstract machine testing .............................................................................. B14

B.7.2 FPT_FLS.1 Failure with preservation of secure state ........................................................ B14

B.7.3 FPT_ITC.1-CSPP Inter-TSF confidentiality during transmission ..................................... B15

B.7.4 FPT_ITI.1-CSPP Inter-TSF detection of modification ...................................................... B15

B.7.5 FPT_RCV.2-NIAP-0406 Recovery from Failure............................................................... B16

B.7.6 FPT_RPL.1-CSPP Replay detection .................................................................................. B16

B.7.7 FPT_RVM.1 Non-bypassability of the TSP....................................................................... B16

B.7.8 FPT_SEP.1 TSF domain separation................................................................................... B17

B.7.9 FPT_TDC.1 Inter-TSF basic TSF data consistency........................................................... B17

B.7.10 FPT_TST.1 TSF testing................................................................................................. B18

B.7.11 FPT_SYN-CSPP.1 TSF synchronization....................................................................... B18

B.8 RESOURCE UTILIZATION (FRU) ............................................................................................... B19

B.8.1 FRU_RSA.1-CSPP Maximum quotas................................................................................ B19

B.9 TOE ACCESS (FTA) ............................................................................................................... B19

B.9.1 FTA_LSA.1 Limitation on scope of selectable attributes.................................................. B19

B.9.2 FTA_MCS.1-CSPP Basic limitation on multiple concurrent sessions............................... B19

B.9.3 FTA_SSL.1 TSF initiated session locking ......................................................................... B20

B.9.4 FTA_SSL.2 User-initiated locking..................................................................................... B20

B.9.5 FTA_SSL.3 TSF-initiated termination............................................................................... B20
CSPP-OS iv Ver 1.0 – 4/23/03 

B.9.6 FTA_TAB.1-CSPP Default TOE access banners .............................................................. B20

B.9.7 FTA_TAH.1 TOE access history ....................................................................................... B21

B.9.8 FTA_TSE.1 TOE session establishment ............................................................................ B21

B.10 TRUSTED PATH/CHANNELS (FTP) ........................................................................................... B22

B.10.1 FTP_ITC.1-CSPP Inter-TSF trusted channel ................................................................ B22

C. APPENDIX C: TOE ASSURANCE REQUIREMENT DETAILS ........................................... C1

C.1 CONFIGURATION MANAGEMENT (ACM) ................................................................................. C1

C.1.1 ACM_CAP.3 Authorization controls................................................................................... C1

C.1.2 ACM_SCP.2 Problem tracking CM coverage ..................................................................... C2

C.2 DELIVERY AND OPERATION (ADO).......................................................................................... C2

C.2.1 ADO_DEL.1 Delivery procedures....................................................................................... C2

C.2.2 ADO_IGS.1 Installation, generation, and start-up procedures............................................. C2

C.3 DEVELOPMENT (ADV) ............................................................................................................. C3

C.3.1 ADV_FSP.1 Informal functional specification .................................................................... C3

C.3.2 ADV_HLD.1 Descriptive high-level design ........................................................................ C3

C.3.3 ADV_RCR.1 Informal Correspondence Demonstration...................................................... C4

C.3.4 ADV_SPM.1 Informal TOE security policy model............................................................. C4

C.4 GUIDANCE DOCUMENTS (AGD) ............................................................................................... C5

C.4.1 AGD_ADM.1 Administrator guidance ................................................................................ C5

C.4.2 AGD_USR.1 User Guidance................................................................................................ C6

C.5 LIFE CYCLE SUPPORT (ALC).................................................................................................... C7

C.5.1 ALC_DVS.1 Identification of security measures................................................................. C7

C.5.2 ALC_FLR.2 Flaw reporting procedures .............................................................................. C8

C.6 TESTS (ATE)............................................................................................................................. C9

C.6.1 ATE_COV.2 – Analysis of coverage................................................................................... C9

C.6.2 ATE_DPT.1 Testing: High Level Design ........................................................................... C9

C.6.3 ATE_FUN.1 Functional Testing ........................................................................................ C10

C.6.4 ATE_IND.2 Independent Testing - Sample ....................................................................... C10

C.7 VULNERABILITY ASSESSMENT (AVA) ................................................................................... C11

C.7.1 AVA_MSU.2 Validation of Analysis ................................................................................ C11

C.7.2 AVA_SOF.1 Strength of TOE Security Function Evaluation............................................ C12

C.7.3 AVA_VLA.1 Developer vulnerability analysis ................................................................. C12

C.8 MAINTENANCE OF ASSURANCE (AMA) ................................................................................. C13

D. APPENDIX D: IT-ENVIRONMENT FUNCTIONAL REQUIREMENT DETAILS............. D1

D.1 AUDIT (FAU) ............................................................................................................................. D1

D.1.1 FAU_STG.1-NIAP-0423 Protected audit trail storage.................................................... D1

D.2 USER DATA PROTECTION (FDP)................................................................................................ D1

D.2.1 FDP_ACC.1 Subset access control.................................................................................. D1

D.2.2 FDP_RIP.1 Subset residual information protection......................................................... D2

D.3 IDENTIFICATION AND AUTHENTICATION (FIA)........................................................................ D2

D.3.1 FIA_UAU.1 Timing of authentication............................................................................. D2

D.3.2 FIA_UAU.6 Re -authentication....................................................................................... D2

D.3.3 FIA_UAU.7 Protected authentication feedback .............................................................. D2

D.4 SECURITY MANAGEMENT (FMT) ............................................................................................... D2

D.4.1 FMT_MOF.1 Management of security functions behavior ............................................. D2

D.4.2 FMT_MSA.3-NIAP-0409 Static attribute initialization .................................................. D3

D.4.3 FMT_MTD.1 Management of TSF’s IT-environment data............................................. D3

D.5 PROTECTION OF TRUSTED SECURITY (FPT)............................................................................. D3

D.5.1 FPT_AMT.1 Abstract machine testing ............................................................................ D3

D.5.2 FPT_RCV.2-NIAP-0406 Recovery from Failure ............................................................ D3
CSPP-OS v Ver 1.0 – 4/23/03 

D.5.3 FPT_RVM.1 Non-bypassability of the TSP .................................................................... D4 

D.5.4 FPT_SEP.1 TSF domain separation ................................................................................ D4

D.5.5 FPT_SYN-CSPP.1 TSF synchronization......................................................................... D4

D.6 RESOURCE UTILIZATION (FRU) ................................................................................................. D4

D.7 TOE ACCESS (FTA) ................................................................................................................. D5

D.7.1 FTA_TAH.1 TOE access history..................................................................................... D5

D.8 TRUSTED PATH/CHANNELS (FTP) ............................................................................................. D5
CSPP-OS vi Ver 1.0 – 4/23/03 

TABLE OF TABLES 

TABLE PAGE 

TABLE 3.2-1 – SECURITY ASSUMPTIONS - TOE.....................................................................................................................7

TABLE 3.2-2 – SECURITY ASSUMPTIONS - PERSONNEL..........................................................................................................7

TABLE 3.3-1 – SECURITY POLICIES........................................................................................................................................8

TABLE 3.4-1 – SECURITY THREATS ADDRESSED BY TOE’S ENVIRONMENT ........................................................................11

TABLE 3.4-2 – SECURITY THREATS ADDRESSED BY TOE....................................................................................................12

TABLE 3.4-3 – SECURITY THREATS ADDRESSED JOINTLY BY TOE AND ENVIRONMENT .....................................................13

TABLE 4-1 – ENVIRONMENTAL SECURITY OBJECTIVES ......................................................................................................22

TABLE 4-2 – TOE SECURITY OBJECTIVES ..........................................................................................................................25

TABLE 4-3 – JOINT TOE/ENVIRONMENT SECURITY OBJECTIVES........................................................................................27

TABLE 5-1 – FUNCTIONAL COMPONENTS - TOE.................................................................................................................29

TABLE 5-2 – FUNCTIONAL COMPONENTS - IT ENVIRONMENT ............................................................................................34

TABLE 5-3 – SOF METRICS - TOE......................................................................................................................................36

TABLE 5-4 – SOF METRICS - IT ENVIRONMENT.................................................................................................................38

TABLE 6-1 – EAL-CSPP ASSURANCE COMPONENTS..........................................................................................................39

TABLE 6-2 – EAL-CSPP AUGMENTATION TO EAL-2 .........................................................................................................40
CSPP-OS 1 Ver 1.0 – 4/23/03 

1. INTRODUCTION 

1.1 IDENTIFICATION 

Title: CSPP-OS - COTS Security Protection Profile - Operating Systems 

Assurance level: EAL2 – augmented (EAL-CSPP) 

CC Conformance Claims: Part 2 Extended, Part 3 Conformant 

Registration: <To be filled in upon registration> 

Keywords: Protection Profile, COTS, general-purpose operating systems, networked information 

systems, baseline protection 

1.2 OVERVIEW 

Purpose 

The purpose of CSPP-OS is to define, and specify the requirements necessary to solve, the 

security problem that COTS operating systems (perhaps with add-on packages) can be expected 

to address in the near-term. 

This PP is developed using the guidance from [CSPP]. 

Scope 

Type of system. CSPP-OS provides the requirements necessary to specify needs for operating 

systems in both stand-alone and distributed, multi-user information systems. 

Type of access. CSPP-OS recognizes two forms of legitimate access; namely, public access and 

“authenticated users”. With public access, the user does not have a unique identifier and is 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” who 

are (1) uniquely identifiable by the system, (2) have legitimate access beyond publicly available 

information, and (3) are authenticated prior to being granted such access. 

Nature of use. CSPP-OS compliant operating systems are suitable for the protection of 

information in real-world environments, both commercial and government. 

• CSPP-OS compliant OSs 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. 
CSPP-OS 2 Ver 1.0 – 4/23/03 

Key Assumptions. Key assumptions that apply for CSPP-OS compliant OSs are – 

• the Target of Evaluation (TOE, the OS for which requirements are being specified) is 

comprised of near-term, commercial off the shelf (COTS) information technology 

• 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 CSPP-OS compliant OS. 

Summary of CSPP-OS Requirements 

Systems incorporating main-stream, COTS operating systems (OSs) achieve the advantages such 

products offer; for example, high-functionality with low-cost. However, these advantages are 

not achieved without some tradeoffs; an example of which is security capability. CSPP-OS 

identifies a cost-effective, security baseline for systems built from COTS OSs, ensuring that 

reasonable security expectations are achieved. 

CSPP-OS also identifies those areas where it is not realistic to expect a typical COTS operating 

system to provide sufficient protection. These areas are the direct result of the fact that the 

driving factors for COTS (functionality, cost, and time to market) have tended to work against 

increasing the security capabilities beyond those identified in CSPP-OS. 

Assurance. CSPP-OS assurances have been selected to provide the level of confidence resulting 

from (1) existing best practices for COTS development and (2) less expensive and more timely 

third-party evaluation. This equates, in summary, to OS technical countermeasures that - 

• are sufficient for controlling a community of benign (i.e., not intentionally malicious) 

authenticated users 

• can provide protection against unsophisticated, technical attacks 

• can not be expected to provide sufficient protection against sophisticated, technical attacks 

(to include denial-of-service) 

Functionality. The CSPP-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 timeof-day and port-of-entry 

• resistance to resource depletion by providing resource allocation features 

• providing mechanisms to detect some insecurities 
CSPP-OS 3 Ver 1.0 – 4/23/03 

• providing mechanisms for trusted recovery in the event of some system failures or detected 

insecurities 

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

CSPP-OS compliant OSs are not expected to – 

• provide the label-based controls appropriate for protecting controlled information (such as 

government classified, company proprietary, or export restricted data) in environments 

containing authenticated users who are not allowed access to such information 

• 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 
CSPP-OS 4 Ver 1.0 – 4/23/03 

2. 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 CSPP-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. 

2.1 PRODUCT CLASS 

CSPP-OS covers general-purpose 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 multiple 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. 

2.2 OPERATIONAL ENVIRONMENT 

The TOE resides within an operational environment. The IT portion of this environment consists 

of the computing system within which the TOE runs and other systems to which this system is 

networked. This IT environment will frequently be referred to as the “system” to differentiate 

between the TOE (operating system) and the other IT around the TOE. 

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 a 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) 
CSPP-OS 5 Ver 1.0 – 4/23/03 

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 

2.3 REQUIRED SECURITY FUNCTIONALITY 

CSPP-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 timeof-day and 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 
CSPP-OS 6 Ver 1.0 – 4/23/03 

3. SECURITY ENVIRONMENT 

3.1 INTRODUCTION 

This section identifies the following: 

• significant assumptions about the operational environment for CSPP-OS compliant OSs 

• organizational security policies for which CSPP-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 CSPP-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. 

Throughout this protection profile, there is a distinction between technical and non-technical. 

Technical measures are those implemented via information technology with an example countermeasure being the access control features of the operating system and an example attack being 

exploitation of a buffer overflow vulnerability. Non-technical measures are those implemented 

outside of the information technology with an example counter-measure being physical 

protections such as locked offices and guarded buildings and an example attack being social 

engineering. 
CSPP-OS 7 Ver 1.0 – 4/23/03 

3.2 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 CSPP-OS 

compliant OSs and essential environmental constraints on the use of compliant TOEs. 

Table 3.2-1 – Security assumptions - TOE 

Name Assumption Discussion 

A.COTS The TOE is constructed from 

near-term achievable, 

commercial off the shelf 

information technology. 

This assumption is a key driver in 

determining the nature of the 

expectations toward, and hence the 

requirements to placed upon, the 

TOE. 

A.MALICIOUS-INSIDER The TOE is not expected to be 

able to sufficiently mitigate the 

risks resulting from malicious 

abuse of authorized privileges. 

It is not reasonable to expect nearterm COTS products to provide 

sufficient protection against the 

malicious actions of authorized 

individuals. 

A.NO-LABELS The TOE does not have to 

provide label-based access 

controls. 

It is an assumption, based upon 

currently available technology and 

current common practice, that label 

based access controls will not be 

included in near-term COTS. 

A.SOPHISTICATEDATTACK The TOE is not expected to be 

able to sufficiently mitigate risks 

resulting from application of 

sophisticated attack methods. 

It is not reasonable to expect nearterm achievable COTS to be able to 

resist sophisticated attacks. 

Table 3.2-2 – Security assumptions - Personnel 

Name Assumption Discussion 

A. ADMIN The security features of the TOE 

are competently administered on 

an on-going basis.

It is essential that security 

administration be both competent 

and on-going. 

A.USER-NEED Authenticated users recognize the 

need for a secure IT 

environment. 

It is essential that the authenticated 

users appreciate the need for 

security. Otherwise they are likely 

to try and circumvent it. 

A.USER-TRUST Authenticated users are generally 

trusted to perform discretionary 

actions in accordance with 

security policies. 

Authenticated users will have a fair 

amount of discretion with CSPP-OS 

systems and must therefore be 

trusted. However, this “trust” is not 

absolute, and hence the phrase 

“generally trusted”. 
CSPP-OS 8 Ver 1.0 – 4/23/03 

3.3 ORGANIZATIONAL SECURITY POLICIES 

The organizational security policies discussed below are addressed by the notional system 

containing CSPP-OS compliant OSs. 

Table 3.3-1 – Security policies 

Name Policy Discussion 

P.ACCESS Access rights to specific data objects 

are determined by object attributes 

assigned to that object, user identity, 

user attributes, and environmental 

conditions as defined by the security 

policy. 

CSPP-OS supports organizational policies which 

grant or deny access to objects using rules driven 

by attributes of the user (such as user identity, 

group, etc.), attributes of the object (such as 

permission bits), type of access (such as read or 

write), and environmental conditions (such as timeof-day). 

P.ACCOUNT Users must be held accountable for 

security-relevant actions. 

CSPP-OS supports organizational policies 

requiring that users are held accountable for their 

actions, facilitating after-the-fact investigations and 

providing some deterrence to improper actions. 

P.COMPLY The implementation and use of the 

organization’s IT systems must 

comply with all applicable laws, 

regulations, and contractual 

agreements imposed on the 

organization. 

The organization will meet all requirements 

imposed upon it from the outside; for example: 

government regulations, national and local laws, 

and contractual agreements. 

P.DUE-CARE The organization’s IT systems must 

be implemented and operated in a 

manner that represents due care and 

diligence with respect to risks to the 

organization. 

It is important that the level of security afforded the 

IT system be in accordance with what is generally 

considered adequate within the business or 

government sector in which the organization is 

placed. 

P.INFO-FLOW Information flow between IT 

components must be in accordance 

with established information flow 

policies. 

CSPP includes information flow control as this is 

needed in many environments. While this might 

not be implemented by mechanisms within the 

CSPP-OS TOE, the IT system, of which the TOE is 

a part, will likely have to meet this policy. 

P.KNOWN Except for a well-defined set of 

allowed operations, users of the TOE 

must be identified and authenticated 

before TOE access can be granted. 

Beyond a well-defined set of actions such as read 

access to a public web-server, there is a finite 

community of known, authenticated users who are 

authenticated before being allowed access. 

P.NETWORK The organization’s IT security policy 

must be maintained in the 

environment of distributed systems 

interconnected via insecure 

networking. 

Since CSPP-OS systems will likely be 

interconnected across untrusted networking, this 

policy statement will have a significant impact on 

CSPP-OS requirement definition. 
CSPP-OS 9 Ver 1.0 – 4/23/03 

Name Policy Discussion 

P.PHYSICAL The processing resources of the TOE 

that must be physically protected in 

order to ensure that security 

objectives are met will be located 

within controlled access facilities 

that mitigate unauthorized, physical 

access. 

A TOE will not be able to meet its security 

requirements unless at least a minimum degree of 

physical security is provided. 

P.SURVIVE The IT system, in conjunction with 

its environment, must be resilient to 

insecurity, resisting the insecurity 

and/or providing the means to detect 

an insecurity and recover from it. 

CSPP-OS systems will provide a measure of this 

resilience through functionality and assurances that 

resist, detect, and recover from insecurities. 

For sophisticated attacks, a large portion of this 

resilience is provided by the TOE environment. 

P.TRAINING Authenticated users of the system 

must be adequately trained, enabling 

them to (1) effectively implement 

organizational security policies with 

respect to their discretionary actions 

and (2) support the need for nondiscretionary controls implemented 

to enforce these policies. 

Once granted legitimate access, authenticated users 

are expected to use IT resources and information 

only in accordance with the organizational security 

policy. In order for this to be possible, these users 

must be adequately trained both to understand the 

purpose and need for security controls and to be 

able to make secure decisions with respect to their 

discretionary actions. 

P.USAGE The organization’s IT resources must 

be used for only for authorized 

purposes. 

CSPP-OS systems must, in conjunction with its 

environment, ensure that the organization’s 

information technology is not used for 

unauthorized purposes. 
CSPP-OS 10 Ver 1.0 – 4/23/03 

3.4 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 CSPP-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 as 

follows: 

 Table 3.4-1 and section 3.4.1: Threats addressed by the environment 

 

 Table 3.4-2 and section 3.4.2: Threats addressed by the TOE 

 Table 3.4-3 and section 3.4.3: Threats addressed jointly by the TOE and its environment 
CSPP-OS 11 Ver 1.0 – 4/23/03 

Table 3.4-1 – Security threats addressed by TOE’s Environment 

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

using non-technical means. 

T.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.AUDIT-CONFIDENTIALITYNon-TOE For audit trails not under control of the TOE, records of security 

events may be disclosed to unauthorized individuals or processes. 

T.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.DENIAL-Non-TOE The IT (other than the TOE) may be subjected to an 

unsophisticated, denial-of-service attack. 

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

attack. 

T.ENTRY-NON-TECHNICAL An individual, other than an authenticated user, may gain access to 

processing resources or information using non-technical means. 

T.ENTRY-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.ENTRY-SOPHISTICATED An individual, other than an authenticated user, may gain access to 

processing resources or information using a sophisticated, technical 

attack. 

T.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.PHYSICAL Security-critical parts of the system may be subjected to a physical 

attack that may compromise security. 

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

recorded. 

T.TRACEABLE-Non-TOE Security relevant events not under control of the TOE may not be 

traceable to the user or system process associated with the event. 
CSPP-OS 12 Ver 1.0 – 4/23/03 

Table 3.4-2 – Security threats addressed by TOE 

Name Threat 

T.ACCESS-TOE 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-TOE For audit trails under control of the TOE, records of security 

events may be disclosed to unauthorized individuals or processes. 

T.AUDIT-CORRUPTED-TOE For audit trails under control of the TOE, records of security 

events may be subjected to unauthorized modification or 

destruction. 

T.CRASH-TOE The secure state of the TOE could be compromised in the event 

of a system crash. 

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

T.ENTRY-TOE An individual other than an authenticated user may gain 

unauthorized, malicious access to TOE controlled processing 

resources or information via an unsophisticated, technical attack. 

T.OBSERVE-TOE 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-TOE 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-TOE Security relevant events controlled by the TOE may not be 

traceable to the user or system process associated with the event. 
CSPP-OS 13 Ver 1.0 – 4/23/03 

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. 

T.SYSTEM-CORRUPTED The security state of the system, as a result of another threat, may be 

intentionally corrupted to enable future insecurities. 
CSPP-OS 14 Ver 1.0 – 4/23/03 

3.4.1 Threats environment addresses 

The threats discussed below must be countered but are not addressed by the technical 

countermeasures within the CSPP-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.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.ACCESS-Non-TOE: An authenticated user may gain unauthorized, non-malicious access to a 

resource or to information not 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. CSPP 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, they 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. CSPP 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.AUDIT-CONFIDENTIALITY-Non-TOE: Records of security events not 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. 
CSPP-OS 15 Ver 1.0 – 4/23/03 

T.AUDIT-CORRUPTED-Non-TOE: Records of security events not under control of the TOE 

may be subjected to unauthorized modification or destruction. 

T.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-ofservice attacks. 

T.DENIAL-SOPHISTICATED: The system may be subjected to a sophisticated, denial-ofservice 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.ENTRY-NON-TECHNICAL: An individual, other than an authenticated user, may gain 

access to processing resources or information using non-technical means. 

T.ENTRY-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. 

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.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.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. 
CSPP-OS 16 Ver 1.0 – 4/23/03 

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

may compromise security. 

The security offered by CSPP 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.RECORD-EVENT-Non-TOE: Security relevant events which IT other than the TOE is 

expected to record may not be recorded. 

T.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. 
CSPP-OS 17 Ver 1.0 – 4/23/03 

3.4.2 Threats TOE addresses 

Technical countermeasures within the CSPP-OS compliant TOE address the threats discussed 

below. 

T.ACCESS-TOE: 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. CSPP-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. CSPP-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-TOE: 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-TOE: Records of security events under control of the TOE may be 

subjected to unauthorized modification or destruction. 
CSPP-OS 18 Ver 1.0 – 4/23/03 

T.CRASH-TOE: 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-TOE: 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-TOE: 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-TOE: 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-TOE: 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-TOE: Due to the TOE, security relevant events may not be traceable to the 

user or system process associated with the event. 
CSPP-OS 19 Ver 1.0 – 4/23/03 

3.4.3 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. 

CSPP-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. 
CSPP-OS 20 Ver 1.0 – 4/23/03 

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.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.) 
CSPP-OS 21 Ver 1.0 – 4/23/03 

3.5 GENERAL ASSURANCE NEED 

CSPP-OS compliant TOEs are targeted for near-term achievable, cost-effective, COTS security. 

In keeping with this target, the general level of assurance for CSPP-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. 

CSPP-OS assurance must also, to enhance wide-spread acceptance, be consistent with current 

and near-term mutual recognition arrangement. This requires that the CSPP-OS assurances: 

• be expressed as an existing evaluation assurance level (EAL) from part 3 of the Common 

Criteria; augmented by CC assurance components as required 

• contain no assurance components first appearing in EAL5 or above 

In keeping with these requirements, the general level of assurance needed for CSPP-OS is EAL2 

augmented to include other vendor actions within the scope of current best commercial practice. 
CSPP-OS 22 Ver 1.0 – 4/23/03 

4. SECURITY OBJECTIVES 

4.1 ENVIRONMENTAL SECURITY OBJECTIVES 

Addressing some policies and threats is beyond the capabilities of the CSPP-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. 

Table 4-1 – Environmental Security Objectives 

Environmental Security Objective Corresponding Threat or Policy 

O.ACCESS-NON-TECHNICAL: The TOE environment must 

provide sufficient protection against non-technical attacks by 

authenticated users for non-malicious 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. 

T.ACCESS-NON-TECHNICAL 

O.ACCESS-Non-TOE: The IT other than 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. 

P.ACCESS 

O.ACCOUNT-Non-TOE: The IT other than the TOE must ensure, 

for actions under its control or knowledge, that all users can 

subsequently be held accountable for their security relevant actions. 

This is expected with a high degree of effectiveness. 

P.ACCOUNT 

T.TRACEABLE-Non-TOE 

T.RECORD-EVENT-Non-TOE 

T.AUDIT-CORRUPTED-NonTOE 

T.AUDIT-CONFIDENTIALITYNon-TOE 

O.AUTHORIZE-Non-TOE: The IT other 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. 

P.ACCESS 
CSPP-OS 23 Ver 1.0 – 4/23/03 

Environmental Security Objective Corresponding Threat or Policy 

O.AVAILABLE-Non-TOE: The IT other than the TOE must 

protect itself from unsophisticated, denial-of-service attacks. This is 

a combination of prevention and detect and recover with a high 

degree of effectiveness.

P.SURVIVE 

T.DENIAL-Non-TOE 

O.BYPASS-Non-TOE: For access not 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 CSPP system are not expected to provide 

sufficient mitigation for the greater negative impact that ‘malicious’ 

implies. 

T.ACCESS-Non-TOE 

O.DENIAL-SOPHISTICATED: The TOE environment must 

maintain system availability in the face of sophisticated denial-ofservice attacks. The focus is on detection and response with a goal 

of moderate effectiveness. 

P.SURVIVE 

T.DENIAL-SOPHISTICATED 

O.DETECT-SOPHISTICATED: The TOE environment must 

provide the ability to detect sophisticated attacks and the results of 

such attacks (e.g., corrupted system state). The goal is for moderate 

effectiveness. 

P.SURVIVE 

T.SYSTEM-CORRUPTED 

O.ENTRY-NON-TECHNICAL: The TOE 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. 

T.ENTRY-NON-TECHNICAL 

O.ENTRY-Non-TOE: For resources not controlled by the TOE, IT 

other than the TOE must prevent logical entry using 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. 

P.USAGE 

T.ENTRY-Non-TOE

O.ENTRY-SOPHISTICATED: The TOE 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. 

T.ENTRY-SOPHISTICATED 

O.INFO-FLOW: The TOE environment must 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. 

P.INFO-FLOW 

O.KNOWN-Non-TOE: The IT other than the 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. 

P.KNOWN 
CSPP-OS 24 Ver 1.0 – 4/23/03 

Environmental Security Objective Corresponding Threat or Policy 

O.OBSERVE-Non-TOE: The IT other than 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. 

T.OBSERVE-Non-TOE 

O.PHYSICAL: Those responsible for the TOE must ensure that 

those parts of the TOE critical to security policy are protected from 

physical attack that might compromise IT security. This will be 

accomplished primarily via prevention with a goal of high 

effectiveness. 

P.PHYSICAL 

T.PHYSICAL 
CSPP-OS 25 Ver 1.0 – 4/23/03 

4.2 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 CSPP-OS compliant TOEs. 

Table 4-2 – TOE Security Objectives 

TOE Security Objective Corresponding Threat or Policy 

O.ACCESS-TOE: The TOE must provide public 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. 

P.ACCESS 

O.ACCOUNT-TOE: The TOE must ensure, for actions under its 

control or knowledge, that all TOE users can subsequently be held 

accountable for their security relevant actions. This will be done with 

moderate effectiveness, in that it is anticipated that individual 

accountability might not be achieved for some actions. 

P.ACCOUNT 

T.TRACEABLE-TOE 

T.RECORD-EVENT-TOE 

T.AUDIT-CORRUPTED-TOE 

T.AUDIT-CONFIDENTIALITYTOE 

O.AUTHORIZE-TOE: 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 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. 

P.ACCESS 

O.AVAILABLE-TOE: The TOE must protect itself from 

unsophisticated, denial-of-service attacks. This will include a 

combination of protection and detection with high effectiveness.

P.SURVIVE 

T.DENIAL-TOE 

O.BYPASS-TOE: The TOE must prevent errant or non-malicious, 

authorized software or users from bypassing or circumventing TOE 

security policy enforcement. This will be accomplished with high 

effectiveness. 

NOTE: This objective is limited to ‘non-malicious’ because CSPP-OS 

controls are not expected to be sufficient mitigation for the greater 

negative impact that ‘malicious’ implies. 

T.ACCESS-TOE 

O.DETECT-TOE: The TOE must enable the detection of TOE 

specific insecurities. The goal is high effectiveness for lower grade 

attacks. 

P.SURVIVE 

T.TOE-CORRUPTED 

O.ENTRY-TOE: The TOE must prevent logical entry to the TOE 

using unsophisticated, technical methods, by persons without authority 

for such access. This will be accomplished with high effectiveness. 

P.USAGE 

T.ENTRY-TOE
CSPP-OS 26 Ver 1.0 – 4/23/03 

TOE Security Objective Corresponding Threat or Policy 

O.KNOWN-TOE: The 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 will 

be accomplished with high effectiveness. 

P.KNOWN 

O.OBSERVE-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. 

T.OBSERVE-TOE 

O.RECOVER-TOE: The TOE must provide for recovery to a secure 

state following a system failure, discontinuity of service, or detection of 

an insecurity. This will be accomplished with a high effectiveness for 

specified failures and a low effectiveness for failures in general. 

P.SURVIVE 

T.CRASH-TOE 

O.RESOURCES: The TOE must protect itself from user or system 

errors that result in shared resource exhaustion. This will be 

accomplished via protection with high effectiveness.

P.SURVIVE 

T.RESOURCES 
CSPP-OS 27 Ver 1.0 – 4/23/03 

4.3 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 

Table 4-3 – Joint TOE/Environment Security Objectives 

Joint Security Objective Corresponding Threat or Policy 

O.ACCESS-MALICIOUS: The TOE controls will 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. 

T.ACCESS-MALICIOUS 

O.COMPLY: The TOE environment, in 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 nontechnical controls to achieve this objective with high effectiveness. 

P.COMPLY 

O.DETECT-SYSTEM: The TOE, in conjunction with other IT in 

the system, must enable the detection of system insecurities. The 

goal is high effectiveness for lower grade attacks. 

P.SURVIVE 

T.SYSTEM-CORRUPTED 

O.DUE-CARE: The TOE environment, in 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. 

P.DUE-CARE 

O.MANAGE: Those responsible for the system (in conjunction with 

mechanisms provided by the TOE) must ensure that it is managed 

and administered in a manner that maintains IT security. This will be 

accomplished with moderate effectiveness. 

T.ADMIN-ERROR 
CSPP-OS 28 Ver 1.0 – 4/23/03 

O.NETWORK: The system must be able to meet its security 

objectives in a distributed environment. This will be accomplished 

with 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 CSPP-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. 

P.NETWORK 

O.OPERATE: Those responsible for the system (in conjunction 

with mechanisms provided by the TOE) must ensure that the system 

is delivered, installed, and operated in a manner which maintains IT 

security. This will be accomplished with moderate effectiveness. 

T.INSTALL 

T.OPERATE 

P.TRAINING 

O.RECOVER-SYSTEM: The system must provide for recovery to 

a secure state following a system failure, discontinuity of service, or 

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. 

P.SURVIVE 

T.CRASH-SYSTEM 
CSPP-OS 29 Ver 1.0 – 4/23/03 

5. FUNCTIONAL SECURITY REQUIREMENTS 

This section contains the functional requirements that must be satisfied by the notional CSPP 

system. These requirements consist of functional components from Part 2 of the CC, in some 

cases with modifications. 

5.1 FUNCTIONAL REQUIREMENTS - TOE 

Table 5-1 lists the functional requirements CSPP-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. 

Table 5-1 – Functional Components - TOE 

Req Number 

CC Component Name 

Extended 

Refined 

ST adds detail 

Objectives function 

helps address 

1 FAU_GEN.1-CSPP Audit data Generation x x x O.ACCOUNT-TOE 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

O.DETECT-TOE 

O.DETECT-SYSTEM 

O.OPERATE 

O.MANAGE 

O.DUE-CARE 

2 FAU_GEN.2 User Identity Generation x O.ACCOUNT-TOE 

3 FAU_SAR.1 Audit Review Required dependency for: 

FAU_SAR.2 

FAU_SAR.3 

4 FAU_SAR.2 Restricted Audit Review O.BYPASS-TOE 

5 FAU_SAR.3 Selectable Audit Review x O.ACCOUNT-TOE 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

O.DETECT-TOE 

O.DETECT-SYSTEM 

O.DUE-CARE 

O.OPERATE 

O.MANAGE 

O.COMPLY 
CSPP-OS 30 Ver 1.0 – 4/23/03 Req Number 

CC Component Name 

Extended 

Refined 

ST adds detail 

Objectives function 

helps address 

6 FAU_SEL.1-CSPP Selective Audit x x O.DUE-CARE 

O.DETECT-TOE 

O.DETECT-SYSTEM 

O.MANAGE 

O.OPERATE 

O.COMPLY 

7 FAU_STG.1-

NIAP-0423 

Protected audit trail storage x O.DETECT-TOE 

O.DETECT-SYSTEM 

O.DUE-CARE 

O.COMPLY 

O.ACCOUNT-TOE 

O.BYPASS-TOE 

8 FAU_STG.3 Action in case of Possible Audit 

Data Loss 

 O.ACCOUNT-TOE 

O.DUE-CARE 

O.MANAGE 

9 FDP_ACC.1 Subset Access Control O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

O.COMPLY 

O.AVAILABLE-TOE 

O.RESOURCES 

10 FDP_ACF.1-CSPP Security Attribute Based Access 

Control 

x x O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

O.COMPLY 

O.AVAILABLE-TOE 

O.RESOURCES 

11 CSPP requirement not applicable 

to this TOE 

 

12 FDP_ETC.1-CSPP Export of user data without 

security attributes 

x O.BYPASS-TOE 

O.DUE-CARE 

O.ENTRY-TOE 

O.AVAILABLE-TOE 

13 CSPP requirement not applicable 

to this TOE 

 

14 CSPP requirement not applicable 

to this TOE 

 

15 FDP_ITC.1 Import of user data without 

security attributes 

 O.NETWORK 
CSPP-OS 31 Ver 1.0 – 4/23/03 Req Number 

CC Component Name 

Extended 

Refined 

ST adds detail 

Objectives function 

helps address 

16 CSPP requirement not applicable 

to this TOE 

 

17 FDP_RIP.1 Subset Residual Information 

protection 

 x x O.BYPASS-TOE 

O.DUE-CARE 

18 CSPP requirement not applicable 

to this TOE 

 

19 FDP_UCT.1 Basic data exchange 

confidentiality 

 x O.NETWORK 

20 FDP_UIT.1 Data exchange integrity x O.NETWORK 

21 FIA_AFL.1-NIAP0425 Authentication Failure Handling x x O.DETECT-TOE 

O.DETECT-SYSTEM 

O.ENTRY-TOE 

O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

22 FIA_ATD.1 User Attribute Definition x x O.AUTHORIZE-TOE 

23 FIA_SOS.1 Verification of Secrets x x O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

24 CSPP requirement not applicable 

to this TOE 

 

25 FIA_UAU.1 Timing of authentication x x O.KNOWN-TOE 

26 FIA_UAU.5 Multiple authentication 

mechanisms 

 x x O.NETWORK 

27 FIA_UAU.6 Re-authenticating x x O.BYPASS-TOE 

28 FIA_UAU.7 Protected authentication feedback x O.BYPASS-TOE 

29 FIA_UID.1 Timing of identification x x O.KNOWN-TOE 

30 FIA_USB.1-NIAP0415 User-Subject Binding O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.DUE-CARE 

O.BYPASS-TOE 

31 FMT_MOF.1 Management of security functions 

behavior 

 x x O.MANAGE 

O.DUE-CARE 

32 FMT_MSA.1 Management of security attributes 

(includes iteration) 

 x x O.MANAGE 

O.DUE-CARE 

O.AUTHORIZE-TOE 

33 FMT_MSA.3-

NIAP-0409 

Static attribute initialization O.MANAGE 

O.DUE-CARE 

O.AUTHORIZE-TOE 
CSPP-OS 32 Ver 1.0 – 4/23/03 Req Number 

CC Component Name 

Extended 

Refined 

ST adds detail 

Objectives function 

helps address 

34 FMT_MTD.1 Management of TSF data x O.MANAGE 

O.DUE-CARE 

35 FMT_SAE.1 Time-Limited Authorization x x O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

O.AUTHORIZE-TOE 

O.MANAGE 

O.DUE-CARE 

36 FMT_SMR.1 Security roles x x O.MANAGE 

O.DUE-CARE 

37 FPT_AMT.1 Abstract Machine Testing x Required dependency for: 

FPT_TST.1 

38 FPT_FLS.1 Failure with preservation of secure 

state 

 x x O.RECOVER-TOE 

O.RECOVER-SYSTEM 

39 FPT_ITC.1-CSPP Inter-TSF Confidentiality During 

Transmission 

x x O.NETWORK 

40 FPT_ITI.1-CSPP Inter-TSF detection of 

modification 

(operations – TBD) 

x x x 

O.NETWORK 

41 CSPP requirement not applicable 

to this TOE 

 

42 FPT_RCV.2-

NIAP-0406 

Recovery from Failure x x O.RECOVER-TOE 

O.RECOVER-SYSTEM 

43 FPT_RPL.1-CSPP Replay detection 

(operations – TBD) 

x x x 

O.NETWORK 

44 FPT_RVM.1 Non-Bypassability of the TSP x O.BYPASS-TOE 

45 FPT_SEP.1 TSF Domain Separation x O.BYPASS-TOE 

O.DUE-CARE 

46 FPT_TDC.1 Inter-TSF basic TSF data 

consistency 

(operations – TBD) 

 x x 

O.NETWORK 

47 CSPP requirement not applicable 

to this TOE 

 

48 FPT_TST.1 TSF Testing x O.DETECT-TOE 

O.DETECT-SYSTEM 

O.DUE-CARE 

49 FRU_RSA.1-CSPP Maximum quotas 

(operations – TBD) 

 x x 

O.RESOURCES 
CSPP-OS 33 Ver 1.0 – 4/23/03 Req Number 

CC Component Name 

Extended 

Refined 

ST adds detail 

Objectives function 

helps address 

50 FTA_LSA.1 Limitation on scope of selectable 

attributes 

(operations – TBD) 

 x x O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

51 FTA_MCS.1-CSPP Basic limitation on multiple 

concurrent session 

x x O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

52 FTA_SSL.1 TSF-initiated session locking O.BYPASS-TOE 

O.DUE-CARE 

53 FTA_SSL.2 User-initiated locking O.OPERATE 

O.BYPASS-TOE 

O.DUE-CARE 

54 FTA_SSL.3 TSF-initiated termination O.BYPASS-TOE 

O.DUE-CARE 

55 FTA_TAB.1-CSPP Default TOE access banners x O.ENTRY-TOE 

O.ACCOUNT-TOE 

O.DUE-CARE 

O.COMPLY 

56 FTA_TAH.1 TOE access history x O.OBSERVE-TOE 

O.ENTRY-TOE 

O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

57 FTA_TSE.1 TOE session establishment 

(operations – TBD) 

 x x O.ACCESS-TOE 

O.ACCESS-MALICIOUS 

O.ENTRY-TOE 

58 FTP_ITC.1-CSPP Inter-TSF trusted channel 

(operations – TBD) 

x x x 

O.NETWORK 

59 CSPP requirement not applicable 

to this TOE 

 

60 Non-CC 

FPT_SYN-CSPP.1 

TSF synchronization 

Component defined in [CSPP] 

FPT_STM.1 changed to be 

synchronization requirements 

(instead of just requiring a 

mechanism that supports it) 

x x 

O.NETWORK 
CSPP-OS 34 Ver 1.0 – 4/23/03 

5.2 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. 

Table 5-2 – Functional Components - IT Environment 

Req Number 

CC Component Name Objectives function helps 

address 

7 FAU_STG.1-

NIAP-0423 

Protected audit trail storage O.DETECT-SYSTEM 

O.DUE-CARE 

O.COMPLY 

O.ACCOUNT-NON-TOE 

O.BYPASS-NON-TOE 

9 FDP_ACC.1 Subset Access Control O.ACCESS-NON-TOE 

O.ENTRY-NON-TOE 

O.DUE-CARE 

O.COMPLY 

O.AVAILABLE-NON-TOE 

17 FDP_RIP.1 Subset Residual Information protection O.BYPASS-NON-TOE 

O.DUE-CARE 

25 FIA_UAU.1 Timing of authentication O.KNOWN-NON-TOE 

27 FIA_UAU.6 Re-authenticating O.BYPASS-NON-TOE 

28 FIA_UAU.7 Protected authentication feedback O.BYPASS-NON-TOE 

31 FMT_MOF.1 Management of security functions behavior O.MANAGE 

O.DUE-CARE 

33 FMT_MSA.3-

NIAP-0409 

Static attribute initialization O.MANAGE 

O.DUE-CARE 

O.AUTHORIZE-NON-TOE 

34 FMT_MTD.1 Management of TSF data O.MANAGE 

O.DUE-CARE 

37 FPT_AMT.1 Abstract Machine Testing Required dependency for: 

FPT_TST.1 

42 FPT_RCV.2-

NIAP-0406 

Recovery from Failure O.RECOVER-SYSTEM 

44 FPT_RVM.1 Non-Bypassability of the TSP O.BYPASS-NON-TOE 

45 FPT_SEP.1 TSF Domain Separation O.BYPASS-NON-TOE 

O.DUE-CARE 
CSPP-OS 35 Ver 1.0 – 4/23/03 Req Number 

CC Component Name Objectives function helps 

address 

56 FTA_TAH.1 TOE access history O.OBSERVE-NON-TOE 

O.ENTRY-NON-TOE 

O.BYPASS-NON-TOE 

O.DUE-CARE 

O.COMPLY 

60 Non-CC 

FPT_SYNCSPP.1 

TSF synchronization 

FPT_STM.1 changed to be synchronization 

requirements (instead of just requiring a 

mechanism that supports it) 

O.NETWORK 

5.3 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 nonIT 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 

 
CSPP-OS 36 Ver 1.0 – 4/23/03 

5.4 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. Both a minimum level for the PP as a whole and specific 

metrics for individual functions are provided. 

Note that, while not probabilistic, SOF metrics have been given for FAU_STG.1-NIAP-0423, 

FDP_RIP.1, FMT_MTD.1, and FPT_SEP.1. This extension of the CC with respect to SOF, is 

being used as a convenient means of capturing all “strength” elements in a common location of 

the PP. 

5.4.1 Minimum SOF Requirement 

As the goal for CSPP-OS is near-term achievable COTS, the appropriate minimum SOF level is 

BASIC. 

5.4.2 Specific SOF Requirements - TOE 

The specific required strength metrics for the functional components are given in Table 5-3. 

Table 5-3 – SOF Metrics - TOE 

# CC Component Name Explicit SOF Metric 

19 FDP_UCT.1 Basic data exchange confidentiality support equivalent or 

stronger: 1024 bit key 

exchange and triple DES or 

better (as well as weaker 

values as required by 

import/export restrictions) 

20 FDP_UIT.1 Data exchange integrity MD5 or stronger checksums 

will be used 

23 FIA_SOS.1 Verification of Secrets FIPS PUB 112 

39 FPT_ITC.1-CSPP Inter-TSF Confidentiality During 

Transmission 

support equivalent, or 

stronger: 1024 bit key 

exchange and triple DES (as 

well as weaker values as 

required by import/export 

restrictions) 

40 FPT_ITI.1-CSPP Inter-TSF detection of modification MD5 equivalent or stronger 

checksums will be used 

45 FPT_SEP.1 TSF Domain Separation use underlying hardware 

ring structure to separate, at 

a minimum, kernel space 

from application space 
CSPP-OS 37 Ver 1.0 – 4/23/03 

# CC Component Name Explicit SOF Metric 

48 FPT_TST.1 TSF Testing MD5 or stronger checksums 

will be used 
CSPP-OS 38 Ver 1.0 – 4/23/03 

5.4.3 Specific SOF Metrics - IT Environment 

Table 5-4 gives the SOF metrics for functional requirements placed on the IT-environment. 

Table 5-4 – SOF Metrics - IT Environment 

# CC Component Name Explicit SOF Metric 

7 FAU_STG.1-

NIAP-0423 

Protected audit trail storage provide a hardware protected 

copy of the audit trail, 

allowing 'append' as the only 

write access 

17 FDP_RIP.1 Subset Residual Information protection applications will take 

advantage of OS supplied 

mechanisms 

34 FMT_MTD.1 Management of TSF data include operating system 

access controls in controlling 

access to TSF critical data 

45 FPT_SEP.1 TSF Domain Separation use underlying hardware 

ring structure to separate, at 

a minimum, kernel space 

from application space 
CSPP-OS 39 Ver 1.0 – 4/23/03 

6. ASSURANCE REQUIREMENTS 

The assurance requirements for CSPP-OS are met by an augmented EAL2 that is henceforth 

termed evaluation assurance level – CSPP (EAL-CSPP). EAL-CSPP stresses assurance through 

vendor actions that are within the bounds of current best-commercial-practice. EAL-CSPP 

provides, primarily via review of vendor supplied evidence, independent confirmation that these 

actions have been competently performed. EAL-CSPP 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 EAL-CSPP are summarized in Table 6-1. Appendix C gives the 

details of these assurance components. Table 6-2 lists those components of EAL-CSPP that 

augment EAL2 from part 3 of the CC. 

Table 6-1 – EAL-CSPP Assurance Components 

Assurance Class Component ID Component Title 

Configuration Management ACM_CAP.3 Authorization controls 

ACM_SCP.2 Problem tracking CM Coverage 

Delivery and Operation ADO_DEL.1 Delivery procedures 

ADO_IGS.1 Installation, Generation, and Start-up Procedures 

ADV_FSP.1 Informal functional specification 

ADV_HLD.1 Descriptive High-Level Design 

ADV_RCR.1 Informal Correspondence Demonstration 

Development 

ADV_SPM.1 Informal TOE security policy model 

Guidance Documents AGD_ADM.1 Administrator Guidance 

AGD_USR.1 User Guidance 

Life Cycle Support ALC_DVS.1 Identification of Security Measures 

ALC_FLR.2 Flaw reporting procedures 

ATE_COV.2 Analysis of coverage 

ATE_DPT.1 Testing - High-Level Design 

ATE_FUN.1 Functional Testing 

Tests 

ATE_IND.2 Independent Testing - Sample 

AVA_MSU.2 Validation of Analysis 

AVA_SOF.1 Strength of TOE Security Function Evaluation 

Vulnerability Assessment 

 

AVA_VLA.1 Developer vulnerability Analysis 
CSPP-OS 40 Ver 1.0 – 4/23/03 

Table 6-2 – EAL-CSPP augmentation to EAL-2 

EAL2 EAL-CSPP Nature of Augmentation to EAL2 

ACM_CAP.2 ACM_CAP.3 • requires a CM plan 

• describe how plan is used 

• provide evidence that 

− CM is operating in accordance with plan 

− configuration items are being effectively maintained 

− only authorized changes are made to configuration items 

none ACM_SCP.2 • CM documentation shows that CM system tracks 

− TOE implementation 

− design documentation 

− test documentation 

− user and administrator documentation 

− CM documentation 

− security flaws 

• CM documentation describes how configuration items are 

tracked 

none ADV_SPM.1 • provide an informal TOE security policy model that 

− describes rules and characteristics of all policies that can be 

modeled. 

− includes a rationale demonstrating consistency and 

completeness with respect to these policies 

• show consistency and completeness between all security 

functions in the functional specification and the model 

none ALC_DVS.1 • produce developmental security documentation that 

− describes the security measures necessary {in the opinion of 

the developer} to provide, for the TOE design and 

implementation, what confidentiality and integrity the 

developer considers necessary 

− provides evidence that these measures are being followed 

during TOE development and maintenance 

• evaluator confirms that the security measures identified are 

being applied 

Note: The evaluator does not, at ALC_DVS.1, confirm that the list 

of security measures in adequate. That is added at the next higher 

component (ALC_DVS.2). 
CSPP-OS 41 Ver 1.0 – 4/23/03 

EAL2 EAL-CSPP Nature of Augmentation to EAL2 

none ALC_FLR.2 • establish procedure for accepting and action upon user reports of 

security flaws 

• document flaw remediation procedures 

− describing procedures used to track security flaws 

− describing methods to provide flaw information, 

corrections, and guidance to users 

− requiring that description of and effect of flaw be provided 

− requiring that corrective actions be identified and correction 

status be provided 

− ensuring that reported flaws are corrected and corrections 

issued to users 

− providing safeguards that any corrections do not introduce 

new flaws 

ATE_COV.1 ATE_COV.2 • requirement for developer analysis of test coverage 

− changing, for correspondence between test coverage and the 

functional specification, “evidence ... show” to “analysis ... 

demonstrate” 

• requirement that the coverage is ‘complete’ 

none ATE_DPT.1 • requirement for developer analysis of test depth 

− depth sufficient to demonstrate operates in accordance with 

high-level design 

none AVA_MSU.2 • requirements placed upon guidance documentation 

− identify all possible modes of operation, their consequences 

and implications toward secure operation 

− be complete, clear, consistent, and reasonable 

− list all assumptions about the intended environment 

− list all requirements for external security measures 

• developer analysis of guidance documentation for completeness 

• evaluator confirmation of analysis of documentation 

completeness 
CSPP-OS 42 Ver 1.0 – 4/23/03 

7. APPLICATION NOTES 

7.1 EVALUATION SCOPE, DEPTH, AND RIGOR. 

In lieu of extensive, independent analysis, CSPP-OS intends the evaluator to: 

a. Review developer supplied evidence to make a determination on: 

i) the competence of the vendor 

ii) the apparent correctness and completeness of the required security actions 

b. Approach all requirements to ensure “all”, “any”, or “none” as generic CC requirements 

to be interpreted loosely when applied to this lower assurance evaluation. 

c. Be consciously aware that there is a point at which more evaluation is not cost-effective; 

keeping in mind that CSPP-OS is a lower assurance, lower cost, basic level of security. 

This intention to limit independent analysis directly applies to the following assurance elements: 

a. ADV_FSP.1.2E The evaluator shall determine that the functional specification is an 

accurate and complete instantiation of the TOE security functional requirements. 

b. ADV_HLD.1.2E The evaluator shall determine that the high-level design is an 

accurate and complete instantiation of the TOE security functional requirements. 

c. ADV_IND.2.2E The evaluator shall test the TSF to confirm that the TSF operates 

as specified. 

d. AVA_MSU.2.3E The evaluator shall determine that the use of the guidance 

documentation allows all insecure states to be detected. 

e. AVA_MSU.2.4E The evaluator shall confirm that the analysis shows that guidance 

is provided for secure operation in all modes of operation of the TOE. 

f. AVA_SOF.1.2E The evaluator shall confirm that the strength claims are correct. 

g. AMA_CAT.1.2E The evaluator shall confirm that the categorization of TOE 

components and tools, and the categorization scheme used, are appropriate and consistent 

with the evaluation results for the certified version. 

8. RATIONALE 

The rationale for this PP guidance is found in [CSPP-OS-R]. 

9. REFERENCES 

[CC-V2.1] Common Criteria for Information Technology Security Evaluation, Version 2.1, 

August 1999. 

[CSPP] CSPP - Guidance for COTS Security Protection Profiles, version 1.0, December 

1999. 

[CSPP-OS-R] Rationale for COTS Security Protection Profile - Operating Systems (CSPP-OSR), version 1.0, April 2003.
CSPP-OS A-1 Ver 1.0 – 4/23/03 

A. APPENDIX A: ACRONYMS 

CC Common Criteria [for IT Security Evaluation] 

COTS Commercial Off The Shelf 

EAL Evaluation Assurance Level 

IT Information Technology 

NIST National Institute of Standards and Technology 

PP Protection Profile 

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 
CSPP-OS B-1 Ver 1.0 – 4/23/03 

B. APPENDIX B: TOE FUNCTIONAL REQUIREMENT DETAILS 

B.1 COMMON SYNTAX 

Throughout this section the following terminology is used: 

 Completed operations: 

 Selection: [selection: selection made] 

 Assignment: [assignment: assignment made] 

 Refinement: refinement made

 Extension: either [extension: extension made] or title indicating following is an 

extension 

 Deferred operations are shown in italics, for example: 

 Deferred assignment: [ST assignment: description of operation to be performed]

B.2 CSPP ACCESS CONTROL SECURITY FUNCTION POLICY (SFP) 

The TOE shall support the administration and enforcement of the an access control SFP that 

provides at least the equivalent of the following two capabilities described below, in accordance 

with the precedence rules indicated. 

B.2.1 Discretionary Access Control 

 Subjects (human users operating through software processes and software processes 

running as system processes) will be granted access to objects (files) based upon authorizations 

associated with the object being accessed, the name of the subject requesting access, the type of 

access requested, and the nature of the access request. 

 Authorizations associated with each object define allowed accesses by: 

 Subject identification: 

 Multiple individuals with potentially different access authorizations 

 Multiple subject groups with potentially different access authorizations 

 Access type, with explicit allow or deny: 

 Read 

 Write 

 Execute 

 Nature of access: 

 Time of day 

 Port of entry 

 For each object, an explicit owning subject (or group of subjects) will be identified. 
CSPP-OS B-2 Ver 1.0 – 4/23/03 

 For each object, the assignment and management of authorizations will be the 

responsibility of the owner of that object and, if the implementation allows, other subjects may 

be explicitly granted the privilege of modifying the object’s authorizations. 

 The system is allowed to provide a privileged user or user role that can bypass all access 

controls; for example the Unix ‘root’ or NT ‘administrator’. 

B.2.2 Non-discretionary Access Controls 

 a. The ability of a software process to access key system resources; for example external 

ports, input output capabilities, and operating system data structures; will be restricted based 

upon the assigned processing level of the process within a multiple ring architecture of the 

underlying hardware platform. A compliant security target will include a definition of key 

resources and a justification for the operating system architecture, displaying how allocation of 

OS processes and user processes between ring levels enforces non-discretionary access controls 

to key resources. 

 b. System level access controls set by explicitly authorized users such as a security 

adminstrator, and not modifiable by the asset owner. These include controls related to: 

 Nature of access, for example: 

 Time of day 

 Port of entry 

 Authentication mechanism(s) required 

B.2.3 CSPP Access Control Precedence Rules 

 CSPP-OS compliant TOEs will determine allowed access for a specific subject to a 

specific object according to these precedence of rules: 

 1) If the requested mode of access is denied to that subject, deny access. 

 2) If the requested mode of access is permitted to that subject, permit access. 

 3) If the requested mode of access is denied to every group of which the user is a 

member, deny access 

 4) If the requested mode of access is permitted to any group of which the user is a 

member, grant access 

 5) If the requested mode of access is denied to public, deny access 

 6) If the requested mode of access is permitted to public, grant access 

 7) Else deny access. 
CSPP-OS B-3 Ver 1.0 – 4/23/03 

B.3 AUDIT (FAU) 

B.3.1 FAU_GEN.1-CSPP Audit data generation 

Dependencies: FPT_STM.1 (FPT_SYN-CSPP.1) 

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable 

events: 

a) Start-up and shutdown of the audit functions; 

b) All auditable events relevant for the [selection: basic] level of audit; and 

c) [assignment: 

 (1) for FPT_ITI.1 and FPT_RPL.1, the ability to provide statistical data representing the 

frequency of occurrence and 

 (2) other auditable events specific to the ST design as listed in the following ST assignment: 

[ST assignment: any other audit events required by specifics of the ST design in order to meet 

PP requirements.]] The ST rationale shall provide a basic justification, showing that the ST 

assignment, to include a “null” assignment, is complete. 

FAU_GEN.1.2-NIAP-0347 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 (human user/software process, if 

applicable), and the outcome (success or failure) of the event; and 

b) For each audit event type, based on the auditable event definitions of the functional 

components included in the PP/ST, [selection: no other information]. 

Extension: 

FAU_GEN.1-CSPP.3 When the TSF provides application support it shall support an 

application program interface (API) that allows a privileged application to append data to the 

security audit trail or to an application-specified alternative security audit trail. 

Refinement: See text in FAU_GEN.1.1 and FAU_GEN.1.2 

B.3.2 FAU_GEN.2-NIAP-0410 User identity generation 

Dependencies: FAU_GEN.1-CSPP, FIA_UID.1 

FAU_GEN.2.1-NIAP-0410 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 that caused the event. 

Refinement: See text of FAU_GEN.2.1-NIAP-0410 
CSPP-OS B-4 Ver 1.0 – 4/23/03 

B.3.3 FAU_SAR.1 Audit review 

Dependencies: FAU_GEN.1-CSPP 

FAU_SAR.1.1 The TSF shall provide [assignment: explicitly authorized user roles, user 

groups, or individually identified users] with the capability to read [assignment: all information 

in the audit records] 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. 

B.3.4 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. 

B.3.5 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, and

ordering] of audit data based upon [assignment: at a minimum, date and time of the event, 

subject (user or process), type of event, and success or failure]. 

Refinement: See text of FAU_SAR.3.1 

B.3.6 FAU_SEL.1-CSPP Selective audit 

Dependencies: FAU_GEN.1-CSPP 

 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) [selection: Object identity, user identity, subject identity, host identity, and/or event type]; 

b) [assignment: success or failure.] 

Extension:

FAU_SEL.1-CSPP.2 The TSF shall provide only explicitly authorized user roles, user groups, 

or individually identified users with the ability to select or display which events are to be 

audited. 

FAU_SEL.1-CSPP.3 The TSF shall provide the capability of FAU_SEL.1-CSPP.2 at any time 

during the operation of the TOE. 
CSPP-OS B-5 Ver 1.0 – 4/23/03 

Refinement: See text of FAU_SEL1.1 

B.3.7 FAU_STG.1-NIAP-0423 Protected audit trail storage 

Dependencies: FAU_GEN.1-CSPP 

FAU_STG.1.1-NIAP-0423 The TSF shall protect the stored audit records in the audit trail from 

unauthorized deletion. 

FAU_STG.1.2-NIAP-0423 The TSF shall be able to [selection: prevent and detect] unauthorized 

modifications to the audit records in the audit trail. 

Refinement: See text in FAU_STG.1.2-NIAP-0423 

B.3.8 FAU_STG.3 Action in case of possible audit data loss 

Dependencies: FAU_STG.1-NIAP-0423 

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

B.4 USER DATA PROTECTION (FDP) 

B.4.1 FDP_ACC.1 Subset access control 

Dependencies: FDP_ACF.1-CSPP 

FDP_ACC.1.1 The TSF shall enforce the [assignment: CSPP access control SFP] on 

[assignment: all subjects, all operating system controlled files (to include all communications 

mechanisms – for internal or external communications – that are implemented as objects 

controlled by the file system), and all access requests to these files]. 
CSPP-OS B-6 Ver 1.0 – 4/23/03 

B.4.2 FDP_ACF.1-CSPP Security attribute based access control 

Dependencies: FDP_ACC.1, FMT_MSA.3-NIAP-0409

FDP_ACF.1.1-NIAP-0416 The TSF shall enforce the [assignment: CSPP access control SFP] 

to objects based on the following: [assignment: for the subjects and objects identified in 

FDP_ACC.1.1, the user/process identity, group membership, subject privileges, and, if included 

in the object authorization information, access restrictions such as the time-of-day and port-ofentry]. 

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: by checking the 

authorizations associated with the object for the entries of that subject]. 

FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the 

following additional rules: [assignment: none]. 

FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the 

following additional rules: [assignment: none]. 

Extension: 

FDP_ACF.1-CSPP.5 The TSF shall provide the capability to assign a user to be a member of 

more than one user group simultaneously. 

FDP_ACF.1-CSPP.6 The TSF shall enforce the rules for authorizing and denying access 

based upon the CSPP precedence rules. 

Refinement: See text in FDP_ACF.1.4 

B.4.3 FDP_ETC.1-CSPP Export of user data without security attributes 

Dependencies: FDP_ACC.1 or- FDP_IFC.1 

FDP_ETC.1.1 The TSF shall enforce the [assignment: CSPP access control SFP] when 

exporting user data, controlled under the SFP(s), outside of the TSC. 

FDP_ETC.1.2 The TSF shall export the user data without the user data’s associated security 

attributes. 

Extension: 

FDP_ETC.1-CSPP.3 The TSF shall shall provide for outgoing information channels, for example 

TCP port numbers, that are under the control of the TSF and for which general application 

programs do not have access, when exporting user data controlled under the SFP outside the 

TSC. 
CSPP-OS B-7 Ver 1.0 – 4/23/03 

B.4.4 FDP_ITC.1 Import of user data without security attributes 

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

FDP_ITC.1.1 The TSF shall enforce the [assignment: CSPP access control] when importing 

user data, controlled under the SFP, from outside the TSC. 

FDP_ITC.1.2 The TSF shall ignore the security attributes associated with the user data when 

imported from outside the TSC. 

FDP_ITC.1.3 The TSF shall enforce the following the following rules when importing user data 

controlled under the SFP from outside the TSC: [assignment: the TOE shall provide for 

incoming information channels, for example TCP port numbers, that are under the control of the 

TSF and for which general application programs do not have access]. 

B.4.5 FDP_RIP.1 Subset residual information protection 

Dependencies: None 

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

unavailable upon the [assignment: following: [ST selection: allocation of the resource to, 

deallocation of the resource from, both]] the following objects [assignment: shared memory and 

file storage space]. The ST rationale shall provide a basic justification, showing that the ST 

selection is consistent with other aspects of the ST design, resulting in a secure solution.

Refinement: See text in FDP_RIP.1.1 

B.4.6 FDP_UCT.1 Basic data exchange confidentiality 

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

FDP_UCT.1.1 The TSF shall support the enforcement of the [assignment: CSPP 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 
CSPP-OS B-8 Ver 1.0 – 4/23/03 

B.4.7 FDP_UIT.1 Data exchange integrity 

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

FDP_UIT.1.1 The TSF shall support the enforcement of the [assignment: CSPP access control 

SFP] to be able to [selection: transmit and receive] user data in a manner protected from 

[selection: modification, deletion, insertion, and replay] errors. 

FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether [selection: 

modification, deletion, insertion, or replay] has occurred. 

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

B.5 IDENTIFICATION AND AUTHENTICATION (FIA) 

B.5.1 FIA_AFL.1-NIAP-0425 Authentication failure handling 

Dependencies: FIA_UAU.1 

FIA_AFL.1.1-NIAP-0425 The TSF shall detect when [selection: an authorized administrator 

configurable integer] unsuccessful authentication attempts over an authorized user configurable 

length of time occur related to [assignment: initial account login, re-authentication after initial 

login, and list of other events given in the following ST assignment: [ST assignment: as 

required by PP, list of ST specific authentication events]]. The ST rationale shall provide a basic 

justification that the ST assignment, including a “null” assignment, includes all events specific to 

the ST design that require authentication failure handling.

FIA_AFL.1.2 After the defined number of unsuccessful authentication attempts has been met or 

surpassed, the TSF shall [assignment: perform the following ST selected actions: [ST selection:

disable the account (requiring it to be re-enabled by an authorized user), cause each subsequent 

logon attempt to be delayed for increasing periods of time up to a maximum number of 

additional attempts at which time the account is disabled pending authorized user action to reenable, allow either option based upon a configuration choice by an authorized user] ]. As any 

selection, other than “null”, is acceptable and the purpose here is to ensure that an explicit choice 

is both made and announced, the ST rationale need not justify the choice made.

Refinement: See text of FIA_AFL.1.1-NIAP-0425 and FIA_AFL.1.2 
CSPP-OS B-9 Ver 1.0 – 4/23/03 

B.5.2 FIA_ATD.1 User attribute definition 

Dependencies: None 

FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to 

individual users: [assignment: user name, authenticator and the following ST specific attributes 

required by the design of the ST: [ST assignment: as required by PP, list of any ST specific 

security attributes]]. The ST rationale shall provide a basic justification for the assignment 

made, including “null”, showing that it is the complete list required to maintain secure operation.

Refinement: See text in FIA_ATD.1.1 

B.5.3 FIA_SOS.1 Verification of secrets 

Dependencies: None 

FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [assignment: for 

passwords, the application note below and the requirements of FIPS PUB 112; for other secrets 

specific to the ST design, the metrics called out in the following ST assignment: [ST 

assignment: as required by PP, any ST specific, defined quality metrics]]. The ST rationale 

shall provide a basic justification that the ST assignment covers all ST specific secrets essential 

for secure operation and that the metric(s) given are appropriate for meeting the PP design goals.

Refinement: See text in FIA_SOS.1.1 

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. 
CSPP-OS B-10 Ver 1.0 – 4/23/03 

B.5.4 FIA_UAU.1 Timing of authentication 

Dependencies: FIA_UID.1 

FIA_UAU.1.1 The TSF shall allow [assignment: no actions other than anonymous access to 

resources explicitly authorized for the type of anonymous access requested and the following ST 

selection [ST selection: as permitted by PP, local shut down of the operating system]] on behalf 

of the user to be performed before the user is authenticated. As the inclusion of this action is 

permitted, but not required, and the purpose here is only to ensure that the ST choice is explicit, 

the ST rationale does not need to include a justification for the choice made.

FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing 

any other TSF-mediated actions on behalf of the user. 

Refinement: See text in FIA_UAU.1.1 

B.5.5 FIA_UAU.5 Multiple authentication mechanisms 

Dependencies: None 

FIA_UAU.5.1 The TSF shall provide support for [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.

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

B.5.6 FIA_UAU.6 Re -authentication 

Dependencies: None 

FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [assignment: reestablishing 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.

Refinement: See text in FIA_UAU.6.1 
CSPP-OS B-11 Ver 1.0 – 4/23/03 

B.5.7 FIA_UAU.7 Protected authentication feedback 

Dependencies: FIA_UAU.1 

FIA_UAU.7.1 The TSF shall not provide [assignment: any indication of success or failure nor 

clear-text display of any secret authenticator] to the user while the authentication is in progress. 

Refinement: See text in FIA_UAU.7.1 

B.5.8 FIA_UID.1 Timing of identification 

Dependencies: None 

FIA_UID.1.1 The TSF shall allow [assignment: no actions other than anonymous access to 

resources explicitly authorized for the type of anonymous access requested and the following ST 

selection [ST selection: as allowed by PP, local shut down of the operating system]] on behalf of 

the user to be performed before the user is identified. As the operation is permitted rather than 

required, and the purpose here is to ensure that the choice is explicit, the ST rationale does not 

need to include a justification for the choice made.

FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any 

other TSF-mediated actions on behalf of that user. 

Refinement: See text in FIA_UID.1.1 

B.5.9 FIA_USB.1-NIAP-0415 User-subject binding 

Dependencies: FIA_ATD.1 

FIA_USB.1.1-NIAP-0415 The TSF shall associate the following user security attributes with 

subjects acting on behalf of that user: [assignment: all user security attributes required to enforce 

access control and information flow control policies and to fully meet goals for individual 

accountability]. 
CSPP-OS B-12 Ver 1.0 – 4/23/03 

B.6 SECURITY MANAGEMENT (FMT) 

B.6.1 FMT_MOF.1 Management of security functions behavior 

Dependencies: FMT_SMR.1 

FMT_MOF.1.1 The TSF shall restrict the ability to [selection: determine the behaviour of, 

disable, enable, modify the behavior of] the functions [assignment: included as requirements for 

CSPP-OS and for which the common criteria indicates security management suggestions, and 

also all items listed in the following ST assignment: [ST assignment: as required by PP, list of 

ST functions and mechanisms resulting from specifics of the ST design]] 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]]. The ST 

rationale must provide a basic justification for the assignment made, to include “null”. The ST 

rationale must also provide a basic justification for the selection made, indicating how it supports 

enforcement of least privilege.

Refinement: See text in FMT_MOF.1.1 

B.6.2 FMT_MSA.1 Management of security attributes 

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

FMT_MSA.1.1 The TSF shall enforce the [assignment: CSPP access control SFP] to restrict 

the ability to [selection: change_default, modify, delete] and [assignment: “null”] the security 

attributes [assignment: all attributes used to define the security state of the system, to control the 

security functionality, to make access control decisions, and those listed in the following ST 

assignment: [ST assignment: as required by PP, list of security attributes requiring management 

and arising from the specifics of the ST design]] to [assignment: for discretionary attributes, the 

owner of the attribute; for both discretionary and non-discretionary attributes, an explicitly 

specified set of users, enforcing least privilege on the basis of the following ST selection: and 

[ST selection: security administrators, security administrator roles, both]]. The ST rationale 

shall provide a basic rationale for the assignment made, showing it to be complete. Also, the ST 

rationale shall provide a basic justification for the selection made, indicating how it enforces 

least privilege. See iteration for restriction on read access to authenticator values. 

Iteration: 

FMT_MSA.1.1 The TSF shall enforce the [assignment: CSPP access control SFP] to restrict 

the ability to [selection: query] [assignment: “null”] the security attributes [assignment: current 

and past values of authenticators, ] to [assignment: no users and only to software processes 

requiring this knowledge]. 

Application note: An example of a processes requiring this information is a password change 

function which will query for current password and must make a determination as to whether the 

password entered is correct. 

Refinement: See text in first iteration of FMT_MSA.1.1 
CSPP-OS B-13 Ver 1.0 – 4/23/03 

B.6.3 FMT_MSA.3-NIAP-0409 Static attribute initialization 

Dependencies: -FMT_MSA.1, FMT_SMR.1 

FMT_MSA.3.1-NIAP-0409 The TSF shall enforce the [assignment: CSPP access control SFP] 

to provide [selection: restrictive] default values for object security attributes that are used to 

enforce the SFP. 

FMT_MSA.3.2 The TSF shall allow the [assignment: data object owner and other authorized 

users] to specify alternate initial values to override the default values when an object or 

information is created. 

B.6.4 FMT_MTD.1 Management of TSF data 

Dependencies: FMT_SMR.1 

FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default, read, modify, 

delete, or clear] the [assignment: all internal TSF data structures that are security critical] to 

[assignment: software processes explicitly authorized to access this data]. 

Refinement: See text in FMT_MTD.1.1 

B.6.5 FMT_SAE.1 Time-limited authorization 

Dependencies: FMT_SMR.1, FMT_STM.1 (FMT_CSPP-OS.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]]. 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,

indicating how it enforces least privilege.

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. The ST rationale shall provide a basic justification for the assignment made, 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 
CSPP-OS B-14 Ver 1.0 – 4/23/03 

B.6.6 FMT_SMR.1 Security roles 

Dependencies: FIA_UID.1 

FMT_SMR.1.1 The TSF shall maintain the roles [assignment: privileged user (for example the 

equivalent of the Unix root) and/or the following set of ST specific roles that the ST author 

wishes to specify as not conflicting with CSPP goals and useful in implementing these goals: 

[ST assignment: as allowed by PP, the ST specific authorized identified roles]]. The ST 

rationale shall provide a basic justification for the assignment made, showing that the roles 

specified do not conflict with PP design goals.

FMT_SMR.1.2 The TSF shall be able to associate users the roles. 

Refinement: See text in FMT_SMR.1.1 

B.7 PROTECTION OF TRUSTED SECURITY (FPT) 

B.7.1 FPT_AMT.1 Abstract machine testing 

Dependencies: None 

FPT_AMT.1.1 The TSF shall run a suite of tests [selection: during initial start-up and at the 

request of explicitly authorized security administrator(s) or security administrator role(s)] to 

demonstrate the correct operation of the security assumptions provided by the abstract machine 

which underlies the TSF. 

Refinement: See text in FPT_AMT.1.1 

B.7.2 FPT_FLS.1 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]]. 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 
CSPP-OS B-15 Ver 1.0 – 4/23/03 

B.7.3 FPT_ITC.1-CSPP Inter-TSF confidentiality during transmission 

Dependencies: None 

FPT_ITC.1.1-CSPP The TSF shall support the protection of [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-CSPP 

Extension: See text of FPT_ITC.1.1-CSPP 

B.7.4 FPT_ITI.1-CSPP Inter-TSF detection of modification 

Dependencies: None 

FPT_ITI.1.1-CSPP The TSF shall support 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.] 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-CSPP The TSF shall support 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. 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-CSPP and FPT_ITI.1.2-CSPP 

Extension: See text in FPT_ITI.1.1-CSPP and FPT_ITI.1.2-CSPP 
CSPP-OS B-16 Ver 1.0 – 4/23/03 

B.7.5 FPT_RCV.2-NIAP-0406 Recovery from Failure 

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

FPT_RCV.2.1-NIAP-0406 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. 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-NIAP-0406 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-NIAP-0406 

B.7.6 FPT_RPL.1-CSPP Replay detection 

Dependencies: None 

FPT_RPL.1.1-CSPP The TSF shall detect replay for the following entities [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]]. The ST rationale 

shall provide a basic justification, showing that the ST assignment is complete. It is acceptable 

to protect all communications, rather than selecting specific entities. 

FPT_RPL.1.2 The TSF shall perform [assignment: the action of discarding duplicates and 

providing the capability to audit this action in a statistical manner] when replay is detected. 

Refinement: See text in FPT_RPL.1.1-CSPP 

Extension: See text in FPT_RPL.1.1-CS 

B.7.7 FPT_RVM.1 Non-bypassability of the TSP 

Dependencies: None 

FPT_RVM.1.1 The TSF shall ensure, to at least a level of confidence appropriate for a lowerlevel of assurance (i.e., EAL-CSPP), that 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 
CSPP-OS B-17 Ver 1.0 – 4/23/03 

B.7.8 FPT_SEP.1 TSF domain separation 

Dependencies: None 

FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that protects, at 

least to the extent such protection can be reasonably expected from a lower-level of assurance 

(i.e., EAL-CSPP), 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 

B.7.9 FPT_TDC.1 Inter-TSF basic TSF data consistency 

Dependencies: None 

FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [assignment:

information critical to security in maintaining a consistent state representation across distributed 

systems as identified in [ST assignment: list of TSF data types] when shared between the TSF 

and another trusted IT product. The ST rationale shall provide a basic justification, showing that 

the ST assignment is complete. It is acceptable to provide a broader definition, rather than 

selecting only a subset - provided the rationale shows that the security critical elements are 

indeed a subset of those chosen. 

FPT_TDC.1.2 The TSF shall use [assignment: the following interpretation rules: [ST 

assignment: list of interpretation rules to be applied by the TSF] when interpreting the TSF data 

from another trusted IT product. The ST rationale shall provide a basic justification, showing 

that the list of rules is comprehensive and internally self-consistent.

Refinement - See text in FPT_TDC.1.1, FPT_TDC.1.2, and this added element (clarifying 

intent): 

FPT_TDC.1.3-CSPP The TSF shall support maintaining consistent data between this TSF 

and another trusted IT product for the data items specified in FPT_TDC.1.1 in accordance 

with the rules specified in FPT_TDC.1.2. 
CSPP-OS B-18 Ver 1.0 – 4/23/03 

B.7.10 FPT_TST.1 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 at the 

request of explicitly authorized security administrator(s) or security administrator role(s)] 

[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 

B.7.11 FPT_SYN-CSPP.1 TSF synchronization 

Non-CC component defined in [CSPP] 

Extension: 

Not hierarchical to any other component. 

Dependencies: None 

FPT_SYN-CSPP.1.1 The TSF shall support the system capability to provide the capability 

to synchronize distributed TSF elements and to associate audit event records produced by 

multiple TSF entities. 

Refinement (to CSPP component): See FPT_SYN-CSPP.1.1 in [CSPP]. 

Application note: This component is similar to FPT_STM “Time stamps”, but calls out the 

synchronization requirement instead of a specifying a mechanism (i.e., reliable time stamps”) 

that could be used for that purpose. 
CSPP-OS B-19 Ver 1.0 – 4/23/03 

B.8 RESOURCE UTILIZATION (FRU) 

B.8.1 FRU_RSA.1-CSPP Maximum quotas 

Dependencies: None 

FRU_RSA.1.1-CSPP 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]. 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-CSPP 

B.9 TOE ACCESS (FTA) 

B.9.1 FTA_LSA.1 Limitation on scope of selectable attributes 

Dependencies: None 

FTA_LSA.1.1 The TSF shall provide the capability to restrict the scope of these session security 

attributes: [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]]. 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 

B.9.2 FTA_MCS.1-CSPP Basic limitation on multiple concurrent sessions 

Dependencies: FIA_UID.1 

FTA_MCS.1.1-CSPP 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, 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-CSPP 
CSPP-OS B-20 Ver 1.0 – 4/23/03 

B.9.3 FTA_SSL.1 TSF initiated session locking 

Dependencies: FIA_UAU.1 

FTA_SSL.1.1 The TSF shall lock an interactive session after [assignment: an authorized user 

specified time interval of user inactivity] by: 

a) clearing or overwriting display devices, making the current contents unreadable; 

b) disabling any activity of the user's data access/display devices other than unlocking the 

session. 

FTA_SSL1.2 The TSF shall require the following events to occur prior to unlocking the session: 

[assignment: user authentication]. 

B.9.4 FTA_SSL.2 User-initiated locking 

Dependencies: FIA_UAU.1 

FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user's own interactive sessions 

by: 

a) clearing or over-writing display devices, making the current contents unreadable; 

b) disabling any activity of the user's data access/display devices other then unlocking the 

session. 

FTA_SSL.2.2 The TSF shall require the following events to occur prior to unlocking the session: 

[assignment: user authentication]. 

B.9.5 FTA_SSL.3 TSF-initiated termination 

Dependencies: None 

FTA_SSL.3.1 The TSF shall terminate an interactive session after [assignment: an authorized 

user specified time interval of user inactivity]. 

B.9.6 FTA_TAB.1-CSPP 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-CSPP.2 The TSF shall provide the capability for an authorized user to specify 

and subsequently modify the contents of this warning message. 
CSPP-OS B-21 Ver 1.0 – 4/23/03 

B.9.7 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, and 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, and 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 

B.9.8 FTA_TSE.1 TOE session establishment 

Dependencies: None 

FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [assignment:

attributes that can be set by explicitly authorized security administrator(s) or security 

administrator role(s), including user identity, port of entry, time of day, day of the week, and any 

[ST assignment: ST specific attributes]. The ST rationale must show that the ST assignment is 

complete.

Refinement: See text in FTA_TSE.1.1 
CSPP-OS B-22 Ver 1.0 – 4/23/03 

B.10 TRUSTED PATH/CHANNELS (FTP) 

B.10.1 FTP_ITC.1-CSPP Inter-TSF trusted channel 

Dependencies: None 

FTP_ITC.1.1-CSPP The TSF shall provide a communication channel between itself and a 

remote trusted IT product that is logically distinct from other communication channels and 

provides assured identification of its end points and protection of the [extension: security 

information as required to mitigate against insecurities resulting from both attacks and 

unintentional modification, to include the following: [ST assignment: other security information 

identified in the ST design and development]] channel data from modification and [extension: 

identification and authentication data and the following other security information: [ST 

assignment: other security information identified in the ST design and development] channel 

data from disclosure. The ST rationale shall provide a basic justification, showing that the ST 

assignments are complete, with regard to mitigation in the intended operational environment for 

the TOE.

FTP_ITC.1.2 The TSF shall permit [ST selection: the TSF, the remote trusted IT product] to 

initiate communication via the trusted channel. The ST rationale shall provide a basic 

justification, showing that the ST selection is appropriate for maintaining secure operation in the 

intended environment.

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: the 

following functions: [ST assignment: list of functions for which a trusted channel is required]]. 

The ST rationale shall provide a basic justification, showing that the ST assignment is a complete 

list, as required to mitigate insecurities in the intended operational environment for the TOE.

Refinement: See text in FTP_ITC.1.1-CSPP, FTP_ITC.1.2, and FTP_ITC.1.3

Extension: See text in FTP_ITC.1.1-CSPP 
CSPP-OS C-1 Ver 1.0 – 4/23/03 

C. APPENDIX C: TOE ASSURANCE REQUIREMENT DETAILS 

C.1 CONFIGURATION MANAGEMENT (ACM) 

C.1.1 ACM_CAP.3 Authorization controls 

Dependencies: ALC_DVS.1 (CM_SCP.1 deleted per CCIMB-I-95) 

Developer action elements: 

ACM_CAP.3.1D The developer shall provide a reference for the TOE. 

ACM_CAP.3.2D The developer shall use a CM system. 

ACM_CAP.3.3D The developer shall provide CM documentation. 

Content and presentation of evidence elements: 

ACM_CAP.3.1C The reference for the TOE shall be unique to each version of the TOE. 

ACM_CAP.3.2C The TOE shall be labeled with its reference. 

ACM_CAP.3.3C The CM documentation shall include a configuration list and a CM plan. 

CCIMB_I-003 The configuration list shall uniquely identify all configuration items that 

comprise the TOE. 

ACM_CAP.3.4C The configuration list shall describe the configuration items that comprise the 

TOE. 

ACM_CAP.3.5C The CM documentation shall describe the method used to uniquely identify 

the TOE configuration items. 

ACM_CAP.3.6C The CM system shall uniquely identify all configuration items. 

ACM_CAP.3.7C The CM plan shall describe how the CM system is used. 

ACM_CAP.3.8C The evidence shall demonstrate that the CM system is operating in accordance 

with the CM plan. 

ACM_CAP.3.9C The CM documentation shall provide evidence that all configuration items 

have been and are being effectively maintained under the CM system. 

ACM_CAP.3.10C The CM system shall provide measures such that only authorized changes are 

made to the configuration items. 

Evaluator action elements: 

ACM_CAP.3.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 
CSPP-OS C-2 Ver 1.0 – 4/23/03 

C.1.2 ACM_SCP.2 Problem tracking CM coverage 

Dependencies: ACM_CAP.3 

Developer action elements: 

ACM_SCP.2.1D The developer shall provide a list of configuration items for the TOE. 

(CCIMB_I-004) 

Content and presentation of evidence elements: 

ACM_SCP.2.1C The list of configuration items shall include the following: implementation 

representation; security flaws; and the evaluation evidence required by the assurance components 

in the ST. (CCIMB_I-004) 

ACM_SCP.2.2C Deleted per CCIMB_I-004. 

Evaluator action elements: 

ACM_SCP.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.2 DELIVERY AND OPERATION (ADO) 

C.2.1 ADO_DEL.1 Delivery procedures 

Dependencies: None 

Developer action elements:

ADO_DEL.1.1D The developer shall document the procedures for delivery of the TOE or parts 

of it to the user. 

ADO_DEL.1.2D The developer shall use the delivery procedures. 

Content and presentation of evidence elements: 

ADO_DEL.1.1C The delivery documentation shall describe the procedures which are necessary 

to maintain security when distributing versions of the TOE to a user site. 

Evaluator action elements: 

ADO_DEL.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.2.2 ADO_IGS.1 Installation, generation, and start-up procedures 

Dependencies: AGD_ADM.1 

Developer action elements:

ADO_IGS.1.1D The developer shall document procedures to be used for the secure installation, 

generation, and start-up of the TOE. 
CSPP-OS C-3 Ver 1.0 – 4/23/03 

Content and presentation of evidence elements: 

ADO_IGS.1.1C The installation, generation, and start-up documentation shall describe all the 

steps necessary for secure installation, generation, and start-up of the TOE. (CCIMB_I-51) 

Evaluator action elements: 

ADO_IGS.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

ADO_IGS.1.2E The evaluator shall confirm that the installation procedures result in a secure 

configuration. 

C.3 DEVELOPMENT (ADV) 

C.3.1 ADV_FSP.1 Informal functional specification 

Dependencies: ADV_RCR.1 

Developer action elements: 

ADV_FSP.1.1D The developer shall provide a functional specification. 

Content and presentation of evidence elements: 

ADV_FSP.1.1C The functional specification shall describe the TSF and its external interfaces 

using an informal style. 

ADV_FSP.1.2C The functional specification shall be internally consistent. 

ADV_FSP.1.3C The functional specification shall describe the purpose and method of use of all 

external TSF interfaces, providing details of effects, exceptions and error messages, as 

appropriate. 

ADV_FSP.1.4C The functional specification shall completely represent the TSF. 

Evaluator action elements: 

ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

ADV_FSP.1.2E The evaluator shall determine that the functional specification is an accurate 

and complete instantiation of the TOE security functional requirements. 

C.3.2 ADV_HLD.1 Descriptive high-level design 

Dependencies: ADV_FSP.1, ADV_RCR.1 

Developer action elements: 

ADV_HLD.1.1D The developer shall provide the high-level design of the TSF. 

Content and presentation of evidence elements: 

ADV_HLD.1.1C The presentation of the high-level design shall be informal. 
CSPP-OS C-4 Ver 1.0 – 4/23/03 

ADV_HLD.1.2C The high-level design shall be internally consistent. 

ADV_HLD.1.3C The high-level design shall describe the structure of the TSF in terms of 

subsystems. 

ADV_HLD.1.4C The high-level design shall describe the security functionality provided by 

each subsystem of the TSF. 

ADV_HLD.1.5C The high-level design shall identify any underlying hardware, firmware, 

and/or software required by the TSF with a presentation of the functions provided by the 

supporting protection mechanisms implemented in that hardware, firmware, or 

software. 

ADV_HLD.1.6C The high-level design shall identify the interfaces of the subsystems of the 

TSF. 

ADV_HLD.1.7C The high-level design shall identify which of the interfaces to the subsystems 

of the TSF are externally visible. 

Evaluator action elements: 

ADV_HLD.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

ADV_HLD.1.2E The evaluator shall determine that the high-level design is an accurate an 

complete instantiation of the TOE security functional requirements. 

C.3.3 ADV_RCR.1 Informal Correspondence Demonstration 

Dependencies: None 

Developer action elements: 

ADV_RCR.1.1D The developer shall provide an analysis of correspondence between all 

adjacent pairs of TSF representations that are provided. 

Content and presentation of evidence elements: 

ADV_RCR.1.1C For each adjacent pair of provided TSF representations, the analysis shall 

demonstrate that all relevant security functionality of the more abstract TSF representation is 

correctly and completely refined in the less abstract TSF representation. 

Evaluator action elements: 

ADV_RCR.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.3.4 ADV_SPM.1 Informal TOE security policy model 

Dependencies: ADV_FSP.1 

Developer action elements: 

ADV_SPM.1.1D The developer shall provide an TSP model. 

ADV_SPM.1.2D The developer shall demonstrate correspondence between the functional 

specification and the TSP model. 
CSPP-OS C-5 Ver 1.0 – 4/23/03 

Content and presentation of evidence elements: 

ADV_SPM.1.1C The TSP model shall be informal. 

ADV_SPM.1.2C The TSP model shall describe the rules and characteristics of all policies of the 

TSP that can be modeled. 

ADV_SPM.1.3C The TSP model shall include a rationale that demonstrates that it is consistent 

and complete with respect to all policies of the TSP that can be modeled. 

ADV_SPM.1.4C The demonstration of correspondence between the TSP model and the 

functional specification shall show that there are no security functions in the functional 

specification are consistent and complete with respect to the TSP model. 

Evaluator action elements: 

ADV_SPM.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.4 GUIDANCE DOCUMENTS (AGD) 

C.4.1 AGD_ADM.1 Administrator guidance 

Dependencies: ADV_FSP.1 

Developer action elements: 

AGD_ADM.1.1D The developer shall provide administrator guidance addressed to system 

administrative personnel. 

Content and presentation of evidence elements: 

AGD_ADM.1.1C The administrator guidance shall describe the administrative functions and 

interfaces available to the administrator of the TOE 

AGD_ADM.1.2C The administrator guidance shall describe how to administer the TOE in a 

secure manner. 

AGD_ADM.1.3C The administrator guidance shall contain warnings about functions and 

privileges that should be controlled in a secure processing environment. 

AGD_ADM.1.4C The administrator guidance shall describe all security parameters under the 

control of the administrator indicating safe values as appropriate. 

AGD_ADM.1.5C The administrator guidance shall describe each type of security-relevant event 

relative to the administrative functions that need to be performed, including changing the 

security characteristics of entities under the control of the TSF. 

AGD_ADM.1.6C The administrator guidance shall be consistent with all other documents 

supplied for evaluation. 

AGD_ADM.1.7C The administrator guidance shall describe all security requirements on the IT 

environment which are relevant to the administrator. 

Evaluator action elements: 
CSPP-OS C-6 Ver 1.0 – 4/23/03 

AGD_ADM.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.4.2 AGD_USR.1 User Guidance 

Dependencies: ADV_FSP.1 

Developer action elements: 

AGD_USR.1.1D The developer shall provide user guidance. 

Content and presentation of evidence elements: 

AGD_USR.1.1C The user guidance shall describe the functions and interfaces available to the 

non-administrative users of the TOE. 

AGD_USR.1.2C The user guidance shall describe the use of user-accessible security functions 

provided by the TOE. 

AGD_USR.1.3C The user guidance shall contain warnings about user-accessible functions and 

privileges that should be controlled in a secure processing environment. 

AGD_USR.1.4C The user guidance shall clearly present all user responsibilities necessary for 

secure operation of the TOE, including all assumptions about user behavior found in the 

statement of TOE security environment. 

AGD_USR.1.5C The user guidance shall be consistent with all other documentation delivered 

for evaluation. 

AGD_USR.1.6C The user guidance shall describe all security requirements on the IT 

environment which are relevant to the user. 

Evaluator action elements: 

AGD_USR.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 
CSPP-OS C-7 Ver 1.0 – 4/23/03 

C.5 LIFE CYCLE SUPPORT (ALC) 

C.5.1 ALC_DVS.1 Identification of security measures 

Dependencies: None 

Developer action elements: 

ALC_DVS.1.1D The developer shall produce development security documentation. 

Content and presentation of evidence elements: 

ALC_DVS.1.1C The development security documentation shall describe the physical, 

procedural, personnel, and other security measures that are necessary to protect the 

confidentiality and integrity of the TOE design and implementation in its development 

environment. 

ALC_DVS.1.2C The development security documentation shall provide evidence that these 

security measures are followed during the development and maintenance of the TOE. 

Evaluator action elements: 

ALC_DVS.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

ALC_DVS.1.2E The evaluator shall check whether the security measures are being applied. 
CSPP-OS C-8 Ver 1.0 – 4/23/03 

C.5.2 ALC_FLR.2 Flaw reporting procedures 

Dependencies: None 

Developer action elements: 

ALC_FLR.2.1D The developer shall document the flaw remediation procedures. 

ALC_FLR.2.2D The developer shall establish a procedure for accepting and acting upon user 

reports of security flaws and requests for corrections to those flaws. 

Content and presentation of evidence elements: 

ALC_FLR.2.1C The flaw remediation procedures documentation shall describe the procedures 

used to track all reported security flaws in each release of the TOE. 

ALC_FLR.2.2C The flaw remediation procedures shall require that a description of the nature 

and effect of each security flaw be provided, as well as the status of finding a correction to that 

flaw. 

ALC_FLR.2.3C The flaw remediation procedures shall require that corrective actions be 

identified for each of the security flaws. 

ALC_FLR.2.4C The flaw remediation procedures documentation shall describe the methods 

used to provide flaw information, corrections and guidance on corrective actions to TOE users. 

ALC_FLR.2.5C The procedures for processing reported security flaws shall ensure that any 

reported flaws are corrected and the correction issued to TOE users. 

ALC_FLR.2.6C The procedures for processing reported security flaws shall provide safeguards 

that any corrections to these security flaws do not introduce any new flaws. 

Evaluator Action Elements: 

ALC_FLR.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 
CSPP-OS C-9 Ver 1.0 – 4/23/03 

C.6 TESTS (ATE) 

C.6.1 ATE_COV.2 – Analysis of coverage 

Dependencies: ADV_FSP.1, ATE_FUN.1 

Developer action elements: 

ATE_COV.2.1D The developer shall provide an analysis of the test coverage. 

Content and presentation of evidence elements: 

ATE_COV.2.1C The analysis of the test coverage shall demonstrate the correspondence 

between the tests identified in the test documentation and the TSF as described in the functional 

specification. 

ATE_COV.2.2C The analysis of the test coverage shall demonstrate that the correspondence 

between the TSF as described in the functional specification and the tests identified in the test 

documentation is complete. 

Evaluator Actions: 

ATE_COV.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.6.2 ATE_DPT.1 Testing: High Level Design 

Dependencies: ADV_HLD.1, ATE_FUN.1 

Developer action elements: 

ATE_DPT.2.1D The developer shall provide the analysis of the depth of testing. 

Content and presentation of evidence elements: 

ATE_DPT.2.1C The depth analysis shall demonstrate that the tests identified in the test 

documentation are sufficient to demonstrate that the TOE operates in accordance with the high 

level design. 

Evaluator action elements: 

ATE_DPT.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 
CSPP-OS C-10 Ver 1.0 – 4/23/03 

C.6.3 ATE_FUN.1 Functional Testing 

Dependencies: None 

Developer action elements: 

ATE_FUN.1.1D The developer shall test the TSF and document the results. 

ATE_FUN.1.2D The developer shall provide test documentation. 

Content and presentation of evidence elements: 

ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure descriptions, 

expected test results and actual test results. 

ATE_FUN.1.2C The test plans shall identify the security functions to be tested and describe the 

goal of the tests to be performed. 

ATE_FUN.1.3C The test procedure descriptions shall identify the tests to be performed and 

describe the scenarios for testing each security function. These scenarios shall include any 

ordering dependencies on the results of other tests. 

ATE_FUN.1.4C The test results in the test documentation shall show the anticipated outputs 

from a successful execution of the tests. 

ATE_FUN.1.5C The test results from the developer execution of the tests shall demonstrate that 

each security function operates as specified. 

Evaluator action elements: 

ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

C.6.4 ATE_IND.2 Independent Testing - Sample 

Dependencies: ADV_FSP.1, AGD_USR.1, AGD_ADM.1, ATE_FUN.1 

Developer action elements: 

ATE_IND.2.1D The developer shall provide the TOE for testing. 

Content and presentation of evidence elements: 

ATE_IND.2.1C The developer shall provide an equivalent set of resources to those that were 

used in the developer’s functional testing of the TSF. 

Evaluator action elements: 

ATE_IND.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

ATE_IND.2.2E The evaluator shall test the TSF to confirm that the TSF operates as specified. 

ATE_IND.2.3E The evaluator shall execute a sample of tests in the test documentation to verify 

the developer test results. 
CSPP-OS C-11 Ver 1.0 – 4/23/03 

C.7 VULNERABILITY ASSESSMENT (AVA) 

C.7.1 AVA_MSU.2 Validation of Analysis 

Dependencies: ADO_IGS.1, AGD_ADM.1, AGD_USR.1, ADV_FSP.1 

Developer action elements: 

AVA_MSU.2.1D The developer shall provide guidance documentation. 

AVA_MSU.2.2D The developer shall document an analysis of the guidance documentation. 

Content and presentation of evidence elements:

AVA_MSU.2.1C The guidance documentation shall identify all possible modes of operation of 

the TOE, including operation following failure or operational error, their consequences and 

implications for maintaining secure operation. 

AVA_MSU.2.2C The guidance documentation shall be complete, clear, consistent and 

reasonable. 

AVA_MSU.2.3.C The guidance documentation shall list all assumptions about the intended 

environment. 

AVA_MSU.2.4C The guidance documentation shall list all requirements for external security 

measures (including external procedural, physical and personnel controls). 

AVA_MSU.2.5C The developer’s analysis documentation shall demonstrate that the guidance 

documentation is complete. 

Evaluator action elements: 

AVA_MSU.2.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

AVA_MSU.2.2E The evaluator shall repeat all configuration and installation procedures, and 

other procedures selectively, to check that the TOE can be configured and used securely using 

only the supplied guidance documentation. 

AVA_MSU.2.3E The evaluator shall determine that the use of the guidance documentation 

allows all insecure states to be detected. 

AVA_MSU.2.4E The evaluator shall confirm that the analysis shows that guidance is provided 

for secure operation in all modes of operation of the TOE. 
CSPP-OS C-12 Ver 1.0 – 4/23/03 

C.7.2 AVA_SOF.1 Strength of TOE Security Function Evaluation 

Dependencies: ADV_FSP.1, ADV_HLD.1 

Developer action elements: 

AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for 

each identified mechanism identified in the ST as having a strength of TOE security function 

claim. 

Content and presentation of evidence elements: 

AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim the 

strength of TOE security function analysis shall show that it meets or exceeds the minimum 

strength level defined in the PP/ST. 

AVA_SOF.1.2C For each mechanism with a strength of TOE security function claim the 

strength of TOE security function analysis shall show that it meets or exceeds the specific 

strength of function metric defined in the PP/ST. 

Evaluator action elements: 

AVA_SOF.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 

AVA_SOF.1.2E The evaluator shall confirm that the strength claims are correct. 

C.7.3 AVA_VLA.1 Developer vulnerability analysis 

Dependencies: ADV_FSP.1, ADV_HLD.1, AGD_ADM.1, AGD_USR.1 

Developer action elements: 

AVA_VLA.1.1D The developer shall perform a vulnerability analysis. (CCIMB_I-51) 

AVA_VLA.1.2D The developer shall provide vulnerability analysis documentation. (CCIMB_I51) 

Content and presentation of evidence elements: 

AVA_VLA.1.1C The vulnerability analysis documentation shall describe the analysis of the 

TOE deliverables performed to search for obvious ways in which a user can violate the TSP. 

(CCIMB_I-51) 

AVA_VLA.1.2C The vulnerability analysis documentation shall describe the disposition of 

obvious vulnerabilities. (CCIMB_I-51) 

AVA_VLA.1.3C The vulnerability analysis documentation shall show, for all identified 

vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the 

TOE. (CCIMB_I-51) 

Evaluator action elements: 

AVA_VLA.1.1E The evaluator shall confirm that the information provided meets all 

requirements for content and presentation of evidence. 
CSPP-OS C-13 Ver 1.0 – 4/23/03 

AVA_VLA.1.2E The evaluator shall conduct penetration testing, based on the developer 

vulnerability analysis, to ensure obvious vulnerabilities have been addressed. 

C.8 MAINTENANCE OF ASSURANCE (AMA) 

None 
CSPP-OS D-1 Ver 1.0 – 4/23/03 

D. APPENDIX D: IT-ENVIRONMENT FUNCTIONAL REQUIREMENT DETAILS 

This section contains information on the security functional requirements expected of the 

hardware/firmware platform upon which the CSPP-OS compliant TOE is to be run. By 

identifying these requirements, it becomes possible to specify OS requirements separate from 

underlying platform requirements. This in turn enables the composition of a compliant OS with 

any number of underlying platforms and being able to make definitive (to the level of confidence 

appropriate for EAL-CSPP) claims about the security provided by the OS/platform pair. 

Throughout these requirements the term “BIOS” (basic input-output system), while a PC specific 

term, is used in its most general sense to mean “any underlying hardware/firmware input/output 

support used by the operating system or capable of by-passing operating system protections”. 

An example of the latter would be a “BIOS” which provided buffering of read/writes to disk 

through a BIOS “owned” portion of memory. Any residual information protection for this 

shared resource must be performed by the BIOS as the operating system is unable to do so. 

D.1 AUDIT (FAU) 

D.1.1 FAU_STG.1-NIAP-0423 Protected audit trail storage 

Dependencies: FAU_GEN.1-CSPP 

FAU_STG.1.1-NIAP-0423 The TSF’s IT-environment shall help protect the stored audit records 

in the audit trail from unauthorized deletion. 

FAU_STG.1.2-NIAP-0423 The TSF’s IT-environment shall be able to [selection: prevent] 

unauthorized modifications to the audit records in the audit trail via hardware write protection to 

removable storage media. 

D.2 USER DATA PROTECTION (FDP) 

D.2.1 FDP_ACC.1 Subset access control 

Dependencies: FDP_ACF.1-CSPP 

FDP_ACC.1.1 The TSF’s IT-environment shall enforce the [assignment: requirement to 

provide a ‘boot-level’ password, if so required based upon a user-selectable parameter,] on 

[assignment: the ability to boot or re-boot the system]. 
CSPP-OS D-2 Ver 1.0 – 4/23/03 

D.2.2 FDP_RIP.1 Subset residual information protection 

Dependencies: None 

FDP_RIP.1.1 The TSF’s IT-environment shall ensure that any previous information content of a 

resource is made unavailable upon the [assignment: following ST selection: [ST selection:

either allocation of the resource to, deallocation of the resource from, or both]] the following 

objects [assignment: any BIOS-controlled shared memory and file storage space]. 

D.3 IDENTIFICATION AND AUTHENTICATION (FIA) 

D.3.1 FIA_UAU.1 Timing of authentication 

Dependencies: FIA_UID.1 

FIA_UAU.1.1 If password-protected system bootup is enabled, the TSF’s IT-environment shall 

allow [assignment: a limited number of authentication attempts] on behalf of the user to be 

performed before the user is authenticated. 

FIA_UAU.1.2 If password-protected system bootup is enabled, the TSF’s IT-environment shall 

require each user to be successfully authenticated before allowing any other TSF’s ITenvironment-mediated actions on behalf of the user. 

D.3.2 FIA_UAU.6 Re -authentication 

Dependencies: None 

FIA_UAU.6.1 If password-protected system bootup is enabled, the TSF’s IT-environment shall 

re-authenticate the user under the conditions [assignment: of system re-boot from the operating 

state]. 

D.3.3 FIA_UAU.7 Protected authentication feedback 

Dependencies: FIA_UAU.1 

FIA_UAU.7.1 The TSF’s IT-environment shall not provide [assignment: any indication of 

success or failure nor clear-text display of any secret authenticator] to the user while the 

authentication is in progress. 

D.4 SECURITY MANAGEMENT (FMT) 

D.4.1 FMT_MOF.1 Management of security functions behavior 

Dependencies: FMT_SMR.1 

FMT_MOF.1.1 The TSF’s IT-environment shall restrict the ability to [selection: disable or

enable] the functions [assignment: of password-protected boot-up] to [assignment: directly 
CSPP-OS D-3 Ver 1.0 – 4/23/03 

connected keyboard entry and, if currently enabled, to only users who have been successfully 

authenticated]. 

D.4.2 FMT_MSA.3-NIAP-0409 Static attribute initialization 

Dependencies: -FMT_MSA.1, FMT_SMR.1 

FMT_MSA.3.1-NIAP-0409 The TSF’s IT-environment shall enforce the [assignment: CSPP 

access control SFP] to provide [assignment: function-disabled] as the default value for 

password-protected system boot-up. 

FMT_MSA.3.2 The TSF’s IT-environment need not allow the [assignment: any users the 

capability] to specify alternate initial default value for the password-protected boot-up function. 

D.4.3 FMT_MTD.1 Management of TSF’s IT-environment data 

Dependencies: FMT_SMR.1 

FMT_MTD.1.1 The TSF’s IT-environment shall restrict the ability to [selection: 

change_default, read, modify, delete, or clear] the [assignment: all internal TSF’s ITenvironment (i.e., the BIOS) data structures that are security critical] to [assignment: only the 

BIOS]. 

D.5 PROTECTION OF TRUSTED SECURITY (FPT) 

D.5.1 FPT_AMT.1 Abstract machine testing 

Dependencies: None 

FPT_AMT.1.1 The TSF’s IT-environment shall run a suite of tests [selection: during initial 

start-up] to demonstrate the correct operation of the security assumptions provided by the 

hardware which underlies the TSF’s IT-environment. 

D.5.2 FPT_RCV.2-NIAP-0406 Recovery from Failure 

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

FPT_RCV.2.1-NIAP-0406 For [assignment: system re-boot], the TSF’s IT-environment shall 

ensure the return of the TOE to a secure state using automated procedures. 

FPT_RCV.2.2-NIAP-0406 When automated recovery from a failure or service discontinuity is 

not possible, the TSF’s IT-environment shall enter a maintenance mode where the ability to 

return the TOE to a secure state is provided. 
CSPP-OS D-4 Ver 1.0 – 4/23/03 

D.5.3 FPT_RVM.1 Non-bypassability of the TSP 

Dependencies: None 

FPT_RVM.1.1 The TSF’s IT-environment shall ensure, to at least a level of confidence 

appropriate for a lower-level of assurance (i.e., EAL-CSPP), that BIOS-level, TSP enforcement 

functions are invoked and succeed before each function within the TSC is allowed to proceed. 

D.5.4 FPT_SEP.1 TSF domain separation 

Dependencies: None 

FPT_SEP.1.1 The TSF’s IT-environment shall maintain a security domain for its own execution 

that protects, at least to the extent such protection can be reasonably expected from a lower-level 

of assurance (i.e., EAL-CSPP), it from interference and tampering by untrusted subjects. 

FPT_SEP.1.2 The TSF’s IT-environment shall enforce separation between the BIOS and 

hardware-level security domains and the other security domains of the OS and applications by 

using the hardware separation features common with today’s processors. 

D.5.5 FPT_SYN-CSPP.1 TSF synchronization 

Non-CC component defined in [CSPP] 

Extension: 

Not hierarchical to any other component. 

Dependencies: None 

FPT_SYN-CSPP.1.1 The TSF’s IT-environment shall support the system capability to

provide the capability to synchronize distributed TSF’s IT-environment elements and to 

associate audit event records produced by multiple TSF’s IT-environment entities by 

providing a real-time clock and the necessary programmatic interfaces. 

Refinement (to CSPP component): See text in FPT_SYN-CSPP.1.1 

Application note: This component is similar to FPT_STM “Time stamps”, but calls out the 

synchronization requirement instead of a specifying a mechanism (i.e., reliable time stamps”) 

that could be used for that purpose. For the IT underlying an operating system, a real-time 

clock will be an important part of meeting this requirement. 

D.6 RESOURCE UTILIZATION (FRU) 

None. 
CSPP-OS D-5 Ver 1.0 – 4/23/03 

D.7 TOE ACCESS (FTA) 

D.7.1 FTA_TAH.1 TOE access history 

Dependencies: None 

FTA_TAH.1.1 Upon successful system boot-up, the TSF’s IT-environment need not display the 

[selection: any information about] the last successful system boot-up to the user. 

FTA_TAH.1.2 If password-protected system boot-up is enabled and an unsuccessful boot-up 

authentication attempt has occurred since the last successful attempt, then upon successful 

session establishment, the TSF’s IT-environment shall display the [selection: date and time] of 

the last unsuccessful boot-up authentication attempt. 

FTA_TAH.1.3 The TSF’s IT-environment shall not erase the access history information from 

the user interface without giving the user an opportunity to review the information. 

D.8 TRUSTED PATH/CHANNELS (FTP) 

None. 
Rationale for 

COTS Security Protection Profile – Operating Systems (CSPP-OS) 

(CSPP-OS-R) 

Version 1.0 

April 23, 2003 

Organization name and address 

This document is consistent with the 

Common Criteria for Information Technology Security Evaluation 

Version 2.1 

Interpretations Incorporated (as applicable) 

NIAP CCIMB 

All approved posted to 

http://niap.nist.gov/cc-scheme

as of 1/15/03 

(347, 350, 352, 375, 381, 389, 393, 395, 405, 406, 

407, 409, 410, 411, 412, 414, 415, 416, 417, 418, 

420, 421, 422, 423, 424, 425, 426, 427, 429, 459) 

Note: Intent of I-0407 and I-0429 have been 

incorporated without renaming affected components 

All Final posted to 

www.commoncriteria.org 

as of 1/15/03 

(3,4,6,8,9,13,16,19,24,27, 31, 32, 33, 37, 43, 49, 51, 

55, 58, 64, 65, 67, 74, 75, 84, 85, 95, 98, 116, 120, 

127, 128, 133, 138) 
CSPP-OS Rationale ii Ver 1.0 – 4/23/03 

TABLE OF CONTENTS 

SECTION PAGE 

1. INTRODUCTION.............................................................................................................................. 1

2. SECURITY ENVIRONMENT RATIONALE ................................................................................ 3

2.1 USAGE ASSUMPTIONS ..................................................................................................................3

2.2 SECURITY POLICIES......................................................................................................................5

2.3 THREATS TO SECURITY ................................................................................................................7

2.4 GENERAL ASSURANCE LEVEL ....................................................................................................12

3. SECURITY OBJECTIVES RATIONALE.................................................................................... 13

3.1 NECESSARY OBJECTIVES ...........................................................................................................14

3.2 COMPLETE OBJECTIVES .............................................................................................................19

3.3 CORRECT OBJECTIVES ...............................................................................................................24

4. TOE FUNCTIONAL REQUIREMENTS RATIONALE............................................................. 30

4.1 NECESSARY TOE FUNCTIONALITY............................................................................................31

4.2 SUFFICIENT TOE FUNCTIONALITY.............................................................................................36

4.2.1 Coverage of Security Objectives...........................................................................................36

4.2.2 Strength of Function (SOF)...................................................................................................42

4.3 CORRECT TOE FUNCTIONALITY................................................................................................43

4.3.1 Dependencies for TOE functionality.....................................................................................43

4.3.2 Functional Operations ...........................................................................................................46

5. ASSURANCE REQUIREMENTS RATIONALE......................................................................... 64

5.1 NECESSARY ASSURANCES .........................................................................................................64

5.1.1 Basic Assurance Goals ..........................................................................................................64

5.1.2 EAL Selection .......................................................................................................................65

5.1.3 EAL Augmentation ...............................................................................................................68

5.2 SUFFICIENT ASSURANCES ..........................................................................................................70

5.3 CORRECT ASSURANCES..............................................................................................................74

5.3.1 Dependencies for assurances.................................................................................................74

5.3.2 Assurance Operations............................................................................................................75

6. APPENDIX A - REFERENCES ..................................................................................................... 76
CSPP-OS Rationale iii Ver 1.0 – 4/23/03 

TABLE OF TABLES 

TABLE PAGE

TABLE 1-1 CSPP-OS RATIONALE OVERVIEW...............................................................................................................1

TABLE 2.1-1 USAGE ASSUMPTION RATIONALE.............................................................................................................3

TABLE 2.2-1 SECURITY POLICY RATIONALE .................................................................................................................5

TABLE 2.3-1 SECURITY THREAT RATIONALE................................................................................................................7

TABLE 3.1-1 NECESSARY OBJECTIVES – MAPPING OBJECTIVES TO POLICY AND THREAT ..........................................14

TABLE 3.2-1 COMPLETE OBJECTIVES – MAPPING POLICY AND THREAT TO OBJECTIVES............................................19

TABLE 3.3-1 CORRECT OBJECTIVES - MAPPING SECURITY OBJECTIVE TO RATIONALE ..............................................24

TABLE 4.1-1 NECESSARY TOE FUNCTIONALITY – MAPPING FUNCTION TO REQUIREMENT .......................................31

TABLE 4.2-1 COMPLETE FUNCTIONALITY - MAP TOE SECURITY OBJECTIVE TO TOE FUNCTIONALITY ....................37

TABLE 4.2-2 COMPLETE FUNCTIONALITY - MAP JOINT SECURITY OBJECTIVE TO TOE FUNCTIONALITY...................40

TABLE 4.3.1-1 CORRECT TOE FUNCTIONALITY – DEPENDENCY MAPPING ................................................................43

TABLE 4.3.2-1 CORRECT FUNCTIONALITY – RATIONALE FOR ASSIGNMENT, SELECTION, AND REFINEMENT..............47

TABLE 4.3.2-2 CORRECT FUNCTIONALITY – RATIONALE FOR DEFERRING OPERATIONS TO ST ..................................55

TABLE 4.3.2-3 CORRECT FUNCTIONALITY – RATIONALE FOR FUNCTIONAL EXTENSIONS ..........................................61

TABLE 5.1.2-1 NECESSARY ASSURANCE - EAL1 NOT SUFFICIENT.............................................................................65

TABLE 5.1.2-2 NECESSARY ASSURANCE - EAL3 TOO MUCH .....................................................................................67

TABLE 5.1.3-1 NECESSARY ASSURANCE - AUGMENTATION RATIONALE ....................................................................68

TABLE 5.2-1 COMPLETE ASSURANCE - NON-SELECTION RATIONALE.........................................................................70

TABLE 5.3.1-1 CORRECT ASSURANCES – DEPENDENCY MAPPING..............................................................................74
CSPP-OS Rationale 1 Ver 1.0 – 4/23/03 

1. INTRODUCTION 

The purpose of this rationale document is to show that the CSPP-OS protection profile (PP) is 

internally consistent, accurate, and complete to a level of confidence corresponding to the EAL2 

assurance level. This is accomplished by the individual rationales listed in Table 1-1. 

Taken together, these rationale show (at a level of rigor appropriate for EAL-2 level evaluations) 

that the PP’s list of functional and assurance requirements are suitable for describing a specific 

user need within the scope of those described in the CSPP-OS introduction and TOE description. 

Table 1-1 CSPP-OS Rationale Overview 

Nature of Rationale Purpose Section 

Discuss the usage assumptions, showing that 

they are necessary and reasonable. 2.1 

Discuss the security policies, showing that they 

are necessary and reasonable. 2.2 

Discuss the security threats, showing that they 

are necessary and reasonable. 2.3 

Discuss the general assurance level, showing 

that it is appropriate. 

Show that the security environment 

description is consistent with the 

introduction and the TOE description. 

2.4 

Map security objectives to policy and threat Show necessity of CSPP-OS objectives 3.1 

Map policy/threat to security objectives Show completeness of CSPP-OS objectives 3.2 

Compare environmental security objectives with 

CSPP-OS introduction and TOE description Show correctness of CSPP-OS objectives 3.3 

Map TOE functional requirement to 

dependencies and security objectives 

Show necessity of CSPP-OS TOE 

functionality 4.1 

Map TOE security objectives to TOE functional 

requirements and justify SOF claims 

Show sufficiency of CSPP-OS TOE 

functionality 4.2 

Map dependencies for CSPP-OS TOE 

functionality to CSPP-OS requirement meeting 

that dependency 

4.3.1 

Discuss operations performed on CSPP-OS 

TOE function components (iteration, 

assignment, selection, or refinement) 

4.3.2 

Discuss functional operations deferred to ST 4.3.3 

Discuss non-CC functional extensions 

Show correctness of CSPP-OS TOE 

functionality 

4.3.4 
CSPP-OS Rationale 2 Ver 1.0 – 4/23/03 

Nature of Rationale Purpose Section 

Discuss basic assurance goals 5.1.1 

Show EAL2 is the correct base level by 

mapping necessary components not in EAL2 to 

need and unnecessary components in EAL3 to 

rationale for being not needed. 

5.1.2 

Map EAL2 augmentation to need 

Show necessity of CSPP-OS assurances 

5.1.3 

Map unused CC components to reason for not 

being used Show sufficiency of CSPP-OS assurances 5.2 

Map dependencies for CSPP-OS assurance to 

CSPP-OS requirement meeting that dependency 5.3.1 

Discuss operations performed on CSPP-OS 

assurance components (iteration, assignment, 

selection, or refinement) 

5.3.2 

Discuss assurance operations deferred to ST 5.3.3 

Discuss non-CC assurance extensions 

Show correctness of CSPP-OS assurances 

5.3.4 
CSPP-OS Rationale 3 Ver 1.0 – 4/23/03 

2. SECURITY ENVIRONMENT RATIONALE 

2.1 USAGE ASSUMPTIONS 

This rationale shows that each of the CSPP-OS usage assumptions is necessary and reasonable in 

light of the CSPP-OS introduction and TOE description. This is accomplished in Table 2.1-1. 

Table 2.1-1 Usage Assumption Rationale 

Name Assumption Rationale 

A. ADMIN The security features of the 

TOE are competently 

administered on an on-going 

basis.

This is widely recognized, even if system 

administration is not always afforded the 

importance it deserves. Unless the system is 

administered competently in an on-going 

manner, security is not feasible. Therefore this 

assumption is both necessary and reasonable. 

A.COTS The TOE is constructed from 

near-term achievable, 

commercial off the shelf 

information technology. 

This assumption is a stated part of the design 

criteria for this PP and is a key driver in 

determining the nature of the expectations 

toward, and hence the requirements to placed 

upon, the TOE. Therefore this assumption is 

both necessary and reasonable. 

A.MALICIOUSINSIDER The TOE is not expected to 

be able to sufficiently 

mitigate the risks resulting 

from malicious abuse of 

authorized privileges. 

It is important to explicitly recognize that it is 

not reasonable to expect near-term COTS 

products to provide sufficient protection against 

the malicious actions of authorized individuals. 

Therefore this assumption is both necessary and 

reasonable. 

A.NO-LABELS The TOE does not have to 

provide label-based access 

controls. 

This assumption is used in the production of this 

PP and it is considered important to state this 

explicitly. Therefore this assumption is both 

necessary and reasonable. 

A.SOPHISTICATEDATTACK The TOE is not expected to 

be able to sufficiently 

mitigate risks resulting from 

application of sophisticated 

attack methods. 

It is important to explicitly recognize that it is 

not reasonable to expect near-term achievable 

COTS to be able to resist sophisticated attacks. 

Therefore this assumption is both necessary and 

reasonable. 

A.USER-NEED Authenticated users recognize 

the need for a secure IT 

environment. 

Unless the users internalize a need for security 

they are bound to circumvent it. This fact is 

commonly recognized and a primary driver in 

security awareness training that is common 

place both in government and industry. 

Therefore this assumption is both necessary and 

reasonable. 
CSPP-OS Rationale 4 Ver 1.0 – 4/23/03 

Name Assumption Rationale 

A.USER-TRUST Authenticated users are 

generally trusted to perform 

discretionary actions in 

accordance with security 

policies. 

The authenticated users are trusted in this 

manner in most organizations. With CSPP-OS 

compliant TOEs, the users have a fair amount of 

discretion and must be trusted to handle it 

appropriately. Therefore this assumption is both 

necessary and reasonable. 
CSPP-OS Rationale 5 Ver 1.0 – 4/23/03 

2.2 SECURITY POLICIES 

Table 2.2-1 presents the rationale showing that each of the CSPP-OS security policies is both 

necessary and reasonable. 

Table 2.2-1 Security Policy Rationale 

Name Policy Rationale 

P.ACCESS Access rights to specific data objects 

are determined by object attributes 

assigned to that object, user identity, 

user attributes, and environmental 

conditions as defined by the security 

policy. 

It is an essential premise for CSPP-OS TOEs that 

the access to objects is controlled. The nature of 

this control is clearly that characteristics of the 

proposed access (entity, type of access; e.g., read, 

write, and nature of access; e.g., local, remote, 

time-of-day) are compared with attributes of the 

object to determine whether the access to be 

allowed. This policy is both necessary and 

reasonable. 

P.ACCOUNT Users must be held accountable for 

security-relevant actions. 

It is generally considered standard, best practice to 

hold users accountable for their actions. This 

policy is necessary and reasonable. 

P.COMPLY The implementation and use of the 

organization’s IT must comply with 

all applicable laws, regulations, and 

contractual agreements imposed on 

the organization. 

This policy is necessary and reasonable. 

P.DUE-CARE The organization’s IT systems must 

be implemented and operated in a 

manner the represents due care and 

diligence with respect to risks to the 

organization. 

As IT becomes a central part of the business or 

mission process, the potential impact on the 

organization, and personally on the organization’s 

senior management, has dramatically increased. 

With this is coming the recognition that due care 

and diligence with respect to computing security is 

now as important as the organization’s fiduciary 

responsibilities in other areas. The policy is 

necessary and reasonable. 

P.INFO-FLOW Information flow between IT 

components must be in accordance 

with established information flow 

policies. 

Most organizations will have a mandatory 

information flow control policy to deal with 

information such as company proprietary data and 

information under contractual or statutory 

limitations. So, in the general case, this policy is 

necessary and reasonable. 

P.KNOWN Except for a well-defined set of 

allowed operations, users of the TOE 

must be identified and authenticated 

before TOE access can be granted. 

It is standard practice to identify and authenticate 

users. It has also become common to allow 

anonymous access in cases such as a public web 

server. This policy is necessary and reasonable. 
CSPP-OS Rationale 6 Ver 1.0 – 4/23/03 

Name Policy Rationale 

P.NETWORK The organization’s IT security policy 

must be maintained in the 

environment of distributed systems 

interconnected via insecure 

networking. 

Distributed information systems is a fact that 

CSPP-OS must incorporate. This policy is 

necessary and reasonable. 

P.PHYSICAL The processing resources of the TOE 

that must be physically protected in 

order to ensure that security 

objectives are met will be located 

within controlled access facilities 

that mitigate unauthorized, physical 

access. 

It is commonly recognized that the TOE will not be 

able to meet its security requirements unless at least 

a minimum degree of physical security is provided. 

Providing such protection is a common element of 

organizational policies. This policy is necessary 

and reasonable. 

P.SURVIVE The IT system, in conjunction with 

its environment, must be resilient to 

insecurity, resisting the insecurity 

and/or providing the means to detect 

an insecurity and recover from it. 

Since IT has become an essential component of 

many mission/business processes, this is a key 

element of a successful computing security 

program. This is also becoming widely understood 

as such. This policy is necessary and reasonable. 

P.TRAINING Authenticated users of the system 

must be adequately trained, enabling 

them to (1) effectively implement 

organizational security policies with 

respect to their discretionary actions 

and (2) support the need for nondiscretionary controls implemented 

to enforce these policies. 

Organizations generally accept this as a need and 

are implementing it. Unless the users are able to 

make appropriate choices, they are likely to defeat 

the security controls. This policy is necessary and 

reasonable. 

P.USAGE The organization’s IT resources must 

be used for only for authorized 

purposes. 

While “use for only authorized purposes” has been 

a common policy for some time, this policy is even 

more important with recent hacking to use 

corporate and government resources for a number 

of unauthorized activities like spamming, software 

piracy, and breaking other systems. This policy is 

necessary and reasonable. 
CSPP-OS Rationale 7 Ver 1.0 – 4/23/03 

2.3 THREATS TO SECURITY 

For each threat addressed by this PP, Table 2.3-1 gives a rationale for that threat, explaining 

why, if not met by the TOE, it is appropriate to be classed as environment or joint. 

Table 2.3-1 Security Threat Rationale 

Name Threat Rationale 

Environment: 

T.ACCESS-NONTECHNICAL 

An authenticated user may gain 

non-malicious, unauthorized 

access using non-technical means. 

Like T-ENTRY-NON-TECHNICAL, this 

threat is explicitly non-technical and its 

mitigation requires environmental controls. 

T.ACCESS-NON-TECHNICAL is listed as 

a separate threat from T.ENTRY-NONTECHNICAL because the likely mitigating 

controls applied to authenticated users are 

different from those applied to individuals 

not authorized IT access. 

Environment: 

T.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. 

The TOE cannot, in general, be expected to 

protect other components of the system from 

such attacks. Therefore, mechanisms within 

these other components must provide this 

protection. 

Environment: 

T.AUDITCONFIDENTIALITYNon-TOE 

For audit trails not under control of 

the TOE, records of security 

events may be disclosed to 

unauthorized individuals or 

processes. 

For audit records not under control of the 

TOE, other components within the system 

must address this threat. 

Environment: 

T.AUDITCORRUPTED-NonTOE 

For audit trails not under control of 

the TOE, records of security 

events may be subjected to 

unauthorized modification or 

destruction. 

For audit records not under control of the 

TOE, other components within the system 

must address this threat. 

Environment: 

T.DENIAL-Non-TOE 

The IT (other than the TOE) may 

be subjected to an unsophisticated, 

denial-of-service attack. 

The TOE cannot, in general, be expected to 

protect other components of the system from 

such attacks. Therefore, mechanisms within 

these other components must provide this 

protection. 

Environment: 

T.DENIALSOPHISTICATED 

The system may be subjected to a 

sophisticated, denial-of-service 

attack. 

The TOE is not capable of resisting 

sophisticated attacks and must therefore, rely 

on protections provided by its environment 

to maintain availability in the face of such 

threats. 
CSPP-OS Rationale 8 Ver 1.0 – 4/23/03 

Name Threat Rationale 

Environment: 

T.ENTRY-NONTECHNICAL 

An individual, other than an 

authenticated user, may gain 

access to processing resources or 

information using non-technical 

means. 

This threat is explicitly non-technical and 

beyond the scope of CSPP technical controls. 

This necessitates environmental controls. 

Environment: 

T.ENTRY-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. 

The TOE cannot, in general, be expected to 

protect other components of the system from 

such attacks. Therefore, mechanisms within 

these other components must provide this 

protection. 

Environment: 

T.ENTRYSOPHISTICATED 

An individual, other than an 

authenticated user, may gain 

access to processing resources or 

information using a sophisticated, 

technical attack. 

The TOE is not expected to be able to protect 

against sophisticated, technical attacks. 

There is no reasonable expectation that a 

TOE compliant with a CSPP-OS PP will 

significantly increase, over that associated 

with a non-compliant TOE, the work-factor 

required to accomplish a successful, highgrade attack. Therefore, this threat is largely 

addressed by the TOE environment. 

Environment: 

T.OBSERVE-NonTOE 

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. 

The TOE cannot, in general, be expected to 

protect other components of the system from 

such attacks. Therefore, mechanisms within 

these other components must provide this 

protection. 

Environment: 

T.PHYSICAL 

Security-critical parts of the TOE 

may be subjected to a physical 

attack that may compromise 

security. 

As explained in the discussion concerning 

P.PHYSICAL the physical protection of IT 

resources is critical. Since CSPP-OS is a 

baseline for near-term COTS, it is not 

reasonable to expect TOE mechanisms that 

address physical security to any significant 

degree. 

Environment: 

T.RECORD-EVENTNon-TOE 

Security relevant events not under 

control of the TOE may not be 

recorded. 

For auditing not under control of the TOE, 

other components within the system must 

address this threat. 

Environment: 

T.TRACEABLE-NonTOE 

Security relevant events not under 

control of the TOE may not be 

traceable to the user or system 

process associated with the event. 

For auditing not under control of the TOE, 

other components within the system must 

address this threat. 
CSPP-OS Rationale 9 Ver 1.0 – 4/23/03 

Name Threat Rationale 

Joint: 

T.ACCESSMALICIOUS 

An authenticated user may obtain 

unauthorized access for malicious 

purposes. 

The TOE mechanisms for controlling access 

will help address this threat. But since CSPP 

is a baseline for near-term COTS, this 

mitigation is not likely to be sufficient for the 

risks implied by this threat. Hence additional, 

environmental controls are essential. A 

compliant solution may provide for some 

trade-off between environment and TOE in 

meeting this threat. 

Joint: 

T.ADMIN-ERROR 

The security of the TOE may be 

reduced or defeated due to errors 

or omissions in the administration 

of the security features of the TOE.

Humans make mistakes, and if that human is 

the system administrator then the security 

consequences may be great. The TOE is 

expected to provide some mitigation, but, 

especially since CSPP is a baseline for nearterm COTS, the TOE controls are not 

expected to be adequate. Environmental 

controls are needed as well. A compliant 

solution may provide for some trade-off 

between environment and TOE in meeting 

this threat. 

Joint: 

T.CRASH-SYSTEM 

The secure state of the system 

could be compromised in the event 

of a system crash. 

As an underlying operating system, the TOE 

is expected to cooperate with its environment 

in addressing this threat. However, as only 

one component of the system, the TOE is 

unable (in general) to ensure recovery for IT 

other than itself. 

Joint: 

T.INSTALL 

The TOE may be delivered or 

installed in a manner that 

undermines security. 

The TOE can be expected to help address 

this threat, but significant environmental 

controls are also expected. There is the 

distinct potential for trade-offs between 

environment and TOE in meeting this threat, 

while maintaining consistency with the intent 

and constraints of this PP. 

Joint: 

T.OPERATE 

Security failures may occur 

because of improper operation of 

the TOE; e.g., the abuse of 

authorized privileges. 

While the TOE can be expected to provide 

mechanisms that help cover this threat, full 

coverage inherently includes actions that 

must be addressed by environmental 

controls. A compliant solution may provide 

for some trade-off between environment and 

TOE in meeting this threat. 
CSPP-OS Rationale 10 Ver 1.0 – 4/23/03 

Name Threat Rationale 

Joint: 

T.SYSTEMCORRUPTED 

The security state of the TOE, as a 

result of another threat, may be 

intentionally corrupted to enable 

future insecurities. 

System penetrations by either sophisticated 

attackers or attackers using sophisticated 

tools will likely result in an intentionally 

corrupted system state. A CSPP-OS 

compliant TOE is not expected to adequately 

mitigate against such a corruption. The TOE 

mechanisms are expected, in concert with 

environmental controls, to support detection 

of such corruption. A compliant solution 

may provide for some trade-off between 

environment and TOE in meeting this threat. 

TOE: 

T.ACCESS-TOE 

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. 

Users are generally trusted to do the right 

thing (A.USER-TRUST). However, they 

will make mistakes and it is likely that 

situations will occur where users circumvent 

security “to get the job done”, out of 

curiosity, or for the sake of the challenge to 

do so. 

CSPP-OS technical controls are limited to 

addressing this threat, in lieu of the threat of 

malicious user actions, because CSPP is a 

baseline for COTS that is near-term 

achievable. Protecting against the greater 

risk from malicious actions is beyond the 

scope of CSPP expectations. 

TOE: 

T.AUDITCONFIDENTIALITYTOE 

For audit trails under control of the 

TOE, records of security events 

may be disclosed to unauthorized 

individuals or processes. 

Because CSPP is not intended to be able to 

resist all attacks, detection and response are 

critical. T.AUDIT-CONFIDENTIALITYTOE is highlighted as a significant 

contributor toward a potential failure in the 

detection and response capability. 

TOE: 

T.AUDITCORRUPTED-TOE 

For audit trails under control of the 

TOE, records of security events 

may be subjected to unauthorized 

modification or destruction. 

Because CSPP is not intended to be able to 

resist all attacks, detection and response are 

critical. T.AUDIT-CORRUPTED-TOE is 

highlighted as a contributor toward a 

potential failure in the detection and response 

capability. 

TOE: 

T.CRASH-TOE 

The secure state of the TOE could 

be compromised in the event of a 

system crash. 

Systems crash and secure systems may crash 

into an insecure state. Mitigating against this 

is reasonable, prudent, and within the scope 

of CSPP technical controls. 
CSPP-OS Rationale 11 Ver 1.0 – 4/23/03 

Name Threat Rationale 

TOE: 

T.DENIAL-TOE 

The TOE may be subjected to an 

unsophisticated, denial-of-service 

attack. 

In the real-world, CSPP systems will be 

subjected to denial of service. This fact and 

the need to meet P.SURVIVE require 

addressing this threat. CSPP technical 

controls are limited to addressing this threat, 

in lieu of the threat of sophisticated attacks, 

because CSPP is a baseline for COTS that is 

near-term achievable. Protecting against the 

greater risk from sophisticated actions is 

beyond the scope of CSPP expectations. 

TOE: 

T.ENTRY-TOE 

An individual other than an 

authenticated user may gain 

unauthorized, malicious access to 

TOE controlled processing 

resources or information via an 

unsophisticated, technical attack. 

CSPP-OS technical controls are limited to 

addressing this threat, in lieu of the threat of 

sophisticated attacks, because CSPP-OS is a 

baseline for COTS that is near-term 

achievable. Protecting against the greater 

risk from sophisticated actions is beyond the 

scope of CSPP expectations. 

TOE: 

T.OBSERVE-TOE 

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. 

CSPP systems must not misrepresent what is 

within the scope of their security 

mechanisms to correctly interpret. The manmachine interface, at least with respect to the 

basic security state of the system, must be 

free from obvious errors that might lead an 

responsible, competent individual to 

misunderstand the system’s security state. 

TOE: 

T.RECORD-EVENTTOE 

Security relevant events controlled 

by the TOE may not be recorded. 

Because CSPP is not intended to be able to 

resist all attacks, detection and response are 

critical. T.RECORD-EVENT-TOE is 

highlighted as a significant contributor 

toward a potential failure in the detection and 

response capability. 

TOE: 

T.RESOURCES 

The shared, internal TOE 

resources may become exhausted 

due to system error or nonmalicious user actions. 

CSPP-OS represents, in general, multi-user 

or multi-process systems. As such, 

mechanisms addressing this threat are 

common place and typically a part of the OS 

rather than other IT elements of the system. 

TOE: 

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. 

For these lower-grade attacks, the TOE is 

expected to provide the mechanisms 

necessary to address purposeful corruption in 

support of producing future insecurities. 

TOE: 

T.TRACEABLE-TOE 

Security relevant events controlled 

by the TOE may not be traceable 

to the user or system process 

associated with the event. 

Because CSPP-OS is not intended to be able 

to resist all attacks, detection and response 

are critical. T.TRACEABLE-TOE is 

highlighted as a significant contributor 

toward a potential failure in the detection and 

response capability. 
CSPP-OS Rationale 12 Ver 1.0 – 4/23/03 

2.4 GENERAL ASSURANCE LEVEL 

The rationale for the general level of assurance for CSPP-OS is fully covered in sections 5.1.1 

“Basic Assurance Goals” and 5.1.2 “EAL Selection”.
CSPP-OS Rationale 13 Ver 1.0 – 4/23/03 

 

3. SECURITY OBJECTIVES RATIONALE 

The rationale for the set of CSPP security objectives will be based upon the following: 

• Necessity – all required. Each objective must contribute to satisfying a security policy or 

countering a threat. 

• Complete – satisfy all policies and counter all threats. The list of security objectives must 

satisfy the policies and adequately counter the threats listed in CSPP. 

• Correct – 

− TOE verses environment. The allocation of policy enforcement and threat mitigation to 

the environment must be reasonable. 

− Correct statement. The security objective must correctly state its intent. 
CSPP-OS Rationale 14 Ver 1.0 – 4/23/03 

3.1 NECESSARY OBJECTIVES 

Table 3.1-1 shows the mapping of security objectives to threats and policies. This table indicates 

that each objective contributes to countering a threat or satisfying a policy. Thus there are no 

unnecessary objectives. 

Table 3.1-1 Necessary Objectives – Mapping Objectives to Policy and Threat 

Security Objective Threats (T.*) and 

Policies (P.*) 

O.ACCESS-MALICIOUS: The TOE controls will 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. 

T.ACCESSMALICIOUS 

O.ACCESS-NON-TECHNICAL: The TOE environment must provide 

sufficient protection against non-technical attacks by authenticated users for 

non-malicious 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. 

T.ACCESS-NONTECHNICAL 

O.ACCESS-Non-TOE: The IT other than 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. 

P.ACCESS 

O.ACCESS-TOE: The TOE must provide public 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. 

P.ACCESS 

O.ACCOUNT-Non-TOE: The IT other than the TOE must ensure, for actions 

under its control or knowledge, that all users can subsequently be held 

accountable for their security relevant actions. This is expected with a high 

degree of effectiveness. 

P.ACCOUNT 

T.TRACEABLE-NonTOE 

T.RECORD-EVENTNon-TOE 

T.AUDITCORRUPTED-NonTOE 

T.AUDITCONFIDENTIALITYNon-TOE 
CSPP-OS Rationale 15 Ver 1.0 – 4/23/03 

Security Objective Threats (T.*) and 

Policies (P.*) 

O.ACCOUNT-TOE: The TOE must ensure, for actions under its control or 

knowledge, that all TOE users can subsequently be held accountable for their 

security relevant actions. This will be done with moderate effectiveness, in that 

it is anticipated that individual accountability might not be achieved for some 

actions. 

P.ACCOUNT 

T.TRACEABLE-TOE 

T.RECORD-EVENTTOE 

T.AUDITCORRUPTED-TOE 

T.AUDITCONFIDENTIALITYTOE 

O.AUTHORIZE-Non-TOE: The IT other 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. 

P.ACCESS 

O.AUTHORIZE-TOE: 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 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. 

P.ACCESS 

O.AVAILABLE-Non-TOE: The IT other than the TOE must protect itself 

from unsophisticated, denial-of-service attacks. This is a combination of 

prevention and detect and recover with a high degree of effectiveness.

P.SURVIVE 

T.DENIAL-Non-TOE 

O.AVAILABLE-TOE: The TOE must protect itself from unsophisticated, 

denial-of-service attacks. This will include a combination of protection and 

detection with high effectiveness.

P.SURVIVE 

T.DENIAL-TOE 

O.BYPASS-Non-TOE: For access not 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 CSPP system are not expected to provide sufficient mitigation for the 

greater negative impact that ‘malicious’ implies. 

T.ACCESS-Non-TOE 
CSPP-OS Rationale 16 Ver 1.0 – 4/23/03 

Security Objective Threats (T.*) and 

Policies (P.*) 

O.BYPASS-TOE: The TOE must prevent errant or non-malicious, authorized 

software or users from bypassing or circumventing TOE security policy 

enforcement. This will be accomplished with high effectiveness. 

NOTE: This objective is limited to ‘non-malicious’ because CSPP-OS controls 

are not expected to be sufficient mitigation for the greater negative impact that 

‘malicious’ implies. 

T.ACCESS-TOE 

O.COMPLY: The TOE environment, in 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. 

P.COMPLY 

O.DENIAL-SOPHISTICATED: The TOE environment must maintain system 

availability in the face of sophisticated denial-of-service attacks. The focus is 

on detection and response with a goal of moderate effectiveness. 

P.SURVIVE 

T.DENIALSOPHISTICATED 

O.DETECT-SOPHISTICATED: The TOE environment must provide the 

ability to detect sophisticated attacks and the results of such attacks (e.g., 

corrupted system state). The goal is for moderate effectiveness. 

P.SURVIVE 

T.SYSTEMCORRUPTED 

O.DETECT-SYSTEM: The TOE, in conjunction with other IT in the system, 

must enable the detection of system insecurities. The goal is high effectiveness 

for lower grade attacks. 

P.SURVIVE 

T.SYSTEMCORRUPTED 

O.DETECT-TOE: The TOE must enable the detection of TOE specific 

insecurities. The goal is high effectiveness for lower grade attacks. 

P.SURVIVE 

T.TOE-CORRUPTED 

O.DUE-CARE: The TOE environment, in conjunction with the TOE itself, 

must be implemented and operated in a manner that clearly demonstrates duecare 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. 

P.DUE-CARE 

O.ENTRY-NON-TECHNICAL: The TOE 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. 

T.ENTRY-NONTECHNICAL 

O.ENTRY-Non-TOE: For resources not controlled by the TOE, IT other than 

the TOE must prevent logical entry using 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. 

P.USAGE 

T.ENTRY-Non-TOE

O.ENTRY-SOPHISTICATED: The TOE 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. 

T.ENTRYSOPHISTICATED 
CSPP-OS Rationale 17 Ver 1.0 – 4/23/03 

Security Objective Threats (T.*) and 

Policies (P.*) 

O.ENTRY-TOE: The TOE must prevent logical entry to the TOE using 

unsophisticated, technical methods, by persons without authority for such 

access. This will be accomplished with high effectiveness. 

P.USAGE 

T.ENTRY-TOE

O.INFO-FLOW: The TOE environment must 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. 

P.INFO-FLOW 

O.KNOWN-Non-TOE: The IT other than the 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. 

P.KNOWN 

O.KNOWN-TOE: The 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 will be accomplished with high 

effectiveness. 

P.KNOWN 

O.MANAGE: Those responsible for the system (in conjunction with 

mechanisms provided by the TOE) must ensure that it is managed and 

administered in a manner that maintains IT security. This will be accomplished 

with moderate effectiveness. 

T.ADMIN-ERROR 

O.NETWORK: The system must be able to meet its security objectives in a 

distributed environment. This will be accomplished with high effectiveness. 

P.NETWORK 

O.OBSERVE-Non-TOE: The IT other than 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. 

T.OBSERVE-NonTOE 

O.OBSERVE-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. 

T.OBSERVE-TOE 

O.OPERATE: Those responsible for the system (in conjunction with 

mechanisms provided by the TOE) must ensure that the system is delivered, 

installed, and operated in a manner which maintains IT security. This will be 

accomplished with moderate effectiveness. 

T.INSTALL 

T.OPERATE 

P.TRAINING 

O.PHYSICAL: Those responsible for the TOE must ensure that those parts of 

the TOE critical to security policy are protected from physical attack that might 

compromise IT security. This will be accomplished primarily via prevention 

with a goal of high effectiveness. 

P.PHYSICAL 

T.PHYSICAL 

O.RECOVER-SYSTEM: The system must provide for recovery to a secure 

state following a system failure, discontinuity of service, or 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. 

P.SURVIVE 

T.CRASH-SYSTEM 
CSPP-OS Rationale 18 Ver 1.0 – 4/23/03 

Security Objective Threats (T.*) and 

Policies (P.*) 

O.RECOVER-TOE: The TOE must provide for recovery to a secure state 

following a system failure, discontinuity of service, or detection of an 

insecurity. This will be accomplished with a high effectiveness for specified 

failures and a low effectiveness for failures in general. 

P.SURVIVE 

T.CRASH-TOE 

O.RESOURCES: The TOE must protect itself from user or system errors that 

result in shared resource exhaustion. This will be accomplished via protection 

with high effectiveness.

P.SURVIVE 

T.RESOURCES 
CSPP-OS Rationale 19 Ver 1.0 – 4/23/03 

3.2 COMPLETE OBJECTIVES 

Table 3.2-1 shows that all policies and threats have related security objectives. While this alone 

does not prove completeness, a simple mapping is considered sufficient in light of the general 

level of assurance provided by EAL2. 

Table 3.2-1 Complete Objectives – Mapping Policy and Threat to Objectives 

Name Description Objectives 

P.ACCESS Access rights to specific data objects 

are determined by object attributes 

assigned to that object, user identity, 

user attributes, and environmental 

conditions as defined by the security 

policy. 

O.ACCESS-NONTECHNICAL 

O.ACCESS-NON-TOE 

O.AUTHORIZE-NON-TOE 

O.AUTHORIZE-TOE 

P.ACCOUNT Users must be held accountable for 

security-relevant actions. 

O.ACCOUNT-NON-TOE 

O.ACCOUNT-TOE 

P.COMPLY The implementation and use of the 

organization’s IT systems must 

comply with all applicable laws, 

regulations, and contractual 

agreements imposed on the 

organization. 

O.COMPLY 

P.DUE-CARE The organization’s IT systems must 

be implemented and operated in a 

manner that represents due care and 

diligence with respect to risks to the 

organization. 

O.DUE-CARE 

P.INFO-FLOW Information flow between IT 

components must be in accordance 

with established information flow 

policies. 

O.INFO-FLOW 

P.KNOWN Except for a well-defined set of 

allowed operations, users of the 

TOE must be identified and 

authenticated before TOE access 

can be granted. 

O.KNOWN-NON-TOE 

O.KNOWN-TOE 

P.NETWORK The organization’s IT security 

policy must be maintained in the 

environment of distributed systems 

interconnected via insecure 

networking. 

O.NETWORK 
CSPP-OS Rationale 20 Ver 1.0 – 4/23/03 

Name Description Objectives 

P.PHYSICAL The processing resources of the 

TOE that must be physically 

protected in order to ensure that 

security objectives are met will be 

located within controlled access 

facilities that mitigate unauthorized, 

physical access. 

O.PHYSICAL 

P.SURVIVE The IT system, in conjunction with 

its environment, must be resilient to 

insecurity, resisting the insecurity 

and/or providing the means to detect 

an insecurity and recover from it. 

O.AVAILABLE-NON-TOE 

O.AVAILABLE-TOE 

O.DENIALSOPHISTICATED 

O.DETECTSOPHISTICATED 

O.DETECT-SYSTEM 

O.DETECT-TOE 

O.RECOVER-SYSTEM 

O.RECOVER-TOE 

O.RESOURCES 

P.TRAINING Authenticated users of the system 

must be adequately trained, enabling 

them to (1) effectively implement 

organizational security policies with 

respect to their discretionary actions 

and (2) support the need for nondiscretionary controls implemented 

to enforce these policies. 

O.OPERATE 

P.USAGE The organization’s IT resources 

must be used for only for authorized 

purposes. 

O.ENTRY-NON-TOE 

O.ENTRY-TOE 

T.ACCESS-MALICIOUS An authenticated user may obtain 

unauthorized access for malicious 

purposes. 

O.ACCESS-MALICIOUS 

T.ACCESS-NON-TECHNICAL An authenticated user may gain nonmalicious, unauthorized access 

using non-technical means. 

O.ACCESS-NONTECHNICAL 

T.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. 

O.BYPASS-NON-TOE 
CSPP-OS Rationale 21 Ver 1.0 – 4/23/03 

Name Description Objectives 

T.ACCESS-TOE 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. 

O.BYPASS-TOE 

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. 

O.MANAGE 

T.AUDITCONFIDENTIALITY-Non-TOE For audit trails not under control of 

the TOE, records of security events 

may be disclosed to unauthorized 

individuals or processes. 

O.ACCOUNT-NON-TOE 

T.AUDITCONFIDENTIALITY-TOE For audit trails under control of the 

TOE, records of security events may 

be disclosed to unauthorized 

individuals or processes. 

O.ACCOUNT-TOE 

T.AUDIT-CORRUPTED-NonTOE For audit trails not under control of 

the TOE, records of security events 

may be subjected to unauthorized 

modification or destruction. 

O.ACCOUNT-NON-TOE 

T.AUDIT-CORRUPTED-TOE For audit trails under control of the 

TOE, records of security events may 

be subjected to unauthorized 

modification or destruction. 

O.ACCOUNT-TOE 

T.CRASH-SYSTEM The secure state of the system could 

be compromised in the event of a 

system crash. 

O.RECOVER-SYSTEM 

T.CRASH-TOE The secure state of the TOE could 

be compromised in the event of a 

system crash. 

O.RECOVER-TOE 

T.DENIAL-Non-TOE The IT (other than the TOE) may be 

subjected to an unsophisticated, 

denial-of-service attack. 

O.AVAILABLE-NON-TOE 

T.DENIAL-SOPHISTICATED The system may be subjected to a 

sophisticated, denial-of-service 

attack. 

O.DENIALSOPHISTICATED 

T.DENIAL-TOE The TOE may be subjected to an 

unsophisticated, denial-of-service 

attack. 

O.AVAILABLE-TOE 
CSPP-OS Rationale 22 Ver 1.0 – 4/23/03 

Name Description Objectives 

T.ENTRY-NON-TECHNICAL An individual, other than an 

authenticated user, may gain access 

to processing resources or 

information using non-technical 

means. 

O.ENTRY-NONTECHNICAL 

T.ENTRY-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. 

O.ENTRY-NON-TOE 

T.ENTRY-SOPHISTICATED An individual, other than an 

authenticated user, may gain access 

to processing resources or 

information using a sophisticated, 

technical attack. 

O.ENTRYSOPHISTICATED 

T.ENTRY-TOE An individual other than an 

authenticated user may gain 

unauthorized, malicious access to 

TOE controlled processing 

resources or information via an 

unsophisticated, technical attack. 

O.ENTRY-TOE 

T.INSTALL The system may be delivered or 

installed in a manner that 

undermines security. 

O.OPERATE 

T.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. 

O.OBSERVE-NON-TOE 

T.OBSERVE-TOE 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. 

O.OBSERVE-TOE 

T.OPERATE Security failures may occur because 

of improper operation of the system; 

e.g., the abuse of authorized 

privileges. 

O.OPERATE 
CSPP-OS Rationale 23 Ver 1.0 – 4/23/03 

Name Description Objectives 

T.PHYSICAL Security-critical parts of the system 

may be subjected to a physical 

attack that may compromise 

security. 

O.PHYSICAL 

T.RECORD-EVENT-Non-TOE Security relevant events not under 

control of the TOE may not be 

recorded. 

O.ACCOUNT-NON-TOE 

T.RECORD-EVENT-TOE Security relevant events controlled 

by the TOE may not be recorded. 

O.ACCOUNT-TOE 

T.RESOURCES The shared, internal TOE resources 

may become exhausted due to 

system error or non-malicious user 

actions. 

O.RESOURCES 

T.SYSTEM-CORRUPTED The security state of the system, as a 

result of another threat, may be 

intentionally corrupted to enable 

future insecurities. 

O.DETECTSOPHISTICATED 

O.DETECT-SYSTEM 

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. 

O.DETECT-TOE 

T.TRACEABLE-Non-TOE Security relevant events not under 

control of the TOE may not be 

traceable to the user or system 

process associated with the event. 

O.ACCOUNT-NON-TOE 

T.TRACEABLE-TOE Security relevant events controlled 

by the TOE may not be traceable to 

the user or system process 

associated with the event. 

O.ACCOUNT-TOE 
CSPP-OS Rationale 24 Ver 1.0 – 4/23/03 

3.3 CORRECT OBJECTIVES 

Table 3.3-1 provides a rationale for the correctness of each of security objectives. Where there is 

a one-to-one match between a policy or threat, that policy or threat is the rationale. For the 

environmental and joint objectives, an explanation is provided for not including the objective in 

the list of TOE security objectives. 

Table 3.3-1 Correct Objectives - Mapping Security Objective to Rationale 

Security Objective Type Rationale 

O.ACCESS-MALICIOUS: The TOE controls will 

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. 

Joint T.ACCESS-MALICIOUS 

As the underlying OS, the TOE is 

expected to provide support for this 

objective. Since the OS is a 

baseline at EAL2, the TOE is not 

expected to be able to meet this 

objective and extensive support 

from its environment will be 

needed. Hence this is joint. 

O.ACCESS-NON-TECHNICAL: The TOE 

environment must provide sufficient protection against 

non-technical attacks by authenticated users for nonmalicious 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. 

Env T.ACCESS-NON-TECHNIAL 

The nature of this threat precludes 

its being addressed by TOE 

mechanisms. Hence this is 

environmental. 

O.ACCESS-Non-TOE: The IT other than 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. 

Env T.ACCESS-NON-TOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.ACCESS-TOE: The TOE must provide public 

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. 

TOE T.ACCESS-TOE 

O.ACCOUNT-Non-TOE: The IT other than the TOE 

must ensure, for actions under its control or knowledge, 

that all users can subsequently be held accountable for 

their security relevant actions. This is expected with a 

high degree of effectiveness. 

Env P.ACCOUNT 

T.TRACEABLE-NON-TOE 

T.RECORD-EVENT-NON-TOE 

T.AUDIT-CORRUPTED-NONTOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 
CSPP-OS Rationale 25 Ver 1.0 – 4/23/03 

Security Objective Type Rationale 

O.ACCOUNT-TOE: The TOE must ensure, for actions 

under its control or knowledge, that all TOE users can 

subsequently be held accountable for their security 

relevant actions. This will be done with moderate 

effectiveness, in that it is anticipated that individual 

accountability might not be achieved for some actions. 

TOE P.ACCOUNT 

T.TRACEABLE-NON-TOE 

T.RECORD-EVENT-NON-TOE 

T.AUDIT-CORRUPTED-NONTOE 

O.AUTHORIZE-Non-TOE: The IT other 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. 

Env P.ACCESS 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.AUTHORIZE-TOE: 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 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. 

TOE P.ACCESS 

O.AVAILABLE-Non-TOE: The IT other than the 

TOE must protect itself from unsophisticated, denial-ofservice attacks. This is a combination of prevention and 

detect and recover with a high degree of effectiveness.

Env P.SURVIVE 

T.DENIAL-NON-TOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.AVAILABLE-TOE: The TOE must protect itself 

from unsophisticated, denial-of-service attacks. This 

will include a combination of protection and detection 

with high effectiveness.

TOE P.SURVIVE 

T.DENIAL-TOE 

O.BYPASS-Non-TOE: For access not 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 CSPP system are not 

expected to provide sufficient mitigation for the greater 

negative impact that ‘malicious’ implies. 

Env T.ACCESS-NON-TOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 
CSPP-OS Rationale 26 Ver 1.0 – 4/23/03 

Security Objective Type Rationale 

O.BYPASS-TOE: The TOE must prevent errant or 

non-malicious, authorized software or users from 

bypassing or circumventing TOE security policy 

enforcement. This will be accomplished with high 

effectiveness. 

NOTE: This objective is limited to ‘non-malicious’ 

because CSPP-OS controls are not expected to be 

sufficient mitigation for the greater negative impact that 

‘malicious’ implies. 

TOE T.ACCESS-TOE 

O.COMPLY: The TOE environment, in 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 nontechnical controls to achieve this objective with high 

effectiveness. 

Joint O.COMPLY 

As compliance applies to the entire 

IT system, this requires support by 

the TOE, other IT, and the non-IT 

environment. Hence this is joint. 

O.DENIAL-SOPHISTICATED: The TOE 

environment must maintain system availability in the 

face of sophisticated denial-of-service attacks. The 

focus is on detection and response with a goal of 

moderate effectiveness. 

Env P.SURVIVIE 

T.DENIAL-SOPHISTICATED 

As the TOE is lower assurance IT, 

this objective is expected to be met 

primarily by the environment. 

Hence this is environmental. 

O.DETECT-SOPHISTICATED: The TOE 

environment must provide the ability to detect 

sophisticated attacks and the results of such attacks (e.g., 

corrupted system state). The goal is for moderate 

effectiveness. 

Env P.SURVIVE 

T.SYSTEM-CORRUPTED 

As the TOE is lower assurance IT, 

this objective is expected to be met 

primarily by the environment. 

Hence this is environmental. 

O.DETECT-SYSTEM: The TOE, in conjunction with 

other IT in the system, must enable the detection of 

system insecurities. The goal is high effectiveness for 

lower grade attacks. 

Joint P.SURVIVE 

T.SYSTEM-CORRUPTED 

Being an underlying OS, the TOE is 

expected to help in meeting this 

objective. Since the TOE is lower 

assurance IT, significant 

environmental support is expected 

in order to accomplish this 

objective. Hence this is joint. 

O.DETECT-TOE: The TOE must enable the detection 

of TOE specific insecurities. The goal is high 

effectiveness for lower grade attacks. 

TOE P.SURVIVE 

T.TOE-CORRUPTED 
CSPP-OS Rationale 27 Ver 1.0 – 4/23/03 

Security Objective Type Rationale 

O.DUE-CARE: The TOE environment, in 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. 

Joint P.DUE-CARE 

As exercising due care applies to 

the entire IT system, this requires 

support by the TOE, other IT, and 

the non-IT environment. Hence this 

is joint. 

O.ENTRY-NON-TECHNICAL: The TOE 

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. 

Env T.ENTRY-NON-TECHNICAL 

The nature of this threat precludes 

its being addressed by TOE 

mechanisms. Hence this is 

environmental. 

O.ENTRY-Non-TOE: For resources not controlled by 

the TOE, IT other than the TOE must prevent logical 

entry using 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. 

Env P.USAGE 

T.ENTRY-NON-TOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.ENTRY-SOPHISTICATED: The TOE 

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. 

Env T.ENTRY-SOPHISTICATED 

As the TOE is lower assurance IT, 

this objective is expected to be met 

primarily by the environment. 

Hence this is environmental. 

O.ENTRY-TOE: The TOE must prevent logical entry 

to the TOE using unsophisticated, technical methods, by 

persons without authority for such access. This will be 

accomplished with high effectiveness. 

TOE P.USAGE 

T.ENTRY-TOE 

O.INFO-FLOW: The TOE environment must 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. 

Env P.INFO-FLOW 

As near-term COTS, the TOE is not 

expected to provide mechanisms to 

help meet this objective. Hence this 

is environmental. 

O.KNOWN-Non-TOE: The IT other than the 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. 

Env P.KNOWN 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.KNOWN-TOE: The 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 will be 

accomplished with high effectiveness. 

TOE P.KNOWN 
CSPP-OS Rationale 28 Ver 1.0 – 4/23/03 

Security Objective Type Rationale 

O.MANAGE: Those responsible for the system (in 

conjunction with mechanisms provided by the TOE) 

must ensure that it is managed and administered in a 

manner that maintains IT security. This will be 

accomplished with moderate effectiveness. 

Joint T.ADMIN-ERROR 

Being an underlying OS, the TOE is 

expected to help in meeting this 

objective. However, since this 

applies to the whole system, other 

IT is involved. Moreover, non-IT 

controls will likely be a major part 

of meeting this objective. Hence 

this is joint. 

O.NETWORK: The system must be able to meet its 

security objectives in a distributed environment. This 

will be accomplished with high effectiveness. 

Joint P.NETWORK 

As this applies to the entire system, 

both the TOE and other IT are 

involved. Hence this is joint. 

O.OBSERVE-Non-TOE: The IT other than 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. 

Env T.OBSERVE-NON-TOE 

This explicitly refers to IT other 

than the TOE. Hence this is 

environmental. 

O.OBSERVE-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 T.OBSERVE-TOE 

O.OPERATE: Those responsible for the system (in 

conjunction with mechanisms provided by the TOE) 

must ensure that the system is delivered, installed, and 

operated in a manner which maintains IT security. This 

will be accomplished with moderate effectiveness. 

Joint T.INSTALL 

T.OPERATE 

P.TRAINING 

Being an underlying OS, the TOE is 

expected to help in meeting this 

objective. However, since this 

applies to the whole system, other 

IT is involved. Moreover, non-IT 

controls will likely be a major part 

of meeting this objective. Hence 

this is joint. 

O.PHYSICAL: Those responsible for the TOE must 

ensure that those parts of the TOE critical to security 

policy are protected from physical attack that might 

compromise IT security. This will be accomplished 

primarily via prevention with a goal of high 

effectiveness. 

Env P.PHYSICAL 

T.PHYSICAL 

Being an OS, the TOE is not 

expected to provide mechanisms 

that address this objective. Hence 

this is environmental. 
CSPP-OS Rationale 29 Ver 1.0 – 4/23/03 

Security Objective Type Rationale 

O.RECOVER-SYSTEM: The system must provide 

for recovery to a secure state following a system failure, 

discontinuity of service, or 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. 

Joint P.SURVIVE 

T.CRASH-SYSTEM 

Being an underlying OS, the TOE is 

expected to help in meeting this 

objective. However, since this 

applies to the whole system, other 

IT is involved. Moreover, non-IT 

controls will likely be a major part 

of meeting this objective. Hence 

this is joint. 

O.RECOVER-TOE: The TOE must provide for 

recovery to a secure state following a system failure, 

discontinuity of service, or detection of an insecurity. 

This will be accomplished with a high effectiveness for 

specified failures and a low effectiveness for failures in 

general. 

TOE P.SURVIVE 

T.CRASH-TOE 

O.RESOURCES: The TOE must protect itself from 

user or system errors that result in shared resource 

exhaustion. This will be accomplished via protection 

with high effectiveness.

TOE P.SURVIVE 

T.RESOURCES 

Note: This objective is classed as 

TOE due to the fact that resource 

allocation mechanisms are expected 

to be primarily contained with in 

the OS. 
CSPP-OS Rationale 30 Ver 1.0 – 4/23/03 

4. TOE FUNCTIONAL REQUIREMENTS RATIONALE 

The rationale for the set of CSPP-OS TOE functions will be based upon the following: 

• Necessary – all required. Each function either (1) meets a dependency for a necessary 

functional or assurance requirement or (2) is required in order to meet one or more security 

objectives. 

• Sufficient – meet objectives. The list of functions completely meets the IT security 

objectives and the TOE’s responsibilities with respect to environmental objectives. Also, the 

strength of function claims are appropriate for the stated effectiveness claims. 

• Correct – 

− Cover dependencies. All dependencies for each functional requirement are satisfied. 

− Operations correct. All operations on CC elements are justified and have been performed 

in accordance with CC guidelines and in accordance with intended CSPP purpose. 

− Deferred operations correct. All deferred operations are justified. 

− Extensions correct. All extensions to CC elements and components are justified and have 

been performed in accordance with CC guidelines and in accordance with intended CSPP 

purpose. 
CSPP-OS Rationale 31 Ver 1.0 – 4/23/03 

4.1 NECESSARY TOE FUNCTIONALITY 

Table 4.1-1 provides the rationale for the necessity of each TOE functional requirement included 

in CSPP. Necessity is demonstrated if, for each functional requirement, there is at least one 

security objective that cannot be met without it. This can be achieved either by directly 

addressing one or more objectives or by meeting a required dependency for another functional 

component that directly addresses security objectives. The latter case is true for functional 

requirements number 3 and 37. 

Function numbers missing from this table represent functions identified in [CSPP] that do not 

apply to this TOE. 

Table 4.1-1 Necessary TOE Functionality – Mapping Function to Requirement 

# Functional 

Component Name Dependency for Required to help address 

1 FAU_GEN.1-

CSPP Audit data Generation 

FAU_GEN.2 

FAU_SAR.1 

FAU_SEL.1-CSPP 

FAU_STG.1-

NIAP-0423 

O.ACCOUNT-TOE 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

O.DETECT-TOE 

O.DETECT 

O.OPERATE 

O.MANAGE 

O.DUE-CARE 

2 FAU_GEN.2 User Identity Generation O.ACCOUNT-TOE 

3 FAU_SAR.1 Audit Review FAU_SAR.2 

FAU_SAR.3 

4 FAU_SAR.2 Restricted Audit Review O.BYPASS-TOE 

5 FAU_SAR.3 Selectable Audit Review 

O.ACCOUNT-TOE 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

O.DETECT-TOE 

O.DETECT 

O.DUE-CARE 

O.OPERATE 

O.MANAGE 

O.COMPLY 

6 FAU_SEL.1-

CSPP Selective Audit 

O.DUE-CARE 

O.DETECT-TOE 

O.DETECT 

O.MANAGE 

O.OPERATE 

O.COMPLY 
CSPP-OS Rationale 32 Ver 1.0 – 4/23/03 

# Functional 

Component Name Dependency for Required to help address 

7 FAU_STG.1-

NIAP-0423 Protected audit trail storage 

FAU_STG.3 O.DETECT-TOE 

O.DETECT 

O.DUE-CARE 

O.COMPLY 

O.ACCOUNT-TOE 

O.BYPASS-TOE 

8 FAU_STG.3 Action in case of Possible Audit 

Data Loss 

O.ACCOUNT-TOE 

O.DUE-CARE 

O.MANAGE 

9 FDP_ACC.1 Subset Access Control 

FDP_ACF.1-CSPP 

FDP_ETC.1-CSPP 

FDP_ITC.1 

FDP_ITT.1 

FDP_UCT.1 

FDP_UIT.1 

FMT_MSA.1

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

O.COMPLY 

O.AVAILABLE-TOE 

O.RESOURCES 

10 FDP_ACF.1-

CSPP 

Security Attribute Based Access 

Control 

FDP_ACC.1 O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

O.COMPLY 

O.AVAILABLE-TOE 

O.RESOURCES 

12 FDP_ETC.1-

CSPP 

Export of user data without 

security attributes 

O.BYPASS-TOE 

O.DUE-CARE 

O.ENTRY-TOE 

O.AVAILABLE-TOE 

15 FDP_ITC.1 Import of user data without 

security attributes 

O.NETWORK 

17 FDP_RIP.1 Subset Residual Information 

protection 

O.BYPASS-TOE 

O.DUE-CARE 

19 FDP_UCT.1 Basic data exchange 

confidentiality 

O.NETWORK 

20 FDP_UIT.1 Data exchange integrity O.NETWORK 

21 FIA_AFL.1-

NIAP-0425 Authentication Failure Handling 

O.DETECT-TOE 

O.DETECT 

O.ENTRY-TOE 

O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

22 FIA_ATD.1 User Attribute Definition FIA_USB.1-NIAP0415 

O.AUTHORIZE-TOE 
CSPP-OS Rationale 33 Ver 1.0 – 4/23/03 

# Functional 

Component Name Dependency for Required to help address 

23 FIA_SOS.1 Verification of Secrets 

O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

25 FIA_UAU.1 Timing of authentication 

FIA_AFL.1-

NIAP-0425

FIA_UAU.7 

FTA_SSL.1 

FTA_SSL.2 

O.KNOWN-TOE 

26 FIA_UAU.5 Multiple authentication 

mechanisms 

O.NETWORK 

27 FIA_UAU.6 Re-authenticating O.BYPASS-TOE 

28 FIA_UAU.7 Protected authentication feedback O.BYPASS-TOE 

29 FIA_UID.1 Timing of identification 

FAU_GEN.2 

FIA_UAU.1 

FMT_SMR.1 

FTA_MCS.1-CSPP 

O.KNOWN-TOE 

30 FIA_USB.1-

NIAP-0415 User-Subject Binding 

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.DUE-CARE 

O.BYPASS-TOE 

31 FMT_MOF.1 Management of security functions 

behavior 

O.MANAGE 

O.DUE-CARE 

32 FMT_MSA.1 Management of security attributes FMT_MSA.3-

NIAP-0409 

O.MANAGE 

O.DUE-CARE 

O.AUTHORIZE-TOE 

33 FMT_MSA.3-

NIAP-0409 Static attribute initialization 

FDP_ACF.1-CSPP 

FDP_IFF.1 

FDP_IFF.8 

FDP_ITC.1 

O.MANAGE 

O.DUE-CARE 

O.AUTHORIZE-TOE 

34 FMT_MTD.1 Management of TSF data FAU_SEL.1-CSPP O.MANAGE 

O.DUE-CARE 

35 FMT_SAE.1 Time-Limited Authorization 

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

O.AUTHORIZE-TOE 

O.MANAGE 

O.DUE-CARE 
CSPP-OS Rationale 34 Ver 1.0 – 4/23/03 

# Functional 

Component Name Dependency for Required to help address 

36 FMT_SMR.1 Security roles 

FMT_MOF.1

FMT_MSA.1 

FMT_MSA.3-

NIAP-0409 

FMT_MTD.1 

FMT_SAE.1 

O.MANAGE 

O.DUE-CARE 

37 FPT_AMT.1 Abstract Machine Testing FPT.TST.1 

38 FPT_FLS.1 Failure with preservation of 

secure state 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

39 FPT_ITC.1-

CSPP 

Inter-TSF Confidentiality During 

Transmission 

O.NETWORK 

40 FPT_ITI.1-

CSPP 

Inter-TSF detection of 

modification 

O.NETWORK 

42 FPT_RCV.2-

NIAP-0406 Recovery from Failure 

O.RECOVER-TOE 

O.RECOVER-SYSTEM 

43 FPT_RPL.1-

CSPP Replay detection 

O.NETWORK 

44 FPT_RVM.1 Non-Bypassability of the TSP O.BYPASS-TOE 

45 FPT_SEP.1 TSF Domain Separation O.BYPASS-TOE 

O.DUE-CARE 

46 FPT_TDC.1 Inter-TSF basic TSF data 

consistency 

O.NETWORK 

48 FPT_TST.1 TSF Testing FPT_RCV.1 

O.DETECT-TOE 

O.DETECT 

O.DUE-CARE 

49 FRU_RSA.1 Maximum quotas O.RESOURCES 

50 FTA_LSA.1 Limitation on scope of selectable 

attributes 

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

51 FTA_MCS.1-

CSPP 

Basic limitation on multiple 

concurrent session 

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

O.DUE-CARE 

52 FTA_SSL.1 TSF-initiated session locking O.BYPASS-TOE 

O.DUE-CARE 

53 FTA_SSL.2 User-initiated locking 

O.OPERATE 

O.BYPASS-TOE 

O.DUE-CARE 

54 FTA_SSL.3 TSF-initiated termination O.BYPASS-TOE 

O.DUE-CARE 
CSPP-OS Rationale 35 Ver 1.0 – 4/23/03 

# Functional 

Component Name Dependency for Required to help address 

55 FTA_TAB.1-

CSPP Default TOE access banners 

O.ENTRY-TOE 

O.ACCOUNT-TOE 

O.DUE-CARE 

O.COMPLY 

56 FTA_TAH.1 TOE access history 

O.OBSERVE-TOE 

O.ENTRY-TOE 

O.BYPASS-TOE 

O.DUE-CARE 

O.COMPLY 

57 FTA_TSE.1 TOE session establishment 

O.ACCESS-TOE 

O.ACCESSMALICIOUS 

O.ENTRY-TOE 

58 FTP_ITC.1-

CSPP Inter-TSF trusted channel FDP_UCT.1 

FDP_UIT.1

O.NETWORK 

59 FTP_TRP.1-

CSPP Trusted path FDP_UCT.1 

FDP_UIT.1

O.NETWORK 

60 

Non-CC 

FPT_SYNCSPP.1 

TSF synchronization 

FPT_STM.1 changed to be 

synchronization requirements 

(instead of just requiring a 

mechanism that supports it) 

FPT_GEN.1 

FMT_SAE.1 

O.NETWORK 
CSPP-OS Rationale 36 Ver 1.0 – 4/23/03 

4.2 SUFFICIENT TOE FUNCTIONALITY 

4.2.1 Coverage of Security Objectives 

Table 4.2-1 indicates completeness of the functional set with respect to covering each TOE 

security objective. As the assurance level for this PP (EAL2) is low, the rigor required to justify 

coverage is also low and is provided in the form of a list of functions for each objective. 

Table 4.2-2 maps Joint security objectives to TOE security functions, identifying the TOE 

portion of meeting that objective. 
CSPP-OS Rationale 37 Ver 1.0 – 4/23/03 

Table 4.2-1 Complete Functionality - Map TOE Security Objective to TOE Functionality 

Security Objective TOE Functionality 

O.ACCESS-TOE: The TOE must provide public 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. 

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 30 FIA_USB.1-NIAP0415 

 35 FMT_SAE.1 

 50 FTA_LSA.1 

 51 FTA_MCS.1-CSPP 

 57 FTA_TSE.1 

O.ACCOUNT-TOE: The TOE must ensure, for actions under its control or 

knowledge, that all TOE users can subsequently be held accountable for 

their security relevant actions. This will be done with moderate 

effectiveness, in that it is anticipated that individual accountability might not 

be achieved for some actions. 

 1 FAU_GEN.1-CSPP 

 2 FAU_GEN.2 

 5 FAU_SAR.3 

 7 FAU_STG.1-

NIAP-0423 

 8 FAU_STG.3 

 55 FTA_TAB.1-CSPP 

O.AUTHORIZE-TOE: 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 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. 

 22 FIA_ATD.1 

 32 FMT_MSA.1 

 33 FMT_MSA.3-

NIAP-0409 

 35 FMT_SAE.1 

O.AVAILABLE-TOE: The TOE must protect itself from unsophisticated, 

denial-of-service attacks. This will include a combination of protection and 

detection with high effectiveness.

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 12 FDP_ETC.1-CSPP 
CSPP-OS Rationale 38 Ver 1.0 – 4/23/03 

Security Objective TOE Functionality 

O.BYPASS-TOE: The TOE must prevent errant or non-malicious, 

authorized software or users from bypassing or circumventing TOE security 

policy enforcement. This will be accomplished with high effectiveness. 

NOTE: This objective is limited to ‘non-malicious’ because CSPP-OS 

controls are not expected to be sufficient mitigation for the greater negative 

impact that ‘malicious’ implies. 

 4 FAU_SAR.2 

 7 FAU_STG.1-

NIAP-0423 

 12 FDP_ETC.1-CSPP 

 17 FDP_RIP.1 

 21 FIA_AFL.1-NIAP0425

 23 FIA_SOS.1 

 27 FIA_UAU.6 

 28 FIA_UAU.7 

 30 FIA_USB.1-NIAP0415 

 44 FPT_RVM.1 

 45 FPT_SEP.1 

 52 FTA_SSL.1 

 53 FTA_SSL.2 

 54 FTA_SSL.3 

 56 FTA_TAH.1 

O.DETECT-TOE: The TOE must enable the detection of TOE specific 

insecurities. The goal is high effectiveness for lower grade attacks. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 7 FAU_STG.1-

NIAP-0423 

 21 FIA_AFL.1-NIAP0425

 48 FPT_TST.1 

O.ENTRY-TOE: The TOE must prevent logical entry to the TOE using 

unsophisticated, technical methods, by persons without authority for such 

access. This will be accomplished with high effectiveness. 

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 12 FDP_ETC.1-CSPP 

 21 FIA_AFL.1-NIAP0425

 35 FMT_SAE.1 

 50 FTA_LSA.1 

 51 FTA_MCS.1-CSPP 

 55 FTA_TAB.1-CSPP 

 56 FTA_TAH.1 

 57 FTA_TSE.1 

O.KNOWN-TOE: The 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 will be 

accomplished with high effectiveness. 

 25 FIA_UAU.1 

 29 FIA_UID.1 
CSPP-OS Rationale 39 Ver 1.0 – 4/23/03 

Security Objective TOE Functionality 

O.OBSERVE-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. 

 56 FTA_TAH.1 

O.RECOVER-TOE: The TOE must provide for recovery to a secure state 

following a system failure, discontinuity of service, or detection of an 

insecurity. This will be accomplished with a high effectiveness for specified 

failures and a low effectiveness for failures in general. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 38 FPT_FLS.1 

 42 FPT_RCV.2-NIAP0406 

O.RESOURCES: The TOE must protect itself from user or system errors 

that result in shared resource exhaustion. This will be accomplished via 

protection with high effectiveness.

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 49 FRU_RSA.1 
CSPP-OS Rationale 40 Ver 1.0 – 4/23/03 

Table 4.2-2 Complete Functionality - Map Joint Security Objective to TOE Functionality 

Security Objective TOE Functionality 

O.ACCESS-MALICIOUS: The TOE controls will 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. 

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 30 FIA_USB.1-NIAP0415 

 35 FMT_SAE.1 

 50 FTA_LSA.1 

 51 FTA_MCS.1-CSPP 

 57 FTA_TSE.1 

O.COMPLY: The TOE environment, in 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. 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 7 FAU_STG.1-

NIAP-0423 

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 21 FIA_AFL.1-NIAP0425

 23 FIA_SOS.1 

 55 FTA_TAB.1-CSPP 

 56 FTA_TAH.1 

O.DETECT-SYSTEM: The TOE, in conjunction with other IT in the 

system, must enable the detection of system insecurities. The goal is high 

effectiveness for lower grade attacks. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 7 FAU_STG.1-

NIAP-0423 

 21 FDP_AFL.1 

 48 FPT_TST.1 
CSPP-OS Rationale 41 Ver 1.0 – 4/23/03 

Security Objective TOE Functionality 

O.DUE-CARE: The TOE environment, in 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. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 7 FAU_STG.1-

NIAP-0423 

 8 FAU_STG.3 

 9 FDP_ACC.1 

 10 FDP_ACF.1-CSPP 

 12 FDP_ETC.1-CSPP 

 17 FDP_RIP.1 

 21 FIA_AFL.1-NIAP0425

 23 FIA_SOS.1 

 30 FIA_USB.1-NIAP0415 

 31 FMT_MOF.1 

 32 FMT_MSA.1 

 33 FMT_MSA.3-

NIAP-0409 

 34 FMT_MTD.1 

 35 FMT_SAE.1 

 36 FMT_SMR.1 

 45 FPT_SEP.1 

 48 FPT_TST.1 

 50 FTA_LSA.1 

 51 FTA_MCS.1-CSPP 

 52 FTA_SSL.1 

 53 FTA_SSL.2 

 54 FTA_SSL.3 

 55 FTA_TAB.1-CSPP 

 56 FTA_TAH.1 

O.MANAGE: Those responsible for the system (in conjunction with 

mechanisms provided by the TOE) must ensure that it is managed and 

administered in a manner that maintains IT security. This will be 

accomplished with moderate effectiveness. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 8 FAU_STG.3 

 31 FMT_MOF.1 

 32 FMT_MSA.1 

 33 FMT_MSA.3-

NIAP-0409 

 34 FMT_MTD.1 

 35 FMT_SAE.1 

 36 FMT_SMR.1 
CSPP-OS Rationale 42 Ver 1.0 – 4/23/03 

Security Objective TOE Functionality 

O.NETWORK: The system must be able to meet its security objectives in 

a distributed environment. This will be accomplished with high 

effectiveness. 

 15 FDP_ITC.1 

 19 FDP_UCT.1 

 20 FDP_UIT.1 

 26 FIA_UAU.5 

 39 FPT_ITC.1-CSPP 

 40 FPT_ITI.1-CSPP 

 43 FPT_RPL.1-CSPP 

 46 FPT_TDC.1 

 58 FTP_ITC.1-CSPP 

 59 FTP_TRP.1-CSPP 

 60 FPT_SYN-CSPP.1 

O.OPERATE: Those responsible for the system (in conjunction with 

mechanisms provided by the TOE) must ensure that the system is delivered, 

installed, and operated in a manner which maintains IT security. This will 

be accomplished with moderate effectiveness. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 6 FAU_SEL.1-CSPP 

 53 FTA_SSL.2 

O.RECOVER-SYSTEM: The system must provide for recovery to a 

secure state following a system failure, discontinuity of service, or 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. 

 1 FAU_GEN.1-CSPP 

 5 FAU_SAR.3 

 38 FPT_FLS.1 

 42 FPT_RCV.2-NIAP0406 

4.2.2 Strength of Function (SOF) 

4.2.2.1 Minimum SOF Claim 

The basic design goal for CSPP was to produce a requirement set that is suitable for near-term 

implementation with commercial off the shelf products. The selection of basic as the minimum 

level is clearly a direct result of this goal. 

4.2.2.2 Specific SOF Claims 

The specific SOF claims are all within the category of currently, and widely available. All 

represent at least a basic level of strength. 

Note that, while not probabilistic, SOF metrics have been given for FAU_STG.1-NIAP-0423, 

FDP_RIP.1, FMT_MTD.1, and FPT_SEP.1. This extension of the CC with respect to SOF, is 

being used as a convenient means of capturing all “strength” elements in a common location of 

the PP. 
CSPP-OS Rationale 43 Ver 1.0 – 4/23/03 

4.3 CORRECT TOE FUNCTIONALITY 

4.3.1 Dependencies for TOE functionality 

Table 4.3.1-1 shows correctness of the TOE functional set with respect to meeting all 

dependencies. (Missing function numbers represent functions called out in [CSPP] that do not 

apply to this TOE.) 

Table 4.3.1-1 Correct TOE Functionality – Dependency Mapping 

# CSPP Functional 

Component Name Dependency 

CSPP-OS 

TOE 

Function # 

1 FAU_GEN.1-CSPP Audit data Generation FPT_SYN-CSPP.1 60 

2 FAU_GEN.2 User Identity Generation FAU_GEN.1-CSPP 

FIA_UID.1 

1 

29 

3 FAU_SAR.1 Audit Review FAU_GEN.1-CSPP 1 

4 FAU_SAR.2 Restricted Audit Review FAU_SAR.1 3 

5 FAU_SAR.3 Selectable Audit Review FAU_SAR.1 3 

6 FAU_SEL.1-CSPP Selective Audit FAU_GEN.1-CSPP 

FMT_MTD.1 

1 

34 

7 FAU_STG.1-

NIAP-0423 Protected audit trail storage FAU_GEN.1-CSPP 1 

8 FAU_STG.3 Action in case of Possible Audit Data 

Loss 

FAU_STG.1-

NIAP-0423 

7 

9 FDP_ACC.1 Subset Access Control FDP_ACF.1-CSPP 10 

10 FDP_ACF.1-CSPP Security Attribute Based Access 

Control 

FDP_ACC.1 

FMT_MSA.3-

NIAP-0409 

9 

33 

12 FDP_ETC.1-CSPP Export of user data without security 

attributes 

FDP_ACC.1 

FDP_IFC.1 

9 

14 

15 FDP_ITC.1 Import of user data without security 

attributes 

FDP_ACC.1 

FDP_IFC.1 

FMT_MSA.3-

NIAP-0409 

9 

14 

33 

17 FDP_RIP.1 Subset Residual Information protection none 

19 FDP_UCT.1 Basic data exchange confidentiality 

FTP_ITC.1-CSPP 

FTP_TRP.1-CSPP 

FDP_ACC.1 

FDP_IFC.1 

58 

59 

9 

13 
CSPP-OS Rationale 44 Ver 1.0 – 4/23/03 

# CSPP Functional 

Component Name Dependency 

CSPP-OS 

TOE 

Function # 

20 FDP_UIT.1 Data exchange integrity 

FTP_ITC.1-CSPP 

FTP_TRP.1-CSPP 

FDP_ACC.1 

FDP_IFC.1 

58 

59 

9 

13 

21 FIA_AFL.1-NIAP0425 Authentication Failure Handling FIA_UAU.1 25 

22 FIA_ATD.1 User Attribute Definition none 

23 FIA_SOS.1 Verification of Secrets none 

25 FIA_UAU.1 Timing of authentication FIA_UID.1 29 

26 FIA_UAU.5 Multiple authentication mechanisms none 

27 FIA_UAU.6 Re-authenticating none 

28 FIA_UAU.7 Protected authentication feedback FIA_UAU.1 25 

29 FIA_UID.1 Timing of identification none 

30 FIA_USB.1-NIAP0415 User-Subject Binding FIA_ATD.1 23 

31 FMT_MOF.1 Management of security functions 

behavior 

FMT_SMR.1 36 

32 FMT_MSA.1 Management of security attributes 

FDP_ACC.1 

FDP_IFC.1 

FMT_SMR.1 

9 

13 

36 

33 FMT_MSA.3-

NIAP-0409 Static attribute initialization FMT_MSA.1 

FMT_SMR.1 

32 

36 

34 FMT_MTD.1 Management of TSF data FMT_SMR.1 36 

35 FMT_SAE.1 Time-Limited Authorization FMT_SMR.1 

FMT_CSPP.1 

36 

60 

36 FMT_SMR.1 Security roles FIA_UID.1 29 

37 FPT_AMT.1 Abstract Machine Testing none 

38 FPT_FLS.1 Failure with preservation of secure 

state 

ADV_SPM.1 PP Sec 6.0 

39 FPT_ITC.1-CSPP Inter-TSF Confidentiality During 

Transmission none 

40 FPT_ITI.1-CSPP Inter-TSF detection of modification none 

42 FPT_RCV.2-NIAP0406 Recovery from Failure ADV_SPM.1 

AGD_ADM.1 

FPT_TST.1 

PP Sec 6.0 

PP Sec 6.0 

48 

43 FPT_RPL.1-CSPP Replay detection none 

44 FPT_RVM.1 Non-Bypassability of the TSP none 
CSPP-OS Rationale 45 Ver 1.0 – 4/23/03 

# CSPP Functional 

Component Name Dependency 

CSPP-OS 

TOE 

Function # 

45 FPT_SEP.1 TSF Domain Separation none 

46 FPT_TDC.1 Inter-TSF basic TSF data consistency none 

48 FPT_TST.1 TSF Testing FPT_AMT.1 37 

49 FRU_RSA.1 Maximum quotas none 

50 FTA_LSA.1 Limitation on scope of selectable 

attributes none 

51 FTA_MCS.1-CSPP Basic limitation on multiple concurrent 

session FIA_UID.1 29 

52 FTA_SSL.1 TSF-initiated session locking FIA_UAU.1 25 

53 FTA_SSL.2 User-initiated locking FIA_UAU.1 25 

54 FTA_SSL.3 TSF-initiated termination none 

55 FTA_TAB.1-CSPP Default TOE access banners none 

56 FTA_TAH.1 TOE access history none 

57 FTA_TSE.1 TOE session establishment none 

58 FTP_ITC.1-CSPP Inter-TSF trusted channel none 

59 FTP_TRP.1-CSPP Trusted path none 

60 FPT_SYN-CSPP.1 TSF synchronization none 
CSPP-OS Rationale 46 Ver 1.0 – 4/23/03 

4.3.2 Functional Operations 

Table 4.3.2-1 provides a rationale for most completed selections, refinements, and assignments. 

Table 4.3.2-2 provides the rationale for most deferred operations and related, completed 

operations. 

Table 4.3.2-3 provides the rationale for functional extensions, and related deferred operations. 
CSPP-OS Rationale 47 Ver 1.0 – 4/23/03 

Table 4.3.2-1 Correct Functionality – Rationale for assignment, Selection, and Refinement 

Assignment, Selection, and Refinement Performed Rationale

FAU_GEN.1.1 

b) All auditable events relevant for the [selection: basic] 

level of audit; and 

c) [assignment: 

 (1) for FPT_ITI.1 and FPT_RPL.1, the ability to 

provide statistical data representing the frequency of 

occurrence ... 

FAU_GEN.1.2 

a) Date and time of the event, type of event, subject 

identity (human user/software process, if applicable), and 

the outcome (success or failure) of the event; and 

b) For each audit event type, based on the auditable event 

definitions of the functional components included in the 

PP/ST, [selection: no other information]. 

FAU_GEN.2.1-NIAP-0410 ... the TSF shall be able to 

associate each auditable event with the individual identity 

of the user or system process that caused the event. 

FAU_SAR.1.1 The TSF shall provide [assignment:

explicitly authorized user roles, user groups, or 

individually identified users] with the capability to read 

[assignment: all information in the audit records] from the 

audit records. 

FAU_SAR.3.1 The TSF shall provide the ability to 

perform [selection: searches, sorting, and ordering] of 

audit data based upon [assignment: at a minimum, date 

and time of the event, subject (user or process), type of 

event, and success or failure]. 

FAU_SEL.1.1 

a) [selection: Object identity, user identity, subject 

identity, host identity, and/or event type]; 

b) [assignment: success or failure.] 

FAU_STG.1.2-NIAP-0423 The TSF shall be able to 

[selection: prevent and detect] unauthorized modifications 

to the audit records in the audit trail. 

• Basic is an appropriate level for a COTS 

baseline requirement set 

• In order to see patterns of network 

activity, it is necessary to be able to 

represent the statistical nature of integrity 

and replays - as these may be due to 

network performance issues and not due to 

attacks. 

• Clarify that process as well as human 

user is to be identified. 

• No other information is necessary. 

• Clarify that process as well as human 

user is to be identified. 

• It is within the scope of COTS to 

provide the granularity of authorization in 

this assignment. 

• As a baseline, it is considered 

reasonable to allow reading of audit 

information. 

• All three CC options for the selection 

are appropriate. 

• A minimal set of rules is provided, 

which is considered within scope for COTS. 

• All CC options are appropriate for this 

selection. 

• These are the essential other elements to 

be recorded. 

• Want, in the baseline requirement, 

mechanisms to both prevent and detect. 
CSPP-OS Rationale 48 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

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

FDP_ACC.1.1 The TSF shall enforce the [assignment:

CSPP access control SFP] on [assignment: all subjects, all 

operating system controlled files (to include all 

communications mechanisms – for internal or external 

communications – that are implemented as objects 

controlled by the file system), and all access requests to 

these files]. 

FDP_ACF.1.1-NIAP-0416 The TSF shall enforce the 

[assignment: CSPP access control SFP] to objects based 

on the following: [assignment: for the subjects and 

objects identified in FDP_ACC.1.1, the user/process 

identity, group membership, subject privileges, and, if 

included in the object authorization information, access 

restrictions such as the time-of-day and port-of-entry]. 

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: by checking 

the authorizations associated with the object for the entries 

of that subject]. 

FDP_ACF.1.3 The TSF shall explicitly authorise access 

of subjects to objects based on the following additional 

rules: [assignment: none]. 

FDP_ACF.1.4 The TSF shall explicitly deny access of 

subjects to objects based on the following additional rules:

[assignment: none]. 

FDP_ETC.1.1 The TSF shall enforce the [assignment:

CSPP access control SFP] when exporting user data, 

controlled under the SFP(s), outside of the TSC. 

FDP_ITC.1.1 The TSF shall enforce the [assignment:

CSPP access control] when importing user data, controlled 

under the SFP, from outside the TSC. 

FDP_ITC.1.3 The TSF shall enforce the following the 

following rules when importing user data controlled under 

the SFP from outside the TSC: [assignment: the TOE 

shall provide for incoming information channels, for 

example TCP port numbers, that are under the control of 

• This is considers a reasonable, baseline 

requirement. 

• It is considered more reasonable to 

make this a parameter than a fixed value. 

• This is the SFP to be enforced. 

• The COTS OS will likely be able to 

accomplish this scope of access control. 

• This is the SFP to be enforced. 

• This assignment is considered within 

scope for near-term COTS products. 

• Further information does not seem 

needed, in light of that provided with the 

SFP description. 

• None appear to be needed. 

• Refinement is strictly editorial. 

• None appear to be needed. 

• This is the SFP to be enforced. 

• This is the SFP to be enforced. 

• This is a reasonable expectation for 

COTS. 
CSPP-OS Rationale 49 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

the TSF and for which general application programs do 

not have access]. 

FDP_RIP.1.1 The TSF shall ensure that any previous 

information content of a ... [assignment: shared memory 

and file storage space]. 

FDP_UCT.1.1 The TSF shall support the enforcement of

the [assignment: CSPP access control SFP] to be able to 

[selection: transmit and receive] objects in a manner 

protected from unauthorized disclosure.

FDP_UIT.1.1 The TSF shall support the enforcement of

the [assignment: CSPP access control SFP] to be able to 

[selection: transmit and receive] user data in a manner 

protected from [selection: modification, deletion, 

insertion, and replay] errors. 

FDP_UIT.1.2 The TSF shall be able to determine on 

receipt of user data, whether [selection: modification, 

deletion, insertion, or replay] has occurred. 

FIA_AFL.1.1-NIAP-0425 The TSF shall detect when 

[selection: an authorized administrator configurable 

integer] unsuccessful authentication attempts over an 

authorized user configurable length of time occur related 

to [assignment: initial account login, re-authentication 

after initial login, and ...]]. 

FIA_SOS.1.1 The TSF shall provide a mechanism to 

verify that secrets meet [assignment: for passwords, the 

application note below and the requirements of FIPS PUB 

112; for other ... 

FIA_UAU.1.1 The TSF shall allow [assignment: no 

actions other than anonymous access to resources 

explicitly authorized for the type of anonymous access 

requested and ... 

FIA_UAU.5.1 The TSF shall provide support for

[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 

• These are the shared resources in a 

typical OS. 

• The OS can support but not fully 

enforce. 

• This is the SFP to be enforced. 

• Both CC choices are appropriate here. 

• The OS can support but not fully 

enforce. 

• This is the SFP to be enforced. 

• Both CC choices are appropriate here. 

• All CC choices are appropriate here. 

• All four CC choices are considered 

appropriate. 

• It is desired that this be configurable, 

rather than a number set in the PP. 

• Some time period seems to be 

appropriate. 

• These are the typical events that need to 

be covered. The remainder of the 

assignment is covered under ‘deferred 

operations’. 

• This is considered reasonable for 

passwords. The remainder of the assignment 

is covered under ‘deferred operations’. 

• This is the basic statement of need. 

• OS must support, not necessary fully 

provide. 

• This is a general statement of the 

desired need. 
CSPP-OS Rationale 50 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

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

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

FIA_UAU.7.1 The TSF shall not provide [assignment: 

any indication of success or failure nor clear-text display 

of any secret authenticator] to the user while the 

authentication is in progress. 

FIA_UID.1.1 The TSF shall allow [assignment: no 

actions other than anonymous access to resources 

explicitly authorized for the type of anonymous access 

requested and ... 

FIA_USB.1.1-NIAP-0415 The TSF shall associate the 

following user security attributes with subjects acting on 

behalf of that user: [assignment: all user security 

attributes required to enforce access control and 

information flow control policies and to fully meet goals 

for individual accountability]. 

FMT_MOF.1.1 The TSF shall restrict the ability to 

[selection: determine the behaviour of, disable, enable, 

modify the behavior of] the functions [assignment:

included as requirements for CSPP-OS and for which the 

common criteria indicates security management 

suggestions, and ... 

FMT_MSA.1.1 The TSF shall enforce the [assignment: 

CSPP access control SFP] to restrict the ability to 

[selection: change_default, modify, delete] and

[assignment: “null”] the security attributes [assignment:

all attributes used to define the security state of the system, 

to control the security functionality, to make access 

control decisions, and ... to [assignment: for discretionary 

attributes, the owner of the attribute; for both discretionary 

• This is a general statement of the 

desired need. The remainder of the 

assignment is covered under ‘deferred 

operations’. 

• These are the basic needs for reauthentication. Other needs are addressed in 

the deferred operation. 

• Refinement recasts requirement in the 

negative as that is the primary need here. 

• This is a reasonable, common 

requirement. 

• This is the basic statement of need. 

• These appear to be the essential 

attributes to achieve desired goals 

• All four CC choices are appropriate. 

• The CC suggestions will be followed. 

Other needs are addressed in the deferred 

operation. 

• This is the SFP to be enforced. 

• All CC choices, except query are 

appropriate, with no additional options per 

the assignment. Query is handled by 

iteration, see below. 

• The refinement “and” is editorial. 

• This provides the description of the 

need. Additional details are covered in the 
CSPP-OS Rationale 51 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

and non-discretionary attributes, an explicitly specified set 

of users, ...]. ... See iteration for restriction on read access 

to authenticator values. 

Iteration: 

FMT_MSA.1.1 The TSF shall enforce the [assignment: 

CSPP access control SFP] to restrict the ability to 

[selection: query] [assignment: “null”] the security 

attributes [assignment: current and past values of 

authenticators, ] to [assignment: no users and only to 

software processes requiring this knowledge]. 

FMT_MSA.3.1-NIAP-0409 The TSF shall enforce the 

[assignment: CSPP access control SFP] to provide 

[selection: restrictive] default values for object security 

attributes that are used to enforce the SFP. 

FMT_MSA.3.2 The TSF shall allow the [assignment: 

data object owner and other authorized users] to specify 

alternate initial values to override the default values when 

an object or information is created. 

FMT_MTD.1.1 The TSF shall restrict the ability to 

[selection: change_default, read, modify, delete, or clear] 

the [assignment: all internal TSF data structures that are 

security critical] to [assignment: software processes 

explicitly authorized to access this data]. 

FMT_SAE.1.1 The TSF shall restrict the ability to specify 

an expiration time for [assignment: user account and 

authenticators and ... 

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

FMT_SMR.1.1 The TSF shall maintain the roles 

[assignment: privileged user (for example the equivalent 

of the Unix root) and/or ... 

FPT_AMT.1.1 The TSF shall run a suite of tests 

[selection: during initial start-up and at the request of 

deferred operation. 

• This is considered an appropriate 

statement of the need. 

• The refinement clarifies the use of 

iteration. 

• This is the SFP to be enforced. 

• The issue here is reading. 

• The values of concern are 

authenticators. 

• This information is not provided to the 

human interface and is limited to explicitly 

authorized processes. 

• This is the SFP to be enforced. 

• A restrictive default is desired. 

• The owner and privileged users should 

be able to assign these values. 

• All CC selections are appropriate. 

• This is a general description of the 

scope. 

• Explicit authorization is required. 

• This is a basic set of actions to be 

covered. Additional actions are covered by 

the deferred operation. 

• This requires explicit specification 

which is accomplished in conjunction with 

the deferred operation. 

• This is considered a reasonable baseline 

requirement. Additional details are covered 

by the deferred operation. 

• This is a reasonable baseline 

requirement with additional possibilities 

through the deferred operation. 

• These two CC selections are considered 

minimal. 
CSPP-OS Rationale 52 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

explicitly authorized security administrator(s) or security 

administrator role(s)] to demonstrate the correct operation 

of the security assumptions provided by the abstract 

machine which underlies the TSF. 

FPT_ITC.1.1-CSPP The TSF shall support the protection 

of ... transmitted from the TSF to a remote trusted IT 

product from unauthorized disclosure during transmission. 

FPT_ITI.1.1-CSPP The TSF shall support the capability 

to detect modification of ... 

FPT_ITI.1.2-CSPP The TSF shall support the capability 

to verify the integrity of ... 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. ... 

FPT_RPL.1.2 The TSF shall perform [assignment: the 

action of discarding duplicates and providing the 

capability to audit this action in a statistical manner] when 

replay is detected. 

FPT_RVM.1.1 The TSF shall ensure, to at least a level of 

confidence appropriate for a lower-level of assurance (i.e., 

EAL-CSPP), that TSP enforcement functions are invoked 

and succeed before each function within the TSC is 

allowed to proceed. 

FPT_SEP.1.1 The TSF shall maintain a security domain 

for its own execution that protects, at least to the extent 

such protection can be reasonably expected from a lowerlevel of assurance (i.e., EAL-CSPP), it from interference 

and tampering by untrusted subjects. 

Refinement: 

FPT_TDC.1.3-CSPP The TSF shall support 

maintaining consistent data between this TSF and 

another trusted IT product for the data items specified 

in FPT_TDC.1.1 in accordance with the rules 

specified in FPT_TDC.1.2. 

FPT_TST.1.1 The TSF shall run a suite of self tests 

[selection: during initial start-up and at the request of 

• Providing clarification for “authorized 

user”. 

• The OS can support, but may not be 

able to fully implement this function. 

• The OS can support, but may not be 

able to fully implement this function. 

• The OS can support, but may not be 

able to fully implement this function. 

• This is the most practical response. 

• This is the most practical response. 

• This refinement clarifies the degree of 

confidence expected in this open-ended 

requirement. 

• This refinement clarifies the degree of 

confidence expected in this open-ended 

requirement. 

• This is a refinement, as the new element 

only clarifies the intent of the component. 

The CC component imposes requirements 

related to consistent syntax and 

interpretation, but does not, as this new 

element adds, require mechanisms to ensure 

that information is kept current and 

consistent between trusted products. 

• These two CC selections are considered 

minimal. 
CSPP-OS Rationale 53 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

explicitly authorized security administrator(s) or security 

administrator role(s)] [assignment: “null”] to demonstrate 

the correct operation of the TSF. 

FRU_RSA.1.1-CSPP The TSF shall enforce maximum 

quotas of the following resources: [assignment: all OScontrolled, multi-user or multi-process resources such as 

memory, disk space, and inter-processor communications 

paths] that ... 

FTA_MCS.1.2 If the TOE is to restrict the maximum 

number of concurrent sessions, the TSF shall enforce 

[assignment: an authorized user selected maximum 

number of] sessions per user. 

FTA_SSL.1.1 The TSF shall lock an interactive session 

after [assignment: an authorized user specified time 

interval of user inactivity] ... 

FTA_SSL1.2 The TSF shall require the following events 

to occur prior to unlocking the session: [assignment: user 

authentication]. 

FTA_SSL.2.2 The TSF shall require the following events 

to occur prior to unlocking the session: [assignment: user 

authentication]. 

FTA_SSL.3.1 The TSF shall terminate an interactive 

session after [assignment: an authorized user specified 

time interval of user inactivity]. 

FTA_TAH.1.1 Upon successful session establishment, the 

TSF shall display the [selection: date, time, method, and

location] of the last successful session establishment to the 

user. 

FTA_TAH.1.2 Upon successful session establishment, the 

TSF shall display the [selection: date, time, method, and

location] of the last unsuccessful attempt to session 

establishment and the number of unsuccessful attempts 

since the last successful session establishment. 

FTA_TSE.1.1 The TSF shall be able to deny session 

establishment based on [assignment: attributes that can be 

set by explicitly authorized security administrator(s) or 

security administrator role(s), including user identity, port 

• Providing clarification for “authorized 

user”. 

• No other conditions are required in the 

baseline specification. 

• These are the basic shared resources. 

• Refinement clarifies intent with 

extended element. 

• Consider it better to make this a 

parameter rather than a specified number. 

• Consider it better to make this a 

parameter rather than a specified number. 

• This is the baseline need. 

• This is the baseline need. 

• Consider it better to make this a 

parameter rather than a specified number. 

• All four CC choices are appropriate. 

• All four CC choices are appropriate. 

• These are the basic elements upon 

which session denial might be based. 
CSPP-OS Rationale 54 Ver 1.0 – 4/23/03 

Assignment, Selection, and Refinement Performed Rationale

of entry, time of day, day of the week, and ... 

FTP_TRP.1.1-CSPP The TSF shall provide a 

communication path between itself and [selection: local] 

users ... 

FTP_TRP.1.2 The TSF shall permit [selection: local 

users] to initiate communication via the trusted path. 

(Note that this requirement does not prevent the TSF from 

initiating communications, only that the TOE must allow 

local users to do so.)

FTP_TRP.1.3 The TSF shall require the use of the trusted 

path for [selection: initial user authentication,] 

[assignment: user re-authentication, and ... 

• ‘Local’ is the reasonable expectation for 

near-term COTS. 

• These choices are the reasonable ones 

for near-term COTS. 

• The refinement clarifies the intent of 

this requirement in CSPP-OS. 

• These two choices are the ones mostly 

likely to be applicable. (The deferred 

assignment provides for the possibility of 

more.) 
CSPP-OS Rationale 55 Ver 1.0 – 4/23/03 

Table 4.3.2-2 Correct Functionality – Rationale for Deferring Operations to ST 

Functional Operations Deferred to ST Rationale for Deferring to ST

FAU_GEN.1.1 

c) [assignment: 

 (2) other auditable events specific to the ST design as 

listed in the following ST assignment: [ST assignment: 

any other audit events required by specifics of the ST 

design in order to meet PP requirements.] The ST 

rationale shall provide a basic justification, showing that 

the ST assignment, to include a “null” assignment, is 

complete.

FDP_RIP.1.1 The TSF shall ensure that any previous 

information content of a resource is made unavailable 

upon the [assignment: following: [ST selection:

allocation of the resource to, deallocation of the resource 

from, both]] the following objects .... The ST rationale 

shall provide a basic justification, showing that the ST 

selection is consistent with other aspects of the ST design, 

resulting in a secure solution.

FIA_AFL.1.1-NIAP-0425 The TSF shall detect when ... 

occur related to [assignment: ..., and list of other events 

given in the following ST assignment: [ST assignment: as 

required by PP, list of ST specific authentication events]]. 

The ST rationale shall provide a basic justification that the 

ST assignment, including a “null” assignment, includes all

events specific to the ST design that require authentication 

failure handling.

FIA_AFL.1.2 After the defined number of unsuccessful 

authentication attempts has been met or surpassed, the 

TSF shall [assignment: perform the following ST selected 

actions: [ST selection: disable the account (requiring it to 

be re-enabled by an authorized user), cause each 

subsequent logon attempt to be delayed for increasing 

periods of time up to a maximum number of additional 

attempts at which time the account is disabled pending 

authorized user action to re-enable, allow either option 

based upon a configuration choice by an authorized user]

]. As any selection, other than “null”, is acceptable and 

the purpose here is to ensure that an explicit choice is both 

made and announced, the ST rationale need not justify the 

choice made.

FIA_ATD.1.1 The TSF shall maintain the following list 

of security attributes belonging to individual users: 

[assignment: user name, authenticator and the following 

ST specific attributes required by the design of the ST: 

[ST assignment: as required by PP, list of any ST specific 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• It does not matter at the PP level of 

abstraction which is selected, as long as the 

selection is not contrary to specifics of the 

ST design. 

• The ST author is required to justify the 

selection made. 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• It is considered necessary to know the 

capabilities of the TOE, but not to specify 

which action(s) are provided, as long as at 

least one is present. (The set of choices 

provided represents commonly available 

choices.) 

• The refinement defines what is expected 

with respect to ST justification. 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 
CSPP-OS Rationale 56 Ver 1.0 – 4/23/03 

Functional Operations Deferred to ST Rationale for Deferring to ST

security attributes]]. The ST rationale shall provide a 

basic justification for the assignment made, including 

“null”, showing that it is the complete list required to 

maintain secure operation.

FIA_SOS.1.1 The TSF shall provide a mechanism to 

verify that secrets meet [assignment: ...; for other secrets 

specific to the ST design, the metrics called out in the 

following ST assignment: [ST assignment: as required by 

PP, any ST specific, defined quality metrics]]. The ST 

rationale shall provide a basic justification that the ST 

assignment covers all ST specific secrets essential for 

secure operation and that the metric(s) given are 

appropriate for meeting the PP design goals.

FIA_UAU.1.1 The TSF shall allow [assignment: ... and 

the following ST selection [ST selection: as permitted by 

PP, local shut down of the operating system]] on behalf of 

the user to be performed before the user is authenticated. 

As the inclusion of this action is permitted, but not 

required, and the purpose here is only to ensure that the ST 

choice is explicit, the ST rationale does not need to include 

a justification for the choice made.

FIA_UAU.5.2 The TSF shall authenticate any user’s 

claimed identity according to the [assignment: ..., 

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.

FIA_UAU.6.1 The TSF shall re-authenticate the user 

under the conditions [assignment: ..., 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.

FIA_UID.1.1 The TSF shall allow [assignment: ... and 

the following ST selection [ST selection: as allowed by 

PP, local shut down of the operating system]] on behalf of 

the user to be performed before the user is identified. As 

the operation is permitted rather than required, and the 

purpose here is to ensure that the choice is explicit, the ST 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• It is considered sufficient to know 

whether the action listed is present in the 

TOE. 

• This defines what justification is to be 

provided by the ST author. 

• Specifics of the TOE design may result 

in a preferred choice for the selection. 

• At the level of abstraction of the PP any 

selection is acceptable provided it is 

justified in the ST. 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• It is considered sufficient to know 

whether the action listed is present in the 

TOE. 

• This defines what justification is to be 

provided by the ST author. 
CSPP-OS Rationale 57 Ver 1.0 – 4/23/03 

Functional Operations Deferred to ST Rationale for Deferring to ST

rationale does not need to include a justification for the 

choice made.

FMT_MOF.1.1 The TSF shall restrict the ability to ... the 

functions [assignment: ..., and also all items listed in the 

following ST assignment: [ST assignment: as required by 

PP, list of ST functions and mechanisms resulting from 

specifics of the ST design]] 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]]. The 

ST rationale must provide a basic justification for the 

assignment made, to include “null”. The ST rationale 

must also provide a basic justification for the selection 

made, indicating how it supports enforcement of least 

privilege.

FMT_MSA.1.1 The TSF shall enforce the ... the security 

attributes [assignment: ..., and those listed in the 

following ST assignment: [ST assignment: as required by 

PP, list of security attributes requiring management and 

arising from the specifics of the ST design]] to 

[assignment: for discretionary attributes, the owner of the 

attribute; for both discretionary and non-discretionary 

attributes, an explicitly specified set of users, enforcing 

least privilege on the basis of the following ST selection: 

and [ST selection: security administrators, security 

administrator roles, both]]. The ST rationale shall provide 

a basic rationale for the assignment made, showing it to be 

complete. Also, the ST rationale shall provide a basic 

justification for the selection made, indicating how it 

enforces least privilege. ... 

FMT_SAE.1.1 The TSF shall restrict the ability to specify 

an expiration time for [assignment: ... 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]]. 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, 

indicating how it enforces least privilege.

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• Specifics of the TOE design may result 

in a preferred choice for the selection. 

• This defines what justification is to be 

provided by the ST author. 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• Specifics of the TOE design may result 

in a preferred choice for the selection. 

• This defines what justification is to be 

provided by the ST author 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• Specifics of the TOE design may result 

in a preferred choice for the selection. 

• This defines what justification is to be 

provided by the ST author 
CSPP-OS Rationale 58 Ver 1.0 – 4/23/03 

Functional Operations Deferred to ST Rationale for Deferring to ST

FMT_SAE.1.2 For each of these security attributes, TSF 

shall be able to ... 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. The ST rationale 

shall provide a basic justification for the assignment made, 

to include “null”, showing that it is sufficient to enable 

secure operation.

FMT_SMR.1.1 The TSF shall maintain the roles 

[assignment: ... and/or the following set of ST specific 

roles that the ST author wishes to specify as not 

conflicting with CSPP goals and useful in implementing 

these goals: [ST assignment: as allowed by PP, the ST 

specific authorized identified roles]]. The ST rationale 

shall provide a basic justification for the assignment made, 

showing that the roles specified do not conflict with PP 

design goals.

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

FPT_RCV.2.1-NIAP-0406 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. 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_TDC.1.1 The TSF shall provide the capability to 

consistently interpret [assignment: information critical to 

security in maintaining a consistent state representation 

across distributed systems as identified in [ST 

assignment: list of TSF data types] when shared between 

the TSF and another trusted IT product. The ST rationale 

• The ST will provide information about 

the security functions and mechanisms not 

available to the PP author. 

• By requiring justification from the ST 

author, the validity of the completion can be 

determined. 

• Specifics of the TOE design may result 

in a preferred choice for the assignment. 

• At the level of abstraction of the PP any 

assignment is acceptable provided it is 

justified in the ST as being consistent with 

other CSPP requirements. 

• The specifics of the ST design will 

likely dictate which failures from which the 

system can reasonably expect to recover. 

• It is considered most important to have 

an explicit list than to specify what the list 

must contain. The ST must, however, 

support the claim that recovery is possible. 

• The specifics of the ST design will 

likely dictate which failures from which the 

system can reasonably expect to recover. 

• It is considered most important to have 

an explicit list than to specify what the list 

must contain. The ST must, however, 

support the claim that recovery is possible. 

• It is anticipated that the specifics of the 

ST design will play a role in the 

determination of the specific data elements. 

• This defines the justification that the ST 

author must provide. This also provides 
CSPP-OS Rationale 59 Ver 1.0 – 4/23/03 

Functional Operations Deferred to ST Rationale for Deferring to ST

shall provide a basic justification, showing that the ST 

assignment is complete. It is acceptable to provide a 

broader definition, rather than selecting only a subset -

provided the rationale shows that the security critical 

elements are indeed a subset of those chosen. 

FPT_TDC.1.2 The TSF shall use [assignment: the 

following interpretation rules: [ST assignment: list of 

interpretation rules to be applied by the TSF] when 

interpreting the TSF data from another trusted IT product. 

The ST rationale shall provide a basic justification, 

showing that the list of rules is comprehensive and 

internally self-consistent.

FRU_RSA.1.1-CSPP The TSF shall enforce maximum 

quotas of the following resources: ... that [ST selection: 

an individual user, a defined group of users, subjects] can 

use [ST selection: simultaneously, over a specified period 

of time]. 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.

FTA_LSA.1.1 The TSF shall provide the capability to

restrict the scope of these session security attributes:

[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]]. The ST rationale shall provide 

a basic justification, showing that the ST specific 

assignments are sufficient to restrict the security critical 

attributes.

FTA_TSE.1.1 The TSF shall be able to deny session 

establishment based on [assignment: attributes that can be 

set by explicitly authorized security administrator(s) or 

security administrator role(s), including user identity, port 

of entry, time of day, day of the week, and any [ST 

assignment: ST specific attributes]. The ST rationale 

must show that the ST assignment is complete.

FTP_ITC.1.2 The TSF shall permit [ST selection: the 

TSF, the remote trusted IT product] to initiate 

communication via the trusted channel. The ST rationale 

guidance on what constitutes an acceptable 

completion. 

• It is anticipated that the specifics of the 

ST design will play a role in the 

determination of the specific data elements. 

• This defines the justification that the ST 

author must provide. 

• For both selections, the ST author may 

select as appropriate, with constraints given 

in the refinement. 

• This defines the justification that the ST 

author must provide. 

• The OS must provide the capability to 

restrict, rather than enforce with without the 

possibility of user choice to the contrary. 

• Second refinement (‘these’) is editorial. 

• Specifics of the ST design play an 

important role in determining both the 

session security attributes and what is used 

to control these attributes. 

• The refinement defines the required 

justification. 

• ST design will likely play a role. 

• This defines the required justification. 

• This is deferred because the ST design 

will play a major role. 

• This defines the required justification. 
CSPP-OS Rationale 60 Ver 1.0 – 4/23/03 

Functional Operations Deferred to ST Rationale for Deferring to ST

shall provide a basic justification, showing that the ST 

selection is appropriate for maintaining secure operation in 

the intended environment.

FTP_ITC.1.3 The TSF shall initiate communication via 

the trusted channel for [assignment: the following 

functions: [ST assignment: list of functions for which a 

trusted channel is required]]. The ST rationale shall 

provide a basic justification, showing that the ST 

assignment is a complete list, as required to mitigate 

insecurities in the intended operational environment for 

the TOE.

FTP_TRP.1.3 The TSF shall require the use of the trusted 

path for ... [assignment: ..., and the following: [ST 

assignment: list of additional services for which a trusted 

path is required, as determined during the ST design and 

development]]. The ST rationale shall provide a basic 

justification, showing that the ST assignments are 

complete, with regard to mitigation in the intended 

operational environment for the TOE.

• This is deferred because the ST design 

will play a major role. 

• This defines the required justification. 

• This is deferred because the ST design 

will play a major role. 

• This defines the required justification. 
CSPP-OS Rationale 61 Ver 1.0 – 4/23/03 

Table 4.3.2-3 Correct Functionality – Rationale for Functional Extensions 

Functional Extension Rationale for the Extension 

Extension: 

FAU_GEN.1-CSPP.3 When the TSF provides 

application support it shall support an application 

program interface that allows a privileged application 

to append data to the security audit trail or to an 

application-specified alternative security audit trail. 

Extension:

FAU_SEL.1-CSPP.2 The TSF shall provide only 

explicitly authorized user roles, user groups, or 

individually identified users with the ability to select or 

display which events are to be audited. 

FAU_SEL.1-CSPP.3 The TSF shall provide the 

capability of FAU_SEL.1-CSPP.2 at any time during the 

operation of the TOE. 

Extension: 

FDP_ACF.1-CSPP.5 The TSF shall provide the 

capability to assign a user to be a member of more 

than one user group simultaneously. 

FDP_ACF.1-CSPP.6 The TSF shall enforce the rules 

for authorizing and denying access based upon the 

CSPP precedence rules. 

Extension: 

FDP_ETC.1-CSPP.3 The TSF shall shall provide for 

outgoing information channels, for example TCP port 

numbers, that are under the control of the TSF and for 

which general application programs do not have access, 

when exporting user data controlled under the SFP 

outside the TSC. 

FPT_ITI.1.1-CSPP The TSF shall ... 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.] 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 

• An API for audit is a reasonable 

baseline requirement that is not explicitly 

captured by any CC functional elements. 

• The ‘management’ requirement, while 

deleted from the final version of the CC, is 

considered appropriate and as a nice 

‘handle’ for the extension below. 

• It is considered reasonable to include 

this non-CC requirement. 

• This common capability is of great 

usefulness but not currently captured within 

the CC. 

• This is considered to be a reasonable, 

baseline requirement, but is not presently in 

the CC. 

• This is a reasonable requirement that is 

captured in the CC for incoming 

information (FDP_ITC) but is missing for 

outgoing information. 

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• The ST design will play a role here. 

• It is conceivable that meeting ITI.1.2 

will be satisfactory. 

• This defines the justification required 

and also provides information on what 

constitutes an acceptable completion. 
CSPP-OS Rationale 62 Ver 1.0 – 4/23/03 

Functional Extension Rationale for the Extension 

acceptable to protect all data, rather than selecting specific 

data elements. 

FPT_ITI.1.2-CSPP The TSF shall ... 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 .... 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. 

FPT_RPL.1.1-CSPP The TSF shall detect replay for the 

following entities [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]]. The ST rationale 

shall provide a basic justification, showing that the ST 

assignment is complete. It is acceptable to protect all 

communications, rather than selecting specific entities. 

Extension: 

FPT_SYN-CSPP.1.1 The TSF shall support the 

system capability to provide the capability to 

synchronize distributed TSF elements and to associate 

audit event records produced by multiple TSF entities. 

FTA_MCS.1.1-CSPP 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. 

FTP_ITC.1.1-CSPP The TSF shall provide a 

communication channel between itself and a remote 

trusted IT product that is logically distinct from other 

communication channels and provides assured 

identification of its end points and protection of the 

[extension: security information as required to mitigate 

against insecurities resulting from both attacks and 

unintentional modification, to include the following: [ST 

assignment: other security information identified in the ST 

design and development]] channel data from modification 

and [extension: identification and authentication data and 

the following other security information: [ST assignment:

other security information identified in the ST design and 

development] channel data from disclosure. The ST 

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• This defines the justification required 

and also provides information on what 

constitutes an acceptable completion. 

• The ST design will play a role here. 

• This defines the justification required 

and also provides information on what 

constitutes an acceptable completion. 

• This component is used in lieu of 

FPT_STM to specify the need instead of a 

mechanism which could help meet the need. 

(Refinement is applied to component as 

stated in [CSPP].) 

• Since limiting concurrent sessions is 

policy specific, it is considered appropriate 

to make limiting concurrent sessions a 

parameter. 

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• This defines the justification required. 
CSPP-OS Rationale 63 Ver 1.0 – 4/23/03 

Functional Extension Rationale for the Extension 

rationale shall provide a basic justification, showing that 

the ST assignments are complete, with regard to mitigation 

in the intended operational environment for the TOE.

FTP_TRP.1.1-CSPP The TSF shall protection of the 

[extension: security information as required to mitigate 

against insecurities resulting from both attacks and 

unintentional modification, to include the following: [ST 

assignment: other security information identified in the ST 

design and development]] communicated data from 

modification and [extension: identification and 

authentication data and the following other security 

information: [ST assignment: other security information 

identified in the ST design and development]

communicated data from disclosure. The ST rationale 

shall provide a basic justification, showing that the ST 

assignments are complete, with regard to mitigation in the 

intended operational environment for the TOE.

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• Rather than “all data”, it is considered 

more realistic to narrow the scope. 

• The ST design will play a role here. 

• This defines the justification required. 
CSPP-OS Rationale 64 Ver 1.0 – 4/23/03 

5. ASSURANCE REQUIREMENTS RATIONALE 

5.1 NECESSARY ASSURANCES 

5.1.1 Basic Assurance Goals 

CSPP-OS provides a definition for near-term achievable, low evaluation cost, COTS security. In 

keeping with this purpose, the assurance components of this protection profile have been selected 

to (1) require only current best-practice development actions and (2) include minimal third-party 

analysis. The rationale for each is given below. 

The need to constrain requirements for developer actions is clearly evident in order to meet 

“near-term achievable”. The current COTS development standards do not include security 

engineering to any significant degree. Adding such techniques and processes would require 

changes to development practices and personnel capabilities. Since such changes are not 

considered likely, CSPP-OS has been developed with that in mind. 

The rationale for limiting third-party analysis is: 

a. Technical basis. In keeping with current best commercial practice, CSPP-OS 

requirements do not include significant security engineering. Therefore, there is no 

reasonable expectation of high security quality with respect to effectiveness in the face of 

competent threat agents. Moreover, the most likely internal structures for CSPP-OS 

components make comprehensive evaluation extremely difficult, if not, for all practical 

purposes, impossible. Hence, the probability of exploitable vulnerabilities in CSPP-OS 

compliant components is not significantly different than that of non-compliant COTS. 

Since there is no reasonable expectation for high security quality in CSPP-OS 

components (even with an extensive evaluation), there is no technical basis for extensive 

evaluation of CSPP-OS class components. 

b. Business-case basis. In order to support a good business case, CSPP-OS evaluation must 

be achievable without negative impact on customer acceptance over non-evaluated 

competition. Since CSPP-OS vendors cannot reasonably claim high security quality, 

CSPP-OS evaluation is unlikely to be a discriminator overcoming cost and time-tomarket. Hence, the CSPP-OS evaluation provides a market advantage if evaluated 

products are competitive against non-evaluated products on the basis of cost and time-tomarket. Therefore, a CSPP-OS evaluation must be low cost and of short duration. 
CSPP-OS Rationale 65 Ver 1.0 – 4/23/03 

5.1.2 EAL Selection 

This section provides a rationale for the selection of EAL2 as the base EAL for EAL-CSPP. 

This will be accomplished by first describing why EAL1 is not sufficient and then describing 

why EAL3 is too much for the basic goals for CSPP-OS. Since the EALs are strictly 

hierarchical, the rationale for not selecting EAL4 through EAL7 is covered by that given for 

EAL3. 

 a. EAL1 not sufficient. Table 5.1.2-1 lists the assurance components contained in EAL2 

which are not a part of EAL1, describing why they are required assurances for CSPP-OS. Since 

EAL1 lacks these components, it is not sufficient as the base EAL. 

Table 5.1.2-1 Necessary Assurance - EAL1 Not Sufficient 

EAL2 Component 

not in EAL1 Component Title Why Required in CSPP-OS 

ACM_CAP.2 

(EAL-1 has CAP.1) Configuration items 

It is well within best commercial practice 

for a security product vendor to have CM 

documentation and to be able to uniquely 

identify all configuration items. Since it 

is reasonable to expect this, the assurance 

it offers should be a part of CSPP-OS. 

ADO_DEL.1 Delivery procedures 

This component requires that the vendor 

have procedures for “secure” delivery to 

the customer. Since (1) software piracy 

controls will be implemented and (2) the 

CSPP-OS requirement does not specify a 

specific set of procedures, this component 

is within the range of best commercial 

practice and should be a part of CSPP-OS. 

ADO_IGS.1 Installation, generation, and startup procedures 

It is necessary and reasonable to expect an 

IT security product to include guidance to 

the user on secure installation, generation, 

and start-up. Therefore this must be a part 

of an effective CSPP-OS. 

ADV_HDL.1 Descriptive high-level design 

If using best commercial practice, the 

vendor can be expected to have the highlevel design for the TOE required by this 

component. Since it is a reasonable 

expectation, it should be included in 

CSPP-OS. 

ATE_IND.2 

(EAL1 has IND.1) Independent testing – sample 

Having the evaluator execute a sample of 

the vendor tests, as a check on their 

validity, is a low-cost, reasonable action 

well within the bounds of the basic goals 

for CSPP-OS assurance. 
CSPP-OS Rationale 66 Ver 1.0 – 4/23/03 

EAL2 Component 

not in EAL1 Component Title Why Required in CSPP-OS 

AVA_SOF.1 Strength of TOE security function 

evaluation 

This is a vendor driven requirement, in 

that the only analysis required is for 

security functionality for which the 

security target includes a claim of strength 

of function. If the claim is not made, no 

analysis is required. If the claim is made, 

then requiring an analysis is a reasonable 

expectation and should be a part of CSPPOS. 

AVA_VLA.1 Developer vulnerability analysis 

It is an essential part of the CSPP-OS 

basic assurance level that at least obvious; 

and common, public-domain; 

vulnerabilities are addressed. 
CSPP-OS Rationale 67 Ver 1.0 – 4/23/03 

 b. EAL3 too much. Table 5.1.2-2 lists the assurance components contained in EAL3 which 

are not a part of EAL2, describing those that are not appropriate for CSPP-OS. Since EAL3 

contains these components, it is too much for the base EAL. Because of the hierarchical nature 

of the EALs, EAL4 through EAL7 are also too much, leaving EAL2 as the best choice. 

Table 5.1.2-2 Necessary Assurance - EAL3 Too Much 

EAL3 Component 

Not in EAL2 Component Title Why not appropriate for CSPP-OS 

ACM_CAP.3 

(EAL2 has CAP.2) Authorization controls N/A – included in EAL-CSPP 

ACM_SCP.1 TOE CM coverage 

N/A – included in EAL-CSPP as part of 

the CSPP-OS requirement for 

ACM_SCP.2 

ADV_HLD.2 Security enforcing high-level 

design 

This component is the reason EAL3 is not 

acceptable as the base level for CSPP-OS. 

The requirement to “describe the 

separation of the TSF into TSP enforcing 

and other subsystems” reflects a degree of 

and capability for security engineering 

that is not a part of current (or expected 

near-term) standard COTS development. 

Although most of EAL3 is a part of EALCSPP, the CC explicitly forbids calling 

out an EAL subset. Therefore, not 

wanting this component of EAL3 

necessitates going to an augmented 

version of the next lower EAL (EAL2). 

ALC_DVS.1 Identification of security 

measures 

N/A – included in EAL-CSPP 

ATE_COV.2 

(EAL2 has COV.1) Analysis of coverage N/A – included in EAL-CSPP 

ATE_DPT.1 Testing: high level design N/A – included in EAL-CSPP 

AVA_MSU.1 Examination of guidance 

N/A – included in EAL-CSPP as part of 

the CSPP-OS requirement for 

AVA_MSU.3 
CSPP-OS Rationale 68 Ver 1.0 – 4/23/03 

5.1.3 EAL Augmentation 

Table 5.1.3-1 gives the rationale for each CC assurance component in EAL-CSPP that is an 

augmentation to the base EAL2 level. 

Table 5.1.3-1 Necessary Assurance - Augmentation Rationale 

Component Component Title Rationale for Augmentation 

ACM_CAP.3 Authorization controls Note: EAL2 includes ACM_CAP.2. 

ACM_CAP.3 adds the requirement for a CM plan and its 

use. A quality IT vendor developing secure products can be 

reasonably expected to provide this CM. The use of a CM 

plan is within the bounds of standard, best commercial 

practice for IT development. 

ACM_SCP.2 Problem tracking CM 

coverage 

Note: EAL2 has no ACM_SCP component. 

A CSPP-OS vendor can be expected to apply CM to the 

items called out in ACM_SCP.2. Specifically, since the 

product is security related, the tracking of security flaws is a 

very reasonable expectation and within the bounds of 

standard, best commercial practice. 

ADV_SPM.1 Informal TOE security 

policy model 

This assurance component is a required dependency for the 

following, essential functional requirements: 

 FMT_MSA.3-NIAP-0409 Static attribute 

initialization 

 FPT_FLS.1 Failure with preservation of secure state 

 FPT_RCV.2-NIAP-0406 Recovery from Failure 

While the generation of a security policy does require 

security expertise, this can be performed by a consultant (if 

necessary) and does not otherwise impact the vendor’s 

existing development process. 

ALC_DVS.1 Identification of 

security measures 

This component requires the definition and implementation 

of protective security measures during IT development. 

Since there is no requirement for a specific set of measures, 

the vendor is largely free to state his procedures as they 

exist. Therefore, this imposes no undue burden on the 

vendor and is within the scope of standard, best commercial 

practice. 
CSPP-OS Rationale 69 Ver 1.0 – 4/23/03 

Component Component Title Rationale for Augmentation 

ALC_FLR.2 Flaw reporting 

procedures 

Note: EAL2 has no ALC_FLR component. 

It is well within standard, best commercial practice for a 

vendor of security products to have flaw remediation 

procedures covering acting upon user reports, correcting 

flaws, notifying users, and reducing the potential for 

introducing new flaws. Specific procedures are not 

indicated in the assurance requirement, therefore there is 

minimal impact on any vendor who is already 

accomplishing the intent of the requirement. 

ATE_COV.2 Analysis of coverage Note: EAL2 has ALC_COV.1. 

It is reasonable to require a security vendor implementing 

best commercial practice to demonstrate that the vendor 

testing completely covers the security functionality called 

out in the vendor produced functional specification. 

ATE_DPT.1 Testing: high level 

design 

This component requires that the vendor analyze the vendor 

testing to demonstrate that it verifies the high-level design. 

For a competent, security vendor implementing best 

commercial practices, this should be of little impact to 

existing development activities. 

AVA_MSU.2 Validation of analysis Note: EAL2 has no AVA_MSU component. 

A security vendor implementing standard, best commercial 

practices will not be impacted by this component. 

AVA_MSU.2 requires that the vendor produce user and 

administrator documentation that is adequate for 

understanding the operating modes of the TOE and the 

required external security controls necessary for secure 

operation. The vendor is required to analyze this 

documentation for conformance to the requirements. The 

other AVA_MSU.2 requirements fall onto the evaluator. 

AVA_MSU.2 is essential in covering T.OBSERVE and is 

important in covering 

 P.SURVIVE T.CRASH 

 T.INSTALL T.OPERATE 
CSPP-OS Rationale 70 Ver 1.0 – 4/23/03 

5.2 SUFFICIENT ASSURANCES 

Table 5.2-1 maps unused CC assurance components to the rationale for non-selection. 

Table 5.2-1 Complete Assurance - Non-Selection Rationale 

Component Component Title Why Not Included in EAL-CSPP 

Family 

ACM_AUT 

CM Automation While automation of the CM process can be 

beneficial, it is simply not a key factor in 

determining the security quality for CSPP-OS 

compliant TOEs. A vendor can use the fact that 

his CM includes automated processes as 

justification for meeting other requirements, but 

automation is not, itself, a requirement. 

ACM_CAP.4 

ACM_CAP.5 

Generation support and 

acceptance procedures 

Advanced support 

While the vendor may have CM procedures 

covering TOE generation (CAP.4) and 

integration (CAP.5), these are much less likely to 

be a part of the existing vendor practices than 

those included with the EAL-CSPP requirement 

for ACM_CAP.3. 

ACM_SCP.3 Development tools CM 

coverage 

Full CM coverage of developmental tools is not a 

part of standard, best commercial practice and is 

therefore beyond the scope of the basic goals for 

CSPP-OS assurance. 

ADO_DEL.2 

ADO_DEL.3 

Detection of modification 

Prevention of modification 

ADO_DEL.2 and DEL.3 are not part of standard, 

best commercial practice and therefore are 

beyond the scope of the basic goals for CSPP-OS 

assurance. 

ADO_IGS.2 Generation log The requirement for a generation log is not a part 

of standard, best commercial practice and is 

therefore beyond the scope of the basic goals for 

CSPP-OS assurance. 

ADV_FSP.2 

ADV_FSP.3 

ADV_FSP.4 

Fully defined external 

interfaces 

Semiformal functional 

specification 

Formal functional specification 

While good ideas, fully defined interfaces and 

semiformal or formal specification are not at part 

of existing best commercial practice. Therefore 

these are beyond the scope of the basic goals for 

CSPP-OS assurance. 

ADV_HLD.2 

ADV_HLD.3 

ADV_HLD.4 

ADV_HLD.5 

Security enforcing high-level 

design 

Semiformal high-level design 

Semiformal high-level 

explanation 

Formal high-level design 

The requirements of ADV_HLD.2 include 

security engineering that is not a part of existing 

best commercial practices. This is sufficient to 

make all of these components beyond the scope 

of the basic goals for CSPP-OS assurance. 
CSPP-OS Rationale 71 Ver 1.0 – 4/23/03 

Component Component Title Why Not Included in EAL-CSPP 

Family 

ADV_IMP 

Implementation representation It is not reasonable, either from the CSPP-OS 

goal to limit evaluation cost and time or the 

CSPP-OS goal to keep within the bounds of best 

commercial practice to include implementation 

representation requirements. 

Family 

ADV_INT 

TSF internals It is clearly outside the bounds of current best 

commercial practice to include these 

requirements on TSF internals. To require these 

would necessitate major changes to the vendor’s 

development practices. Such changes are beyond 

the scope of the basic goals for CSPP-OS 

assurance. 

Family 

ADV_LLD 

Low-level design It is not reasonable, either from the CSPP-OS 

goal to limit evaluation cost and time or the 

CSPP-OS goal to keep within the bounds of best 

commercial practice to include low-level design 

requirements. 

ADV_RCR.2 

ADV_RCR.3 

Semiformal correspondence 

demonstration 

Formal correspondence 

demonstration 

Semiformal or formal requirements are not a part 

of existing, best commercial practice. Therefore 

these are beyond the scope of the basic goals for 

CSPP-OS assurance. 

ADV_SMP.2 

ADV_SMP.3 

Semiformal TOE security 

policy model 

Formal TOE security policy 

model 

Semiformal or formal requirements are not a part 

of existing, best commercial practice. Therefore 

these are beyond the scope of the basic goals for 

CSPP-OS assurance. 

ALC_DVS.2 Sufficiency of security 

measures 

This requirement may necessitate major changes 

to existing, vendor development practices, even 

where standard, best commercial practices are 

being implemented. Therefore these are beyond 

the scope of the basic goals for CSPP-OS 

assurance. 

ALC_FLR.3 Systematic flaw remediation It is beyond best commercial practices to require 

specific points of contact for flaw reporting and 

the automatic distribution of flaw reports. 

Therefore this component is beyond the scope of 

the basic goals for CSPP-OS assurance. 

Family 

ALC_LCD 

Life cycle definition Current best commercial practices do not include 

clearly defined life-cycle models. While this 

may become standard, it is not at present. 

Therefore this family is beyond the scope of the 

basic goals for CSPP-OS assurance. 
CSPP-OS Rationale 72 Ver 1.0 – 4/23/03 

Component Component Title Why Not Included in EAL-CSPP 

Family 

ALC_TAT 

Tools and techniques Current best commercial practices do not include 

these requirements on the definition and control 

of all tools used in the development. Moreover, 

this family has ADV_IMP as a required 

dependency and, as already explained, 

ADV_IMP is beyond the scope of the basic goals 

for CSPP-OS assurance. 

ATE_COV.3 Rigorous analysis of coverage It is well outside the bounds of current, best 

commercial practices to require a rigorous 

analysis of vendor testing. Therefore this 

component is beyond the scope of the basic goals 

for CSPP-OS assurance. 

ATE_DPT.2 

ATE_DPT.3 

Testing – low level design 

Testing – implementation 

representation 

Since the low-level design and implementation 

requirements are beyond scope and not included 

in CSPP-OS, these depth of testing requirements 

are also beyond the scope of the basic goals for 

CSPP-OS assurance. 

ATE_FUN.2 Ordered functional testing The requirement for analysis of test ordering 

dependencies is not part of best commercial 

practices and hence is beyond the scope of the 

basic goals for CSPP-OS assurance. 

ATE_IND.3 Independent testing – complete This requirement adds unnecessary time and cost 

to the evaluation. Therefore it is beyond the 

scope of the basic goals for CSPP-OS assurance.

Family 

AVA_CCA 

Covert channel analysis Covert channel analysis is not a part of existing 

best commercial practice and therefore is beyond 

the scope of the basic goals for CSPP-OS 

assurance. 

AVA_MSU.3 Analysis and testing for 

insecure states 

While this component might be considered 

within the range of best commercial practices, it 

is outside the scope of near-term, mutual 

recognition agreements and hence has not been 

selected for CSPP-OS. 

AVA_VLA.2 

AVA_VLA.3 

AVA_VLA.4 

Independent vulnerability 

analysis 

Moderately resistant 

Highly resistant 

The requirements already a part of CSPP-OS 

through AVA_VLA.1 include evaluator 

penetration testing, and additional evaluator 

actions would be beyond the scope of the basic 

goals for CSPP-OS assurance. Moreover, the 

reasonable expectations for CSPP-OS compliant 

TOEs do not include the potential for resistance 

to penetration. 

AMA_AMP Assurance maintenance plan This family is beyond the scope of the basic 

goals for CSPP-OS assurance. 
CSPP-OS Rationale 73 Ver 1.0 – 4/23/03 

Component Component Title Why Not Included in EAL-CSPP 

AMA_CAT TOE component categorization 

report 

While a case can be made for inclusion of this 

family as part of CSPP-OS, AMA_CAT is not 

covered by near-term, mutual recognition 

agreements and is therefore excluded from 

CSPP-OS. 

AMA_EVD Evidence of assurance 

maintenance 

This family does not apply to an initial 

evaluation. 

AMA_SIA Security impact analysis This family does not apply to an initial 

evaluation. 
CSPP-OS Rationale 74 Ver 1.0 – 4/23/03 

5.3 CORRECT ASSURANCES 

5.3.1 Dependencies for assurances 

Table 5.3.1-1 shows correctness of the assurances with respect to meeting all dependencies. 

Table 5.3.1-1 Correct Assurances – Dependency Mapping 

Item # Component Component Title Dependency Item # 

1 ACM_CAP.3 Authorization controls ALC_DVS.1 

(CCIMB_I-95) 

11 

2 ACM_SCP.2 Problem tracking CM Coverage ACM_CAP.3 1 

3 ADO_DEL.1 Delivery procedures  

4 ADO_IGS.1 Installation, Generation, and Start-up Procedures AGD_ADM.1 9 

5 ADV_FSP.1 Informal functional specification ADV_RCR.1 7 

6 ADV_HLD.1 Descriptive High-Level Design ADV_FSP.1 

ADV_RCR.1 

5 

7 

7 ADV_RCR.1 Informal Correspondence Demonstration  

8 ADV_SPM.1 Informal TOE security policy model ADV_FSP.1 5 

9 AGD_ADM.1 Administrator Guidance ADV_FSP.1 5 

10 AGD_USR.1 User Guidance ADV_FSP.1 5 

11 ALC_DVS.1 Identification of Security Measures  

12 ALC_FLR.2 Flaw reporting procedures  

13 ATE_COV.2 Analysis of coverage ADV_FSP.1 

ATE_FUN.1 

5 

15 

14 ATE_DPT.1 Testing: High-Level Design ADV_HLD.1 

ATE_FUN.1 

6 

15 

15 ATE_FUN.1 Functional Testing  

16 ATE_IND.2 Independent Testing - Sample 

ADV_FSP.1 

AGD_ADM.1 

AGD_USR.1 

ATE_FUN.1 

5 

9 

10 

15 

17 AVA_MSU.2 Validation of analysis 

ADO_IGS.1 

ADV_FSP.1 

AGD_ADM.1 

AGD_USR.1 

4 

5 

9 

10 

18 AVA_SOF.1 Strength of TOE Security Function Evaluation ADV_FSP.1 

ADV_HLD.1 

5 

6 
CSPP-OS Rationale 75 Ver 1.0 – 4/23/03 

Item # Component Component Title Dependency Item # 

19 AVA_VLA.1 Developer vulnerability Analysis 

ADV_FSP.1 

ADV_HLD.1 

AGD_ADM.1 

AGD_USR.1 

5 

6 

9 

10 

5.3.2 Assurance Operations 

There are no operations performed on assurance components in CSPP-OS. 
CSPP-OS Rationale 76 Ver 1.0 – 4/23/03 

6. APPENDIX A - REFERENCES 

[CC-V2.1] Common Criteria for Information Technology Security Evaluation, August 1999. 

[CSPP] CSPP - Guidance for COTS Security Protection Profiles, version 1.0, December 

1999. 

[CSPP-OS] CSPP-OS - COTS Security Protection Profile - Operating Systems, version 1.0, 

April 2003