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:
- Do not panic — Follow these steps calmly and carefully
- Do not destroy evidence — Do not modify systems, delete logs, or clear history
- Isolate affected systems (if possible without destroying evidence)
- Stop application if actively being exploited
- Disconnect network if ransomware is spreading
- But preserve logs and forensic data
- Report immediately:
- Slack: #security-incident channel (if available)
- Email: security@timelessbiotech.com with "INCIDENT" in subject
- 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:
- Assembles response team based on incident type
- Creates incident ticket for tracking
- Determines severity level (P1/P2/P3/P4)
- Establishes communication channel (war room, Slack channel, phone bridge)
- 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:
- What happened?
- What type of incident? (breach, compromise, misconfiguration, etc.)
- Which systems were affected?
-
What was the attack vector?
-
When did it happen?
- When was the incident first detected?
- When did the incident actually start?
-
How long was the system/data exposed?
-
Who is affected?
- How many patients/users?
- Which data was accessed?
-
What is the sensitivity of exposed data?
-
What data is involved?
- Is PHI (Protected Health Information) involved?
- How much data? (rows, records, files)
-
De-identified or personally identifiable?
-
What is the impact?
- Confidentiality impact (data disclosure)
- Integrity impact (data modification)
-
Availability impact (system downtime)
-
What should we do?
- Can we contain it immediately?
- Should we notify external parties?
- 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:
- Date, time, and nature of the breach
- Description of what happened (how the breach occurred)
- Data involved (specific types of PHI, number of records)
- Persons affected (number of patients, healthcare provider)
- Discovery date (when breach was discovered)
- Investigation results (what data was accessed, how long access lasted)
- Steps taken to respond (containment, remediation, monitoring)
- Steps users can take (credit monitoring, identity protection)
- 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:
- Notify affected individuals (primary breach notification)
- Notify healthcare provider (if customer/partner)
- Notify media (if breach affects more than 500 residents in a jurisdiction)
- 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:
- Incident summary (10 min)
- Timeline of events
- Severity and impact
-
Root cause
-
Investigation findings (15 min)
- Evidence discovered
- Attack method
-
Scope of compromise
-
Response effectiveness (10 min)
- What went well
- What could be improved
-
Was response time adequate
-
Lessons learned (20 min)
- Why did this happen?
- What controls failed?
-
What controls worked?
-
Action items (15 min)
- Prevent recurrence
- Improve detection
- Improve response
- 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.