Documenting WordPress Security Incidents Properly

Proper security incident documentation serves multiple purposes: supporting recovery efforts, meeting compliance requirements, improving future response, and potentially supporting legal action. Learn how to document incidents effectively.

Why Documentation Matters

Documentation Benefits

• Supports investigation and recovery
• Meets compliance requirements
• Enables post-incident analysis
• Supports insurance claims
• Aids law enforcement
• Improves future response

Incident Timeline

Recording Events

// Example incident log structure
$incident_log = array(
    'incident_id' => 'INC-2024-001',
    'status' => 'investigating',
    'severity' => 'high',
    'timeline' => array(
        array(
            'timestamp' => '2024-01-15 09:30:00',
            'event' => 'Anomaly detected in access logs',
            'actor' => 'Monitoring system',
            'details' => 'Unusual number of requests to wp-login.php'
        ),
        array(
            'timestamp' => '2024-01-15 09:35:00',
            'event' => 'Investigation started',
            'actor' => 'Admin: John Smith',
            'details' => 'Reviewing security logs and access patterns'
        ),
        // Continue logging all actions...
    )
);

Key Timestamps to Record

• Initial detection time
• When each responder was notified
• Actions taken with timestamps
• When containment was achieved
• When recovery started/completed

Evidence Preservation

What to Preserve

• Server access logs
• WordPress debug logs
• Database state/backups
• Modified files (quarantined)
• Email headers if relevant
• Screenshots of anomalies

Evidence Collection Script

#!/bin/bash
# Evidence collection script
INCIDENT_ID=$1
EVIDENCE_DIR="/var/evidence/$INCIDENT_ID"

mkdir -p $EVIDENCE_DIR

# Copy logs
cp -r /var/log/apache2/ $EVIDENCE_DIR/apache_logs/
cp /path/to/wordpress/wp-content/debug.log $EVIDENCE_DIR/

# Database dump
mysqldump -u user -p database > $EVIDENCE_DIR/database_snapshot.sql

# File listings with timestamps
find /path/to/wordpress -type f -printf "%T+ %p
" > $EVIDENCE_DIR/file_listing.txt

# Modified files (last 24 hours)
find /path/to/wordpress -type f -mtime -1 > $EVIDENCE_DIR/recently_modified.txt

# Calculate hashes
find /path/to/wordpress -type f -exec md5sum {} ; > $EVIDENCE_DIR/file_hashes.md5

# Compress with timestamp
tar -czf "${EVIDENCE_DIR}_$(date +%Y%m%d_%H%M%S).tar.gz" $EVIDENCE_DIR

Incident Report Template

Report Structure

# Security Incident Report

## Executive Summary
- Incident ID: INC-2024-001
- Date Detected: 2024-01-15 09:30 UTC
- Date Resolved: 2024-01-15 14:45 UTC
- Severity: High
- Status: Resolved

## Impact Assessment
- Systems Affected: Production website
- Data Potentially Exposed: None confirmed
- Downtime: 2 hours
- Users Affected: Approximately 500 during incident

## Timeline of Events
[Chronological list of all events]

## Root Cause Analysis
[Technical explanation of vulnerability exploited]

## Response Actions
[List of all actions taken]

## Lessons Learned
[What worked, what didn't]

## Recommendations
[Preventive measures for future]

## Appendices
- A: Evidence inventory
- B: Affected file list
- C: Log excerpts

Technical Details to Document

Attack Vector Documentation

## Attack Vector Analysis

### Entry Point
- Method: SQL injection in contact form
- Affected File: /wp-content/plugins/contact-plugin/submit.php
- Vulnerable Code: Line 45, unsanitized $_POST['email']

### Exploitation Steps
1. Attacker submitted malicious form data
2. SQL injection extracted user table
3. Admin credentials obtained
4. Unauthorized login at 10:15 UTC
5. Malicious plugin uploaded

### Indicators of Compromise (IOCs)
- IP Addresses: 192.168.x.x, 10.0.x.x
- User Agents: "Mozilla/5.0 (compatible; evil-bot)"
- File Hashes:
  - malicious.php: a1b2c3d4e5...
  - backdoor.php: f6g7h8i9j0...

Notification Documentation

Stakeholder Notifications

## Notifications Log

### Internal Notifications
| Time | Recipient | Method | Response |
|------|-----------|--------|----------|
| 09:35 | IT Manager | Phone | Acknowledged 09:37 |
| 09:40 | CEO | Email | Read 09:55 |

### External Notifications
| Time | Recipient | Method | Response |
|------|-----------|--------|----------|
| 12:00 | Hosting Provider | Ticket | Resolved 12:30 |
| 14:00 | Affected Users | Email | Sent to 500 users |

### Regulatory Notifications
- Supervisory Authority: [Date/Reference if required]
- Data Subjects: [Date/Method if required]

Post-Incident Review

Lessons Learned Template

## Post-Incident Review

### What Worked Well
- Detection system identified anomaly within 5 minutes
- Team assembled quickly
- Communication was clear

### What Could Improve
- Initial response playbook was outdated
- Backup restoration took longer than expected
- Some contact information was outdated

### Action Items
| Item | Owner | Due Date | Status |
|------|-------|----------|--------|
| Update incident playbook | IT Manager | 2024-01-30 | Pending |
| Implement WAF rule | Security Team | 2024-01-20 | Complete |
| Review plugin security | Developer | 2024-02-01 | Pending |

Document Retention

Retention Requirements

• Keep incident records for compliance period
• Maintain evidence securely
• Document destruction when appropriate
• Consider legal hold requirements

Tools for Documentation

• Ticketing systems (Jira, ServiceNow)
• Secure note-taking (encrypted notes)
• Screenshot tools with timestamps
• Log aggregation systems
• Evidence management platforms

Conclusion

Thorough incident documentation supports recovery, compliance, and continuous improvement. Establish templates and procedures before incidents occur so documentation happens naturally during response.