Security Event Logging - Security Monitoring | OneNoughtOne

0/273

System Design (HLD)Security Monitoring

Security Monitoring

LevelAdvanced

Duration90 mins

TopicSecurity Monitoring

1 / 5

Security Event Logging

The Foundation of Security Visibility

In the world of distributed systems security, there is one axiom that stands above all others: you cannot protect what you cannot see. Security event logging is the discipline that provides this visibility—the systematic collection, storage, and organization of security-relevant events that enables detection, investigation, and response to threats.

When a security breach occurs, the first question asked is invariably: "What happened?" The quality of your security logging determines whether you can answer this question in minutes, hours, or never. Organizations with mature security logging practices can reconstruct attack timelines, identify compromised assets, determine data exposure, and establish the blast radius of incidents. Those without comprehensive logging are left fumbling in the dark, making educated guesses while attackers maintain persistence.

Beyond incident response, security event logging forms the foundation for proactive threat detection, compliance attestation, forensic investigation, and security analytics. It is the raw material from which security insights are derived. Without robust logging, advanced security capabilities like SIEM systems, user behavior analytics, and threat hunting become impossible.

What You Will Learn

By the end of this page, you will understand what constitutes security event logging, which events must be captured for comprehensive security visibility, how to design log formats that enable analysis, and how to architect centralized logging systems that scale while maintaining integrity. You'll gain the knowledge to implement logging that transforms your security posture from reactive guessing to informed decision-making.

Understanding Security Event Logging

Security event logging is fundamentally different from operational logging, although they share infrastructure. While operational logs focus on system health, performance, and debugging, security logs are specifically designed to capture events that have security relevance—actions that could indicate attacks, policy violations, or compliance-relevant activities.

The Core Purpose of Security Logging

Security event logging serves multiple critical functions:

Detection: Identifying ongoing attacks or policy violations in near real-time
Investigation: Reconstructing what happened during and after security incidents
Forensics: Providing evidence for legal proceedings or disciplinary action
Compliance: Demonstrating adherence to regulatory requirements
Threat Hunting: Enabling proactive searches for hidden threats
Risk Assessment: Understanding normal baselines to identify anomalies

The Logging Paradox

There's an inherent tension in security logging: you need enough detail to detect and investigate incidents, but excessive logging creates noise that obscures threats, increases storage costs, and can itself become a security liability if logs contain sensitive data. Mastering security logging requires understanding this balance and making deliberate choices about what to capture.

Security vs. Operational Logging

Consider the difference in perspective between these two disciplines:

An operational log for a failed login might read:

[ERROR] Authentication failed for user jdoe - invalid password

A security log for the same event captures far more context:

{
  "timestamp": "2024-01-15T14:32:17.892Z",
  "event_type": "authentication.failure",
  "event_category": "authentication",
  "outcome": "failure",
  "reason": "invalid_password",
  "user": {
    "name": "jdoe",
    "domain": "corporate",
    "id": "usr_abc123"
  },
  "source": {
    "ip": "192.168.1.105",
    "geo": {"country": "US", "city": "Seattle"},
    "user_agent": "Mozilla/5.0..."
  },
  "target": {
    "application": "employee-portal",
    "resource": "/api/auth/login"
  },
  "authentication": {
    "method": "password",
    "mfa_required": true,
    "mfa_completed": false
  },
  "session": {
    "previous_failures": 2,
    "time_since_last_failure": "PT30S"
  }
}

The security log enables answering questions like:

Is this a brute force attack? (check previous_failures, time patterns)
Is this an unusual location for this user? (geo data)
Is this happening at an unusual time? (timestamp analysis)
Are multiple accounts targeted from this IP? (correlation by source.ip)

What to Log: The Security Event Taxonomy

Determining what events to log is one of the most critical decisions in security architecture. Log too little, and you miss attacks. Log too much, and you drown in noise while incurring massive storage costs. The key is to identify events with security significance—those that indicate or could indicate security-relevant activity.

A comprehensive security event taxonomy covers several major categories:

Security Event Categories
Category	Event Types	Security Relevance
Authentication Events	Login success/failure, logout, session creation, session termination, MFA challenges, password resets	Detect credential attacks, account takeover, unauthorized access attempts
Authorization Events	Access granted/denied, privilege escalation, role changes, permission modifications	Detect lateral movement, privilege abuse, policy violations
Administrative Actions	User creation/deletion, configuration changes, policy modifications, system updates	Detect insider threats, malicious admins, configuration tampering
Data Access Events	File reads/writes, database queries, API calls, exports, downloads	Detect data exfiltration, unauthorized access to sensitive data
Network Events	Connection attempts, firewall blocks, DNS queries, traffic anomalies	Detect network attacks, C2 communications, lateral movement
System Events	Process execution, service starts/stops, kernel events, driver loads	Detect malware execution, rootkits, persistence mechanisms
Security Tool Events	Antivirus detections, IDS alerts, WAF blocks, vulnerability scan results	Direct security indicators requiring investigation

Authentication Events - The First Line of Detection

Authentication events are often the most valuable security logs because they represent the boundary between anonymous and identified users. Every access to your system begins with authentication, making these events critical for detecting:

Credential stuffing attacks: High volume of failures across many accounts from few sources
Brute force attacks: Many failures for single accounts
Password spraying: Few failures per account but across many accounts
Account takeover: Successful login from unusual locations or devices
Credential theft aftermath: Valid credentials used from attacker infrastructure

Authentication logs should capture:

Authentication Event Details

•Timestamp — High precision (milliseconds) for correlation
•User identifier — Username, email, user ID (all that apply)
•Outcome — Success, failure, locked, expired, MFA required
•Failure reason — Invalid password, unknown user, expired credentials, etc.
•Source IP address — Client IP, considering proxy headers
•Geolocation data — Derived from IP for anomaly detection
•User agent — Browser/client information for device fingerprinting
•Authentication method — Password, SSO, MFA method used
•Session information — New session ID created, previous session state
•Request metadata — Endpoint accessed, protocol, TLS version

Authorization and Access Control Events

While authentication determines who someone is, authorization determines what they can do. Authorization events are crucial for detecting:

Lateral movement: Users accessing resources outside their normal scope
Privilege escalation: Attempts to gain higher privileges
Data exfiltration: Unusual patterns of data access
Insider threats: Authorized users abusing their access

Authorization logs should capture:

Resource being accessed (with hierarchy: system > service > resource > action)
Permission required vs. permission possessed
Decision outcome (allow/deny/challenge)
Policy that made the decision
Context that influenced the decision (time, location, device state)

Administrative Actions - Configuration Integrity

Administrative actions represent some of the highest-risk events because they can affect system security posture. An attacker with administrative access can:

Create persistence mechanisms (backdoor accounts)
Disable security controls (turn off logging, disable MFA)
Exfiltrate data (increase permissions, modify policies)
Cover tracks (delete logs, modify audit settings)

Administrative action logging must be tamper-resistant. If an admin can both perform actions and delete the logs of those actions, the logging provides false assurance. Best practices include:

Immediate forwarding to write-once storage
Cryptographic integrity verification
Separation of duties (admins cannot access log storage)
Anomaly detection on administrative action patterns

The 'Crown Jewels' Approach

Apply the most comprehensive logging to your most valuable assets. Identify your 'crown jewels' (customer PII databases, financial systems, intellectual property repositories) and ensure every access to these systems is logged with maximum context. Lesser systems can use proportionally less detailed logging, balancing security with cost.

Log Format Design

The format of your security logs profoundly affects their utility. Well-designed log formats enable automated parsing, efficient storage, powerful querying, and meaningful correlation. Poorly designed formats create parsing nightmares, lose critical context, and make analysis labor-intensive.

Structured vs. Unstructured Logs

The security industry has largely moved from unstructured text logs to structured formats, and for good reason:

Unstructured Logs

•Requires regex parsing for each format
•Format changes break parsers
•Context often lost or inconsistent
•Difficult to query specific fields
•Human-readable but machine-hostile
•Example: Jan 15 14:32:17 auth failed user jdoe from 192.168.1.105

Structured Logs (JSON)

•Native parsing by all modern tools
•Schema evolution without breaking changes
•Consistent, complete context
•Direct field-level querying
•Both human and machine-readable
•Example: {"timestamp":"...","event":"auth.failure",...}

Adopting Industry Standards

Rather than inventing your own log format, adopt established standards that provide:

Common Schema: Pre-defined field names and structures that tools understand
Normalization: Mapping different sources to common fields for correlation
Extensibility: Ability to add custom fields without breaking compatibility
Ecosystem Support: Parsers, analyzers, and visualization tools already built

Major Security Log Standards:

Elastic Common Schema (ECS) — A framework for structuring data with common fields for categories like host, user, source, destination, and event. Widely adopted in the Elastic ecosystem but usable anywhere.

Open Cybersecurity Schema Framework (OCSF) — An open-source project backed by AWS, Splunk, IBM, and others that defines a vendor-agnostic schema for security events. Designed specifically for security use cases.

CEF (Common Event Format) — An older format developed by ArcSight, still widely used in legacy SIEM deployments. Structured but uses a custom syntax rather than JSON.

Syslog (RFC 5424) — The traditional Unix logging standard, still relevant for network devices and operating systems. Modern implementations support structured data extensions.

security_event_schema.json
JSON Schema
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Security Event",
  "type": "object",
  "required": ["@timestamp", "event", "source"],
  "properties": {
    "@timestamp": {
      "type": "string",
      "format": "date-time",
      "description": "Event timestamp in ISO 8601 format with milliseconds"
    },
    "event": {
      "type": "object",
      "required": ["category", "type", "outcome"],
      "properties": {
        "category": {
          "type": "string",
          "enum": ["authentication", "authorization", "network", 
                   "file", "process", "admin", "iam"],
          "description": "High-level event category"
        },
        "type": {
          "type": "string",
          "description": "Specific event type within category"
        },
        "action": {
          "type": "string",
          "description": "Action performed (login, access, create, etc.)"
        },
        "outcome": {
          "type": "string",
          "enum": ["success", "failure", "unknown"],
          "description": "Result of the action"
        },
        "reason": {
          "type": "string",
          "description": "Why outcome occurred (for failures)"
        },
        "severity": {
          "type": "integer",
          "minimum": 0,
          "maximum": 10,
          "description": "Security severity 0 (info) to 10 (critical)"
        }
      }
    },
    "source": {
      "type": "object",
      "properties": {
        "ip": { "type": "string", "format": "ipv4" },
        "port": { "type": "integer" },
        "geo": {
          "type": "object",
          "properties": {
            "country_iso_code": { "type": "string" },
            "city_name": { "type": "string" },
            "location": {
              "type": "object",
              "properties": {
                "lat": { "type": "number" },
                "lon": { "type": "number" }
              }
            }
          }
        },
        "user_agent": { "type": "string" }
      }
    },
    "user": {
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "name": { "type": "string" },
        "email": { "type": "string", "format": "email" },
        "roles": { "type": "array", "items": { "type": "string" } }
      }
    },
    "target": {
      "type": "object",
      "properties": {
        "service": { "type": "string" },
        "resource": { "type": "string" },
        "action": { "type": "string" }
      }
    },
    "trace": {
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "span_id": { "type": "string" },
        "parent_span_id": { "type": "string" }
      }
    }
  }
}

Essential Fields for Security Events

Regardless of which standard you adopt, ensure your security events include these critical fields:

Temporal Fields:

@timestamp: When the event occurred (source system time, UTC preferred)
event.ingested: When the log was received by central system
event.created: When the event record was created (if different from occurrence)

Actor Fields:

user.id: Immutable user identifier
user.name: Human-readable username
user.email: Email if available
user.roles: Active roles at time of event
user.effective_id: If acting as another user (sudo, impersonation)

Source Fields:

source.ip: Client IP address
source.geo: Geolocation data derived from IP
source.user_agent: Client identifier string
source.device: Device fingerprint or identifier if available

Event Classification:

event.category: Broad category (authentication, authorization, etc.)
event.type: Specific type within category
event.action: The action performed
event.outcome: Success, failure, unknown
event.severity: Numeric severity for prioritization

Correlation Fields:

trace.id: Distributed tracing ID for request correlation
session.id: User session identifier
transaction.id: Business transaction identifier

Centralized Logging Architecture

In distributed systems, security events are generated across dozens or hundreds of services, each producing logs locally. A centralized logging architecture aggregates these events into a unified platform where they can be searched, analyzed, correlated, and retained according to policy.

Centralized logging is not optional for security—it's mandatory. Without centralization:

You cannot correlate events across services to detect multi-stage attacks
Log retention becomes inconsistent and ungovernable
Incident investigation requires accessing each system individually
Attackers who compromise a system can delete local logs

Converting Mermaid diagram...

Collection Layer: Getting Logs Off the Source

The collection layer is responsible for reliably moving logs from source systems to the central platform. Key considerations:

Log Agents (Filebeat, Fluent Bit, Vector): Software running on each host that reads logs from files or stdout and ships them to the transport layer. Agents should:

Handle back-pressure gracefully (queue when downstream is slow)
Guarantee at-least-once delivery
Minimize resource consumption on the host
Support structured and unstructured log formats

Syslog Receivers: Many network devices, load balancers, and security appliances only support syslog. Deploy dedicated syslog collectors (rsyslog, syslog-ng) that forward to your transport layer.

API Collectors: Cloud services and SaaS applications expose logs via APIs. Deploy collectors that poll these APIs and normalize events to your schema.

Security Considerations for Collection:

Encrypt log transport (TLS minimum)
Authenticate agents to collectors (mTLS preferred)
Sign log entries at source for integrity verification
Minimize agent privileges on source systems

Transport Layer: Reliable, Scalable Delivery

The transport layer moves logs from collectors to processing. Modern architectures use message queues (Kafka, Kinesis, Pulsar) rather than direct connections. Benefits:

Decoupling: Sources and processors can operate independently
Buffering: Handle spikes in log volume without data loss
Scalability: Add consumers without changing producers
Replayability: Re-process historical logs when rules change
Durability: Logs persist until confirmed processed

Kafka Cluster Design for Security Logs:

Topic: security-events-raw
  Partitions: 24 (scale with ingestion rate)
  Replication Factor: 3 (durability)
  Retention: 7 days (pre-processing buffer)
  Compaction: disabled (need all events)
  
Topic: security-events-normalized
  Partitions: 24
  Replication Factor: 3
  Retention: 7 days
  
Topic: security-alerts
  Partitions: 6
  Replication Factor: 3
  Retention: 30 days

Processing Layer: Parse, Normalize, Enrich

Raw logs from diverse sources need processing before they're useful for security analysis:

Parsing: Extract structured fields from various formats (JSON, syslog, custom formats). Use schema registries to manage parsers.

Normalization: Map source-specific field names to your common schema. Example:

AWS CloudTrail: userIdentity.arn → user.id
Okta: actor.alternateId → user.email
Linux auth.log: USER=jdoe → user.name

Enrichment: Add context not present in the original event:

Geo-IP enrichment: Convert IP addresses to geographic data
ASN enrichment: Add autonomous system number and organization
Threat intelligence: Check IPs/domains against threat feeds
Asset context: Add asset owner, criticality, network zone
User context: Add department, manager, risk score from IAM

Filtering/Routing: Send different events to different destinations:

High-severity alerts → immediate alerting system
Compliance-relevant events → compliance-specific indices
High-volume, low-value events → compressed cold storage

Processing Pipeline Reliability

Your processing pipeline is security-critical infrastructure. If it fails, you lose security visibility. Design for high availability with redundant processors, dead-letter queues for parsing failures, and comprehensive monitoring of pipeline health. A misconfigured parser that silently drops events can blind your security team for hours or days.

Storage Strategy and Retention

Security log storage presents unique challenges: you need fast queries for real-time detection, long retention for compliance and forensics, and massive scale as distributed systems generate billions of events daily. The solution is tiered storage with hot, warm, and cold layers.

Hot Storage (0-7 days): Optimized for query speed. Events here are actively searched during investigations and feed real-time alerting. Technologies: Elasticsearch, Splunk, ClickHouse.

Warm Storage (7-90 days): Optimized for cost-efficient querying. Accessed for investigations beyond immediate incidents. May use slower, cheaper storage tiers. Technologies: Elasticsearch frozen tier, S3 + query engines.

Cold Storage (90+ days): Optimized for retention cost. Rarely accessed but required for compliance or deep investigations. Technologies: S3 Glacier, Google Coldline, Azure Archive.

Tiered Storage Characteristics
Tier	Retention	Access Time	Query Speed	Cost/GB/Month	Use Case
Hot	0-7 days	Instant	Sub-second	$0.50-1.00	Real-time alerting, active investigations
Warm	7-90 days	Seconds	Seconds-minutes	$0.10-0.30	Recent incident investigation, trend analysis
Cold (Archive)	90 days-7 years	Hours	Hours-days	$0.004-0.01	Compliance retention, forensic investigations

Retention Requirements by Regulation

Compliance requirements often dictate minimum retention periods:

PCI DSS: 1 year minimum, 3 months immediately accessible
HIPAA: 6 years for audit logs
SOC 2: 1 year typical, varies by trust service criteria
GDPR: No minimum, but must be able to demonstrate compliance
Financial services (SEC 17a-4): 6 years, 2 years immediately accessible

Design your retention policy to meet the most stringent applicable requirement, but implement tiered storage to manage costs.

Log Integrity and Tamper Evidence

Security logs are only valuable if they're trustworthy. An attacker who gains system access often attempts to modify or delete logs to cover their tracks. Implement integrity controls:

Write-Once Storage: Use immutable storage (S3 Object Lock, WORM-compliant storage) for log archives. Once written, logs cannot be modified or deleted until retention expires.

Cryptographic Signing: Sign log entries or batches at the source. Any modification invalidates signatures.

Hash Chains: Create cryptographic chains linking log entries. Deletion or modification breaks the chain.

Third-Party Attestation: Forward copies to an independent system that can attest to what was received.

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Log Entry 1   │───▶│   Log Entry 2   │───▶│   Log Entry 3   │
│ hash: abc123    │    │ prev: abc123    │    │ prev: def456    │
│                 │    │ hash: def456    │    │ hash: ghi789    │
└─────────────────┘    └─────────────────┘    └─────────────────┘
        ▲                       ▲                       ▲
        │                       │                       │
    Can't modify           Can't delete           Chain proves
    without breaking       without breaking       completeness
    hash chain             hash chain

Cost Optimization Strategy

Storage costs dominate log platform expenses. Optimize by: (1) Filtering out known-low-value events before storage, (2) Using aggressive compression on cold storage, (3) Sampling high-volume, low-value events, (4) Storing parsed/normalized data rather than raw duplicates, (5) Right-sizing hot tier retention to actual investigation patterns.

Implementation Best Practices

Implementing security event logging in production requires careful attention to reliability, performance, and security. Here are battle-tested practices from organizations operating at scale:

Security Logging Best Practices

•Log at the point of decision — Capture events where security decisions are made (authentication service, authorization middleware, data access layer), not where they're consumed. This ensures context is available.
•Include correlation IDs everywhere — Every request should carry a trace ID that's included in all logs. This enables stitching together events from a single user session or transaction across services.
•Treat logging as critical infrastructure — Apply the same SLOs to logging as to user-facing services. If logging fails, security visibility fails. Monitor pipeline health, set alerts for ingestion drops.
•Separate security and operational logs — While they may share infrastructure, treat them as distinct data streams with different retention, access controls, and analysis. Security logs may require stricter access.
•Test log coverage regularly — Conduct 'detection engineering' exercises where you simulate attacks and verify logs capture the activity. Gaps in logging are discovered during attacks or during testing—choose testing.
•Document log schema changes — Schema changes can break downstream parsers and alerts. Maintain schema versioning and communicate changes to consumers before deployment.
•Implement log level controls — Enable dynamic adjustment of logging verbosity. During incidents, you may need DEBUG-level security logs temporarily without deploying new code.
•Sanitize sensitive data — Never log passwords, credit card numbers, or other secrets. Implement redaction at the logging framework level to catch developer mistakes.

secure_logging_middleware.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
import { Request, Response, NextFunction } from 'express';
import { v4 as uuidv4 } from 'uuid';
import { securityLogger } from './security-logger';
 
// Patterns for sensitive data that should never be logged
const SENSITIVE_PATTERNS = [
  { regex: /password/i, replacement: '[REDACTED]' },
  { regex: /authorization:s*bearers+[a-zA-Z0-9-_]+/gi, replacement: 'Authorization: Bearer [REDACTED]' },
  { regex: /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/g, replacement: '[CARD_REDACTED]' },
  { regex: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/g, replacement: '[EMAIL_REDACTED]' },
];
 
function sanitize(data: unknown): unknown {
  if (typeof data === 'string') {
    return SENSITIVE_PATTERNS.reduce(
      (str, pattern) => str.replace(pattern.regex, pattern.replacement),
      data
    );
  }
  if (typeof data === 'object' && data !== null) {
    const sanitized: Record<string, unknown> = {};
    for (const [key, value] of Object.entries(data)) {
      if (SENSITIVE_PATTERNS.some(p => p.regex.test(key))) {
        sanitized[key] = '[REDACTED]';
      } else {
        sanitized[key] = sanitize(value);
      }
    }
    return sanitized;
  }
  return data;
}
 
export function securityLoggingMiddleware(req: Request, res: Response, next: NextFunction) {
  // Ensure correlation ID exists
  const traceId = req.headers['x-trace-id'] as string || uuidv4();
  req.headers['x-trace-id'] = traceId;
  res.setHeader('x-trace-id', traceId);
  
  const startTime = Date.now();
  
  // Log request start
  securityLogger.info({
    '@timestamp': new Date().toISOString(),
    'event.category': 'web',
    'event.type': 'access',
    'event.action': 'request_start',
    'trace.id': traceId,
    'http.request.method': req.method,
    'url.path': req.path,
    'source.ip': req.ip || req.socket.remoteAddress,
    'source.user_agent': sanitize(req.headers['user-agent']),
    'user.id': (req as any).user?.id,
    'user.name': sanitize((req as any).user?.name),
  });
  
  // Capture response
  const originalSend = res.send;
  res.send = function(body) {
    const duration = Date.now() - startTime;
    
    securityLogger.info({
      '@timestamp': new Date().toISOString(),
      'event.category': 'web',
      'event.type': 'access',
      'event.action': 'request_end',
      'event.outcome': res.statusCode >= 400 ? 'failure' : 'success',
      'trace.id': traceId,
      'http.request.method': req.method,
      'url.path': req.path,
      'http.response.status_code': res.statusCode,
      'event.duration': duration * 1_000_000, // nanoseconds
      'source.ip': req.ip || req.socket.remoteAddress,
      'user.id': (req as any).user?.id,
    });
    
    return originalSend.call(this, body);
  };
  
  next();
}

Common Pitfalls and Anti-Patterns

Even experienced organizations make predictable mistakes when implementing security logging. Learn from these common anti-patterns:

Anti-Patterns to Avoid

•Logging everything without purpose — More logs ≠ better security. Logging every variable and function call creates noise that obscures meaningful events. Be intentional about what you capture.
•Inconsistent timestamps — Different systems using different time zones or lacking synchronization makes correlation impossible. Use UTC everywhere and ensure NTP sync across all systems.
•Logging sensitive data — Passwords, tokens, PII, and secrets in logs create a new attack surface. If logs are compromised, so is the data in them. Implement redaction at the framework level.
•No correlation IDs — Without request/trace IDs, connecting events from the same incident across services requires timestamp fuzzy matching—unreliable at scale.
•Ignoring log pipeline failures — Silent log drops mean blind spots. One team had 40% of auth failures not logging due to a parser bug—discovered months later during an incident.
•Not testing log coverage — Assuming logs capture security events without verification. Run attack simulations and verify logs contain expected events.
•Insufficient context — Logging 'access denied' without who, what, where, and why requires investigation to understand. Include complete context in every event.
•No schema management — Ad-hoc field names across teams create parsing nightmares. 'user_id', 'userId', 'uid', 'user' for the same concept across services.

The Hidden Danger of Log-Based Attacks

Logs themselves can be attack vectors. Log injection attacks occur when user input ends up in logs—attackers can inject fake log entries, corrupt format, or exploit log parsing vulnerabilities (Log4Shell). Always sanitize user input before logging and use structured logging to prevent format manipulation.

Summary: Security Event Logging Foundations

Security event logging is the foundation upon which all other security monitoring capabilities are built. Without comprehensive, reliable, well-structured logs, detection becomes guessing, investigation becomes archeology, and compliance becomes hope.

Key Takeaways

•Security logging differs from operational logging — Security logs require complete context, reliable capture, long retention, and tamper resistance.
•Know what to log — Authentication, authorization, administrative actions, data access, network events, and system events form the core security event taxonomy.
•Use structured, standardized formats — Adopt schemas like ECS or OCSF for consistent parsing, correlation, and tool ecosystem support.
•Centralize logging with reliable pipelines — Collection, transport, processing, and storage layers must be designed for high availability and scale.
•Implement tiered storage — Balance query performance and cost with hot, warm, and cold storage tiers aligned to access patterns.
•Ensure log integrity — Use write-once storage, cryptographic signing, and hash chains to prevent tampering by attackers.
•Treat logging as critical infrastructure — Monitor pipeline health, test log coverage, and maintain SLOs for your logging platform.

What's Next:

With security event logging in place, the next step is using those logs to detect threats. The following page covers Intrusion Detection—how to analyze security events to identify attacks in progress, from signature-based detection to behavioral analysis and network-based approaches.

Page Complete

You now understand the principles and practices of security event logging. This foundation enables all subsequent security monitoring capabilities—detection, investigation, response, and compliance. The logs you capture today determine what threats you can find tomorrow.