Search / finos-ccc/ccc.core.cn / v2026.06-rc5

Release · v2026.06-rc5

FINOS-CCC/CCC.Core.CN Control Catalog

FINOS-CCC/CCC.Core.CN

Controls for Common Cloud Controls Core technologies, as defined by the FINOS Common Cloud Controls project.

Published by FINOS Common Cloud Controls

Install

OCI v1.1
$grcli unpack --repository finos-ccc/ccc.core.cn --tag v2026.06-rc5
Coordinate
oci.grc.store/finos-ccc/ccc.core.cn:v2026.06-rc5
Manifest digest
sha256:07f60df8ceee7e6aa527bf488e8ea428bcbc9a687c30feacaff330d98b6058e8

Provenance

1 layer
Digest Media type Size
3a46f3e61c9b… application/vnd.gemara.artifact.v1+yaml 30.7 KiB
Bundle config blob
{
  "bundle-version": "1.0",
  "gemara-version": "v1.2.0",
  "metadata": {
    "provenance": {
      "buildDefinition": {
        "buildType": "https://grc.store/grcli/buildtype/v0",
        "externalParameters": {
          "artifact": {
            "id": "CCC.Core.CN",
            "type": "ControlCatalog"
          },
          "target": {
            "registry": "oci.grc.store",
            "repository": "finos-ccc/ccc.core.cn",
            "tag": "v2026.06-rc5"
          }
        },
        "internalParameters": {
          "CI": "true",
          "GITHUB_ACTIONS": "true",
          "GITHUB_ACTOR": "eddie-knight",
          "GITHUB_REF": "refs/heads/main",
          "GITHUB_REPOSITORY": "eddie-knight/common-cloud-controls",
          "GITHUB_RUN_ATTEMPT": "1",
          "GITHUB_RUN_ID": "26771723499",
          "GITHUB_SHA": "a9503345caf59a144d8ab9b4bede212b393ca56a",
          "GITHUB_WORKFLOW": "Batch Release All Catalogs",
          "RUNNER_OS": "Linux"
        },
        "resolvedDependencies": [
          {
            "name": "artifacts/core/ccc/controls.yaml",
            "uri": "file://artifacts/core/ccc/controls.yaml",
            "digest": {
              "sha256": "3a46f3e61c9ba94cb0d90ead061570d115a675485d956c378262f7826c3f8cc2"
            }
          },
          {
            "name": "source",
            "uri": "git+https://github.com/eddie-knight/common-cloud-controls@a9503345caf59a144d8ab9b4bede212b393ca56a",
            "digest": {
              "gitCommit": "a9503345caf59a144d8ab9b4bede212b393ca56a"
            }
          }
        ]
      },
      "runDetails": {
        "builder": {
          "id": "https://github.com/eddie-knight/common-cloud-controls/actions/runs/26771723499",
          "version": {
            "go": "go1.25.0",
            "go-arch": "amd64",
            "go-os": "linux",
            "grcli": "v0.2.2"
          }
        },
        "metadata": {
          "invocationId": "26771723499-1",
          "startedOn": "2026-06-01T17:47:01.344766074Z",
          "finishedOn": "2026-06-01T17:47:01.518750021Z"
        },
        "byproducts": [
          {
            "name": "controls.yaml",
            "digest": {
              "sha256": "3a46f3e61c9ba94cb0d90ead061570d115a675485d956c378262f7826c3f8cc2"
            }
          }
        ]
      }
    }
  },
  "artifacts": [
    {
      "name": "controls.yaml",
      "type": "ControlCatalog",
      "id": "CCC.Core.CN",
      "role": "artifact"
    }
  ]
}

CCC Common Cloud Controls Core Controls

Controls for Common Cloud Controls Core technologies, as defined by the FINOS Common Cloud Controls project.

ID
CCC.Core.CN
Version
v2026.06-rc5
Gemara version
v1.2.0
Author
FINOS Common Cloud Controls

Encryption

The Encryption group covers entries related to protecting data confidentiality and integrity through cryptographic mechanisms. This includes encryption in transit and at rest, key management, and certificate lifecycle management.

  1. CCC.Core.CN01 Encrypt Data for Transmission

    Objective

    Ensure that all communications are encrypted in transit to protect data integrity and confidentiality.

    Assessment requirements
    1. When a port is exposed for non-SSH network traffic, all traffic MUST include a TLS handshake AND be encrypted using TLS 1.3 or higher.

      Applicability: tlp-green, tlp-amber, tlp-red

    2. When a port is exposed for SSH network traffic, all traffic MUST include a SSH handshake AND be encrypted using SSHv2 or higher.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    3. When the service receives unencrypted traffic, then it MUST either block the request or automatically redirect it to the secure equivalent.

      Applicability: tlp-green, tlp-amber, tlp-red

    4. When a port is exposed, the service MUST ensure that the protocol and service officially assigned to that port number by the IANA Service Name and Transport Protocol Port Number Registry, and no other, is run on that port.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    5. When a service transmits data using TLS, mutual TLS (mTLS) MUST be implemented to require both client and server certificate authentication for all connections.

      Applicability: tlp-amber, tlp-red

    Guidelines
    • CCM
      • CEK-03Data Encryption (in transit and at rest)
      • CEK-04Key Management (use strong encryption)
      • IVS-03Network Security (monitor, encrypt, restrict)
      • IVS-07Migration to Cloud Environments (encrypt when migrating servers)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH02
  2. CCC.Core.CN13 Minimize Lifetime of Encryption and Authentication Certificates

    Objective

    Ensure that encryption and authentication certificates have a limited lifetime to reduce the risk of compromise and ensure the use of up-to-date security practices.

    Assessment requirements
    1. When a port is exposed that uses certificate-based encryption, the service MUST only use valid, unexpired certificates issued by a trusted certificate authority.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When a port is exposed that uses certificate-based encryption, the service MUST rotate active certificates within 180 days of issuance.

      Applicability: tlp-amber

    3. When a port is exposed that uses certificate-based encryption, the service MUST rotate active certificates within 90 days of issuance.

      Applicability: tlp-red

    Threats
    • CCC.Core.Threats
      • CCC.Core.TH18
  3. CCC.Core.CN02 Encrypt Data for Storage

    Objective

    Ensure that all data stored is encrypted at rest using strong encryption algorithms.

    Assessment requirements
    1. When data is stored, it MUST be encrypted using the latest industry-standard encryption methods.

      Applicability: tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • CEK-03Data Encryption (in transit and at rest)
      • CEK-04Key Management (use strong encryption)
      • UEM-08Storage Encryption (on managed endpoint devices)
      • DSP-17
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH01
  4. CCC.Core.CN11 Protect Encryption Keys

    Objective

    Ensure that encryption keys are managed securely by enforcing the use of approved algorithms, regular key rotation, and customer-managed encryption keys (CMEKs).

    Assessment requirements
    1. When encryption keys are used, the service MUST verify that all encryption keys use the latest industry-standard cryptographic algorithms.

      Applicability: tlp-amber, tlp-red

    2. When encryption keys are used, the service MUST rotate active keys within 180 days of issuance.

      Applicability: tlp-amber

    3. When encrypting data, the service MUST verify that customer-managed encryption keys (CMEKs) are used.

      Applicability: tlp-amber, tlp-red

    4. When encryption keys are accessed, the service MUST verify that access to encryption keys is restricted to authorized personnel and services, following the principle of least privilege.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    5. When encryption keys are used, the service MUST rotate active keys within 365 days of issuance.

      Applicability: tlp-clear, tlp-green

    6. When encryption keys are used, the service MUST rotate active keys within 90 days of issuance.

      Applicability: tlp-red

    Guidelines
    • CCM
      • CEK-08CSC Key Management Capability (must provide the capability to self-manage keys)
      • CEK-10Key Generation (using industry accepted cryptographic libraries)
      • CEK-12Key Rotation
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH16

Data Resilience

The Data Resilience group covers entries related to ensuring data availability, integrity, and sovereignty across its lifecycle. This includes replication, backup, recovery, region restrictions, and protection against data loss or corruption.

  1. CCC.Core.CN06 Restrict Deployments to Trust Perimeter

    Objective

    Ensure that the service and its child resources are only deployed on infrastructure in locations that are explicitly included within a defined trust perimeter.

    Assessment requirements
    1. When the service is running, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When a child resource is deployed, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • DSP-19Data Location (specify and document processing and backup locations)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH03
  2. CCC.Core.CN08 Replicate Data to Multiple Locations

    Objective

    Ensure that data is replicated across multiple physical locations to protect against data loss due to hardware failures, natural disasters, or other catastrophic events.

    Assessment requirements
    1. When data is created or modified, the data MUST have a complete and recoverable duplicate that is stored in a physically separate data center.

      Applicability: tlp-green, tlp-amber, tlp-red

    2. When data is replicated into a second location, the service MUST be able to accurately represent the replication locations, replication status, and data synchronization status.

      Applicability: tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • BCR-08Backup
      • BCR-10Disaster Response Plan
      • BCR-11Equipment Redundancy
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH06
  3. CCC.Core.CN10 Restrict Data Replication to Trust Perimeter

    Objective

    Ensure that data is only replicated on infrastructure in locations that are explicitly included within a defined trust perimeter.

    Assessment requirements
    1. When data is replicated, the service MUST ensure that replication only occurs to destinations that are explicitly included within the defined trust perimeter.

      Applicability: tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • DSP-10Sensitive Data Transfer (only processed within scope as permitted)
      • DSP-19Data Location (specify and document the physical locations of data)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH04
  4. CCC.Core.CN14 Maintain Recent Backups

    Objective

    Ensure that all backups used for disaster recovery are recent and subject to a retention policy that limits deletion.

    Assessment requirements
    1. When backups are created for disaster recovery purposes, the storage mechanism MUST NOT allow modification or deletion within 30 days of creation.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When backups are created for disaster recovery purposes, the most recent backup MUST have a creation date within the past 30 days.

      Applicability: tlp-clear, tlp-green, tlp-amber

    3. When backups are created for disaster recovery purposes, the most recent backup MUST have a creation date within the past 14 days.

      Applicability: tlp-red

    Threats
    • CCC.Core.Threats
      • CCC.Core.TH06Data is Lost or Corrupted

Observability

The Observability group covers entries related to logging, monitoring, metrics, alerting, and event publication. This includes audit trail integrity, enumeration detection, and protection against tampering or unauthorized access to operational telemetry.

  1. CCC.Core.CN09 Ensure Integrity of Access Logs

    Objective

    Ensure that access logs are always recorded to an external location that cannot be manipulated from the context of the service(s) it contains logs for.

    Assessment requirements
    1. When the service is operational, its logs and any child resource logs MUST NOT be accessible from the resource they record access to.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When the service is operational, disabling the logs for the service or its child resources MUST NOT be possible without also disabling the corresponding resource.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    3. When the service is operational, any attempt to redirect logs for the service or its child resources MUST NOT be possible without halting operation of the corresponding resource and publishing corresponding events to monitored channels.

      Applicability: tlp-amber, tlp-red

    Guidelines
    • CCM
      • LOG-02Audit Logs Protection (security and retention)
      • LOG-04Audit Logs Access and Accountability (Restrict audit logs access to authorized personnel)
      • LOG-09Log Protection (protects audit records from unauthorized access)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH07
      • CCC.Core.TH09
      • CCC.Core.TH04
  2. CCC.Core.CN04 Log All Access and Changes

    Objective

    Ensure that all access attempts are logged to maintain a detailed audit trail for security and compliance purposes.

    Assessment requirements
    1. When administrative access or configuration change is attempted on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When any attempt is made to modify data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

      Applicability: tlp-amber, tlp-red

    3. When any attempt is made to read data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

      Applicability: tlp-red

    Guidelines
    • CCM
      • LOG-08Log Records (Generate audit records containing relevant security information)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH01
  3. CCC.Core.CN07 Alert on Unusual Enumeration Activity

    Objective

    Ensure that logs and associated alerts are generated when unusual enumeration activity is detected that may indicate reconnaissance activities.

    Assessment requirements
    1. When enumeration activities are detected, the service MUST publish an event to a monitored channel which includes the client identity, time, and nature of the activity.

      Applicability: tlp-amber, tlp-red

    2. When enumeration activities are detected, the service MUST log the client identity, time, and nature of the activity.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • LOG-05Audit Logs Monitoring and Response (take action on detected anomalies)
      • SEF-05Incident Response Metrics (establish and monitor metrics)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH15

Access Control

The Access Control group covers entries related to authentication, authorization, and trust perimeter enforcement. This includes multi-factor authentication, least privilege access, network access rules, and prevention of unauthorized access or reconnaissance.

  1. CCC.Core.CN03 Implement Multi-factor Authentication (MFA) for Access

    Objective

    Ensure that all sensitive activities require two or more identity factors during authentication to prevent unauthorized access.

    Assessment requirements
    1. When an entity attempts to modify the service through a user interface, the authentication process MUST require multiple identifying factors for authentication.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When an entity attempts to modify the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    3. When an entity attempts to view information on the service through a user interface, the authentication process MUST require multiple identifying factors from the user.

      Applicability: tlp-amber, tlp-red

    4. When an entity attempts to view information on the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.

      Applicability: tlp-amber, tlp-red

    Guidelines
    • CCM
      • IAM-14Strong Authentication (Define, implement and evaluate processes - including MFA)
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH01
  2. CCC.Core.CN05 Prevent Access from Untrusted Entities

    Objective

    Ensure that secure access controls enforce the principle of least privilege to restrict access to authorized entities from explicitly trusted sources only.

    Assessment requirements
    1. When an attempt is made to modify data on the service or a child resource, the service MUST block requests from unauthorized entities.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    2. When administrative access or configuration change is attempted on the service or a child resource, the service MUST refuse requests from unauthorized entities.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    3. When administrative access or configuration change is attempted on the service or a child resource in a multi-tenant environment, the service MUST refuse requests across tenant boundaries unless the origin is explicitly included in a pre-approved allowlist.

      Applicability: tlp-clear, tlp-green, tlp-amber, tlp-red

    4. When data is requested from outside the trust perimeter, the service MUST refuse requests from unauthorized entities.

      Applicability: tlp-amber, tlp-red

    5. When any request is made from outside the trust perimeter, the service MUST NOT provide any response that may indicate the service exists.

      Applicability: tlp-red

    6. When any request is made to the service or a child resource, the service MUST refuse requests from unauthorized entities.

      Applicability: tlp-green, tlp-amber, tlp-red

    Guidelines
    • CCM
      • DSP-01Security and Privacy Policy and Proceduress
      • DSP-07Data Protection by Design and Default
      • DSP-08Data Privacy by Design and Default
      • DSP-10Sensitive Data Transfer
      • DSP-17Sensitive Data Protection
    Threats
    • CCC.Core.Threats
      • CCC.Core.TH01