collaborative PP-Module for DBMS in the Cloud

This document presents the Common Criteria (CC) collaborative Protection Profile Module (PP-Module) to express the security functional requirements (SFRs) and security assurance requirements (SARs) for Database Management Systems deployed in cloud environments. The Evaluation activities that specify the actions the evaluator performs to determine if a product satisfies the SFRs captured within this PP-Module, are described in [SD].

The scope of the PP-Module within the development and evaluation process is described in the Common Criteria for Information Technology Security Evaluation, CC:2022. In particular, a PP-Module defines the IT security requirements of a generic type of TOE and specifies the functional security measures to be offered by that TOE to meet stated requirements [[CC1], Section B.14].

The target audiences of this PP-Module are developers, CC consumers, system integrators, evaluators and schemes.

Although the PP-Module and SD may contain minor editorial errors, the PP-Module is recognized as living document and the iTC is dedicated to ongoing updates and revisions. Please report any issues to the DBMS-iTC.

For more information, see the Common Criteria Portal.

This section provides the formal identification of this PP-Module per ACE_INT requirements.

The Base PP of this PP-Module is:

Together with the required DBMS Cryptographic Functions Module identified below, the cPP_DBMS constitutes the base against which the consistency of this PP-Module is demonstrated in Consistency Rationale.

This PP-Module requires the following PP-Module to be claimed in conjunction with the Base PP:

Rationale: Deploying a tenant-operated DBMS in a cloud environment, whether cloud-native or lift-and-shift, exposes management interfaces, audit channels, and IAM integration traffic to shared cloud networks. Data-in-Transit protection using TLS, including HTTPS over TLS where applicable, is therefore a mandatory baseline security property. The DBMS Crypto Module provides the necessary Security Functional Requirements (SFRs) for this protection.

Note: The Crypto Module is mandatory. Data-at-rest protection for Cloud PP-Configurations is satisfied through the Crypto Module’s FDP_DAR_EXT.1 requirement, where the ST author selects the applicable strategy ("Storage-Scope Encryption" or "Granular Data Encryption") and includes the corresponding Catalogue-derived components consumed in that module. Cloud provider storage controls may be described as supplemental environmental support, but they do not replace the mandatory Crypto Module.

The only allowed PP-Configuration for this module is:

Any PP-Configuration claiming this PP-Module that does not include the DBMS Cryptographic Module is not valid.

The following PP-Modules are planned for future development:

The TOE type addressed by this PP-Module is: Database Management Systems deployed in cloud environments.

The TOE is a DBMS deployed and administered by the end user (tenant), not by the cloud service provider. It may be a cloud-native DBMS designed for cloud deployment or a traditional DBMS that is functionally equivalent to its on-premises version, and it may be delivered as a binary package, virtual machine image, or containerized application. This PP-Module does not apply to database-as-a-service (DBaaS) offerings operated by the cloud provider; those deployments are out of scope and will be addressed in a separate PP-Module. The distinguishing criterion is administrative authority over the DBMS software lifecycle (installation, patching, version selection, and instance configuration): where the tenant holds that authority, this module applies; where the cloud provider holds it, the deployment is a DBaaS offering.

The TOE is hosted in a cloud operational environment that includes a Trusted Platform. Depending on the evaluated architecture, Trusted Platform services may include:

This list is illustrative and does not establish a fixed boundary. A cloud service may be part of the TOE, TOE Platform, Trusted Platform, or another operational environment component according to the evaluated configuration and the security behavior it provides. Trusted Platform properties relied upon by the TOE are captured in the assumptions and Operational Environment objectives defined by this module.

The TOE may include:

The following are typically outside the TOE unless the ST explicitly includes them in the TOE boundary and applies the applicable evaluation activities:

This module requires the TOE to include the DBMS Crypto Module as defined in its associated PP-Configuration. Data-in-transit protections are mandatory for the cloud deployment channels covered by this module, and data-at-rest encryption is specified by the DBMS Crypto Module.

This PP-Module does not prescribe a single implementation boundary for every conformant database architecture. Provider ownership, use of a managed service, or deployment on shared infrastructure does not by itself determine whether a component is part of the TOE, TOE Platform, Trusted Platform, or another operational environment component.

The ST shall identify each component or service that implements or supports security behavior relevant to a claimed SFR and shall identify:

A claimed SFR shall not be satisfied solely by Trusted Platform evidence. Where an SFR, selection, or Application Note permits the TOE to use a platform-provided mechanism, the TSS shall distinguish the TSF behavior being evaluated from the external property on which that behavior relies.

This PP-Module defines the Trusted Platform properties needed by the evaluated configuration but does not prescribe which cloud authorization, certification, or other evidence is acceptable. The evaluation authority determines the acceptance criteria for Trusted Platform evidence under the applicable scheme policy.

The TOE provides the following major security features:

The TOE is deployed by an enterprise customer using a "lift-and-shift" strategy onto a public cloud provider’s infrastructure-as-a-service (IaaS) offering. The deployment consists of:

In this scenario, the following cryptographic protections are essential:

This use case illustrates the practical necessity of the cryptographic requirements defined in the DBMS Crypto Module. A TOE claiming conformance to this PP-Module receives these protections as mandatory requirements of its PP-Configuration.

The TOE is a cloud-native DBMS deployed by an enterprise customer onto tenant-managed container orchestration or platform-as-a-service (PaaS) infrastructure. The TOE has no on-premises predecessor; it is designed for elastic, orchestrated cloud deployment. The deployment consists of:

The tenant retains administrative authority over the DBMS software lifecycle: installation, version selection, patching, and instance configuration. The cryptographic protections identified in the lift-and-shift scenario apply identically: management, IAM, audit export, and client channels require Data-in-Transit protection as specified in FDP_DIT_EXT.1, and persistent storage requires Data-at-Rest Encryption as specified in FDP_DAR_EXT.1, both defined in the DBMS Crypto Module.

Application Note: These Cloud deployment use cases do not automatically select the Crypto Module’s optional [USE CASE 2] Enterprise Enhanced. An ST may claim Enterprise Enhanced for a Cloud PP-Configuration when the deployment requires its FIPS 140-3, NIAP, and CNSA 2.0-aligned cryptographic selections; the ST then follows the selection template defined entirely by the Crypto Module.

This PP-Module claims conformance to the Common Criteria for Information Technology Security Evaluation, CC:2022, as follows:

A PP-Configuration including this PP-Module inherits the cPP_DBMS claim of conformance to the EAL2 assurance package defined in CC:2022 Part 5 [[CC5]], augmented by ALC_FLR.3 Systematic flaw remediation. This PP-Module does not introduce additional assurance package claims.

This PP-Module defines no functional package claims of its own. The mandatory DBMS Cryptographic Functions Module [[DBMS_MOD_CRYPTO]] requires a conforming Security Target to claim the Functional Package for Transport Layer Security (TLS), Version 2.1 [[TLS_FP]], and, where certificate-based endpoint authentication applies, the Functional Package for X.509 Certificates, Version 1.0 [[X509_FP]], per that module’s Package Conformance section; those claims cover the cloud deployment channels this module identifies for FDP_DIT_EXT.1.

This PP-Module requires Exact Conformance from Security Targets claiming conformance.

A Security Target or PP claiming conformance to this PP-Module shall include:

This section describes the threats that the TOE is designed to address. Each threat identifies the threat agent, the adverse action, and the asset being protected, in accordance with CC:2022 requirements.

This section describes the assumptions about the operational environment that must be satisfied for the TOE to provide its security functionality. If these assumptions are not met, the TOE cannot be expected to operate securely.

This section defines the organizational security policies that the TOE must support or enforce. These policies represent security rules that organizations deploying the TOE are expected to implement.

The following table maps each threat to the security objectives that address it. Each threat must be fully addressed by the combination of TOE objectives and operational environment objectives.

The following table maps each assumption to the operational environment objectives that uphold it.

The following table maps each organizational security policy to the objectives that support or enforce it.

The following table maps each TOE security objective to the SFRs that satisfy it. Each objective must be fully satisfied by the combination of mandatory SFRs, Base PP SFRs, mandatory Crypto Module SFRs, and selection-based SFRs where applicable.

The following table summarizes when each OE objective applies based on mandatory requirements and ST selections.

The individual security functional requirements are specified in the sections below. The following conventions are used for SFR operations and module-specific refinements:

Extended SFRs are identified by having the label "EXT" in the SFR name.

Data-in-Transit Protection (FDP_DIT_EXT.1) is a mandatory requirement defined in the DBMS Cryptographic Functions Module [[DBMS_MOD_CRYPTO]], which is mandatory for every PP-Configuration claiming this Cloud Module. This Cloud Module does not define or redefine FDP_DIT_EXT.1; it relies on the requirement inherited from the Crypto Module and identifies the cloud deployment channels to which it applies. This section is descriptive: the inherited requirement is claimed through the Crypto Module, and it is not part of the SFRs specified by this module in Security Functional Requirements (Mandatory).

Application Note: In a cloud deployment, the inherited FDP_DIT_EXT.1 applies to management APIs, admin consoles, cloud IAM integrations, audit export channels, remote DBMS connections exposed to untrusted networks, and other external service channels identified by the ST. TLS, including HTTPS over TLS where applicable, is the required baseline for those cloud deployment channels. The channel bindings for this module’s own SFRs are normative: see FAU_STG_EXT.1.2 (audit export), FIA_UID_EXT.1.4 (external identity providers), and FMT_MTD_EXT.1.2 (cloud configuration and secret management systems). The ST author includes the corresponding TLS and X.509 components from the Functional Package for TLS and Functional Package for X.509 Certificates. CCDB-018 supplies cryptographic primitives and does not supply TLS or certificate-validation components. HTTPS is treated as HTTP over the claimed TLS channel and does not require a separate HTTPS cryptographic component.

The following SAR families, as defined in the cPP_DBMS, are inherited unchanged:

No additional or modified SARs are introduced by this PP-Module.

The applicable SAR set is inherited from cPP_DBMS Version 2.0: EAL2 as defined in CC:2022 Part 5 [[CC5]], augmented by ALC_FLR.3 Systematic flaw remediation.

This PP-Module does not define SFRs from the FCS (Cryptographic Support) class. All cryptographic requirements are deferred to the DBMS Crypto Module for the following reasons:

The DBMS Crypto Module is mandatory for every PP-Configuration claiming this Cloud Module. Data-at-rest encryption is specified by the Crypto Module using Catalogue-derived components consumed there. The protocol mechanisms selected for FDP_DIT_EXT.1 are specified by the applicable Functional Packages.

The Base PP defines a Database Management System TOE. This PP-Module constrains that TOE type by deployment and operation model — a DBMS deployed in a cloud environment and operated by the tenant — and not by product lineage: both cloud-native DBMS products and lift-and-shift deployments of traditional DBMS products remain the Base PP TOE type. The module adds cloud-integration security functionality to that TOE; it does not redefine what the TOE is, and all Base PP SFRs continue to apply to it.

The module’s threats supplement the Base PP SPD with the attack surface introduced by cloud deployment: elastic and orchestrated infrastructure (T.ELASTIC_ENVIRONMENT, T.INTEGRITY_FAILURE), cloud-scoped administration and co-tenancy (T.MALICIOUS_TENANT_ADMIN, T.UNAUTHORIZED_ACCESS), cloud-integrated identity, secrets, and audit pipelines (T.SECRETS_EXPOSURE, T.AUDIT_FAILURE), and shared networks (T.NETWORK_INTERCEPTION). None of these contradicts a Base PP threat; each extends an existing Base PP protection concern into the cloud context. T.UNAUTHORIZED_ACCESS is countered by the TOE only at tenant-visible interfaces; an attacker with control of the underlying infrastructure or control plane is addressed by A.TRUSTED_PLATFORM and OE.TRUSTED_PLATFORM rather than by TOE SFRs, consistent with the Base PP’s treatment of the underlying platform.

The module’s assumptions (A.TRUSTED_PLATFORM, A.SECURE_DEPLOYMENT, A.CLOUD_SERVICE_INTEGRITY, A.AUTHORIZED_ADMINISTRATORS, A.TIME_SYNCHRONIZATION) scope the cloud operational environment and neither remove nor weaken any Base PP assumption. The organizational security policies (P.AUDIT_RETENTION, P.ACCESS_CONTROL_POLICY) are additive and have no Base PP counterpart with which to conflict.

The module’s TOE objectives (O.CLOUD_IDENTITY_INTEGRATION, O.CLOUD_AUDIT_INTEGRATION, O.INTERNAL_RESOURCE_RESILIENCE, O.CLOUD_DEPLOYMENT_INTEGRITY, O.CONFIGURATION_PROTECTION) are additive: each addresses a cloud-specific threat or policy, and none redefines, weakens, or replaces a Base PP objective. The operational environment objectives assign to the environment only properties the Base PP never assigned to the TOE — platform isolation (OE.TRUSTED_PLATFORM), orchestration integrity (OE.SECURE_ORCHESTRATION), external logging, identity, and secrets services (OE.LOGGING_SERVICES, OE.IDENTITY_PROVIDERS, OE.SECRETS_MANAGEMENT), and organizational personnel controls (OE.AUTHORIZED_ADMINISTRATORS). No Base PP TOE responsibility is reassigned to the operational environment.

Components also defined by the Base PP are claimed by this module as iterations — FAU_GEN.1/Cloud, FAU_SEL.1/Cloud, FMT_MTD.1/Cloud, FMT_SMF.1/Cloud, FMT_SMR.1/Cloud — leaving the Base PP components claimed unchanged in the PP-Configuration. FAU_STG.2/Cloud, FMT_MOF.1, and FPT_FLS.1 use CC Part 2 components the Base PP does not claim, so no conflicting completion can arise. Module SFRs depend on Base PP components where appropriate (FIA_UID.2 and FIA_UAU.2 for identification and authentication; the FMT management components) and do not alter their Base PP completions.

FPT_ITT.1 is claimed by this module to protect internal TSF transfers in cloud deployments. The Base PP does not claim FPT_ITT.1; it relies on A.CONNECT to discharge the FPT_ITT.1 dependency of FPT_TRC.1. This module’s claim supplements A.CONNECT with TOE-enforced protection for cloud deployments; A.CONNECT is retained in full in the PP-Configuration and is not rescinded or weakened.

The extended components defined by this module (FIA_UID_EXT.1, FMT_MTD_EXT.1, FPT_ARS_EXT.1, FPT_TUD_EXT.1, FPT_SBT_EXT.1, FAU_STG_EXT.1) address cloud-integration behavior for which no Base PP or CC Part 2 component exists and do not overlap any Base PP component.

Every PP-Configuration claiming this module also includes the DBMS Cryptographic Functions Module. This module references, and does not redefine, the Crypto Module’s requirements: FDP_DIT_EXT.1 (this module only identifies the cloud deployment channels — management, IAM, audit export, and external service connections — to which the inherited requirement applies), FDP_DAR_EXT.1 (data-at-rest protection), and the key-lifecycle components. The threats T.NETWORK_INTERCEPTION and T.SECRETS_EXPOSURE are countered jointly with the Crypto Module — its O.PROTECTED_TRANSIT objective covers external channel protection, and its key-management objectives cover Master Key lifecycle protection. The channel list identified by this module is a subset of the channels FDP_DIT_EXT.1 covers, and this module introduces no completion of any Crypto Module operation, so no contradiction can arise between the two modules.

The following table summarizes the dependencies between SFRs in this PP-Module: