---
title: "HeliosDB Security Incident Response Plan"
---

# 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

#### Legal Counsel
- 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](/docs/full/deployment/production_deployment_backup/)).
- **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

```sql
-- 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;
```

```bash
# 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:

   ```bash
   # 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

```bash
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](/docs/full/deployment/production_deployment_backup/)),
   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