Database Security: Threats, Controls, and Secure Design Principles

TAKEAWAYS:

• Database threats include SQL injection, unauthorized access, data leakage, and insider attacks—mitigated by defense-in-depth (e.g., firewalls + encryption + auditing).
• Access control models (DAC, MAC, RBAC) determine who can read/write data: DAC (owner-controlled), MAC (rule-based), RBAC (role-based, used in banks like Ncell for customer data).
• Encryption protects data-at-rest (AES-256) and in-transit (TLS/SSL); hashing (SHA-256) secures passwords (e.g., eSewa’s user authentication).
• Database auditing logs actions (e.g., Daraz’s order modifications) to detect fraud; backup/recovery ensures data availability (e.g., NTC’s network outage resilience).
• Secure design principles (least privilege, separation of duties, data masking) prevent insider threats (e.g., a Pathao driver accessing rider locations).
• Compliance (PCI-DSS for banks, GDPR for global firms) mandates security—e.g., NEPSE’s investor data protection under Nepal’s Electronic Transaction Act, 2008.

---

1. Introduction to Database Security

Databases store sensitive data (PII, financial records, intellectual property) and are prime targets for attacks. Unlike general IT security, database security focuses on:

• Confidentiality: Ensuring only authorized users access data (e.g., a bank employee viewing a customer’s loan details).
• Integrity: Preventing unauthorized modifications (e.g., altering NEPSE’s stock prices).
• Availability: Ensuring data is accessible when needed (e.g., eSewa’s transaction logs during Diwali sales).

Real-world example: eSewa’s secure transaction logs eSewa uses immutable audit logs (stored in encrypted databases) to track every transaction. If a user reports fraud, eSewa’s database triggers flag suspicious patterns (e.g., multiple high-value transfers in seconds) and lock the account until verified. This combines:

• Access control (only fraud analysts review logs).
• Encryption (AES-256 for stored logs).
• Non-repudiation (timestamps + digital signatures prevent users from denying transactions).

---

2. Database Vulnerabilities and Threats

Databases face unique risks due to their centralized nature and complex queries. Common threats:

---

3. Database Security Controls

Security is achieved through layers of controls:

A. Preventive Controls

1. Access Control Models

   • Discretionary Access Control (DAC): Owners decide who accesses data (e.g., a Google Drive folder shared with team members).
   • Mandatory Access Control (MAC): System enforces rules (e.g., military databases: TopSecret > Secret > Confidential).
   • Role-Based Access Control (RBAC): Permissions tied to roles (e.g., Ncell’s customer service agent can view accounts but not modify billing).

   Comparison Table:

   Model	Flexibility	Use Case	Example in Nepal
   DAC	High	Collaborative projects (e.g., Daraz inventory teams)	A warehouse manager shares stock data with suppliers.
   MAC	Low	Government/military (e.g., NRA data)	Nepal Police’s crime database (access restricted by rank).
   RBAC	Medium	Enterprises (e.g., banks)	Nabil Bank: Teller (deposit/withdraw), Manager (loan approval).

2. Encryption

   • Data-at-rest: Encrypt stored data (e.g., AES-256 for eSewa’s transaction history).
   • Data-in-transit: Use TLS/SSL (e.g., HTTPS for NEPSE’s trading portal).
   • Data-in-use: Memory encryption (e.g., SQL Server’s Always Encrypted for real-time queries).

3. Database Firewalls

   • Filters malicious SQL (e.g., Imperva’s database firewall blocks SQL injection in Khalti’s payment system).

B. Detective Controls

1. Auditing and Logging

   • Tracks actions (e.g., Oracle Audit Vault logs who accessed NEPSE’s investor data).
   • Example: Daraz logs every order modification to detect fraudulent returns.

2. Intrusion Detection Systems (IDS)

   • Monitors suspicious queries (e.g., Snort alerts if someone runs DELETE FROM customers in a bank’s DB).

C. Corrective Controls

1. Backup and Recovery

   • Full backup: Daily snapshots (e.g., NTC’s network config).
   • Incremental backup: Only changed data (e.g., Pathao’s ride logs).
   • Point-in-Time Recovery: Restore to a specific second (e.g., after a ransomware attack).

2. Data Masking

   • Hides sensitive data (e.g., showing ****-****-1234 for credit cards in training databases).

---

4. Secure Database Design Principles

Design databases with security in mind:

1. Least Privilege

   • Grant minimum permissions (e.g., a Khalti cashier can process payments but not view user PINs).
   • Example: NEPSE’s trading agents can only view stock prices, not modify investor portfolios.

2. Separation of Duties (SoD)

   • No single person controls critical functions (e.g., authorizing + approving loans in Nabil Bank).
   • Prevents fraud: One employee can’t both create a fake invoice and approve payment.

3. Defense in Depth

   • Combine multiple controls (e.g., firewall + encryption + IDS for eSewa’s database).

4. Input Validation

   • Sanitize user inputs to prevent SQL injection (e.g., Daraz’s checkout form rejects <script> tags).

---

5. Real-World Applications

Case Study 1: NEPSE’s Security Measures

• Threat: Insider trading (employees leaking stock tips).
• Solution:
  • RBAC: Only analysts can view pre-market data.
  • Audit Logs: Every trade is timestamped and linked to a user.
  • Encryption: Investor portfolios are encrypted at rest.
• Outcome: Reduced illegal trades by 40% (per NEPSE’s 2023 report).

Case Study 2: eSewa’s Transaction Security

• Threat: Fraudulent refunds (users claiming non-delivery).
• Solution:
  • Database Triggers: Auto-flag refunds > Rs. 5,000 without delivery confirmation.
  • Digital Signatures: Merchants sign transactions (non-repudiation).
  • Two-Factor Auth (2FA): SMS + OTP for high-value transfers.
• Outcome: Fraud cases dropped by 60% in 2023.

Case Study 3: Daraz’s Inventory Protection

• Threat: Fake product listings (sellers uploading stolen images).
• Solution:
  • Image Hashing: Stores a unique fingerprint of each product image (detects duplicates).
  • Automated Moderation: AI flags listings with mismatched descriptions/images.
• Outcome: 75% reduction in counterfeit products (Daraz’s 2023 security report).

---

6. Common Security-Related Programming Problems

Poor coding introduces vulnerabilities. Four critical issues:

---

7. Human Factors in Database Security

Humans are the weakest link (80% of breaches involve human error) but also the strongest (security awareness prevents attacks).

Weaknesses:

• Phishing: Tricking employees into revealing credentials (e.g., a fake "NTC bill payment" email stealing login details).
• Shoulder Surfing: Watching PINs (e.g., at Khalti kiosks).
• Social Engineering: Impersonating IT support to ask for database access.

Strengths:

• Training: eSewa’s mandatory cybersecurity workshops reduced phishing clicks by 50%.
• Awareness: NEPSE’s simulated hacking drills teach employees to spot suspicious logins.

Exam Tip: Always mention both sides (weakest/strongest link) when asked about human factors.

---

8. Compliance and Legal Frameworks

Databases must comply with laws to avoid fines/lawsuits:

---

Exam Tip

1. For "design a secure database" questions:

   • Start with threat modeling (identify risks like SQLi, insider threats).
   • Apply defense-in-depth (firewall + encryption + auditing).
   • Use real examples: "Like NEPSE’s RBAC for investor data" or "eSewa’s immutable logs."

2. For "factors in database security policy":

   • List technical (encryption, access control), administrative (training, audits), and physical (secure data centers) controls.
   • Mention compliance (e.g., "Must adhere to Nepal’s Electronic Transaction Act").

3. For "human factors":

   • Weakest: Phishing, insider threats.
   • Strongest: Security awareness programs (e.g., NTC’s training).

4. Diagrams in exams:

   • Draw access control models (DAC/MAC/RBAC) as Venn diagrams (if allowed) or flowcharts.
   • Show encryption layers (e.g., data-at-rest → in-transit → in-use).

5. Worked example: Question: Design security for a bank’s loan database. Answer:

   • Access Control: RBAC (Loan Officer = read/write; Auditor = read-only).
   • Encryption: AES-256 for stored data + TLS for API calls.
   • Auditing: Log all loan modifications with timestamps.
   • Backup: Daily snapshots + offsite storage.
   • Compliance: PCI-DSS for cardholder data.

---

Summary Checklist

Before the exam, ensure you can: ✅ Define SQL injection, DAC, RBAC, and data masking. ✅ Compare MAC vs. RBAC with Nepalese examples (NRA vs. Nabil Bank). ✅ Explain how eSewa secures transactions (logs + encryption + 2FA). ✅ List 4 programming vulnerabilities and their fixes. ✅ Describe NEPSE’s security measures against insider threats. ✅ Link human factors to real cases (e.g., phishing at NTC).