CCSK Domain 3 Notes: Risk, Audit and Compliance

This domain covers evaluating cloud service providers (CSPs) and establishing cloud risk registries, discussing compliance requirements, and introducing tools for governance and risk management.

3.1. Cloud Risk Management

Key Concepts in Risk

• Asset: A valuable target, e.g., cloud storage bucket with customer personal information.
• Threat Actor (Attacker): The entity targeting the asset.
• Vulnerability: A weakness of an asset, e.g., a misconfigured storage bucket. This is an attack vector for the attacker.
• Risk: The potential for a negative outcome, such as personal data leaking and the company getting fined, or data becoming unavailable/corrupted.
• Control/Countermeasure: A way to reduce risk (e.g., a policy that prevents storage buckets from being accessible to a threat actor).
• Threat Modeling: The process of understanding important assets and threat actors. In a cloud world, it starts with identifying where data is stored and how it flows between cloud services.

Cloud Risk Factors (Pandemic Eleven, 2022 CSA Top Threats)

Common risk factors and categories include:

• Insufficient Identity, Credentials, Access, and Key Management.
• Insecure Interfaces and APIs.
• Misconfiguration and Inadequate Change Control.
• Lack of Cloud Security Architecture and Strategy.
• Cloud Storage Data Exfiltration.
• Accidental Cloud Data Disclosure.
• Misconfiguration and Exploitation of Serverless and Container Workloads.

Cloud Risk Management Process (Based on ENISA framework)

Risk management in the cloud uses the same methodologies as on-premises environments, but the specific actions for scope definition, environment setup, and risk evaluation/treatment change. The process includes:

1. Definition of Scope and Framework: Defining the external and internal environment, generating the risk management context, and formulating risk criteria.
2. Risk Assessment: Identify, analyze (likelihood and severity), and evaluate risks.
3. Risk Treatment: Identify options, develop, approve, and implement an action plan (mitigate, transfer, avoid, or accept), and identify residual risks.
4. Risk Acceptance.
5. Risks Communication and Awareness Consulting.
6. Monitoring & Review: Continuously monitor plans, events, and quality.

3.1.3 Assessing Cloud Services

This is a systematic process for evaluating and approving cloud services.

1. Business Requests: Understand the business need, the data involved, risk appetite, and relevant policies/regulations.
2. Review CSP Documentation: Check security/privacy policies, SLAs, Terms of Service (ToS), and use the CSA Consensus Assessments Initiative Questionnaire (CAIQ) for security controls disclosure. Also review certifications (e.g., ISO/IEC 27001, SOC 2).
3. Review External Sources: Research external reviews, reported vulnerabilities, and past security/operational incidents.
4. Map to Compliance Requirements: Align the CSP’s features/policies with organizational requirements (e.g., GDPR, HIPAA, PCI DSS).
5. Map to Data Classification: Approve providers and services based on the data types (sensitivity) they will handle. Riskier services are acceptable for less valuable or public data.
6. Define Required & Compensating Controls: Security defines required controls (e.g., configuration settings) and compensating controls (e.g., third-party tools) needed to safely use the service.
7. Approval Process: If criteria are met, approve the service and incorporate it into the cloud register. Reassess based on time, major use, or major feature changes.

The Cloud Register

• A central repository of approved cloud services, detailing what kind of data they are approved to handle at a given risk level.
• Guides internal teams on which providers and services to use for projects.
• Helps ensure data is only used with compliant services (a role in compliance).

3.2 Compliance & Audit

Compliance Definition

• Compliance: Adherence to a set of requirements from internal policies, applicable laws/regulations, sector-specific codes, standards, and best practices.
• Compliance is demonstrated through audits and conformity assessments.
• Requirements can stem from National/International standards, Industry standards (like PCI), Contracts, and Internal policies.

Jurisdictions

The complexity of cloud compliance is magnified by operating across multiple regions with different legal and regulatory frameworks. Compliance is affected by:

• Location of the cloud provider and cloud consumer.
• Location of the data subject and where the data is stored.
• Legal jurisdiction of the contract.
• Treaties or other legal frameworks between locations.

Cloud-Relevant Laws & Regulations Examples

Category	Regulation/Standard (Examples)	Key Focus
Privacy	EU GDPR, Brazil LGPD	High standard for data protection, individual rights, consent, strict penalties.
	US: CCPA, COPPA	Protect specific sectors/consumers (e.g., children’s online privacy, California consumers).
Industry/Sector	HIPAA (US)	Safeguards medical privacy/personal health information.
	GLBA (US)	Imposes requirements on financial institutions to protect consumer information.
	PCI DSS (Cross-jurisdictional)	Standard for organizations handling cardholder information; financial data protection.
EU Laws	DORA	Ensures operational resilience for critical financial market infrastructures.
	EU AI Act	Establishes regulations for the trustworthiness of AI systems.

Factors Common Across Laws

• Secure handling: Tightly controlled access to sensitive data to maintain confidentiality and integrity.
• Secure storage: Encryption, proper data retention, and deletion practices for data at rest and in transit.
• Due care: Adhering to industry best practices and security standards.
• Audit trails: Maintaining records of data processing for compliance demonstration and audits.

Adherence to Standards

• ISO/IEC 27001: International standard for Information Security Management Systems (ISMS); systematic, risk-management based approach.
• System and Organization Controls (SOC): Compliance standard focusing on five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. Important for SaaS companies.
• Security Trust Assurance and Risk (STAR) Registry: Developed by the CSA. CSPs publish adherence to standards enhanced with cloud-specific controls from the Cloud Controls Matrix (CCM).

Compliance Inheritance

• Follows the shared responsibility model.
• Allows the customer to acquire a control set from a compliant provider.
• Example: A customer using a PCI DSS-compliant infrastructure provider inherits that compliance at the infrastructure level. The customer is still responsible for their application’s PCI DSS compliance.
• Both the CSP and the customer (CSC) are audited independently.

Artifacts of Compliance

These are the materials needed for audits, serving as evidence of compliance. Customers are ultimately responsible for providing artifacts for their audits. Examples include:

• Audit Logs: Detailed records of events, actions, and changes.
• Activity Reporting: Summaries of user activities and access patterns.
• System Configuration Details: Documentation of network settings and access controls.
• Change Management Details: Records of updates, modifications, and patches.

3.3 Governance, Risk, Compliance (GRC) Tools & Technologies

The GRC tool kit includes both technical and non-technical tools.

• Non-technical: Clear documentation of responsibilities, contracts, the risk register, and frameworks/processes adapted for the business context.
• Technical: Tools to automate labor-intensive tasks.

Flashcards: https://quizlet.com/in/1086485167/ccsk-domain-3-flash-cards/?i=4jehw4&x=1qqt