Cyber Security

01- Data lifecycle

• Lifecycle

• Classification

  • Encrypt or not

  • Available for public or not

• Retention

  • Policy

  • Data destruction policy

02- 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

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

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

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

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

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

✅ 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

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.

Practices

• Data classification

• Data ownership

• Data Access Security

• Credential hardening (Complex password)

• Data encryption

• Data retention

• DBA Admins

• Data users

• Backup and recovery

• Data retention

• VPD: Virtual private database

• Patch updates

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;

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