🔐 Chapter 15 — Cloud Security & Privacy Cheat Sheet

Core Problem: Cloud = a black box. You hand over your data and compute to someone else. Even if the provider is honest, malicious insiders, co-tenants, and outside attackers are real threats. Security in the cloud is fundamentally about loss of control, lack of trust, and multi-tenancy.

🏦 Analogy: เหมือนฝากเงินกับธนาคาร แต่ไม่รู้เลยว่าข้างในทำอะไรกับเงินเรา แม้ธนาคารจะซื่อสัตย์ แต่พนักงานอาจไม่ใช่

"Cloud Computing is a security nightmare and it can't be handled in traditional ways." — John Chambers, Cisco CEO

🗺️ Part 1 — Big Picture: Three Root Causes

These three problems exist mainly in 3rd-party managed clouds.
Self-managed clouds have security issues too, but not these three specifically.

😨 Part 2 — Taxonomy of Fear (What Are We Afraid Of?)

Confidentiality ← Most feared in the cloud!

• Will sensitive data stored on a cloud remain confidential?
• Will cloud compromises leak confidential client data?
• Will the cloud provider itself peek into the data?

Integrity

• How do I know the cloud provider is doing computations correctly?
• How do I ensure my data wasn't tampered with?

Availability

• Will a DoS attack bring critical systems down?
• What if the cloud provider goes out of business?
• Will the cloud scale well enough?

Privacy

• Massive data mining risk — cloud stores many clients' data → can run mining algorithms on it
• Increased attack surface — attacker can target the communication link between client and cloud
• Cloud provider employees can be phished

Auditability & Forensics

• Difficult to audit data held outside the organization
• Clients don't maintain data locally → forensics is harder

💡 If you want to audit → implement it yourself (log files, auditing mechanisms)

Legal Quagmire & Transitive Trust

• Who is responsible for complying with: SOX, HIPAA, GLBA, GDPR, PDPA?
• If provider subcontracts to a third-party cloud — is your data still safe?

🧑‍💻 Part 3 — Attacker Types & Capabilities

Malicious Insider (Client Side)

• Learn passwords / authentication tokens
• Gain control of VMs

Malicious Insider (Provider Side)

• Log client communication
• Read unencrypted data
• Peek into or copy VMs
• Monitor network patterns
• Why? Sell information or use it directly

Outside Attacker

Attacker Challenges

• How to find where the target VM lives in the cloud?
• How to become co-located on the same physical machine?
• How to extract information from target once co-located?

All answers: ✅ Yes — researchers have shown all of these are practically feasible.

🧾 Part 4 — Threat Model

A structured way to analyze, design, and evaluate security:

Step 1: Identify attackers, assets, threats, and components
Step 2: Rank the threats (severity + likelihood)
Step 3: Choose mitigation strategies
Step 4: Build solutions

Components

• Attacker Modeling — Insider vs outsider? Single vs collaborator? Capabilities?
• Attacker Goals — What are they trying to achieve?
• Vulnerabilities / Threats — What weaknesses exist?

☁️ Part 5 — Top 9 Cloud Threats (CSA)

✅❌ Part 6 — Due Diligence vs. Due Care

⚠️ Due Diligence comes BEFORE Due Care — it is a management process used to gather facts before decisions.

🏗️ Part 7 — Infrastructure Security (3 Levels)

Level 1: Network Level

• Ensure confidentiality & integrity of data-in-transit (e.g., TLS)
• Ensure proper access control (authentication, authorization, auditing)
• Ensure availability of Internet-facing resources
• Replace network zones/tiers model with domains

Level 2: Host Level

• SaaS / PaaS → abstract the host OS → host security responsibility transferred to CSP
• As a customer: you don't manage hosts, but you still own the risk of data

Local Host Security ⚠️ Often Forgotten!

• Local machines are outside the cloud security perimeter
• A compromised local device can:
  • Let malicious cloud services attack local networks
  • Compromise the cloud for other users
• Local devices accessing cloud should have:
  • Strong authentication mechanisms
  • Tamper-resistant design
  • Strong app isolation
  • Trusted OS
  • Cryptographic functionality for traffic confidentiality

Level 3: Application Level

💸 EDoS Analogy: เหมือนให้คนมากด Grab Food สั่งทิ้งไว้ตลอด จนร้านต้องเสียค่าใช้จ่ายจนเจ๊ง

⚠️ Final Exam: For web application protection, both the cloud provider AND consumer share responsibility.
At minimum: cloud provider must provide a Web Application Firewall (WAF).

💾 Part 8 — Data Security & Storage

Data States

Homomorphic Encryption vs. Predicate Encryption

Data Remanence

• Residual representation of data that remains even after deletion attempts
• Example: encryption key left in memory → Data Remanence
• Mitigation:
  • Don't place sensitive data in a public cloud
  • Encrypt data before placing it in the cloud
• For sure destruction of data:
  • Degaussing (magnetic field scramble — works on HDD, NOT SSD)
  • Shredding / Crushing / Incineration (physical destruction)
  • Overwriting (software wipe)

Searchable Encryption Model

Data Owner: encrypt files + encrypt index → send to Cloud
User: request → get trapdoor → use trapdoor to search encrypted index
→ retrieve matching encrypted files → decrypt locally

🔑 Part 9 — Identity & Access Management (IAM)

Why IAM Matters

• Organization's trust boundary becomes dynamic (extends to provider domain)
• Must manage access for: employees, contractors, partners
• Personal/financial/medical data now in the cloud → need higher-assurance authentication
• Authentication now happens outside the firewall
• Need to support authentication from mobile devices

Access Control Architecture: SAML + XACML ⚠️ Final Exam!

[Consumer Domain B]
  1. AuthN request → IDP
  2. ← SAML Assertion (identity token)
  3. Resource request + SAML assertion → [Cloud Provider Domain A]
       4. Redirect to resource owner's domain
       5. Retrieve policy for resource → PDP
       6. PDP decides: grant or deny
          → creates signed+encrypted ticket → ACM (XACML policies)
       7. ← Signed + Encrypted ticket
  4. Decrypt + verify signature → PEP
  5. Retrieve capability from ticket
  6. Grant or deny access

Key Components ⚠️ Final Exam!

Most important component for regaining control from the cloud provider = ACM — because it controls the policy.

Key used to sign and encrypt the ticket = PEP Cloud's Public Key

Consumer-Managed Access Control

• Consumer keeps the PDP in their own domain → retains decision authority
• Requires:
  • Pre-existing trust relationship with provider
  • Pre-negotiated standard for describing resources, users, and decisions
  • Provider upholds consumer-side access decisions

🔒 Part 10 — Privacy

What is Privacy?

• About the collection, use, disclosure, storage, and destruction of PII (Personally Identifiable Information)
• Two core principles:
  • Accountability — organizations accountable to data subjects
  • Transparency — clear about how personal data is handled

🔍 Security vs. Privacy:

• Security = a developer/technical concern
• Privacy = a general public concern

Key Privacy Dimensions

Responsibility Paradox

Example: Hacker breaks into Cloud Provider A → steals data from Company X. Server also has Y & Z's data.

• Who investigates?
• Does Company X have the right to see logs of the provider's server?

• Organizations can transfer liability — but not accountability
• Data stewardship responsibility stays with the data owner

Data Destruction Methods

🛡️ Part 11 — Cloud DLP (Data Loss Prevention)

DLP = process for protecting sensitive data at rest, in-transit, and on endpoints.

Cloud DLP specifically:

• Ensures sensitive data is encrypted before entering the cloud
• Ensures data only goes to authorized cloud applications
• Removes or alters classified/sensitive data before files are shared to cloud
• Can integrate with on-premise systems (hybrid model)

🔍 DLP checks: does this file contain PII? If so → block or encrypt before sending!

Key Benefits of Cloud DLP

• Scan servers + identify and encrypt sensitive data before sharing
• Continuously audit uploaded files
• Automatically apply controls: prompt, block, or encrypt
• Instantly alert admins when data is at risk
• Maintain compliance with privacy regulations

🖥️ Part 12 — VM Security: Co-Tenancy Attacks

New Vulnerabilities in VM Environments

• Threats from other consumers (co-tenants) on the same physical machine
• Attacks based on placement and extraction:
  • Map cloud infrastructure
  • Identify likely physical location of target VM
  • Instantiate new VMs until co-resident with target
  • Extract information via cross-VM side-channel attacks

Side-Channel Attack

• Exploits indirect hardware effects rather than attacking code directly
• Gathers information by measuring: timing, power consumption, electromagnetic emissions, cache behavior
• Goal: extract cryptographic keys or sensitive data from a co-located VM

👂 Analogy: เหมือนแอบฟังเสียงพิมพ์คีย์บอร์ดของคนอื่น แทนที่จะแฮ็ครหัสผ่านตรงๆ

Are cryptographic side-channel attacks possible in a virtualization environment?
✅ Yes — because VMs share physical resources (CPU, cache, memory). Data in shared resources can leak.

🛡️ Part 13 — Prevention: Cross-VM Attack Mitigations

A. Hardware-Level Defenses

• Cache Partitioning
• Intel CAT (Cache Allocation Technology) — prevents cache sharing between VMs

B. Hypervisor / System-Level Defenses

• VM Isolation Policy — avoid co-locating sensitive workloads
• Dedicated cores for high-security VMs

C. Oblivious RAM (ORAM) — Advanced Defense

• Hides access patterns completely — even if data is encrypted, an attacker watching access patterns can infer what you're doing
• ORAM makes all accesses look random and indistinguishable
• Implemented inside: secure processors, memory controllers, TEEs (Intel SGX)

🌳 Part 14 — ORAM (Oblivious RAM) ⚠️ Final Exam: Path ORAM Steps!

The Problem ORAM Solves

Even with encrypted data, an attacker can still observe:

• Which memory locations are accessed
• How often and in what order
• Access patterns over time → reveals what you're doing

📚 Analogy: ORAM = ไปหยิบหนังสือในห้องสมุด แต่แทนที่จะเดินตรงไปหยิบเล่มที่ต้องการ เราเดินวนหยิบหลายๆ เล่มสุ่มๆ ทำให้คนสังเกตไม่รู้ว่าเราต้องการเล่มไหน

Data is remapped every time it's accessed → obfuscates access patterns.
ORAM data disappears when power is off (stored in RAM).
ORAM overhead: too many reads/writes → active research area!

🌳 Part 15 — Path ORAM: 5 Steps ⚠️ Final Exam!

Path ORAM organizes data in a binary tree of buckets. Each block is mapped to a leaf.

Step 1: Program Requests Data (address a)

• CPU queries the Position Map (on trusted side)
• Learns: block a is currently mapped to leaf $s = 5$

Step 2: Read Path (root → leaf 5)

• ORAM reads the entire path from root to leaf 5 from untrusted DRAM
• Reads multiple buckets along the path (not just the target block)
• A block can be stored in any node along its assigned path

Step 3: Load into Stash → Return Data

• All blocks on the path are decrypted → temporarily stored in Stash (secure buffer)
• Target block a is found in stash → returned to program

Step 4: Remap (assign new random leaf)

• Block a is assigned a new random leaf (e.g., old = 5 → new = 2)
• Position Map is updated

Step 5: Write Path Back (root → leaf 5)

• Write data back to the same path (root → leaf 5)
• Place back: some real blocks, some dummy blocks
• Ensures: storage looks consistent + access pattern remains hidden

Key Mechanisms in Step 3

Position Map (trusted client side):
  block a → leaf 5

Binary Tree (untrusted DRAM):
         [Root]
        /       \
   [Node]       [Node]
   /    \       /    \
[L1]  [L2]  [L3]  [Leaf 5 ← target]

Read entire path root→leaf5, decrypt all, stash, return a, remap to random leaf, write back

🔄 Part 16 — Minimize Loss of Control (4 Sub-Areas)

1. Monitoring

• Consumer needs situational awareness for critical apps
• Cloud consumer and cloud provider have different views of the system

2. Utilize Different Clouds (Multi-Cloud)

• "Don't put all your eggs in one basket"
• Spread risk + increase redundancy + increase mission completion probability

3. Access Control (see Part 9 — SAML + XACML)

4. Identity Management (IDM) (see Part 17)

🆔 Part 17 — Identity Management (IDM) in the Cloud ⚠️ Final Exam!

The Problem

Users on Amazon Cloud must share: Name, Email, Password, Billing Address, Shipping Address, Credit Card — with Amazon AND multiple services.

Problem: Too much PII disclosed unnecessarily to each service.

Goals of User-Centric IDM

1. Authenticate without disclosing identifying information
2. Securely use services even on an untrusted host (cloud VM)
3. Minimal disclosure — reduce risk of MITM, Side-Channel, and Correlation attacks
4. Independence from a Trusted Third Party

IDM Approach 1: IDM Wallet + Anonymous Identification (ZKP)

IDM Wallet = uses Active Bundle (AB) scheme to protect PII from untrusted hosts
Anonymous Identification = uses Zero-Knowledge Proof (ZKP) to authenticate without revealing the identifier

🔐 ZKP: Prove you know a secret without revealing the secret itself — like proving you know a password without saying it

Active Bundle (AB) Components

Shamir's Anonymous Identification (Credit Card ZKP)

1. IdP provides Encrypted Identity Information to both User and Service Provider
2. User and SP interact
3. Both run IdP's public function on certain bits of encrypted data
4. Exchange results → if they match → identity confirmed (without revealing raw data)

IDM Approach 2: Predicate over Encrypted Data + Multi-Party Computing

• Active Bundle → protects PII on untrusted hosts
• Predicates over Encrypted Data → authenticate without decrypting identity data
• Multi-Party Computing → independent of any single trusted third party

Predicate over Encrypted Data Flow

User has: Email, Password, E(Name), E(Shipping), E(Billing), E(CreditCard)

SP sends predicate request:
  → Age Verification: age ≥ 18?
  → Credit Card Verification: card valid?

SP receives: E(Name), E(Billing), E(CreditCard)
SP verifies predicate → WITHOUT seeing raw data ✅

Multi-Party Computing for Key Independence

• Multiple services hold shares of the secret key: $K'_1, K'_2, K'_3, \ldots, K'_n$
• No single party holds the full key → minimizes risk of breach
• Decryption handled by Key Management Services cooperatively
• Result: Age Verified ✅, Credit Card Verified ✅

Selective Disclosure (Active Bundle in Action)

FedEx gets only Name + Shipping Address. eBay gets Name + Shipping. Nobody gets raw data. 🔒

Full Amazon Cloud Flow

User has: Name, Email, Password, Billing, Shipping, Credit Card

Amazon:   receives Email + Password (login) + Name + Billing + Card (payment)
FedEx:    receives Name + Shipping (delivery)
E-mail:   receives Email only

IDM Key Characteristics

🧩 Quick Reference Summary

⚠️ Final Exam Reminders

1. SAML + XACML flow — be able to trace all 10 steps; know what PEP, PDP, ACM each do

   • Most important component for regaining control = ACM
   • Key used to sign/encrypt ticket = PEP Cloud's Public Key

2. Path ORAM — know all 5 steps (request → read path → stash → remap → write back); know the 4 mechanisms (shuffling, dummy accesses, position map, stash)

3. Web Application Security — both cloud provider AND consumer responsible; at minimum, cloud must provide a Web Application Firewall (WAF)

4. Due Diligence vs Due Care — diligence comes FIRST (verify), care is ongoing (implement)

5. Active Bundle + ZKP — understand how IDM Wallet protects PII using predicates + multi-party computing + selective disclosure; know what happens on untrusted hosts (apoptosis/evaporation)

6. EDoS — distinguish from regular DoS: targets billing model, not just availability