Incident Response and Audit Logs: Using Trails for Security Investigations

When a security incident occurs, time is critical. Every minute counts in containing the threat, understanding the scope, and preventing further damage. Audit logs are your most valuable tool during incident response—they provide the evidence needed to investigate what happened, who was involved, and what data or systems were affected. Let's explore how to use audit logs effectively in incident response.

The Role of Audit Logs in Incident Response

Audit logs serve multiple critical functions during incident response:

Detection

Audit logs often provide the first indication that something is wrong:

• Unusual access patterns
• Failed authentication attempts
• Privilege escalations
• Unauthorised data access
• Configuration changes

Automated monitoring of audit logs can detect incidents faster than manual review.

Investigation

Once an incident is detected, audit logs help you understand:

• What happened
• When it happened
• Who was involved (or if it was automated)
• What systems or data were affected
• How the attacker gained access
• What actions they took

Containment

Audit logs help you contain incidents by:

• Identifying compromised accounts that need to be disabled
• Determining which systems need to be isolated
• Understanding the scope of the breach
• Identifying data that needs to be protected

Recovery

After containing an incident, audit logs help with recovery:

• Understanding what was changed so you can restore systems
• Identifying data that may have been corrupted or stolen
• Determining what security controls failed

Post-Incident Analysis

Audit logs provide evidence for:

• Root cause analysis
• Compliance reporting
• Legal proceedings
• Insurance claims
• Improving security controls

Types of Security Incidents

Different types of incidents require different approaches to using audit logs:

Unauthorised Access

When someone gains unauthorised access to your system:

• Review authentication logs to see how they gained access
• Check authorisation logs to see what they accessed
• Review data access logs to see what data they viewed or exported
• Look for privilege escalation attempts

Data Breach

When data is accessed, stolen, or exposed:

• Identify when the breach occurred
• Determine what data was affected
• Find all access to that data
• Identify who had access (authorised and unauthorised)
• Determine if data was exported or copied

Malicious Activity

When malicious code or actions are detected:

• Trace the origin of the malicious activity
• Identify all systems affected
• Determine the timeline of the attack
• Find what data or systems were compromised

Insider Threat

When an authorised user misuses their access:

• Review their access patterns over time
• Identify what data they accessed
• Determine if they exported or copied data
• Find if they shared credentials or access

Configuration Changes

When unauthorised configuration changes are made:

• Identify what was changed
• Determine who made the change
• Understand the impact of the change
• Restore proper configuration

The Incident Response Process

Here's how audit logs fit into each phase of incident response:

Phase 1: Preparation

Before incidents occur, prepare your audit logging:

Ensure Comprehensive Logging: Log all security-relevant events:

• Authentication and authorisation
• Data access
• Administrative actions
• Configuration changes
• Network activity

Implement Monitoring: Set up automated monitoring and alerting:

• Failed authentication attempts
• Unusual access patterns
• Privilege escalations
• Data exports
• Configuration changes

Test Your Capabilities: Regularly test that you can:

• Query audit logs effectively
• Reconstruct timelines
• Identify compromised accounts
• Export logs for analysis

Document Procedures: Document how to use audit logs during incidents:

• How to query logs
• What to look for
• How to export logs
• Who to contact for help

Phase 2: Detection

Use audit logs to detect incidents:

Automated Detection: Set up alerts for suspicious patterns:

```typescript // Alert on multiple failed logins if (failedLoginAttempts(userId, lastHour) > 5) { alert('Possible brute force attack', { userId }); }

// Alert on unusual data access if (dataAccessCount(userId, lastHour) > threshold) { alert('Unusual data access pattern', { userId }); }

// Alert on privilege escalation if (privilegeEscalation(userId)) { alert('Unauthorised privilege escalation', { userId }); } ```

Manual Review: Regularly review audit logs for:

• Unusual patterns
• Anomalies
• Suspicious activity
• Policy violations

Phase 3: Containment

Use audit logs to contain incidents:

Identify Compromised Accounts: Query audit logs to find:

• Accounts used in the attack
• Accounts that accessed compromised data
• Accounts with unusual activity

Isolate Affected Systems: Determine which systems were affected:

• Systems accessed by the attacker
• Systems where data was accessed
• Systems with configuration changes

Revoke Access: Use audit logs to identify what access needs to be revoked:

• API keys used in the attack
• User accounts that need to be disabled
• Service accounts that need rotation

Phase 4: Eradication

Use audit logs to eradicate threats:

Understand the Attack Vector: Reconstruct how the attacker gained access:

• Review authentication logs
• Check for credential theft
• Look for vulnerability exploitation
• Identify misconfigurations

Remove Malicious Artifacts: Use audit logs to find:

• Files created or modified by the attacker
• Processes started by the attacker
• Network connections established
• Configuration changes made

Phase 5: Recovery

Use audit logs to recover systems:

Restore Data: Identify what data was changed:

• Review data modification logs
• Determine what needs to be restored
• Verify data integrity

Restore Configuration: Find configuration changes:

• Review configuration change logs
• Restore proper settings
• Verify configurations are correct

Verify Systems: Use audit logs to verify systems are clean:

• Check for remaining malicious activity
• Verify normal operations have resumed
• Confirm security controls are working

Phase 6: Post-Incident

Use audit logs for post-incident analysis:

Root Cause Analysis: Understand why the incident occurred:

• What security controls failed
• What vulnerabilities were exploited
• What processes were inadequate

Compliance Reporting: Generate reports for:

• Regulatory authorities
• Customers
• Insurance companies
• Internal stakeholders

Improve Security: Use lessons learned to improve:

• Security controls
• Monitoring and alerting
• Incident response procedures
• Audit logging itself

Querying Audit Logs During Incidents

Effective incident response requires efficient querying of audit logs:

By Time Range

Start with a time range around when the incident was detected:

``typescript const events = await auditLog.query({ start_time: incidentDetectedTime - hours(24), end_time: incidentDetectedTime + hours(1) }); ``

By User or Actor

Find all events involving a specific user:

``typescript const userEvents = await auditLog.query({ actor: { type: 'user', id: userId } }); ``

By Resource

Find all access to a specific resource:

``typescript const resourceEvents = await auditLog.query({ resource: { type: 'customer', id: customerId } }); ``

By Action Type

Find all events of a specific type:

``typescript const exportEvents = await auditLog.query({ action: 'export' }); ``

Complex Queries

Combine multiple criteria:

``typescript const suspiciousEvents = await auditLog.query({ start_time: incidentDetectedTime - hours(48), actor: { type: 'user', id: userId }, action: ['export', 'delete', 'update'], resource: { type: 'customer' } }); ``

Timeline Reconstruction

One of the most valuable uses of audit logs is reconstructing the timeline of an incident:

Step 1: Identify the Entry Point

Find when and how the attacker first gained access:

• Review authentication logs
• Look for failed login attempts before successful access
• Check for credential theft or sharing
• Identify vulnerability exploitation

Step 2: Map the Attack Path

Trace what the attacker did after gaining access:

• What systems did they access?
• What data did they view?
• What actions did they take?
• Did they escalate privileges?

Step 3: Identify Data Access

Determine what data was accessed:

• Which records were viewed?
• Was data exported or copied?
• Were backups or archives accessed?
• Was data modified or deleted?

Step 4: Find the Exit Point

Determine when the attacker left or was contained:

• Last activity timestamp
• Data export timestamps
• When access was revoked

Step 5: Create the Timeline

Compile all events into a chronological timeline:

```typescript const timeline = await auditLog.reconstructTimeline({ correlation_id: incidentId, start_time: incidentStartTime, end_time: incidentEndTime });

// Returns chronological list of events: // 10:23:45 - Failed login attempt (user@example.com) // 10:24:12 - Successful login (user@example.com) // 10:25:03 - Accessed customer database // 10:26:18 - Exported customer data (1000 records) // 10:27:45 - Logged out ```

Common Challenges

Too Much Data

Audit logs can be overwhelming. Use filters and queries to focus on relevant events.

Missing Events

If events aren't being logged, you can't investigate them. Ensure comprehensive logging.

Out-of-Order Events

In distributed systems, events might arrive out of order. Use timestamps and correlation IDs.

Incomplete Context

Events might lack context needed for investigation. Include sufficient metadata in logs.

Performance

Querying large volumes of logs can be slow. Use indexing and efficient storage systems.

Best Practices

1. Log Comprehensively

Log all security-relevant events. You can't investigate what you don't log.

2. Make Logs Queryable

Ensure you can quickly query logs by time, user, resource, action, etc.

3. Retain Logs Appropriately

Retain logs long enough to support investigations (typically 1-2 years minimum).

4. Protect Log Integrity

Use hash chains or other techniques to make logs tamper-evident.

5. Monitor Continuously

Set up automated monitoring to detect incidents early.

6. Practice Regularly

Regularly practice using audit logs for incident response.

7. Document Procedures

Document how to use audit logs during incidents.

Conclusion

Audit logs are essential for effective incident response. They provide the evidence needed to detect, investigate, contain, and recover from security incidents. By logging comprehensively, making logs queryable, and practising incident response procedures, you can significantly improve your ability to respond to security incidents.

The key is to prepare before incidents occur—ensure you're logging the right events, that logs are queryable, and that your team knows how to use them. When an incident happens, audit logs will be your most valuable tool for understanding what occurred and responding effectively.

Remember: the goal isn't just to log events—it's to enable effective incident response. Design your audit logging system with incident response in mind, and you'll be much better prepared when security incidents occur.