Skip to content

Incident Response

Overview

A security incident is any event that compromises or potentially compromises the confidentiality, integrity, or availability of MenoTime systems or data. This document defines how to identify, report, respond to, and learn from security incidents, with special emphasis on HIPAA breach notification requirements.

Golden Rule: Any suspected incident involving PHI must be immediately escalated to the Security Officer and Privacy Officer.

Incident Classification

Incidents are classified by severity to determine response priority and escalation.

Severity Levels

Level Name Examples Response Time Escalation
P1 Critical Data breach, ransomware, production outage, PHI exposure < 15 min CEO, Board
P2 High Unauthorized access attempt, failed intrusion detection, credential compromise < 1 hour Executives, Legal
P3 Medium Account misconfiguration, suspicious but contained activity < 4 hours Security team, affected teams
P4 Low Low-risk misconfigurations, informational alerts < 1 business day Security team

Incident Examples

P1 — Critical Incidents

  • PHI data breach: Unauthorized access to or disclosure of patient health information
  • Ransomware: Ransomware infection or encryption of systems
  • System compromise: Malicious code in production systems
  • Denial of service: Prolonged system outages affecting patient care
  • Insider threat: Employee deliberately exfiltrating or destroying data
  • Mass credential compromise: Multiple user passwords compromised
  • Database deletion: Production database deletion or data loss
  • Massive unauthorized access: Attacker with broad system access

Response: Activate incident response team immediately; notify external parties

P2 — High Incidents

  • Unauthorized access attempt: Successful login with stolen credentials (if contained)
  • Single credential compromise: One user's password or API key compromised
  • Failed intrusion detection: Intrusion attempt blocked by security systems
  • Privilege escalation: User gains higher access than authorized
  • Configuration vulnerability: Missing security control (e.g., unencrypted S3 bucket)
  • Third-party breach: Vendor or contractor with MenoTime data is compromised

Response: Incident response team engaged; investigation within 1 hour

P3 — Medium Incidents

  • Suspicious activity: Unusual access patterns, late-night logins, bulk downloads
  • Account misconfiguration: Overly permissive access controls
  • Failed login attempts: Multiple failed login attempts (possible brute force)
  • Unpatched system: Security vulnerability identified but not yet exploited
  • Policy violation: Violation of security policies without confirmed damage

Response: Investigation by security team; remediation within 4 hours

P4 — Low Incidents

  • Informational alerts: GuardDuty findings that are benign
  • Log anomalies: Suspicious log entries with minimal risk
  • Expiring certificates: SSL certificate or credential approaching expiration
  • Minor misconfigurations: Low-risk configuration issues

Response: Documentation and remediation within 1-2 business days

Incident Response Procedures

Phase 1: Detect and Report (0-15 minutes)

How Incidents are Detected

Automated Detection: - CloudWatch alarms (CPU, memory, latency spikes) - GuardDuty alerts (intrusion detection) - AWS Security Hub findings - Falco intrusion detection (container runtime) - Application error monitoring (e.g., Datadog, New Relic)

Manual Detection: - Employee reports suspicious activity - Customer reports unusual behavior - Monitoring dashboard alerts - Regular log reviews

Reporting Process

If you discover or suspect an incident:

  1. Do not panic — Follow these steps calmly and carefully
  2. Do not destroy evidence — Do not modify systems, delete logs, or clear history
  3. Isolate affected systems (if possible without destroying evidence)
  4. Stop application if actively being exploited
  5. Disconnect network if ransomware is spreading
  6. But preserve logs and forensic data
  7. Report immediately:
  8. Slack: #security-incident channel (if available)
  9. Email: security@timelessbiotech.com with "INCIDENT" in subject
  10. Phone: Call Security Officer immediately (for P1/P2)

Report Include: - What happened (what you observed) - When it started (time/date) - Which systems are affected - Is PHI potentially involved? (Critical) - Screenshots or logs if available

Report Example:

Subject: INCIDENT - Possible unauthorized database access

I noticed unusual database queries in CloudWatch logs at 2024-01-15 14:35 UTC.
Queries appear to be SELECT * on the patients table from an IP address not
in our known range (IP: 203.0.113.45).

The query ran 47 times over 2 minutes before stopping. This is not a normal
access pattern for our application.

Affected system: menotime-prod RDS database
Time of incident: 2024-01-15 14:35-14:37 UTC
Possible PHI exposure: YES (patient table was queried)

Security Officer: Please advise next steps immediately.

Phase 2: Triage and Assessment (15 min - 4 hours)

Incident Commander Assigned

The Security Officer immediately becomes the Incident Commander and:

  1. Assembles response team based on incident type
  2. Creates incident ticket for tracking
  3. Determines severity level (P1/P2/P3/P4)
  4. Establishes communication channel (war room, Slack channel, phone bridge)
  5. Defines scope (which systems, what data, how many users/patients affected)

Incident Response Team

Role Responsibility
Incident Commander Overall response coordination, escalation decisions
Security Officer Forensic investigation, HIPAA response decisions
Privacy Officer Patient notification decisions, regulatory compliance
Technical Lead System remediation, logs analysis
DevOps/SRE System isolation, patching, recovery
Database Administrator Data access audit, snapshot recovery
Communications Internal and external notifications
Legal Regulatory requirements, liability assessment

Assessment Questions

The response team investigates and answers:

  1. What happened?
  2. What type of incident? (breach, compromise, misconfiguration, etc.)
  3. Which systems were affected?
  4. What was the attack vector?

  5. When did it happen?

  6. When was the incident first detected?
  7. When did the incident actually start?
  8. How long was the system/data exposed?

  9. Who is affected?

  10. How many patients/users?
  11. Which data was accessed?
  12. What is the sensitivity of exposed data?

  13. What data is involved?

  14. Is PHI (Protected Health Information) involved?
  15. How much data? (rows, records, files)
  16. De-identified or personally identifiable?

  17. What is the impact?

  18. Confidentiality impact (data disclosure)
  19. Integrity impact (data modification)
  20. Availability impact (system downtime)

  21. What should we do?

  22. Can we contain it immediately?
  23. Should we notify external parties?
  24. Does this trigger HIPAA breach notification?

Investigation Tasks

For P1 Incidents (Immediate - within 15 minutes):

  • ✓ Verify incident is real (not false alarm)
  • ✓ Determine severity and classification
  • ✓ Check if PHI is involved
  • ✓ Initiate containment measures
  • ✓ Activate incident response team
  • ✓ Assess need for external notifications

For P2/P3 Incidents (Within 1-4 hours):

  • ✓ Collect initial facts and logs
  • ✓ Determine root cause
  • ✓ Assess scope and impact
  • ✓ Plan containment and remediation
  • ✓ Prepare communications

Phase 3: Containment (Varies by severity)

Immediate Containment

For active attacks or ongoing compromise:

Stop the attack:

# Isolate compromised instance from network
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --no-source-dest-check

# Revoke all credentials
aws iam update-access-key \
  --access-key-id AKIA... \
  --status Inactive \
  --user-name compromised-user

# Block attacker's IP (if known)
aws waf create-ip-set \
  --name AttackerIPs \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses '["203.0.113.45/32"]'

Preserve evidence:

# Create snapshot of compromised volume before terminating
aws ec2 create-snapshot \
  --volume-id vol-1234567890abcdef0 \
  --description "Forensic snapshot for incident #12345"

# Download logs before deletion
aws s3 sync s3://menotime-logs/incident/ ./forensics/

Escalate If Necessary

For P1 incidents, activate escalation:

L0: Security Officer
↓ (if unresponsive in 10 min)
L1: VP of Engineering / VP of Product
↓ (if unresponsive in 10 min)
L2: CEO, Legal Counsel
↓ (if P1 confirmed)
L3: Healthcare provider partners (breach notification)
    Regulatory bodies (HIPAA/HHS)
    Affected patients

Phase 4: Investigation and Root Cause Analysis

Evidence Collection

Preserve all evidence for forensic investigation:

CloudTrail logs (API actions):

# Export all CloudTrail events for the incident time window
aws cloudtrail lookup-events \
  --start-time 2024-01-15T14:00:00Z \
  --end-time 2024-01-15T16:00:00Z \
  --max-results 50 > cloudtrail-events.json

CloudWatch logs (application logs):

# Export application logs
aws logs get-log-events \
  --log-group-name /menotime/prod/application \
  --log-stream-name ecs/task-id \
  --start-time 1705335600000 \
  --end-time 1705342800000 > app-logs.json

RDS audit logs (database access):

# Download pgAudit logs from PostgreSQL
SELECT * FROM pgaudit.audit_log
WHERE event_time >= '2024-01-15 14:00'
AND event_time <= '2024-01-15 16:00'
ORDER BY event_time;

System logs (OS-level):

# Collect from affected EC2 instance
sudo journalctl --since "2024-01-15 14:00" --until "2024-01-15 16:00" > system.log
sudo ausearch -ts 2024-01-15 > audit.log

Timeline Reconstruction

Create a detailed timeline of the incident:

2024-01-15 14:35:00 UTC — First anomalous query detected by CloudWatch alert
2024-01-15 14:35:15 UTC — Security team notified via alert
2024-01-15 14:36:00 UTC — Security Officer begins investigation
2024-01-15 14:37:30 UTC — Database queries stop (attacker disconnected or attack complete)
2024-01-15 14:38:00 UTC — Database access revoked (compromise contained)
2024-01-15 15:15:00 UTC — Full scope assessment: 47 patients' records accessed
2024-01-15 15:30:00 UTC — Assessment: HIPAA breach determination made

Root Cause

Determine how the incident occurred:

Example findings:

  • Weak credential: User password was reused on compromised third-party site; attacker used same password on MenoTime
  • Misconfiguration: S3 bucket was accidentally set to public; search engine indexed data
  • Unpatched system: Known vulnerability in library was not patched; exploit code available online
  • Insider threat: Employee downloaded bulk data and uploaded to personal cloud storage
  • Supply chain: Vendor's software was compromised; malware installed on our systems

Phase 5: Remediation and Recovery

Short-Term Remediation (< 24 hours)

Step 1: Stop the bleeding - Revoke compromised credentials - Patch exploited vulnerabilities - Reset user passwords - Block attacker's IP addresses - Review and restrict suspicious access

Step 2: Validate the fix - Confirm the attack is stopped - Monitor for recurrence - Verify backup systems are unaffected

Long-Term Remediation (1-7 days)

Step 1: Restore systems - Restore from clean backups if necessary - Rebuild compromised systems - Redeploy with security patches

Step 2: Hardening - Implement controls to prevent recurrence - Update security configurations - Deploy additional monitoring

Example Remediation Plan:

INCIDENT: Unauthorized RDS access due to credential compromise

SHORT-TERM:
- ✓ Revoke compromised user credentials (5 min)
- ✓ Reset all passwords for affected users (10 min)
- ✓ Rotate RDS master password (15 min)
- ✓ Review database access logs (1 hour)
- ✓ Determine scope of data accessed (2 hours)

LONG-TERM:
- ✓ Implement IAM database authentication (remove password auth) (2 days)
- ✓ Enable RDS audit logging (pgAudit) (1 day)
- ✓ Implement network segmentation (RDS in private subnet only) (3 days)
- ✓ Add anomaly detection for bulk queries (2 days)
- ✓ Audit third-party data breaches weekly (ongoing)

Phase 6: Notifications (If Applicable)

HIPAA Breach Notification Rules

A breach occurs when there is unauthorized access to, acquisition of, or transmission of unencrypted or unredacted PHI.

Key points: - Encrypted PHI is not considered a breach (encryption is a safe harbor) - De-identified data is not a breach (does not contain PHI) - Accidental access by authorized user is not a breach - Unauthorized access to encrypted data is not a breach (if properly destroyed)

60-Day Notification Rule

Healthcare providers using MenoTime must be notified of breaches within 60 calendar days of discovery.

Timeline: - Day 1: Breach confirmed, investigation begins - Day 5-10: Investigation complete, scope determined - Day 15: Notification content drafted - Day 30: Legal review of notification - Day 45: Notification approved and prepared - Day 60: Notification delivered to healthcare providers

Notification Content

Breach notifications must include:

  1. Date, time, and nature of the breach
  2. Description of what happened (how the breach occurred)
  3. Data involved (specific types of PHI, number of records)
  4. Persons affected (number of patients, healthcare provider)
  5. Discovery date (when breach was discovered)
  6. Investigation results (what data was accessed, how long access lasted)
  7. Steps taken to respond (containment, remediation, monitoring)
  8. Steps users can take (credit monitoring, identity protection)
  9. Contact information for questions

Example Breach Notification:

Date: January 31, 2024
Subject: Important: MenoTime Security Incident Notification

Dear [Healthcare Provider Name]:

We are writing to inform you of a security incident that may have affected
some patient information on MenoTime.

WHAT HAPPENED:
On January 15, 2024, we discovered unauthorized access to our patient database
resulting from a compromised user credential. The attacker accessed patient
records containing names, dates of birth, and menopause severity scores.

DATA AFFECTED:
- 47 patient records accessed
- Data elements: Patient name, date of birth, menopause symptom severity
- No financial information, insurance data, or SSNs were accessed

HOW WE RESPONDED:
- Immediately revoked the compromised credential
- Reviewed all access logs to determine scope
- Implemented IAM database authentication to prevent password-based access
- Notified law enforcement and privacy regulatory bodies

WHAT YOU SHOULD DO:
Monitor patient accounts for suspicious activity. We recommend informing affected
patients to:
1. Monitor credit reports for identity theft
2. Place fraud alerts with credit bureaus (call 1-888-5-OPTOUT)
3. Consider credit monitoring services

QUESTIONS:
Contact our Privacy Officer at privacy@timelessbiotech.com or 1-800-XXX-XXXX.

We sincerely regret this incident and appreciate your partnership.

Sincerely,
Timeless Biotech Privacy Officer

Regulatory Notifications

HIPAA Breach Notification Rule requires:

  1. Notify affected individuals (primary breach notification)
  2. Notify healthcare provider (if customer/partner)
  3. Notify media (if breach affects more than 500 residents in a jurisdiction)
  4. Notify HHS (Department of Health and Human Services)

HHS Notification (for breaches of 500+ individuals):

https://www.hhs.gov/hipaa/filing-a-complaint/breach-notification/index.html

Reportable breaches go to: ocr@hhs.gov
Breach portal: https://ocrportal.hhs.gov/ocr/breach/wizard_upload.jsf

Non-HIPAA Notification (if applicable): - State breach notification laws (vary by state) - Consumer protection agencies - Credit bureaus (for identity theft risk)

Phase 7: Post-Incident Review

Timeline: 5-7 days after incident

Participants: Full incident response team + department leads

Agenda:

  1. Incident summary (10 min)
  2. Timeline of events
  3. Severity and impact
  4. Root cause

  5. Investigation findings (15 min)

  6. Evidence discovered
  7. Attack method
  8. Scope of compromise

  9. Response effectiveness (10 min)

  10. What went well
  11. What could be improved
  12. Was response time adequate

  13. Lessons learned (20 min)

  14. Why did this happen?
  15. What controls failed?
  16. What controls worked?

  17. Action items (15 min)

  18. Prevent recurrence
  19. Improve detection
  20. Improve response
  21. Owner and due date for each action

Example Post-Incident Report

INCIDENT POST-MORTEM
Incident #2024-001: Unauthorized Database Access
Date: January 15, 2024
Impact: 47 patient records accessed; HIPAA breach notification triggered

ROOT CAUSE:
User's password was compromised in a third-party data breach. User reused
the same password on MenoTime, allowing unauthorized access.

DETECTION:
CloudWatch anomaly detection identified unusual query patterns.
Detection latency: ~1 minute (acceptable).

RESPONSE:
Credential revoked, access blocked. Response time: 2 minutes (good).

LESSONS LEARNED:
1. Password reuse across services enabled compromise
2. Network segmentation would have limited data accessed
3. IAM database auth would have prevented password-based access
4. We need employee credential hygiene training

ACTION ITEMS:
- Implement IAM database auth for RDS (due: 2024-02-15) [DBA]
- Add password reuse detection monitoring (due: 2024-02-08) [Security]
- Conduct password hygiene training (due: 2024-02-22) [HR]
- Implement network segmentation (due: 2024-03-01) [DevOps]
- Monthly security awareness emails (due: ongoing) [Communications]

STATUS: CLOSED
Follow-up: Monitor action items; reopen if new risks identified

Incident Contact Information

Internal Escalation

IMMEDIATE CONTACTS (24/7):
Security Officer: [phone], [email]
Privacy Officer: [phone], [email]

SECONDARY (during business hours):
VP of Engineering: [phone], [email]
VP of Product: [phone], [email]
CEO: [phone], [email]

EMERGENCY NUMBERS:
FBI (if criminal): 1-800-CALL-FBI
Local Police (if criminal): 911 or local emergency number

External Escalation

HIPAA COMPLIANCE:
HHS Office for Civil Rights: ocr@hhs.gov
Breach notification portal: https://ocrportal.hhs.gov

HEALTHCARE PROVIDERS (Partners):
Send notifications via secure portal or encrypted email

LAW ENFORCEMENT:
FBI Cyber Division: 1-800-CALL-FBI
Local law enforcement: 911 or local non-emergency number

Incident Reporting and Metrics

Incident Log

All incidents are logged in the central incident tracking system:

Incident #  | Date       | Type              | Severity | Status    | Resolution
------------|------------|-------------------|----------|-----------|------------------
2024-001    | 2024-01-15 | Data breach       | P1       | CLOSED    | 4 hours
2024-002    | 2024-01-20 | Config error      | P3       | CLOSED    | 8 hours
2024-003    | 2024-02-01 | Suspicious access | P2       | CLOSED    | 2 hours

Metrics Tracked

  • Number of incidents (by severity)
  • Mean time to detect (MTTD)
  • Mean time to respond (MTTR)
  • Mean time to resolve (MTTR)
  • False alarm rate (alerts that are not real incidents)
  • Recurrence rate (repeat incidents from same root cause)
  • Compliance with 60-day breach notification rule

Annual Review

Annually, the security team reviews: - Incident trends and patterns - Effectiveness of detection systems - Response procedures and timing - Lessons learned and improvements - Compliance with regulations


Questions or Report an Incident? Contact the Security Officer at security@timelessbiotech.com or call immediately for P1/P2 incidents.