Cloud Security

Cloud security threats

• 1. Data breaches
• 2. Unmanaged attack surface
• 3. Data loss
• 4. Insufficient access management
• 5. Shadow IT
• Shadow IT is any information technology an employee uses without IT
knowledge approval. This includes:
• Peer-to-peer collaboration tools
• Bluetooth-based sharing tools
• Messaging apps
• Personal laptops, phones, or tablets
Cloud security threats
• 6. Hijacking
• 7. Malware infections
• 8. Insider threats
• 9. Zero-day exploits
• 10. Shared technology weakness
• The Infrastructure as a Service (IaaS) and Platform as a Service (PaaS)
technology computers use to connect to the cloud allows them to share cloud
security vulnerabilities hackers can take advantage of.
Cloud security threats
• 11. Misconfigured cloud storage
• 12. Compliance
• 13. Data and privacy contract breaches
• 14. Human error
• 15. Insecure APIs
• 16. Denial of service attacks
• 17. Advanced persistent threats
Attacks and threats
6 cloud computing security best practices to
follow
• 1. Use a cloud service that encrypts
• 2. Read user agreements
• 3. Enable two-factor authentication
• 4. Don’t share personal information
• 5. Don’t store sensitive data
• 6. Do your research
Cloud Penetration Testing
• 1> We first need to determine what type of cloud; PaaS, IaaS or Saas.
• 2> Obtaining written consents for performing the penetration tests. This is requirement for
all ethical hacking.
• 3> Ensure every aspect of the infrastructure are included in the scope of testing and
generated reports.
• 4> Determine how often and what kind of testing is permitted by the Cloud Service Provider.
• 5> Prepare legal and contractual documents
• 6> Perform both internal and external penetration testing of the cloud
• 7> Perform penetration tests on the web application and services in the cloud.
• 8> Perform vulnerability scans on host available in the cloud
• 9> Determine how to coordinate with the Cloud Service Provider for scheduling and
performing the test
CCSK Outline
• Module 1: Cloud Architecture
• Module 2: Infrastructure Security for Cloud
• Module 3: Managing Cloud Security and Risk
• Module 4: Data Security for Cloud Computing
• Module 5: Application Security and Identity Management for Cloud
Computing
• Module 6: Cloud Security Operations
Module 1: Cloud Architecture
• Unit 1 - Introduction to Cloud Computing
• Unit 2 - Introduction & Cloud Architecture
• Unit 3 - Cloud Essential Characteristics
• Unit 4 - Cloud Service Models
• Unit 5 - Cloud Deployment Models
• Unit 6 - Shared Responsibilities
Unit 2 - Introduction & Cloud Architecture
• Amazon EC2 Study
• Resources pools
• Static virtualization vs. Cloud computing
• Definitions of cloud computing from NIST, ISO & IEC
• What is cloud computing
• Potential benefits of cloud computing
Ressources extension over time
Amazon Elastic Compute Cloud EC2 Story
note
• Amazon wanted to more efficiently use their resources.
• And better enable developers without having to go through hardware
procurement.
• Cloud meant they didn't have to have dedicated capacity for each
kind of system.
• Just pull what's needed out of the pool.
• Still needed enough overall capacity for peak (e.g. holidays), so a lot of
hardware wasnt being used day to day.
• Rent out the spare capacity (EC2).
• Note that public AWS was a separate project, NOT renting core capacity, but
all Amazon now runs on it.
Resource pools
Building resource pools
• There are two key technologies :
• Abstraction (virtualization) : separates resources from their underlying physical
infrastructure  allowing to create of resource pools out of those underlying assets.
• automation (orchestration) : coordinate the use of the resources in the resource pool
• Combining them leads to cloud computing
Static virtualization vs. Cloud computing
• TRADITIONAL VIRTUALIZATION
• Abstraction of compute, network, and storage from physical infrastructure.
• A human administrator manually (mostly) allocates resources.
• Not self-service. Administrator required.
• Not elastic due to lack of automation.
• CLOUD COMPUTING
• Abstraction of compute, network, storage (and more) from physical
infrastructure.
• The cloud automates and orchestrates management of the resource pools.
• Self-service. Users provision the resources from their own allocated pool
based on policies.
Cloud computing defintion
• NIST:
• Cloud computing is a model for enabling ubiquitous, convenient, on demand
network access to a shared pool of configurable computing resources (e.g.,
networks, servers, storage, applications, and services) that can be rapidly
provisioned and released With minimal management effort or service
provider interaction.
• ISO&IEC
• Paradigm for enabling network access to a scalable and elastic pool of
shareable physical or virtual resources with self-service provisioning and
administration on- demand.
What is cloud computing ?
• Cloud separates application and information resources from the
underlying infrastructure, and the mechanisms used to deliver them.
• Cloud describes the use of a collection of services, applications,
information, and infrastructure comprised of pools of compute,
network, information, and storage resources.
• These pools can be rapidly orchestrated, provisioned, implemented
and decommissioned, and scaled up or down.
• Cloud provides for an on-demand utility-like model of allocation and
consumption.
Potential benefits of cloud computing

• Economics : No capital expenditures (using public Cloud) ; Pay for use

• More Agility
• Unbounded scale
• Improved resource utilization
• Customer-controlled migration
• Resilience
Unit 3 - Cloud Essential Characteristics
• NIST Model Of Cloud Computing
• Essential Characteristics of Cloud:
• Broad Network Access
• Rapid Elasticity
• Measured Service
• On-Demand Self-Service
• Resource Pooling
• Resource Pooling and Multi-Tenancy
NIST Model of Cloud computing
Essential Characteristics of Cloud
• Broad Network Access
• Access through standard clients (Computers, Mobile devices)
• Traditional or cloud-based software services (applications, processes, etc.)
• Rapid Elasticity
• Services can be rapidly and elastically provisioned - in some cases, automatically - to quickly scale out; and rapidly
released to quickly scale in.
• Measured Service
• Automatically control and optimize resource usage
• Leveraging a metering capability at some level of abstraction
• Utility computing - you pay for what you use.
• On-Demand Self-Service
• A consumer can unilaterally provision computing capabilities, such as server time and network storage as needed
automatically, without requiring human interaction With a service provider.
• Resource Pooling
• Resources are pooled to serve multiple consumers using a multi-tenant model (Different physical and virtual resources)
• Location independence (Exact location of resources not in customer's control)
Resource Pooling and Multi-Tenancy
• Multi-tenancy is an emergent property of
resource pooling.
• Once you have a pool and allow more than
one consumer to access it, you have
multitenancy.
• For multitenancy of a shared resource pool
to work it needs a few characteristics and
enforcement capabilities; all of which
affect security
 Characteristics and enforcement capabilities
• Policy-driven enforcement
• the cloud provider and cloud consumers define how their environment should look and run using policies.
• can be implemented in a user interface or directly, using a formal policy language (code).
• Segmentation: how the provider divides the cloud up among different tenants
• Isolation: Consumers in one segment should never see anything running another segment.
• Governance:
• the overall management model of the cloud, from contracts and service levels to policies.
• Many of the other characteristics are enforcement mechanisms of governance.
• Service levels
• Service levels define Who gets what resources.
• Divvy up the resources among tenants and assure them that they will have the resources that are promised.
• Chargeback/Billing models :
• Since the cloud controller needs to know exactly Who is using what resources from the pool at all times, it is only
natural this is metered and can be used for billing purposes.
Unit 4 - Cloud Service Models
• Cloud Service Models
• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)
Cloud Service Models (SPI)
Infrastructure as a Service (IaaS)
• Provisions processing, storage,
networks, and other
fundamental computing
resources
• Consumer deploys and runs
arbitrary software that can
include operating systems and
applications
Simplified IaaS architecture

Network
Platform as a service (PaaS)
• Provider  Application development
frameworks, middleware capabilities,
and functions such as databases,
messaging, and queuing.
• Client  Deploy consumer-created or
acquired applications onto cloud
infrastructure
• Created using programming languages
and tools supported by the cloud
provider
Simplified PaaS architecture

Network
Software as a Service (SaaS)
• The consumer uses the provider' s
applications.
• Doesn’t necessarily have to run on laaS or
PaaS, but must still have the Essential
Characteristics.
• The consumer does not manage or control
the underlying cloud infrastructure
including network, servers, operating
systems, storage, or even individual
application capabilities.
Simplified SaaS architecture
Summary
• Service models describe what is actually offered to a cloud consumer- infrastructure, a
platform, or a complete application (software).
• Infrastructure as a Service provides resource pools of virtualized infrastructure, such as
compute, network, or storage pools.
• Platform as a Service further abstracts capabilities and provides resource pools of pre-
configured services where the cloud consumer doesn't manage the underlying
infrastructure. Such as databases, container platforms, message queues, and a Wide
range of other services.
• Software as a Service fully abstracts everything except the application itself. Cloud
consumers use the application but have no insight or management of the underlying
resources.
• ln real-world deployments cloud consumers often mix and match the service models to
meet project requirements.
Unit 5 - Cloud Deployment Models
• Cloud Deployment Models
• Models and Responsibilities
• Hybrid Cloud
• Logical Model
Cloud Deployment Models
• Public
• The cloud infrastructure is made available to the general public or a large industry
group and is owned by an organization selling cloud services.
• This tends to be what most organizations view as the "cloud."
• Private
• The cloud infrastructure is operated solely for a single organization.
• It may be managed by the organization or a third party, and may exist on-premises (a
solution hosted in-house and usually supported by a third-party ) or off-premises (a
solution hosted by a third-party and usually supported by a different third-party).
• Any infrastructure you are responsible for managing can be termed a "private cloud.“
• There is a lot of work to be done to turn a traditional existing data center into a
private cloud facility, but it's definitely a direction many organizations are moving
towards.
Cloud Deployment Models
• Community
• specialized Community comes together and open their clouds that are
otherwise essentially private
• Hybrid
• The cloud infrastructure is a composition of two or more clouds (private,
community, or public) that remain unique entities but are bound together by
standardized or proprietary technology that enables data and application
portability
• It connects on-premise resources to public cloud deployment
• Hybrid models are real and provide both a shorter term migration plan (so you
can support your existing data centers/private cloud, while moving some or all
of your infrastructure to another cloud platform).
Cloud deployment models & responsabilities
Hybrid Cloud cloud bursting is a configuration that's set up between a private
cloud and a public cloud to deal with peaks in IT demand.

Combine private cloud with public cloud

Logical Model
The data and information. Content in a database, i.e. storage, etc.

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 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.

The core components of a computing system: compute network, and

storage. The foundation that every else is built on. The moving parts.
Logical Model and Security
• Different security focuses map to the different logical layers.
• Application security maps to applistructure,
• data security to infostructure,
• infrastructure security to infrastructure.
• The key difference between cloud and traditional computing is the metastructure.
• Cloud metastructure includes the management plane components, which are network-enabled and
remotely accessible.
• Another key difference is that, in cloud, you tend to double up on each layer.
• Infrastructure, for example, includes both the infrastructure used to create the cloud as well as the
virtual infrastructure used and managed by the cloud user.
• In private cloud, the same organization might need to manage both;
• In public cloud the provider manages the physical infrastructure while the consumer manages their
portion of the virtual infrastructure.
• As we will discuss later this has profound implications on who is responsible for, and
manages, security
Unit 6 - Shared Responsibilities
• Shared Responsibilities Model
• Security Impact of the Service Model
• Cloud Security Considerations
 Shared Responsibilities Model
Cloud computing is a shared technology model where different organizations are frequently responsible for implementing
and managing different parts of the stack. As a result security responsibilities are also distributed across the stack.
 Shared Responsibilities
• Responsibility matrix that depends on the particular cloud provider and feature/product, the
service model, and the deployment model.
• Software as a Service: The cloud provider is responsible for nearly all security, since the cloud
user can only access and manage their use of the application, and can’t alter how the
application works.
• Platform as a Service: The cloud provider is responsible for the security of the platform, while
the consumer is responsible for everything they implement on the platform, including how
they configure any offered security features. The responsibilities are thus more evenly split.
• Infrastructure as a Service:
• Just like PaaS, the provider is responsible for foundational security, while the cloud user is responsible
for everything they build on the infrastructure.
• Unlike PaaS, this places far more responsibility on the client. For example, the IaaS provider will likely
monitor their perimeter for attacks, but the consumer is fully responsible for how they define and
implement their virtual network security.
Security Impact of the Service Model

• The Iower down the stack the cloud service provider stops, the more
security capabilities and management consumers are responsible for
implementing and ma naging themselves.
Security recommendations for the two parties
• The shared responsibility model directly correlates to two recommendations:
• Cloud providers should clearly document their internal security controls and customer
security features so the cloud user can make an informed decision. Providers should
also properly design and implement those controls.
• Cloud users should, for any given cloud project, build a responsibilities matrix to
document who is implementing which controls and how. This should also align with any
necessary compliance standards.
• The Cloud Security Alliance provides two tools to help meet these
requirements:
• The Consensus Assessments Initiative Questionnaire (CAIQ). A standard template for
cloud providers to document their security and compliance controls.
• The Cloud Controls Matrix (CCM), which lists cloud security controls and maps them to
multiple security and compliance standards. The CCM can also be used to document
security responsibilities.
Cloud Security Models
• Cloud security models are tools to help guide security decisions. We break out
the following types
• Conceptual models or frameworks include visualizations and descriptions used to explain
cloud security concepts and principles, such as the CSA logical model in this document.
• Controls models or frameworks categorize and detail specific cloud security controls or
categories of controls, such as the CSA CCM.
• Reference architectures are templates for implementing cloud security, typically
generalized (e.g. an IaaS security reference architecture). They can be very abstract,
bordering on conceptual, or quite detailed, down to specific controls and functions.
• Design patterns are reusable solutions to particular problems. In security, an example is
IaaS log management. As with reference architectures, they can be more or less abstract
or specific, even down to common implementation patterns on particular cloud
platforms.
CSA recommended models
• The CSA has reviewed and recommends the following models:
• The CSA Enterprise Architecture
• The CSA Cloud Controls Matrix
• The NIST draft Cloud Computing Security Reference Architecture (NIST Special
• Publication 500-299), which includes conceptual models, reference
architectures, and a controls framework.
• ISO/IEC FDIS 27017 Information technology – Security techniques – Code of
practice for information security controls based on ISO/IEC 27002 for cloud
services
Cloud Security Considerations
• SECURITY CONSIDERATIONS BREAK DOWN TO
• How does the underlying technology affect security controls?
• Who will consume assets, resources, information?
• Who is responsible for governance, security and compliance?
A Simple Cloud Security Process Model
Module 2: Infrastructure Security for
Cloud
• Maps to the following in Guidance :
• DOMAIN 6 Management Plane Business
• DOMAIN 7 Infrastructure Security
• DOMAIN 8 Virtualization and Containers
• Covers the following subject areas:
• Securing base infrastructure
• Management plane security
• Securing virtual hosts and networks
• laaS PaaS, Saas security
Unit 2.1 - Module Intro
• Unit 1 - Module Intro
• Unit 2 - Intro to Infrastructure Security for Cloud Computing
• Unit 3 - Software Defined Networks
• Unit 4 - Cloud Network Security
• Unit 5 - Securing Compute Workloads
• Unit 6 - Management Plane Security
• Unit 7 - Business Continuity and Disaster Recovery (BCDR)
Unit 2.2 - Intro to Infrastructure Security for
Cloud Computing
• Macro Layers
• Cloud Infrastructure Security Overview
• How IaaS works
• Public vs. Private
• Simplified Infrastructure Components
• Securing Cloud infrastructure
 Macro Layers
• In cloud computing there are two macro layers to
infrastructure:
• The fundamental resources pooled together to create a cloud.
This is the raw, physical and logical compute (processors,
memory, etc.), networks, and storage used to build the cloud’s
resource pools. For example, this includes the security of the
networking hardware and software used to create the network
resource pool.
• The virtual/abstracted infrastructure managed by a cloud user.
That’s the compute, network, and storage assets that they use
from the resource pools. For example, the security of the virtual
network, as defined and managed by the cloud user.
• Infrastructure security that’s more fundamental for cloud
providers, including those who manage private clouds, is
well aligned with existing security standards for data
centers.
Cloud Infrastructure Security Overview
How IaaS works
Public vs. Private
• If you run your own private cloud,
you're responsible for all of this.
• ln a public Cloud, you only control
what you consume, plus a little
management.
Simplified Infrastructure Components

All of these core

components need
to be securely
configured,
patched,
hardened and
maintained
Securing Cloud infrastructure
Unit Summary
• Infrastructure security includes all of the underlying physical resources and the
software, like operating systems, that runs on them.
• With private cloud, you are responsible for securing all of the hardware and
software that makes up the cloud platforms.
• With public cloud you are only responsible for what you deploy in the cloud.
• Cloud platforms, especially private cloud, are often built using common
components including operating systems, message queues, and databases. All
of these need to properly secured.
• Security Cloud infrastructure starts With proper design, then hardening of the
base systems, the various services, and eventually the management plane.
Unit 3 - Software Defined Networks
• Underlying laaS Networks
• Building Underlying Networks for Cloud
• Virtual Network
• Major Virtual Network Types
• Software-Defined Networking (SDN)
• SDN Security Benefit
• SDN Firewalls / Security Groups
 Underlying laaS Networks
• All clouds utilize some form of virtual
networking to abstract the physical network
and create a network resource pool.
• For a cloud provider (including managing a
private cloud), physical segregation of
networks composing the cloud is important
for both operational and security reasons.
• We most commonly see at least three
different networks which are isolated onto
dedicated hardware since there is no
functional or traffic overlap:
Building Underlying Networks for Cloud
• USE SEPARATE PHYSICAL • ISOLATE THE CLOUD NETWORKS
NETWORKS. FROM THE LAN.
• Don't rely on VLANs. • There should be only 2 outside
• SDN may be a good option, but connections:
depends on the version and the • The network manager to route
hardware you use... physical Internet traffic.
separation is still preferred, as • The management and web and API
server.
much for performance as security.
Virtual Network
• VIRTUAL NETWORKS AND • VIRTUAL NETWORKS MAY
SECURITY PROVIDE A SIMPLER STACK TO
• Virtual networks always run on a BUILD THE PRIVATE CLOUD.
physical network. • Greater control is afforded
• Virtual networks are subject to the through SDN.
same security concerns of a • VIRTUAL NETWORKS MAY
physical network.
include inherent (in-built)
security capabilities.
Major Virtual Network Types
• VLAN
• Leverage existing technology available in essentially all networks
• Designed for network segregation, not isolation, in single-tenant environments
• Never a substitute for physical network segregation
• Not effective as a security barrier
• Have performance and address space limitations at cloud scale
• Not designed for cloud-scale virtualization or security
• SDN
• Software Defined Networks decouple the network control plane from the underlying hardware
• Abstracts virtual networking from traditional LAN limitations
• Extremely flexible (e.g. overlapping IP address ranges on same physical hardware)
• Multiple implementations, both standard and proprietary
• Can create effective security barriers
• On the surface, an SDN may look like a regular network to a cloud user
• The underlying technologies and the management of the SDN will look nothing like what the cloud
user accesses, and will have quite a bit more complexity.
Software-Defined Networking (SDN)
• Provides a decoupled control plane that is
(potentially) easier to secure.
• OpenFlow is an example of a SDN.
• Remote access is controlled by the Administrator.
• Different flavors support different capabilities, but
generally, they can couple tightly with the Cloud
platform and possibly security tools.
• Nearly all implementations are API- enabled.
• While they may look like a regular network to the
Cloud consumer, they function VERY differently.
• Rely heavily on packet encapsulation.
 SDN Security Benefit
• Software-defined networks enable new types of security controls
• Isolation is easier. It becomes possible to build out as many isolated networks as you need
without constraints of physical hardware
• SDN firewalls (e.g., security groups) can apply to assets based on more flexible criteria than
hardware-based firewalls, since they aren’t limited based on physical topology.
• SDN firewalls are typically policy sets that define ingress and egress rules that can apply to single assets or
groups of assets, regardless of network location (within a given virtual network).
• Combined with the cloud platform’s orchestration layer, this enables very dynamic and granular
combinations and policies with less management overhead
• Default deny is often the starting point, and you are required to open connections
• Granularity of host firewall with manageability of a network appliance
• Security policies and controls based on tags and other context
• Many network attacks are eliminated by default (depending on your platforms), such as ARP spoofing and
other lower level exploits, beyond merely eliminating sniffing.
• As with security groups, other routing and network design can be dynamic and tied to the cloud’s
orchestration layer, such as bridging virtual networks or connecting to internal PaaS services.
• Additional security functions can potentially be added natively
SDN Firewalls (= Security Groups)
• POLICY-BASED
• Not necessarily tied to IP addresses
• Can include context/tagging and other intelligence
• NO ADDITIONAL HARDWARE OR SOFTWARE TO DEPLOY
• TYPICALLY DEFAULT-DENY
• Even assets in the same security group can't communicate
• APPLY ON A PER-ASSET LEVEL (INSTANCE OR PaaS OBJECT)
• But managed outside that asset. For example, if a virtual machine is compromised, it can't be
used to disable the firewall
• INTEGRATED INTO CORE SDN LOGIC
• Traffic/packets simply dropped if they don't match the policy's rules
• Tightly coupled With the cloud orchestration so fully capable of keeping up With high velocity
changes
Unit Summary
• Cloud platforms typically rely on 3 physical networks (at a minimum). One for
management, one for storage, and one for traffic between resources.
• The two mast common virtual networking technologies used in cloud are VLANs
and Software Defined Networks. For security, SDNs are preferred since they
provide better isolation and security.
• SDNs decouple the control plane from the underlying physical network and
provide tremendous flexibility. They are capable, for example, of deploying the
same IP address range across isolated networks on the same physical hardware.
• Security Groups is the common name for the firewalling built into SDNs. They
can provide the manageability of a network firewall With the granularity of a
host firewall.
Unit 4 - Cloud Network Security
• Controlling Blast Radius
• Losing Network Visibility
• Third-Party Security Tools Advantages and Disadvantages
• Bastion Networks / Accounts for Hybrid
• Software-Defined Perimeter
• Shared Responsibility
• Network Security recommendations
Controlling blast radius with virtual networks & cloud
account / subaccount / subscription isolation
• A blast radius is the distance from the source that will be affected when an explosion occurs.
• Separate accounts and virtual networks dramatically limit blast radius compared to traditional
data centers.
• Establishing multiple accounts with your provider will help with account granularity and to limit blast radius
(with IaaS and PaaS).
• running most, if not all, applications on their own virtual network and only connecting those networks as
needed
• Although there are no increases in capital expenses since cloud microsegmentation is based on software configurations, it
can increase operational expenses in managing multiple overlapping networks and connectivity.
 Losing Network Visibility

• One challenge in collecting information may be limited network visibility.

• Network logs from a cloud provider will tend to be flow records, but not full packet capture.
• Monitoring and filtering (including firewalls) change extensively due to the differences in how
packets move around the virtual network
• Resources may communicate on a physical server without traffic crossing the physical network
(e.g. 2 VM in the same physical machine).
• To compensate, you can route traffic to a virtual network monitoring or filtering tool on the
same hardware (including a virtual machine version of a network security product). You can also
bridge all network traffic back out to the network, or route it to a virtual appliance on the same
virtual network.
• Each of these approaches has drawbacks since they create bottlenecks and less-efficient routing.
• Visibility and the availability of monitoring and logging are impacted. This is especially true when
using PaaS, where commonly available logs, such as system or network logs, are often no longer
accessible to the cloud user.
 Bastion Networks / Accounts for Hybrid
• Hybrid clouds connect an enterprise private cloud
or data center to a public cloud provider, typically
using either a dedicated Wide Area Network (WAN)
link or VPN.
• Ideally the hybrid cloud will support arbitrary
network addressing to help seamlessly extend the
cloud user’s network.
• The hybrid connection may reduce the security of
the cloud network if the private network isn’t at an
equivalent security level
• One emerging architecture for hybrid cloud
connectivity is “bastion” or “transit” virtual networks
• This scenario allows you to connect multiple, different cloud you can deploy different security tools, firewall
networks to a data center using a single hybrid connection. rulesets, and Access Control Lists in the
• Second-level networks connect to the data center through bastion network to further protect traffic in
the bastion network, but since they aren’t peered to each
other they can’t talk to each other and are effectively and out of the hybrid connection.
segregated
 Software-Defined Perimeter (SDP)
• Microsegmentation (also sometimes referred to as
hypersegregation) leverages virtual network topologies to run
more, smaller, and more isolated networks without incurring
additional hardware costs that historically make such models
prohibitive
• The CSA Software Defined Perimeter Working Group has developed
a model and specification that combines device and user
authentication to dynamically provision network access to
resources
• SDP includes three components:
• An SDP client on the connecting asset (e.g. a laptop).
• The SDP controller for authenticating and authorizing SDP clients and
configuring the connections to SDP gateways.
• The SDP gateway for terminating SDP client network traffic and enforcing
policies in communication with the SDP controller.
• Network security decisions can thus be made on a wider range of
criteria than just IP packets. Especially combined with SDNs this
potentially offers greater flexibility and security for evolving
network topologies.
 Shared Responsibility
CONSUMER
• Proper virtual network design
• Implementing virtual security
controls (e.g., security groups)
• Securing their portion of the
management plane/metastructure
PROVIDER (e.g., proper IAM)
• Security of the
virtualization technology
• Exposing security
controls (e.g., security
groups)
• Disabling attack surface
(e.g., packet sniffing)
• Securing the virtual
management
infrastructure
Network Security recommendations
• Prefer SDN when available.
• Use SDN capabilities for multiple virtual networks and multiple cloud
accounts/segments to increase network isolation.
• Separate accounts and virtual networks dramatically limit blast radius compared
to traditional data centers.
• Implement default deny with cloud firewalls.
• Apply cloud firewalls on a per-workload basis as opposed to a per-network basis.
• Always restrict traffic between workloads in the same virtual subnet using a cloud
firewall (security group) policy whenever possible.
• Minimize dependency on virtual appliances that restrict elasticity or cause
performance bottlenecks
Unit 5 - Securing Compute Workloads
• Workloads in Cloud
• Impact of cloud Workloads
• ImmutabIe WorkIoads
• Immutable images and Deployment Pipelines
• Provider and Consumer Responsibilities
• Recommendations
Workloads in Cloud
• A workload is a unit of processing, which can be in a virtual machine,
a container, or other abstraction.
• Workloads always run somewhere on a processor and consume
memory.
• Workloads include a very diverse range of processing tasks, which
range from traditional applications running in a virtual machine on a
standard operating system, to GPU- or FPGA-based specialized tasks
• Nearly every one of these options is supported in some form in cloud
computing.
Compute abstraction types (1/2)
• There are multiple compute abstraction types, each with differing degrees of
segregation and isolation
• Virtual machines: Virtual machines are the most-well known form of compute
abstraction, and are offered by all IaaS providers.
• commonly called instances in cloud computing since they are created (or cloned) off a base image.
• Virtual Machine Manager (hypervisor) abstracts an operating system from the underlying hardware.
• Containers: Containers are code execution environments that run within an operating
system (for now), sharing and leveraging resources of that operating system.
• While a VM is a full abstraction of an operating system, a container is a constrained place to run
segregated processes while still utilizing the kernel and other capabilities of the base OS.
• containers launch incredibly rapidly, since they don’t need to boot an operating system or launch
many (sometimes any) new services
• Platform-based workloads
• Serverless computing
Compute abstraction types (2/2)
• There are multiple compute abstraction types, each with differing degrees of
segregation and isolation
• Virtual machines
• Containers
• Platform-based workloads : more complex category that covers workloads running on a shared
platform that aren’t virtual machines or containers, such as logic/procedures running on a shared
database platform.
• Imagine a stored procedure running inside a multitenant database, or a machine-learning job running on a
machine-learning Platform as a Service.
• Isolation and security are totally the responsibility of the platform provider
• Serverless computing: Serverless is a broad category that refers to any situation where the cloud
user doesn’t manage any of the underlying hardware or virtual machines, and just accesses
exposed functions.
• For example, there are serverless platforms for directly executing application code
• From a security perspective, serverless is merely a combined term that covers containers and platform-based
workloads
Impact of cloud Workloads
• SECURITY CONTROLS WILL VARY, BUT IN
GENERAL:
• Configure the environment/features
securely
• Application security fundamentals still
apply, but may need to be implemented at a
different layer (e.g., within the
code/workload)
• Monitoring/logging will change significantly
 Impact on traditional workload security controls
• CONTROLS MONITORING ASSESSMENT
• May not be able to run agents • Network addresses are not • Providers often limit
(E.g., AV) sufficient to identify a workload in vulnerability assessment
• "Traditional" agents may not work the cloud • Default deny networks may
properly in cloud or will impede • Logs should be offloaded quickly further limit network
performance due to more-ephemeral nature of assessment effectiveness
• Agents must be cloud aware cloud workloads • Host assessment (agents) is
• a E.g., not rely on static IP • Logging architectures should be often preferable
addresses and capable of redesigned to account for cloud • Assess images rather than
communicating across virtual topology and variable costs of instances when using immutable
network boundaries different storage tiers
• Agents should be lightweight and • Cascading log collection is
support autoscaling and generally preferred. Collect
autoregistration locally in object storage and
• Agents should not increase attack use filtering tools to migrate
surface security-sensitive logs to
• a E.g., require ports to be central collection and
open for management management
Immutable workloads enable security
• Standard/long-running
• Managed just like traditional Servers
• Automated configuration management
• The virtual machine is automatically configured using template/policy based tool
(e.g. Chef / Puppet / Ansible / Salt)
• It changes but manual changes disabled since the automation would overwrite
• Immutable
• Based on image and automatically deployed (e.g. by an auto scale group)
• Login disabled since changes won’t propagate to other instances
• You replace with new versions instead of patching/updating versions
• Very easy to harden for security (e.g. disable SSH)
Immutable images and Deployment Pipelines
 Provider & consumer responsibilities
CONSUMER
• Security settings
• Monitoring and logging
• Image asset management
• Use dedicated hosting if needed
PROVIDER and available
• Workload isolation
• All in-workload security controls
• Underlying
(e.g., patching virtual machines)
infrastructure security
• Securing the
virtualization technology
• Providing consumers
adequate security
controls
• Protecting volatile
memory
Summary : Computer security recommendations
• Leverage immutable workloads whenever possible.
• Disable remote access.
• Integrate security testing into image creation.
• Alarm With file integrity monitoring.
• Patch by updating images, not patching running instances.
• Choose security agents that are cloud-aware and minimize performance impact, if
needed.
• Maintain security controls for long-running workloads, but use tools that are
cloud aware.
• Store logs external to workloads.
• Understand and comply with cloud provider limitations on vulnerability
assessments and penetration testing.
Unit 6 - Management Plane Security

• Management Plane
• Access and Credentials
• Management Plane Security process
• Root Account Security
• Cloud IAM Management
• Privileged Users
• Monitoring and Auditing
• Recommendations
Management Plane
• Cloud abstracts and centralizes administrative management of resources. Instead of
controlling a data center configuration with boxes and wires, it is now controlled
with API calls and web consoles.
• Gaining access to the management plane is like gaining unfettered access to your
data center, unless you put the proper security controls in place
• To think about it in security terms, the management plane consolidates many things
we previously managed through separate systems and tools, and then makes them
Internet-accessible with a single set of authentication credentials.
• Centralization also brings security benefits. There are no hidden resources, you
always know where everything you own is at all times, and how it is configured
• This doesn’t mean that all the assets you put into the cloud are equally managed.
The cloud controller can’t peer into running servers or open up locked files, nor
understand the implications of your specific data and information.
Access and Credentials
• KEY FUNCTIONS
• Provisioning resources
• Starting/stopping/terminating
• Configuring resources
• SECURITY CONSIDERATIONS
• Authentication
• Access Control
• Logging/Monitoring
• THE MANAGEMENT PLANE IS THE LITERAL
KEY TO YOUR PRIVATE CLOUD. PROTECT IT
WISELY.
Management Plane Access
• Web Console
• Password
• Federation
• Enable Multi-factor authentication
• API-Level Access
• Different credentials
• HTTP request signing
• Tokens
• OAuth/SAML
Always use TLS
Management Plane Access & Credentials
• Different providers / platforms use different authentication options
• We cover some of these in more depth in the identity management section
• Web console logins are typically like logging into any other web service
• Username and password
• Maybe MFA
• APIs use multiple techniques that may or may not have credentials
different from the web console
• Http request signing (crypto using keys, API key)
• Tokens
• Oauth/saml
• All connections should always use TLS
Management Plane Security process
• Secure root account
• Manage Non-Root Users
• Enable Monitoring / Auditing
Root Account Security
• Enable hardware multi-factor authentication (MFA)
• Store in a locked, central location
• Use isolated credentials (a designated email or user account not used
for anything else)
• Use a name with a random seed if possible to reduce phishing
• If available, use account security questions
• Record and store securely
• Never use account except for emergencies
Cloud IAM Management
• Role-Based Access Control (RBAC)
• Variable granularity across providers/platforms
• Variable granularity within product lines
• Look for ability to integrate w/SSO or directory services
• Investigate third-party tools
Privileged Users
• There is an account owner (or master) with super-admin
privileges to manage the entire configuration.
• This should be enterprise-owned (not personal),
tightly locked down, and nearly never used.
• Separate from the account-owner you can usually create super-admin accounts
for individual admin use.
• Use these privileges sparingly; this should also be a smaller group since compromise or
abuse of one of these accounts could allow someone to change or access essentially
everything and anything.
• Your platform or provider may support lower-level administrative accounts that
can only manage parts of the service.
• We sometimes call these “service administrators” or “day to day administrators”.
• These accounts don’t necessarily expose the entire deployment if they are abused or
compromised and thus are better for common daily usage.
Monitoring and Auditing
• CLOUD SIDE
• Logs all API and internal activity
• Best option when available
• Pull logs to secure, central location
• PORTAL / PROXY
• Route users through a portal, they don't have direct credentials
• (-) Misses internal activity or compromised creds
• May be the only option
• CASB (Cloud Access and Security Brokers) tools often used for SaaS (we
discuss later) Host / Network Logs
 Recommendations
• The management plane is how you manage your cloud deployments. It's the biggest
difference from traditional infrastructure security, and the most critical piece to protect.
• Nearly all clouds support both web console and API access to the management plane.
When running your own cloud it's critical to make sure these are effectively locked down.
• Management planes support different kinds of credentials, all of which must be managed
securely.
• Always start by securing the root or master account since losing control of that means
losing complete control over your cloud deployment
• Enforce least privilege when setting up your other privileged users and administrators.
• Always use multifactor authentication for all cloud accounts, especially privileged users.
Unit 7 - Business Continuity and Disaster
Recovery (BCDR)
• Architect for Failure
• Key Aspects of Disaster Planning for Cloud
• Cover the Entire Stack
• BC/DR in the Cloud
Architect for Failure
• Cloud platforms can be incredibly resilient, but single cloud assets are typically less
resilient than in the case of traditional infrastructure. This is due to the inherently
greater fragility of virtualized resources running in highly-complex environments.
•  This means that cloud providers tend to offer options to improve resiliency
• Extra resiliency is only achievable if you architect to leverage these capabilities
• “lift and shift” wholesale migration of existing applications without architectural
changes can reduce resiliency.
• The ability to manage is higher with IaaS and much lower with SaaS, just like security.
For SaaS, you rely on the cloud provider keeping the entire application service up.
• With IaaS, you can architect your application to account for failures, putting more
responsibility in your hands.
• PaaS, as usual, is in the middle.
Architect for Failure
• Rule #1 : Architect for failure !
• Design for your platform(s) and don't expect existing architectures to lift and
shift without compromise
Key Aspects of Disaster Planning for Cloud
• Ensuring continuity and recovery within a given cloud provider.
• These are the tools and techniques to best architect your cloud deployment to keep
things running if either what you deploy breaks, or a portion of the cloud provider
breaks.
• Preparing for and managing cloud provider outages.
• This extends from the more constrained problems that you can architect around
within a provider to the wider outages that take down all or some of the provider in a
way that exceeds the capabilities of inherent DR controls.
• Considering options for portability, in case you need to migrate providers or
platforms.
• This could be due to anything from desiring a different feature set to the complete loss
of the provider if, for example, they go out of business or you have a legal dispute.
Cover the Entire Stack METASTRUCTURE / MANAGEMENT PLANE
• The Cloud configuration
• IAM, monitoring, and other in-cloud
management controls and compliance
artifacts
• Software Defined Infrastructure is a key tool

INFOSTRUCTURE INFRASTRUCTURE
• Leverage "resilient" provider • Core configuration (config de base)
storage (e.g. most object • Leverage platform/provider resiliency
storage is highly resilient) capabilities rather than building from
• Keep backups/snapshots scratch inside VMs
within the provider for rapid
restore APPLISTRUCTURE
• Always use Iowest cost • Understand PaaS limitations and lock-in,
storage and transfer including the historical availability of
mechanisms within and services
between providers • Downtime is nearly always an option -
have realistic standards
• Adopt Chaos Engineering
BC/DR in the Cloud
• 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.
• Business continuity for metastructure is as important as that for assets.
BC/DR in the Cloud
• 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 with your current provider.
• For super-high-availability applications, start with cross-location 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.
Risk-based approach
• Overall, a risk-based approach is key:
• Not all assets need equal continuity.
• Don’t drive yourself crazy by planning for full provider outages just because of
the perceived loss of control. Look at historical performance.
• Strive (try) to design for RTOs and RPOs equivalent to those on traditional
infrastructure.
Summary
• The first rule of cloud is to architect for failure. Since any individual virtual
resource may be less resilient, cloud provides and platforms have built in
tools to improve systemic resilience. But fail to use these and you are
more Iikely to experience an outage.
• The two major areas to focus on are resiliency within your cloud provider,
then resiliency if your provider goes down. Portability can play a role here
but don’t get so hung up on it that you become paralized and can't use all
of the capabilities of your platform or provider.
• Your BC/DR should cover the entire stack of the logical model- from the
metastructure / management plane and infrastructure to your data and
application architecture.
Module 3: Managing Cloud Security and
Risk
• Unit 1 - Module Introduction
• Unit 2 - Governance
• Unit 3 - Managing Cloud Security Risk
• Unit 4 - Compliance
• Unit 5 - Legal Issues In Cloud
• Unit 6 - Audit
• Unit 7 - CSA Tools
Unit 1 - Module Introduction

• Content in this module comes from the following domains in CSA's

Security Guidance and covers the following subject areas:
• DOMAIN 2: Governance and Enterprise Risk Management
• DOMAIN 3: Legal Issues, Contracts and Electronic Discovery
• DOMAIN 4: Compliance and Audit Management
• DOMAIN 5: Information Governance Risk and governance Legal and
compliance
Objectives
• The implications of cloud on governance, With a focus on contracts
and controls.
• How cloud affects enterprise risk management.
• Some top-level legal areas cloud tends to affect (but not legal advice).
• Managing compliance and audits for cloud deployments.
• Tools from the Cloud Security Alliance to help assess and manage risk.
Unit 2 - Governance
• A Simplified Hierarchy
• Tools of Cloud Governance
• The Contract
• From Governance to Risk
• Recommendations
Introduction
• Governance includes the policy, process, and internal controls that comprise how an
organization is run.
• Enterprise risk management includes managing overall risk for the organization,
aligned to the organization’s governance and risk tolerance. Enterprise risk
management includes all areas of risk, not merely those concerned with technology.
• Information risk management covers managing the risk to information, including
information technology. Organizations face all sorts of risks, from financial to
physical, and information is only one of multiple assets an organization needs to
manage.
• Information security is the tools and practices to manage risk to information.
Information security isn’t the be-all and end-all of managing information risks;
policies, contracts, insurance, and other mechanisms also play a role (including
physical security for non-digital information).
A Simplified Hierarchy

• In a simplified hierarchy, information security is a tool of information

risk management, which is a tool of enterprise risk management,
which is a tool of governance.
• The four are all closely related but require individual focus, processes,
and tools.
Tools of Cloud Governance
• Contracts: The primary tool of governance is the contract between a cloud provider and a
cloud customer (this is true for public and private cloud). The contract is your only
guarantee of any level of service or commitment. Contracts are the primary tool to extend
governance into business partners and providers.
• Supplier (cloud provider) Assessments: These assessments are performed by the potential
cloud customer using available information and allowed processes/techniques. They
combine contractual and manual research with third-party attestations and technical
research.
• Compliance reporting: Compliance reporting includes all the documentation on a
provider’s internal (i.e. self) and external compliance assessments. They are the reports
from audits of controls, which an organization can perform themselves, a customer can
perform on a provider (although this usually isn’t an option in cloud), or have performed
by a trusted third party. Third-party audits and assessments are preferred since they
provide independent validation (assuming you trust the third party).
The Contract

Contract
• The way you define the
relationship
• Terms of service
• Scope
• Breaches
• How you govern With
that cloud provider
From Governance to Risk
Conclusion
• Governances defines how an organization is managed.
• Contracts can extend governance and internal controls to the cloud
provider.
• The contract helps define the roles of the shared responsibilities
model.
• Supplier assessments and compliance reports help validate that the
cloud provider is meeting the expectations of the cloud consumer.
Unit 3 - Managing Cloud Security Risk
• Risk Management
• Risk Assessment
• Service Model Effects
• Deployment Model Effects
• Tradeoff Considerations
• Cloud Risk Management Tools
• Governance Risk and Considerations
 Risk Management
• ENTERPRISE RISK MANAGEMENT (ERM) • INFORMATION RISK
• Rooted in providing value to stakeholders.
• How to measure, manage, and mitigate uncertainty.
MANAGEMENT
• Aligning risk management to the
• ERM is based on the shared responsibilities
model.
tolerance of the data owner.
• Primary means of decision support
• ERM relies on good contracts and documentation
to know where the division of responsibilities for IT/security on the CIA of
and potential for untreated risk lie information assets.
• For more on risk management see
• ISO 31000:2009 - Risk management – Principles and
guidelines
• ISO/IEC 31010:2009 - Risk management – Risk
assessment techniques
• [NIST Special Publication 800-37 Revision 1](updated
June 5, 2014)
Risk Assessment
• Risk tolerance is the amount of risk that the leadership and stakeholders of an
organization are willing to accept.
• It varies based on asset and you shouldn’t make a blanket risk decision about a
particular provider; rather, assessments should align with the value and
requirements of the assets involved.
• Just because a public cloud provider is external and a consumer might be
concerned with shared infrastructure for some assets doesn’t mean it isn’t within
risk tolerance for all assets.
• Practically speaking, you will build out a matrix of cloud services along with which
types of assets are allowed in those services.
• Moving to the cloud doesn’t change your risk tolerance, it just changes how risk is
managed.
 Service Model Effects
Attention must be paid to how the Service and Deployment models affect the
ability to manage governance and risk
INFRASTRUCTURE AS A PLATFORM AS A SERVICE SOFTWARE ASA SERVICE (SAAS)
SERVICE (AAS) (PAAS)
• Closest to traditional data center • Less likely to have fully • most critical example of the need for a
• Most existing risk controls/activities negotiated contract negotiated contract.
will transfer • May be difficult to measure • Such a contract will protect the
• Key differences are contract compliance (SLAs) ability to govern or validate risk as it
metastructure/management plane • Much comes down to the relates to data stored, processed,
and abstraction / orchestration details of the PaaS and how you and transmitted with and in the
integrate application.
• Nearly fully reliant on the contract to
define governance/risk since you rely on
the provider for nearly everything
• Big variation in maturity in the market
• Often limited to what you see in the UI
Deployment Model Effects
PUBLIC CLOUD COMMUNITY/HYBRID PRIVATE CLOUD
ENVIRONMENT ENVIRONMENT ENVIRONMENT
• Reduced ability to govern • The governance strategy must • Governance/risk issues may be
ops consider the minimum common set similar to public if third-party
• Reduced ability to of controls comprised of the Cloud managed/hosted
negotiate contracts Service Provider’s contract and the • Provider may not negotiate
• Shared responsibilities organization’s internal governance contracts once terms set; e.g,.
model agreements. won't patch in timely manner
• Now have to calculate across 2 sets • Internal SLAS still used in private
of contracts
• Or are dealing With group-
negotiated contract and potential
of differing priorities
Tradeoff Considerations
• There are advantages and disadvantages to managing enterprise risk for
cloud deployments.
• These factors are more pronounced for public cloud and hosted private
cloud
• LESS
• Physical control over assets.
• Need to manage risks the provider accepts.
• MORE
• Reliance on SLA and contract.
• Requirement to manage the relationship and stay up to date.
• Assessment instead of testing.
Cloud Risk Management Tools
Governance Risk and Considerations
• 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).
Governance Risk and Considerations
• 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.
• 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.
Governance Risk and Considerations
• Cloud providers should offer easy access to documentation and reports
needed by cloud prospects for assessments, for example, the CSA STAR
registry.
• Align risk requirements to the specific assets involved and the risk tolerance
for those assets.
• Create specific risk management and risk acceptance/mitigation
methodology to assess the risks of every solution in the space
• Use controls to manage residual risks.
• If residual risks remain, choose to accept or avoid the risks.
• Use tooling to track approved providers based on asset type (e.g. linked to
data classification), cloud usage, and management.
Conclusion
• Enterprise risk management includes all-risk management for the entire
organization.
• Information risk management focuses on the risk to information, and must still
align with the risk tolerance of the data owner.
• The effort in a risk assessment should align with the value of the data. Just
because something is moving to the cloud doesn't mean you now need to treat
it as being higher-value.
• ln terms of risk, like security, laaS is most closely aligned to traditional
infrastructure, while With SaaS there is a greater reliance on the cloud provider.
• Risks in private cloud may be similar to that of public cloud if the private cloud
is hosted and/or managed by a third party.
Unit 4 - Compliance
• Compliance and Audit
• How Cloud Changes Compliance
• Compliance Inheritance
Compliance and Audit
• OBLIGATIONS ARISE FROM MULTIPLE SOURCES
• Legislation
• Broad based regulation
• Industry specific regulation
• Contracts
• COMPLIANCE AND AUDITS
• Compliance validates awareness of and adherence to corporate obligations
• Audits are a key tool for proving (or disproving) compliance.
How Cloud Changes Compliance
• The cloud customer is always responsible for compliance but may now also rely on the
provider.
• Cloud customers will rely more on third-party assessments.
• Many cloud providers are certified for various regulations and industry requirements, such
as PCI DSS, SOC1, SOC2, HIPAA, best practices/frameworks like CSA CCM, and
global/regional regulations like the EU GDPR. These are sometimes referred to as pass-
through audits. A pass-through audit is a form of compliance inheritance
• Many cloud providers offer globally distributed data centers running off a central
management console/platform. The cloud management plane / metastructure may span
(s’étendre) jurisdictions, while the data/assets don't; this must be integrated into
compliance activities.
• Not all cloud providers are equal With regards to compliance, and not all services from a
single provider are always within the same audit / attestation / certification scope.
 Compliance Inheritance
With compliance inheritance the cloud provider’s infrastructure is out of scope for a
customer’s compliance audit, but everything the customer configures and builds on
top of the certified services is still within scope.
Compliance and Audit Recommendations
• 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 towards this model.
• This is especially true in cloud computing, where both the provider and
customer tend to be in more-constant flux and are rarely ever in a static
state.
 Compliance and Audit Recommendations
• Cloud providers should:
• Clearly communicate their audit results, certifications, and attestations with
particular attention to:
• The scope of assessments.
• Which specific features/services are covered in which locations and jurisdictions.
• How customers can deploy compliant applications and services in the cloud.
• 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 commonly needed evidence and artifacts of compliance,
such as logs of administrative activity the customer cannot otherwise collect
on their own.
 Compliance and Audit Recommendations
• 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.
Conclusion
• Compliance is a tool to ensure organizations are meeting corporate
obligations.
• Audits are how we validate compliance, and they can be performed
internally or externally using third parties.
• Cloud changes compliance because it now becomes a shared responsibility
between the cloud consumer and the provider.
• Compliance inheritance is the principle that if a cloud provider's service is
compliant with a regulation/standard, then cloud consumers can build
compliant services/applications using that service.
• But it does not guarantee compliance since the cloud consumer can still build a
non-compliant application on top of a compliant service.
Unit 5 - Legal Issues In Cloud
• Laws & Implementing Regulations
• APAC Region (Asia-Pacific)
• EMEA Region (Europe Middle East & Africa)
• Americas Region
• Industry Standards
• Contracts
• Conclusion
Laws & Implementing Regulations
• Despite a common theme, countries on all continents have developed data
protection regimes that occasionally conflict with each other.
• As a result, cloud providers and cloud users operating in multiple regions struggle to
meet compliance requirements.
• In many cases, the laws of different countries might apply concurrently, in
accordance with the following:
• The location of the cloud provider
• The location of the cloud user
• The location of the data subject
• The location of the servers
• The legal jurisdiction of the contract between parties, which may be different than the
locations of any of the parties involved
• Any treaties or other legal frameworks between those various locations
 Asia-Pacific (APAC)

APAC-Australia
• Two key laws provide protection to consumers of cloud services
• Privacy Act of 1988
• 13 Australian Privacy Principles (APPs)
• Applies to private, not-for- profits With 3+ million AUD, private healthcare providers
• Australian Consumer Law (ACL)
• Entities must provide notification when breaches occur
• ACL protects against false/misleading contracts and failed breach
notifications
• Privacy Act applies to Australian customers even if CSP (Cloud Service
provider) is based elsewhere
 Asia-Pacific (APAC)

APAC-China
• 2017 Cyber Security Law governs network operators
• Data localization requires certain data is stored in the country
• Privacy landscape still in transition
 Asia-Pacific (APAC)

APAC-JAPAN
• Act on the Protection of Personal Information (APPI) requires private
sector to protect personal information
• Prior consent is required for data transferred to 3rd party outside the
country
• Consent is not required if certain standards are met as outlined by the
Personal Information Protection Commission
APAC-RUSSIA
• Russian data protection laws require consent for most data processing
• Companies are required to store personal data of Russian citizens
within Russia
EMEA - EUROPEAN UNION &
EUROPEAN ECONOMIC AREA
• 2018 General Data Protection Regulation (GDPR)
• Member states can supplement the GDPR
• 2002 Directive on Privacy and Electronic Communications (new E-
Privacy Regulation to replace it)
• Network Information Security Directive (NIS Directive)
• Protects critical infrastructure and essential services
 GENERAL DATA PROTECTION
RECULATION (GDPR)
• APPLICABILITY
• Applies to data controllers/ processors in the EU/EEA, or activities within and outside the EU/EEA
• Applies to controllers/ processors outside the EU/EEA if monitoring or processing data owned by an individual in the EU/EEA
• ACCOUNTABILITY OBLIGATIONS
• Entities must keep records of data processing activities
• Must develop and operate according to "privacy by design" and "privacy by default" principles
• DATA SUBJECTS' RIGHTS
• Subjects have a right to know what info an entity has about them
• Right to object to how personal data is used
• Right to data erasure/corrections
• Right to be forgotten
• CROSS-BORDER DATA TRANSFER RESTRICTIONS
• Personal data cannot transfer across borders unless a country has similar data and privacy rights.
• Entities outside of the EU/EEA must show an adequate level of protection
• BREACHES OF SECURITY
• Entities must report a security breach to the Supervisory Authority or Authorities and data subjects when the breach meets certain
thresholds.
• SANCTIONS
• Violators are subject to sanctions, up to 4% of global gross income, or up to EUR 20 million .
NETWORK INFORMATION SECURITY
DIRECTIVE (NIS)
• Requires that EU/EEA member states' laws govern network and
information security requirements for digital and essential services:
i.e., e-commerce, search engines, cloud computing.
• Providers outside the EU offering services inside the EU are
accountable.
• Providers must notify agencies if an incident substantially impacts the
provision of a service.
EMEA - COUNTRIES OUTSIDE EU/EEA
• Countries With similar protection laws such as GDPR or 1995 EU Data
Protection Directive: Dubai, Israel, Morocco, Senegal, South Africa,
Qatar.
Americas – Central & South
• Argentina, Chile, Colombia, Mexico, Peru and Uruguay have laws
inspired mainly by the European directive 95/46/EC
• Many laws refer to the APEC Privacy Framework
Americas – CANADA
• Personal Information Protection and Electronic Documents Act
(PIPEDA)
• Applies to entities subject to federal jurisdiction and all provincial
jurisdictions
Americas – UNITED STATES
• No single national law for data protection and regulation.
U.S. Federal Laws
• Among others, Gramm-Leach-BIiIey Act (GLBA), Accountability Act of
1996 (HIPAA), Children's Online Privacy Protection Act of 1998
(COPPA) all regulate privacy and information security.
• Companies must adopt reasonable security measures around
personal data.
• Organizations are responsible for subcontractors' actions.
U.S. STATE Laws
• State laws around data security apply to any entity that
collects/processes data of an individual living in that state, regardless
of where data is stored.
• Most state laws that address information security require a written
contract between the entity and the service provider mandating use
of reasonable security measures.
 LAWS, AGENCIES, & LITICATION
• BREACHES OF SECURITY
• Private or gov't entities must notify individuals of security breaches.
• PRIVACY LAWS
• California Consumer Privacy Act (CCPA) protects data for individuals, families and devices. In effectJan.
2020 sign ificant implications.
• FEDERAL & STATE AGENCIES
• Federal Trade Commission (FTC) & state attorneys general also enforce accountability in entities
around privacy and security practices.
• These decrees give guidance around protection of personal information.
• LITIGATION & E-DISCOVERY
• Litigation in the US differs from other countries
• Each party can obtain documents through "discovery"
• Discovery is complex when documents are hosted in the cloud due data dispersion.
• Cloud will become the repository of most electronically stored information
• Providers and their clients must plan how to identify all documents
Industry Standards
• Created by private organizations, industry standards are not laws.
• Many industry standards related to the cloud are produced by these
organizations on the right side of the screen.
Contracts
• BEFORE ENTERING NEGOTIATIONS
• Due diligence of your own entity
• Due diligence of other party
• Does the service allow your company to meet its objectives & still be in compliance?
• CONTRACT TERMS
• Pricing
• Allocation of Risk/ResponsibiIity
• Termination
• Representation and Warranties
• Data/IP Ownership
• Data Location
• SLA
• Privacy/Privacy Level Agreement (PLA)
• DURING PERFORMANCE
• Monitoring
• Preparing for termination and transition
• Unintended contract
• Closing
Conclusion
• Due to the nature of the cloud, it has become easy to transfer data
across the globe. However, the ease of movement of the data makes
it susceptible to be caught under numerous legal systems.
• It is therefore important to appreciate the Wide variety - as well as
the amazing similarities - between the laws that govern cloud
services.
• ln the past 10 years, the number of countries having privacy or
security laws has more than doubled, and the number of laws that
govern the privacy or security of company data and personal data has
skyrocketed.
Conclusion
• GLOBAL TRENDS:
• Protection of privacy and allowing individuals to have some control over the collection and use of
their personal data.
• There is a concern for the security of personal data and company data. A significant number of laws
require the adoption of formal security policies
• Countries and states are recognizing that security breach occurs, far a variety of reasons - state
actors, hackers, disgruntled employees, negligence or inadvertent error. These breaches should be
notified to be affected parties. Numerous new require prompt disclosures to individuals and
government agencies.
• There is a concern that data laws many not be equivalent from state to state and countries are
establishing barriers to prevent the transfer of data ta those that do not offer "adequate
protection".
• Finally like for any other relationship, things are better recorded in writing. Contracts are important.
Cloud contract can be tricky because too easy to sign when they are just posted on a website far
the customer to click an "l agree". Make sure you read them carefully to and understand the terms.
Unit 6 - Audit
• Audit
• Previous Audit Results (Third- Party Attestations)
• Artifacts of Compliance
• Assessment Frequency
Audit
• Different types of audit / assessment / attestation have different
focuses and Vary across providers.
• Attestations are legal statements and providers may be required by
the auditor to have an NDA (nondisclosure agreement) With the
customer before releasing.
• Customers will likely be limited in their ability to assess (and
vulnerability assess) providers.
• These could be a security risk to the provider. Cloud providers should
have a rigorous portfolio of compliance attestations to support their
customers.
Previous Audit Results
(Third- Party Attestations)
• Be aware of when the
audit was performed,
the scope of the audit,
and the audit results.
Artifacts of Compliance
• Artifacts are the logs, documentation, and other materials needed for
audits and compliance; they are the evidence to support compliance
activities.
• Both providers and customers have responsibilities for producing and
managing their respective artifacts.
• Collecting and maintaining artifacts of compliance will change when
using a cloud provider
Artifacts of Compliance
• ln cloud, assessing risk is collecting all audit evidence and can be challenging
• Understand requirements for logging and what kinds of data to collect
• Change in management logs are common artifacts you need.
• Map what you need to your cloud provider
• Collect admin activity to have logs of changes
• Store artifacts in a central repository. Build architecture to store centrally.
• Key places to focus on:
• Management place
• Configuration pieces
• Adding more logging in applications
• System logs need to be pushed to a different location, ex: object storage on cloud provider
• Core of audit considerations:
• Make sure you know what you need to collect to meet compliance obligations
• Evaluate what you can get from your cloud provider and how to get it
• Store in a central location
• Build in extra logging to compensate for places where you lose visibility
Assessment Frequency
• Due to the evolving nature of a cloud service, more frequent
assessment is required.
• Consider STAR/CAIQ/CCM and other CSA tools and programs.
Conclusion
• Different types of audits and assessments have different focuses, and
even when the same name is used can have different focus and scope
across cloud providers.
• Cloud providers often limit the kinds of assessments their customers can
use since some of these, like vulnerability assessments, can't be
distinguished from real attacks without being constrained.
• Ensure you know the scope, results, and timing (dates) of previous
audits. Not all audits on a provider’s website are necessarily up to date
or cover the service under consideration.
• Cloud consumers are responsible for maintaining their own artifacts of
compliance for their own audits, such as log files.
Unit 7 - CSA Tools
• CCM
• CAIQ
• STAR
• STARWatch
CLOUD CONTROLS MATRIX (CCM)
• The CSA CCM is a controls framework for organizations to operate securely when
Cloud services are utilized.
• Intended for cloud providers, SaaS providers, other end-user services in the cloud
• Designed by SMEs across industries.
• Provides security principles to providers to define and apply best practices
• Assists customers to assess cloud providers
• Standardized guidance on control objectives in cloud-based IT systems
• Based on CSA Security Guidance, research artifacts, Mobile WG
• Addresses intra- and inter- org challenges by delineating (defining) control
ownership
CLOUD CONTROLS MATRIX (CCM)
• Normalizes security expectations, cloud taxonomy, and security
measures implemented in cloud supply chain
• Guides security efforts in vetting (examining) cloud providers, building
proposal requests and operational risk assessment.
• Aids in internal and external assessments and audits, and can submit
to CSA STAR registry
CCM tool
Structure of CCM Tool
• 16 security control domains
• identity and access management, encryption key management, human resources, Mobile Security
• Each domain has a set of control objectives
• overall there are 133 control objectives across all of the domain
• Controls map to
• one or more of the six high-level categories of architectural relevance to physical, Network, compute,
storage, application and data and
• one or more of the applicable delivery models SaaS, PaaS and IaaS
• Supplier relationship: Service provider and/or Tenant-consumer
• other industry accepted security standards regulations and Frameworks
• AICPA, BITS shared assessments, BSI Germany, Canada PIPEDA, CCM V1.X, COBIT 4.1, COBIT 5.0, COPPA, CSA
Enterprise Architecture, CSA Guidance, ENISA IAF, 95/46/EC, FedRAMP Security Controls, FERPA, GAPP, HIPAA /
HITECH Act, HITRUST CSF, ISO/IEC 27001:2013, ISO/IEC 27002:2013, ISO/IEC 27017:2015, ISO/IEC 270018:2015, ITAR,
Jericho Forum, Mexico - Federal Law on Protection of Personal Data Held by Private Parties, NERC CIP, NIST SP800-53
R3, NIST SP800-53 R4 App J, NZISM, ODCA UM: PA R2.0, PCI DSS , Shared Assessments 2017 AUP, IEC 62443-3-3:2013,
C5, NIST 800-53 R4 Moderate, AICPA TSC 2017, FedRAMP R4 Moderate.
Consensus Assessments Initiative Questionnaire
(CAIQ)
• The CSA CAIQ assesses the security postures of a cloud service provider.
• Originated in the CSA Consensus Assessments Initiative WG
• CAIQ is a simplified distillation of issues and control specs associated With cloud security
• Simple tool to standardize approach of validation of a cloud provider’s security postures
• Companion to CSA security guidance and CCM
• Helps cloud SPs assess security postures, provides single location for details about their
information security program
• Streamlines compliance assessments and improves communication between cloud SPs, business
partners, and customers
• Allows customers and auditors to ask the right questions of cloud provider about their security
posture.
• Consumers can use completed CAIQs to assess provider control and risk models.
• Helps organizations build assessment processes prior and during to engagement With cloud
provider.
CAIQ tool
Structure of CAIQ tool
• A series of 295 yes or no control assertion question
• Divided into security domain and the security control, in the same
manner of CCM
• A question ID extends the control ID for each question
• Assessment answers have three options yes no and not applicable
• A notes field to add any additional information or comment that
should be provided
• Same standards mapping as CCM
 Security, Trust & Assurance Registry (STAR)
• Promotes security governance, assurance and compliance in the cloud.
• Based on CSA OCF (Open Certification Framework), CCM and CAIQ WGs.
• Third-party resources that encompasses key principles of transparency, auditing and standards
harmonization
• Initially launched in 2010, STAR addresses lack of transparency in a burgeoning market
• Supports cloud customers in evaluation and selection process, and helps cloud SPS to easily
communicate security posture to their customers.
• Offers self-assessment, third-party certification, and continuous auditing
• Increases security by requesting adherence to best practices by implement CCM
• Details security postures of security providers, offers assurance by indicating level of compliance
of CSA best practices
• Offers layered approach to cloud assurance: self-assessment, third-party certification and
attestation, and continuous auditing
• Customer can access security documentation for cloud providers from a single trusted repository
Security, Trust & Assurance Registry (STAR)

• https://cloudsecurityalliance.org/star/registry
• It's free and accessible to the public
• Multiple entries to search information about a particular organization
• Click on the links to go ahead and download any of their supporting
documentation
• Gain access to caiq and any other certification and supporting
documentation posted to start
• The registry is also accessible via API.
• Access is currently to CSA members
• content in a machine-readable format accessible through a simple application
programming interface
 STARWatch
• The CSA STARWatch is an SaaS application to help cloud providers manage compliance
With CSA STAR requirements.
• STARWatch grew out of CSA's desires to manage CAIQ responses more effectively
• Facilitates adoption and implementation of CCM and CAIQ and streamlines provider
and consumer compliance efforts
• Allows users to create, edit, import, and export CAIQs
• Intended for users of cloud services, cloud SPs, IT auditors, security solution providers
and consultants
• Provides multi-user access to CCM and CAIQ in database format
• Incorporates a maturity model to measure the evolution of security posture of the org
• Assistance in mapping security requirements to those of CSA
• Relevant mapping to relevant standards/regs
Conclusion
• The Cloud Controls Matrix is a list of cloud security controls mapped by domain and
aligned to various regulatory frameworks.
• The CCM is an excellent tool for evaluating your cloud security controls and is useful
to both cloud providers and consumers.
• The Consensus Assessment Initiative Questionnaire is a standard set of security
questions for cloud providers. It allows cloud consumers to directly compare
providers, and allows providers to reduce the need to respond to non-standard RFPs.
• The Cloud Security Alliance Guidance (which this training is based on) tells you how
to implement your controls, while the CCM tells you which controls to implement.
• The Star Registry and StarWatch tool serve as central repositories for cloud provider
security documentation, including the CAIQ.
Module 4: Data Security for Cloud
Computing
• Unit 1 - Module Introduction
• Unit 2 - Cloud Data Storage
• Unit 3 - Securing Data In The Cloud
• Unit 4 - Encryption For IaaS
• Unit 5 - Encryption For PaaS & SaaS
• Unit 6 - Encryption Key Management
• Unit 7 - Other Data Security Options
• Unit 8 - Data Security Lifecycle
Objectives
• Understand the different cloud storage models
• Define security issues for data in the cloud
• Assess the role and effectiveness of access controls.
• Learn different cloud encryption models.
• Understand additional data security options
• Introduce data security lifecycle.
Unit 2 - Cloud Data Storage
• Cloud Data Storage Differences
• Cloud Data Storage Types
• Data Dispersion
• Controlling Data Migration to the Cloud
• CASB (Cloud Access Security Broker)
• Protecting Data as it Moves
Cloud Data Storage Differences

• All data is eventually stored on a physical device, but cloud platforms use
multiple types of data storage virtualization to abstract and build storage
pools.
• These are not necessarily off-the- shelf technologies that map to traditional data
storage virtualization, like SAN/NAS, that are well known.
• This storage may be expressed/exposed like traditional storage but under
the hood is quite different.
• Just like SDN
• Security focuses on access controls, encryption, and proper
configuration.
Cloud Data Storage Types
• VOLUME
• Essentially, virtual hard drives for VMs/instances.
• OBJECT
• Resilient file storage via API
• Object storage is similar to a file system. Not a normal filesystem, but closer to a
"database for files."
• DATABASE
• Includes relational and non-relational (NoSQL, key/value storage systems, file system
based databases (e.g. HDFS)).
• Not merely a DB running on an instance.
• APPLICATION / PLATFORM
• content delivery network (CDN), files stored in SaaS, caching, and other novel options..
Data Dispersion (Bit Splitting)
• The process takes chunks of data, breaks them up, and then stores
multiple copies on different physical storage to provide high
durability.
• Data stored in this way is thus physically dispersed. A single file, for
example, would not be located on a single hard drive.
Controlling Data Migration to the Cloud
• Before securing the data in the cloud, most
organizations want some means of managing what
data is stored in private and public cloud providers.
• To start, define your policies for which data types are
allowed and where they are allowed, then tie these
to your baseline security requirements.
• Then identify your key data repositories. Monitor
them for large migrations/activity using tools such as
Database Activity Monitoring (DAM) and File Activity
Monitoring (FAM). DAM: Database Access Monitoring
• To detect actual migrations, monitor cloud usage and CASB: Cloud Access Security Brokers
any data transfers. you can do this with the help of DLP: Data Loss Prevention
URL : Uniform Resource Locator Filtering
the following tools: CASB, URL filtering, DLP
Controlling Data Migration to the Cloud
• CASB: Cloud Access and Security Brokers (also known as Cloud Security Gateways)
• discover internal use of cloud services using various mechanisms such as network monitoring,
integrating with an existing network gateway or monitoring tool, or even by monitoring DNS queries.
• It can offer monitoring of activity on approved services through API connections (when available) or
inline interception (man in the middle monitoring).
• Many support DLP and other security alerting and even offer controls to better manage use of
sensitive data in cloud services (SaaS/PaaS/and IaaS).
• URL filtering: While not as robust as CASB, a URL filter/web gateway may help you
understand which cloud services your users are using (or trying to use).
• DLP: If you monitor web traffic (and look inside SSL connections) a Data Loss Prevention
(DLP) tool may also help detect data migrations to cloud services.
• However, some cloud SDKs and APIs may encrypt portions of data and traffic that DLP tools can’t
unravel, and thus they won’t be able to understand the payload.
CASB (Cloud Access Security Broker)
• known as Cloud Security Gateways
• Discover: What cloud services are employees using?
• DNS records
• URL filters
• Secure web gateways
• Monitor :
• Auditability of cloud services
• SaaS especially lacks the ability to monitor what employees are doing
• CASB monitors traffic from outside
• Protect
• Provides security controls
• Generic or more specific controls for cloud providers
• How do these tools connect?
• API - Cloud providers don't always have access to APIs
• Inline/Proxy - Via CASBs in the cloud. Problematic, last resort if API doesn't work, but can work for SaaS
• Inline/Local
Protecting Data as it Moves

• Encrypt before you send it

• Encrypt as you transfer it
• Encrypt as you transfer it, through a proxy
Conclusion
• Data stored in the cloud may use a range of different abstraction and virtualization technologies.
To the user these may look Iike traditional storage, but behind the scenes the mechanisms will
be quite different. However, all data is still eventually stored on physical media,
• Volume storage is virtual hard drives, while object storage is like a database for files that is
managed via APIs. Databases in the cloud may be multitenant and don’t necessarily work like on-
premise database systems. Cloud applications may store files using a Wide range of techniques
that the cloud consumer has no insight into.
• Most cloud storage uses data dispersion for resilience, which breaks our traditional ties to
knowing the physical location of drives.
• Tools Iike CASB, DLP, and even URL filtering can help us visualize or manage data migrating to the
cloud.
• Data can be encrypted before migrating to the cloud, protected in transit With TLS or other
network encryption, and may be consolidated and encrypted through an on-premise proxy,
especially for cloud backed backups.
Unit 3 - Securing Data In The Cloud
• Access Controls
• Entitlement Matrix
 Access Controls
• Always your first data security control
• Access controls should be implemented with a minimum of three layers:
• Management plane: controls managing access of users that directly access the cloud platform’s management plane.
• For example, logging in to the web console of an IaaS service will allow that user to access data in object storage. Fortunately, most cloud
platforms and providers start with default deny access control policies.
• Public and internal sharing controls: If data is shared externally to the public or partners that don’t have direct access to the
cloud platform, there will be a second layer of controls for this access.
• Application level controls: When building the applications, design and implement controls to manage access.

• Options for access controls will vary based on cloud service model and provider-specific features.
• Granularity and implementation vary massively between platforms, services, and technologies
• The finer-grained the access controls the better for security, but the harder for manageability
• Create an entitlement matrix based on platform-specific capabilities.
• An entitlement matrix documents which users, groups, and roles should access which resources and functions.
• It's critical to create platform-specific entitlement matrices
Entitlement Matrix

This is a simplified entitlement matrix example.

Conclusion
• Access controls are the most fundamental security control, even in
cloud computing.
• There is massive variability of available access controls between cloud
providers, and cloud storage may offer new categories of controls,
such as sharing, beyond those in more- traditional storage.
• An entitlement matrix is the documentation of authorizations. It
defines Who should be allowed to not only access data, but what they
should be allowed to do With it.
Unit 4 - Encryption For IaaS
• Encryption Layers
• Cloud Encryption System Matrix
• Volume Storage Encryption
• Instance-Managed Encryption
• Object Storage Encryption
 Encryption Layers

Encrypting higher in the application stack is often best for

discreet data, while Iower-level encryption, like volume, is
better for bulk data

IaaS volumes can be encrypted using different methods,

depending on your data.
• Volume storage encryption
• Object and file storage
Storage (At-Rest) Encryption and
Tokenization
• Encryption options vary tremendously based on service model, provider, and
application/deployment specifics.
• Key management is just as essential as encryption
• Encryption and tokenization are two separate technologies.
• Encryption protects data by applying a mathematical algorithm that
“scrambles” the data
• Tokenization takes the data and replaces it with a random value. It then stores
the original and the randomized version in a secure database for later recovery.
• Tokenization is often used when the format of the data is important (e.g.
replacing credit card numbers in an existing system that requires the same
format text string).
Cloud Encryption System Matrix
• There are three components of an encryption system: data, the encryption
engine, and key management.
• The data is, of course, the information that you’re encrypting.
• The engine is what performs the mathematical process of encryption.
• Finally, the key manager handles the keys for the encryption.
• The overall design of the system focuses on where to put each of these
components.
• When designing an encryption system, you should start with a threat model.
• For example, do you trust a cloud provider to manage your keys? How could
the keys be exposed? Where should you locate the encryption engine to
manage the threats you are concerned with?
 Volume Storage Encryption

• Two methods
• Instance-managed encryption: The
encryption engine runs within the instance,
and the key is stored in the volume but
protected by a passphrase or keypair.
• Externally managed encryption (preferred):
The encryption engine runs in the instance,
but the keys are managed externally and
issued to the instance on request.
Instance-Managed Encryption
Object Storage Encryption
• There are 3 methods:
• Client-side encryption: When object storage is used as the back-end for an
application (including mobile applications), encrypt the data using an
encryption engine embedded in the application or client.
• Server-side encryption: Data is encrypted on the server (cloud) side after
being transferred in. The cloud provider has access to the key and runs the
encryption engine.
• Proxy encryption: In this model, you connect the volume to a special instance
or appliance/software, and then connect your instance to the encryption
instance. The proxy handles all crypto operations and may keep keys either
onboard or externally.
Conclusion
• There are multiple layers where you can encrypt each with benefits and
complications. Encrypting higher in the application stack is often best for
discreet data, while Iower-level encryption, like volume, is better for bulk data.
• Encryption systems are composed of the data, the encryption engine, and the
key management, where you place these determines the architecture and
affects the security of the system.
• Whenever possible, you want to separate the encryption key from the data
and the encryption engine.
• For object storage encryption, you can encrypt the data on the client site, the
server side (using multiple techniques), or even through storage proxies (which
we frequently see used for site backups).
Unit 5 - Encryption For PaaS & SaaS
• Encrypting PaaS
• Example - Application Encryption
• Encrypting SaaS
• Proxy Encryption for SaaS
Encrypting PaaS
• PaaS encryption varies tremendously due to different PaaS platforms.
• Application layer encryption: Encrypt within your app code or Encrypt before sending to the
platform
• Database encryption: Data is encrypted in the database using encryption that’s built in and
is supported by a database platform like Transparent Database Encryption (TDE) or at the
field level.
• Other: These are provider-managed layers in the application, such as the messaging queue.
There are also IaaS options when that is used for underlying storage.
• When you control the code, you can always encrypt there, which is also more
portable.
• Volatile memory and swap files may be issues; understand your platform specifics.
• If you are the provider, use per- customer keys as much as possible.
Example - Application Encryption
Encrypting SaaS
• SaaS providers may use any of the options previously discussed.
• It is recommended to use per customer keys when possible, in order
to better enforce multitenancy isolation.
• The following options are for SaaS consumers:
• Provider-managed encryption: Data is encrypted in the SaaS application and
generally managed by the provider.
• Proxy encryption: Data passes through an encryption proxy before being sent
to the SaaS application.
Proxy Encryption for SaaS
Not going to break as much: Breaks:
• Basic text file • Data that needs analysis
• Word doc

Encryption Proxy breaks TLS, interprets HTML, and

selectively encrypts/decrypts

Consider provider-level encryption first!

Conclusion
• Platform as a Service encryption will depend almost completely on the kind of
platform and options supported by your provider. For workloads though, you
can nearly always program your own encryption at the application layer.
• When encrypting in your application, you can handle the encryption in your
own code or send it off to an external encryption server or service.
• For Software as a Service you only have two options - rely on your provider's
supported encryption, or use a third-party encryption proxy that sits as a man
in the middle.
• Saas encryption proxies may introduce new security concerns due to requiring
you to break any network encryption to the cloud provider. They may also
break application functionality. However, there are still valid use cases, albeit
limited.
Unit 6 - Encryption Key Management
• Cloud Key Management Techniques
• Provider Key Management & BYOK
• Cloud Key Management Options
Cloud Key Management Techniques
• The main considerations for key management are performance, accessibility, latency, and
security
• Can you get the right key to the right place at the right time while also meeting your security and
compliance requirements?
• There are four potential options for handling key management:
• HSM/appliance: Use a traditional hardware security module (HSM) or appliance-based key manager,
which will typically need to be on-premises, and deliver the keys to the cloud over a dedicated
connection.
• Virtual appliance/software: Deploy a virtual appliance or software-based key manager in the cloud.
• Cloud provider service: This is a key management service offered by the cloud provider. Before
selecting this option, make sure you understand the security model and SLAs to understand if your
key could be exposed.
• Hybrid: You can also use a combination, such as using a HSM as the root of trust for keys but then
delivering application-specific keys to a virtual appliance that’s located in the cloud and only manages
keys for its particular context.
Provider Key Management & BYOK
• Some providers build encryption into their platform. By default they
typically manage keys for you.
• E.g., The checkbox to encrypt an S3 bucket, or the default encryption on
BoWDropbox.
• Some providers now allow you to manage your own keys.
• "Bring your own key ' (we also call these customer managed keys).
• varying degrees of security. Some are fully under your control, others the
provider can technically get to, but they provide separation of duties.
Cloud Key Management Options
• PROVIDER MANAGED
• Cloud provider manages encryption
• The customer owns the keys, but the provider may manage
• This isn't necessarily insecure, it all depends on the provider's security controls
• Providers should be very transparent about these
• 3rd-PARTY / CUSTOMER MANAGED
• Encryption management and data storage is handled by cloud provider
• You own the keys, provider may manage
• Keys may be exposed at some level, but typically data encryption keys, not master keys
• Often good option for SaaS and PaaS
• CUSTOMER KEY MANAGER
• You manage keys and encryption
• Virtual appliance option
• Good for laaS, doesn't integrate well With cloud provider services
• Can cause issues w/PaaS and not an option With SaaS
• HSM
• ln hybrid cloud scenarios you can own your physical HSM
• Can be available via API
Conclusion
• Proper key management is essential to effective encryption, and we have more options at
our disposal in cloud computing.
• HSMs and physical appliances may be offered by your cloud provider, or you can look at
deploying software or virtual appliances in the cloud, connecting to existing hardware over
a hybrid connection, or even leverage new options like a key management service from
your cloud provider or a third party.
• Providers offer a range of key management options, from the provider completely
managing the keys, to allowing you to manage your own keys in their environment or even
provide keys as needed.
• Bring Your Own Key will work differently on different providers and services, with varying
levels of relative security.
• The final choice will come down to your risk and threat models. Once you know the risk you
are trying to prevent, can evaluate the technical options in your provider and platform of
choice. Remember, not all data needs the same level of security so you don’t always need
to default to the most secure option.
Unit 7 - Other Data Security Options
• Data Security Architecture
• Additional Controls
• Data Masking
Data Security Architecture
• Application architecture impacts data security.
• The features your cloud provider offers can reduce the attack surface, but make sure to demand
strong metastructure security.
• For example, gap networks by using cloud storage or a queue service that communicates on the
provider’s network, not within your virtual network.
• That forces attackers to either fundamentally compromise the cloud provider or limit themselves to
application-level attacks, since network attack paths are closed.
• An example would be using object storage for data transfers and batch processing, rather than
SFTP-ing, to static instances.
• Another is message queue gapping—run application components on different virtual networks
that are only bridged by passing data through the cloud provider’s message queue service. This
eliminates network attacks from one portion of the application to the other.
 Data Security Architecture
• This example shows using a private network for
data processing without ever exposing servers
to the Internet.
• Good architectural decisions can optimize
security
• Performance advantages: no servers running,
no instances, no virtual machines - you only pay
for batch jobs, archival storage, & object storage
• There's no attack path
Additional Controls
More than encryption
• AUDITING / MONITORING / ALERTING
• Collect at the provider / metastructure/management plane and the data storage level when possible
• PROVIDER SPECIFIC CONTROLS
• Various providers and platforms have their own data security controls that may not fit our categories
• DATA LOSS PREVENTION
• Typically a Saas (and maybe PaaS) priority, dont see much in laaS
• CASB often best bet, and may integrate With dedicated DLP tools
• Cloud providers sometimes offer basic DLP in the platform (mostly file collaboration products)
• ERM DRM
• Full DRM (digital rights management) not often seen and not a cloud-specific issue. Will break most
SaaS (such as browser preview or collaboration, unless there is some sort of integration)
• Providers may offer DRM-like capabilities (e.g., user + device + content restrictions)
• E.g. a policy that only allows certain users to view a file in a web browser, while other users can download and/or edit
the content.
Data Masking

• These are techniques to protect data used in development and test

environments, or to limit real-time access to data in applications.
• Test data generation: This is the creation of a database with non-sensitive test
data based on a “real” database. It can use scrambling and other
randomization techniques to create a data set that resembles the source in
size and structure but lacks sensitive data.
• Dynamic masking: Dynamic masking rewrites data on the fly, typically using a
proxy mechanism, to mask all or part of data delivered to a user. It is usually
used to protect some sensitive data in applications, for example masking out
all but the last digits of a credit card number when presenting it to a user.
Conclusion
• Integrating PaaS and other new cloud architectural options into applications and
data storage may allow cloud consumers to shift more security burden onto cloud
providers and reduce the stack’s attack surface.
• Good activity monitoring and alerting are important to cloud data security, and
providers may also support a variety of additional security controls.
• Data Loss Prevention tends to be more useful for SaaS and may be integrated into
CASB tools.
• Traditional DRM/ERM isn't necessarily useful for cloud, but some SaaS/PaaS
services may have "DRM-like" capabilities such as sharing or view controls that
provide similar protections.
• Data masking is critical for test data generation and to ensure production data is
not exposed in development environments.
Unit 8 - Data Security Lifecycle
• How to use the lifecycle
• Data Security Lifecycle
• Location and Access
• Mapping Elements to the Lifecycle
• Entitlement matrix
• Mapping Controls
Data Security Lifecycle
How to use the lifecycle
• The Data Security Lifecycle is a tool to help you model your security
controls.
• Don't get too granular or it will be too complex to model. Focus on
the big picture.
• Use the lifecycle to determine where data flows.
• Then use it to map how data *can* be used, and how it *should* be
used.
• When you can do something that shouldn't be allowed, that’s where
you need to insert a security control.
Data Security Lifecycle
Location and Access
• The simple data security
lifecycle does not address
location or how data is
accessed
• External use reliant on
different controls
• Internal and external access
usually have different security
policies
• You have *multiple* data
security lifecycles
Mapping Elements to the Lifecycle

• Access to data, processing and storage are basic cloud functions

• Allowable functions change per location/user
• Controls differ upon user/location
• Internal and external access usually have different security policies
• You have *multiple* data security lifecycles, since you may have *multiple* location.
Simple Entitlement matrix
Mapping Controls
Recommendations
• 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 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.
Recommendations
• 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.
Conclusion
• The Data Security Lifecycle is a tool to help us visualize how our data is used and
exposed, and can be helpful in determining where to place security controls.
• The lifecycle itself consists of 6 phases from creation to destruction, but practically
speaking data will bounce between all the phases as it is used. However, each phase
has a distinct set of potential associated security issues and controls.
• Data will move between various locations, and be accessed using a variety of devices,
users, and services. Mapping these can be useful in designing security controls.
• Depending on the location, phase, etc., the data will have a set of potential actors,
functions, and locations. We map those against what we want to allow, and use
security controls to pare the potential list to the allowed list.
• We can encode this into an entitlement matrix which we then implement as security
controls, such as access controls.
Module 5: Application Security and Identity
Management for Cloud Computing
• Unit 1 - Module Introduction
• Unit 2 - Secure Software Development Life Cycle (SSDLC)
• Unit 3 - Testing & Assessment
• Unit 4 - DevOps
• Unit 5 - Secure Operations
• Unit 6 - Identity & Access Management Definitions
• Unit 7 - IAM Standards
• Unit 8 - IAM In Practice
Unit 1 - Module Introduction
• Content in this module comes from the following domains in CSA's
Security Guidance:
• Domain 10: Application security
• Domain 12:Identity Entitlement and Access Management
• Domain 14: Related Technologies
• Covers the following subject areas:
• SSDLC
• Dev Ops
• Immutable
• IAM
Objectives
• Discover how application security differs in cloud computing.
• Review secure software development basics and how those change in
the cloud.
• Leverage cloud capabilities for more secure cloud applications.
Unit 2 - Secure Software Development Life
Cycle (SSDLC)
• How Cloud Changes AppSec
• Application Security Phases
• SSDLC Frameworks & Guidance
• Cloud impact on SSDLC
• Secure Design and Development
• Threat Modeling Example
• Mapping to Countermeasures
How Cloud Changes AppSec
• Application security encompasses an incredibly complex and large
body of knowledge
• Application security is also evolving at an incredibly rapid pace as the
practice of application development continues to progress and
embrace new processes, patterns, and technologies
• Cloud computing is one of the biggest drivers of these advancements
• Cloud computing mostly brings security benefits to applications, but as
with most areas of cloud technology, it does require commensurate
changes to existing practices, processes, and technologies.
 How Cloud Changes AppSec

• Higher baseline security : providers, especially major IaaS and PaaS providers, have significant economic incentives
to maintain higher baseline security than most organizations
• Responsiveness / agility : APIs and automation provide extensive flexibility to build more responsive
security programs at a lower cost than in traditional infrastructure
• Isolated environments: Cloud applications can also leverage virtual networks and other structures, including PaaS, for hyper-
segregated environments
Opprtunities

• Independent VMs for microservices: Security is further enhanced by the use of micro-service architectures.
Developers can instead deploy more, smaller virtual machines, each dedicated to a function or service.
• Elasticity : Elasticity enables greater use of immutable infrastructure. When using elasticity tools like auto-scale groups, each
production system is launched dynamically based on a baseline image, and may be automatically deprovisioned without
human interaction
• DevOps : automation of application development and deployment
• Unified interface: unified interface (management interface and APIs) for infrastructure and application services (when using
PaaS) provides a more comprehensive view and better management compared to the traditional disparate systems and
devices (load balancers,servers, network devices, firewalls, ACLs, etc.), which are often managed by different groups.

• Limited visibility: Visibility and the availability of monitoring and logging are impacted
• Increased application scope: The management plane/metastructure security directly affects the security of any
Challenges

applications associated with that cloud account

• Changing threat models: The cloud provider relationship and the shared security model will need to be included in
the threat model, as well as in any operational and incident response plans.
• Reduced transparency: There may be less transparency as to what is going on within the application, especially as it
integrates with external services. For example, you rarely know the entire set of security controls for an external
PaaS service integrated with your application
 Application Security Phases
• Due to the range of
frameworks and
differences in
terminology, the Cloud
Security Alliance breaks
these into larger “meta-
phases” to help
describe the relatively
standard set of
activities seen across
the frameworks.
SSDLC Frameworks & Guidance
• Security is vital in a time in which businesses and
organizations are the targets of cyberattacks daily.
• Secure software development can help your team
maintain users’ and employees’ privacy, avoid
costly data breaches, comply with current cyber
regulations, and more.

• Several Frameworks & guidance

• Microsoffs Security Development Lifecycle
• NIST 800-64
• ISO/IEC 27034
• Other organizations, including OWASP (Open Web
Application Security Project) and a variety of
application security vendors, also publish their own
lifecycle and security activities guidance.
Microsoft’s Security Development Lifecycle
Cloud impact on SSDLC
• Cloud computing affects every phase of the SSDLC, regardless of which particular SSDLC you use
• This is a direct result of the abstraction and automation of cloud computing, combined with (in
the public cloud) a greater reliance on an external provider.
• Specifically:
• The shared responsibility model means there is always some reliance on the cloud provider for some
aspects of security, even in a very bare-bones IaaS-based application.
• There are large changes in visibility and control. When running mostly on IaaS it might just be a lack of
network logs, but as you move into PaaS it may mean a loss of server and service logs. And, it will all vary
based on provider and technology.
• Different cloud providers have different capabilities in terms of features, services, and security, which must
be accounted for in the overall application security plan.
• The management plane and metastructure may now be within the application security scope, especially
when the application components communicate directly with the cloud service.
• There are new and different architectural options, especially, again, as you consume PaaS.
• The rise and impact of DevOps, which we cover later in this Domain
Cloud impact on SSDLC
Cloud impact on SSDLC
• More reliance on cloud provider under shared responsibilities model
• Large changes to visibility and control
• Highly variable difference between providers and platforms
• Management plane/metastructure now within scope of application
security
• New architectural options, especially With PaaS
• DevOps // Not cloud-specific, but highly correlated
Secure Design and Development
Secure Design and Development
• Training:
• Three different roles will require two new categories of training. Development,
operations, and security should all receive additional training on cloud security
fundamentals as well as appropriate technical security training on any specific cloud
providers and platforms used on their projects
• Define:
• The cloud user determines the approved architectures or features/tools for the
provider, security standards, and other requirements
• Security standards should include the initial entitlements for who is allowed to
manage which services in the cloud provider, which is often independent of the
actual application architecture.
• It should also include pre-approved tools, technologies, configurations, and even
design patterns
Secure Design and Development
• Design:
• During the application design process, especially when PaaS is involved, the focus for security in cloud
is on architecture, the cloud provider’s baseline capabilities, cloud provider features, and automating
and managing security for deployment and operations.
• We find that there are often significant security benefits to integrating security into the application
architecture since there are opportunities to leverage the provider’s own security capabilities.
• For example, inserting a serverless load balancer or message queue could completely block certain
network attack paths.
• Develop:
• Developers may need a development environment with administrative access to the cloud
management plane so that they can configure networks, services, and other settings.
• This should never be a production environment or hold production data.
• Developers will also likely use a CI/CD pipeline, which must be secured—especially the code repository.
• If PaaS is used, then developers should build logging into their application to compensate, as much as
possible, for any loss of network, system, or service logs.
Secure Design and Development
• Test:
• Security testing should be integrated into the deployment process and pipeline.
• Testing tends to span this and the Secure Deployment phase, but leans towards
security unit tests, security functional tests, Static Application Security Testing (SAST),
and Dynamic Application Security Testing (DAST).
• Organizations should also rely more on automated testing in cloud.
• Infrastructure is more often in scope for application testing due to “infrastructure as
code,” where the infrastructure itself is defined and implemented through templates
and automation.
• As part of security testing, consider requiring flagging features for security-sensitive
capabilities that may require deeper security review, such as authentication and
encryption code.
Threat Modeling Example
Mapping to Countermeasures
STRIDE is a model for identifying computer security threats. It
provides a mnemonic for security threats in six categories
STRIDE
Unit Summary
• The secure software development lifecycle (SSDLC) is a structured
process for ensuring security needs are met throughout application
development processes.
• There are multiple frameworks, such as those from Microsoft and
OWASP.
• Cloud will impact each phase of the lifecycle, from training all the way
into operations. Changes in visibility and more reliance on the shared
responsibilities model are constant threads.
• When modeling application threats for cloud deployments, some risk
will be greater and some less. Threat modeling is a great way to evaluate
these differences.
Unit 3 - Testing & Assessment
• Testing Overlap
• Secure Development and Testing
• Secure Deployment and Testing
• Vulnerability Testing in the Cloud
Testing Overlap
• Testing is not isolated to secure development or secure deployment,
these phases overlap and there aren't walls between them.
 Testing type (1/2)
• There are multiple kinds of application security tests integrated into development and
deployment:
• Code Review:
• Manual activity, not necessarily integrated into automated testing, but CI/CD pipeline might impose a manual gate.
• Review itself doesn’t necessarily change for cloud, but there are specific areas that need additional attention.
• Any application communication with the management plane (e.g., API calls to the cloud service) should be
scrutinized (inspected), especially early in the project.
• Security team can focus on ensuring that only the least privilege entitlements are enabled.
• Anything related to authentication and encryption is also important for additional review.
• The deployment process can then be automated to notify security if there are any modifications to these portions.
• Unit testing, regression testing, and functional tests:
• Standard tests used by developers in their normal processes.
• Security testing can and should be integrated in these to ensure that the security features in the application
continue to function as expected.
• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
 Testing type (2/2)
• There are multiple kinds of application security tests integrated into
development and deployment:
• Code Review
• Unit testing, regression testing, and functional tests
• Static Application Security Testing (SAST):
• should ideally incorporate checks on API calls to the cloud service.
• should also look for any static embedded credentials for those API calls, which is a growing
problem.
• Dynamic Application Security Testing (DAST):
• DAST tests running applications and includes tests such as web vulnerability testing and fuzzing.
• DAST may be limited and/or require pre-testing permission from the provider.
• With cloud and automated deployment pipelines it is possible to stand up entirely functional test
environments using infrastructure as code and then perform deep assessments before approving
changes for production.
Secure Development and Testing
Secure Development and Testing
• Code review
• Manual
• Usually implemented at gate/checkpoint for only specific functionality
• E.g., Cloud auth and encryption
• Unit testing, regression testing, and functional tests:
• Standards of dev testing
• Should be used to test for security capabilities / functions
• SATS
• Static Application Security Testing
• Add checks for Cloud credentials and API calls
Secure Development and Testing (cloud
impact/change)
• Cloud doesn't change the kind of testing, but does change some of
what is tested
• E.g., need to account for cloud API calls, environment, PaaS integration
• ln laaS, you have substantial restrictions to test the cloud
infrastructure, but you are free to test the app, database, etc.
• ln PaaS, you are free to test your app code and all the rest is restricted.
• ln Saas, you would need to rely on 3rd-party testing done on behalf of
the providers.
• ln laaS you are generally free to test without permission at the app
level, but not in PaaS/Saas
Secure Deployment and Testing
Secure Deployment and Testing
• Dynamic Analysis (Fuzzing)
• You can expect mostly free reign (sovereignty) to fuzz in laaS, but not same
level PaaS and Saas
• Vulnerability Scanning
• Must define what level in the stack the scan targets
• External scans may require Cloud provider permission
• Penetration Testing
• Often requires close coordination With Cloud provider (depending on scope)
Impact on Vulnerability Assessment
• Vulnerability assessment can be integrated into CI/CD pipelines and implemented in
cloud fairly easily,
• It nearly always requires compliance with the provider’s terms of service.
• There are two specific patterns we commonly see.
• Full assessments against images or containers as part of the pipeline in a special testing area of the
cloud (a segment of a virtual network. The image is only approved for production deployments if it
passes this test.
• Test entire infrastructures by building a test environment using infrastructure as code.
• In both cases production is tested less, or not at all, since it should be immutable and
exactly resemble the test environment.
• Organizations can also use host-based vulnerability assessment tools, which run locally
in a virtual machine and thus do not require coordination with or permission of the
cloud provider.
Impact on Penetration Testing
• Limits on performing penetration tests without the permission of the
cloud provider.
• The CSA recommends adapting penetration testing for cloud using the
following guidelines:
• Use tools and companies with cloud-specific features and experience; tools
and background don't translate from traditional to cloud as well in these
areas
• Include developers and cloud admins within scope of penetration tests Since
they are often the weak link
• For multitenant apps, allow pen testers authorized access to try and break
tenancy isolation
Vulnerability Testing in the Cloud
Conclusion
• Secure software development involves a range of security testing. All of
these are impacted by cloud computing.
• With static analysis you should place a greater emphasis on looking for
stored cloud credentials, as well as the proper configuration of API usage.
• Dynamic analysis and vulnerability assessment may require permission
from your cloud provider.
• New vulnerability analysis options, such as scanning in a deployment
pipeline or using host- based agents, are often better used for cloud.
• Assessing the configuration of the cloud environment should now be
within scope for an application security assessment.
Unit 4 - DevOps
• Devops
• Continuous Integration
• Immutable and Infrastructure as Code
Devops Cycle
Devops
• No single definition, but typically refers to changing culture and process around
continuous integration / delivery and automation.
• Security benefits:
• Greater standardization
• Dev/Test/Prod are all based on the exact same source files, which eliminates any deviation from known-good
standards
• Automated testing
• a wide variety of security testing can be integrated into the CI/CD pipeline
• Improved auditing and change management
• CI/CD pipelines can track everything
• Leverage automation techniques to improve security operations
• SecDevOps/DevSecOps and Rugged DevOps: These two terms are emerging to describe the integration of security
activities into DevOps
• Immutable:
• CI/CD pipelines can produce master images for virtual machines, containers, and infrastructure stacks very quickly
and reliably.
Continuous Integration
 Immutable and Infrastructure as Code
• Infrastructure stack, virtual machines
(instances), and containers all defined in
templates in version control
• Environments and servers/containers rebuilt
based on updated configurations
• Changes never made manually in production since
the next approved change would overwrite
• Entire environment fully consistent, easy to
rebuild roll-back
• Can remove ability to log into production
• E.g., disable SSH on instances
• Massive security benefits- consistency, control,
auditability
Conclusion
• There are many definitions of Devops, but a key defining characteristic is the
use of continuous integration and/or continuous delivery (CI/CD).
• Continuous integration pipelines support consistency and integrated security
testing.
• Devops also supports immutable deployments, where instead of updating
things or making manual changes we replaced them from a known good
definition.
• This supports security through consistency and allowing us to even remove
the need to log into production assets.
• There is a lot more to Devops, but integrated security testing, consistency due
to use of CI/CD, and immutable are some of the key security benefits.
Unit 5 - Secure Operations
• Secure Operations
• How Cloud Impacts Application Design & Architecture
• Serverless
• Application Security
 Secure Operations
• When an application is deployed into production, security
activities continue. Many of these are covered in other areas,
especially in Domain 7 (Infrastructure), Domain 8 (Containers),
Domain 11 (Data), and Domain 12 (Identity and Access
Management). Domain 10 (Application) is also concerned.
• Lock down the management plane very tightly for production
• Even when using immutable infrastructure, actively monitor
for changes at both cloud and app stack levels
• Don't neglect ongoing testing
• Cloud configuration is now within scope of change
management
• WAF
• Must auto scale, be embedded in the workload, or be cloud-hosted
(filter traffic before it hits your application)
• RASP (Realtime Application Security Protection) an emerging option
How Cloud Impacts Application Design &
Architecture
How Cloud Impacts Application Design &
Architecture
• Segregation by default:
• Applications can easily be run in their own isolated cloud environments.
• Depending on the provider, this could be a separate virtual network or account/sub-account.
• The organization can open up wider rights in development accounts while running highly-restrictive production accounts.
• Immutable infrastructure:
• immutable infrastructure is becoming increasingly common in cloud, for operational reasons.
• Security can extend these benefits by disabling remote logins to immutable servers/containers, adding file integrity monitoring, and
integrating immutable techniques into incident recovery plans.
• Increased use of micro-services:
• In cloud computing, it is easier to segregate out different services onto different servers (or containers), since, you no longer need
to maximize utilization of physical servers and auto-scale groups can assure application scalability
• Since each node does less, it’s easier to lock down and minimize the services running on it.
• Add some overhead to secure the communications between all the micro-services and ensure that any service discovery,
scheduling, and routing is also configured securely.
• PaaS and “serverless” architectures:
• With PaaS and “serverless” setups (running workloads directly on the cloud provider’s platform, where you don’t manage the
underlying services and operating system) there is great potential for dramatically reducing the attack surface.
• This is only if the cloud provider takes responsibility for the security of the platform/serverless setup and meets your requirements
 Serverless
• Provider takes an more security responsibilities
• removes the dayto-day responsibility for keeping these secure
from the cloud user, but never obviates their ultimate
accountability for security
• Communicating via API on provider's platforn-reduces
network attack paths
• The attacker is limited to attempting API calls or HTTPS traffic
and can’t port scan, identify other servers, or use other common
techniques
• Enables software defined security (security automated
With APIS and code)
• E.g. automating cloud incident response, automating dynamic
changes to entitlements, and remediation of unapproved
infrastructure changes
• May enable event-driven security (events in the cloud
trigger execution of security code)
Application Security
• 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.
Conclusion
• Secure operations is all about keeping your application secure once is
deployed into production.
• When using cloud, the management plane is a concern and the cloud
configuration is now within scope for change management.
• WAF will need to be adjusted to account for the different deployment
options, like autoscaling, used in cloud.
• New cloud architectural options, such as serverless and micro services may
offer security benefits, and are increasingly common.
• Serverless puts more responsibility onto the cloud provider, leveraging the
shared responsibilities model to reduce the customer's attack surface and
scope of security operations.
Unit 6 - Identity & Access Management
Definitions
• Identity Access Management: Concepts and Definitions
INTRO TO CSA IDENTITY TERMS
• ENTITY: Discrete types that will have Identity, these are to Users,
Devices, Code, Organizations and Agents
• IDENTITY: The unique expression of an entity within a given namespace.
• IDENTIFIER: The means by which an Identity can asserted, usually using
crypto tokens for digital identities
• ATTRIBUTES: Facets of an identity (e.g., org. unit or IP address)
• PERSONA: Expression of an identity with attributes that indicates
context. E.g., a developer logged into a given project
INTRO TO CSA IDENTITY TERMS
• ROLE: Has multiple meanings. Typically used to indicate a persona or
subset. E.g„ "developer" vs. "admin"
• AUTHENTICATION: The process of confirming an identity. aka. Authn
• MULTIFACTOR AUTHENTICATION: Use of multiple factors in
authentication (e.g., username + password + token)
• ACCESS CONTROL: Restricting access to a resource, Access
management is the corresponding process
• AUTHORITATIVE SOURCE: The "root" source for an identity, such as a
directory server
INTRO TO CSA IDENTITY TERMS
• AUTHORIZATION: Allowing an identity access.
Authz
• ENTITLEMENT: Mapping an identity to an
authorization
• FEDERATED IDENTITY MANAGEMENT: The process
of asserting an identity across different systems
• IDENTITY PROVIDER: The trusted source of the
identity in federation
• RELYING PARTY: The system that relies on an
identity assertion from an identity provider
Conclusion
• It is important to understand the foundational terminology for identity and
access management (IAM)
• At the heart is an entity, which is a person, device, or other "thing" that will be
given access.
• An identity is the expression of that entity within a namespace, such as an email
address or username for a given system.
• Entities prove their identity by providing identifiers during authentication.
• After being authenticated, users may be granted access to objects or actions.
This is called an authorization, and an entitlement is a specific approval.
• Federated identity is critical for cloud computing because it allows us to manage
identities across different systems.
Unit 7 - IAM Standards
• How IAM is Different for Cloud
• IAM Standards for Cloud
• OpenlD Example
IAM and Cloud
• Identity and access management is always complicated
• At the heart we are mapping some form of an entity (a person, system, piece of code) to a
verifiable identity associated with various attributes (which can change based on current
circumstances), and then making a decision on what they can or can’t do based on entitlements.
• In cloud computing, the fundamental problem is that multiple organizations are now managing
the identity and access management to resources, which can greatly complicate the process.
• For example, imagine having to provision the same user on dozen of different cloud services
• Federation is the primary tool used to manage this problem, by building trust relationships
between organizations and enforcing them through standards-based technologies
• The migration to cloud is an opportunity to build new infrastructure and processes on modern
architectures and standards
• Moving to federation at scale with multiple internal and external parties can be complex and
difficult to manage due to the sheer mathematics of all the variables involved.
How IAM is Different for Cloud
IAM Standards for Cloud
 IAM Standards for Cloud
• Security Assertion Markup Language (SAML) 2.0
• OASIS standard for federated identity management that supports both authentication and authorization.
• It uses XML to make assertions between an identity provider and a relying party.
• Assertions can contain authentication statements, attribute statements, and authorization decision
statements.
• SAML is very widely supported by both enterprise tools and cloud providers but can be complex to initially
configure.
• OAuth
• IETF standard for authorization that is very widely used for web services (including consumer services).
• OAuth is designed to work over HTTP and is currently on version 2.0, which is not compatible with version 1.0.
• OAuth 2.0 is more of a framework and less rigid than OAuth 1.0
• It is most often used for delegating access control/authorizations between services.
• OpenID
• Standard for federated authentication that is very widely supported for web services.
• It is based on HTTP with URLs used to identify the identity provider and the user/ identity
• The current version is OpenID Connect 1.0 and it is very commonly seen in consumer services.
 IAM Standards for Cloud
• eXtensible Access Control Markup Language (XACML)
• Standard for defining attribute-based access controls/authorizations.
• It is a policy language for defining access controls at a Policy Decision Point and
then passing them to a Policy Enforcement Point.
• It can be used with both SAML and OAuth since it solves a different part of the
problem
• i.e. deciding what an entity is allowed to do with a set of attributes, as opposed to handling
logins or delegation of authority.
• System for Cross-domain Identity Management (SCIM)
• Standard for exchanging identity information between domains.
• It can be used for provisioning and deprovisioning accounts in external systems
and for exchanging attribute information.
Choice of an identity protocol
• No protocol is a silver bullet that solves all identity and access control
problems.
• Identity protocols must be analyzed in the context of use case(s).
• For example, Browser-based Single Sign On, API keys, or mobile-to-cloud
authentication could each lead companies to a different approach.
• The key operating assumption should be that identity is a perimeter in
and of itself, just like a DMZ.
• So any identity protocol has to be selected and engineered from the
standpoint that it can traverse risky territory and withstand malice
OpenID connect
Conclusion
• IAM for cloud computing relies on federated identity due to the requirement to
manage authentication and authorization between the Cloud consumer and the
Cloud provider.
• The most widely supported and used federation standard for connecting
enterprises With their cloud providers SAML.
• Oauth and OpenlD are web-centric federation standards often used by both
consumers and organizations.
• Federation involves multi-step cryptographically supported processes to connect
an Identity Provider (the source for the identity) and the Relying Party (mast often
the cloud provider, where authorizations occur).
• Typically the identity provider handles authentication, then the relying party
handles authorization (enforcing what someone can actually do).
SAML
• Le SAML (Security Assertion Markup Language) est un standard ouvert, basé sur
XML et développé par OASIS (consortium international œuvrant pour la
standardisation de formats de fichiers ouverts).
• Il définit le processus permettant à un utilisateur d’accéder à plusieurs
applications via une authentification unique (Single Sign-On ou SSO).
• SAML est déjà bien implanté en entreprise de par son efficacité et son
ancienneté.
• Il reste cependant assez lourd et contraignant (cela en raison de l’utilisation du
XML) comparé à OpenID Connect.
• Toutefois, si une organisation a déjà une partie de ses infrastructures utilisant
SAML, il n’est pas forcément intéressant de partir sur d’autres technologies : le
retour sur investissement ne serait que trop faible, voire nul.
SAML
1.Un utilisateur veut se connecter à une application de son entreprise à partir de
son navigateur web.
2.L’application demande au navigateur web une authentification de type SAML.
3.Le navigateur va alors rediriger l’utilisateur vers le fournisseur d’identité qui va
analyser la demande. Si l’utilisateur n’est pas authentifié, il devra saisir son
identifiant et son mot de passe. Dès que celui est identifié et authentifié, le
fournisseur d’identité va générer une réponse SAML qui prouvera son identité (le
fichier XML présenté plus haut, appelé aussi « token » ou « jeton » en français).
4.Le fournisseur d’identité envoie le jeton au navigateur web.
5.Le navigateur redirige le jeton vers l’application.
6.Si la vérification réussit, l’utilisateur est connecté à l’application.
OAuth2
• Malgré qu’ils souvent associés, SAML et Oauth sont deux standards
avec des utilités différentes
• SAML est un standard de fédération d’identité,
• OAuth est un standard de délégation d’autorisation.
• OAuth, dans sa version 2, est un standard ouvert basé sur JWT (JSON
Web Token, standard permettant l’échange sécurisé de jetons grâce à
une vérification de l’intégrité des données) permettant à des services
d’accéder à des données d’autres services via une autorisation du
propriétaire de celles-ci et sans communication de mot de passe.
• OAuth2 est donc un très bon outil pour sécuriser l’accès aux API d’une
entreprise, mais en aucun cas un standard de fédération d’identité.
 OAuth2
• But: application A accède aux données de l’utilisateur stockées dans l’application
B, sans que celui-ci ne communique son identifiant et son mot de passe
1. L’utilisateur va demander à l’application A de contacter l’application B.
2. Il est redirigé par l’application A vers l’application B et il s’authentifie sur cette
dernière.
3. L’application B va alors demander à l’utilisateur s’il autorise ou non
l’application A à accéder aux ressources hébergées dans l’application B. Si
l’utilisateur l’autorise, l’application B va envoyer un code d’autorisation au
navigateur web de l’utilisateur.
4. Ce code est ensuite communiqué à l’application A.
5. Dès lors, le code est envoyé de l’application A vers la B pour obtenir en
échange un jeton d’accès. Ce jeton a pour objectif d’éviter de communiquer
les codes d’accès de l’utilisateur de l’application B à l’application A. On gagne
ainsi en sécurité et en simplicité.
6. Le jeton d’accès est transmis à l’application A.
7. L’application A peut ainsi demander, via le jeton d’accès, d’accéder aux
données de l’application B.
OpenID connect
• OpenID Connect est une couche d’identité au-dessus du protocole
OAuth 2.0, permettant, à l’instar de SAML, de réaliser une
authentification fédérée.
• Là où OAuth se base sur un principe de délégation d’autorisation,
OpenID Connect se base sur un principe de fédération
d’authentification.
• Pour le fonctionnement, on retrouve en grande partie les mécanismes
d’OAuth. La différence principale réside dans la demande de jeton
d’accès. Là où OAuth 2.0 va communiquer un jeton d’accès pour
accéder aux données, OpenID Connect va communiquer un jeton
d’identité pour accéder aux applications
 OpenID connect
1. L’utilisateur veut se connecter à l’application.
2. Il est redirigé par celle-ci vers le serveur
d’authentification, puis il s’authentifie.
3. Le serveur d’authentification va envoyer un code
d’autorisation au navigateur web de l’utilisateur.
4. Ce code est communiqué à l’application.
5. Le code est envoyé de l’application vers le serveur
d’authentification pour obtenir en échange un
jeton d’identité (jeton au format JWT).
6. Le jeton d’identité est transmis à l’application.
Celle-ci a donc la garantie de la part du serveur
d’authentification que l’utilisateur peut accéder à
l’application.
Unit 8 - IAM In Practice
• Managing Users & Identities for Cloud
• Additional Identity Decisions
• Authentication: MFA is mandatory
• Moving from RBAC to ABAC
• Sample Cloud Entitlement Matrix
• Recommendations
Managing Users & Identities for Cloud (1/4)
• The “identity” part of identity management focuses on the processes
and technologies for registering, provisioning, propagating, managing,
and deprovisioning identities
• Managing identities and provisioning them in systems are problems
that information security has been tackling for decades.
• It wasn’t so long ago that IT administrators needed to individually
provision users in every different internal system
• Even today, with centralized directory servers and a range of
standards, true Single Sign On for everything is relatively rare
Managing Users & Identities for Cloud (2/4)
• Cloud providers and cloud users need to start with the fundamental
decision on how to manage identities:
• Cloud providers need to nearly always support internal identities, identifiers,
and attributes for users who directly access the service, while also supporting
federation so that organizations don’t have to manually provision and manage
every user in the provider’s system and issue everyone separate credentials.
• Cloud users need to decide where they want to manage their identities and
which architectural models and technologies they want to support to
integrate with cloud providers
 Managing Users & Identities for Cloud (3/4)
• When using federation, the cloud user needs to determine the
authoritative source that holds the unique identities they will federate.
This is often an internal directory server.
• The next decision is whether
• to directly use the authoritative source as the identity provider,
• use a different identity source that feeds from the authoritative source (like a
directory fed from an HR system),
• or to integrate an identity broker.
 Managing Users & Identities for Cloud (4/4)
• There are two possible architectures:
• Free-form: internal identity providers/sources (often directory servers) connect directly
to cloud providers.
• raises a few issues : (-) directory needs Internet access;
• (-) may require users to VPN back to the corporate network before accessing cloud services ;
• (-) if you have multiple directory servers in different organizational silos, federating to an external
provider may be complex and technically difficult.
• Hub and spoke: internal identity providers/sources communicate with a central broker or
repository that then serves as the identity provider for federation to cloud providers.
• Identity brokers handle federating between identity providers and relying parties (which may not
always be a cloud service). They can be located on the network edge or even in the cloud in order to
enable web-SSO.
• Note: Identity providers don’t need to be located only on-premises; many cloud
providers now support cloud-based directory servers that support federation
internally and with other cloud services
Managing Users & Identities for Cloud
(short)
• Cloud providers need to support
internal identities and federation
• Cloud consumers need to
determine where to manage
identities and how to integrate
With providers
• Generally, consumers should own
the identity and federate to the
provider (as much as possible)
Additional Identity Decisions
• How to manage identities for systems / code / devices / services
• Defining the identity provisioning process and how to integrate With cloud.
• Often a good time to review and update your process
• Provisioning and supporting various cloud providers / platforms.
• There should be a formal process for adding new providers into the IAM infrastructure.
• This includes the process of establishing any needed federation connections, as well as:
• Mapping attributes
• Enabling monitoring / logging
• Building entitlement matrices
• Documenting break / fix for federation outages
• IR (incident response) for account takeovers and other IAM incidents
• Deprovisioning or entitlement change
Authentication: MFA is Mandatory
• The biggest impact of cloud computing on authentication is a greater
need for strong authentication using multiple factors. This is for two
reasons:
• Broad network access means cloud services are always accessed over the
network, and often over the Internet. Loss of credentials could more easily
lead to an account takeover by an attacker, since attacks aren’t restricted to
the local network.
• Greater use of federation for Single Sign On means one set of credentials can
potentially compromise a greater number of cloud services.
MFA options
• Hard tokens are physical devices that generate one time passwords for human entry or
need to be plugged into a reader.
• These are the best option when the highest level of security is required.
• Soft tokens work similarly to hard tokens but are software applications that run on a phone
or computer.
• could be compromised if the user’s device is compromised, and this risk needs to be considered in
any threat model.
• Out-of-band Passwords are text or other messages sent to a user’s phone (usually) and are
then entered like any other one time password generated by a token.
• threat model must consider message interception, especially with SMS.
• Biometrics are growing as an option, thanks to biometric readers now commonly available
on mobile phones.
• For cloud services, the biometric is a local protection that doesn’t send biometric information to the
cloud provider and is instead an attribute that can be sent to the provider.
Moving from RBAC to ABAC
• RBAC (Role Based Access Controls)
• Very familiar
• Decisions based on assigned role in that
context
• ABAC (Attribute Based Access Controls)
• Decision based on more attributes than
just role
• context aware decisions by incorporating
multiple attributes, such as role, location,
authentication method, and more
• Far more granular and flexible
• Best model for cloud
Authorization, access control and entitlement
• An authorization is permission to do something—access a file or
network, or perform a certain function like an API call on a particular
resource.
• An access control allows or denies the expression of that
authorization, so it includes aspects like assuring that the user is
authenticated before allowing access.
• An entitlement maps identities to authorizations and any required
attributes (e.g. user x is allowed access to resource y when z
attributes have designated values).
• Entitlement is written as a policy that is loaded into the cloud provider’s
system for enforcement.
Sample Cloud Entitlement Matrix
 Cloud impacts entitlements, authorizations,
and access management
• Cloud providers and platforms, like any other technology, will have their own set of potential
authorizations specific to them. Unless the provider supports XACML (rare today) the cloud user will
usually need to configure entitlements within the cloud platform directly.
• The cloud provider is responsible for enforcing authorizations and access controls.
• The cloud user is responsible for defining entitlements and properly configuring them within the cloud
platform.
• Cloud platforms tend to have greater support for the Attribute-Based Access Control (ABAC) model for
IAM, which offers greater flexibility and security than the Role-Based Access Control (RBAC) model.
ABAC is the preferred model for cloud-based access management.
• When using federation, the cloud user is responsible for mapping attributes, including roles and groups,
to the cloud provider and ensuring that these are properly communicated during authentication.
• Cloud providers are responsible for supporting granular attributes and authorizations to enable ABAC
and effective security for cloud users.
Privileged User Management
• Strong authentication should be a strong consideration for any
privileged user.
• Account and session recoding should be implemented to drive up
accountability and visibility for privileged users.
• In some cases, it will be beneficial for a privileged user to sign in
through a separate tightly controlled system using higher levels of
assurances for credential control, digital certificates, physically and
logically separate access points, and/or jump hosts.
Recommendations
• Cloud consumers should prefer MFA for all external cloud accounts and send MFA
status as an attribute when using federated authentication.
• Privileged identities should always use MFA.
• Develop an entitlement matrix for each cloud provider and project, with an emphasis
on access to the metastructure and/or management plane.
• Translate entitlement matrices into technical policies when supported by the cloud
provider or platform.
• Prefer ABAC over RBAC for cloud computing.
• Cloud providers should offer both internal identities and federation using open
standards.
• There are no magic protocols: pick your use cases and constraints first and find the
right protocol second.
Conclusion
• Due to the complexity of managing multiple directory servers and cloud
providers, a hub and spoke model using a federated identity broker is often
preferred.
• Because of the broad network access supported by cloud providers, multi
factor authentication is critical to help reduce the chances of account
takeovers.
• Many cloud providers are supporting attribute based access controls, which
support greater granularity in entitlements than traditional role-based
access controls.
• Building an entitlement matrix can help document authorizations for your
cloud providers different services, and help With assessments and audits.
Module 6: Cloud Security Operations
• Unit 1 - Module Introduction
• Unit 2 - Selecting A Cloud Provider
• Unit 3 - Incident Response
• Unit 4 - SECaaS Fundamentals
• Unit 5 - SECaaS Categories & Recommendations
• Unit 6 - Domain 14 Considerations
• Unit 7 - CCSK Exam Preparation
Unit 1 - Module Introduction
• Maps to the following domains in the Security Guidance
• DOMAINS 9: Incident response
• DOMAIN 13: SECaaS fundamentals and categories
• DOMAIN14: Related Technologies
• Covers the following subject areas
• What to look for in a cloud provider
• Security as a Service
• Incident Response
• IOT
• Serveless
• Mobile
• big Data
Objectives
• How to select cloud providers
• The advantages & disadvantages of Security as a Service.
• The different major Security as a Service categories.
• How to respond to security incidents in the cloud
• The security issues of technologies related to cloud computing: Big
Data, mobile, serverless, IOT.
• Security as a Service recommendations
Unit 2 - Selecting A Cloud Provider
• Enabling the Security Strategy
• Characteristics to Look for in a Cloud Provider
• Documentation to Look for From a Cloud Provider
• Critical Security Capabilities
• Outsourcing Accountability
• CSA Tools
Enabling the Security Strategy
• A big question to the cloud provider: how do you enable my security
strategy ?
• What do you do ?
• What do I have to do ?
• Do you enable me to do what I need to do ?
Characteristics to Look for in a Cloud
Provider
• Compartmentalization of Job • Configuration Management
Roles Process
• Well-defined Security Policies • Patch Management Process
• Reviewable Audits • Robust, Well-documented API
• The Ability To Inspect / Audit • Security In The Development
Provider Process
• Well-defined Contractual • Security In The Operations
Language (Security / Privacy) Process
• Well-defined BC/DR Policy / • Prioritization Of Security
Process
Characteristics to Look for in a Cloud
Provider
Ensure that your requirements,
which should be based on
recognized standards, are within the
scope of the audit
Critical Security Capabilities in cloud
providers (IaaS & PaaS)
• API/admin activity logging
• Elasticity and autoscaling
• APIS for all security features
• Granular entitlements
• Good SAML support
• Multiple accounts per customer (or equivalent)
• Software-defined networking
• Region/location control
• Infrastructure templating/automation
Critical Security Capabilities in cloud
providers (SaaS)
• Robust external security and compliance assessments available for
customers to review
• Granular IAM entitlements within the SaaS application
• SAML support
• Logging of administrator activity
• External log feeds or API access to logs
• Strong internal controls to limit admin access to customer data o
• These should be externally validated and clearly documented
Outsourcing Accountability
• ALWAYS KEEP IN MIND...

An organization cannot outsource accountability... Ever.

• Same as, an organization can never outsource responsibility for

governance, even when using external providers.
• you can never outsource your overall responsibility and accountability
for risk management to an external provider but you can certainly
outsource the management of some risks.
CSA Tools
Conclusion
• The critical security capabilities for Cloud providers are list of features required in
a Cloud platform to fully enable customers to build a comprehensive Cloud
security program.
• When evaluating Cloud providers, Cloud consumers should also look at all
available documentation, pay particular attention to internal security controls
that ensure a strong baseline level of security over time.
• Individual security features are not as indicative as strong programmatic controls.
• Cloud providers should offer a wide array of reviewable third-party audits and
assessments to validate their security program and control.
• The Cloud Security Alliance provides the CAIQ, CCM. STAR STARWatch to help
both Cloud providers consumers in communicating security posture.
Unit 3 - Incident Response
• Incidents Change
• Incident Response Lifecycle
• Preparation
• Detection & Analysis
• Containment, Eradication, Recovery
• Post-Mortem
• Incident Response Recommendations
Incident Response
• Preventive security controls have proven unable to completely
eliminate the possibility that critical data could be compromised.
• Most organizations have some sort of IR plan to govern how they will
investigate an attack
• But as the cloud presents distinct differences in both access to
forensic data and governance, organizations must consider how their
IR processes will change.
Incidents Change
• Likelihood of some kinds of incidents goes up, others goes down - its a
different environment
• The metastructure is the biggest difference
• Consider attacks targeted at the Cloud Provider and how that affects
your systems
• You and the provider will likely have different priorities
• Your processes will certainly change
• Don't wait until the first incident to figure this all out
Incident Response Lifecycle
• The Incident Response Lifecycle is defined in the NIST 800-61rev2
document
Preparation
• Preparation: “Establishing an incident response capability so that the
organization is ready to respond to incidents.”
• Process to handle the incidents.
• Handler communications and facilities.
• Incident analysis hardware and software.
• Internal documentation (port lists, asset lists, network diagrams, current
baselines of network traffic).
• Identifying training.
• Evaluating infrastructure by proactive scanning and network monitoring,
vulnerability assessments, and performing risk assessments.
• Subscribing to third-party threat intelligence services.
Detection and Analysis
• Alerts [endpoint protection, network security monitoring, host monitoring,
account creation, privilege escalation, other indicators of compromise, SIEM,
security analytics (baseline and anomaly detection), and user behavior
analytics].
• Validate alerts (reducing false positives) and escalation.
• Estimate the scope of the incident.
• Assign an Incident Manager who will coordinate further actions.
• Designate a person who will communicate the incident containment and
recovery status to senior management.
• Build a timeline of the attack.
• Determine the extent of the potential data loss.
Containment, Eradication and Recovery
• Containment: Taking systems offline. Considerations for data loss
versus service availability. Ensuring systems don’t destroy themselves
upon detection.
• Eradication and Recovery: Clean up compromised devices and restore
systems to normal operation. Confirm systems are functioning
properly. Deploy controls to prevent similar incidents.
• Documenting the incident and gathering evidence (chain of custody).
Post-mortem
• What could have been done better?
• Could the attack have been detected sooner?
• What additional data would have been helpful to isolate the attack
faster?
• Does the IR process need to change? If so, how?
How the Cloud Impacts IR - Preparation
• Understand where data is and moves.
• Understand and clarify SLAs and contracts.
• These become your primary communication and enforcement tool
• Look for things like:
• Points of contact, communications channels.
• Incident definition and notification criteria.
• Testing, scoping, and roles and responsibilities.
• IaaS/PaaS vs. SaaS:
• In a multitenant environment, how can data specific to your cloud be provided for investigation?
• For each major service you should understand and document what data and logs will be available in an incident.
• Don’t assume you can contact a provider after the fact and collect data that isn’t normally available
• Build a cloud jump kit (tools needed to investigate in a remote location)
• For example, do you have tools to collect logs and metadata from the cloud platform?
• Do you have the ability to interpret the information?
• How do you obtain images of running virtual machines and what kind of data do you have access to: disk storage or volatile
memory?
• Architect for faster detection, investigation, and remediation (differences between IaaS/PaaS/SaaS)
• Immutable, infrastructure as code, isolation,
• application stack maps (to understand where data is going to reside),
• threat modeling and tabletop exercises (to determine the most effective means of containment)
• instrumentation (such as cloud API logs and ensuring that they feed to a secure location that’s available to investigators)
 How the Cloud Impacts IR - Detection &
Analysis
• Detection and analysis in a cloud environment may look nearly the same (for IaaS) and quite different (for
SaaS).
• leverage in-cloud monitoring and alerts that can kick off an automated IR Workflow
• Cloud platforms also offer a variety of logs, which can sometimes be integrated into existing security
operations/monitoring (not available on all providers; more with IaaS and PaaS than SaaS)
• Detection depends on data availability.
• Know your data sources- what the provider gives you, and what you collect yourself
• Pay particular attention to in-cloud monitoring and alerting capabilities
• One challenge in collecting information may be limited network visibility
• Analysis impacted by lack of transparency to provider's infrastructure.
• Data source issues:
• What should be logged and what is logged?
• Are logs consistent and complete?
• Do logs reflect the dynamic nature of the cloud?
• Do logs meet legal requirements, tamper resistance, and format requirements?
• External threat intelligence may also be useful
 How the Cloud Impacts IR - Detection &
Analysis
• Forensics likely limited to your virtual instances. Snapshots are useful.
• There is a greater need to automate many of the forensic/investigation
processes in cloud environments, because of their dynamic and higher-
velocity nature.
• Some examples of tasks you can automate include:
• Snapshotting the storage of the virtual machine.
• Capturing any metadata at the time of alert, so that the analysis can happen based
on what the infrastructure looked like at that time.
• If your provider supports it, “pausing” the virtual machine, which will save the
volatile memory state.
 How the Cloud Impacts IR - Detection &
Analysis
• You can also leverage the capabilities of the cloud platform to determine
the extent of the potential compromise:
• Analyze network flows to check if network isolation held up.
• Examine configuration data to check if other similar instances were potentially
exposed in the same attack.
• Review data access logs (for cloud-based storage, if available) and management
plane logs to see if the incident affected or spanned into the cloud platform.
• Serverless and PaaS-based architectures will require additional correlation across
the cloud platform and any self-generated application logs
How the Cloud Impacts IR - Containment,
Eradication, Recovery
• Cloud provider's primary responsibility is to the entire customer based.
• Containment may mean containing you. You will be sacrificed to maintain the stability of the service.
• You are responsible for your own containment, eradication, and recovery.
• Start With the management plane/metastructure
• Always start by ensuring the cloud management plane/metastructure is free of an attacker
• The cloud often provides a lot more flexibility in this phase of the response, especially for
IaaS.
• Software-defined infrastructure allows you to quickly rebuild from scratch in a clean
environment, and, for more isolated attacks, inherent cloud characteristics can speed
quarantine, eradication, and recovery processes
• This also means there’s no need to immediately “eradicate” the attacker before you identify
their exploit mechanisms and the scope of the breach.
• With SaaS and some PaaS you may be very limited and will thus need to rely more on the
cloud provider
How the Cloud Impacts IR - Post-Mortem

• Mostly equivalent to how you handle for traditional infrastructure

• As with any attack, work with the internal response team and
provider to figure what worked and what didn’t, then pinpoint any
areas for improvement.
• Pay particular attention to data sources, the metastructure
/management plane response, and communications with the cloud
provider.
• It is hard to change SLAs, but if the agreed-upon response time, data,
or other support wasn’t sufficient, go back and try to renegotiate.
Incident Response Recommendations
• Cloud-based applications should leverage automation and orchestration to streamline
and accelerate the response, including containment and recovery.
• For each cloud service provider used, the approach to detecting and handling
incidents involving the resources hosted at that provider must be planned and
described in the enterprise incident response plan.
• The SLA With each cloud service provider must guarantee support for the incident
handling required for the effective execution of the enterprise incident response plan.
• This must cover each stage of the incident handling process: detection, analysis, containment,
eradication, and recovery.
• Testing will be conducted at least annually or whenever there are significant changes
to the application architecture.
• Customers should seek to integrate their testing procedures With that of their provider (and
other partners) to the greatest extent possible.
Conclusion
• The fundamental nature of Cloud changes the Iikelihood and nature of
incidents. It is important to adjust your incident response process to
account for these.
• Cloud consumers and cloud providers will have different priorities in an
incident. These may conflict when a provider needs to contain a consumer.
• Focus on preperation, especiaIIy communications with Cloud providers,
adjusting IR plans, and building tool or “jump” kits to more-rapidly respond
• When available, infrastructure as code can allow isolation of compromised
environment while rebuilding a functional environment in parallel to
reduce downtime. But don't forget, this will carry over (postpone) any
active vulnerabilities and configuration errors in the templates.
Unit 4 - SECaaS Fundamentals
• SECaaS Defined
• SECaaS Characteristics
• SECaaS Benefits
• SECaaS Concerns
SECaaS Defined
• Security as a Service is defined as a security product or service,
with cloud-based management.
• These services can secure systems and data in the Cloud, in
traditional on-premises networks, or hybridized environments.
SECaaS Characteristics

• SECaaS includes dedicated SecaaS providers, as well as packaged

security features from general cloud-computing providers.
• Security as a Service encompasses a very wide range of possible
technologies, but they must meet the following criteria:
• SecaaS includes security products or services that are delivered as a cloud
service.
• To be considered SecaaS, the services must still meet the essential NIST
characteristics for cloud computing, as defined in Domain 1.
SECaaS Benefits
 SECaaS Benefits
• Cloud-computing benefits:
• reduced capital expenses, agility, redundancy, high availability, and resiliency.
• these benefits depend on the pricing, execution, and capabilities of the security provider.
• Staffing and expertise.
• Many organizations struggle to employ, train, and retain security professionals across relevant domains of expertise.
• This can be exacerbated due to limitations of local markets, high costs for specialists, and balancing day-to-day needs with the high rate of
attacker innovation.
• Intelligence-sharing.
• SecaaS providers protect multiple clients simultaneously and have the opportunity to share data intelligence and data across them.
• Deployment flexibility.
• SecaaS may be better positioned to support evolving workplaces and cloud migrations, since it is itself a cloud-native model delivered using
broad network access and elasticity.
• Insulation of clients.
• In some cases, SecaaS can intercept attacks before they hit the organization directly.
• For example, spam filtering and cloud-based Web Application Firewalls are positioned between the attackers and the organization.
• Scaling and cost.
• The cloud model provides the consumer with a “Pay as You Grow” model, which also helps organizations focus on their core business and lets
them leave security concerns to the experts.
SECaaS Concerns
• Lack of visibility. Since services operate at a remove from the customer, they often provide less
visibility or data compared to running one’s own operation.
• Regulation differences. Given global regulatory requirements, SecaaS providers may be unable to
assure compliance in all jurisdictions that an organization operates in.
• Handling of regulated data. Customers will also need assurance that any regulated data potentially
vacuumed up (aspirée) as part of routine security scanning or a security incident is handled in
accordance with any compliance requirements
• Data leakage. Especially for the highly sensitive nature of security data (and other regulated data
potentially exposed in security scanning or incidents) . The SecaaS providers should be held to the
highest standards of multitenant isolation and segregation.
• Changing providers. organizations may be concerned about lock-in due to potentially losing access to
data, including historical data needed for compliance or investigative support.
• Migration to SecaaS. For organizations that have existing security operations and on-premises legacy
security control solutions, the migration to SecaaS and the boundary and interface between any in-
house IT department and SecaaS providers must be well planned, exercised, and maintained.
Conclusion
• Security as a Service is defined as a security product or service, with cloud-
based management. These services can secure systems and data in the cloud,
in traditional on-premises networks, or hybridized environments.
• Security as a Service includes security products delivered as a cloud service,
that also meet the NIST essential characteristics.
• They offer the same benefits as the rest of cloud computing, and may also
offer benefits such as deeper expertise among their staff, as well as
intelligence sharing across all the customers they protect
• Drawbacks can include regulatory differences, reduced visibility, and the
potential for your data leaking through the provider.
• The cloud consumer can never outsource their security accountability.
Unit 5 - SECaaS Categories &
Recommendations
• IAM Services
• Cloud Access & Security Brokers (CASB)
• Web Security Gateways
• Email Security
• Security Assessment
• Web Application Firewalls
• Encryption & Key Management
• Security Information & Event Management
• BC/DR
• Additonal Categories (Anti-DDOS/Security Management/IDPS)
• SECaaS Recommendations
IAM Services
• Identity-as-a-service is a generic term that covers one or many of the services that may
comprise an identity ecosystem,
• Policy Enforcement Points (PEP-as-a-service),
• Policy Decision Points (PDP-as-a-service),
• Policy Access Points (PAP-as-a-service),
• services that provide Entities with Identity,
• services that provide attributes (e.g. Multi-Factor Authentication),
• services that provide reputation.
• Best-known categories heavily used in cloud security
• Federated Identity Brokers
• intermediate IAM between an organization’s existing identity providers (internal or cloud-hosted directories) and
the many different cloud services used by the organization
• can provide web-based Single Sign On (SSO)
• Strong Authentication (e.g. mobile device apps and tokens for MFA)
• Cloud-Based Directories
• Other emerging options
 Cloud Access & Security Brokers (CASB)
• Also known as Cloud Security Gateways
• Discussed in the Data Security module
• On-premises or often offered as a cloud-hosted service.
• Commonly used to manage an organization’s sanctioned and unsanctioned SaaS services.
• Intercept communications that are directed towards a cloud service or directly connect to the service via API
in order to monitor activity, enforce policy, and detect and/or prevent security issues.
• can also connect to on-premises tools to help an organization detect, assess, and potentially
block cloud usage and unapproved services
• Can include risk-rating capabilities to help customers understand and categorize hundreds or
thousands of cloud services
• Most providers also offer basic Data Loss Prevention
• The term is also sometimes used to include Federated Identity Brokers. This can be confusing.
Although the combination, the market is still dominated by independent services for those two
capabilities.
Web Security Gateways
• Web Security involves real-time protection
• Protective, detective, and reactive technical control
• Offered either on-premises through software and/or appliance installation, or
via the Cloud by proxying or redirecting web traffic to the cloud provider (or a
hybrid of both).
• Provides an added layer of protection on top of other protection, such as anti-
malware software to prevent malware from entering the enterprise
• Enforce policy rules around types of web access and the time frames when
they are allowed
• Application authorization management can provide an extra level of granular
and contextual security enforcement for web applications
Email Security
• Filters inbound and outbound email to block spam, phishing, and
malware.
• Enforcing corporate polices like acceptable use and spam prevention,
• Protects users from email floods and provides business continuity.
• May include encryption and features like digital signatures that
enable identification and non-repudiation
Security Assessment
• Third-party or customer-driven audits of cloud services or
assessments of on-premises systems via cloud-provided solutions
• Main Types:
• Traditional security/vulnerability assessments of assets that are deployed in
the cloud (e.g.virtual machines/instances for patches and vulnerabilities) or
on-premises.
• Application security assessments, including SAST, DAST, and management of
RASP.
• Cloud platform assessment tools that connect directly with the cloud service
over API to assess not merely the assets deployed in the cloud, but the cloud
configuration as well.
Web Application Firewalls
• In a cloud-based WAF,
customers redirect traffic
(using DNS) to a service
that analyzes and filters
traffic before passing it
through to the
destination web
application.
• Many cloud WAFs also
include anti-DDoS
capabilities.
Intrusion Detection/Prevention (IDS/IPS)
• Intrusion Detection/Prevention systems monitor behavior patterns
using rule-based, heuristic, or behavioral models to detect anomalies
in activity which might present risks to the enterprise.
• With IDS/IPS as a service, the information feeds into a service-
provider’s managed platform, as opposed to the customer being
responsible for analyzing events themselves.
• Cloud IDS/IPS can use existing hardware for on-premises security,
virtual appliances for in-cloud (see Domain 7 for the limitations), or
host-based agents.
Encryption & Key Management
• These services encrypt data and/or manage encryption keys
• Cloud-based key management can protect cloud data (for a specific
cloud provider or accessible across multiple providers) and also on-
premise data via API.
• Encryption/Decryption via API and encrypted network connections
• The category also includes encryption proxies for SaaS, which
intercept SaaS traffic to encrypt discrete data.
• Consistency With existing key management schemes is important.
Security Information & Event Management
• Cloud SIEMs collect data in a cloud service, as opposed to a customer-
managed, on-premises system
• Aggregate log and event data from virtual and real networks,
applications, and systems.
• Correlate and provide alerts and real-time reporting based on
mutually agreed rule set.
• Ensure the hand-off (transfer) between provider and internal ops
group is clean.
BC/DR
• Providers of cloud BC/DR services back up data from individual
systems, data centers, or cloud services to a cloud platform instead of
relying on local storage or shipping tapes
• They may use a local gateway to speed up data transfers and local
recoveries, with the cloud service serving as the final repository for
worst-case scenarios or archival purposes.
• Requires synchronization and clear demarcation (distinction) of
accountability.
Security Management
• These services roll up traditional security management capabilities,
such as EPP (endpoint) protection, agent management, network
security, mobile device management, and so on into a single cloud
service.
• This reduces or eliminates the need for local management servers and
may be particularly well suited for distributed organizations.
Distributed Denial of Service Protection
• By nature, most DDoS protections are cloud-based.
• They operate by rerouting traffic through the DDoS service in order to
absorb attacks before they can affect the customer’s own
infrastructure.
Additonal Categories
• ADDITIONAL CATEGORIES
• DDoS Protection
• Security Management
• Managed Network or Endpoint Security (e.g. IDS)
SECaaS Recommendations
• Before engaginga SECaaS provider, be sure to understand any
security-specific requirements for data-handling (and availability),
investigative, and compliance support.
• Pay particular attention to handling of regulated data, like Pll.
• Understand your data retention needs and select a provider that can
support data feeds that dont create a lock-in situation.
• Ensure that the SECaaS service is compatible With your current and
future plans, such as its supported cloud (and on premises) platforms,
the workstation and mobile operating systems it accommodates, and
so on.
Conclusion
• Security as Service offerings include Wide range of categories that span
most, if not aII, major security domains.
• The key is that the service meets the NIST essential characteristics, and this
also includes hybrid offerings (e.g. the management is in the cloud with
same on- premise components.
• Common categories include everything from security assessment, to cloud-
based defensive tools Iike WAF email, and web filtering, to SIEM logging.
• When selecting a provider ensure you understand your data handling and
compliance requirements and evaluate services that are compatible with
your existing technology requirements, such as architectures and operating
systems.
Unit 6 - Domain 14 Considerations
• Related Technologies
• Big Data
• Big Data Cloud Security
• Internet of Things Security priorities
• Mobile and Cloud
• Serverless
Related Technologies
• Related technologies fall into two broad categories:
• Technologies that rely nearly exclusively on cloud computing to operate.
• Technologies that don’t necessarily rely on cloud, but are commonly seen in
cloud deployments.
• Covered by additional Cloud Security Alliance research working
groups
• Big Data Working Group
• Internet of Things Working Group
• Mobile Working Group
Big Data
• Big data includes a collection of technologies for working with extremely large datasets that traditional
data-processing tools are unable to manage
• It’s not any single technology but rather refers commonly to distributed collection, storage, and data-
processing frameworks
• Gartner defines it as such: “Big data is high volume, high velocity, and/or high variety information assets
that require new forms of processing to enable enhanced decision making, insight discovery and process
optimization.”
• High volume: a large size of data, in terms of number of records or attributes.
• High velocity: fast generation and processing of data, i.e., real-time or stream data.
• High variety: structured, semi-structured, or unstructured data.

• Cloud computing, due to its elasticity and massive storage capabilities, is very often where big data projects
are deployed
• Big data is not exclusive to cloud by any means, but big data technologies are very commonly integrated
into cloud-computing applications and offered by cloud providers as IaaS or PaaS.
Big Data
• There are three common components of big data, regardless of the specific
toolset used:
• Distributed data collection: Mechanisms to ingest large volumes of data, often of a
streaming nature. This could be as “lightweight” as web-click streaming analytics and
as complex as highly distributed scientific imaging or sensor data. Not all big data
relies on distributed or streaming data collection, but it is a core big data technology.
• Distributed storage: The ability to store the large data sets in distributed file systems
(such as Google File System, Hadoop Distributed File System, etc.) or databases
(often NoSQL), which is often required due to the limitations of non-distributed
storage technologies.
• Distributed processing: Tools capable of distributing processing jobs (such as map
reduce, spark, etc.) for the effective analysis of data sets so massive and rapidly
changing that single origin processing can’t effectively handle them.
Big Data
Big Data security
• Security and Privacy Considerations
• Due to a combination of the highly distributed nature of big data applications and the sheer (total)
volume and potential sensitivity of the information, security and privacy are typically high priorities
but are challenged by a patchwork (‫ )مرقع‬of different tools and platforms.
• Data Collection
• Data collection mechanisms will likely use intermediary storage that needs to be appropriately
secured.
• Even if primary storage is well-secured it’s important to also check intermediary storage (some swap
space on a processing node)
• Key Management
• Key management for storage may be complicated depending on the exact mechanisms used due to
the distributed nature of nodes.
• There are techniques to properly encrypt most big data storage layers today
• The complicating factor is that key management needs to handle distributing keys to multiple storage
and analysis nodes
Big Data security
• Security Capabilities
• Not all big data technologies have robust security capabilities.
• Cloud provider security capabilities can help compensate for the big data technology limitations.
• Both should be included in any security architecture.
• Identity and Access Management
• Identity and Access Management will likely occur at both cloud and big data tool levels, which can
complicate entitlement matrices.
• PaaS
• Many cloud providers are expanding big data support with machine learning and other platform as
a service options that rely on access to enterprise data.
• These should not be used without a full understanding of potential data exposure, compliance, and privacy
implications.
• This doesn’t mean you shouldn’t use the services, it just means you need to understand the
implications and make appropriate risk decisions.
Big Data Cloud Security (brief)
• KNOW YOUR PLATFORM
• Capabilities vary greatly between both providers and platforms
• If you use machine learning/Al, understand the security and privacy model.
• SECURING ALL THE STORAGE
• Including intermediary storage like containers or storage volumes for vms
performing processing
• SECURE THE PLATFORM
• Big data platforms still have relatively Iow inherent security.
• Look to paas and isolated virtual networks
• ENCRYPTION KEY MANAGEMENT
• No change to the fundamentals, but BYOK most likely required if paas involved.
 Internet of Things Security priorities
• The Internet of Things is a blanket term (terme générique) for non-traditional computing
devices used in the physical world that utilize Internet connectivity.
• A very large percentage of these devices connect back to cloud computing infrastructure for
their back-end processing and data storage.
• Key cloud security issues related to IoT include:
• Secure data collection and sanitization.
• Device registration, authentication, and authorization.
• One common issue encountered today is use of stored credentials to make direct API calls to the back-end cloud provider.
• attackers decompile applications or device software and then use those credentials for malicious purposes.
• API security for connections from devices back to the cloud infrastructure.
• The APIs themselves could be decoded and used for attacks on the cloud infrastructure.
• Encrypted communications.
• Many current devices use weak, outdated, or non-existent encryption
• Ability to patch and update devices so they don’t become a point of compromise.
• Currently, it is common for devices to be shipped as-is and never receive security updates for operating systems or applications.
Internet of Things Security priorities

APIs and Device

Authentication / Device Patching and Updating
Authorization

Encrypted Communications
Data Collection
Mobile and Cloud
• Most mobile apps connect back to cloud.
• The primary security issues for mobile computing (in the cloud
context) are very similar to IoT, except a mobile phone or tablet is also
a general purpose computer:
• Device Registration, Authentication, & Authorization
• Stored credentials are a risk.
• Including federation tokens with long refreshes
• Application APIs can expose the cloud deployment if not secured properly
• Attackers are known to sniff API connections, and then decompile the API calls and
explore them for security weaknesses.
• Certificate pinning/validation inside the device application may help reduce this risk.
 Serverless
• Serverless computing is the extensive use of certain PaaS capabilities to such a degree that all or some of an
application stack runs in a cloud provider’s environment without any customer-managed operating systems,
or even containers.
• “Serverless computing” is a bit of a misnomer since there is always a server running the workload
• But this server and its configuration and security are completely hidden from the cloud user.
• The consumer only manages settings for the service.
• Serverless includes services such as:
• Object storage
• Cloud load balancers
• Cloud databases
• Machine learning
• Message queues
• Notification services
• Code execution environments (generally restricted containers where a consumer runs uploaded application code.)
• API gateways
• Web servers
• Serverless capabilities may be deeply integrated by the cloud provider and tied together with event driven
systems and integrated IAM and messaging
Serverless security
• key issues include:
• Serverless places a much higher security burden on the cloud provider. Choosing your provider and
understanding security SLAs and capabilities is absolutely critical.
• Using serverless, the cloud user will not have access to commonly-used monitoring and logging levels, such
as server or network logs. Applications will need to integrate more logging, and cloud providers should
provide necessary logging.
• Not necessarily every service will match every potential regulation. Providers need to keep compliance
mappings up to date, and customers need to ensure they only use services within their compliance scope.
• There will be high levels of access to the cloud provider’s management plane since that is the only way to
integrate and use the serverless capabilities.
• Serverless can dramatically reduce attack surface and pathways and integrating serverless components may
be an excellent way to break links in an attack chain.
• Any vulnerability assessment or other security testing must comply with the provider’s terms of service.
Cloud users may no longer have the ability to directly test applications, or must test with a reduced scope.
• Incident response may also be complicated and will definitely require changes in process and tooling to
manage a serverless-based incident.
Serverless (brief)
• Includes PaaS and Function as a Service
• New frameworks being released at a rapid pace (step, stride)
• IAM and logging are key security issues for serverless apps
• Often provides more security benefits than downside due to pushing
more security responsibility onto the cloud provider (in the shared
responsibilities model)
Recommendations – Big Data
• Leverage cloud provider capabilities wherever possible, even if they overlap with big data tool security capabilities.

• Use encryption for primary, intermediary, and backup storage for both data collection and data storage planes.

• Include both the big data tool and cloud platform Identity and Access Management in the project entitlement matrix.

• Fully understand the potential benefits and risks of using a cloud machine-learning or analytics service. Pay particular
attention to privacy and compliance implications.
• Cloud providers should ensure customer data is not exposed to employees or other administrators

• Cloud providers should clearly publish which compliance standards their analytics and machine-learning services are
compliant with (for their customers).
• Cloud users should consider use of data masking or obfuscation when considering a service that doesn’t meet
security, privacy, or compliance requirements.
• Follow additional big data security best practices, including those provided by the tool vendor (or Open Source
project) and the Cloud Security Alliance.
Recommendations – IoT
• Ensure devices can be patched and upgraded.
• Do not store static credentials on devices that could lead to compromise of the
cloud application or infrastructure.
• Follow best practices for secure device registration and authentication to the cloud-
side application, typically using a federated identity standard.
• Encrypt communications.
• Use a secure data collection pipeline and sanitize data to prevent exploitation of the
cloud application or infrastructure through attacks on the data-collection pipeline.
• Assume all API requests are hostile.
• Follow the additional, more-detailed guidance issued by the CSA Internet of Things
Working Group.
Recommendations – Mobile
• Follow your cloud provider’s guidance on properly authenticating and authorizing mobile devices
when designing an application that connects directly to the cloud infrastructure.
• Use industry standards, typically federated identity, for connecting mobile device applications to
cloud-hosted applications.
• Never transfer unencrypted keys or credentials over the Internet.
• Test all APIs under the assumption that a hostile attacker will have authenticated, unencrypted
access.
• Consider certificate pinning and validation inside mobile applications.
• Validate all API data and sanitize for security.
• Implement server/cloud-side security monitoring for hostile API activity.
• Ensure all data stored on device is secured and encrypted.
• Sensitive data that could allow compromise of the application stack should not be stored locally on-device
where a hostile user can potentially access it.
• Follow the more detailed recommendations and research issued by the CSA Mobile Working
Group.
Recommendations – Serverless Computing
• Cloud providers must clearly state which PaaS services have been assessed against
which compliance requirements or standards.
• Cloud users must only use serverless services that match their compliance and
governance obligations.
• Consider injecting serverless components into application stacks using architectures
that reduce or eliminate attack surface and/or network attack paths.
• Understand the impacts of serverless on security assessments and monitoring.
• Cloud users will need to rely more on application-code scanning and logging and less on server
and network logs.
• Cloud users must update incident response processes for serverless deployments.
• Although the cloud provider is responsible for security below the serverless platform
level, the cloud user is still responsible for properly configuring and using the products.
Conclusion
• Related techrologies are key technologies often seen with, used by, Cloud deployments.
• Big Data, the Internet of Things, mobile computing, and serverless computing.
• Big Date platforms tend to have Iow inherent security, so using the Cloud for isolation is
important. It’s also critical to understand where and how data is stored and, often, to
protect it with distributed encryption.
• The Internet of Things often uses Cloud computing for end processing application logic, and
data storage. Security concerns tend to focus on device and user authentication and
authorization, secure communications, and data storage.
• Mobile issues are often very similar to those of IOT when it comes to Cloud as the Cloud
becomes the back-end for many mobile apps.
• Serverless is a cloud-native technology used in most modern deployments to some degree.
IAM and logging tend to be security focus since they are so different compared to on-
premise or Even virtualized workIoads.
Unit 7 - CCSK Exam Preparation
• Preparing for the CCSK Exam
• Helpful Hints
• CCSK Exam Platform
• Final Knowledge Check
• Closing
Preparing for the CCSK Exam
• STUDY THE GUIDANCE AND ENISA DOCUMENTS.
• CSA Guidance:
• https://cloudsecurityalliance.org/download/security- guidance-v4/
• ENISA:
• https://www.enisa.europa.eu/publications/cloud-
computing-risk-assessment/at_download/fullReport
• The CAQ and CCM:
• https://cloudsecuritya/liance.org/group/consensus- assessments/# overview
• https://cloudsecurityalliance.org/group/cloud- controls-matrix/# overview
• REVIEW THE CCSK PREP KIT AT:
• https://cloudsecurityalliance.org/education/ccsk/stud y-guide
Helpful Hints
• Read the Guidance 3-4 times and have it With you.
• As With any test, the wording is weird (starnge), but if you are familiar With the material and
know where to check in the Guidance, you should be fine.
• Don’t wait to long after this training to take your test. If you don’t already have a test token
you should receive it in a couple of business days.
• If you have technical issues,
• email: [email protected]
• IF YOU PURCHASED A TOKEN WITH THIS TRAINING YOU SHOULD HAVE RECEIVED AN EMAIL
ABOUT YOUR EXAM TOKEN.
• When you are completing the process to redeem (exchange, convert) your token be sure you use the
same email you used to register for this training.
• YOU WILL HAVE TWO ATTEMPTS TO PASS THE EXAM.
• THE EXAM IS TIMED (90 MINUTES), BUT OPEN BOOK.
CCSK Exam Platform
Final Knowledge Check
Closing
Extra
cloud native
• The term cloud native refers to an application that was designed to
reside in the cloud from the start. Cloud native involves cloud
technologies like microservices, container orchestrators, and auto
scaling.