Supporting Document: Evaluation Activities for collaborative PP-Module for DBMS in the Cloud

Start the TOE from a powered-off or non-operational state.

Verify the audit log contains a record indicating start-up of the audit functions.

Shut down the TOE using normal administrative procedures.

Restart the TOE and verify the audit log contains a record indicating shutdown of the audit functions from the previous session.

Each administrative action generates an appropriate audit record.

The audit record contains: date/time, event type, subject identity (the administrator), and outcome (success).

For cloud-specific deployments, the tenant identifier and source IP address are recorded.

Attempt successful authentication using each supported authentication mechanism (local, cloud IAM, federated directory).

Attempt failed authentication using invalid credentials.

Verify audit records are generated for both successful and failed authentication attempts.

Verify external identity provider authentication events are recorded when federated authentication is used.

Trigger the auditable event.

Examine the resulting audit record.

Verify the record contains all mandatory fields per FAU_GEN.1.2/Cloud:

Verify any additional cloud-specific information (tenant ID, region, source IP) is present when applicable.

Administrative action via cloud interface (e.g., API call to modify configuration)

Configuration or deployment change

External identity provider authentication event

Access to cloud secret management integration (if applicable)

Generate an auditable event while audit functions are disabled (if disabling is permitted).

Verify the event is either not recorded (if audit is disabled) or is recorded (if audit cannot be disabled for this event type).

Configure audit selection to include events related to a specific database object (e.g., a particular table or schema).

Perform operations on the selected object and on other objects.

Verify only events related to the selected object are audited.

Configure audit selection to exclude events for the specific object.

Repeat operations and verify events for the excluded object are not audited.

Configure audit selection to include events for a specific user identity.

Perform operations as the selected user and as other users.

Verify only events from the selected user are audited.

Configure exclusion for the specific user.

Verify events from the excluded user are not audited.

Configure audit selection to include events for a specific tenant identifier.

Perform operations in the context of multiple tenants.

Verify only events for the selected tenant are audited.

Configure audit selection to include events for a specific IAM role (e.g., "cloud audit authority" or "tenant administrator").

Perform operations using accounts with different IAM roles.

Verify only events from the selected IAM role are audited.

Configure audit selection to include events for specific API endpoints or operation types (e.g., only audit administrative APIs).

Invoke various API endpoints including selected and non-selected endpoints.

Verify only events for selected API endpoints are audited.

Configure multiple selection criteria (e.g., specific user AND specific object).

Perform operations that match all criteria, some criteria, and no criteria.

Verify only events matching ALL specified inclusion criteria are audited.

Configure conflicting inclusion and exclusion rules for the same event type.

Trigger an event that matches both rules.

Verify the behavior matches the documented precedence rules.

Generate multiple auditable events.

Verify audit records are stored in the configured location.

Retrieve and examine stored audit records to verify content integrity.

As an unprivileged user (or a user without audit management privileges), attempt to delete audit records.

Verify the deletion attempt is denied.

Verify the deletion attempt itself is audited (if deletion attempts are auditable events).

As an unprivileged user, attempt to modify stored audit records through each TSF interface that exposes audit data.

Verify each modification attempt is denied.

As an authorized administrator with audit management privileges, delete audit records following documented procedures.

Verify the deletion succeeds.

Verify the deletion action is audited.

Configure the external audit receiver.

Generate auditable events.

Verify audit records arrive at the external receiver.

Verify the transmission uses the specified trusted channel mechanism.

Make the external audit receiver unavailable.

Generate auditable events.

Verify the TSF’s handling (buffering, alerting, etc.) matches documentation.

Restore the external receiver.

Verify buffered records are transmitted (if buffering is supported).

Configure audit export to the cloud logging service.

Generate auditable events on the TOE.

Query the cloud logging service to retrieve exported audit records.

Verify the exported records match the source audit records in content.

Configure audit export to a destination.

Generate a sample of different auditable event types.

Capture the exported records at the destination.

Verify the format matches the documented export format.

Verify all required audit record fields are present in the exported format.

Configure audit export using the trusted channel mechanism.

Use network analysis tools to capture export traffic.

Verify the traffic is protected (e.g., TLS encryption verified).

Verify certificate validation is performed (attempt export to a service with an invalid certificate and confirm failure).

Configure audit export to a destination.

Generate auditable events.

Temporarily make the export destination unavailable.

Continue generating events during unavailability.

Restore the export destination.

Verify events generated during unavailability are eventually exported (if buffering is supported) or that the unavailability was detected and handled per documentation.

Configure export to multiple cloud logging services simultaneously.

Generate auditable events.

Verify records appear in all configured destinations.

Configure audit export with valid credentials.

Verify export succeeds.

Configure audit export with invalid credentials.

Verify export fails with appropriate error handling.

Verify the authentication failure is audited or logged.

Attempt a representative set of TSF-mediated actions through each available interface (for example, query execution, configuration query, and management operations).

Verify each attempt is refused before identification and authentication complete.

Configure the TOE to accept identity from cloud IAM.

Authenticate using a valid cloud IAM role (e.g., via assumed role credentials, instance metadata).

Verify the user is identified by their IAM role.

Verify the identified IAM role is correctly mapped to TOE permissions.

Attempt identification using credentials from an IAM role not authorized for the TOE.

Verify the identification/authentication attempt is rejected.

Verify the rejection is audited.

Configure the TOE to integrate with an LDAP or AD directory.

Authenticate using valid directory credentials.

Verify the user is identified by their directory identity.

Verify directory group memberships are correctly mapped to TOE roles (if applicable).

Attempt identification using invalid directory credentials.

Verify the attempt is rejected.

Verify the rejection is audited.

Configure a service principal for TOE access.

Authenticate using service principal credentials (certificate or secret).

Verify the service principal is identified.

Verify appropriate access is granted based on service principal permissions.

Attempt identification using invalid service principal credentials.

Verify the attempt is rejected.

Verify the rejection is audited.

Present an identity assertion with an expired timestamp.

Verify the assertion is rejected.

Present an identity assertion with an invalid signature (if signatures are used).

Verify the assertion is rejected.

Present an identity assertion from an untrusted issuer.

Verify the assertion is rejected.

Identify users with different external attributes (e.g., different group memberships, different roles).

Verify each user is mapped to the correct internal role based on configured mapping rules.

Modify mapping configuration and verify changes take effect.

Make the external identity provider unavailable (simulate network failure or service outage).

Attempt identification through the unavailable provider.

Verify the TOE handles the unavailability according to documented behavior (e.g., fail closed, use cached credentials if permitted, provide appropriate error).

Restore the identity provider.

Verify normal identification resumes.

Configure the TOE to accept identity from multiple sources (e.g., both cloud IAM and federated directory).

Authenticate using each identity source.

Verify each source correctly identifies the user.

Verify identity source precedence if the same user exists in multiple sources.

Configure the TOE to use an external identity provider (e.g., Azure AD, AWS IAM).

Initiate an authentication attempt.

Capture network traffic between the TOE and the identity provider endpoint.

Verify that the traffic is protected (e.g., encrypted using TLS, including HTTPS over TLS).

Confirm, by reference to the Cryptographic Validation Coverage Matrix and the TLS Functional Package evaluation evidence recorded for the DBMS Crypto Module, that certificate validation for the TLS client role used by this interface is covered there.

The complete list of security functions whose behavior can be determined, disabled, enabled, or modified, and for each function:

How the TSF enforces role-based restrictions on management operations, including:

For cloud deployments specifically:

The relationship between FMT_MOF.1 functions and those specified in FMT_SMF.1/Cloud, demonstrating that all cloud management functions are subject to appropriate access restrictions.

Identifies all security functions subject to management restrictions and documents:

Provides clear instructions for administrators on:

Documents cloud-specific management considerations:

Warns administrators about security implications of:

Step: Authenticate as a user assigned to an authorized role for managing the function.

Step: Attempt to perform each permitted management operation (determine behavior, disable, enable, modify).

Expected Result: All operations succeed for authorized roles.

Step: Authenticate as a user assigned to a role NOT authorized to manage the function.

Step: Attempt each management operation.

Expected Result: All operations are denied with appropriate error messages.

Step: Configure a cloud IAM role mapping to a TOE role with management privileges.

Step: Authenticate using the cloud IAM identity.

Step: Verify that management operations permitted for the mapped role succeed.

Step: Modify the cloud IAM role mapping to remove management privileges.

Step: Re-authenticate using the same cloud IAM identity.

Step: Verify that management operations are now denied.

Step: Verify that management restrictions are consistently enforced across all cluster nodes.

Step: Attempt management operations via different nodes in the cluster.

Expected Result: Role-based restrictions are identical regardless of which node handles the request.

Step: If the cluster includes separate management and data plane components, verify restrictions apply to management plane access.

Step: Enumerate all management APIs and CLI commands exposed by the TOE.

Step: For each interface, attempt operations requiring elevated privileges using both authorized and unauthorized credentials.

Expected Result: Access controls are consistently enforced across all interfaces.

The complete list of TSF data managed by this requirement, including:

For each operation (query, modify, delete, clear, and any other specified operations):

The cloud-native configuration and secret management systems supported by the TOE, such as:

That retrieval of TSF data from, and writes of TSF data to, each supported networked system use a channel protected by the inherited FDP_DIT_EXT.1, per FMT_MTD_EXT.1.2, identifying the corresponding TLS components claimed in the ST. TLS protocol behavior itself is evaluated under the DBMS Crypto Module SD and the TLS Functional Package.

For each supported cloud secret management system:

Protection of environment variables containing sensitive data:

Provides instructions for configuring integration with each supported cloud secret management system, including:

Documents secure practices for credential rotation:

Describes secure handling of environment variables:

Documents the protection of credentials in memory:

Warns administrators about common misconfigurations:

Step: Authenticate as a user with an authorized role for the operation.

Step: Perform the operation.

Expected Result: Operation succeeds.

Step: Authenticate as a user without authorization for the operation.

Step: Attempt the same operation.

Expected Result: Operation is denied.

Step: Configure the TOE to retrieve database credentials from AWS Secrets Manager.

Step: Verify the TOE authenticates to Secrets Manager using IAM role assumption.

Step: Verify the TOE successfully retrieves and uses the secret.

Step: Rotate the secret in AWS Secrets Manager.

Step: Verify the TOE retrieves and uses the new secret value (either automatically or after configured refresh).

Step: Revoke the TOE’s IAM permissions to access the secret.

Step: Verify the TOE handles the access denial securely (fails closed, generates appropriate audit record).

Step: Configure the TOE to retrieve secrets from Azure Key Vault.

Step: Verify the TOE authenticates using managed identity or service principal.

Step: Verify successful secret retrieval and usage.

Step: Rotate the secret in Azure Key Vault.

Step: Verify the TOE retrieves the rotated secret.

Step: Remove the TOE’s access policy from Key Vault.

Step: Verify secure failure behavior.

Step: Configure the TOE to retrieve secrets from Vault using the appropriate auth method (e.g., Kubernetes auth, AppRole).

Step: Verify successful authentication and secret retrieval.

Step: Test secret renewal and rotation scenarios.

Step: Revoke the TOE’s Vault token.

Step: Verify secure failure behavior.

Step: Configure sensitive data to be passed via environment variables.

Step: Verify the TOE does not log or expose environment variable values in error messages.

Step: Attempt to retrieve environment variable values through the TOE’s interfaces (APIs, logs, debug endpoints).

Expected Result: Sensitive environment variable values are not exposed.

Step: For containerized deployments, verify environment variables are not exposed via container inspection commands to unauthorized users.

Step: Configure the TOE to retrieve credentials from a cloud secret service.

Step: If memory inspection capabilities are available (e.g., core dump analysis), verify credentials are not retained in memory longer than necessary.

Step: Verify credentials are cleared from memory when the connection is terminated or credentials are rotated.

Configure the TOE to retrieve a secret (e.g., database connection string or master key) from the cloud service.

Verify the retrieval request is made over a secure channel (for example, HTTPS over TLS).

Verify the secret is not logged in plaintext by the TOE upon retrieval.

If the retrieved secret is a cryptographic key (and the ST claims FCS_CKM_EXT.1 in the Crypto Module), verify that the TOE handles the key material according to the Crypto Module’s FCS_CKM.6 key destruction claims and does not persist it to non-volatile storage in plaintext.

Configuration of audit selection criteria (FAU_SEL.1/Cloud):

Configuration of audit export destinations (FAU_STG_EXT.1):

Configuration of secure external communications (FDP_DIT_EXT.1):

Management of external identity provider mappings (FIA_UID_EXT.1):

Monitoring and querying trusted update status and claimed integrity status:

Rotation of cloud-managed credentials or secrets:

Other cloud-specific management functions:

Documents the interface(s) through which each management function is accessed, including:

Provides step-by-step instructions for performing each management function.

Documents any prerequisites or dependencies for management functions (e.g., TLS must be configured before enabling HTTPS for management APIs).

Describes the impact of each management function on TOE security and operation.

Documents cloud-specific management considerations:

Step: Access the audit selection configuration interface.

Step: Configure audit selection based on each available criterion (user identity, tenant identifier, event type, etc.).

Step: Generate events matching and not matching the selection criteria.

Expected Result: Only events matching the criteria are audited.

Step: Restart the TOE.

Step: Verify audit selection configuration persists.

Step: Configure audit export to each supported destination.

Step: Generate auditable events.

Step: Verify events are exported to the configured destination.

Step: Misconfigure the export destination (invalid credentials, unreachable endpoint).

Step: Verify the TOE handles export failures appropriately (generates local alerts, retains events locally).

Step: Register an external identity provider (cloud IAM, LDAP, OIDC).

Step: Configure identity-to-role mappings.

Step: Test authentication using the external provider.

Step: Modify the mappings.

Step: Verify the modified mappings take effect.

Step: Remove the identity provider configuration.

Step: Verify authentication via that provider is no longer possible.

Step: Query trusted update status using available interfaces.

Step: Verify the status report includes relevant update information.

Step: If FPT_TST.1 or FPT_SBT_EXT.1 is implemented, trigger an integrity check and verify the status is updated.

Step: Initiate credential rotation through the management interface.

Step: Verify old credentials are invalidated.

Step: Verify new credentials are functional.

Step: If automated rotation is supported, configure automatic rotation and verify it executes correctly.

Step: Verify management functions can be configured via Kubernetes ConfigMaps or Helm values.

Step: Apply configuration changes using kubectl apply or helm upgrade.

Step: Verify the TOE applies the new configuration.

Step: Verify management functions can be configured via cloud provider interfaces (parameter groups, configuration services).

Step: Apply changes via the cloud provider console or CLI.

Step: Verify the TOE applies the new configuration.

The complete list of roles maintained by the TSF, as assigned in FMT_SMR.1.1/Cloud by the ST author. The SFR’s application note gives tenant administrator, tenant user, and cloud audit authority (a read-only role for audit data and security status) as examples; this SD does not levy roles beyond the ST’s assignment.

For each role:

The mechanism for associating users with roles:

How role membership is verified during access control decisions.

For cloud deployments specifically:

Documents all pre-defined roles and their associated privileges.

Provides instructions for:

Documents the minimum privileges required for each administrative task.

Provides guidance on implementing least-privilege principles using the TOE’s role model.

Documents cloud-specific role management:

Step: Verify the TSF maintains each role specified in the TSS.

Step: Query the list of roles using available administrative interfaces.

Expected Result: All specified roles are present.

Step: Create a new user (or use an existing user not assigned to any role).

Step: Associate the user with the Tenant Administrator role.

Step: Verify the user can perform administrative functions.

Step: Remove the user from the Tenant Administrator role.

Step: Verify the user can no longer perform administrative functions.

Step: Associate a user with the Tenant User role.

Step: Verify the user can perform standard database operations (queries, data modification as permitted).

Step: Verify the user cannot perform administrative operations.

Step: Associate a user with the Cloud Audit Authority role.

Step: Verify the user can access audit data and security status information.

Step: Verify the user cannot modify security configurations or data.

Step: Verify the user cannot modify audit records.

Step: Configure a cloud IAM role (e.g., AWS IAM role, Azure AD group) to map to the Tenant Administrator role.

Step: Authenticate using an identity assigned the cloud IAM role.

Step: Verify the user has Tenant Administrator privileges.

Step: Change the IAM role mapping to Tenant User.

Step: Re-authenticate using the same identity.

Step: Verify the user now has only Tenant User privileges.

Step: Create roles with the same name in two different tenants.

Step: Assign different users to each role.

Step: Verify that users in Tenant A cannot access resources in Tenant B, even with the same role name.

Step: Verify administrative actions in one tenant do not affect another tenant.

Step: Assign a user to a role.

Step: Verify an audit record is generated for the assignment.

Step: Remove the user from the role.

Step: Verify an audit record is generated for the removal.

Step: Verify audit records include user identity, role, action, and timestamp.

The runtime environment conditions monitored by the TSF, from the selection:

For each monitored condition:

The notification mechanisms and recipients:

For cloud deployments specifically:

Documents the configuration of each monitored condition:

Provides instructions for configuring notifications:

Documents recommended responses to each type of detected condition.

Provides guidance for cloud-specific monitoring:

Step: Establish a known security configuration baseline.

Step: Modify a security-relevant configuration parameter outside of authorized management interfaces (e.g., directly edit configuration file, modify database system table).

Expected Result: TSF detects the drift and generates a notification.

Step: Verify the notification includes information about what changed.

Step: Identify a resource the TOE depends on (storage volume, network service, cloud service).

Step: Make the resource unavailable (disconnect network, unmount storage, stop service).

Expected Result: TSF detects the unavailability and generates a notification.

Step: Restore the resource.

Step: Verify the TSF detects recovery (if recovery notification is supported).

Step: Trigger a self-test that will fail (if testing capability exists, e.g., corrupt a test file).

Expected Result: TSF detects the integrity failure and generates a notification.

Step: Verify the notification identifies the integrity failure.

Step: Deploy the TOE as a Kubernetes pod with liveness and readiness probes.

Step: Verify probes respond correctly under normal operation.

Step: Simulate a condition that should cause probe failure.

Expected Result: TSF indicates failure via probe response.

Step: Verify Kubernetes takes configured action (restart pod, mark unhealthy).

Step: Simulate an orchestration failure (deployment timeout, resource allocation failure).

Expected Result: TSF detects and signals the failure.

Step: Trigger a monitored condition.

Step: Verify the notification is received by the configured recipient.

Step: Verify the notification contains required information:

Step: Configure the TOE to send alerts to CloudWatch, Azure Monitor, or equivalent.

Step: Trigger a monitored condition.

Step: Verify the alert appears in the cloud monitoring service.

Step: Verify alert metadata is correct.

Induce or simulate the failure according to the TSS description (for example, revoking connectivity to a required cloud service, detaching storage, or terminating an instance through the orchestrator).

Verify the TOE enters the secure state defined in the TSS.

While the TOE is in the secure state, attempt to access protected data or perform a security-relevant operation, and verify the attempt is refused consistent with the TSS definition of the secure state.

Recover the TOE per the operational guidance and verify normal operation resumes.

The protection type selected (disclosure, modification, or both):

The separate parts of the TOE between which TSF data is transferred:

The specific TSF data protected during transfer:

The mechanisms used to protect transfers:

For cloud deployments specifically:

Documents the deployment architecture for distributed configurations.

Provides instructions for:

Documents the cryptographic algorithms used for protection (reference to DBMS Crypto Module if applicable).

Provides cloud-specific deployment guidance:

Step: Deploy the TOE in a distributed configuration (multi-node cluster).

Step: Capture network traffic between TOE components.

Step: Generate traffic that includes TSF data (authentication, configuration synchronization).

Expected Result: Captured traffic is encrypted; TSF data is not visible in plaintext.

Step: Deploy the TOE in a distributed configuration.

Step: If possible, intercept and modify traffic between components (man-in-the-middle).

Expected Result: Receiving component detects modification and rejects the data.

Step: Verify an appropriate error or audit record is generated.

Step: Verify all nodes in the cluster use protected communication channels.

Step: Attempt to add a rogue node to the cluster without proper credentials.

Expected Result: The rogue node is rejected.

Step: Verify legitimate cluster operations succeed with protection enabled.

Step: Verify management plane traffic is protected independently of data plane traffic.

Step: Capture traffic on both planes.

Expected Result: Both planes use appropriate protection mechanisms.

Step: Verify cluster nodes communicate only over private networks/VPCs.

Step: Verify external access to inter-node communication is blocked.

Step: For Kubernetes deployments, verify network policies restrict inter-pod communication appropriately.

Step: Configure replication between primary and replica instances.

Step: Capture replication traffic.

Expected Result: Replication data is protected according to selected protection type.

Step: Verify replication functions correctly with protection enabled.

The mechanism for querying the current TOE version:

The update mechanisms supported:

The authenticity and integrity verification mechanisms:

For cloud deployments specifically:

Documents the procedure for querying current TOE version.

Provides step-by-step update procedures for each supported mechanism.

Documents the verification process:

Provides guidance for cloud-native updates:

Documents the trusted sources for updates:

Step: Use each available interface to query the current TOE version.

Expected Result: Version information is returned accurately.

Step: Verify the version information matches the installed TOE version.

Step: Obtain a genuine update package from a trusted source.

Step: Apply the update using the documented procedure.

Step: Verify the update is verified for authenticity and integrity.

Step: Verify the update installs successfully.

Step: Query the version to confirm the update was applied.

Step: Obtain a genuine update package.

Step: Modify the package (change a byte, alter contents).

Step: Attempt to apply the tampered update.

Expected Result: The TSF rejects the update due to integrity verification failure.

Step: Verify an appropriate error message or audit record is generated.

Step: Create or obtain an update package signed with an untrusted key.

Step: Attempt to apply the package.

Expected Result: The TSF rejects the update due to authenticity verification failure.

Step: Verify an appropriate error message or audit record is generated.

Step: Push a signed container image to the registry.

Step: Deploy the TOE using the signed image.

Expected Result: Deployment succeeds.

Step: Push an unsigned or invalidly signed image.

Step: Attempt to deploy using the unsigned image.

Expected Result: Deployment fails or generates a security alert.

Step: Configure the TOE to receive updates from the cloud update service.

Step: Apply an update through the service.

Step: Verify the update was validated before installation.

Step: Apply a successful update.

Step: Verify an audit record is generated indicating:

The boot-time or deployment-time components subject to verification:

The integrity verification mechanisms:

The authenticity verification mechanisms:

The action taken if verification fails:

For containerized deployments:

Documents the components verified at boot/deployment time.

Provides instructions for:

Documents the expected behavior when verification fails.

Provides cloud-specific guidance:

Step: Boot the TOE normally.

Step: Verify all boot-time integrity checks pass.

Step: Verify the TOE starts successfully.

Step: Modify a boot-time component (if possible in the test environment).

Step: Attempt to boot the TOE.

Expected Result: TOE detects integrity failure and takes configured action (prevent boot or alert).

Step: Verify the action matches the configuration.

Step: Deploy the TOE using a properly signed container image.

Expected Result: Deployment succeeds.

Step: Attempt to deploy using an unsigned image.

Expected Result: Deployment fails or generates security alert.

Step: Attempt to deploy using an image with invalid signature.

Expected Result: Deployment fails or generates security alert.

Step: Configure an admission controller to validate image signatures.

Step: Attempt to deploy a pod with a signed image.

Expected Result: Pod is admitted.

Step: Attempt to deploy a pod with an unsigned image.

Expected Result: Pod is rejected by the admission controller.

Step: Trigger a verification failure (deploy unsigned image, modify component).

Step: Verify an alert is generated to administrators.

Step: Verify the alert includes information about the failure.

The conditions under which self-tests are run:

The self-tests performed:

For each self-test:

The mechanism for users to verify TSF integrity:

Documents all self-tests performed and their purpose.

Provides instructions for:

Documents the expected behavior when self-tests fail.

Provides troubleshooting guidance for self-test failures.

Step: Start the TOE.

Step: Verify self-tests are executed during startup (check logs, audit records).

Step: Verify self-tests complete successfully.

Step: Verify the TOE becomes operational after successful tests.

Step: Configure the self-test interval.

Step: Wait for the interval to elapse.

Step: Verify self-tests are executed (check logs, audit records).

Step: As an authorized user, initiate a self-test.

Step: Verify the self-test executes.

Step: Verify results are reported to the user.

Step: If possible, cause a self-test to fail (corrupt a verified file, alter configuration).

Step: Trigger the self-test.

Expected Result: TSF detects the failure.

Step: Verify the configured failure action is taken (alert, shutdown, degraded mode).

Step: Verify an audit record is generated for the failure.

Step: Request TSF data integrity verification (as authorized user).

Step: Verify the result indicates current integrity status.

Step: Modify TSF data (if possible in test environment).

Step: Request integrity verification again.

Expected Result: Verification detects the modification.

Step: Verify known-answer tests or algorithm validation tests are performed.

Step: Verify cryptographic operations are blocked until self-tests pass.