CLD-04: Application Programming Interface (API) Security

There is no evidence of a capability to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).

C|P-CMM1 is N/A, since a structured process is required to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).

Cloud Security (CLD) efforts are requirements-driven and governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist: o Identify cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements for cloud security management. o Use an informal process to govern cloud-specific cybersecurity and data privacy-specific tools. Cloud requirements for interoperability between components (APIs) are identified and documented.

• Cloud security management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
• IT/cybersecurity personnel:
• A Shared Responsibility Matrix (SRM), or similar Customer Responsibility Matrix (CRM), is documented for each Cloud Service Providers (CSPs) instance that takes into account differences between Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) methodologies.
• IT personnel have a documented architecture for cloud-based technologies to support cybersecurity and data protection requirements.
• Cybersecurity and data privacy requirements are identified and documented for cloud-specific sensitive/regulated data processing, storing and/ or transmitting, including restrictions on data processing and storage locations.

Cloud Security (CLD) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist: o Ensure the cloud security architecture supports the organization's technology strategy to securely design, configure and maintain cloud employments. o Ensure multi-tenant CSP assets (physical and virtual) are designed and governed such that provider and customer (tenant) user access is appropriately segmented from other tenant users. o Ensure CSPs use secure protocols for the import, export and management of data in cloud-based services. o Implement a dedicated subnet to host security-specific technologies on all cloud instances, where technically feasible. o Governs changes to cloud-based systems, applications and services to ensure their stability, reliability and predictability. o Reviews processes to identify and prevent use of unapproved CSPs. Cloud requirements for interoperability between components (APIs) are identified and documented.

• Roles and associated responsibilities for governing cloud instances, including provisioning, maintaining and deprovisioning, are formally assigned.
• A Shared Responsibility Matrix (SRM), or similar Customer Responsibility Matrix (CRM), is documented for each Cloud Service Providers (CSPs) instance that takes into account differences between Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) methodologies.
• IT architects, in conjunction with cybersecurity architects:
• A Change Advisory Board (CAB), or similar function:
• A dedicated IT infrastructure team, or similar function, enables the implementation of cloud management controls to ensure cloud instances are both secure and compliant, leveraging industry-recognized secure practices that are CC|P-specific.
• Cybersecurity and data privacy requirements are identified and documented for each CSP instance to address sensitive/regulated data processing, storing and/ or transmitting and provide restrictions on data processing and storage locations.
• A Data Protection Impact Assessment (DPIA) is used to help ensure the protection of sensitive/regulated data processed, stored or transmitted on external systems.

See C|P-CMM3. There are no defined C|P-CMM4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).

See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to ensure support for secure interoperability between components with Application Programming Interfaces (APIs).