NISTIR 6985

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

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

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)	

TABLE OF CONTENTS
SECTION	PAGE
1.	INTRODUCTION
1.1	Identification
1.2	overview
2.	TOE DESCRIPTION
2.1	Product class
2.2	OPerational Environment
2.3	required security functionality
3.	Security environment
3.1	INTRODUCTION
3.2	Secure Usage Assumptions
3.3	ORGANIZATIONAL security policies
3.4	Threats to security
3.4.1	Threats environment addresses
3.4.2	Threats TOE addresses
3.4.3	Threats TOE and Environment jointly address
3.5	General assurance need
4.	security objectives
4.1	Environmental security objectives
4.2	TOE security objectives
4.3	Joint TOE/Environment security objectives
5.	Functional Security REQUIREMENTS
5.1	Functional Requirements - TOE
5.2	functional requirements - IT Environment
5.3	non-it Environmental Functional Requirements
5.4	Strength of function (SOF)
5.4.1	Minimum SOF Requirement
5.4.2	Specific SOF Requirements - TOE
5.4.3	Specific SOF Metrics - IT Environment
6.	Assurance Requirements
7.	Application NOTES
7.1	Evaluation scope, depth, and rigor.
8.	rationale
9.	references
A.	APPENDIX A:  ACRONYMS
B.	APPENDIX B:  TOE fUNCTIONAL rEQUIREMENT dETAILS
B.1	Common syntax
B.2	CSPP Access Control Security Function Policy (SFP)
B.2.1	Discretionary Access Control
B.2.2	Non-discretionary Access Controls
B.2.3	CSPP Access Control Precedence Rules
B.3	Audit (fau)
B.3.1	FAU_GEN.1-CSPP Audit data generation
B.3.2	FAU_GEN.2-NIAP-0410 User identity generation
B.3.3	FAU_SAR.1 Audit review
B.3.4	FAU_SAR.2 Restricted audit review
B.3.5	FAU_SAR.3 Selectable audit review
B.3.6	FAU_SEL.1-CSPP Selective audit
B.3.7	FAU_STG.1-NIAP-0423 Protected audit trail storage
B.3.8	FAU_STG.3 Action in case of possible audit data loss
B.4	User Data Protection (fdp)
B.4.1	FDP_ACC.1 Subset access control
B.4.2	FDP_ACF.1-CSPP Security attribute based access control
B.4.3	FDP_ETC.1-CSPP Export of user data without security attributes
B.4.4	FDP_ITC.1 Import of user data without security attributes
B.4.5	FDP_RIP.1 Subset residual information protection
B.4.6	FDP_UCT.1 Basic data exchange confidentiality
B.4.7	FDP_UIT.1 Data exchange integrity
B.5	Identification and Authentication (FIA)
B.5.1	FIA_AFL.1-NIAP-0425 Authentication failure handling
B.5.2	FIA_ATD.1 User attribute definition
B.5.3	FIA_SOS.1 Verification of secrets
B.5.4	FIA_UAU.1 Timing of authentication
B.5.5	FIA_UAU.5 Multiple authentication mechanisms
B.5.6	FIA_UAU.6 Re -authentication
B.5.7	FIA_UAU.7 Protected authentication feedback
B.5.8	FIA_UID.1 Timing of identification
B.5.9	FIA_USB.1-NIAP-0415 User-subject binding
B.6	Security management (fmt)
B.6.1	FMT_MOF.1 Management of security functions behavior
B.6.2	FMT_MSA.1 Management of security attributes
B.6.3	FMT_MSA.3-NIAP-0409 Static attribute initialization
B.6.4	FMT_MTD.1 Management of TSF data
B.6.5	FMT_SAE.1 Time-limited authorization
B.6.6	FMT_SMR.1 Security roles
B.7	Protection of Trusted Security (FPT)
B.7.1	FPT_AMT.1 Abstract machine testing
B.7.2	FPT_FLS.1 Failure with preservation of secure state
B.7.3	FPT_ITC.1-CSPP Inter-TSF confidentiality during transmission
B.7.4	FPT_ITI.1-CSPP Inter-TSF detection of modification
B.7.5	FPT_RCV.2-NIAP-0406 Recovery from Failure
B.7.6	FPT_RPL.1-CSPP Replay detection
B.7.7	FPT_RVM.1 Non-bypassability of the TSP
B.7.8	FPT_SEP.1 TSF domain separation
B.7.9	FPT_TDC.1 Inter-TSF basic TSF data consistency
B.7.10	FPT_TST.1 TSF testing
B.7.11	FPT_SYN-CSPP.1 TSF synchronization
B.8	Resource utilization (fru)
B.8.1	FRU_RSA.1-CSPP Maximum quotas
B.9	TOE Access (FTA)
B.9.1	FTA_LSA.1 Limitation on scope of selectable attributes
B.9.2	FTA_MCS.1-CSPP Basic limitation on multiple concurrent sessions
B.9.3	FTA_SSL.1 TSF initiated session locking
B.9.4	FTA_SSL.2 User-initiated locking
B.9.5	FTA_SSL.3 TSF-initiated termination
B.9.6	FTA_TAB.1-CSPP Default TOE access banners
B.9.7	FTA_TAH.1 TOE access history
B.9.8	FTA_TSE.1 TOE session establishment
B.10	trusted path/channels (FTP)
B.10.1	FTP_ITC.1-CSPP Inter-TSF trusted channel
C.	Appendix C:  TOE ASSURANCE rEQUIREMENT dETAILS
C.1	Configuration Management (ACM)
C.1.1	ACM_CAP.3 Authorization controls
C.1.2	ACM_SCP.2 Problem tracking CM coverage
C.2	Delivery and operation (ADO)
C.2.1	ADO_DEL.1 Delivery procedures
C.2.2	ADO_IGS.1 Installation, generation, and start-up procedures
C.3	Development (ADV)
C.3.1	ADV_FSP.1 Informal functional specification
C.3.2	ADV_HLD.1 Descriptive high-level design
C.3.3	ADV_RCR.1 Informal Correspondence Demonstration
C.3.4	ADV_SPM.1 Informal TOE security policy model
C.4	Guidance documents (AGD)
C.4.1	AGD_ADM.1 Administrator guidance
C.4.2	AGD_USR.1 User Guidance
C.5	Life Cycle Support (ALC)
C.5.1	ALC_DVS.1 Identification of security measures
C.5.2	ALC_FLR.2 Flaw reporting procedures
C.6	Tests (ATE)
C.6.1	ATE_COV.2 – Analysis of coverage
C.6.2	ATE_DPT.1  Testing: High Level Design
C.6.3	ATE_FUN.1 Functional Testing
C.6.4	ATE_IND.2 Independent Testing - Sample
C.7	Vulnerability assessment (AVA)
C.7.1	AVA_MSU.2 Validation of Analysis
C.7.2	AVA_SOF.1 Strength of TOE Security Function Evaluation
C.7.3	AVA_VLA.1 Developer vulnerability analysis
C.8	Maintenance of assurance (AMA)
D.	Appendix D:  IT-Environment Functional rEQUIREMENT dETAILS
D.1	Audit (fau)
D.1.1	FAU_STG.1-NIAP-0423 Protected audit trail storage
D.2	User Data Protection (fdp)
D.2.1	FDP_ACC.1 Subset access control
D.2.2	FDP_RIP.1 Subset residual information protection
D.3	Identification and Authentication (FIA)
D.3.1	FIA_UAU.1 Timing of authentication
D.3.2	FIA_UAU.6 Re -authentication
D.3.3	FIA_UAU.7 Protected authentication feedback
D.4	Security management (fmt)
D.4.1	FMT_MOF.1 Management of security functions behavior
D.4.2	FMT_MSA.3-NIAP-0409 Static attribute initialization
D.4.3	FMT_MTD.1 Management of TSF’s IT-environment data
D.5	Protection of Trusted Security (FPT)
D.5.1	FPT_AMT.1 Abstract machine testing
D.5.2	FPT_RCV.2-NIAP-0406 Recovery from Failure
D.5.3	FPT_RVM.1 Non-bypassability of the TSP
D.5.4	FPT_SEP.1 TSF domain separation
D.5.5	FPT_SYN-CSPP.1 TSF synchronization
D.6	Resource utilization (fru)
D.7	TOE Access (FTA)
D.7.1	FTA_TAH.1 TOE access history
D.8	trusted path/channels (FTP)

TABLE OF TABLES
TABLE	PAGE
Table 3.2-1 – Security assumptions - TOE
Table 3.2-2 – Security assumptions - Personnel
Table 3.3-1 – Security policies
Table 3.4-1 – Security threats addressed by TOE’s Environment
Table 3.4-2 – Security threats addressed by TOE
Table 3.4-3 – Security threats addressed Jointly by TOE and Environment
Table 4-1 – Environmental Security Objectives
Table 4-2 – TOE Security Objectives
Table 4-3 – Joint TOE/Environment Security Objectives
Table 5-1 – Functional Components - TOE
Table 5-2 – Functional Components - IT Environment
Table 5-3 – SOF Metrics - TOE
Table 5-4 – SOF Metrics - IT Environment
Table 6-1 – EAL-CSPP Assurance Components
Table 6-2 – EAL-CSPP augmentation to EAL-2

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.

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 time-of-day and port-of-entry
•	resistance to resource depletion by providing resource allocation features
•	providing mechanisms to detect some insecurities
•	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
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)

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 time-of-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

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 counter-measure 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.  
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 near-term 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.SOPHISTICATED-ATTACK	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 near-term 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”.	
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 time-of-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.	
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 non-discretionary 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.	

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

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-CONFIDENTIALITY-Non-TOE	For audit trails not under control of the TOE, records of security events may be disclosed to unauthorized individuals or processes. 	
T.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. 	

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-of-service 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. 	

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

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-of-service attacks.  

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

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

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

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

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

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

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.

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-Non-TOE
T.AUDIT-CONFIDENTIALITY-Non-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	
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-of-service 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	
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	
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-CONFIDENTIALITY-TOE	
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	
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	

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 non-technical 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	
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	

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	
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	
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-NIAP-0425	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-NIAP-0415	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	
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	
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	

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	
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_SYN-CSPP.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 non-IT environmental support.  

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

	O.ACCESS-NON-TECHNICAL
	O.DENIAL-SOPHISTICATED
	O.DETECT-SOPHISTICATED
	O.ENTRY-NON-TECHNICAL
	O.ENTRY-SOPHISTICATED
	O.PHYSICAL

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

	O.ACCESS-MALICIOUS
	O.COMPLY
	O.DUE-CARE
	O.MANAGE
	O.OPERATE

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	
48	FPT_TST.1 	TSF Testing 	MD5 or stronger checksums will be used	
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	

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 	
Development	ADV_FSP.1	Informal functional specification	
	ADV_HLD.1	Descriptive High-Level Design	
	ADV_RCR.1	Informal Correspondence Demonstration 	
	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	
Tests	ATE_COV.2	Analysis of coverage 	
	ATE_DPT.1	Testing - High-Level Design 	
	ATE_FUN.1	Functional Testing 	
	ATE_IND.2	Independent Testing - Sample	
Vulnerability Assessment 
 	AVA_MSU.2 	Validation of Analysis 	
	AVA_SOF.1	Strength of TOE Security Function Evaluation 	
	AVA_VLA.1	Developer vulnerability Analysis 	

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).	
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	
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-OS-R), version 1.0, April 2003.
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 	

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. 

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

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

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

Refinement:  See text of FIA_AFL.1.1-NIAP-0425 and FIA_AFL.1.2
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. 
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: re-establishing a session following session locking, request to change authentication secrets, and the following ST supplied conditions specific to the ST design: [ST assignment: as required by PP, list of other, ST specific conditions under which re-authentication is required]].  The ST rationale shall provide a basic justification for the assignment made, including a “null” list, showing why it is complete.

Refinement:  See text in FIA_UAU.6.1
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].
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
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
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
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
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 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. 

Refinement:  See text in FPT_RVM.1.1
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.
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.
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
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.
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
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

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

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

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: 
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. 
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. 
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. 
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. 
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. 
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.
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_I-51)

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

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].
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 IT-environment-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 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 IT-environment (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. 
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.
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)	

TABLE OF CONTENTS
SECTION	PAGE

1.	INTRODUCTION
2.	SECURITY environment RATIONALE
2.1	Usage assumptions
2.2	security policies
2.3	threats to security
2.4	general assurance level
3.	SECURITY OBJECTIVES RATIONALE
3.1	necessary Objectives
3.2	complete Objectives
3.3	correct Objectives
4.	TOE FUNCTIONAL REQUIREMENTS RATIONALE
4.1	Necessary TOE functionality
4.2	sufficient TOE functionality
4.2.1	Coverage of Security Objectives
4.2.2	Strength of Function (SOF)
4.3	Correct TOE functionality
4.3.1	Dependencies for TOE functionality
4.3.2	Functional Operations
5.	ASSURANCE REQUIREMENTS RATIONALE
5.1	Necessary assurances
5.1.1	Basic Assurance Goals
5.1.2	EAL Selection
5.1.3	EAL Augmentation
5.2	sufficient assurances
5.3	correct assurances
5.3.1	Dependencies for assurances
5.3.2	Assurance Operations
6.	Appendix a - REFERENCES

TABLE OF TABLES
TABLE	PAGE
Table 1-1  CSPP-OS Rationale Overview
Table 2.1-1  Usage Assumption Rationale
Table 2.2-1  Security Policy Rationale
Table 2.3-1  Security Threat Rationale
Table 3.1-1  Necessary Objectives – Mapping Objectives to Policy and Threat
Table 3.2-1  Complete Objectives – Mapping Policy and Threat to Objectives
Table 3.3-1  Correct Objectives - Mapping Security Objective to Rationale
Table 4.1-1  Necessary TOE Functionality – Mapping Function to Requirement
Table 4.2-1  Complete Functionality - Map TOE Security Objective to TOE Functionality
Table 4.2-2  Complete Functionality - Map Joint Security Objective to TOE Functionality
Table 4.3.1-1  Correct TOE Functionality – Dependency Mapping
Table 4.3.2-1  Correct Functionality – Rationale for assignment, Selection, and Refinement
Table 4.3.2-2  Correct Functionality – Rationale for Deferring Operations to ST
Table 4.3.2-3  Correct Functionality – Rationale for Functional Extensions
Table 5.1.2-1  Necessary Assurance - EAL1 Not Sufficient
Table 5.1.2-2  Necessary Assurance - EAL3 Too Much
Table 5.1.3-1  Necessary Assurance - Augmentation Rationale
Table 5.2-1  Complete Assurance - Non-Selection Rationale
Table 5.3.1-1  Correct Assurances – Dependency Mapping

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.	Show that the security environment description is consistent with the introduction and the TOE description.	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.		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	Show correctness of CSPP-OS TOE functionality	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		4.3.4	

Nature of Rationale	Purpose	Section	
Discuss basic assurance goals	Show necessity of CSPP-OS assurances	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		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	Show correctness of CSPP-OS assurances	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		5.3.4	

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.MALICIOUS-INSIDER	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.SOPHISTICATED-ATTACK	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.	
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.	

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.	
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 non-discretionary 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.	

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-NON-TECHNICAL	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-NON-TECHNICAL 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.AUDIT-CONFIDENTIALITY-Non-TOE	For audit trails not under control of the TOE, records of security events may be disclosed to unauthorized individuals or processes. 	For audit records not under control of the TOE, other components within the system must address this threat.	
Environment:
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. 	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.DENIAL-SOPHISTICATED	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.	
Environment:
T.ENTRY-NON-TECHNICAL	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.ENTRY-SOPHISTICATED	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, high-grade attack.  Therefore, this threat is largely addressed by the TOE environment.	
Environment:
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. 	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-EVENT-Non-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-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. 	For auditing not under control of the TOE, other components within the system must address this threat.	
Joint:
T.ACCESS-MALICIOUS	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 near-term 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.	
Joint:
T.SYSTEM-CORRUPTED	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.AUDIT-CONFIDENTIALITY-TOE	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-CONFIDENTIALITY-TOE is highlighted as a significant contributor toward a potential failure in the detection and response capability.	
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. 	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.	
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 man-machine 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-EVENT-TOE	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 non-malicious 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.	

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”.
  
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.
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.ACCESS-MALICIOUS	
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.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-Non-TOE
T.RECORD-EVENT-Non-TOE
T.AUDIT-CORRUPTED-Non-TOE
T.AUDIT-CONFIDENTIALITY-Non-TOE	
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-CONFIDENTIALITY-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	
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	
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.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.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.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 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.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.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-Non-TOE	
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	
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	

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-non-technical
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	
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.denial-sophisticated
o.detect-sophisticated
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 non-discretionary 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 non-malicious, unauthorized access using non-technical means.	o.access-non-technical	
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	
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.AUDIT-CONFIDENTIALITY-Non-TOE	For audit trails not under control of the TOE, records of security events may be disclosed to unauthorized individuals or processes. 	o.account-non-toe	
T.AUDIT-CONFIDENTIALITY-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-Non-TOE	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.denial-sophisticated	
T.DENIAL-TOE	The TOE may be subjected to an unsophisticated, denial-of-service attack.	o.available-toe	
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-non-technical	
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.entry-sophisticated	
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	
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.detect-sophisticated
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	

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 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.	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-NON-TOE
This explicitly refers to IT other than the TOE.  Hence this is environmental.	
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-NON-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.	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-of-service 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.	
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 non-technical 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	
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	
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.	
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.	
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.
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	
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.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	FDP_ACC.1	o.access-TOE
o.access-malicious
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-NIAP-0415	o.authorize-TOE	
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.access-malicious
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.access-malicious
o.entry-TOE
o.authorize-TOE
o.manage
o.due-care	
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.access-malicious
o.entry-TOE
o.due-care	
51	FTA_MCS.1-CSPP	Basic limitation on multiple concurrent session		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		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.access-malicious
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_SYN-CSPP.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	

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.

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-NIAP-0415
	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	
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-NIAP-0425
	23	FIA_SOS.1
	27	FIA_UAU.6
	28	FIA_UAU.7
	30	FIA_USB.1-NIAP-0415
	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-NIAP-0425
	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-NIAP-0425
	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	
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-NIAP-0406	
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	

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-NIAP-0415
	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-NIAP-0425
	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	
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-NIAP-0425
	23	FIA_SOS.1
	30	FIA_USB.1-NIAP-0415
	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	
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-NIAP-0406	

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.
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	
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-NIAP-0425 	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-NIAP-0415	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-NIAP-0406	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		
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		

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.

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.

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 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 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 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 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 lower-level 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 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 OS-controlled, 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 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 …

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

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

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

•	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 re-authentication.  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 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.
•	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.
•	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.

•	‘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.)

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

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

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

•	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

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

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

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

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

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

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-to-market.  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-to-market.  Therefore, a CSPP-OS evaluation must be low cost and of short duration.

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 start-up 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 high-level 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.	
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 CSPP-OS.	
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.	

	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 EAL-CSPP, 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	

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

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