Incident Response Plan

This document describes how Charming Holdings LLC ("the company") responds to a security incident affecting buyer data, system integrity, or operational availability. It is reviewed every six months and any time there is a material change in our systems or personnel.

Scope

This plan applies to any incident involving data received from a marketplace (Amazon, Walmart, eBay), the systems that process that data (our application server, database, and supporting infrastructure), or the accounts that access them.

Roles

Because this is a small operation, the IMPOC is also the individual who executes containment and remediation steps. If that person is unavailable, the IRP is paused until they are reachable; this is documented as an operational risk.

Severity classification

Response steps

1. Detect

Incidents are surfaced through:

• fail2ban alerts and audit log anomaly detection
• Employee or customer report (email or phone)
• External notification (security researcher, marketplace, hosting provider)
• Web Push alert from the application's anomaly middleware

2. Triage

The IMPOC classifies severity using the table above within the listed SLA and opens an incident record (private GitHub issue with severity label and timestamps).

3. Contain

• Revoke compromised credentials (rotate user passwords, revoke API keys)
• Block source IPs at the firewall (ufw)
• Terminate active sessions in the application
• Disable affected user accounts
• If the database is suspected compromised: isolate the server from external network access (close port 443 temporarily) while investigation proceeds

4. Notify (within 24 hours of detection)

For incidents involving marketplace data, the IMPOC notifies the affected marketplace's security contact within 24 hours of detection, with: incident summary, time of detection, approximate scope of affected data, containment actions taken, and next-step plan.

If the incident also triggers a regulatory notification obligation (e.g., state breach notification laws), the IMPOC executes that notification per the applicable law.

5. Investigate

• Review access logs (Flask + journald + dedicated audit log) for the time window around the incident
• Identify root cause (vulnerability exploited, credential leak, misconfiguration, etc.)
• Document the scope of data accessed or exfiltrated
• Preserve evidence (log snapshots, file checksums) before any destructive remediation

6. Eradicate

• Patch the underlying vulnerability
• Rotate all credentials and encryption keys that may have been exposed (DB password, SP-API refresh token, pgcrypto column key)
• Remove any malicious artifacts (webshells, modified files, unexpected database objects)

7. Recover

• If integrity is in question, restore the database from the most recent clean encrypted backup (Backblaze B2, separate region)
• Re-enable normal network access only after the eradication steps are verified
• Confirm services are operational and monitoring resumed

8. Lessons learned (within 7 days)

• Write a brief post-incident report: timeline, root cause, impact, what worked, what didn't
• Update controls or processes to prevent recurrence
• Communicate relevant changes to all staff with system access

Plan review cadence

This IRP is reviewed every 6 months by the IMPOC. Each review confirms: contact information is current, marketplace security contacts are current, severity examples still reflect realistic threats to our environment, and the post-incident lessons from the prior period have been incorporated. Reviews are logged in our private GitHub repository.