A Checklist for CSA’s Cloud Controls Matrix v4

Originally published by NCC Group.

Written by Nandor Csonka, Director of Cloud Security, NCC Group.

The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is an internationally recognized framework that helps cloud service providers (CSPs) and cloud service customers (CSCs) manage risk. While often used in silos, CSA CCM is an effective tool for multinational organizations to align their cloud security across and into regional requirements. And the latest versions of CCM is a reflection of the latest CSA evolutions and improvements.

The latest version, CCM v4.0, was released in 2021 and consists of 197 individual controls across 17 cloud security domains. In this article, we'll summarize each domain and give some tips to enhance cloud security along the way.

But first, let’s look at what’s been added to this version.

The 17 CSA CCM v4 Controls: Explained

Check out the control explanations below for definitions, professional tips, and a breakdown of the impacts on different industries, businesses, and types of programs.

1. Audit & Assurance (A&A)

Audit controls are an essential part of cloud security, but many organizations find the auditing process challenging. Audit and environmental reviews can and should be documented in a change management or service ticketing system to show dates, personnel, and results of all reviews. The A&A domain helps CSPs define and implement audit management processes to provide them with a clear understanding of the level of assurance expected by customers, industry standards, and self-imposed business requirements.

Quick Tip Compliance, audit, and assurance should be continuous. They should not be seen as merely point-in-time activities, and many standards and regulations are moving more toward this model. This is especially true in cloud computing where both the provider and customer tend to be in a constant state of change and are rarely ever in a static state.

Cloud/SaaS providers should:

• Clearly communicate their audit results, certifications, and attestations with particular attention to:
  • The scope of assessments.
  • Specific features/services that are covered in specific locations and jurisdictions.
  • How customers can deploy compliant applications and services using the platform.
  • Clearly stating any additional customer responsibilities and limitations.
  • Cloud providers must maintain their certifications/attestations over time and proactively communicate any changes in status.
  • Cloud providers should engage in continuous compliance initiatives to avoid creating any gaps, and thus exposures, for their customers.
  • Provide customers with commonly needed evidence and artifacts of compliance, such as logs of administrative activity the customer cannot otherwise collect on their own.

Cloud customers should:

• Understand their full compliance obligations before deploying, migrating to, or developing in the cloud.
• Evaluate a provider's third-party attestations and certifications and align those to compliance needs.
• Understand the scope of assessments and certifications, including both the controls and the features/services covered.
• Attempt to select auditors with experience in cloud computing, especially if pass-through audits and certifications will be used to manage the customer's audit scope.
• Ensure they understand what artifacts of compliance the provider offers, and effectively collect and manage those artifacts.
• Create and collect their own artifacts when the provider's artifacts are not sufficient.
• Keep a register of cloud providers used, relevant compliance requirements, and current status. The Cloud Security Alliance Cloud Controls Matrix can support this activity.

2. Application & Interface Security (AIS)

Many organizations struggle to effectively identify and mitigate risk within cloud environments. The AIS domain was designed to help organizations migrate towards secure design, development, deployment, and operations of applications and their interfaces in the cloud environment.

Quick Tip Ensure there is strong perimeter security for API gateways and web consoles.

• Use strong authentication and MFA.
• Maintain tight control of primary account holder/root account credentials and consider dual-authority principles to access them.
  • Establishing multiple accounts with your provider will help with account granularity and to limit potential impacts (with IaaS and PaaS).
• Use separate super administrator and day-to-day administrator accounts instead of root/primary account holder credentials.
• Consistently implement least-privilege accounts for access.
  • This is why you separate development and test accounts with your cloud provider.
• Enforce use of MFA whenever available.
• Understand the security capabilities of your cloud providers. Not merely their baseline, but the various platforms and services.
• Build security into the initial design process. Cloud deployments are more often greenfield, creating new opportunities to engage security early.
• Even if you don't have a formal SDLC, consider moving to continuous deployment and automating security into the deployment pipeline.
• Threat modeling, Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST), with fuzzing, should all be integrated. Testing should be configured to work in the cloud environment, but also to test for concerns specific to cloud platforms, such as stored API credentials.
• Understand the new architectural options and requirements in the cloud. Update your security policies and standards to support them, and don't merely attempt to enforce existing standards on an entirely different computing model.
• Integrate security testing into the deployment process.
• Use software-defined security to automate security controls.
• Use event-driven security, when available, to automate detection and remediation of security issues.
• Use different cloud environments to better segregate management plane access and provide developers the freedom they need to configure development environments, while also locking down production environments.

3. Business Continuity Management and Operational Resilience (BCR)

Many organizations’ business continuity plans do not incorporate cloud services. The BCR domain focuses on cloud resilience, including:

• Assess the impact of unavailability
• Determine strategies to reduce disruptions
• Establish backup capabilities and disaster response plans
• Exercise disaster recovery
• Install relevant equipment for redundancy.

Quick Tip Architecture for failure. Take a risk-based approach to everything. Even when you assume the worst, it doesn't mean you can afford or need to keep full availability if the worst happens.

• Design for high availability within your cloud provider. In IaaS and PaaS this is often easier and more cost-effective than the equivalent in traditional infrastructure.
  • Take advantage of provider-specific features.
  • Understand provider history, capabilities, and limitations.
  • Cross-location should always be considered but beware of costs depending on availability requirements.
  • Also ensure things like images and asset IDs are converted to work in the different locations.
• Prepare for graceful failure in case of a cloud provider outage.
  • This can include plans for interoperability and portability with other cloud providers or a different region from your current provider.
• For super-high-availability applications, start with a cross-location business community (BC) before attempting cross-provider BC.
• Cloud providers, including private cloud, must provide the highest levels of availability and mechanisms for customers/users to manage aspects of their own availability.

4. Change Control and Configuration Management (CCC)

The Change Control and Configuration Management domain consists of nine (9) controls. These controls are designed to mitigate risks associated with configuration changes to information technology (IT) assets by adherence to a robust change management process, regardless of whether IT assets are managed internally or externally.

This domain ensures IT asset configurations are only modified to an approved baseline after the change management authority authorizes planned changes.

Quick Tip The organization should:

• Collaborate with relevant internal and external parties involved in the change management
• Assess the impact and type of change to determine the risk of the change before it is applied.
• Adopt Change Management Technologies to manage the change management workflow.

These tools should help adequately manage the authorization process, including activity logging. In addition, real-time reporting/monitoring capabilities should be implemented to monitor change progress so that quick decisions can be made to manage the risks of unforeseen issues due to the change implementation.

Understanding how those relevant components impact the security and usability of the supply chain that supports organizational environments should be one aspect of such collaboration.

5. Cryptography, Encryption & Key Management (CEK)

The CEK domain is designed to help organizations employ encryption to secure their sensitive data. Controls within this domain span the governance, risk, and compliance (GRC) spectrum, and are applicable for governing policies and procedures, risk management, the processing of key lifecycle activities, and cryptographic key management systems (CKMS).

Implementation of these controls may be a shared responsibility between the CSP (Cloud Service Provider) and CSC (Cloud Service Customer). The detailed implementation and allocation of these responsibilities are dependent on the model (i.e., on-premises, in the cloud, hybrid, etc.), services used (IaaS, PaaS, SaaS), and the applicability of any laws and regulations.

Quick Tip Understand the specific capabilities of the cloud platform you are using.

• Don't dismiss cloud provider data security. In many cases, it is more secure than building your own and comes at a lower cost.
• Create an entitlement matrix for determining access controls. Enforcement will vary based on cloud provider capabilities.
• Consider Cloud Access Security Brokers (CASB) to monitor data flowing into SaaS. It may still be helpful for some PaaS and IaaS but rely more on existing policies and data repository security for those types of large migrations.
• Use the appropriate encryption option based on the threat model for your data, business, and technical requirements.
• Consider use of provider-managed encryption and storage options. Where possible, use a customer-managed key.
• Leverage architecture to improve data security. Don't rely completely on access controls and encryption.
• Ensure both API and data-level monitoring are in place, and that logs meet compliance and lifecycle policy requirements
• Standards exist to help establish good security and the proper use of encryption and key management techniques and processes. Specifically, NIST SP-800-57 and ANSI X9.69 and X9.73.

6. Datacenter Security (DCS)

Controls within this domain focus on data center security and are geared toward Cloud Service Providers (CSPs). CSPs can use these controls to protect the information that they host on behalf of their customers.

Quick Tip Keeping an updated inventory is critical. Ensure that all assets are classified appropriately to ensure that appropriate security gets applied based on how critical those systems are to running the organization.

7. Data Security and Privacy Lifecycle Management (DSP)

This is a new domain that was introduced in this version of CCM. Controls within this domain focus on general privacy and data security elements. They were designed by combining common elements of major privacy regulations and serve as a baseline for organizations worldwide.

Quick Tip Don’t forget about the regulatory and compliance requirements associated with the types of data being stored/processed/transmitted. i.e., GDPR, NIST 800-171, PCI, HIPAA, etc.

• Data Loss Prevention (DLP) is typically a way to monitor and protect data that your employees’ access via monitoring local systems, web, email, and other traffic. It is not typically used within data centers, and thus is more applicable to SaaS than PaaS or IaaS, where it is typically not deployed.
• CASB (Cloud Access and Security Brokers): Some CASBs include basic DLP features for the sanctioned services they protect. For example, you could set a policy that a credit card number is never stored in a particular cloud service. The effectiveness depends greatly on the tool, the cloud service, and how the CASB is integrated for monitoring. Some CASB tools can also route traffic to dedicated DLP platforms for more robust analysis than is typically available when the CASB offers DLP as a feature.
• Cloud provider feature: The cloud provider themselves may offer DLP capabilities, such as a cloud file storage and collaboration platform that scans uploaded files for content and applies corresponding security policies

8. Governance, Risk Management and Compliance (GRC)

Controls within this domain focus on compliance efforts (specifically corporate and IT governance) that are commonly managed by a governance committee or board of directors. This domain provides guidance on:

• Developing, implementing and documenting security policies (regulatory, advisory, and informative)
• Managing governance and enterprise risk programs and confidentiality, integrity, and availability (CIA)
• Creating procedures to meet compliance while reducing risk when implementing security controls.

Quick Tip Identify the shared responsibilities of security and risk management based on the chosen cloud deployment and service model.

• Develop a Cloud Governance Framework/Model as per relevant industry best practices, global standards, and regulations like CSA CCM, COBIT 5, NIST RMF, ISO/IEC 27017, HIPAA, PCI DSS, EU GDPR, etc.
• Understand how a contract affects your governance framework/model.
  • Obtain and review contracts (and any referenced documents) before entering into an agreement.
  • Don't assume that you can effectively negotiate contracts with a cloud provider—but this also shouldn't necessarily stop you from using that provider.
  • If a contract can't be effectively negotiated and you perceive an unacceptable risk, consider alternate mechanisms to manage that risk (e.g. monitoring or encryption).
• Develop a process for cloud provider assessments.
  • This should include: Contract review, self-reported compliance review, documentation and policies, available audits and assessments, service reviews adapting to the customer’s requirements, and strong change-management policies to monitor changes in the organization's use of the cloud services.
  • Cloud provider re-assessments should occur on a scheduled basis and be automated if possible.
  • Cloud providers should offer easy access to documentation and reports needed by cloud prospects for assessments, (e.g.the CSA STAR registry).
• Align risk requirements to the specific assets involved and the risk tolerance for those assets.
• Create a specific risk management and risk acceptance/mitigation methodology to assess the risks of every solution in the space
• Use controls to manage residual risks by mitigating, transferring, avoiding, or accepting. Understand your organization’s risk tolerance to decide how to address the current situation. Generally speaking, the total cost to address risks should be less than the revenue-generating capability of your affected systems over a specific period of time.
• Use tooling to track approved providers based on asset type (e.g. linked to data classification), cloud usage, and management.

9. Human Resources (HRS)

As the conduit between people and technology, Human Resources plays an instrumental role in IT security and the success of an organization's compliance structure. That's why controls in this domain focus on ensuring that internal personnel complies with organizational security policies. It includes guidance on things like:

• Remote work procedures
• Security awareness training - see tips below!
• Code of conduct and the acceptable use of technology
• Securing corporate assets

Quick Tip

Focus on organizational security awareness training on the individual's compliance responsibilities and the importance it plays in organizational security.

Embed testing to embed training over time. Tests should measure personnel’s understanding of the responsibilities and protections required to secure corporate assets. This evaluation may be used to improve training and verify that relevant knowledge transfer occurs. A training attendance registry should be maintained.

10. Identity and Access Management (IAM)

This domain focuses on ensuring appropriate access to resources across increasingly heterogeneous cloud environments by fulfilling IAM requirements. It includes guidance on creating and managing:

• Access controls for individual network entities
• Privileged and non-privileged access rights to cloud assets

Quick Tip The information system should require authorizations to access system resources and follow communicated and approved policies. The organization should adopt multiple authorization concepts (i.e., user manager, system/information owner).

11. Interoperability and Portability (IPY)

Proper interoperability and portability standards ensure that components of processing systems, data, and applications continue to work properly when elements of the cloud environment change.

Without these standards intact, service disruption and lock-ins caused by processing incompatibility and conflicts can occur. That is why this domain focuses on helping organizations implement measures to mitigate risks related to the lack of interoperability and portability. To name a few, this domain helps organizations:

• Create standardized network protocols for data imports and exports,
• Implement standardized network protocols for the management of all interoperability and portability systems
• Use an industry-recognized virtualization platform and standard virtualization formats.

Quick Tip Evidence of executed and planned security tests on all interoperability and portability systems should be provided per contractual agreements or upon request. Agreements must include provisions specifying CSCs access to data upon contract termination and will include:

• Data format
• Length of time the data will be stored
• Scope of the data retained and made available to the CSCs
• Data deletion policy

12. The Infrastructure and Virtualization Security (IVS)

The IVS domain helps CSPs, and CSCs improve infrastructure resilience and utilize virtualization technologies - a vital element of IaaS (Infrastructure as a Service) and private clouds.

Quick Tip Network communications authorized by a business should be encrypted and require authorization. Conversely, unjustified network communications should be disallowed. Container-based application-aware network monitoring tools should be leveraged for:

• Automated determination of proper container networking surfaces, including both inbound ports and process-port bindings.
• Detection of traffic flows between containers and other network entities over both wire traffic and encapsulated traffic.
• Detection of network anomalies—such as unexpected traffic flows within the organization’s network, port scanning, or outbound access to potentially dangerous destinations.
• Detection of invalid or unexpected malicious processes—and data they introduce into the environment.

13. Logging and Monitoring (LOG)

Controls in this domain enable organizations to improve their enterprise security operations with efficient logging and monitoring - both of which are critical for incident response, incident management, and digital forensics.

Quick Tip Logging and monitoring policies and procedures should capture the following events:

• Individual user accesses to systems and invalid access attempts
• Actions taken by any individual with root or administrative privileges
• Access to all audit logs should be restricted based on need-to-know and least privilege principles
• Changes, additions, or deletions to accounts with root or administrative privileges.
• Use of, and changes to, identification and authentication mechanisms, including elevation of privilege
• Initializing, stopping, or pausing audit logs
• Creation and deletion of system-level objects. (I.e., anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, etc.)

14. Security Incident Management, E-Discovery, and Cloud Forensics (SEF)

Controls in this domain are designed to help organizations establish procedures to manage security incidents and mitigate business risks.

Quick Tip Periodically test, update, and verify the effectiveness of incident response plans using various event scenarios.

• All critical operations should be tested at least once annually, with test results and follow-up developed, documented, and communicated as appropriate.
• Organizations should also test, update, and improve incident response plans after:
  • Significant organizational changes
  • External supply chain disruptions and natural disasters
  • Security attacks, particularly those resulting in security breaches
• Incident response plans should be reconciled with the organization’s business continuity and disaster recovery plans.

15. Supply Chain Management Transparency and Accountability (STA)

This domain includes supply chain risk management controls that focus on monitoring security and compliance across the supply chain and creating and managing policies to secure data exchanged between the CSP/CSC Shared Security Responsibility Model (SSRM) and third-party providers.

Quick Tip Both the CSP and CSC should follow applicable local and international third-party risk management (TPRM) best practices for managing supply chain risks, including:

• Periodic reviews of organizational and technical risk factors
• Contract requirements
• Environmental changes
• Security incident response capabilities for all supply chain organizations.
• Any other applicable regulatory requirements and standards

16. Threat and Vulnerability Management (TVM)

Controls in this domain focus on assessing and mitigating vulnerabilities that may evolve and impact assets, security architectures, designs, and solution components - and cause ongoing issues with the security architecture and engineering of an organization’s infrastructure.

Quick Tip Organizations should establish a schedule of detection, reporting, and mitigation so that all actions to address threats and non-conformance are performed on time and reported to the integrated TVM system for monitoring and oversight. When applicable, organizations should implement automation so that threats and non-conformance are mitigated in a timely manner.

17. Universal Endpoint Management (UEM)

Humans are the biggest cybersecurity vulnerability. When it comes to enterprise endpoint security, this is mainly due to user behavior (cough: human error...) and the awareness (or lack thereof) of a company’s approach to acceptable use of devices and technologies (e.g., managed vs. unmanaged, enterprise-owned vs. personal). This domain helps organizations mitigate risks associated with using a computer outside of the corporate office (e.g., mobile computing, mobile devices, etc.). Controls focus on:

• Maintaining an inventory of all endpoints.
• Managing services and application approvals
• Implementing security measures like automatic lock screens, firewalls, and anti-malware detection, and utilizing prevention technologies, storage encryption, and data loss prevention technologies.

Quick Tip All organizational endpoint systems should be identified and protected. In addition, a policy against the inventory should be established and documented (including scan type, number of scans, schedule, and exceptions/exclusions).

An inventory of all mobile devices used to store and access company data should be kept and maintained. Include all device status changes (i.e., operating system, patch levels, lost/decommissioned status, and to whom the device is assigned or approved for usage [BYOD]) in the inventory.

A documented list of approved application stores should be defined as acceptable for mobile devices accessing or storing provider-managed data.

About the Author

Nandor Csonka joined NCC Group in 2021 as Director of Cloud Security within the Risk Management and Governance (RMG) team in North America, helping clients secure their cloud environments, align with various frameworks and reduce risk. Nandor’s 10+ years of experience performing security assessments against various frameworks and standards, such as FedRAMP, Cloud Security Alliance (CSA), NIST CSF, PCI DSS, ISO 27001/27017, Center for Internet Security (CIS), and conducting cyber risk assessments on cloud environments.