Cyber Security

01- Data lifecycle: Security Perspective

1. Data Creation / Collection

• Input validation and sanitization to prevent attacks such as SQL Injection and XSS.

• Data classification to identify sensitivity levels and apply appropriate protection.

• Secure collection channels using encryption (TLS) and strong authentication.

2. Data Storage

• Encryption at transit

• Encryption at rest using technologies such as AES-256 or Transparent Data Encryption (TDE).

• Access control enforcement using RBAC/ABAC and least privilege principles.

• Database monitoring and auditing to detect unauthorized access or changes.

3. Data Usage / Processing

• Strong identity management using MFA and privileged access controls.

• Data masking and tokenization to protect sensitive information during processing.

• Secure application development practices following OWASP guidelines to prevent vulnerabilities.

• Implement virtual private database for Multi-Tenant solutions

4. Data Sharing / Transmission

• Encryption in transit using TLS 1.2/1.3 to protect data communication.

• API security controls including authentication, authorization, validation, and rate limiting.

• Data Loss Prevention (DLP) to detect and prevent unauthorized data sharing.

5. Data Archiving

• Encrypt archived data and backups to prevent unauthorized disclosure.

• Apply retention policies based on regulatory and business requirements.

• Restrict archive access and maintain audit logs.

6. Data Disposal / Destruction

• Secure data deletion using cryptographic erasure or secure wiping methods.

• Verify destruction completion and maintain evidence for audit purposes.

• Remove all copies including backups, replicas, and temporary storage.

• Create data retention policy

Cross-Lifecycle Security Controls

• Data governance: Define ownership, classification, retention, and handling policies.

• Continuous monitoring: Track access, changes, and suspicious activities.

• Zero Trust security: Continuously verify users, devices, applications, and access requests.

02- Data Encryption

Definition

Encryption is the process of transforming readable data (plaintext) into an unreadable form (ciphertext) using a mathematical key — so only authorized parties can decrypt & read it.

Generation Process 

1. Key Generation: Create cryptographic keys securely.

2. Encryption: Use the key & algorithm to turn plaintext → ciphertext.

3. Key Management: Store, distribute, rotate, revoke keys securely.

4. Decryption: Use key to restore ciphertext → plaintext.

5. Destruction/Archival: Securely delete keys & data when no longer needed.

Encryption Levels

1. At-Rest Encryption: Protects data on disk/storage (e.g., database encryption, BitLocker).

2. In-Transit Encryption: Protects data moving over networks (e.g., TLS, IPSec).

3. End-to-End Encryption: Only sender & receiver can decrypt (e.g., Signal, WhatsApp).

4. Field-Level Encryption: Encrypt specific sensitive fields (e.g., SSNs, credit cards).

5. Homomorphic Encryption: Allows computation on encrypted data (advanced).

6. Tokenization & Masking: Alternatives for some use cases where full encryption isn’t practical.

Best Practices:

• Use strong, modern algorithms (e.g., AES-256, RSA-2048+).

• Never hard-code keys; use Hardware Security Modules (HSM) or Key Management Systems (KMS).

• Regularly rotate and revoke keys.

• Combine with access controls & monitoring.

How Hackers attack encryption?

• Bruite force: Many trials for decryption

Defense Mechanism

1. Concrete approach of Encryption

2. Rate limiting

3. Account Blocking

4. Foot printing

03- DB Hardening

Definition

securing a system by reducing its attack surface — removing unnecessary services, tightening configurations, and enforcing best practices to make it more resistant to attacks. 

Practices:

1. Authentication & Access Control

• Disable default accounts or change their passwords.

• Use strong, unique passwords.

• Configure least privilege for all users.

• Create dedicated DB accounts (no shared accounts).

• Deny OS-level access to DB users.

• Use role-based access control (RBAC).

• Lock accounts after repeated login failures.

• Audit privileged users.

• Deny unnecessary privileges like CREATE ANY or DROP ANY on production:

  • • Enable only within the deployment process

    • Disable immediately after the deployment process finishes

• Never connect an application from database admin users. 

• Revoke access to DDL metadata from application users, for example:

  • • DBMS_METADATA 

    • ALL_TABLES

    • ALL_TAB_COLUMNS 

• Run TOAD PL/SQL code analysis 

2. Network Security

• Bind DB to localhost or specific IPs.

• Use firewalls to restrict DB port access.

• Change default DB ports.

• Enforce TLS/SSL for all connections.

• Disable remote root/admin logins.

• Deploy DB behind VPN or bastion host.

• Block connections from untrusted networks.

• Monitor incoming/outgoing DB traffic.

• Enable host-based access controls.

• Separate DB network segment from application/public.\

3. Patching & Updates

• Keep DBMS up-to-date with vendor patches.

• Subscribe to security advisories.

• Test patches in staging before production.

4. Configuration

• Disable unused features (e.g., XML DB, external procedures).

• Remove sample databases & schemas.

• Restrict OS file permissions on DB files.

• Disable directory listing & UTL_FILE (Oracle).

• Turn off XP_CMDSHELL (SQL Server).

• Remove or disable web-based DB admin tools (like phpMyAdmin).

5. Encryption

• Enable Transparent Data Encryption (TDE) if available, which will:

  • • Encrypt data at rest(Physical files)

    • If hackers reach the data files, it will be encrypted

• Encrypt backups:

  • • 
      

• Encrypt sensitive columns (e.g., PII, PCI).

• Use TLS/SSL for replication links.

• Protect encryption keys outside DB (HSM or Vault).

6. Auditing & Monitoring

• Enable native DB auditing.

• Log failed & successful logins.

• Monitor schema changes.

• Record privileged commands.

• Centralize log collection (SIEM).

• Detect & alert on suspicious queries.

• Track access to sensitive tables.

• Audit changes to DB configurations.

7. Backup & Recovery

• Use secure backup locations.

• Encrypt backups at rest & in transit.

• Test restores regularly.

• Maintain offsite backups.

• Retain backups per compliance needs.

• Secure backup credentials.

8. Application Interaction

• Use parameterized queries (prevent SQL injection).

• Restrict DB account permissions for apps.

• Do not let apps connect as DBA/root.

• Validate & sanitize user inputs.

• Block dangerous SQL constructs (e.g., EXEC, DROP) where possible.

• Implement connection pooling with proper isolation.

• Avoid dynamic SQL when possible.

• Avoid trusting application-layer validations. Use strong CHECK constraints in tables, not just PL/SQL 

• 'Never accept dynamic SQL

  • • Set policy

    • Need for implementation should be justified

09. Physical & OS Security

• Secure the server physically.

• Remove unnecessary OS packages.

• Harden OS per CIS benchmarks.

• Disable unused network interfaces.

• Restrict OS-level file system access.

10. Compliance & Policy

• Align with standards (PCI-DSS, HIPAA, GDPR).

• Document & enforce DB security policies.

• Classify data & apply appropriate controls.

• Review compliance regularly.

• Ensure vendor contracts address DB security.

11. Maintenance & Testing

• Perform regular security assessments.

• Use automated hardening tools where possible.

• Review audit logs weekly.

• Run penetration tests on DB systems.

• Validate RBAC configurations periodically.

• Rotate keys & passwords regularly.

• Benchmark performance vs. security impact.

• Remove obsolete schemas & tables.

12. Advanced Measures

• Implement database firewalls/WAF for DBs.

• Use Data Masking in non-production environments.

• Enable row-level security (if supported).

• Deploy anomaly detection on queries.

• Use HSM (Hardware Security Modules) for keys.

• Separate duties between DBA & developers.

• Block or sandbox untrusted PL/SQL or T-SQL code.

• Minimize round-trips by batch logic

13. Replication

• Remove unnecessary replication/slave users.

04- Practices

• Data classification

• Data ownership

• Data Access Security

• Credential hardening (Complex password)

• Data encryption

• Data retention

• DBA Admins

• Data users

• Backup and recovery

• VPD: Virtual private database

• Patch updates

04- Data Retention Model

What is Data Retention?

Definition: Data retention is the set of policies, processes, and technical controls that define how long data is stored, where it is stored, and how it is securely deleted after its lifecycle ends.

Objectives:

•Legal compliance (GDPR, HIPAA, PCI DSS, SOX, ISO 27001).

•Security (prevent misuse of stale data).

•Cost optimization (storage efficiency).

•Risk reduction (less data = less exposure in breaches).

•Solution Performance

Architecture Approach:

•Well-defined data retention policy

•Alignment with business

•Schedular agent implementation

•Data retention procedures

•Data Model rebuilder

•

05- Data Model Governance

In order to secure your data model persistency, you have 2 approaches:

• Virtual private database, which have full isolation of the data according to its tenant

• Data encryption: at data level

1. Personal Info

2. Financial Information

3. Authentication Data

4. OTP

5. Integration Endpoints

6. Configuration Data

7. Access Sensitive Data: By Customer

8. Properties data

   1. 1. Trade license

      2. EID

      3. Plate No

      4. Certificate ID

6- TDE

Definition

• Transparent Data Encryption (TDE) is a database security feature that encrypts data at rest without requiring application code changes.

• It protects sensitive database files, tablespaces, and backups from unauthorized access if storage media or backup files are compromised.

• Encryption and decryption are performed automatically by the database engine during read/write operations.

• Commonly supported by enterprise databases such as Oracle Database and Microsoft SQL Server.

Business Value of TDE

Security Value

• Protects sensitive data at rest against unauthorized access.

• Reduces impact of stolen database files or backups by making data unreadable without encryption keys.

• Supports Defense in Depth by adding an additional security layer beyond access controls.

Compliance Value

• Helps satisfy data protection requirements from standards and regulations:

  • PCI DSS (payment card protection)

  • GDPR (personal data protection)

  • ISO/IEC 27001 security controls

  • Industry-specific security requirements

7- Attacks types

1. SQL Injection: Attacking software and databases

• Use parameterized queries and stored procedures: SELECT * FROM users WHERE id = ?

2. Excessive Privileges

• Grant the least privileges required

• GRANT SELECT ON users TO readonly_user;

3. Unencrypted Data at Rest: Stolen data files and disk space 

• Use TDE or disk-level encryption

• Enable Transparent Data Encryption (TDE)

4. Unencrypted Data in Transit

• Use SSL/TLS connections

• jdbc:postgresql://host/db?ssl=true

5. Improper Backup Security

• Encrypt backups and restrict access

• gpg --encrypt backup.sql

6. Weak Authentication

• Enforce password complexity policy

7. Missing Patches

• Apply regular database security patches

• Apply Oracle CPU patches quarterly

8. Misconfigured Database Services

• Disable unused services and ports

• Disable remote access for development DBs

9. Audit Logging Disabled

• Enable logging and monitor regularly

• Exposure of Metadata

• Restrict access to system tables/views

10. Data leakage

• Least privilege

• Encryption

• Data retention

11. Database per service approach: DDoS attach

• Module-based physical segregation: pluggable DB for each module

• Logical segregation per service: schema per service

12. Fine-Grained Auditing:

• Fine-Grained Auditing (FGA) is an Oracle feature that lets you audit specific rows & columns based on conditions, rather than auditing every access to a table.

• Use DBMS_FGA (Fine-Grained Auditing) when needed 

• Audit only when specific data is accessed (e.g., salary > 10000).

• Reduce audit noise compared to standard auditing.

• Comply with regulations like GDPR, HIPAA, PCI-DSS by tracking sensitive data use.

• Example: Create Policy

  • BEGIN

  •   DBMS_FGA.ADD_POLICY (

  •     object_schema   => 'HR',

  •     object_name     => 'EMPLOYEES',

  •     policy_name     => 'AUDIT_HIGH_SALARY',

  •     audit_condition => 'SALARY > 10000',

  •     audit_column    => 'SALARY',

  •     handler_module  => NULL,

  •     enable          => TRUE

  •   );

  • END;

  • /

• Test Policy

  • SELECT employee_id, salary FROM HR.EMPLOYEES WHERE salary > 12000;

• View audit records:

  • SELECT * FROM DBA_FGA_AUDIT_TRAIL;