Version | Date | Comment |
---|---|---|
4.4 | 2024-09-06 |
|
4.3 | 2022-09-27 |
|
4.2.1 | 2019-04-22 | Formatting changes as a result of PP evaluation |
4.2 | 2018-05-22 | Multiple Technical Decisions applied |
4.1 | 2016-03-09 | Minor updates - cryptographic modes |
4.0 | 2015-08-14 | Release - significant revision |
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. |
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 which are typically used in 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. |
Hybrid Authentication | A hybrid authentication factor is one where a user has to submit a combination of a cryptographic token and a PIN or password and both must pass. If either factor fails, the entire attempt fails. |
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. |
Personal Identification Number (PIN) | An authentication factor that is comprised of a set of numeric or alphabetic characters that may be used in addition to a cryptographic token to provide a hybrid authentication factor. At this time it is not considered as a stand-alone authentication mechanism. A PIN is distinct from a password in that the allowed character set and required length of a PIN is typically smaller than that of a password as it is designed to be input quickly. |
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. |
The OS provides a platform for end user devices such as desktops, laptops, convertibles, and tablets. These devices may optionally be bound to a directory server or management server.
As this Protection Profile does not address threats against data-at-rest, enterprises deploying operating systems in mobile scenarios should ensure that these systems include data-at-rest protection spelled out in other Protection Profiles. Specifically, this includes the Protection Profiles for Full Drive Encryption - Encryption Engine, Full Drive Encryption - Authorization Acquisition, and Software File Encryption. The Protection Profile for Mobile Device Fundamentals includes requirements for data-at-rest protection and is appropriate for many mobile devices.
The OS provides a platform for providing cloud services running on physical or virtual hardware. An OS is typically part of offerings identified as Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS).
This use case typically involves the use of virtualization technology which should be evaluated against the Protection Profile for Server Virtualization.
Assumption or OSP | Security Objectives | Rationale |
A.PLATFORM | OE.PLATFORM | The operational environment objective OE.PLATFORM is realized through A.PLATFORM. |
A.PROPER_USER | OE.PROPER_USER | The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. |
A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
The ST author will select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.
If the OS acts only as a receiver in the RSA key establishment scheme, the OS does not need to implement RSA key generation.
“P-256” may only be selected if the PP-Module for Bluetooth V1.0 is included in the ST and may only be used specifically for Bluetooth functions.
The ST author will select all key establishment schemes used for the selected cryptographic protocols.
The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1. The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1. The finite field-based key establishment schemes that conform to NIST SP 800-56A Revision 3 correspond to the "safe-prime" groups selection in FCS_CKM.1.1.
The interface referenced in the requirement could take different forms, the most likely of which is an application programming interface to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation that overwrites a key stored in non-volatile memory, the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation, that instructs the underlying platform to destroy the representation of a key stored in non-volatile memory, the application may simply have a handle to a resource and can only ask the platform to delete the resource, as may be the case with a platforms secure key store. The latter implementation should only be used for the most restricted access. The level of detail to which the TOE has access will be reflected in the TSS section of the ST.
Several selections allow assignment of a 'value that does not contain any CSP.' This means that the TOE uses some other specified data not drawn from a source that may contain key material or reveal information about key material, and not being any of the particular values listed as other selection options. The point of the phrase 'does not contain any CSP' is to ensure that the overwritten data is carefully selected, and not taken from a general 'pool' that might contain current or residual data that itself requires confidentiality protection.
For the selection destruction of all key encrypting keys (KEKs) protecting the target key according to FCS_CKM_EXT.4.1, where none of the KEKs protecting the target key are derived , a key can be considered destroyed by destroying the key that protects the key. If a key is wrapped or encrypted it is not necessary to "overwrite" that key, overwriting the key that is used to wrap or encrypt the key used to encrypt/decrypt data, using the appropriate method for the memory type involved, will suffice. For example, if a product uses a KEK to encrypt a Data Encryption Key (DEK), destroying the KEK using one of the methods in FCS_CKM_EXT.4 is sufficient, since the DEK would no longer be usable (of course, presumes the DEK is still encrypted and the KEK cannot be recovered or re-derived.).
For the purposes of this requirement, key material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc.
Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1.
AES CCMP (which uses AES in CCM as specified in SP 800-38C) becomes mandatory and must be selected if the ST includes the PP-Module for Wireless LAN Clients.
AES-CCM becomes mandatory and must be selected if the ST includes the PP-Module for Bluetooth.
For the second selection, the ST author should choose the mode or modes in which AES operates.
For the third selection, the ST author may only choose 128-bit if the ST includes the PP-Module for Bluetooth, and it may only be used specifically with AES-CCM for Bluetooth functions.
The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used.
The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the OS (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/HASH.
For the selection in this requirement, the ST author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if the seed is formed from a combination of two or more noise sources. If the TSF implements two or more separate DRBGs, this SFR should be isolated. It multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source."
If "TSF noise source" is selected, FCS_RBG.3 must be claimed.
If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.
If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.
# | Management Function | Administrator | User |
1 | Enable/disable [selection: screen lock, session timeout] | MMandatory | OOptional |
2 | Configure [selection: screen lock, session] inactivity timeout | MMandatory | OOptional |
3 | import keys/secrets into the secure key storage | OOptional | OOptional |
4 | Configure local audit storage capacity | OOptional | OOptional |
5 | Configure minimum password length | OOptional | OOptional |
6 | Configure minimum number of special characters in password | OOptional | OOptional |
7 | Configure minimum number of numeric characters in password | OOptional | OOptional |
8 | Configure minimum number of uppercase characters in password | OOptional | OOptional |
9 | Configure minimum number of lowercase characters in password | OOptional | OOptional |
10 | Configure lockout policy for unsuccessful authentication attempts through [selection: timeouts between attempts, limiting number of attempts during a time period] | OOptional | OOptional |
11 | Configure host-based firewall | OOptional | OOptional |
12 | Configure name/address of directory server with which to bind | OOptional | OOptional |
13 | Configure name/address of remote management server from which to receive management settings | OOptional | OOptional |
14 | Configure name/address of audit/logging server to which to send audit/logging records | OOptional | OOptional |
15 | Configure audit rules | OOptional | OOptional |
16 | Configure name/address of network time server | OOptional | OOptional |
17 | Enable/disable automatic software update | OOptional | OOptional |
18 | Configure Wi-Fi interface | OOptional | OOptional |
19 | Enable/disable Bluetooth interface | OOptional | OOptional |
20 | Enable/disable [assignment: list of other external interfaces] | OOptional | OOptional |
21 | [assignment: list of other management functions to be provided by the TSF] | OOptional | OOptional |
The ST should indicate which of the optional management functions are implemented in the TOE. This can be done by copying the above table into the ST and adjusting the "Administrator" and "User" columns to "M" according to which capabilities are present or not present, and for which privilege level. The Application Note for FMT_MOF_EXT.1 explains how to indicate Administrator or User capability.
The terms "Administrator" and "User" are defined in the glossary. The intent of this requirement is to ensure that the ST is populated with the relevant management functions that are provided by the OS.
Sophisticated account management policies, such as intricate password complexity requirements and handling of temporary accounts, are a function of directory servers. The OS can enroll in such account management and enable the overall information system to achieve such policies by binding to a directory server.
If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test.
For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1.
If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test.
The bootchain of the OS is the sequence of software, to include the OS loader, the kernel, system drivers or modules, and system files, which ultimately result in loading the OS. The first part of the OS, usually referred to as the first-stage bootloader, must be loaded by the platform. Assessing its integrity, while critical, is the platform's responsibility; and therefore outside the scope of this PP. All software loaded after this stage is potentially within the control of the OS and is in scope.
The verification may be transitive in nature: a hardware-protected public key, X509 certificate or hash may be used to verify the mutable bootloader code which contains a key, certificate, or hash used by the bootloader to verify the mutable OS kernel code, which contains a key, certificate, or hash to verify the next layer of executable code, and so on. However, the way in which the hardware stores and protects these keys is out of scope.
If all executable code (including bootloader(s), kernel, device drivers, pre-loaded applications, user-loaded applications, and libraries) is verified, all executable code stored in mutable media should be selected.
If certificates are used, they can be hardware-protected trust store elements or leaf certificates in a certificate chain that terminates in a root CA which is an element of a hardware protected trust store. If the certificates themselves are not trust store elements, revocation information is expected to be available for each CA certificate in the chain that is not a trust element, in accordance with FIA_X509_EXT.1 as defined in the Functional Package for X.509.
The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1.1 in the main body of the ST.
If TLS or DTLS is selected, the TSF must be validated against the appropriate requirements in the Functional Package for Transport Layer Security (TLS), version 1.1.
If IPsec as conforming to the PP-Module for Virtual Private Network (VPN) Clients is selected, then FDP_IFC_EXT.1 must be included in the ST.
If SSH is selected, the TSF must be validated against the Functional Package for Secure Shell (SSH), version 1.0 and the corresponding selection is expected to be made in FIA_UAU.5.1. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST.
This requirement ensures that all remote administrative actions are protected. Authorized remote administrators must initiate all communication with the OS via a trusted path and all communication with the OS by remote administrators must be performed over this path. The data passed in this trusted communication channel is encrypted as defined in FTP_ITC_EXT.1.1. If local users access is selected and no unprotected traffic is sent to remote users, then this requirement is met. If remote users access is selected, the ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1.1 in the main body of the ST.
This requirement ensures that authorized remote administrators initiate all communication with the OS via a trusted path, and that all communication with the OS by remote administrators is performed over this path. The data passed in this trusted communication channel is encrypted as defined in FTP_ITC_EXT.1.
If "remote" is selected in FTP_TRP.1.1, "all remote administrative actions" must be selected in FTP_TRP.1.3.
If "local" is selected in FTP_TRP.1.1, then "initial user authentication" must be selected in FTP_TRP.1.3.
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
Threat | Addressed by | Rationale |
---|---|---|
T.NETWORK_ATTACK | FAU_GEN.1 | FAU_GEN.1 helps mitigate the threat of a network attack by logging evidence of potential malicious activity. |
FCS_CKM.1 | FCS_CKM.1 helps mitigate the threat of a network attack by ensuring the generation of strong keys used for trusted communications. | |
FCS_CKM.2 | FCS_CKM.2 helps mitigate the threat of a network attack by implementing secure methods to perform key establishment for trusted communications. | |
FCS_CKM_EXT.4 | FCS_CKM_EXT.4 helps mitigate the threat of a network attack by ensuring that keys used for trusted communications are destroyed in a secure manner. | |
FCS_COP.1/ENCRYPT | FCS_COP.1/ENCRYPT helps mitigate the threat of a network attack by ensuring that secure symmetric algorithms are used for trusted communications. | |
FCS_COP.1/HASH | FCS_COP.1/HASH helps mitigate the threat of a network attack by ensuring that secure hash algorithms are used for trusted communications. | |
FCS_COP.1/KEYHMAC | FCS_COP.1/KEYHMAC helps mitigate the threat of a network attack by ensuring that secure HMAC algorithms are used for trusted communications. | |
FCS_COP.1/SIGN | FCS_COP.1/SIGN helps mitigate the threat of a network attack by ensuring that secure digital signature algorithms are used for trusted communications. | |
FCS_RBG.1 | FCS_RBG.1 helps mitigate the threat of a network attack by ensuring that keys used for trusted communications are generated using a secure DRBG. | |
FIA_AFL.1 | FIA_AFL.1 helps mitigate the threat of a network attack by preventing an unprivileged user from logging into a network interface by brute force guessing the credential. | |
FIA_UAU.5 | FIA_UAU.5 helps mitigate the threat of a network attack by providing specified authentication mechanisms for network user authentication. | |
FMT_MOF_EXT.1 | FMT_MOF_EXT.1 helps mitigate the threat of a network attack by limiting the management functions that are available to a given user. | |
FMT_SMF_EXT.1 | FMT_SMF_EXT.1 helps mitigate the threat of a network attack by limiting the management functions that are available to a given user. | |
FPT_ACF_EXT.1 | FPT_ACF_EXT.1 helps mitigate the threat of a network attack by limiting the ability of an unprivileged user to modify the behavior of the TSF. | |
FPT_ASLR_EXT.1 | helps mitigate the threat of a network attack by limiting the ability to modify the behavior of the TSF via memory overflow. | |
FPT_FLS.1 | FPT_FLS.1 helps mitigate the threat of a network attack by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys. | |
FPT_SBOP_EXT.1 | helps mitigate the threat of a network attack by limiting the ability to modify the behavior of the TSF via stack overflow. | |
FPT_TST.1 | FPT_TST.1 helps mitigate the threat of a network attack by implementing a mechanism to detect when the DRBG may be failing to generate secure cryptographic keys. | |
FTP_ITC_EXT.1 | FTP_ITC_EXT.1 helps mitigate the threat of a network attack by requiring the TSF to implement trusted protocols for network communication. | |
FTP_TRP.1 | FTP_TRP.1 helps mitigate the threat of a network attack by requiring the use of a trusted path for any remote administration that can be performed on the TOE. | |
FCS_RBG.6 (optional) | FCS_RBG.6 helps mitigate the threat of a network attack by providing a secure DRBG service for third-party applications running on the TOE which may use this service to generate their own cryptographic keys for trusted communications. | |
FPT_W^X_EXT.1 (optional) | FPT_W^X_EXT.1 helps mitigate the threat of a network attack by enforcing data execution prevention so that an external interface cannot attempt to write data to executable memory. | |
FTA_TAB.1 (optional) | FTA_TAB.1 helps mitigate the threat of a network attack by providing actionable consequences for misuse of the TSF. | |
FPT_BLT_EXT.1 (objective) | FPT_BLT_EXT.1 helps mitigate the threat of a network attack by enforcing least functionality of the TOE's Bluetooth interface. | |
FCS_RBG.2 (selection-based) | FCS_RBG.2 helps mitigate the threat of a network attack by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.3 (selection-based) | FCS_RBG.3 helps mitigate the threat of a network attack by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.4 (selection-based) | FCS_RBG.4 helps mitigate the threat of a network attack by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.5 (selection-based) | FCS_RBG.5 helps mitigate the threat of a network attack by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FDP_IFC_EXT.1 (selection-based) | FDP_IFC_EXT.1 helps mitigate the threat of a network attack by ensuring that the TOE has the ability to enforce the use of an IPsec VPN for all network traffic. | |
FCS_SSH_EXT.1 (SSH Package) | Helps mitigate the threat of a network attack by defining the TOE's implementation of SSH if this protocol is used for protected communications. | |
FCS_SSHC_EXT.1 (SSH Package) | Helps mitigate the threat of a network attack by defining the TOE's implementation of SSH as a client if this protocol is used for protected communications. | |
FCS_SSHS_EXT.1 (SSH Package) | Helps mitigate the threat of a network attack by defining the TOE's implementation of SSH as a server if this protocol is used for protected communications. | |
FCS_TLS_EXT.1 (TLS Package) | Helps mitigate the threat by identifying the TOE's support for TLS or DTLS as trusted communications channels. | |
FCS_DTLSC_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_TLSC_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FIA_XCU_EXT.1 (X.509 Package) | Helps mitigate the threat of a network attack by requiring the use of X.509 certificates to validate the authenticity of network entities. | |
FIA_XCU_EXT.2 (X.509 Package) | Helps mitigate the threat of a network attack by requiring the use of X.509 certificates to assert its own identity to external entities. | |
FIA_X509_EXT.1 (X.509 Package) | Helps mitigate the threat of a network attack by defining how X.509 certificates are validated. | |
FIA_X509_EXT.2 (X.509 Package) | Helps mitigate the threat of a network attack by defining where X.509 certificates are used. | |
T.NETWORK_EAVESDROP | FCS_CKM.1 | FCS_CKM.1 helps mitigate the threat of network eavesdropping by ensuring the generation of strong keys used for trusted communications. |
FCS_CKM.2 | FCS_CKM.2 helps mitigate the threat of network eavesdropping by implementing secure methods to perform key establishment for trusted communications. | |
FCS_CKM_EXT.4 | FCS_CKM_EXT.4 helps mitigate the threat of network eavesdropping by ensuring that keys used for trusted communications are destroyed in a secure manner. | |
FCS_COP.1/ENCRYPT | FCS_COP.1/ENCRYPT helps mitigate the threat of network eavesdropping by ensuring that secure symmetric algorithms are used for trusted communications. | |
FCS_COP.1/HASH | FCS_COP.1/HASH helps mitigate the threat of network eavesdropping by ensuring that secure hash algorithms are used for trusted communications. | |
FCS_COP.1/KEYHMAC | FCS_COP.1/KEYHMAC helps mitigate the threat of network eavesdropping by ensuring that secure HMAC algorithms are used for trusted communications. | |
FCS_COP.1/SIGN | FCS_COP.1/SIGN helps mitigate the threat of network eavesdropping by ensuring that secure digital signature algorithms are used for trusted communications. | |
FCS_RBG.1 | FCS_RBG.1 helps mitigate the threat of network eavesdropping by ensuring that keys used for trusted communications are generated using a secure DRBG. | |
FPT_FLS.1 | FPT_FLS.1 helps mitigate the threat of network eavesdropping by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys. | |
FPT_TST.1 | FPT_TST.1 helps mitigate the threat of network eavesdropping by implementing a mechanism to detect when the DRBG may be failing to generate seucre cryptographic keys. | |
FTP_ITC_EXT.1 | FTP_ITC_EXT.1 helps mitigate the threat of network eavesdropping by requiring the TSF to implement trusted protocols for network communication. | |
FTP_TRP.1 | FTP_TRP.1 helps mitigate the threat of network eavesdropping by requiring the use of a trusted path for any remote administration that can be performed on the TOE. | |
FCS_RBG.6 (optional) | FCS_RBG.6 helps mitigate the threat of network eavesdropping by providing a secure DRBG service for third-party applications running on the TOE which may use this service to generate their own cryptographic keys for trusted communications. | |
FPT_BLT_EXT.1 (objective) | FPT_BLT_EXT.1 helps mitigate the threat of network eavesdropping by enforcing least functionality of the TOE's Bluetooth interface. | |
FCS_RBG.2 (selection-based) | FCS_RBG.2 helps mitigate the threat of network eavesdropping by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.3 (selection-based) | FCS_RBG.3 helps mitigate the threat of network eavesdropping by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.4 (selection-based) | FCS_RBG.4 helps mitigate the threat of network eavesdropping by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FCS_RBG.5 (selection-based) | FCS_RBG.5 helps mitigate the threat of network eavesdropping by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys. | |
FDP_IFC_EXT.1 (selection-based) | FDP_IFC_EXT.1 helps mitigate the threat of network eavesdropping by ensuring that the TOE has the ability to enforce the use of an IPsec VPN for all network traffic. | |
FCS_SSH_EXT.1 (SSH Package) | Helps mitigate the threat of network eavesdropping by defining the TOE's implementation of SSH if this protocol is used for protected communications. | |
FCS_SSHC_EXT.1 (SSH Package) | Helps mitigate the threat of network eavesdropping by defining the TOE's implementation of SSH as a client if this protocol is used for protected communications. | |
FCS_SSHS_EXT.1 (SSH Package) | Helps mitigate the threat of network eavesdropping by defining the TOE's implementation of SSH as a server if this protocol is used for protected communications. | |
FCS_TLS_EXT.1 (TLS Package) | Helps mitigate the threat by identifying the TOE's support for TLS or DTLS as trusted communications channels. | |
FCS_DTLSC_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSC_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_DTLSS_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of DTLS as a trusted network communications channel. | |
FCS_TLSC_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSC_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.1 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.2 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.3 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.4 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.5 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FCS_TLSS_EXT.6 (TLS Package) | Helps mitigate the threat by defining the use of TLS as a trusted network communications channel. | |
FIA_XCU_EXT.1 (X.509 Package) | Helps mitigate the threat of network eavesdropping by requiring the use of X.509 certificates to validate the authenticity of network entities. | |
FIA_XCU_EXT.2 (X.509 Package) | Helps mitigate the threat of a network attack by requiring the use of X.509 certificates to assert its own identity to external entities. | |
FIA_X509_EXT.1 (X.509 Package) | Helps mitigate the threat of network eavesdropping by defining how X.509 certificates are validated. | |
FIA_X509_EXT.2 (X.509 Package) | Helps mitigate the threat of network eavesdropping by defining where X.509 certificates are used. | |
T.LOCAL_ATTACK | FAU_GEN.1 | FAU_GEN.1 helps mitigate the threat of a local attack by logging evidence of potential malicious activity. |
FCS_COP.1/HASH | FCS_COP.1/HASH helps mitigate the threat of a local attack by ensuring that secure hash algorithms are used for trusted updates. | |
FCS_COP.1/KEYHMAC | FCS_COP.1/KEYHMAC helps mitigate the threat of a local attack by ensuring that secure HMAC algorithms are used for trusted updates. | |
FCS_COP.1/SIGN | FCS_COP.1/SIGN helps mitigate the threat of a local attack by ensuring that secure digital signature algorithms are used for trusted updates. | |
FCS_STO_EXT.1 | FCS_STO_EXT.1 helps mitigate the threat of a local attack by providing a mechanism to protect sensitive data at rest. | |
FDP_ACF_EXT.1 | FDP_ACF_EXT.1 helps mitigate the threat of a local attack by providing a mechanism to restrict the ability of one user account to access data owned by another user. | |
FIA_AFL.1 | FIA_AFL.1 helps mitigate the threat of a local attack by preventing an unprivileged user from gaining access to the TSF by brute force guessing the credential. | |
FIA_UAU.5 | FIA_UAU.5 helps mitigate the threat of a local attack by providing specified authentication mechanisms for user authentication. | |
FMT_MOF_EXT.1 | FMT_MOF_EXT.1 helps mitigate the threat of a local attack by limiting the management functions that are available to a given user. | |
FMT_SMF_EXT.1 | FMT_SMF_EXT.1 helps mitigate the threat of a local attack by limiting the management functions that are available to a given user. | |
FPT_ACF_EXT.1 | FPT_ACF_EXT.1 helps mitigate the threat of a local attack by limiting the ability of an unprivileged user to modify the behavior of the TSF. | |
FPT_ASLR_EXT.1 | helps mitigate the threat of a local attack by limiting the ability of an application to modify the behavior of the TSF via memory overflow. | |
FPT_SBOP_EXT.1 | helps mitigate the threat of a local attack by limiting the ability of an application to modify the behavior of the TSF via stack overflow. | |
FPT_TST_EXT.1 | helps mitigate the threat of a local attack by ensuring the integrity of the TSF on boot. | |
FPT_TUD_EXT.1 | helps mitigate the threat of a local attack by ensuring the authenticity and integrity of updates applied to the TOE. | |
FPT_TUD_EXT.2 | helps mitigate the threat of a local attack by ensuring the integrity of updates applied to applications running the TOE. | |
FPT_W^X_EXT.1 (optional) | FPT_W^X_EXT.1 helps mitigate the threat of a local attack by enforcing data execution prevention so that an application cannot attempt to write data to executable memory. | |
FTA_TAB.1 (optional) | FTA_TAB.1 helps mitigate the threat of a local attack by providing actionable consequences for misuse of the TSF. | |
FPT_SRP_EXT.1 (objective) | FPT_SRP_EXT.1 helps mitigate the threat of a local attack by preventing the execution of unknown or untrusted software. | |
T.LIMITED_PHYSICAL_ACCESS | FAU_GEN.1 | FAU_GEN.1 helps mitigate the threat of by logging evidence of potential malicious activity should illicit access to the TSF be gained. |
FCS_STO_EXT.1 | FCS_STO_EXT.1 helps mitigate the threat by providing a mechanism to protect sensitive data at rest which prevents exfiltration of sensitive data during a limited access window. | |
FIA_AFL.1 | FIA_AFL.1 helps mitigate the threat by preventing an unprivileged user from gaining access to the TSF by brute force guessing the credential in a limited time window. | |
FIA_UAU.5 | FIA_UAU.5 helps mitigate the threat by providing specified authentication mechanisms for user authentication to prevent unauthorized access to the TOE. | |
FMT_MOF_EXT.1 | FMT_MOF_EXT.1 helps mitigate the threat by limiting the management functions that are available to a given user which minimizes the impact of compromise should illicit access be gained. | |
FMT_SMF_EXT.1 | FMT_SMF_EXT.1 helps mitigate the threat by limiting the management functions that are available to a given user which minimizes the impact of compromise should illicit access be gained. |
The Security Functional Requirements (SFRs) in Section 5.1 Security Functional Requirements are specified to mitigate the threats defined in Section 3.1 Threats. 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 evaluation activities to be performed are specified both in Section 5 Security Requirements as well as in this section.
The general model for evaluation of TOEs against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation, the ITSEF
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 evaluation activities contained within
Section 5 Security 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 evaluation activities that are captured in
Section 5 Security Requirements also provide
clarification as to what the developer needs to provide to demonstrate the OS is compliant
with the PP.
Some Bluetooth services incur more serious consequences if unauthorized remote devices gain access to them. Such services should be protected by measures like disabling support for the associated Bluetooth profile unless it is actively being used by an application on the OS (in order to prevent discovery by a Service Discovery Protocol search), and then requiring explicit user action to enable those profiles in order to use the services. It may be further appropriate to require additional user action before granting a remote device access to that service.
For example, it may be appropriate to disable the OBEX Push Profile until a user pushes a button in an application indicating readiness to transfer an object. After completion of the object transfer, support for the OBEX profile should be suspended until the next time the user requests its use.
This PP does not define any Implementation-dependent requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
This component may also be included in the ST as if optional.
Typically, the traffic required to establish the VPN connection is referred to as "Control Plane" traffic, whereas the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All Data Plane traffic must flow through the VPN connection and the VPN must not split-tunnel.
If no native IPsec client is validated or third-party VPN clients may also implement the required Information Flow Control, the first option must be selected. In these cases, the TOE provides an API to third-party VPN clients that allows them to configure the TOE's network stack to perform the required Information Flow Control.
If the TSF implements a native VPN client, then the ST author must select provide a VPN client that can protect all IP traffic using IPsec and includes the PP-Module for VPN Client as part of the ST.
In the future, this requirement may also make a distinction between the current requirement (which requires that when the IPsec trusted channel is enabled, all traffic from the TSF is routed through that channel) and having an option to force the establishment of an IPsec trusted channel to allow any communication by the TSF.
Functional Class | Functional Components |
---|---|
Cryptographic Support (FCS) | FCS_CKM_EXT Cryptographic Key Management FCS_STO_EXT Storage of Sensitive Data |
Protection of the TSF (FPT) | FPT_ACF_EXT Access Controls FPT_ASLR_EXT Address Space Layout Randomization FPT_BLT_EXT Limitation of Bluetooth Profile Support FPT_SBOP_EXT Stack Buffer Overflow Protection FPT_SRP_EXT Software Restriction Policies FPT_TST_EXT Boot Integrity FPT_TUD_EXT Trusted Update FPT_W^X_EXT Write XOR Execute Memory Pages |
Security Management (FMT) | FMT_MOF_EXT Management of Functions Behavior FMT_SMF_EXT Specification of Management Functions |
Trusted Path/Channels (FTP) | FTP_ITC_EXT Trusted Channel Communication |
User Data Protection (FDP) | FDP_ACF_EXT Access Controls for Protecting User Data FDP_IFC_EXT Information Flow Control |
FCS_CKM_EXT.4, Cryptographic Key Destruction, requires the TSF to destroy cryptographic keys based on one or more specific methods, depending on the physical medium on which the key data is stored. Note that 4 was chosen for the family’s sole component number to show that this requirement is similar to FCS_CKM.4, from which it was originally derived.
There are no management activities foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FCS_STO_EXT.1, Storage of Sensitive Data, requires the TSF to include a mechanism that encrypts sensitive data and that can be invoked by third-party applications in addition to internal TSF usage.
There are no management activities foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation |
FPT_ACF_EXT.1, Access Controls, requires the TSF to prohibit unauthorized users from reading or modifying specific TSF data.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_ASLR_EXT.1, Address Space Layout Randomization, defines the ability of the TOE to use ASLR as well as the objects that ASLR is applied to.
There are no management functions foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_BLT_EXT.1, Limitation of Bluetooth Profile Support, requires the TSF to maintain a disabled by default posture for Bluetooth profiles.
There are no management activities foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_SBOP_EXT.1, Stack Buffer Overflow Protection, requires the TSF to be compiled using stack-based buffer overflow protections or to store data in such a manner that a stack-based buffer overflow cannot compromise the TSF.
There are no management activities foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_SRP_EXT.1, Software Restriction Policies, defines the criteria the TSF can use to prevent execution of restricted programs.
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_TST_EXT.1, Boot Integrity, defines the mechanisms that the TSF uses to assert its own integrity at startup.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FIA_X509_EXT.1 X.509 Certificate Validation |
FPT_TUD_EXT.1, Integrity for Installation and Update, requires the TOE to provide a mechanism to verify the integrity of updates to itself.
FPT_TUD_EXT.2, Integrity for Installation and Update of Application Software, requires the TOE to provide a mechanism to verify the integrity of updates to non-TSF applications that are running on the TOE.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation |
FPT_W^X_EXT.1, Write XOR Execute Memory Pages, defines the ability of the TOE to prevent memory from being simultaneously writable and executable unless otherwise specified.
There are no management functions foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FMT_MOF_EXT.1, Management of Functions Behavior, requires the TSF to define a set of management functions for the TOE and the privileges that are required to administer them.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: | FMT_SMF_EXT.1 Specification of Management Functions |
FMT_SMF_EXT.1, Specification of Management Functions, requires the TSF to define a set of management functions for the TOE.
There are no management functions foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
# | Management Function | Administrator | User |
1 | Enable/disable [selection: screen lock, session timeout] | MMandatory | OOptional |
2 | Configure [selection: screen lock, session] inactivity timeout | MMandatory | OOptional |
3 | import keys/secrets into the secure key storage | OOptional | OOptional |
4 | Configure local audit storage capacity | OOptional | OOptional |
5 | Configure minimum password length | OOptional | OOptional |
6 | Configure minimum number of special characters in password | OOptional | OOptional |
7 | Configure minimum number of numeric characters in password | OOptional | OOptional |
8 | Configure minimum number of uppercase characters in password | OOptional | OOptional |
9 | Configure minimum number of lowercase characters in password | OOptional | OOptional |
10 | Configure lockout policy for unsuccessful authentication attempts through [selection: timeouts between attempts, limiting number of attempts during a time period] | OOptional | OOptional |
11 | Configure host-based firewall | OOptional | OOptional |
12 | Configure name/address of directory server with which to bind | OOptional | OOptional |
13 | Configure name/address of remote management server from which to receive management settings | OOptional | OOptional |
14 | Configure name/address of audit/logging server to which to send audit/logging records | OOptional | OOptional |
15 | Configure audit rules | OOptional | OOptional |
16 | Configure name/address of network time server | OOptional | OOptional |
17 | Enable/disable automatic software update | OOptional | OOptional |
18 | Configure Wi-Fi interface | OOptional | OOptional |
19 | Enable/disable Bluetooth interface | OOptional | OOptional |
20 | Enable/disable [assignment: list of other external interfaces] | OOptional | OOptional |
21 | [assignment: list of other management functions to be provided by the TSF] | OOptional | OOptional |
FTP_ITC_EXT.1, Trusted Channel Communication, defines the specific secure communications protocols the TSF uses to communicate with a specific set of non-TOE entities in the Operational Environment.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_DTLS_EXT.1 DTLS Implementation FCS_IPSEC_EXT.1 IPsec FCS_SSH_EXT.1 SSH Protocol FCS_TLSC_EXT.1 TLS Client Protocol |
FDP_ACF_EXT.1, Access Controls for Protecting User Data, requires the TSF to prevent unprivileged users from accessing operating system objects owned by other users.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP or ST:
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FDP_IFC_EXT.1, Information Flow Control, requires the TSF to provide the ability to protect IP traffic using IPsec.
There are no management activities foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | FTP_ITC_EXT.1 Trusted Channel Communication |
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. 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.3 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP 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. |
This appendix describes the required supplementary information for the entropy source used by the OS.
The documentation of the entropy source should be detailed enough that, after reading, the evaluator shall thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.
Documentation will include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to include, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.
If implemented, the design description will include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on will be included.
There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular OS). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the OS randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.
The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.
For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.
For third-party provided entropy sources, in which the OS vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to "assume" an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.
Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.
The entropy justification will not include any data added from any third-party application or from any state saving between restarts.
IF |
From FCS_CKM.2.1: |
THEN |
From FCS_CKM.1.1: |
IF |
From FCS_CKM.2.1: |
THEN |
From FCS_CKM.1.1: |
IF |
From FCS_CKM.2.1: |
THEN |
From FCS_CKM.1.1: |
DECISION A | |||
CHOICE A1 Exclude the
PP-Module for Wireless LAN Clients,
version
1.0 module from the ST
| |||
CHOICE A2
Include the PP-Module for Wireless LAN Clients,
version
1.0 module in the ST
|
IF |
From FTP_ITC_EXT.1.1: * select TLS as conforming to the Functional Package for Transport Layer Security (TLS),
version
1.1 as a
[selection: client, server] * select server(TLS) |
THEN |
From FCS_TLS_EXT.1.1: * select TLS as a server |
IF |
From FTP_ITC_EXT.1.1: * select DTLS as conforming to the Functional Package for Transport Layer Security (TLS),
version
1.1 as a
[selection: client, server] * select client(DTLS) |
THEN |
From FCS_TLS_EXT.1.1: * select DTLS as a client |
IF |
From FTP_ITC_EXT.1.1: * select DTLS as conforming to the Functional Package for Transport Layer Security (TLS),
version
1.1 as a
[selection: client, server] * select server(DTLS) |
THEN |
From FCS_TLS_EXT.1.1: * select DTLS as a server |
IF |
From FTP_ITC_EXT.1.1: * select SSH * select client(SSH) |
THEN |
From FCS_SSH_EXT.1.1: * select client |
IF |
From FTP_ITC_EXT.1.1: * select SSH * select server(SSH) |
THEN |
From FCS_SSH_EXT.1.1: * select server |
DECISION C | |||
CHOICE C1 Exclude the
PP-Module for Bluetooth,
version
1.0 module from the ST
| |||
CHOICE C2
Include the PP-Module for Bluetooth,
version
1.0 module in the ST
|
Acronym | Meaning |
---|---|
AES | Advanced Encryption Standard |
API | Application Programming Interface |
app | Application |
ASLR | Address Space Layout Randomization |
Base-PP | Base Protection Profile |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
CESG | Communications-Electronics Security Group |
CMC | Certificate Management over CMS |
CMS | Cryptographic Message Syntax |
CN | Common Names |
cPP | Collaborative Protection Profile |
CRL | Certificate Revocation List |
CSA | Computer Security Act |
CSP | Critical Security Parameters |
DAR | Data At Rest |
DEP | Data Execution Prevention |
DES | Data Encryption Standard |
DHE | Diffie-Hellman Ephemeral |
DNS | Domain Name System |
DRBG | Deterministic Random Bit Generator |
DSS | Digital Signature Standard |
DT | Date/Time Vector |
DTLS | Datagram Transport Layer Security |
EAP | Extensible Authentication Protocol |
ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
ECDSA | Elliptic Curve Digital Signature Algorithm |
EP | Extended Package |
EST | Enrollment over Secure Transport |
FIPS | Federal Information Processing Standards |
FP | Functional Package |
HMAC | Hash-based Message Authentication Code |
HTTP | Hypertext Transfer Protocol |
HTTPS | Hypertext Transfer Protocol Secure |
IETF | Internet Engineering Task Force |
IP | Internet Protocol |
ISO | International Organization for Standardization |
IT | Information Technology |
ITSEF | Information Technology Security Evaluation Facility |
NIAP | National Information Assurance Partnership |
NIST | National Institute of Standards and Technology |
OCSP | Online Certificate Status Protocol |
OE | Operational Environment |
OID | Object Identifier |
OMB | Office of Management and Budget |
OS | Operating System |
PII | Personally Identifiable Information |
PIN | Personal Identification Number |
PKI | Public Key Infrastructure |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
RBG | Random Bit Generator |
RFC | Request for Comment |
RNG | Random Number Generator |
S/MIME | Secure/Multi-purpose Internet Mail Extensions |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
SHA | Secure Hash Algorithm |
SIP | Session Initiation Protocol |
ST | Security Target |
SWID | Software Identification |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
URI | Uniform Resource Identifier |
URL | Uniform Resource Locator |
USB | Universal Serial Bus |
VPN | Virtual Private Network |
XCCDF | eXtensible Configuration Checklist Description Format |
XOR | Exclusive Or |