The document discusses emerging trends, statistics, and major breaches in cloud security, emphasizing the growth of security spending and the increasing focus on various aspects such as access management and incident response. Key case studies include Capital One's breach, highlighting insider threats and misconfigured resources, alongside notable earlier breaches from companies like Microsoft and Dropbox. Additionally, it examines common security risks, concerns of trust, and the challenges posed by multi-tenancy in cloud environments.

1. Cloud Security :
Emerging Facets and Frontiers
1

2. Cloud Security Trends 2019
2

3. Top 10 Trends
» Access Management
» Data Security
» Infrastructure Security
» Microservices Security
» Threat Management
» Vulnerability Management
» Secure SDLC
» Logging and Auditing
» Incident Response
» Compliance
3

4. Cloud Security Statistics
» Global Security Spending is expected to reach
$103.1 billion in 2019, up 9.4% for 2018.
» Cloud is expected to account for 38% of the
security budgets in 2020, up from 18% in
2018.
4

5. Seven most infamous
cloud security breaches
5

6. CapitalOne
On July 29, FBI agents arrested Paige A. Thompson on suspicion
of downloading nearly 30 GB of Capital One credit application
data from a rented cloud data server. Capital One said the
incident affected approximately 100 million people in the United
States and six million in Canada.
6

7. The Twitter user “erratic” posting about tools and
processes used to access various Amazon cloud instances.
7

8. Capital One incident contains the hallmarks
of many other modern data breaches
» The attacker was a former employee of the web
hosting company involved which is what generally
referred as insider threat
» She allegedly used web application firewall
credentials to obtain privileges escalation
» She also used TOR and an offshore VPN for
obfuscation commonly seen in similar data breaches
8

9. A Forensic Approach to the CapitalOne
Incident
» She must have used AWS CLI or PowerShell that used the API
credentials
» Then she could have done ‘list buckets’ and ‘sync buckets’. The
credentials were for ISRM-WAF
» Speculation is that Credentials such as the access tokens were
retrieved from the AWS Metadata API via the web application with a
SSRF vulnerability
» In third party WAF, if we can connect to the Metadata end point, we
can pull the ephemeral API key to use with the AWS CLI
9

10. A Forensic Approach to the CapitalOne
Incident
» She may have found AWS IAM credentials that
allowed her to access all sort of S3 stuff.
» It is quite possible that there was just a
misconfigured EC2 instance that had those
overly permissive IAM role / credential
available.
10

11. How did Capital One Team respond ?
The good news, however, is that Capital One Incidence Response
was able to move quickly once they were informed of a possible
breach via their Responsible Disclosure program, which is
something a lot of other companies struggle with.
11

12. Microsoft
In late 2010, Microsoft experienced a breach that was traced
back to a configuration issue within its Business Productivity
Online Suite.
The problem allowed non-authorized users of the cloud service to
access employee contact info in their offline address books.
Microsoft claims that customer had access to their data and that
they fixed the issue two hours after it occured.
12

13. Dropbox
No one knew the severity of the breach cloud-based file sharing
giant Dropbox announced back in 2012.
In fact, it wasn’t until four years later that we learned what
really happened. Hackers tapped into more than 68 million user
accounts – email addresses and passwords included – representing
nearly 5 gigabytes of data.
Those stolen credentials reportedly made their way to a dark
web marketplace – the price for them was bitcoins.
13

14. National Electoral Institute of Mexico
In April 2016, the National Electoral Institute of Mexico was the
victim of a breach that saw over 93 million voter registration
records compromised.
Most of the records were lost due to a poorly configured
database that made this confidential information publicly
available to anyone.
Later it was identified that the Institute was storing data on an
insecure, illegally hosted Amazon cloud server outside of Mexico.
14

15. Six most common cloud computing
security risks
» Distributed Denial of Service
» Shared Cloud Computing Services
» Data Loss and Inadequate Backups
» Phishing and Social Engineering Attacks
» System Vulnerabilities
15

16. Cloud computing fundamentals
16

17. Cloud computing fundamentals
• Features
– Use of internet-based services to support business process
– Rent IT-services on a utility-like basis
• Attributes
– Rapid deployment
– Low startup costs/ capital investments
– Costs based on usage or subscription
– Multi-tenant sharing of services/ resources
• Essential characteristics
– On demand self-service
– Ubiquitous network access
– Location independent resource pooling
– Rapid elasticity
– Measured service
17

18. “Cloud computing is a compilation of existing techniques and technologies, packaged within a
new infrastructure paradigm that offers improved scalability, elasticity, business agility, faster
startup time, reduced management costs, and just-in-time availability of resources”
18

19. Cloud computing : Advantages
• Efficiency
• Cost
• Time
• Reliability
• Availability
• All environments, especially disaster recovery
• Scalability
• Elastic capacity
• Manageability
• Cost effective
• Capital expenditure free
19

20. Cloud Computing : Disadvantages
• To be fair we need to mention disadvantages however most can be overcome
• Hard to establish clear governance
• Unclear documentation and specifications
• Vendor lock-in
• Limited control
• Security ****
20

21. Cloud Operating Models
• Delivery Models
– SaaS
– PaaS
– IaaS
• Deployment Models
– Private cloud
– Community cloud
– Public cloud
– Hybrid cloud
• Management Models (trust and tenancy issues)
– Self-managed
– 3rd party managed (e.g. public clouds and VPC)
21

22. Cloud Computing Service Architecture
22
Facilities
Hardware
Integration
Middleware
Interfaces
Abstraction Layer
Connectivity/Network
Presentment
Application Programming Interfaces
Data Metadata
Applications/Software
Infrastructure as a Service
Platform as a Service
Software as a Service

23. Cloud Delivery Models and Security
‣ Cloud-based IaaS does not typically expose actual hardware or networking layers
to the tenant of the service, rather these underlying resources are abstracted for
the consumer.
‣ PaaS abstracts infrastructure to a greater extent and generally presents
middleware containers that are tailored for categories of usag such as
development.
‣ SaaS abstracts even further and generally exposes narrow-functionality software-
based services such as Customer Relationship Management (CRM) or e-mail.
‣ At every step up the continuum, there are increasing limitations on lower-level
computing functions. In other words, from IaaS to SaaS underlying computing
functions are more and more abstracted
23

24. Cloud Delivery Models and Security
‣ With SaaS, the burden of security lies with the cloud provider. In part,
this is because of the degree of abstraction, but the SaaS model is
based on a high degree of integrated functionality with minimal
customer control or extensibility.
‣ By contrast, the PaaS model offers greater extensibility and greater
customer control but fewer higher-level features. Largely because of
the relatively lower degree of abstraction, IaaS offers greater tenant or
customer control over security than do PaaS or SaaS.
24

25. 25

26. 26

27. 27

28. Cloud Security
Common Concerns
28

29. Cloud Computing : Common Questions
• The cloud acts as a big black box, nothing inside the cloud is visible
to the clients
• Clients have no idea or control over what happens inside a cloud
• Even if the cloud provider is honest, it can have malicious system
admins who can tamper with the VMs and violate confidentiality
and integrity
• Clouds are still subject to traditional data confidentiality, integrity,
availability, and privacy issues, plus some additional attacks
29

30. Key concerns about cloud computing
implementations
30
Security Availability Performance Costs Standards

31. Cloud security concerns and
management models
• Most security problems stem from:
– Loss of control
– Lack of trust (mechanisms)
– Multi-tenancy
• These problems exist mainly in 3rd party management models
– Self-managed clouds still have security issues, but not
related to above
31

32. Loss of control in cloud
• Consumer’s loss of control
– Data, applications, resources are located with provider
– User identity management is handled by the cloud
– User access control rules, security policies and enforcement are
managed by the cloud provider
– Consumer relies on provider to ensure
• Data security and privacy
• Resource availability
• Monitoring and repairing of services/resources
32

33. Lack of trust in cloud
• Trusting a third party requires taking risks
• Defining trust and risk
– Opposite sides of the same coin (J. Camp)
– People only trust when it pays (Economist’s view)
– Need for trust arises only in risky situations
• Defunct third party management schemes
– Hard to balance trust and risk
– e.g. Key Escrow (Clipper chip)
– Is the cloud headed toward the same path?
33

34. Multi tenancy issues in the cloud
• Conflict between tenants’ opposing goals
– Tenants share a pool of resources and have opposing goals
• How does multi-tenancy deal with conflict of interest?
– Can tenants get along together and ‘play nicely’ ?
– If they can’t, can we isolate them?
• How to provide separation between tenants?
• Cloud Computing brings new threats
– Multiple independent users share the same physical infrastructure
– Thus an attacker can legitimately be in the same physical machine as the
target
34

35. Taxonomy of fear
• Confidentiality
– Fear of loss of control over data
• Will the sensitive data stored on a cloud remain confidential?
• Will cloud compromises leak confidential client data
– Will the cloud provider itself be honest and won’t peek into the data?
• Integrity
– How do I know that the cloud provider is doing the computations correctly?
– How do I ensure that the cloud provider really stored my data without
tampering with it?
35

36. Taxonomy of fear ( CONTD. )
• Availability
– Will critical systems go down at the client, if the provider
is attacked in a Denial of Service attack?
– What happens if cloud provider goes out of business?
– Would cloud scale well-enough?
– Often-voiced concern
• Although cloud providers argue their downtime
compares well with cloud user’s own data centres
36

37. Taxonomy of fear ( CONTD. )
• Privacy issues raised via massive data mining
– Cloud now stores data from a lot of clients, and can run data
mining algorithms to get large amounts of information on clients
• Increased attack surface
– Entity outside the organisation now stores and computes data, and
so
– Attackers can now target the communication link between cloud
provider and client
– Cloud provider employees can be phished
37

38. Taxonomy of fear ( CONTD. )
• Auditability and forensics (out of control of data)
– Difficult to audit data held outside organisation in a cloud
– Forensics also made difficult since now clients don’t maintain data
locally
• Legal dilemma and transitive trust issues
– Who is responsible for complying with regulations?
• e.g., SOX, HIPAA, GLBA ?
– If cloud provider subcontracts to third party clouds, will the data
still be secure?
38

39. Cloud Security
Threat Modelling
39

40. Cloud security challenges
• Security is one of the most difficult task to implement in cloud
computing.
– Different forms of attacks in the application side and in the
hardware components
• Attacks with catastrophic effects only needs one security flaw
40

41. Threat model
• A threat model helps in analysing a security problem, design
mitigation strategies, and evaluate solutions
•Steps:
– Identify attackers, assets, threats and other components
– Rank the threats
– Choose mitigation strategies
– Build solutions based on the strategies
41

42. Threat model
• Basic components
– Attacker modelling
• Choose what attacker to consider
– insider vs. outsider?
– single vs. collaborator?
• Attacker motivation and capabilities
– Attacker goals
– Vulnerabilities / threats
42

43. Trust context and threat models
• The core issue here is the levels of trust
– Many cloud computing providers trust their customers
– Each customer is physically commingling its data with data from anybody
else using the cloud while logically and virtually you have your own space
– The way that the cloud provider implements security is typically focused on
they fact that those outside of their cloud are evil, and those inside are good.
• But what if those inside are also evil?
43

44. Attack vectors : Malicious insiders
• At client
– Learn passwords/authentication information
– Gain control of the VMs
• At cloud provider
– Log client communication
– Can read unencrypted data
– Can possibly peek into VMs, or make copies of VMs
– Can monitor network communication, application patterns
– Why?
• Gain information about client data
• Gain information on client behavior
• Sell the information or use itself
44

45. Attack vectors : Outside attacks
• What?
– Listen to network traffic (passive)
– Insert malicious traffic (active)
– Probe cloud structure (active)
– Launch DoS
• Goal?
– Intrusion
– Network analysis
– Man in the middle
– Cartography
45

46. Cloud Security Solution Design
46

47. Security issues in the cloud
• In theory, minimising any of the issues would help:
– Third Party Cloud Computing
– Loss of Control
• Take back control
– Data and apps may still need to be on the cloud
– But can they be managed in some way by the consumer?
– Lack of trust
• Increase trust (mechanisms)
– Technology
– Policy, regulation
– Contracts (incentives)
– Multi-tenancy
• Private cloud
– Takes away the reasons to use a cloud in the first place
• VPC: its still not a separate system
• Strong separation
47

48. Third party cloud computing
• Known issues: Already exist
• Confidentiality issues
• Malicious behaviour by cloud provider
• Known risks exist in any industry practicing outsourcing
• Provider and its infrastructure needs to be trusted
48

49. New vulnerabilities and attacks
• Threats arise from other consumers
• Due to the subtleties of how physical resources can be transparently shared
between VMs
• Such attacks are based on placement and extraction
• A customer VM and its adversary can be assigned to the same physical
server
• Adversary can penetrate the VM and violate customer confidentiality
49

50. More on attacks
• Collaborative attacks
• Mapping of internal cloud infrastructure
• Identifying likely residence of a target VM
• Instantiating new VMs until one gets co-resident with the target
• Cross-VM side-channel attacks
• Extract information from target VM on the same machine
50

51. More on attacks
1. Can one determine where in the cloud infrastructure an instance is located?
2. Can one easily determine if two instances are co-resident on the same
physical machine?
3. Can an adversary launch instances that will be co-resident with other user
instances?
4. Can an adversary exploit cross-VM information leakage once co-resident?
Answer: Yes to all
51

52. Minimise lack of trust : Policy language
• Consumers have specific security needs but don’t have a say-so in how they are handled
– Currently consumers cannot dictate their requirements to the provider (SLAs are one-sided)
• Standard language to convey one’s policies and expectations
– Agreed upon and upheld by both parties
– Standard language for representing SLAs
• Create policy language with the following characteristics:
– Machine-understandable (or at least processable),
– Easy to combine/merge and compare
52

53. Minimise lack of trust : Certification
• Certification
– Some form of reputable, independent, comparable assessment and description
of security features and assurance
• Sarbanes-Oxley, DIACAP, DISTCAP, etc
• Risk assessment
– Performed by certified third parties
– Provides consumers with additional assurance
53

54. Minimise Lose of Control : Monitoring
• Cloud consumer needs situational awareness for critical applications
– When underlying components fail, what is the effect of the failure to the mission logic
– What recovery measures can be taken
• by provider and consumer
• Requires an application-specific run-time monitoring and management tool for the consumer
– The cloud consumer and cloud provider have different views of the system
– Enable both the provider and tenants to monitor the components in the cloud that are under
their control
54

55. Minimise Loss of Control : Monitoring
– Provide mechanisms that enable the provider to act on attacks he can handle.
• infrastructure remapping
– create new or move existing fault domains
• shutting down offending components or targets
– and assisting tenants with porting if necessary
• Repairs
– Provide mechanisms that enable the consumer to act on attacks that he can handle
• application-level monitoring
• RAdAC (Risk-adaptable Access Control)
• VM porting with remote attestation of target physical host
• Provide ability to move the user’s application to another cloud
55

56. Minimise Lose of Control : Diversity
• The concept of ‘Don’t put all your eggs in one basket’
– Consumer may use services from different clouds through an intra-cloud or multi-cloud architecture
– A multi-cloud or intra-cloud architecture in which consumers
• Spread the risk
• Increase redundancy (per-task or per-application)
• Increase chance of mission completion for critical applications
– Possible issues to consider:
• Policy incompatibility (combined, what is the overarching policy?)
• Data dependency between clouds
• Differing data semantics across clouds
• Knowing when to utilize the redundancy feature
– monitoring technology
• Is it worth it to spread your sensitive data across multiple clouds?
56

57. Minimise Lose of Control : IAM
• Many possible layers of access control
– E.g. access to the cloud, access to servers, access to services, access to databases (direct and queries via web services),
access to VMs, and access to objects within a VM
– Depending on the deployment model used, some of these will be controlled by the provider and others by the consumer
• Regardless of deployment model, provider needs to manage the user authentication and access control procedures (to the cloud)
– Federated Identity Management: access control management burden still lies with the provider
– Requires user to place a large amount of trust on the provider in terms of security, management, and maintenance of
access control policies.
• This can be burdensome when numerous users from different organizations with different access control policies,
are involved
57

58. Minimise Multi Tenancy
• Can’t really force the provider to accept less tenants
– Can try to increase isolation between tenants
• Strong isolation techniques (VPC to some degree)
• QoS requirements need to be met
• Policy specification
– Can try to increase trust in the tenants
• Who’s the insider, where’s the security boundary? Who can I trust?
• Use SLAs to enforce trusted behavior
58

59. Cloud Security Solution Architecture
59

60. Cloud Architecture Constraints
» Costs and Resources
‣ The cloud provider’s financial resources will act to constrain investment in technology, security controls included. But it is
important to recognize that the absence of unlimited resources can be very motivating to how one designs, architects, and
builds.
» Reliability
‣ This is a quality that refers to the degree you can depend on a system to deliver its stated services. Reliability can be described
as a guarantee that the underlying technology can provide delivery of services
» Performance
• A measure of one or more qualities that have to do with the usefulness of a system.
» The Security Triad
• The essential security principles of confidentiality, integrity, and availability apply to most of the systems.
» Legal and Regulatory Constraints
60

61. 61

62. 62

63. Cloud encryption tools and techniques
63

64. Cloud Encryption major components
64

65. Cloud Firewalls
65

66. Cloud Firewall categories
‣ Cloud-based firewalls come in two delicious flavours: vanilla and
strawberry.
‣ Both flavours are software that checks incoming and outgoing
packets to filter against access policies and block malicious traffic.
66

67. Cloud firewall categories
‣ Vanilla firewalls are usually stand-alone products or services designed to protect an enterprise network
and its users—like an on-premises firewall appliance, except that it’s in the cloud.
‣ Service providers call this a software-as-a-service (SaaS) firewall, security as a service (SECaaS), or even
firewall as a service (FWaaS)
‣ By contrast, strawberry firewalls are cloud-based services that are designed to run in a virtual data center
using your own servers in a platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS) model.
‣ In these cases, the firewall application runs on the virtual servers and protects traffic going to, from, and
between applications in the cloud.
‣ The industry sometimes calls these next-generation firewalls, though the term is inconsistently applied
and sometimes refers to any advanced firewall system running on-prem or in the cloud.
67

68. Cloud firewall value proposition
What makes a cloud-based firewall different from an on-premise firewall (other than being
off-premise) comes down to three things: scalability, availability and extensibility.
Scalability: Cloud-based firewall providers deliver services to multiple customers and at
the core of their service they use firewalls designed to scale to meet ever-increasing
demand.
From the enterprise perspective this scalability comes into play when bandwidth increases.
Unlike an on-premise firewall that needs replacement when bandwidth exceeds firewall
throughput, cloud-based firewalls are designed to scale as customer bandwidth increases—
or at least any hardware upgrade has to be made transparent to customers. Availability:
68

69. Cloud firewall advantage layers
‣ Cloud-based firewall providers offer extremely high availability (> 99.99%) through an infrastructure with fully
redundant power, HVAC, and network services, as well as backup strategies in the event of a site failure.
‣ In contrast, on-premise firewalls are only as reliable as the existing IT infrastructure, which may not be an issue at
the data centre but could be at the branch.
‣ High availability is certainly possible but depending on the manufacturer, high-availability can double the cost of
hardware and make operations more complex.
‣ Extensibility: Cloud-based firewalls are available anywhere the network manager can provide a protected
communications path. Given interconnection agreements between network providers, the footprint of service
may extend well beyond the boundaries of any single service provider’s network.
‣ An on-premise firewall on the other hand may be deployed at any corporate location, with the associated capital
cost (higher for redundancy)—if there is enough space and the necessary out-of-band management connection.
69

70. Cloud malware propagation
70

71. Cloud Malware Attack Types
» DDoS Attacks
• Botnets are becoming more and more common, with malware-as-a-service
being offered by more malicious actors at an increasingly cheap price.
• Self-service cloud offerings allow these attackers to easily gain access and
notoriety by launching large-scale DDoS attacks, which have been
measured at speeds of up to 30 Gbps.
• Since cloud computing hosts multiple customers in a single cloud, these
attacks can affect your cloud environment, as well.
71

72. Cloud Malware Attack Types
» Hypercall Attacks
• An attacker uses a Virtual Machine (VM) to intrude the victim’s VM by exploiting the Virtual Machine Manager
(VMM) hypercall handler.
• This gives the attacker the ability to access VMM privileges and possibly even execute malicious code.
» Hypervisor DoS
• This attack uses a high percentage of your hypervisor’s resources in order to leverage flaws in design or setup.
• Researchers found that this malware accounted for 70 percent of malware attacks targeting cloud providers’
hypervisor, which manages customers’ virtual environments.
• One study found that 71.2 percent of all Xen and 65.8 percent of all KVM vulnerabilities could be exploited by
a guest VM.
72

73. Cloud Malware Attack Types
‣ Co-Location
‣ An attacker tries to find the target VM’s host in order to place their own VM on the same host. This is used
to gain leverage in cross-VM side-channel attacks, such as Flush/Reload or Prime and Probe.
‣ Hyperjacking
‣ This is where an attacker tries to take control of the hypervisor, sometimes using a virtual machine-based
rootkit. If the attacker is successful, they will have access to the entire machine. This could be used to
change the behavior of the VM, causing it to be partially or fully compromised.
‣ Man in the middle (MITM)
‣ MITM is when an attacker can intercept and/or change messages exchanged between users. Ghostwriter is
a common precursor to a MitM attack. This allows the attacker access to a misconfigured cloud
configuration with public write access.
73

74. Cloud Malware Attack Types
‣ Exploiting Live Migration
‣ During migration from one cloud service provider to another, the cloud management system is tricked into creating multiple migrations,
which turns into a denial-of-service attack. This can also be used to potentially craft a VM Escape.
‣ VM Escape
‣ This accounts for 13.1 percent of all malware attacks on virtual machines in cloud environments. VM Escape involves running in a VM and
escaping to infect the hypervisor. The goal in this attack is to obtain root privileges, host OS control and maybe even full access across the
environment.
‣ Flush/Reload
‣ This attack utilises a memory optimisation technique known as memory deduplication. By enacting a sophisticated cross side-channel
technique, a malicious actor can detect a full AES encryption key.
‣ Prime and Probe
‣ This is a VM cross side-channel attack that utilises cache instead of memory. The attacker fills the cache with some of their own information.
Once the victim uses the VM, the attacker uses this information to see which cache lines were accessed by the victim. This method has been
used to recover an AWS encryption key.
74