Skip to content
HeliosDB HeliosDB Full

HeliosDB Security Incident Response Plan

1. Executive Summary

This document defines the procedures for responding to security incidents affecting HeliosDB deployments. It provides step-by-step guidance for detecting, containing, eradicating, and recovering from security breaches.

1.1 Objectives

  • Minimize damage and impact of security incidents
  • Preserve evidence for forensic analysis
  • Restore normal operations quickly and safely
  • Learn from incidents to improve security posture

1.2 Scope

This plan applies to all security incidents affecting:

  • HeliosDB database servers
  • Encryption key management systems
  • Authentication and authorization systems
  • Network infrastructure
  • Data storage systems

2. Incident Classification

2.1 Severity Levels

P0 - Critical

  • Response Time: Immediate (< 15 minutes)
  • Examples:
    • Active data breach
    • Encryption key compromise
    • Ransomware attack
    • Admin account compromise
    • Critical vulnerability exploitation

P1 - High

  • Response Time: < 1 hour
  • Examples:
    • Successful SQL injection
    • Privilege escalation
    • DDoS attack
    • Failed authentication spike
    • Suspicious admin activity

P2 - Medium

  • Response Time: < 4 hours
  • Examples:
    • Repeated failed login attempts
    • Minor policy violations
    • Suspicious query patterns
    • Configuration drift

P3 - Low

  • Response Time: < 24 hours
  • Examples:
    • Security scan alerts
    • Policy violations (non-critical)
    • Low-risk vulnerability detection

2.2 Incident Categories

  1. Unauthorized Access

    • Authentication bypass
    • Stolen credentials
    • Privilege escalation
    • Session hijacking

  2. Data Breach

    • Unauthorized data access
    • Data exfiltration
    • Data modification
    • Data deletion

  3. Malware/Ransomware

    • Malicious code execution
    • System compromise
    • Data encryption by attacker

  4. Denial of Service

    • DDoS attacks
    • Resource exhaustion
    • System unavailability

  5. Insider Threat

    • Malicious insider activity
    • Accidental data exposure
    • Policy violations

3. Roles and Responsibilities

3.1 Incident Response Team

Incident Commander (IC)

  • Overall incident coordination
  • Communication with stakeholders
  • Decision-making authority
  • Resource allocation

Security Lead

  • Technical security analysis
  • Threat assessment
  • Forensic investigation
  • Remediation planning

Database Administrator (DBA)

  • Database health monitoring
  • Query analysis
  • Data integrity verification
  • Backup and recovery

Network Administrator

  • Network isolation
  • Traffic analysis
  • Firewall rule management
  • DDoS mitigation
  • Regulatory compliance
  • Breach notification requirements
  • Evidence preservation
  • Legal liability assessment

Communications Lead

  • Internal communications
  • External communications
  • Customer notifications
  • Media relations (if needed)

3.2 Contact Information

Emergency Hotline: +1-XXX-XXX-XXXX
Security Email: security@example.com
Pager: security-oncall@pagerduty.com


Incident Commander: ic@example.com
Security Lead: security-lead@example.com
DBA Lead: dba-lead@example.com
Legal: legal@example.com

4. Incident Response Phases

The commands in this section use psql, the HTTP gateway’s health route, the host firewall and the service manager. Replace db.internal and paths with your own.

4.1 Phase 1: Preparation

Before an Incident

  • Logging: ship the server log (stdout/journald or docker logs) to central logging with at least 90 days of retention. Set --log-min-duration-statement to a value that captures the statements you need for investigations.
  • Alerts: authentication failures, connections from unexpected addresses, unexpected restarts, GET /health failures, disk usage.
  • Backups: scheduled snapshots or cold copies, encrypted, with restores tested (see Backup & Disaster Recovery).
  • Secrets inventory: know where HELIOSDB_SUPERUSER_PASSWORD, HELIOSDB_API_KEY, the listener credentials and application role passwords are stored and who can change them.
  • Baseline: record the server’s normal flags (systemctl cat heliosdb or the container spec), heliosdb-full --version and SHOW ROLES output.

4.2 Phase 2: Detection and Analysis

Detection Methods

  • Authentication failures and connection bursts in the server log
  • Rate-limit rejections (--conn-rate-limit, --query-rate-limit) in the log
  • Slow or unusual statements in the slow-statement log
  • New or changed roles in SHOW ROLES
  • Unexpected data changes in SHOW CDC EVENTS
  • Host and network alerts (EDR, IDS, flow logs)

Initial Analysis

-- Who is connected and what is running
SHOW CONNECTIONS;
SELECT pid, usename, state, query FROM pg_stat_activity;


-- Roles and their login settings
SHOW ROLES;


-- Recent data changes (kept in memory since the last restart)
SHOW CDC EVENTS LIMIT 200;
Terminal window
# Log lines for authentication and connections in the last hour
journalctl -u heliosdb --since "1 hour ago" | grep -Ei "auth|denied|connection from|rate limit"


# Which addresses are connected to the database ports
ss -tnp state established '( sport = :5432 or sport = :3306 or sport = :1521 or sport = :8443 )'

Record findings with timestamps in the incident log before changing anything.

4.3 Phase 3: Containment

Short-term Containment (< 30 minutes)

  1. Preserve evidence first (copy logs and session lists; see below).

  2. Cut access at the network layer while keeping the server running:

    Terminal window
    # Allow only the admin host to the database ports
    iptables -I INPUT -p tcp -m multiport --dports 5432,3306,1521,1433,27017,9042,6379,8443 ! -s 10.0.0.5 -j DROP

    In Kubernetes, apply a NetworkPolicy that admits only the admin pod.

  3. Disable a compromised role: ALTER ROLE suspicious_user NOLOGIN;

  4. Close unused listeners: restart the server without the --enable-<protocol> flags you do not need, and without --allow-external if only local access is needed during the investigation.

  5. End sessions: existing sessions end when the server restarts. Restart once the evidence is saved.

Evidence Preservation

Terminal window
INCIDENT=INC-$(date +%Y%m%d-%H%M%S); mkdir -p /secure/$INCIDENT && cd /secure/$INCIDENT
journalctl -u heliosdb --since "7 days ago" > server.log          # or: docker logs heliosdb > server.log 2>&1
psql "host=127.0.0.1 user=postgres" -c "SHOW CONNECTIONS" -c "SHOW ROLES" -c "SHOW CDC EVENTS LIMIT 1000" > sql-state.txt
systemctl cat heliosdb > unit.txt; heliosdb-full --version > version.txt
# Crash-consistent copy of the data directory (storage snapshot), see the backup guide
sha256sum * > SHA256SUMS

Long-term Containment

  • Rotate every credential the attacker could have seen (Phase 4).
  • Keep the restrictive firewall rules until eradication is confirmed.
  • Increase logging: --log-min-duration-statement 0 temporarily logs every statement.

4.4 Phase 4: Eradication

  1. Rotate secrets:
    • Superuser: set a new HELIOSDB_SUPERUSER_PASSWORD in the secrets store or environment file and restart the server; confirm the old password is refused.
    • HTTP gateway: set a new HELIOSDB_API_KEY and restart.
    • Listener credentials: HELIOSDB_ORACLE_NATIVE_PASSWORD, HELIOSDB_SQLSERVER_*, HELIOSDB_MONGODB_*, HELIOSDB_CASSANDRA_*, then restart.
    • Application roles: ALTER ROLE app PASSWORD 'new-value';, then update the applications.
    • TLS: replace the certificate and key if the host was compromised.
  2. Remove what the attacker created: roles (DROP ROLE), tables or functions that are not in your schema baseline.
  3. Fix the entry point: patch the application (for example parameterise the query behind a SQL injection), close the exposed port, upgrade the server.
  4. Rebuild compromised hosts from known-good images rather than cleaning them.

4.5 Phase 5: Recovery

  1. If data was altered or deleted, restore the last backup taken before the incident onto a clean host (see Backup & Disaster Recovery), then re-apply legitimate changes made since that backup from application records.
  2. Start the server with the hardened configuration and the new secrets.
  3. Verify: curl -fsS http://127.0.0.1:8443/ready, SHOW ROLES, row counts of key tables, application smoke tests.
  4. Re-open network access gradually and watch the logs closely for at least a week.

4.6 Phase 6: Post-Incident Activity

  • Write a timeline from detection to recovery, with the evidence references.
  • Identify the root cause and the controls that would have prevented or detected it sooner (network restriction, rotation, alerting, instance isolation).
  • Track the follow-up actions to completion and update this plan.
  • Measure detection, containment and recovery times (section 8).

5. Communication Protocols

5.1 Internal Communication

War Room Setup

Use the tools your organisation already has for incident communication:

  • open a dedicated chat channel named after the incident ID and invite the incident response team;

  • start a standing conference bridge for the duration of the incident;

  • record the channel and bridge links in the incident ticket.

  • Frequency: Every 30 minutes during active incident

  • Format:

    Incident State Update - [TIME]
    

    Incident ID: ${INCIDENT_ID}
    Severity: P0
    

    Current Situation:
    - [Update 1]
    - [Update 2]
    

    Actions Taken:
    - [Action 1]
    - [Action 2]
    

    Next Steps:
    - [Next step 1]
    - [Next step 2]
    

    ETA to Resolution: [Estimate]

5.2 External Communication

Customer Notification

When Required:

  • Data breach confirmed
  • Personal information compromised
  • Service disruption > 4 hours
  • Regulatory requirement

Notification Template:

Subject: Important Security Notice - HeliosDB Incident


Dear Valued Customer,


We are writing to inform you of a security incident affecting HeliosDB
services. We take the security of your data very seriously and want to
provide you with transparent information about this situation.


What Happened:
[Brief description of the incident]


What Information Was Involved:
[Description of compromised data, if any]


What We Are Doing:
[Description of response actions]


What You Can Do:
[Recommended actions for customers]


More Information:
For questions or concerns, please contact:
Email: security-response@example.com
Phone: +1-XXX-XXX-XXXX


We apologize for any inconvenience and thank you for your patience as we
work to resolve this matter.


Sincerely,
[Security Team]

Regulatory Notification

  • GDPR: Within 72 hours of discovery
  • CCPA: Without unreasonable delay
  • HIPAA: Within 60 days
  • SOX: Immediate for material incidents

6. Incident Playbooks

6.1 Data Breach Playbook

  1. Save evidence (4.3 Evidence Preservation).
  2. Restrict network access to the admin host.
  3. Identify scope: which roles connected from where (server log, SHOW CONNECTIONS), which statements ran (slow-statement log, application logs), which tables hold the affected data.
  4. Rotate all database credentials (4.4) and disable the roles involved (ALTER ROLE ... NOLOGIN).
  5. Notify legal and communications leads for breach-notification assessment.
  6. Monitor with full statement logging until closure.

6.2 SQL Injection Playbook

  1. Block the source address at the firewall or WAF.
  2. Find the injected statements in the application logs and in the server’s slow-statement log (SET log_min_duration_statement = 0 on the application’s sessions, or --log-min-duration-statement 0 temporarily, captures every statement).
  3. Check what the injected statements read or changed (SHOW CDC EVENTS for recent writes; compare row counts against the last backup).
  4. Fix the code path to use bind parameters; redeploy.
  5. Rotate the application role’s password, since the attacker may have read it from the application environment.

6.3 Credential Compromise Playbook

  1. ALTER ROLE <role> NOLOGIN; or rotate its password immediately.
  2. For the superuser or the API key: change the environment value and restart.
  3. Review the server log for logins by that role and the addresses they came from.
  4. Review roles and schema for changes made with the credential.

6.4 Denial of Service Playbook

  1. Identify the sources in the log (rate-limit rejections, connection from lines) and block them upstream.
  2. Tighten limits and restart: --conn-rate-limit, --query-rate-limit, --max-connections.
  3. Put a connection pooler in front of the server so client bursts do not reach it.

6.5 Ransomware Playbook

  1. Isolate the host from the network; keep it running for forensics.
  2. Do not restore onto the affected host. Provision a clean host from a known-good image.
  3. Restore the most recent backup that predates the infection (verify it on an isolated host first) and rotate every credential.
  4. Notify the authorities and legal counsel as your policy requires. Do not pay.

7. Testing and Training

7.1 Incident Response Drills

Quarterly Tabletop Exercise

  • Duration: 2 hours
  • Participants: All IR team members
  • Scenario: Simulated incident
  • Objectives: Test decision-making, communication, procedures

Annual Full-Scale Drill

  • Duration: 4 hours
  • Participants: Extended team including management
  • Scenario: Complex multi-stage attack
  • Objectives: Test complete IR capability

7.2 Training Requirements

  • New Team Members: Complete IR training within 30 days
  • Annual Refresher: All team members
  • Post-Incident Training: After each real incident

8. Continuous Improvement

8.1 Metrics

  • Time to detect (TTD)
  • Time to respond (TTR)
  • Time to contain (TTC)
  • Time to recover (TTRec)
  • Number of incidents by severity
  • False positive rate

8.2 Review Schedule

  • Monthly: Incident metrics review
  • Quarterly: Procedure updates
  • Annually: Complete plan revision

Next Review: 2025-04-02