Data Security & Encryption in Cloud: Threats, Controls & Real-World Cases

Core Concepts: Why Cloud Security is Different

Cloud computing shifts security responsibilities from on-premise IT teams to shared models where data resides on third-party servers (often across multiple jurisdictions). This creates unique challenges:

1. The CIA Triad in Cloud Context

The Confidentiality, Integrity, Availability (CIA) triad must be enforced across:

• Multi-tenant environments (one physical server hosts data for multiple customers).
• Dynamic scaling (virtual machines spin up/down automatically).
• Geographic distribution (data may replicate across continents).

stateDiagram-v2
    [*] --> CIA_Threats: Cloud-Specific Risks
    CIA_Threats --> Confidentiality: Data Leakage (e.g., insider threats, misconfigured S3 buckets)
    CIA_Threats --> Integrity: Tampering (e.g., malicious VM modifications)
    CIA_Threats --> Availability: DDoS (e.g., 2016 Dyn attack taking down Twitter)
    CIA_Threats --> Accountability: Audit gaps (e.g., "who deleted this record?")
    CIA_Threats --> Compliance: Jurisdictional conflicts (e.g., GDPR vs. local laws)

2. Encryption: The First Line of Defense

Symmetric vs. Asymmetric Encryption

Worked Example: AES-256 for e-Governance Documents

1. Scenario: A district office uploads citizen ID scans to the cloud.
2. Process:
   • Document → AES-256-CBC (128-bit IV + 256-bit key) → Encrypted blob stored in S3.
   • Key stored in AWS KMS (Key Management Service) with IAM policies restricting access to "DistrictOfficer" role.
3. Real-World Tie: Nepal’s e-Dhoka project uses similar encryption for land records to prevent tampering.

3. Access Control Models

Role-Based Access Control (RBAC)

• Definition: Permissions tied to roles (e.g., "AuditAdmin", "DataAnalyst") rather than individual users.
• Example: In NEPSE’s cloud dashboard, only "Regulator" role can view IPO filings.

Attribute-Based Access Control (ABAC)

• Definition: Granular policies based on attributes (time, location, device, data sensitivity).
• Example: Khalti’s API allows transactions only from:
  • Devices with Nepal IP ranges,
  • Between 9 AM–6 PM (local time),
  • For amounts < Rs. 50,000 (unless KYC-verified).

erDiagram
    USER ||--o{ ROLE : "has"
    ROLE ||--o{ PERMISSION : "grants"
    PERMISSION }|--|| RESOURCE : "applies to"
    RESOURCE {
        string name
        string sensitivity_level
    }
    USER {
        string id
        string location
        datetime last_active
    }

4. Real-World Security Breaches and Lessons

Case Study 1: eSewa’s 2021 Data Leak

• What Happened: Unencrypted backup tapes containing 1.2 million user records (names, PAN numbers, transaction histories) were sold on the dark web.
• Root Cause:
  • Lack of encryption at rest for backups.
  • Weak access controls (third-party vendor had admin rights).
• Fix Applied:
  • Mandated AES-256 for all backups.
  • Implemented just-in-time (JIT) access for vendors.

Case Study 2: Ncell’s SIM Swap Attacks

• What Happened: Hackers exploited weak 2FA to take over 50,000 accounts, draining Rs. 200M+.
• Security Flaw:
  • SMS-based 2FA (vulnerable to SIM swaps).
  • No hardware tokens for high-value transactions.
• Cloud Security Lesson:
  • Multi-factor authentication (MFA) with TOTP (Time-based OTP) or FIDO2 keys.
  • Rate limiting on API calls to prevent brute force.

5. Compliance Frameworks and Standards

6. Secure Data Storage Techniques

Encryption in Transit vs. at Rest

Worked Example: Secure Database for NEPSE

• Requirement: Store shareholder data with column-level encryption.
• Solution:
  1. Use SQL Server Always Encrypted to encrypt shareholder_pan and transaction_amount.
  2. Store keys in Azure Key Vault with split knowledge (2 admins required).
  3. Apply row-level security to restrict access by market_segment.

7. Threat Detection and Incident Response

Common Cloud Threats

mindmap
  root((Cloud Threats))
    Data Breaches
      Insider Threats
      Misconfigured Storage
    DDoS Attacks
      Volumetric (UDP floods)
      Application Layer (API abuse)
    Account Hijacking
      Credential Stuffing
      Session Hijacking
    Malicious Insiders
    Shared Technology Vulnerabilities

Incident Response Plan (IRP) Steps

1. Detection: Use AWS GuardDuty or Azure Sentinel to flag anomalies.
2. Containment: Isolate affected VMs (e.g., AWS EC2 stop-instance).
3. Eradication: Patch vulnerabilities (e.g., CVE-2021-44228 in Apache Log4j).
4. Recovery: Restore from immutable backups (e.g., AWS Backup).
5. Post-Mortem: Update runbooks (e.g., "If ransomware detected, trigger auto-snapshot").

In the Real World

1. eSewa’s Encryption for Bill Payments

   • Idea Used: TLS 1.3 + AES-256 for end-to-end encryption of payment data.
   • How: When you pay a utility bill via eSewa:
     • Your browser → TLS handshake with eSewa’s server.
     • Payment details → AES-256 encrypted before hitting the database.
     • Tokenization: PAN numbers replaced with tokens (e.g., tok_abc123).

2. Ncell’s Secure API for Top-Up

   • Idea Used: OAuth 2.0 + JWT for API authentication.
   • How: When Pathao requests a top-up via Ncell’s API:
     • Pathao’s server → OAuth token request (client_credentials grant).
     • Ncell validates the token → JWT with short expiry (5 mins).
     • API response includes transaction ID + encrypted receipt.

3. Daraz’s Order Queue Security

   • Idea Used: Queue-based load leveling + encryption.
   • How: During sales (e.g., 11.11), Daraz uses:
     • Amazon SQS to manage order spikes (prevents DDoS).
     • KMS encryption for order data at rest.
     • Rate limiting (10 requests/sec per user).

Exam Tip: How to Score Full Marks

1. Diagrams > Text: Always draw CIA triad, encryption workflows, or access control models (use Mermaid).

   • Example: For "describe data security strategies," show a layered security diagram (physical → network → application).

2. Real-World Mapping: Tie every concept to Nepali examples (e.g., "eSewa uses AES-256 for...").

   • Example: For "explain symmetric encryption," say:

     "Nepal’s e-Governance portal encrypts citizen documents with AES-256 before storing them in Google Cloud Storage. The key is managed by Nepal’s National Data Center using a hardware security module (HSM)."

3. Comparison Tables: For questions like "differentiate between symmetric and asymmetric encryption," use a Markdown table with cloud use cases.

4. Worked Examples: Solve one numerical or trace example per question.

   • Example: For "calculate the impact of a DDoS attack," assume:

     "Ncell’s API handles 10,000 requests/sec normally. A DDoS sends 1M requests/sec. With AWS Shield, 90% are mitigated, but remaining 100K requests cause a 5-second delay per user. Calculate downtime cost if 50K users are affected (assume Rs. 200/hour/user)."

5. Compliance Shortcuts: Memorize these framework mappings:

   • GDPR → User consent, right to erasure.
   • ISO 27001 → Risk assessments, audit logs.
   • PCI DSS → Tokenization, secure APIs.

6. Avoid Common Pitfalls:

   • ❌ Saying "cloud is 100% secure" (always mention shared responsibility model).
   • ❌ Ignoring jurisdictional risks (e.g., storing Nepali citizen data in a US cloud may violate local laws).
   • ❌ Confusing encryption at rest (data stored) vs. in transit (data moving).

Pro Tip: For 5-mark questions, allocate marks as:

• 1 mark: Definition (e.g., "What is AES-256?").
• 2 marks: Diagram/explanation.
• 2 marks: Real-world example (e.g., "How does eSewa use it?").