Loading learning content...
In 2019, British Airways was fined £183 million (later reduced to £20 million due to COVID-19 impact) for a data breach that exposed the personal and financial details of approximately 500,000 customers. The root cause? Inadequate security monitoring and logging that failed to detect the attack for over two months. The fine wasn't for getting hacked—it was for failing to have adequate security controls, including proper audit trails.
Welcome to the world of security compliance, where auditing and logging are not optional best practices but legal requirements. Organizations face a complex web of regulations—PCI DSS for payment data, HIPAA for health information, SOX for financial systems, GDPR for European personal data, and dozens more. Non-compliance doesn't just mean fines; it can mean criminal liability for executives, loss of business licenses, and irreparable reputational damage.
This page navigates the compliance landscape from a technical perspective—what these regulations actually require for auditing and logging, how to implement compliant systems, and how to demonstrate compliance through documentation and evidence.
By the end of this page, you will understand: (1) Major compliance frameworks and their audit requirements, (2) Technical controls that satisfy regulatory mandates, (3) Audit log retention and integrity requirements, (4) Evidence collection and audit preparation, (5) Continuous compliance monitoring, and (6) Documentation and reporting requirements.
Organizations typically face multiple overlapping compliance requirements based on industry, geography, and the types of data they process. Understanding which frameworks apply is the first step toward compliance.
| Framework | Scope | Key Audit Requirements | Penalties |
|---|---|---|---|
| PCI DSS | Payment card data | Log all access to cardholder data, daily log review, 1-year retention | Fines up to $500k/month, loss of card processing |
| HIPAA | Healthcare data (US) | Access logs for PHI, 6-year retention, audit controls | Up to $1.5M per violation category per year |
| SOX | Public company finance (US) | Audit trail for financial systems, 7-year retention | Criminal penalties for executives, delisting |
| GDPR | EU personal data | Processing logs, breach notification, access logging | Up to 4% of global annual revenue |
| GLBA | Financial institutions (US) | Access controls logging, risk assessment | Up to $100k per violation |
| FISMA/FedRAMP | US federal systems | Continuous monitoring, real-time alerting, NIST controls | Loss of federal contracts |
| SOC 2 | Service organizations | Security logging, access monitoring, integrity | Loss of customer trust, contracts |
Most organizations face multiple frameworks. Fortunately, there's significant overlap in audit requirements:
Rather than implementing each regulation separately, organizations often adopt control frameworks that satisfy multiple compliance requirements:
A well-designed audit infrastructure based on NIST 800-53 can satisfy PCI DSS, HIPAA, SOX, and SOC 2 audit requirements simultaneously. The key is implementing robust common controls and then mapping them to specific regulation requirements.
Let's examine the specific technical requirements for major frameworks. Understanding these requirements helps you design systems that satisfy multiple mandates.
| Requirement | Description | Technical Implementation |
|---|---|---|
| 10.2.1 | Log all individual user access to cardholder data | Enable audit on CDE systems, log file access |
| 10.2.1.1 | Log all actions by any individual with administrative access | Audit sudo, RDP sessions, admin console access |
| 10.2.1.2 | Log all actions by root or admin accounts | Full command logging for privileged accounts |
| 10.2.1.3 | Log access to all audit trails | Monitor audit log file access, SIEM access |
| 10.2.1.4 | Log invalid logical access attempts | Failed logins, denied access, auth failures |
| 10.2.1.5 | Log changes to authentication credentials | Password changes, key rotations, MFA changes |
| 10.2.1.6 | Log initialization of audit logs | Log service start, rotation, clearing |
| 10.2.1.7 | Log creation/deletion of system-level objects | Object creation in databases, file systems |
| 10.3 | Record timestamp, user, event type, success/failure, origin, affected resource | Structured logging with required fields |
| 10.4 | Use time-synchronization technology | NTP with authenticated sources |
| 10.5 | Secure audit trails so they cannot be altered | Write-once storage, integrity checking |
| 10.6 | Review logs daily for security events | Automated review with SIEM, documented process |
| 10.7 | Retain audit trail history for at least one year (3 months immediately available) | Tiered storage with ILM policies |
| Section | Requirement | Technical Implementation |
|---|---|---|
| §164.312(b) | Implement audit controls to record/examine activity in systems with ePHI | Enable auditing on all PHI-containing systems |
| §164.308(a)(1)(ii)(D) | Implement procedures to review records of activity (log review) | Regular log review process with documentation |
| §164.312(c) | Implement mechanisms to authenticate ePHI hasn't been altered | Hash verification, integrity monitoring |
| §164.308(a)(5)(ii)(C) | Log-in monitoring procedures | Failed login tracking, account lockout |
| §164.530(j) | Retain documentation for 6 years from creation or last effective date | 6-year retention with verified deletion |
NIST 800-53 provides the most comprehensive control catalog, with an entire family (AU) dedicated to auditing:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113
# NIST 800-53 Rev 5 - Audit and Accountability Family (AU)# Key controls for compliance mapping controls: AU-2: name: "Audit Events" description: "Identify auditable events" requirements: - "Coordinate audit event selection with other entities" - "Include rationale for why audit events are deemed adequate" - "Include auditable events listed in 10.2.1 (if PCI applicable)" implementation: | Document auditable event categories: - Authentication events (success/failure) - Authorization decisions - System administrator actions - Data access and modifications - Security policy changes AU-3: name: "Content of Audit Records" description: "What information to include in each record" requirements: - "Type of event" - "Time of event" - "Source of event" - "Outcome (success/failure)" - "Identity of subject" - "Objects accessed or modified" implementation: | Minimum audit record fields: - timestamp (UTC, microsecond precision) - event_type (authentication, authorization, etc.) - outcome (success, failure, error) - subject (user ID, process ID, service account) - source (hostname, IP address, terminal) - target (file path, database table, API endpoint) - details (additional context as JSON) AU-4: name: "Audit Storage Capacity" description: "Allocate sufficient audit log storage" requirements: - "Allocate storage based on audit record size and retention" - "Transfer to alternate storage if primary fills" - "Alert when storage reaches threshold" implementation: | - Calculate: daily_events * record_size * retention_days * 1.5 - Set alerts at 70%, 80%, 90% capacity - Automatic transfer to archive at threshold AU-5: name: "Response to Audit Processing Failures" description: "Define behavior when audit fails" requirements: - "Alert personnel when audit fails" - "Take defined actions (shutdown, switch destination)" implementation: | failure_actions: disk_full: "halt_non_essential_services" daemon_crash: "restart_attempt_then_alert" network_unavailable: "local_buffer_then_retry" AU-6: name: "Audit Review, Analysis, and Reporting" description: "Regularly review audit records" requirements: - "Review and analyze audit records at defined frequency" - "Report findings to appropriate personnel" - "Integrate audit review with incident response" implementation: | review_schedule: security_events: "real-time SIEM alerting" admin_actions: "daily manual review" access_patterns: "weekly statistical analysis" full_audit: "monthly compliance review" AU-9: name: "Protection of Audit Information" description: "Protect audit records from unauthorized access/modification" requirements: - "Protect audit information from unauthorized access" - "Protect audit tools from unauthorized modification" - "Alert on unauthorized access attempts" implementation: | - Separate log storage with restricted access - Immutable attributes on log files - Cryptographic signing of audit records - Network segmentation for log infrastructure AU-11: name: "Audit Record Retention" description: "Retain audit records per retention schedule" requirements: - "Retain audit records for defined period" - "Ensure records are retrievable for investigation" implementation: | retention_tiers: online: "90 days in primary SIEM" warm: "1 year in searchable archive" cold: "7 years in compliance archive" AU-12: name: "Audit Generation" description: "Generate audit records for defined events" requirements: - "Provide audit record generation capability" - "Allow authorized personnel to configure auditable events" - "Generate audit records with required content" implementation: | - Deploy audit agents on all systems - Centralized audit policy management - Verify audit generation with periodic testsNIST 800-53 defines three control baselines: Low, Moderate, and High impact. Most production systems handling sensitive data require at least the Moderate baseline for audit controls. Federal systems and critical infrastructure typically require High.
Understanding requirements is one thing; implementing systems that satisfy them is another. Here's how to build infrastructure that achieves compliance.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231
# Terraform configuration for compliant audit infrastructure# Satisfies PCI DSS, HIPAA, and SOC 2 requirements # ================================================# ENCRYPTED, IMMUTABLE LOG STORAGE# ================================================ # S3 bucket with compliance featuresresource "aws_s3_bucket" "audit_logs" { bucket = "company-security-audit-logs" # Prevent accidental deletion force_destroy = false tags = { Purpose = "Compliance Audit Logs" Compliance = "PCI-DSS,HIPAA,SOC2" DataClass = "Confidential" }} # Enable versioning (protects against accidental deletion/modification)resource "aws_s3_bucket_versioning" "audit_logs" { bucket = aws_s3_bucket.audit_logs.id versioning_configuration { status = "Enabled" }} # Server-side encryptionresource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" { bucket = aws_s3_bucket.audit_logs.id rule { apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" kms_master_key_id = aws_kms_key.audit_logs.arn } bucket_key_enabled = true }} # Object Lock for immutability (WORM)resource "aws_s3_bucket_object_lock_configuration" "audit_logs" { bucket = aws_s3_bucket.audit_logs.id rule { default_retention { mode = "COMPLIANCE" # Cannot be removed, even by root years = 7 } }} # Lifecycle policy for tiered storageresource "aws_s3_bucket_lifecycle_configuration" "audit_logs" { bucket = aws_s3_bucket.audit_logs.id rule { id = "compliance-tiering" status = "Enabled" transition { days = 90 storage_class = "STANDARD_IA" } transition { days = 365 storage_class = "GLACIER" } # No expiration - compliance storage is permanent # Deletion handled by separate compliance process }} # Block all public accessresource "aws_s3_bucket_public_access_block" "audit_logs" { bucket = aws_s3_bucket.audit_logs.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true} # ================================================# ENCRYPTION KEY MANAGEMENT# ================================================ resource "aws_kms_key" "audit_logs" { description = "KMS key for audit log encryption" deletion_window_in_days = 30 enable_key_rotation = true # Key policy restricting access policy = jsonencode({ Version = "2012-10-17" Statement = [ { Sid = "Allow administration" Effect = "Allow" Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/SecurityAdmin" } Action = ["kms:*"] Resource = "*" }, { Sid = "Allow audit log service usage" Effect = "Allow" Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/AuditLogService" } Action = [ "kms:Encrypt", "kms:GenerateDataKey*" ] Resource = "*" } ] }) tags = { Purpose = "Audit Log Encryption" }} # ================================================# ACCESS CONTROL# ================================================ # IAM policy for log writers (minimal permissions)resource "aws_iam_policy" "audit_log_writer" { name = "AuditLogWriter" description = "Allows writing audit logs only" policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = [ "s3:PutObject" ] Resource = "${aws_s3_bucket.audit_logs.arn}/*" Condition = { StringEquals = { "s3:x-amz-server-side-encryption" = "aws:kms" } } } ] })} # IAM policy for log readers (SOC analysts)resource "aws_iam_policy" "audit_log_reader" { name = "AuditLogReader" description = "Allows reading audit logs for investigation" policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = [ "s3:GetObject", "s3:ListBucket" ] Resource = [ aws_s3_bucket.audit_logs.arn, "${aws_s3_bucket.audit_logs.arn}/*" ] }, { Effect = "Allow" Action = [ "kms:Decrypt" ] Resource = aws_kms_key.audit_logs.arn } ] })} # ================================================# MONITORING AND ALERTING# ================================================ # CloudWatch alarm for audit destination healthresource "aws_cloudwatch_metric_alarm" "audit_destination_failures" { alarm_name = "AuditDestinationFailures" comparison_operator = "GreaterThanThreshold" evaluation_periods = 1 metric_name = "AuditLogDeliveryFailures" namespace = "Security/AuditLogs" period = 300 statistic = "Sum" threshold = 0 alarm_description = "Alert if any audit log delivery fails" alarm_actions = [ aws_sns_topic.security_alerts.arn ] ok_actions = [ aws_sns_topic.security_alerts.arn ]} # CloudTrail for log access auditing (audit the audits)resource "aws_cloudtrail" "audit_log_access" { name = "audit-log-access-trail" s3_bucket_name = aws_s3_bucket.cloudtrail_logs.id include_global_service_events = true is_multi_region_trail = true enable_log_file_validation = true # Detect tampering event_selector { read_write_type = "All" include_management_events = true data_resource { type = "AWS::S3::Object" values = ["${aws_s3_bucket.audit_logs.arn}/"] } }}AWS S3 Object Lock in COMPLIANCE mode cannot be disabled, shortened, or bypassed—even by the root account. Before enabling, ensure your retention period is correct. Once set, objects are truly immutable for the specified duration. This satisfies the strictest WORM requirements but requires careful planning.
When auditors come—and they will—you need to demonstrate compliance with documented evidence. Preparing for audits should be an ongoing process, not a fire drill.
| Control Area | Evidence Required | Auditor Expectation |
|---|---|---|
| Logging Enabled | Configuration files, screenshots, test results | Prove logging is active and capturing required events |
| Log Completeness | Sample searches showing event types | All required event types are present |
| Log Integrity | Hash chains, signatures, access logs | Prove logs haven't been modified |
| Log Protection | Access control configs, encryption proof | Only authorized access is possible |
| Log Retention | Retention policies, sample retrieval | Logs available for required period |
| Log Review | Review procedures, tickets, reports | Regular review is happening |
| Alerting | Alert rules, incident tickets | Alerts trigger on security events |
Maintain documentation that auditors expect to see:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157
# Security Audit Evidence Package ## 1. Audit and Logging Policy Document **Document:** POL-SEC-003 - Audit and Logging Policy**Version:** 2.4**Last Review:** 2024-01-15**Next Review:** 2025-01-15**Approved By:** CISO ### Policy Statements 1.1 All systems processing [sensitive data type] SHALL log authentication events.1.2 All administrative actions SHALL be logged with timestamp, user, and action detail.1.3 Logs SHALL be retained for minimum [X] years per regulatory requirement.1.4 Log integrity SHALL be protected using cryptographic controls.1.5 Log review SHALL occur [frequency] by qualified personnel. --- ## 2. System Architecture Documentation **Diagram:** audit-architecture-diagram.pdf**Systems in Scope:**- Web servers (AWS EC2)- Database servers (AWS RDS)- Application servers (ECS)- Network devices (Palo Alto)- Cloud infrastructure (AWS CloudTrail, GuardDuty) **Log Flow:**Sources → Fluentd Agents → Kafka → Logstash → Elasticsearch → S3 Archive --- ## 3. Configuration Evidence ### 3.1 Linux Auditd Configuration```# Output of: cat /etc/audit/auditd.conf# Date captured: 2024-01-15# System: app-server-prod-01log_file = /var/log/audit/audit.logmax_log_file = 50num_logs = 10max_log_file_action = ROTATEspace_left = 75space_left_action = emailadmin_space_left = 50admin_space_left_action = singledisk_full_action = HALT[... full output ...]``` ### 3.2 Windows Audit Policy```# Output of: auditpol /get /category:*# Date captured: 2024-01-15# System: dc-prod-01 System audit policy for DC-PROD-01: Account Logon Credential Validation Success and Failure Kerberos Authentication Service Success and Failure Logon/Logoff Logon Success and Failure Logoff Success Special Logon Success[... full output ...]``` --- ## 4. Retention Evidence ### 4.1 Retention Policy| Log Type | Online Retention | Archive Retention | Verification Date ||----------|------------------|-------------------|-------------------|| Authentication | 90 days | 7 years | 2024-01-15 || Privileged Access | 180 days | 7 years | 2024-01-15 || File Access | 30 days | 1 year | 2024-01-15 | ### 4.2 Retrieval Test**Test Date:** 2024-01-15**Tested By:** jsmith@security.com **Test 1:** Retrieve authentication logs from 18 months ago- Date requested: 2022-07-15- Search executed: [query]- Result: 4,532 events retrieved successfully- Screenshot: retrieval-test-001.png **Test 2:** Retrieve privileged access logs from 3 years ago- Date requested: 2021-01-15- Search executed: [query]- Result: 12,847 events retrieved successfully- Screenshot: retrieval-test-002.png --- ## 5. Log Review Evidence ### 5.1 Review Schedule| Review Type | Frequency | Responsible Party | Documentation ||-------------|-----------|-------------------|---------------|| Security alerts | Real-time | SOC Analysts | SIEM tickets || Admin activity | Daily | Security Engineer | Daily report || Access patterns | Weekly | Security Manager | Weekly report || Full audit | Monthly | Security Director | Monthly report | ### 5.2 Sample Review Documentation**Week of:** 2024-01-08 to 2024-01-14**Reviewed By:** analyst@security.com **Summary:**- Total alerts reviewed: 342- True positives: 28- False positives: 314- Escalated to incident: 3 **Notable Findings:**1. [Ticket SEC-2024-0042] Brute force attempt from [IP] - blocked2. [Ticket SEC-2024-0045] Unusual file access by service account - investigated, authorized3. [Ticket SEC-2024-0048] Potential data exfiltration - escalated to IR --- ## 6. Integrity Evidence ### 6.1 S3 Object Lock Configuration```json{ "ObjectLockConfiguration": { "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Years": 7 } } }}``` ### 6.2 CloudTrail Log File Validation**Test Date:** 2024-01-15```$ aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:us-east-1:123456789:trail/audit-trail --start-time 2024-01-01 Validating log files for trail arn:aws:cloudtrail:us-east-1:123456789:trail/audit-trail between 2024-01-01T00:00:00Z and 2024-01-15T23:59:59Z Results:Log files validated: 15Log files not validated: 0Digest files validated: 15Digest files not validated: 0```Don't manually collect evidence before audits. Build automation that generates compliance reports continuously. Use tools like AWS Config, Chef InSpec, or OpenSCAP to automatically verify and document control implementation. When auditors arrive, you should be able to generate fresh evidence in minutes.
Point-in-time audits are giving way to continuous compliance monitoring. Rather than demonstrating compliance once per year, organizations must prove compliance continuously.
Using tools like Chef InSpec or AWS Config Rules, encode compliance checks as code:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
# Chef InSpec profile for audit logging compliance# Satisfies PCI DSS 10.x, HIPAA, and SOC 2 requirements # Control: Audit daemon must be runningcontrol 'audit-1.1' do impact 1.0 title 'Audit daemon is running' desc 'The auditd service must be running to capture security events' tag 'pci-dss': '10.1' tag 'hipaa': '164.312(b)' describe service('auditd') do it { should be_installed } it { should be_enabled } it { should be_running } endend # Control: Audit configuration is immutablecontrol 'audit-1.2' do impact 1.0 title 'Audit configuration is immutable' desc 'Audit rules cannot be modified without reboot' tag 'pci-dss': '10.5' describe auditd_conf do its('enabled') { should eq 2 } # Immutable mode endend # Control: Required events are being auditedcontrol 'audit-2.1' do impact 1.0 title 'Authentication events are audited' desc 'All login/logout events must be captured' tag 'pci-dss': '10.2.1' tag 'hipaa': '164.308(a)(5)(ii)(C)' describe auditd_rules do its('lines') { should include('-w /var/log/lastlog -p wa -k logins') } its('lines') { should include('-w /var/run/faillock/ -p wa -k logins') } end describe file('/etc/audit/rules.d/security.rules') do its('content') { should match(/identity/) } its('content') { should match(/logins/) } its('content') { should match(/privileged/) } endend # Control: Log files are protectedcontrol 'audit-3.1' do impact 1.0 title 'Audit log files have correct permissions' desc 'Only root/audit group can access audit logs' tag 'pci-dss': '10.5.1' describe file('/var/log/audit/audit.log') do it { should exist } its('mode') { should cmp '0600' } its('owner') { should eq 'root' } its('group') { should eq 'root' } endend # Control: Time synchronization is configuredcontrol 'audit-4.1' do impact 0.7 title 'Time synchronization is enabled' desc 'NTP must be configured for accurate timestamps' tag 'pci-dss': '10.4' describe service('chronyd') do it { should be_running } it { should be_enabled } end describe command('chronyc tracking') do its('stdout') { should match(/Leap statuss+:s+Normal/) } endend # Control: Logs are being forwardedcontrol 'audit-5.1' do impact 1.0 title 'Logs are forwarded to central collector' desc 'Logs must be sent to SIEM for review and long-term storage' tag 'pci-dss': '10.5.3' describe service('fluent-bit') do it { should be_running } it { should be_enabled } end # Verify recent successful forwarding describe command('journalctl -u fluent-bit --since "1 hour ago" | grep -c "output:es"') do its('stdout.to_i') { should be > 0 } endend # Control: Logs are retained appropriatelycontrol 'audit-6.1' do impact 1.0 title 'Log retention meets requirements' desc 'Logs must be available for minimum retention period' tag 'pci-dss': '10.7' tag 'hipaa': '164.530(j)' describe auditd_conf do its('max_log_file') { should be >= 50 } its('num_logs') { should be >= 10 } its('max_log_file_action') { should eq 'ROTATE' } end # Verify we have logs from 90+ days ago (online retention) describe command('find /var/log/audit -name "audit.log.*" -mtime +90 | wc -l') do its('stdout.to_i') { should be > 0 } endendTrack and visualize compliance status continuously:
| Metric | Target | Alert Threshold | Measurement Method |
|---|---|---|---|
| Audit Coverage | 100% of in-scope systems | <100% | Asset inventory vs. log sources |
| Log Completeness | All required event types present | Missing event types | Daily sampling verification |
| Log Latency | <5 min to SIEM | 15 min | Timestamp comparison |
| Retention Compliance | 100% retrievable | <100% | Monthly retrieval tests |
| Review Completion | 100% reviews on schedule | Missed reviews | Review tracking system |
| Control Pass Rate | 95% | <90% | Automated control testing |
Even compliant systems drift over time. New servers are deployed without proper configuration, services are modified, log destinations change. Continuous compliance monitoring catches drift before auditors do. Run compliance checks at least daily and alert immediately on any failure.
Many regulations require notification within specific timeframes when breaches occur. Your audit and logging infrastructure must support rapid incident investigation and evidence preservation.
| Regulation | Notification Deadline | Who to Notify | Documentation Required |
|---|---|---|---|
| GDPR | 72 hours to regulator | Supervisory authority, affected individuals | Nature of breach, categories of data, mitigation measures |
| HIPAA | 60 days to individuals, immediate if >500 affected | HHS, individuals, media (if large) | Description, dates, types of PHI, remediation |
| PCI DSS | Immediate to acquirer | Card brands, payment processor | Forensic investigation, scope, containment |
| CCPA | Without unreasonable delay | Affected California residents | Categories of information, remediation steps |
| NYDFS | 72 hours | NY DFS Superintendent | Nature of incident, corrective action |
During incident response, logging requirements become even more critical. You must preserve evidence while documenting response actions:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
# Incident Logging Procedure ## 1. Evidence Preservation (First 1 Hour) ### Immediate Actions- [ ] Activate log preservation hold (prevent rotation/deletion)- [ ] Capture current log files with timestamps- [ ] Document chain of custody- [ ] Take memory snapshots if malware suspected- [ ] Preserve network traffic captures ### Commands for Evidence Preservation```bash# Prevent log rotationchattr +a /var/log/audit/audit.logsystemctl stop logrotate # Create forensic copy with verificationDATE=$(date +%Y%m%d_%H%M%S)INCIDENT_ID="INC-2024-0042" mkdir -p /evidence/$INCIDENT_IDcp -a /var/log/audit/ /evidence/$INCIDENT_ID/audit_logs/sha256sum /evidence/$INCIDENT_ID/audit_logs/* > /evidence/$INCIDENT_ID/hashes.txt # Document collectioncat << EOF > /evidence/$INCIDENT_ID/collection_log.txtIncident: $INCIDENT_IDCollected By: $(whoami)Collected At: $(date -u)System: $(hostname)Hashes: See hashes.txtEOF``` ## 2. Incident Timeline Logging ### Required DocumentationEvery action during incident response must be logged: | Timestamp (UTC) | Actor | Action | Result | Reference ||-----------------|-------|--------|--------|-----------|| 2024-01-15T14:32:00Z | SOC Analyst | Detected anomaly in SIEM | Alert SEC-9876 | [SIEM screenshot] || 2024-01-15T14:35:00Z | Incident Lead | Declared incident | INC-2024-0042 | [Incident ticket] || 2024-01-15T14:40:00Z | IR Team | Isolated affected host | Network segment quarantined | [Firewall change record] | ## 3. Regulatory Notification Log ### GDPR 72-Hour Timeline- [ ] Hour 0: Breach confirmed- [ ] Hour 4: Scope assessment complete- [ ] Hour 12: Impact assessment complete- [ ] Hour 24: Draft notification prepared- [ ] Hour 48: Legal review complete- [ ] Hour 72: Submission to supervisory authority ### Notification Record```Notification Date: 2024-01-17Notified Authority: ICO (UK)Reference: [submission number]Submitted By: DPO NameBackup Confirmation: [screenshot/email]``` ## 4. forensic Evidence Chain of Custody ### Chain of Custody Form| Evidence ID | Description | Collected By | Date/Time | Transferred To | Date/Time | Storage Location ||-------------|-------------|--------------|-----------|----------------|-----------|------------------|| EVD-001 | Audit logs Jan 1-15 | jsmith | 2024-01-15 15:00 UTC | forensics team | 2024-01-15 16:00 UTC | Secure evidence locker | ### Evidence Integrity Verification```bash# Verify evidence integrity before analysiscd /evidence/$INCIDENT_IDsha256sum -c hashes.txt# Expected output: All files OK```Under GDPR, you have exactly 72 hours from becoming 'aware' of a breach to notify the supervisory authority. This clock cannot be stopped. If your audit logs are slow to search, poorly indexed, or require manual analysis, you may not be able to determine breach scope in time. Invest in fast search capabilities and automated breach detection.
Compliance transforms security from best practice to legal requirement. Auditing and logging are no longer optional—they're mandated by regulations that carry significant penalties for non-compliance. Let's consolidate the key concepts:
Module Complete:
You have now completed the full Auditing and Logging module. From the foundational concepts of audit trails, through log management infrastructure, intrusion detection systems, log analysis techniques, and finally compliance requirements—you now possess comprehensive knowledge of this critical security domain.
Congratulations! You've mastered the complete auditing and logging discipline—from generating audit events to satisfying regulatory compliance. These skills form the foundation of security operations, incident response, and organizational risk management. Whether you're building security infrastructure, investigating incidents, or preparing for audits, this knowledge will serve you throughout your career.