Cloud Security: Threats, Controls, and Best Practices

TAKEAWAYS:

• Cloud security threats (e.g., data breaches, DDoS, insider threats) require layered defenses like encryption, IAM, and network segmentation.
• Shared responsibility models define who (cloud provider vs. user) secures what in IaaS, PaaS, and SaaS.
• Encryption (at rest, in transit) and key management are essential for protecting sensitive data in cloud storage.
• Compliance frameworks (ISO 27001, GDPR, HIPAA) guide security policies for industries like healthcare and finance.
• Zero Trust Architecture and multi-factor authentication (MFA) mitigate unauthorized access risks.
• Real-world examples (e.g., eSewa’s PCI-DSS compliance, Ncell’s DDoS protection) show how security directly impacts trust and operations.

1. Introduction to Cloud Security

Cloud security is the practice of protecting data, applications, and infrastructure in cloud environments from threats, unauthorized access, and breaches. Unlike traditional IT, cloud security involves shared responsibility between the cloud provider (e.g., AWS, Azure) and the customer. Key challenges include:

• Data breaches: Unauthorized access to sensitive information (e.g., customer records, financial data).
• Insider threats: Employees or contractors misusing access privileges.
• DDoS attacks: Overloading cloud services to disrupt operations (e.g., Nepal’s NTC website crashes during peak hours).
• Compliance risks: Failing to meet industry regulations (e.g., GDPR for EU data, Nepal’s Data Privacy Act).

Why Cloud Security Matters

Cloud adoption in Nepal (e.g., eSewa for payments, Daraz for e-commerce) relies on trust. A single breach can lead to:

• Financial losses (e.g., Khalti’s 2021 data leak exposed user details).
• Legal penalties (e.g., fines under GDPR for non-compliance).
• Reputation damage (e.g., Pathao’s security concerns affecting rider trust).

2. Shared Responsibility Model

The shared responsibility model clarifies security tasks between the cloud provider and the user. The division varies by service model:

Worked Example: Securing a Daraz Order Queue

Daraz uses IaaS (AWS) to host its e-commerce platform. The shared responsibilities are:

1. AWS secures: Physical servers, virtualization layer, network routing.
2. Daraz secures:
   • Customer data encryption (AES-256 for payment details).
   • IAM policies (e.g., restricting admin access to order databases).
   • DDoS protection (AWS Shield for traffic spikes during sales).

MERMAID DIAGRAM:

flowchart TD
    A["Cloud Provider"] -->|"Physical Security"| B["Data Centers"]
    A -->|"Network Security"| C["Firewalls/DDoS Protection"]
    A -->|"Compliance Certifications"| D["ISO 27001/GDPR"]
    B -->|"Hypervisor Security"| E["Virtual Machines"]
    E -->|"Customer Responsibility"| F["OS Patching"]
    E -->|"Customer Responsibility"| G["Application Security"]
    E -->|"Customer Responsibility"| H["Data Encryption"]

3. Key Security Threats in Cloud Computing

A. Data Breaches and Leakage

• Cause: Weak encryption, misconfigured storage (e.g., AWS S3 buckets left public).
• Example: Khalti’s 2021 breach exposed 200,000+ user records due to poor access controls.
• Mitigation:
  • Encryption at rest (AES-256 for databases).
  • Tokenization (replacing card numbers with tokens, like eSewa’s PCI-DSS compliance).

B. Denial-of-Service (DoS/DDoS) Attacks

• Cause: Attackers flood services with traffic (e.g., NTC’s website crashes during exams).
• Mitigation:
  • AWS Shield (free tier for basic DDoS protection).
  • Rate limiting (e.g., Pathao’s API throttling to prevent ride-hailing abuse).

C. Insider Threats

• Cause: Employees or contractors with excessive privileges (e.g., a Daraz IT admin selling customer data).
• Mitigation:
  • Least privilege access (e.g., Nepal Rastra Bank’s audit logs).
  • Behavioral analytics (AI detecting anomalies in access patterns).

D. Account Hijacking

• Cause: Weak passwords or phishing (e.g., WhatsApp hacking via SIM swapping).
• Mitigation:
  • Multi-Factor Authentication (MFA) (SMS/OTP + biometrics).
  • Password managers (e.g., 1Password for corporate accounts).

E. Insecure APIs

• Cause: Poorly designed APIs exposing backend data (e.g., Facebook’s 2018 breach via third-party apps).
• Mitigation:
  • API gateways (e.g., AWS API Gateway with rate limiting).
  • OAuth 2.0 for secure authentication (used by Google Sign-In).

A network diagram showing how a botnet floods a target server with requests, causing downtime. (Image: Nasanbuyn, CC BY-SA 4.0, via Wikimedia Commons)

4. Security Controls and Best Practices

A. Encryption

Cloud data must be encrypted:

• At rest: Data stored in databases (e.g., SQL Server encryption).
• In transit: Data moving between client and server (e.g., TLS 1.3 for HTTPS).
• Key management: Use AWS KMS or Azure Key Vault to store encryption keys securely.

B. Identity and Access Management (IAM)

• Principle of Least Privilege: Grant only necessary permissions (e.g., a Daraz customer support agent should not access financial data).
• Role-Based Access Control (RBAC): Assign roles like Admin, Developer, Auditor.
• MFA: Enforce for all admin accounts (e.g., Nepal Rastra Bank’s MFA for online banking).

C. Network Security

• Firewalls: Filter traffic between cloud resources (e.g., AWS Security Groups).
• VPNs: Secure remote access (e.g., NTC engineers using VPNs to manage network devices).
• Segmentation: Isolate sensitive workloads (e.g., Nepal’s election commission’s separate cloud network).

D. Compliance and Auditing

• Frameworks:
  • ISO 27001: Information security management.
  • GDPR: EU data protection (applies to Nepalese companies handling EU citizen data).
  • HIPAA: Healthcare data security (used by Kathmandu’s CIAA hospitals).
• Tools:
  • AWS Config (audit resource configurations).
  • Azure Sentinel (threat detection).

MERMAID DIAGRAM:

erDiagram
    USER ||--o{ ROLE : "has"
    ROLE ||--o{ PERMISSION : "grants"
    PERMISSION ||--|| RESOURCE : "applies to"
    USER {
        string username
        string email
        boolean mfa_enabled
    }
    ROLE {
        string role_name
        string description
    }
    PERMISSION {
        string permission_name
        boolean is_active
    }
    RESOURCE {
        string resource_id
        string type "e.g., S3 Bucket, EC2"
    }

5. Zero Trust Architecture

Traditional security assumes trust inside the network. Zero Trust assumes no trust by default and verifies every request:

1. Verify explicitly: Check identity (e.g., MFA for eSewa logins).
2. Use least privilege: Limit access (e.g., a bank teller cannot transfer funds).
3. Assume breach: Monitor for anomalies (e.g., Ncell detecting unusual SIM swaps).

Example: Ncell’s Zero Trust for Customer Data

• Step 1: Customer logs in via MFA (OTP + fingerprint).
• Step 2: The system checks if the device is trusted (not jailbroken).
• Step 3: Access to billing data is temporary and logged.

6. Cloud Security Standards and Certifications

MERMAID DIAGRAM:

mindmap
  root((Cloud Security Standards))
    ISO 27001
    GDPR
      Applies to: EU Data
      Penalties: Fines up to 4% of revenue
    PCI-DSS
      Focus: Payment Security
      Requirements: Encryption, Access Controls
    HIPAA
      Focus: Healthcare Data
      Example: Patient Records
    SOC 2
      Focus: Cloud Provider Audits
      Example: AWS SOC 2 Report

7. Real-World Applications in Nepal

A. eSewa’s PCI-DSS Compliance

• Challenge: Handling credit card transactions securely.
• Solution:
  • Tokenization: Replaces card numbers with tokens.
  • Encryption: AES-256 for transaction data.
  • Regular audits: PCI-DSS compliance checks.

B. Ncell’s DDoS Protection

• Challenge: Preventing service disruptions during peak usage (e.g., New Year sales).
• Solution:
  • AWS Shield Advanced: Blocks large-scale attacks.
  • Rate limiting: Drops malicious traffic before it reaches servers.

C. Nepal Rastra Bank’s Cloud Security

• Challenge: Securing financial transactions in the cloud.
• Solution:
  • Zero Trust: MFA + device checks for all logins.
  • ISO 27001: Aligns with international banking standards.

8. Common Mistakes to Avoid

1. Over-permissive IAM roles: Giving admins full access without monitoring.
2. Ignoring patch management: Unpatched VMs are easy targets (e.g., Log4j vulnerabilities).
3. Storing secrets in code: Hardcoding API keys (e.g., GitHub repos leaking AWS keys).
4. Skipping backups: Relying only on cloud provider snapshots (use 3-2-1 rule: 3 copies, 2 media, 1 offsite).
5. Neglecting compliance: Assuming "the cloud is secure" without audits.

Exam Tip

How This Unit is Examined

1. Definitions and Concepts (20%):

   • Explain shared responsibility model, Zero Trust, or encryption at rest.
   • Example question: "Differentiate between IaaS and SaaS security responsibilities."

2. Scenario-Based Questions (30%):

   • Analyze a case (e.g., "How would you secure Daraz’s order database?").
   • Key points to include: Encryption, IAM, DDoS protection, compliance.

3. Diagrams and Comparisons (20%):

   • Draw a shared responsibility model or a Zero Trust flow.
   • Compare IAM vs. RBAC in a table.

4. Short Answer (20%):

   • Define tokenization, PCI-DSS, or AWS KMS.
   • Example: "What is the purpose of MFA in cloud security?"

5. True/False or Fill-in-the-Blank (10%):

   • "GDPR applies only to EU-based companies." (False—applies to global companies handling EU data).
   • "______ is used for encrypting data in transit." (Answer: TLS/SSL).

Top 3 Exam Strategies

1. Memorize the shared responsibility table—it’s a common question.
2. Practice drawing diagrams (e.g., Zero Trust flow, DDoS attack).
3. Relate to Nepalese examples (e.g., eSewa, Ncell, NTC) to make answers stand out.