Comment: Comment-1-

Protection Profile for QQQQ

NIAP Logo
Version: 1.0
2015-08-14
National Information Assurance Partnership

Revision History

VersionDateComment
Round 12015-04-23First draft of version 1.0 for comment
1.02015-08-14Release - first version released

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.3.2TOE Platform1.4Use Cases2Conformance Claims3Security Problem Description3.1Threats3.2Assumptions4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1TOE Security Functional Requirements5.2TOE Security Functional Requirements Rationale6Consistency RationaleAppendix A - Optional SFRsAppendix B - Extended Component DefinitionsB.1Extended Components TableB.2Extended Component DefinitionsB.2.1Cryptographic Support (FCS)B.2.1.1FCS_CKM_EXT Cryptographic Key ManagementB.2.2Security Audit (FAU)B.2.2.1FAU_STG_EXT Security Store FilteringAppendix C - Inherently Satisfied RequirementsAppendix D - AcronymsAppendix E - Bibliography

1 Introduction

1.1 Overview

Content added 11 Feb 2021: 1307pm. Content added 11 Feb 2021: 1249pm. Σ
Table Caption
Column 1Column 2
Row 1Data 1 Data 2
Row 2Data 3 Data 4
Row 2 Data 7
Row 3Data 5
The scope of this Protection Profile (PP) is to describe the security functionality of QQQQ products in terms of [CC] and to define functional and assurance requirements for such products. An operating system is software that manages computer hardware and software resources, and provides common services for application programs. The hardware it manages may be .
Something

This is going to show some tests:

And this is another sentence (or fragment). I added this sentence and deleted the next one. This uses the plural acronym OSes.

And here's a generic coutner Abc 1: Some Words

And here's the reference to it Abc 1.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Collaborative Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria Testing Laboratory
 Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology, or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.

1.2.2 Technical Terms

Address Space Layout Randomization (ASLR)
 An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of a process.
Administrator
 An administrator is responsible for management activities, including setting policies that are applied by the enterprise on the operating system. This administrator could be acting remotely through a management server, from which the system receives configuration policies. An administrator can enforce settings on the system which cannot be overridden by non-administrator users.
Application (app)
 Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation.
Application Programming Interface (API)
 A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform.
Credential
 Data that establishes the identity of a user, e.g. a cryptographic key or password.
Critical Security Parameters (CSP)
 Information that is either user or system defined and is used to operate a cryptographic module in processing encryption functions including cryptographic keys and authentication data, such as passwords, the disclosure or modification of which can compromise the security of a cryptographic module or the security of the information protected by the module.
DAR Protection
 Countermeasures that prevent attackers, even those with physical access, from extracting data from non-volatile storage. Common techniques include data encryption and wiping.
Data Execution Prevention (DEP)
 An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code.
Developer
 An entity that writes OS software. For the purposes of this document, vendors and developers are the same.
General Purpose Operating System
 A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services. Typical characteristics for OSes in this class include support for third-party applications, support for multiple users, and security separation between users and their respective resources. General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems (RTOS). RTOSes typically power routers, switches, and embedded devices.
Host-based Firewall
 A software-based firewall implementation running on the OS for filtering inbound and outbound network traffic to and from processes running on the OS.
Operating System (OS)
 Software that manages physical and logical resources and provides services for applications. The terms TOE and OS are interchangeable in this document.
Personally Identifiable Information (PII)
 Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother's maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual.[OMB]
Sensitive Data
 Sensitive data may include all user or enterprise data or may be specific application data such as PII, emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include credentials and keys. Sensitive data shall be identified in the OS's TSS by the ST author.
User
 A user is subject to configuration policies applied to the operating system by administrators. On some systems under certain configurations, a normal user can temporarily elevate privileges to that of an administrator. At that time, such a user should be considered an administrator.
Virtual Machine (VM)
Blah Blah Blah

1.3 Compliant Targets of Evaluation

1.3.1 TOE Boundary


Figure 2: General TOE

1.3.2 TOE Platform

1.4 Use Cases

Requirements in this Protection Profile are designed to address the security problems in at least the following use cases. These use cases are intentionally very broad, as many specific use cases exist for an operating system. These use cases may also overlap with one another. An operating system's functionality may even be effectively extended by privileged applications installed onto it. However, these are out of scope of this PP.
[USE CASE 1] Elephant-own device
This is everything we need to describe in words about this use case.

For changes to included SFRs, selections, and assignments required for this use case, see .

2 Conformance Claims

3 Security Problem Description

The security problem is described in terms of the threats that the OS is expected to address, assumptions about the operational environment, and any organizational security policies that the OS is expected to enforce.

3.1 Threats

T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with applications and services running on or part of the OS with the intent of compromise. Engagement may consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between applications and services that are running on or part of the OS.
T.LOCAL_ATTACK
An attacker may compromise applications running on the OS. The compromised application may provide maliciously formatted input to the OS through a variety of channels including unprivileged system calls and messaging via the file system.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access data on the OS while having a limited amount of time with the physical device.

3.2 Assumptions

These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security functionality specified in the PP-Module can be provided by the TOE. If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality.
A.PLATFORM
The OS relies upon a trustworthy computing platform for its execution. This underlying platform is out of scope of this PP.
A.PROPER_USER
The user of the OS is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy. At the same time, malicious software could act as the user, so requirements which confine malicious subjects are still in scope.
A.PROPER_ADMIN
The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.

4 Security Objectives

4.1 Security Objectives for the TOE

O.ACCOUNTABILITY
Conformant OSes ensure that information exists that allows administrators to discover unintentional issues with the configuration and operation of the operating system and discover its cause. Gathering event information and immediately transmitting it to another system can also enable incident response in the event of system compromise.
O.INTEGRITY
Conformant OSes ensure the integrity of their update packages. OSes are seldom if ever shipped without errors, and the ability to deploy patches and updates with integrity is critical to enterprise network security. Conformant OSes provide execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems.
O.MANAGEMENT
To facilitate management by users and the enterprise, conformant OSes provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration and application execution control.
O.PROTECTED_STORAGE
To address the issue of loss of confidentiality of credentials in the event of loss of physical control of the storage medium, conformant OSes provide data-at-rest protection for credentials. Conformant OSes also provide access controls which allow users to keep their files private from other users of the same system.
O.PROTECTED_COMMS
To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant OSes provide mechanisms to create trusted channels for CSP and sensitive data. Both CSP and sensitive data should not be exposed outside of the platform.

4.2 Security Objectives for the Operational Environment

The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve. This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means. The assumptions identified in Section 3 are incorporated as security objectives for the environment. The following security objectives for the operational environment assist the OS in correctly providing its security functionality. These track with the assumptions about the environment.
OE.PLATFORM
The OS relies on being installed on trusted hardware.
OE.PROPER_USER
The user of the OS is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy. Standard user accounts are provisioned in accordance with the least privilege model. Users requiring higher levels of access should have a separate account dedicated for that use.
OE.PROPER_ADMIN
The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.

4.3 Security Objectives Rationale

This section describes how the assumptions, threats, and organizational security policies map to the security objectives.
Table 1: Security Objectives Rationale
Threat, Assumption, or OSPSecurity ObjectivesRationale
T.NETWORK_​ATTACKO.PROTECTED_​COMMSThe threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides for integrity of transmitted data.
O.INTEGRITYThe threat T.NETWORK_ATTACK is countered by O.INTEGRITY as this provides for integrity of software that is installed onto the system from the network.
O.MANAGEMENTThe threat T.NETWORK_ATTACK is countered by O.MANAGEMENT as this provides for the ability to configure the OS to defend against network attack.
O.ACCOUNTABILITYThe threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this provides a mechanism for the OS to report behavior that may indicate a network attack has occurred.
T.NETWORK_​EAVESDROPO.PROTECTED_​COMMSThe threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides for confidentiality of transmitted data.
O.MANAGEMENTThe threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides for the ability to configure the OS to protect the confidentiality of its transmitted data.
T.LOCAL_​ATTACKO.INTEGRITYThe objective O.INTEGRITY protects against the use of mechanisms that weaken the TOE with regard to attack by other software on the platform.
O.ACCOUNTABILITYThe objective O.ACCOUNTABILITY protects against local attacks by providing a mechanism to report behavior that may indicate a local attack is occurring or has occurred.
T.LIMITED_​PHYSICAL_​ACCESSO.PROTECTED_​STORAGEThe objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE.
A.PLATFORMOE.PLATFORM The operational environment objective OE.PLATFORM is realized through A.PLATFORM.
A.PROPER_​USEROE.PROPER_​USERThe operational environment objective OE.PROPER_USER is realized through A.PROPER_USER.
A.PROPER_​ADMINOE.PROPER_​ADMINThe operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN.

5 Security Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

5.1 TOE Security Functional Requirements

This PP-Module does not define any mandatory SFRs.

5.2 TOE Security Functional Requirements Rationale

The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:

Table 2: SFR Rationale
ObjectiveAddressed byRationale
O.ACCOUNTABILITY
FAU_GEN.1'cause FAU_GEN.1 is awesome
FTP_ITC_EXT.1Cause FTP reasons
O.INTEGRITY
FPT_SBOP_EXT.1For reasons
FPT_ASLR_EXT.1ASLR For reasons
FPT_TUD_EXT.1For reasons
FPT_TUD_EXT.2For reasons
FCS_COP.1/HASHFor reasons
FCS_COP.1/SIGNFor reasons
FCS_COP.1/KEYHMACFor reasons
FPT_ACF_EXT.1For reasons
FPT_SRP_EXT.1For reasons
FIA_X509_EXT.1For reasons
FPT_TST_EXT.1For reasons
FTP_ITC_EXT.1For reasons
FPT_W^X_EXT.1For reasons
FIA_AFL.1For reasons
FIA_UAU.5For reasons
O.MANAGEMENT
FMT_MOF_EXT.1For reasons
FMT_SMF_EXT.1For reasons
FTA_TAB.1For reasons
FTP_TRP.1For reasons
O.PROTECTED_​STORAGE
FCS_STO_EXT.1, FCS_RBG_EXT.1, FCS_COP.1/ENCRYPT, FDP_ACF_EXT.1Rationale for a big chunk
O.PROTECTED_​COMMS
 FCS_RBG_EXT.1, FCS_CKM.1, FCS_CKM.2, FCS_CKM_EXT.4, FCS_COP.1/ENCRYPT, FCS_COP.1/HASH, FCS_COP.1/SIGN, FCS_COP.1/HMAC, FDP_IFC_EXT.1, FIA_X509_EXT.1, FIA_X509_EXT.2, FTP_ITC_EXT.1 Rationale for a big chunk

6 Consistency Rationale

Appendix A - Optional SFRs

Appendix B - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP-Module.

B.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:
Table 3: Extended Component Definitions
Functional ClassFunctional Components
Cryptographic Support (FCS)FCS_CKM_EXT Cryptographic Key Management
Security Audit (FAU)FAU_STG_EXT Security Store Filtering

B.2 Extended Component Definitions

B.2.1 Cryptographic Support (FCS)

This PP-Module defines the following extended components as part of the FCS class originally defined by CC Part 2:

B.2.1.1 FCS_CKM_EXT Cryptographic Key Management

Family Behavior

This family defines requirements for management of cryptographic keys.

Component Leveling

FCS_CKM_EXT

B.2.2 Security Audit (FAU)

THis is information about the FAU class.

B.2.2.1 FAU_STG_EXT Security Store Filtering

Appendix C - Inherently Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this Protection Profile. However, these requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the Protection Profile provides evidence that these controls are present and have been evaluated.
Requirement Rationale for Satisfaction
FIA_UAU.1 - Timing of authentication FIA_AFL.1 implicitly requires that the OS perform all necessary actions, including those on behalf of the user who has not been authenticated, in order to authenticate; therefore it is duplicative to include these actions as a separate assignment and test.
FIA_UID.1 - Timing of identification FIA_AFL.1 implicitly requires that the OS perform all necessary actions, including those on behalf of the user who has not been identified, in order to authenticate; therefore it is duplicative to include these actions as a separate assignment and test.
FMT_SMR.1 - Security roles FMT_MOF_EXT.1 specifies role-based management functions that implicitly defines user and privileged accounts; therefore, it is duplicative to include separate role requirements.
FPT_STM.1 - Reliable time stamps FAU_GEN.1.2 explicitly requires that the OS associate timestamps with audit records; therefore it is duplicative to include a separate timestamp requirement.
FTA_SSL.1 - TSF-initiated session locking FMT_MOF_EXT.1 defines requirements for managing session locking; therefore, it is duplicative to include a separate session locking requirement.
FTA_SSL.2 - User-initiated locking FMT_MOF_EXT.1 defines requirements for user-initiated session locking; therefore, it is duplicative to include a separate session locking requirement.
FAU_STG.1 - Protected audit trail storage FPT_ACF_EXT.1 defines a requirement to protect audit logs; therefore, it is duplicative to include a separate protection of audit trail requirements.
FAU_GEN.2 - User identity association FAU_GEN.1.2 explicitly requires that the OS record any user account associated with each event; therefore, it is duplicative to include a separate requirement to associate a user account with each event.
FAU_SAR.1 - Audit review FPT_ACF_EXT.1.2 requires that audit logs (and other objects) are protected from reading by unprivileged users; therefore, it is duplicative to include a separate requirement to protect only the audit information.

Appendix D - Acronyms

AcronymMeaning
AESAdvanced Encryption Standard
APIApplication Programming Interface
APIApplication Programming Interface
appApplication
ASLRAddress Space Layout Randomization
CEMCommon Evaluation Methodology
CESGCommunications-Electronics Security Group
CMCCertificate Management over CMS
CMSCryptographic Message Syntax
CNCommon Names
cPPCollaborative Protection Profile
CRLCertificate Revocation List
CSAComputer Security Act
CSPCritical Security Parameters
DARData At Rest
DEPData Execution Prevention
DESData Encryption Standard
DHEDiffie-Hellman Ephemeral
DNSDomain Name System
DRBGDeterministic Random Bit Generator
DSSDigital Signature Standard
DSSDigital Signature Standard
DTDate/Time Vector
DTLSDatagram Transport Layer Security
EAPExtensible Authentication Protocol
ECDHEElliptic Curve Diffie-Hellman Ephemeral
ECDSAElliptic Curve Digital Signature Algorithm
EPExtended Package
ESTEnrollment over Secure Transport
FIPSFederal Information Processing Standards
FPFunctional Package
HMACHash-based Message Authentication Code
HTTPHypertext Transfer Protocol
HTTPSHypertext Transfer Protocol Secure
IETFInternet Engineering Task Force
IPInternet Protocol
ISOInternational Organization for Standardization
ITInformation Technology
ITSEFInformation Technology Security Evaluation Facility
NIAPNational Information Assurance Partnership
NISTNational Institute of Standards and Technology
OCSPOnline Certificate Status Protocol
OEOperational Environment
OIDObject Identifier
OMBOffice of Management and Budget
OSOperating System
PIIPersonally Identifiable Information
PKIPublic Key Infrastructure
PPProtection Profile
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RBGRandom Bit Generator
RFCRequest for Comment
RNGRandom Number Generator
RNGVSRandom Number Generator Validation System
S/MIMESecure/Multi-purpose Internet Mail Extensions
SANSubject Alternative Name
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
SHASecure Hash Algorithm
SIPSession Initiation Protocol
STSecurity Target
SWIDSoftware Identification
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
URIUniform Resource Identifier
URLUniform Resource Locator
USBUniversal Serial Bus
VMVirtual Machine
XCCDFeXtensible Configuration Checklist Description Format
XORExclusive Or

Appendix E - Bibliography

IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM] Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 4, September 2012.
[CESG]CESG - End User Devices Security and Configuration Guidance
[CSA] Computer Security Act of 1987, H.R. 145, June 11, 1987.
[OMB] Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.