Version | Date | Comment |
---|---|---|
1.0 | 2016-11-17 | Initial Publication |
1.1 | 2021-06-14 | Incorporate TDs, Reference TLS Package, Add Equivalency Guidelines, etc. |
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. |
Administrator | Administrators perform management activities on the VS. These management functions do not include administration of software running within Guest VMs, such as the Guest OS. Administrators need not be human as in the case of embedded or headless VMs. Administrators are often nothing more than software entities that operate within the VM. |
Auditor | Auditors are responsible for managing the audit capabilities of the TOE. An Auditor may also be an Administrator. It is not a requirement that the TOE be capable of supporting an Auditor role that is separate from that of an Administrator. |
Domain | A Domain or Information Domain is a policy construct that groups together execution environments and networks by sensitivity of information and access control policy. For example, classification levels represent information domains. Within classification levels, there might be other domains representing communities of interest or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem. |
Guest Network | See Operational Network. |
Guest Operating System | An operating system that runs within a Guest VM. |
Guest VM | A Guest VM is a VM that contains a virtual environment for the execution of an independent computing system. Virtual environments execute mission workloads and implement customer-specific client or server functionality in Guest VMs, such as a web server or desktop productivity applications. |
Helper VM | A Helper VM is a VM that performs services on behalf of one or more Guest VMs, but does not qualify as a Service VM—and therefore is not part of the VMM. Helper VMs implement functions or services that are particular to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are therefore subject to all the same requirements, unless specifically stated otherwise. |
Host Operating System | An operating system onto which a VS is installed. Relative to the VS, the Host OS is part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. |
Hypercall | An API function that allows VM-aware software running within a VM to invoke VMM functionality. |
Hypervisor | The Hypervisor is part of the VMM. It is the software executive of the physical platform of a VS. A Hypervisor’s primary function is to mediate access to all CPU and memory resources, but it is also responsible for either the direct management or the delegation of the management of all other hardware devices on the hardware platform. |
Information Domain | See Domain. |
Introspection | A capability that allows a specially designated and privileged domain to have visibility into another domain for purposes of anomaly detection or monitoring. |
Management Network | A network, which may have both physical and virtualized components, used to manage and administer a VS. Management networks include networks used by VS Administrators to communicate with management components of the VS, and networks used by the VS for communications between VS components. For purposes of this document, networks that connect physical hosts and backend storage networks for purposes of VM transfer or backup are considered management networks. |
Management Subsystem | Components of the VS that allow VS Administrators to configure and manage the VMM, as well as configure Guest VMs. VMM management functions include VM configuration, virtualized network configuration, and allocation of physical resources. |
Operational Network | An Operational Network is a network, which may have both physical and virtualized components, used to connect Guest VMs to each other and potentially to other entities outside of the VS. Operational Networks support mission workloads and customer-specific client or server functionality. Also called a “Guest Network.” |
Physical Platform | The hardware environment on which a VS executes. Physical platform resources include processors, memory, devices, and associated firmware. |
Platform | The hardware, firmware, and software environment into which a VS is installed and executes. |
Service VM | A Service VM is a VM whose purpose is to support the Hypervisor in providing the resources or services necessary to support Guest VMs. Service VMs may implement some portion of Hypervisor functionality, but also may contain important system functionality that is not necessary for Hypervisor operation. As with any VM, Service VMs necessarily execute without full Hypervisor privileges—only the privileges required to perform its designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices, VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that help establish communication paths between VMs. |
System Security Policy | The overall policy enforced by the VS defining constraints on the behavior of VMs and users. |
User | Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software entities that operate within the VM. |
Virtual Machine | A Virtual Machine is a virtualized hardware environment in which an operating system may execute. |
Virtual Machine Manager | A VMM is a collection of software components responsible for enabling VMs to function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. |
Virtualization System | A software product that enables multiple independent computing systems to execute on the same physical hardware platform without interference from one another. For the purposes of this document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem, and other components. |
A Security Target must claim exact conformance to this Protection Profile, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
Threat, Assumption, or OSP | Security Objectives | Rationale |
T.3P_SOFTWARE | O.VMM_INTEGRITY | The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. |
T.DATA_LEAKAGE | O.DOMAIN_INTEGRITY | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. |
O.VM_ISOLATION | Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. | |
T.DENIAL_OF_SERVICE | O.RESOURCE_ALLOCATION | The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. |
T.MISCONFIGURATION | O.CORRECTLY_APPLIED_CONFIGURATION | Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. |
T.PLATFORM_COMPROMISE | O.PLATFORM_INTEGRITY | Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. |
T.UNAUTHORIZED_ACCESS | O.MANAGEMENT_ACCESS | Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. |
T.UNAUTHORIZED_MODIFICATION | O.AUDIT | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. |
O.VMM_INTEGRITY | Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. | |
T.UNAUTHORIZED_UPDATE | O.VMM_INTEGRITY | System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. |
T.UNPATCHED_SOFTWARE | O.PATCHED_SOFTWARE | The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. |
T.USER_ERROR | O.VM_ISOLATION | Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. |
T.VMM_COMPROMISE | O.VMM_INTEGRITY | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. |
O.VM_ISOLATION | Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. | |
T.WEAK_CRYPTO | O.VM_ENTROPY | Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. |
A.NON_MALICIOUS_USER | OE.CONFIG | If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE will be configured in a correct and secure manner. |
OE.NON_MALICIOUS_USER | If the organization properly vets and trains users, it is expected that they will be non-malicious. | |
A.PHYSICAL | OE.PHYSICAL | If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed to be physically secure. |
A.PLATFORM_INTEGRITY | OE.PHYSICAL | If the underlying platform has not been compromised prior to installation of the TOE, its integrity can be assumed to be intact. |
A.TRUSTED_ADMIN | OE.TRUSTED_ADMIN | Providing guidance to administrators and ensuring that individuals are properly trained and vetted before being given administrative responsibilities will ensure that they are trusted. |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FAU_GEN.1 | ||
No events specified | N/A | |
FAU_SAR.1 | ||
No events specified | N/A | |
FAU_STG.1 | ||
No events specified | N/A | |
FAU_STG_EXT.1 | ||
Failure of audit data capture due to lack of disk space or pre-defined limit. | No additional information | |
On failure of logging function, capture record of failure and record upon restart of logging function. | No additional information | |
FCS_CKM.1 | ||
No events specified | N/A | |
FCS_CKM.2 | ||
No events specified | N/A | |
FCS_CKM_EXT.4 | ||
No events specified | N/A | |
FCS_COP.1/Hash | ||
No events specified | N/A | |
FCS_COP.1/KeyedHash | ||
No events specified | N/A | |
FCS_COP.1/Sig | ||
No events specified | N/A | |
FCS_COP.1/UDE | ||
No events specified | N/A | |
FCS_ENT_EXT.1 | ||
No events specified | N/A | |
FCS_RBG_EXT.1 | ||
Failure of the randomization process. | No additional information | |
FDP_HBI_EXT.1 | ||
No events specified | N/A | |
FDP_PPR_EXT.1 | ||
Successful and failed VM connections to physical devices where connection is governed by configurablepolicy. | VM and physical device identifiers. | |
Security policy violations. | Identifier for the security policy that was violated. | |
FDP_RIP_EXT.1 | ||
No events specified | N/A | |
FDP_RIP_EXT.2 | ||
No events specified | N/A | |
FDP_VMS_EXT.1 | ||
No events specified | N/A | |
FDP_VNC_EXT.1 | ||
Successful and failed attempts to connect VMs to virtual and physical networkingcomponents. | VM and virtual or physical networking component identifiers. | |
Security policy violations. |
| |
Administrator configuration of inter-VM communications channels between VMs. | VM and virtual or physical networking component identifiers. | |
FIA_AFL_EXT.1 | ||
Unsuccessful login attempts limit is met or exceeded. | Origin of attempt (e.g., IP address). | |
FIA_PMG_EXT.1 | ||
No events specified | N/A | |
FIA_UAU.5 | ||
No events specified | N/A | |
FIA_UIA_EXT.1 | ||
Administrator authentication attempts. | Provided user identity, origin of the attempt (e.g., console, remote IP address). | |
All use of the identification and authentication mechanism. | Provided user identity, origin of the attempt (e.g., console, remote IP address). | |
[selection, choose one of: Start and end of administrator session., none] | Start time and end time of administrator session. | |
FMT_SMO_EXT.1 | ||
No events specified | N/A | |
FPT_DVD_EXT.1 | ||
No events specified | N/A | |
FPT_EEM_EXT.1 | ||
No events specified | N/A | |
FPT_HAS_EXT.1 | ||
No events specified | N/A | |
FPT_HCL_EXT.1 | ||
Invalid parameter to hypercall detected. | Hypercall interface for which access was attempted. | |
Hypercall interface invoked when documented preconditions are not met. | No additional information | |
FPT_RDM_EXT.1 | ||
Connection/disconnection of removable media or device to/from a VM. | VM Identifier, Removable media/device identifier, event description or identifier (connect/disconnect, ejection/insertion, etc.). | |
Ejection/insertion of removable media or device from/to an already connected VM. | VM Identifier, Removable media/device identifier, event description or identifier (connect/disconnect, ejection/insertion, etc.). | |
FPT_TUD_EXT.1 | ||
Failure of signature verification. | No additional information | |
Initiation of update. | No additional information | |
FPT_VDP_EXT.1 | ||
No events specified | N/A | |
FPT_VIV_EXT.1 | ||
No events specified | N/A | |
FTA_TAB.1 | ||
No events specified | N/A | |
FTP_ITC_EXT.1 | ||
Initiation of the trusted channel. | User ID and remote source (IP Address) if feasible. | |
Termination of the trusted channel. | User ID and remote source (IP Address) if feasible. | |
Failures of the trusted path functions. | User ID and remote source (IP Address) if feasible. | |
FTP_TRP.1 | ||
Initiation of the trusted channel. | User ID and remote source (IP Address) if feasible. | |
Termination of the trusted channel. | User ID and remote source (IP Address) if feasible. | |
Failures of the trusted path functions. | User ID and remote source (IP Address) if feasible. | |
FTP_UIF_EXT.1 | ||
No events specified | N/A | |
FTP_UIF_EXT.2 | ||
No events specified | N/A |
FCS_TLSC_EXT.1 | Failure to establish a session. | Reason for failure. |
FCS_TLSC_EXT.1 | Failure to verify presented identifier. | Presented identifier and reference identifier. |
FCS_TLSC_EXT.1 | Establishment/termination of a TLS session. | Non-TOE endpoint of connection. |
FCS_TLSS_EXT.1 | Failure to establish a session. | Reason for failure. |
FCS_DTLSC_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
FCS_DTLSS_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
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:
Objective | Addressed by | Rationale |
---|---|---|
O.AUDIT | FAU_ARP.1 | Requires support for automatic responses to audit events (optional). |
FAU_GEN.1 | Requires reporting of audit events. | |
FAU_SAA.1 | Requires support for rules for indicating security violations based on audit events (optional). | |
FAU_SAR.1 | Requires support for Administrator review of audit records. | |
FAU_STG.1 | Requires protection of stored audit records. | |
FAU_STG_EXT.1 | Requires support for protected transmission of audit records off the TOE. | |
O.CORRECTLY_APPLIED_CONFIGURATION | FDP_VMS_EXT.1 | Ensures that data sharing between VMs is turned off by default. |
O.DOMAIN_INTEGRITY | FCS_CKM_EXT.4 | Requires cryptographic key destruction to protect domain data in shared storage. |
FCS_ENT_EXT.1 | Requires that domains have access to high-quality entropy for cryptographic purposes. | |
FCS_RBG_EXT.1 | Requires that the TOE has access to high-quality entropy for cryptographic purposes. | |
FDP_RIP_EXT.1 | Ensures that domain data is cleared from memory before memory is re-allocated to another domain. | |
FDP_RIP_EXT.2 | Ensures that domain data is cleared from physical storage upon re-allocation of the storage to another domain. | |
FDP_VMS_EXT.1 | Ensures that authorized data transfers between domains are done securely. | |
FDP_VNC_EXT.1 | Ensures that network traffic is visible only to VMs configured to be that network. | |
FPT_EEM_EXT.1 | Requires that the TOE use security mechanisms supported by the physical platform. | |
FPT_GVI_EXT.1 | Requires that the TOE support Guest VM measurements and integrity checks (optional). | |
FPT_HAS_EXT.1 | Requires that the TOE use platform-supported virtualization assists to reduce attack surface. | |
FPT_INT_EXT.1 | Requires that the TOE support introspection into Guest VMs (optional). | |
FPT_RDM_EXT.1 | Requires support for rules for switching removeable media between domains to reduce the chance of data spillage. | |
FPT_VDP_EXT.1 | Requires validation of parameter data passed to the hardware abstraction by untrusted VMs. | |
O.MANAGEMENT_ACCESS | FAU_GEN.1 | Audit events report attempts to access the management subsystem. |
FCS_CKM.1 | Requires generation of asymmetric keys for trusted communications channels. | |
FCS_CKM.2 | Requires establishment of cryptographic keys for trusted communications channels. | |
FCS_HTTPS_EXT.1 | Ensures that HTTPS trusted communications channels are implemented properly. | |
FCS_IPSEC_EXT.1 | Ensures that IPsec trusted communications channels are implemented properly. | |
FCS_RBG_EXT.1 | Requires that the TOE has access to high-quality entropy for cryptographic purposes. | |
FIA_AFL_EXT.1 | Requires that the TOE detect failed authentication attempts for Administrator access. | |
FIA_PMG_EXT.1 | Ensures that password-based administrator login is properly implemented. | |
FIA_UAU.5 | Ensures that strong mechanisms are used for Administrator authentication. | |
FIA_UIA_EXT.1 | Requires that Administrators be successfully authenticated before performing management functions. | |
FIA_X509_EXT.1 | Ensures that certificate validation is implemented properly. | |
FIA_X509_EXT.2 | Ensures that certificate-based authentication is implemented properly.t functions. | |
FMT_SMO_EXT.1 | Requires that the TOE support having separate management and operational networks. | |
O.PATCHED_SOFTWARE | FPT_IDV_EXT.1 | Requires support for software identification labels (optional). |
FPT_TUD_EXT.1 | Requires support for product updates. | |
FPT_TUD_EXT.2 | Specifies requirements for certificate-based code signing for update. | |
O.PLATFORM_INTEGRITY | FDP_HBI_EXT.1 | Requires that the TOE use platform-supported mechanisms for access to physical devices. |
FDP_PPR_EXT.1 | Requires support for reducing attack surface through disabling access to unneeded physical platform resources. | |
FDP_VMS_EXT.1 | Ensures that authorized data transfers between VMs are done securely. | |
FDP_VNC_EXT.1 | Ensures that network traffic is visible only to VMs configured to be that network. | |
FPT_DVD_EXT.1 | Ensures that VMs cannot access virtual devices that they are not configured to access. | |
FPT_EEM_EXT.1 | Requires that the TOE use security mechanisms supported by the physical platform. | |
FPT_HAS_EXT.1 | Requires that the TOE use platform-supported virtualization assists to reduce attack surface. | |
FPT_HCL_EXT.1 | Requires that Hypercall parameters be validated. | |
FPT_ML_EXT.1 | Requires measured launch of the platform and VMM (objective). | |
FPT_VDP_EXT.1 | Requires validation of parameter data passed to the hardware abstraction by untrusted VMs. | |
FPT_VIV_EXT.1 | Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation. | |
O.RESOURCE_ALLOCATION | FCS_CKM_EXT.4 | Requires cryptographic key destruction to ensure residual data in shared storage is unrecoverable. |
FDP_RIP_EXT.1 | Ensures that domain data is cleared from memory before memory is re-allocated. | |
FDP_RIP_EXT.2 | Ensures that domain data is cleared from storage upon re-allocation of the storage. | |
O.VMM_INTEGRITY | FAU_GEN.1 | Audit events can report potential integrity breaches and attempts. |
FCS_CKM.1 | Requires generation of asymmetric keys for protection of integrity measures. | |
FCS_RBG_EXT.1 | Requires that the TOE has access to high-quality entropy for cryptographic purposes. | |
FDP_PPR_EXT.1 | Requires support for reducing attack surface through disabling access to unneeded physical platform resources. | |
FDP_VMS_EXT.1 | Ensures that authorized data transfers between VMs are done securely. | |
FDP_VNC_EXT.1 | Ensures that network traffic is visible only to VMs configured to be that network. | |
FPT_DDI_EXT.1 | Requires that physical device drivers be isolated other parts of the TOE and from one another (optional). | |
FPT_EEM_EXT.1 | Requires that the TOE use security mechanisms supported by the physical platform. | |
FPT_HAS_EXT.1 | Requires that the TOE use platform-supported virtualization assists to reduce attack surface. | |
FPT_HCL_EXT.1 | Requires that Hypercall parameters be validated. | |
FPT_ML_EXT.1 | Requires measured launch of the platform and VMM (objective). | |
FPT_VDP_EXT.1 | Requires validation of parameter data passed to the hardware abstraction by untrusted VMs. | |
FPT_VIV_EXT.1 | Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation. | |
O.VM_ENTROPY | FCS_ENT_EXT.1 | Requires that domains have access to high-quality entropy for cryptographic purposes. |
FCS_RBG_EXT.1 | Requires that the TOE has access to high-quality entropy for cryptographic purposes. | |
O.VM_ISOLATION | FAU_GEN.1 | Audit events can report attempts to breach isolation. |
FCS_CKM_EXT.4 | Requires cryptographic key destruction to protect domain data in shared storage. | |
FDP_PPR_EXT.1 | Requires support for reducing attack surface through disabling access to unneeded physical platform resources. | |
FDP_RIP_EXT.1 | Ensures that domain data is cleared from memory before memory is re-allocated. | |
FDP_RIP_EXT.2 | Ensures that domain data is cleared from physical storage upon re-allocation of the storage. | |
FDP_VMS_EXT.1 | Ensures that authorized data transfers between VMs are done securely. | |
FDP_VNC_EXT.1 | Ensures that network traffic is visible only to VMs configured to be that network. | |
FPT_DVD_EXT.1 | Ensures that VMs can access only those virtual devices that they are configured to access. | |
FPT_EEM_EXT.1 | Requires that the TOE use security mechanisms supported by the physical platform. | |
FPT_HAS_EXT.1 | Requires that the TOE use platform-supported virtualization assists to reduce attack surface. | |
FPT_VDP_EXT.1 | Requires validation of parameter data passed to the hardware abstraction by untrusted VMs. | |
FPT_VIV_EXT.1 | Ensures that untrusted VMs cannot invoke privileged code without proper hypervisor mediation. |
The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 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 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.2 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.
Table 5: Implicitly Satisfied RequirementsRequirement | Rationale for Satisfaction |
FCS_CKM.4 – Cryptographic Key Destruction | FCS_CKM.1 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency by defining an alternate requirement for key destruction. |
FCS_CKM.4 – Cryptographic Key Destruction | FCS_CKM.2 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency by defining an alternate requirement for key destruction. |
FCS_CKM.4 – Cryptographic Key Destruction | Each iteration of FCS_COP.1 has a dependency on FCS_CKM.4. The extended SFR FCS_CKM_EXT.4 addresses this dependency by defining an alternate requirement for key destruction. |
FIA_UID.1 – Timing of Identification | FMT_SMR.2 has a dependency on FIA_UID.1. The extended SFR FIA_UID_EXT.1 expresses this dependency by also requiring user identification for use of the TOE. |
FPT_STM.1 – Reliable Time Stamps | FAU_GEN.1 has a dependency on FPT_STM.1. While not explicitly stated in the PP, it is assumed that this will be provided by the underlying hardware platform on which the TOE is installed. This is because the TOE is installed as a software or firmware product that runs on general-purpose computing hardware so a hardware clock is assumed to be available. |
FPT_STM.1 – Reliable Time Stamps | FIA_X509_EXT.1 has a dependency on FPT_STM.1. While not explicitly stated in the PP, it is assumed that this will be provided by the underlying hardware platform on which the TOE is installed. This is because the TOE is installed as a software or firmware product that runs on general-purpose computing hardware so a hardware clock is assumed to be available. |
Factor | Same/Different | Guidance |
Target Platform | Different | Product Models that virtualize different instruction sets (e.g., x86, ARM, POWER, SPARC, MIPS) are not equivalent. |
Installation Types | Different | If a Product can be installed either on bare metal or onto an operating system and the vendor wants to claim that both installation types constitute a single Model, then see the guidance for “PP-Specified Functionality,” below. |
Software Platform | Different | Product Models that run on substantially different software environments, such as different host operating systems, are not equivalent. Models that install on different versions of the same software environment may be equivalent depending on the below factors. |
PP-Specified Functionality | Same | If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. |
Different | If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary to test only the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are fully tested separately, then there is no need to document the differences. |
Factor | Same/Different | Guidance |
Product Models | Different | Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3. |
PP-Specified Functionality | Same | If the differences affect only non-PP-specified functionality, then the Versions are equivalent. |
Different | If PP-specified security functionality is affected by the differences, then the Versions are considered to be not equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are fully tested separately, then there is no need to document the differences. |
Factor | Same/Different/None | Guidance |
Platform Architectures | Different | Hardware platforms that implement different processor architectures and instruction sets are not equivalent. |
PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms. |
Factor | Same/Different/None | Guidance |
Platform Type/Vendor | Different | Operating systems that are substantially different or come from different vendors are not equivalent. |
Platform Versions | Different | Operating systems are not equivalent if they have different major version numbers. |
PP-Specified Functionality | Same | If the differences between software platform models or versions affect only non-PP-specified functionality, then the software platforms are equivalent. |
Different | If PP-specified security functionality is affected by the differences between software platform versions or models, then the software platforms are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Products are fully tested on each platform, then there is no need to document the differences. |
Acronym | Meaning |
---|---|
Base-PP | Base Protection Profile |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
cPP | Collaborative Protection Profile |
EP | Extended Package |
FP | Functional Package |
OE | Operational Environment |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
ST | Security Target |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. |