Path to CCSK: Security Guidance v4 (Domains 1-7)

Jul 03, 20

The CCSK is the Cloud Security Alliance’s Certificate of Cloud Security Knowledge. It is one of the top two cloud-agnostic security certifications, along with the (ISC)² CCSP (see: CCSK vs CCSP: An Unbiased Comparison). I am currently self-studying for this certificate, and documenting that process.

There are three core documents in the body of knowledge for the CCSK(v4):

  1. ENISA report: Cloud Computing: Benefits, Risks and Recommendations for Information Security
  2. CSA Security Guidance for Critical Areas of Focus in Cloud Computing v4
  3. CSA Cloud Controls Matrix 3.0.1

This post will capture my notes from a review of the CSA Security Guidance (a 152 page document, covering 14 core domains).

Domain 1: Concepts and Architecture

Cloud computing … is, at its essence, transformative and disruptive.

  • Benefits in agility, resiliency, economy … and security
  • ties into NIST 800-145, ISO/IEC 17788/17789
  • multi-tenancy, segregation, and isolation
  • shared/pooled resources (definition)
  • key techniques: abstraction and orchestration
    • orchestration is the differentiation from virtualization

NIST Model of Cloud Computing

  • Essential characteristics: broad network access, rapid elasticity, measured service, on-demand self-service, resource pooling
  • Service models (SPIs): SaaS, based on on PaaS, based on IaaS
  • Deployment models: Public, Private, Hybrid, Community

The ISO model adds multitenancy, and replaces SPIs with a matrix of cloud capabilities and cloud service categories

IaaS: APIs wrapped into cloud management plane

  • Facility + Hardware + Abstraction + Orchestration + APIs

PaaS: adds services, integrations, middleware, and functions. Infrastructure is user-opaque

SaaS: Full applications, app/logic + data storage + API

Logical model

  • Infrastructure: The core components of a computing system: compute, network, and storage. The foundation that everything else is built on. The moving parts.
  • Metastructure: The protocols and mechanisms that provide the interface between the infrastructure layer and the other layers. The glue that ties the technologies and enables management and configuration.
  • Infostructure: The data and information. Content in a database, file storage, etc.
  • Applistructure: The applications deployed in the cloud and the underlying application services used to build them. For example, Platform as a Service features like message queues, artificial intelligence analysis, or notification services.

The metastructure is the key difference between cloud & traditional computing

Shared Responsibility Model

Saas: consumer is responsible for authorization and entitlements

PaaS: consumer is responsible for security features of databases, accounts, and authentication methods

IaaS: consumer is responsible for everything but the perimeter

The most important security consideration is knowing exactly who is responsible for what in any given cloud project.

Cloud providers should document, design, and implement security controls

Cloud consumers should build a responsibilities matrix for each cloud project

Cloud Security Models

Conceptual, Controls (CCM), Reference Architectures (NIST 500-299), Design Patterns (ISO27017)

Cloud Security Process Model:

Identify requirements → select provider, service, deployment models → define architecture → assess controls → gap analysis →design and implement controls → change management

Use CSA Consensus Assessments Initiative Questionnaire (CAIQ) to evaluate and compare cloud providers

The 13 other domains span strategic and tactical security, grouped into Governance (2-5) and Operations (6-14).

Domain 2: Governance and Risk Management

The following is the top-down hierarchy:

Governance includes the policy, process, and internal controls

Enterprise risk management includes managing overall risk for the organization, aligned to the organization’s governance and risk tolerance … not merely those concerned with technology.

Information risk management covers managing the risk to information … from financial to physical

Information security is the tools and practices to manage risk to information.

You can manage, transfer, accept, or avoid risks. An organization can never outsource responsibility for governance.

Tools of Cloud Governance: Contracts, CP assessments, compliance reporting

ERM is based on the share responsibility model … but you should consider Risk Tolerance

SaaS: visibility is solely limited to CP, contract negotiation is often possible

PaaS: APIs for data collection on governance/risk management

IaaS: most GRC are transferable, new complexities arise from orchestration and management layers

Private Cloud: hidden costs may exist for everything not contractually mandated

Supplier Assessments

documentation → security program review → legal, industry, contract obligations → evaluate in context → evaluate overall provider

Periodic, automated re-assessment

Identify and document residual risk (insurance may be one way to transfer)

Application of law dependent on: location of CP/user/data subject/servers, jurisdiction of contracts/treaties/legal frameworks

Laws

International themes: required security measures, restricted cross-boarder data transfers

Australia: Privacy Act of 1988 (updated 2017 with breach notification), Australia Consumer Law

China: 2017 cybersecurity law: report defects/bugs to users/government, data must reside in China

Japan: Act on the Protection of Personal Information, Sector/Profession specific laws. AAPI updated in 2017 to regulate 3rd parties

Russia: Data localization since 2015

EU: GDPR (2016), enforced 2018. E-Privacy Regulation (2018). Network Information Security Directive (NISD) requires information security laws from member states

GDPR: applicable to EU citizens or establishments in the EU. Specific, informed consent, record-keeping, and data subject rights. No transfer outside EU/EEA, 72 hours for breach notification. Sanctions/fines 4% of gross or <20M

NISD: member states infosec laws must cover essential services, digital service providers, and include notification requirements

U.S: sectoral approach, with federal laws such as Gramm-Leach-Bliley, HIPPA, COPPA, and state laws (CA & MA big examples). PCI-DSS

Contracts

Terms of Service, Privacy Policy, Monitoring/Testing/Updating, Contract Review

External Due Diligence: service-level, end-user, and legal agreements. privacy policies. security disclosures. proof of compliance. terms and conditions.

Third-party audits/attestations

Discovery

Federal Rules of Civil Procedures (as applicable to Electronically Stored Information)

  • possession, custody, control
  • searchability/e-discovery tools
  • preservation/”litigation hold”
  • costs/storage of data retention
    • scope of retention
    • dynamic/shared storage
  • access
  • bandwidth
  • forensic limitations
  • reasonable integrity
  • direct access generally impossible
  • ESI must be produced in standard formats
  • Provider/Client cooperation
  • subpoenas/search warrants

Domain 4: Compliance & Audit Management

  • Regulatory and jurisdictional issues abound
  • Assignment of compliance responsibilities
  • CP ability to demonstrate compliance
    • CP audit scope and affect on customer audit requirements
    • CP audit scoped features/services

Compliance validates awareness of and adherence to corporate obligations

  • Audits can prove/disprove compliance
  • Regulations may mandate compliance
  • Pass-through audits (compliance inheritance) → everything customer builds is still in scope
  • CPs may prohibit on-premises audits
  • Third-party attestations, often only available under NDA (due to audit firm requirements)
  • Artifacts: Audit logs, activity reporting, system configuration details, change management details
  • Pursuit of continuous compliance, audit, and assurance

Domain 5: Information Governance

Don’t lift and shift existing problems.

Ensuring compliant organizational use of data and information

  • multi-tenancy
  • shared responsibility: ownership versus custodianship
  • jurisdiction and data sovereignty
  • compliance, regulations, and privacy policies
  • data destruction and removal

Cloud Information Governance Domains:

  • classification
  • management policies
  • location and jurisdiction policies
  • security controls
  • authorizations
  • ownership
  • privacy
  • contractual controls

Data Security Lifecycle: create → store → use → share → archive → destroy

Entitlements define who can access data (and how)

  • Functions: read/process/store
  • Controls map possible functions to allowed functions

Domain 6: Management Plane and Business Continuity

Cloud abstracts and centralizes administrative management of resources.

Business Continuity/Disaster Recovery

  • ensuring within a given CP
  • preparing for CP outages
  • portability

Architect for failure: singular cloud assets are more fragile than their on-premises alternatives. A risk-based approach is key.

Management Plane Security:

  • console
  • APIs (REST)
  • IAM
  • Principle of least privilege
  • MFA
  • no root account usage

Building a Secure Management Plane:

  • perimeter
  • customer authentication
  • internal authentication
    • credential passing
  • authorization and entitlements
  • logging, monitoring, and alerting

Cloud BR/DC can be cost-prohibitive - make sure to ask the CP for outage statistics

BC in the CP:

Metastructure: Software defined resources and infrastructure allow for easy redeployment

Infrastructure: Most CPs offer high availability options, if necessary

Infostructure: data syncronization

Downtime can be an option

Design for real-time-switching or at a minimum for graceful failure

  • Chaos Engineering
  • SaaS has the biggest outage concerns → main mitigation is to regularly export/archive

Domain 7: Infrastructure Security

There are two layers to cloud infrastructure:

  1. Fundamental resources
  2. User managed virtual infrastructure

Cloud Network Virtualization

  • service → storage → management
  • Virtual Local Area Networks: VLANs are not designed for cloud-scale virtualization or security
    • designed for use in single-tenant networks
  • Software Defined Networking
    • complete abstraction layer on top of networking hardware
    • network controls are decoupled from the data plane
    • Implemented properly, and unlike standard VLANs, SDNs provide effective security isolation boundaries.
    • SDNs allow software definition of arbitrary IP ranges (such as RFC1918 IPs)
    • an SDN may use packet encapsulation

Challenges of Virtual Appliances

  • bottlenecks, resources/costs for performance
  • must auto-scale, be cloud-aware, handle fast rate-of-change, be IP-address agnostic, support ephemeral infrastructure

SDN Security Benefits

  • easier isolation, with flexible firewalls (often via security groups)
  • granular and dynamic (tagging), including routing and design
  • default deny, and native security functions
  • network attacks mitigated by default
  • encrypt packets while encapsulating

Microsegmentation can reduce blast radius with increased OPEX but decreased CAPEX

Software Defined Perimeter “combines device and user authentication to dynamically provision network access to resources and enhance security.”

  • SDP client + SDP controller for AuthN/AuthZ and configuring the connections + SDP gateway for terminating SDP client network traffic and enforcing policies
  • Provides broad range of criteria for network security decisions

Public Cloud Security Considerations

  • need to mitigate DDOS
  • need to baseline IPs
  • expose security controls to end users

Hybrid Cloud Security Considerations

  • avoid flattening
  • minimize connections/connectors
  • bastion/transit networks

Cloud Compute: VMs, Containers, Platform-based Workloads, Serverless

Immutable Workloads

Instances launched dynamically based on an image

  • can’t make dynamic changes to the running instance, as manual changes won’t filter down to the base image
  • to update an immutable instance, changes need to be made to the underlying image
  • hybrid immutable instances can rely on image changes for OS updates, and use other means for code updates

Security benefits

  • no patching necessary, just a simple base image update
  • disable remote logins while running, ensuring consistency
  • faster support for rolling out updates
  • easier to disable services and whitelist applications/processes
  • security testing can be managed during image creation

Requirements

  • consistent image creation process
  • security testing in image creation and deployment
  • image must be configured pre-deployment
  • troubleshooting process necessary
  • increased service catalog management complexity

Cloud Impact on Standard Workload Security Controls

  • no agent support in non-VM workloads
  • agents have heavier performance impacts
  • agent discovery is challenging
  • traditional tools can’t handle cloud velocity
  • agents may open attack surface
  • file integrity monitoring can be a more effective security control

Workload Security Monitoring and Logging

  • lack of traditional IPs
  • higher velocity and therefore cost

Vulnerability Assessment

  • notification requirements
  • benefits of defaults deny
  • increased assessment surface due to targeting images