Collaborative 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.1Security Functional Requirements5.1.1Something5.1.2QQQQ5.1.3QQQQ5.1.4Security Management (FMT)5.1.5Security Audit (FAU)5.1.6TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documentation5.2.4Class ALC: Life-cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Implementation-based RequirementsA.1Widget ThingAppendix B - Extended Component DefinitionsB.1Extended Components TableB.2Extended Component DefinitionsB.2.1Security Audit (FAU)B.2.1.1FAU_STG_EXT Security Store FilteringAppendix C - Inherently Satisfied RequirementsAppendix D - Use Case TemplatesD.1Elephant-own deviceAppendix E - AcronymsAppendix F - Bibliography

1 Introduction

1.1 Overview

Content added 11 Feb 2021: 1307pm. Content added 11 Feb 2021: 1249pm. 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].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
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 D.1 Elephant-own device.

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-based SFRs, and Optional SFRs (dated May 2017).

CC Conformance Claims
This PP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
PP Claim
This PP does not claim conformance to any Protection Profile.
Package Claim
This PP is Functional Package for Transport Layer Security (TLS), version 1.1 Conformant and Functional Package for Secure Shell (SSH), version 1.0 Conformant.

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

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 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 Security Functional Requirements

5.1.1 Something

Here's whwere we talk about an audit table.
Table 2: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_STG_EXT.1
Failure of audit data capture due to lack of disk space or pre-defined limit. On failure of logging function, capture record of failure and record upon restart of logging function. No additional information
FQQ_QQQ.1
On failure of audit data capture due to lack of disk space or pre-defined limit. None.

5.1.2 QQQQ

FOO_FOO.1 Foo Foo

The TOE shall consiste of [selection: soup, salad ] followed by [selection: pizza, spaghetti, ratatouille, sushi ] with [selection: white, red ].
Application Note:
Validation Guidelines:

Rule #1
Evaluation Activities
FOO_FOO.1
The following content should be included if:
Check for anchovies
Specific to the componenet
TSS
ABC
FOO_FOO.1.1
Specific to the element
TSS
ABC

FOO_BAR.1 Foo Bar

The TOE shall drink [selection: tea, coffee ].
Application Note:
Validation Guidelines:

Rule #2: Selections tea and crackers must be chosen together or not at all.
The TOE shall eat [selection: crackers, nothing ]
Application Note: Deonstrating rules across elements
Validation Guidelines:

Rule #2: Selections tea and crackers must be chosen together or not at all.
Testing selectables
  • something
  • [selection:
    • abc
    • def
    ]
  • somethingelse
Evaluation Activities
FOO_BAR.1
SomethingSomething
TSS
ABC
Guidance
Some guidance

5.1.3 QQQQ

FQQ_QQQ.1 QQQQQ

The TOE shall do either [selection: this, that ].
Application Note:
Evaluation Activities
FQQ_QQQ.1
TSS
Activities assoiated with the TSS.
Guidance
Activities assoiated with guidance
Tests
  • Test 1: Make shadow puppets.
    Test 1.1This is the motivation behind the tests.
    Evidence:A warm fuzzy feeling
Activities assoiated with the Tests.
The following content should be included if:
Great tests for something virtual.
The following content should be included if:
  • For physical/imaginary TOEs
Great tests for something tangible or in my mind.

FQQ_QQQ.3 BQQQQQ

This is an objective component.
The TOE shall do [assignment: guidance on what things should be assignable ].
Application Note: Notes. Notes. Notes.
Evaluation Activities
FQQ_QQQ.3
Guidance
Activities assoiated with guidance

FQQ_QQQ.2 TQQQQQ

This is an optional component. However, applied modules or packages might redefine it as mandatory.
The TOE shall do soemthing.
Application Note:
Evaluation Activities
FQQ_QQQ.2
TSS
Activities assoiated with the TSS.

FQQ_QQQ.4 UQQQQQ

This is a selection-based component. Its inclusion depends upon selection from FQQ_QQQ.1.1.
The TOE shall do something great.
Application Note:
Evaluation Activities
FQQ_QQQ.4
TSS
Activities assoiated with the TSS.

FQQ_QQQ.6 WQQQQQ

This is an implementation-based component. Its inclusion in depends on whether the TOE implements one or more of the following features: as described in Appendix A: Implementation-based Requirements.
The TOE shall do something with regards to some implementation.
Application Note:
Evaluation Activities
FQQ_QQQ.6
TSS
Activities assoiated with the TSS.

5.1.4 Security Management (FMT)

FMT_SMF.1/HOST Specification of Management Functions (EDR Management of Host Agent)

The EDR shall be capable of performing the following functions that control behavior of the Host Agent:
#Management FunctionAdministratorSOC AnalystRead-Only User
1Configure the time frame for sending Host Agent data to the EDR [assignment: list of configurable time frames]
MMandatory
OOptional
-N/A
2Assign a label or tag to categorize or group individual endpoint systems
MMandatory
OOptional
-N/A
Application Note: This requirement captures all the configuration functionality the EDR provides the administrator to configure the EDR Host Agents.

Chart legend: X = Mandatory, O = Optional, - = N/A
Evaluation Activities
FMT_SMF.1/HOST
TSS
The evaluator shall verify the ST contains a list of roles and what functions they can perform. The evaluator shall verify the list matches the chart in the requirement.
Guidance
The evaluator shall review the operational guidance to verify that the EDR has documented capabilities to perform the management functions.
Tests
The evaluator shall perform the below tests:
  • Test 2: The evaluator shall modify the time frame for sending Host Agent data to the EDR and verify that an affected Host Agent is sending data at the intended interval.
  • Test 3: The evaluator shall tag or categorize a group of individual endpoint systems and verify that the tag or categorization persists within the EDR management dashboard for other users.
  • Test 4: The evaluator shall attempt each function with each role and verify access conforms with the chart in the requirement.
Test 5This is the motivation behind the tests.
Evidence:A check should appear.

5.1.5 Security Audit (FAU)

FAU_GEN.1 Audit Data Generation

The TSF shall be able to generate an audit record of the following auditable events:
  1. Start-up and shutdown of audit functions
  2. All administrative actions
  3. [Specifically defined auditable events in Table 1]
  4. [selection: additional information defined in Table 2, additional information defined in Table 3, additional information defined in Table 4, additional information defined in in Table 5, no other information ]
The TSF shall record within each audit record at least the following information:
  1. Date and time of the event
  2. Type of event
  3. Subject and object identity (if applicable)
  4. The outcome (success or failure) of the event
  5. [Additional information defined in Table 1]
  6. [selection: additional information defined in Table 2, additional information defined in Table 3, additional information defined in Table 4, additional information defined in in Table 5, no other information ]
Application Note: The ST author can include other auditable events directly in Table 1; they are not limited to the list presented. The ST author should update the table in FAU_GEN.1.2 with any additional information generated. “Subject identity” in FAU_GEN.1.2 could be a user id or an identifier specifying a VM, for example.

If ‘additional information defined in Table 3’ is selected, it is acceptable to include individual entries from Table 3 without including the entirety of Table 3. Appropriate entries from Tables 2, 4, and 5 should be included in the ST if the associated SFRs and selections are included.

The Table 1 entry for FDP_VNC_EXT.1 refers to configuration settings that attach VMs to virtualized network components. Changes to these configurations can be made during VM execution or when VMs are not running. Audit records must be generated for either case.

The intent of the audit requirement for FDP_PPR_EXT.1 is to log that the VM is connected to a physical device (when the device becomes part of the VM’s hardware view), not to log every time that the device is accessed. Generally, this is only once at VM startup. However, some devices can be connected and disconnected during operation (e.g., virtual USB devices such as CD-ROMs). All such connection/disconnection events must be logged.
Evaluation Activities
FAU_GEN.1
TSS
The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type shall be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described in the TSS.

Guidance
The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the administrative guide and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security-relevant with respect to this PP.

Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed and administrative actions. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly.
See Table t-audit-mandatory for more information.

FAU_SAR.1 Audit Review

The TSF shall provide [administrators] with the capability to read [all information] from the audit records.
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
Evaluation Activities
FAU_SAR.1
Guidance
The evaluator shall review the operational guidance for the procedure on how to review the audit records.
Tests
The evaluator shall verify that the audit records provide all of the information specified in FAU_GEN.1 and that this information is suitable for human interpretation. The assurance activity for this requirement is performed in conjunction with the assurance activity for FAU_GEN.1.

FAU_STG.1 Protected Audit Trail Storage

The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
The TSF shall be able to [prevent] modifications to the stored audit records in the audit trail.
Application Note: The assurance activity for this SFR is not intended to imply that the TOE must support an administrator’s ability to designate individual audit records for deletion. That level of granularity is not required.
Evaluation Activities
FAU_STG.1
The evaluator shall ensure that the TSS describes how the audit records are protected from unauthorized modification or deletion. The evaluator shall ensure that the TSS describes the conditions that must be met for authorized deletion of audit records. The evaluator shall perform the following tests:

Tests
  • Test 6: The evaluator shall access the audit trail as an unauthorized Administrator and attempt to modify and delete the audit records. The evaluator shall verify that these attempts fail.
  • Test 7: The evaluator shall access the audit trail as an authorized Administrator and attempt to delete the audit records. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records authorized for deletion are deleted.

FAU_STG_EXT.1 Off-Loading of Audit Data

The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1.
The TSF shall [selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records], [assignment: other action] ] when the local storage space for audit data is full.
Application Note: An external log server, if available, might be used as alternative storage space in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the new audit data to an external IT entity’.
Evaluation Activities
FAU_STG_EXT.1
Protocols used for implementing the trusted channel must be selected in FTP_ITC_EXT.1.
TSS
The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The evaluator shall examine the TSS to ensure it describes what happens when the local audit data store is full.
Guidance
The evaluator shall examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. The evaluator shall also examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the audit server.
Tests
Testing of the trusted channel mechanism is to be performed as specified in the assurance activities for FTP_ITC_EXT.1.

The evaluator shall perform the following test for this requirement:

  • Test 8: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.
The evaluator shall perform operations that generate audit data and verify that this data is stored locally. The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behavior defined in the ST for FAU_STG_EXT.1.2.

FAU_ARP.1 Security Audit Automatic Response

This is an optional component. However, applied modules or packages might redefine it as mandatory.
The TSF shall take [assignment: list of actions] upon detection of a potential security violation.
Application Note: In certain cases, it may be useful for Virtualization Systems to perform automated responses to certain security events. An example may include halting a VM which has taken some action to violate a key system security policy. This may be especially useful with headless endpoints when there is no human user in the loop.

The potential security violation mentioned in FAU_ARP.1.1 refers to FAU_SAA.1.
Evaluation Activities
FAU_ARP.1
Tests
The evaluator shall generate a potential security violation as defined in FAU_SAA.1 and verify that each action in the assignment in FAU_ARP.1.1 is performed by the TSF as a result. The evaluator shall perform this action for each security violation that is defined in FAU_SAA.1.

FAU_SAA.1 Security Audit Analysis

This is an optional component. However, applied modules or packages might redefine it as mandatory.
The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the enforcement of the SFRs.
The TSF shall enforce the following rules for monitoring audited events:
  1. accumulation or combination of [assignment: subset of defined auditable events] known to indicate a potential security violation
  2. [assignment: any other rules]
Application Note: The potential security violation described in FAU_SAA.1 can be used as a trigger for automated responses as defined in FAU_ARP.1.
Evaluation Activities
FAU_SAA.1
Tests
The evaluator shall cause each combination of auditable events defined in FAU_SAA.1.2 to occur, and verify that a potential security violation is indicated by the TSF.

5.1.6 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 3: 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

5.2 Security Assurance Requirements

The Security Objectives in Section 4 Security Objectives were constructed to address threats identified in Section 3.1 Threats. The Security Functional Requirements (SFRs) in Section 5.1 Security Functional Requirements are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Assurance Activities o be performed are specified both in Section 5.1 Security Functional Requirements as well as in this section.
The general model for evaluation of OSs against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation, the TSEF will obtain the OS, supporting environmental IT, and the administrative/user guides for the OS. The ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Assurance Activities contained within Section 5.1 Security Functional Requirements, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the OS. The Assurance Activities that are captured in Section 5.1 Security Functional Requirements also provide clarification as to what the developer needs to provide to demonstrate the OS is compliant with the PP.

5.2.1 Class ASE: Security Target

As per ASE activities defined in [CEM].

5.2.2 Class ADV: Development

The information about the OS is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The OS developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The Assurance Activities contained in Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

The functional specification describes the TSFIs. It is not necessary to have a formal or complete specification of these interfaces. Additionally, because OSs conforming to this PP will necessarily have interfaces to the Operational Environment that are not directly invokable by OS users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the activities for this family should focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional “functional specification” documentation is necessary to satisfy the assurance activities specified. The interfaces that need to be evaluated are characterized through the information needed to perform the assurance activities listed, rather than as an independent, abstract list.

Developer action elements:

The developer shall provide a functional specification.

Content and presentation elements:

The developer shall provide a tracing from the functional specification to the SFRs.
Application Note: As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation. The developer may reference a website accessible to application developers and the evaluator. The assurance activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.
The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
Evaluation Activities
ADV_FSP.1
There are no specific assurance activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.

5.2.3 Class AGD: Guidance Documentation

The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes instructions to successfully install the TSF in that environment; and Instructions to manage the security of the TSF as a product and as a component of the larger operational environment. Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the assurance activities specified with each requirement.

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

The developer shall provide operational user guidance.
Application Note: The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. Rather than repeat information here, the developer should review the assurance activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance.

Content and presentation elements:

The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
Application Note: User and administrator are to be considered in the definition of user role.
The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the OS in a secure manner.
The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
Application Note: This portion of the operational user guidance should be presented in the form of a checklist that can be quickly executed by IT personnel (or end-users, when necessary) and suitable for use in compliance activities. When possible, this guidance is to be expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to support security automation. Minimally, it should be presented in a structured format which includes a title for each configuration item, instructions for achieving the secure configuration, and any relevant rationale.
The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
The operational user guidance shall identify all possible modes of operation of the OS (including operation following failure or operational error), their consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
The operational user guidance shall be clear and reasonable.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
AGD_OPE.1
Some of the contents of the operational guidance are verified by the assurance activities in Section 5.1 Security Functional Requirements and evaluation of the OS according to the [CEM]. The following additional information is also required. If cryptographic functions are provided by the OS, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the OS. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the OS. The documentation must describe the process for verifying updates to the OS by verifying a digital signature – this may be done by the OS or the underlying platform. The evaluator will verify that this process includes the following steps: Instructions for obtaining the update itself. This should include instructions for making the update accessible to the OS (e.g., placement in a specific directory). Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature. The OS will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

Developer action elements:

The developer shall provide the OS, including its preparative procedures.
Application Note: As with the operational guidance, the developer should look to the assurance activities to determine the required content with respect to preparative procedures.

Content and presentation elements:

The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered OS in accordance with the developer's delivery procedures.
The preparative procedures shall describe all the steps necessary for secure installation of the OS and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall apply the preparative procedures to confirm that the OS can be prepared securely for operation.
Evaluation Activities
AGD_PRE.1
As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support OS functional requirements. The evaluator shall check to ensure that the guidance provided for the OS adequately addresses all platforms claimed for the OS in the ST.

5.2.4 Class ALC: Life-cycle Support

At the assurance level provided for OSs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the OS vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level.

ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)

This component is targeted at identifying the OS such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user.

Developer action elements:

The developer shall provide the OS and a reference for the OS.

Content and presentation elements:

The OS shall be labeled with a unique reference.
Application Note: Unique reference information includes:
  • OS Name
  • OS Version
  • OS Description
  • Software Identification (SWID) tags, if available

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_CMC.1
The evaluator will check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator will check the AGD guidance and OS samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the OS, the evaluator will examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product.

ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)

Given the scope of the OS and its associated evaluation evidence requirements, this component’s assurance activities are covered by the assurance activities listed for ALC_CMC.1.

Developer action elements:

The developer shall provide a configuration list for the OS.

Content and presentation elements:

The configuration list shall include the following: the OS itself; and the evaluation evidence required by the SARs.
The configuration list shall uniquely identify the configuration items.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_CMS.1
The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the OS is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. Life-cycle support is targeted aspects of the developer’s life-cycle and instructions to providers of applications for the developer’s devices, rather than an in-depth examination of the TSF manufacturer’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it’s a reflection on the information to be made available for evaluation.
The evaluator will ensure that the developer has identified (in guidance documentation for application developers concerning the targeted platform) one or more development environments appropriate for use in developing applications for the developer’s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) are invoked (e.g., compiler and linker flags). The evaluator will ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. The evaluator will ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification.

ALC_TSU_EXT.1 Timely Security Updates

This component requires the OS developer, in conjunction with any other necessary parties, to provide information as to how the end-user devices are updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, carriers(s)) and the steps that are performed (e.g., developer testing, carrier testing), including worst case time periods, before an update is made available to the public.

Developer action elements:

The developer shall provide a description in the TSS of how timely security updates are made to the OS.
The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product.

Content and presentation elements:

The description shall include the process for creating and deploying security updates for the OS software.
The description shall include the mechanisms publicly available for reporting security issues pertaining to the OS.
Note: The reporting mechanism could include web sites, email addresses, as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_TSU_EXT.1
The evaluator will verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator will verify that this description addresses the entire application. The evaluator will also verify that, in addition to the OS developer’s process, any third-party processes are also addressed in the description. The evaluator will also verify that each mechanism for deployment of security updates is described.
The evaluator will verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the OS patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator will verify that this time is expressed in a number or range of days.
The evaluator will verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the OS. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website.

5.2.5 Class ATE: Tests

Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements.

ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)

Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operational) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met, although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The Assurance Activities identify the additional testing activities associated with these components. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/OS combinations that are claiming conformance to this PP. Given the scope of the OS and its associated evaluation evidence requirements, this component’s assurance activities are covered by the assurance activities listed for ALC_CMC.1.

Developer action elements:

The developer shall provide the OS for testing.

Content and presentation elements:

The OS shall be suitable for testing.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
Application Note: The evaluator will test the OS on the most current fully patched version of the platform.
Evaluation Activities
ATE_IND.1
The evaluator will prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. The test plan covers all of the testing actions contained in the [CEM] and the body of this PP’s Assurance Activities.
While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered. The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the OS and its platform.
This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS). The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results.
The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.

5.2.6 Class AVA: Vulnerability Assessment

For the first generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the OS. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles.

AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

Developer action elements:

The developer shall provide the OS for testing.

Content and presentation elements:

The OS shall be suitable for testing.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the OS.
Application Note: Public domain sources include the Common Vulnerabilities and Exposures (CVE) dictionary for publicly-known vulnerabilities. Public domain sources also include sites which provide free checking of files for viruses.
The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the OS is resistant to attacks performed by an attacker possessing Basic attack potential.
Evaluation Activities
AVA_VAN.1
The evaluator will generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses. The evaluator documents the sources consulted and the vulnerabilities found in the report.
For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.

Appendix A - Implementation-based Requirements

Implementation-based Requirements are dependent on the TOE implementing a particular function. If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the evaluated configuration.

A.1 Widget Thing

This is a super description of this certain feature.

If this is implemented by the TOE, the following requirements must be included in the ST:

Appendix B - Extended Component Definitions

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

B.1 Extended Components Table

All extended components specified in the PP are listed in this table:
Table 4: Extended Component Definitions
Functional ClassFunctional Components
Security Audit (FAU)FAU_STG_EXT Security Store Filtering

B.2 Extended Component Definitions

B.2.1 Security Audit (FAU)

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

B.2.1.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 - Use Case Templates

D.1 Elephant-own device

The configuration for [USE CASE 1] Elephant-own device modifies the base requirements as follows:
From FOO_FOO.1.1:
* select soup
Do not choose:
* ratatouille
* pizza
From FAU_GEN.1.1:
Do not choose:
* additional information defined in Table 2
Include FQQ_QQQ.2 in the ST

Appendix E - Acronyms

AcronymMeaning
AESAdvanced Encryption Standard
APIApplication Programming Interface
APIApplication Programming Interface
appApplication
ASLRAddress Space Layout Randomization
Base-PPBase Protection Profile
CCCommon Criteria
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 F - 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.