Bağışla — problem məndən qaynaqlandı. A09 məqaləsini bütöv bir `markdown bloku içində vermişdim, amma məqalənin özündə də kod blokları var idi. Ona görə kopyalayanda Markdown strukturu pozulurdu.

Aşağıda A09-u yenidən, birbaşa .md məzmunu kimi verirəm. Kənarında əlavə kod bloku yoxdur: cavabın məzmununu olduğu kimi A09-Security-Logging-and-Monitoring-Failures.md faylına köçürə bilərsən.

🔍 A09:2021 — Security Logging and Monitoring Failures

An attack you cannot detect can continue long after the vulnerability that enabled it has been fixed.

A successful security program needs more than preventive controls. Authentication can fail. A dependency can be compromised. An administrator can make a mistake. When that happens, logging and monitoring determine whether the incident is discovered in minutes—or reconstructed months later from incomplete evidence.

A09:2021 — Security Logging and Monitoring Failures addresses the systems, processes, and decisions required to detect attacks, investigate them, and respond effectively. The category is not simply about writing more log lines. It is about producing useful security evidence, protecting that evidence, turning it into actionable alerts, and ensuring someone acts on those alerts.

📖 Table of Contents

1. Introduction
2. What Is a Security Logging and Monitoring Failure?
3. The Detection Lifecycle
4. A09 Compared with Other OWASP Categories
5. Real-World Lessons
6. Relevant CWEs
7. What Should Be Logged?
8. What Must Never Be Logged?
9. Log Injection and Evidence Tampering
10. Detection Engineering and Alerting
11. Cloud-Native Logging Challenges
12. Vulnerable vs. Secure Code
13. Tools and Standards
14. Interactive Review Widget
15. ✅ Ultimate Checklist
16. Conclusion
17. Further Reading

18. Introduction

OWASP placed Security Logging and Monitoring Failures at #9 in its 2021 Top 10.

The central problem is straightforward:

If an application cannot record meaningful security events, or an organization cannot detect and respond to those events, an attacker may remain active without being noticed.

Logging and monitoring are related but distinct:

A system that writes detailed logs but never analyzes them has logging, not effective monitoring. A SIEM that raises accurate alerts that nobody investigates has detection, not effective response.

Why A09 amplifies other failures

Imagine an application has an authorization flaw that lets a normal user export records belonging to another customer.

• With strong A09 controls, unusual export activity may trigger an alert within minutes.
• With weak A09 controls, the attacker may repeat the export until the customer notices missing or exposed data.
• With no usable audit trail, the organization may be unable to determine which records were accessed.

A09 often does not create the initial breach. It determines how long the breach lasts and whether its scope can be established.

1. What Is a Security Logging and Monitoring Failure?

A security logging and monitoring failure occurs when security-relevant activity is not recorded, is recorded without useful context, cannot be trusted, is not examined, does not generate actionable alerts, or does not lead to a timely response.

Common examples include:

• Failed logins are not recorded.
• Privilege changes appear only in generic application logs.
• Logs contain timestamps but no user ID or request ID.
• Application servers retain logs only on local disks.
• A compromised administrator can delete the audit trail.
• An alert fires, but there is no assigned owner or response procedure.
• Production logs contain passwords, access tokens, or payment details.
• A critical service stops sending logs, and nobody notices the silence.

A practical definition

An effective security event should allow an investigator to answer:

1. When did it happen?
2. What happened?
3. Which account or service performed the action?
4. Which resource was affected?
5. From where did the activity originate?
6. Was the action allowed or denied?
7. Which other events belong to the same request or session?
8. Can the record be trusted?

If several of these answers are missing, the log may exist but have little investigative value.

1. The Detection Lifecycle

The crucial insight

The lifecycle is only as strong as its weakest stage.

Perfect application logs do not help if they never reach central storage. Excellent SIEM rules do not help if the required events were never logged. Immediate alerts do not help if nobody owns the response.

1. A09 Compared with Other OWASP Categories

A09 is not a substitute for prevention. Logging an unauthorized data export does not make the export safe. It gives defenders a chance to discover, contain, and investigate it.

1. Real-World Lessons

5.1 Target: A detection is not a response

During the 2013 Target breach, attackers used compromised third-party access and ultimately stole payment-card data. Public reporting established that security tooling generated warnings about malicious activity, yet those warnings did not result in timely containment.

The lesson is not merely “install a detection product.” The lesson is:

An alert must have an owner, priority, investigation procedure, and escalation path.

5.2 Equifax: Monitoring blind spots matter

The 2017 Equifax breach began with exploitation of an unpatched Apache Struts vulnerability. Investigations also identified failures in security operations and visibility. An expired certificate affected a network monitoring tool’s ability to inspect relevant traffic.

The broader lesson is that the health of monitoring controls must itself be monitored.

Examples of alerts that deserve immediate attention include:

• An inspection certificate approaching expiration
• A log collector that stops receiving events
• A disabled audit policy
• A sharp drop in expected log volume
• A security agent that stops reporting

A dashboard showing “no suspicious activity” is not reassuring if the sensor is offline.

5.3 SolarWinds: Monitor the software factory

The SolarWinds compromise demonstrated that a build and update pipeline can become an attacker’s distribution channel.

An A09 program should therefore cover not just production applications but also:

• Source-control administration
• CI/CD workflow changes
• Build-runner activity
• Secrets access
• Artifact publication
• Signing-key use
• Deployment approvals

If production is monitored but the build pipeline is invisible, attackers may compromise software before it reaches production.

5.4 The lesson behind long breach lifecycles

Incident reports often measure how long it takes organizations to identify and contain breaches. Those averages vary by study and year, but the operational implication remains the same: detection delay gives attackers time to move, persist, and expand impact.

Do not treat an industry-wide average as a target. For high-confidence events—such as a production audit log being disabled—the desired response time should be measured in minutes, not months.

1. Relevant CWEs

A09 encompasses multiple weaknesses rather than one specific bug.

CWE-778 — Insufficient Logging

Security-relevant events are not recorded.

Example: An administrator changes another user’s MFA settings, but the application logs only "Settings updated".

Better event:

{
  "event": "mfa_settings_changed",
  "actor_id": "user_142",
  "target_user_id": "user_827",
  "action": "disable",
  "outcome": "success",
  "request_id": "req_68c2...",
  "timestamp": "2025-02-20T12:40:18Z"
}

CWE-223 — Omission of Security-Relevant Information

An event is logged, but essential context is missing.

Weak:

Login failed.

Useful:

{
  "event": "authentication_failed",
  "account_reference": "acct_72f...",
  "source_ip": "203.0.113.42",
  "outcome": "denied",
  "reason_category": "invalid_credentials",
  "request_id": "req_68c2...",
  "timestamp": "2025-02-20T12:40:18Z"
}

The account_reference should be chosen to support investigation while minimizing unnecessary personal data in logs.

CWE-117 — Improper Output Neutralization for Logs

Attacker-controlled input changes the apparent structure of log output.

Example input:

alice
2025-02-20T12:40:19Z INFO administrator_login_success

If the application writes that value into a plain-text log without escaping line breaks, the attacker may forge what appears to be a second event.

CWE-532 — Insertion of Sensitive Information into a Log File

Logs contain secrets or private data that should never have been recorded.

Examples include:

• Passwords
• Session cookies
• Authorization headers
• API keys
• Password-reset links
• Payment-card numbers
• Medical information

Logging must preserve investigative value without creating a second database of sensitive information.

1. What Should Be Logged?

Start from security decisions and state changes, not from a generic rule to “log every request.”

A useful security-event schema

{
  "timestamp": "2025-02-20T12:40:18Z",
  "event": "customer_data_export",
  "severity": "high",
  "outcome": "success",
  "actor_id": "user_142",
  "resource_type": "customer_records",
  "resource_count": 12000,
  "source_ip": "203.0.113.42",
  "request_id": "req_68c2...",
  "session_reference": "sess_hash_9db...",
  "environment": "production"
}

Design rules for event fields

• Use UTC timestamps and synchronized system clocks.
• Use a stable event name, not free-form prose.
• Include an outcome such as success, failure, or denied.
• Include request or trace IDs for cross-service investigation.
• Identify the actor and affected resource without dumping entire objects.
• Avoid placing attacker-controlled text in fields used as trusted labels.
• Define a schema and validate it in tests.

1. What Must Never Be Logged?

The correct objective is high-signal logging, not indiscriminate logging.

Secrets to exclude

• Passwords and password-reset tokens
• Session IDs and cookies
• OAuth access and refresh tokens
• API keys
• Private keys
• Authentication headers
• One-time passwords
• Full payment-card data and CVV

Data to minimize

• Email addresses
• Phone numbers
• IP addresses, where privacy rules apply
• Health information
• Government identifiers
• Full request bodies
• Search terms containing personal data

A safe practice is to log a non-reversible reference where possible:

Bad:  session_token=eyJhbGciOi...
Better: session_reference=HMAC(session_token)

If a token reference is needed for correlation, use a keyed digest with a protected key. Simply logging the first or last characters of a live token can expose information and should not be the default.

Privacy and retention are design questions

Before adding a field, ask:

1. What detection or investigation requires it?
2. Who can read it?
3. How long will it be retained?
4. Can the same purpose be served with less sensitive data?
5. Is deletion or retention subject to applicable law or contractual requirements?

6. Log Injection and Evidence Tampering

9.1 Log injection

The vulnerable pattern:

logger.warning("Login failed for username: " + username)

If username contains newline characters, a line-oriented log viewer may present attacker-controlled text as a separate event.

Defenses:

• Prefer structured logging.
• Escape or reject control characters in fields displayed as text.
• Limit field lengths.
• Encode logs safely in any web-based viewer.
• Do not interpret log content as shell commands or executable templates.

Parameterized logging improves performance and consistency, but it does not by itself make attacker-controlled text safe in every downstream log viewer. The output format and viewer also matter.

9.2 Log tampering

An attacker with access to an application server may try to delete or change local logs.

Recommended controls:

• Forward security logs off-host promptly.
• Put logging infrastructure in a separate security account or project.
• Restrict deletion and configuration permissions.
• Use immutable or retention-locked storage where appropriate.
• Alert when log forwarding stops.
• Test whether a compromised application identity can alter stored evidence.

1. Detection Engineering and Alerting

Collecting logs is the beginning of detection engineering, not the end.

A useful detection rule should specify:

• Threat hypothesis: What attacker behavior are we trying to identify?
• Required events: Which sources and fields must exist?
• Logic: What sequence or threshold indicates concern?
• Expected false positives: What legitimate activity might match?
• Owner: Who receives and investigates the alert?
• Response: What should that person do first?
• Test: How do we prove the rule still works?

Example: suspicious account takeover sequence

One failed login is usually low-confidence. A failed-login burst followed by successful access, MFA changes, and a bulk export is a much stronger signal.

Alerts worth designing early

Avoid alert fatigue

Do not make every validation failure a pager alert. Separate:

• Events: Recorded for investigation.
• Signals: Worth automated analysis.
• Alerts: Worth human review.
• Pages: Require immediate action.

Tune rules against actual traffic and regularly review missed incidents and false positives.

1. Cloud-Native Logging Challenges

Cloud and container environments create short-lived systems and fragmented evidence.

Kubernetes

Pods can disappear quickly. If their logs are only available on the node, the evidence may disappear with the workload.

Monitor:

• Kubernetes API audit events
• Changes to roles and role bindings
• Container creation with elevated privileges
• Secret access
• Admission-controller decisions
• Runtime alerts
• Missing logs from workloads expected to be active

Serverless

A single user request may cross several functions and managed services. Propagate trace IDs and ensure each function records relevant security decisions.

Multi-account and multi-region cloud

Verify that audit logging covers every applicable account, subscription, project, and region. A single omitted environment may become an investigative blind spot.

CI/CD

Production monitoring alone will not reveal every software supply-chain attack. Record and alert on:

• Repository permission changes
• Workflow modifications
• New deployment credentials
• Artifact digest changes
• Signing activity
• Unexpected releases

1. Vulnerable vs. Secure Code

12.1 🔴 Vulnerable: missing security events and leaked secrets

# ══════════════════════════════════════════════════════════════
# 🔴 VULNERABLE — illustrative Flask endpoint
# ══════════════════════════════════════════════════════════════

from flask import Flask, request
import logging

app = Flask(__name__)
logger = logging.getLogger(__name__)

@app.post("/login")
def login():
    username = request.form.get("username", "")
    password = request.form.get("password", "")

    # Dangerous: writes a password to a log.
    logger.info("Login request: username=%s password=%s", username, password)

    user = find_user(username)

    if user and verify_password(user, password):
        return {"status": "ok"}, 200

    # Dangerous: no useful authentication-failure event.
    return {"error": "Invalid credentials"}, 401

Problems:

1. The password enters the log.
2. Failure events lack context.
3. There is no request identifier.
4. User-controlled text may create confusing output in line-oriented logs.
5. Investigators cannot reliably correlate the login with other activity.

12.2 🟢 Secure: structured, minimal authentication events

# ══════════════════════════════════════════════════════════════
# 🟢 SECURE — illustrative Flask endpoint
# ══════════════════════════════════════════════════════════════

from flask import Flask, request, g
from datetime import datetime, timezone
import json
import logging
import uuid

app = Flask(__name__)
logger = logging.getLogger("security")

@app.before_request
def assign_request_id():
    g.request_id = str(uuid.uuid4())

def security_event(event_name, outcome, **fields):
    event = {
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "event": event_name,
        "outcome": outcome,
        "request_id": g.request_id,
        **fields,
    }

    # Structured JSON keeps individual fields separate.
    # Forward this output to protected, centralized storage.
    logger.info(json.dumps(event, ensure_ascii=True))

@app.post("/login")
def login():
    username = request.form.get("username", "")
    password = request.form.get("password", "")

    user = find_user(username)

    if user and verify_password(user, password):
        security_event(
            "authentication",
            "success",
            actor_id=str(user.id),
            authentication_method="password",
        )

        return {"status": "ok"}, 200

    security_event(
        "authentication",
        "failure",
        # Use a privacy-reviewed reference rather than recording
        # the raw username when it is not necessary.
        attempted_account_reference=account_reference(username),
        reason_category="invalid_credentials",
    )

    # Keep the client response generic to avoid account enumeration.
    return {"error": "Invalid credentials"}, 401

Important: account_reference() should be a stable, privacy-reviewed implementation, such as an HMAC-based reference. Do not replace it with Python’s built-in hash(), which is unsuitable as a durable identifier.

The example focuses on logging; production authentication also needs rate limiting, secure sessions, and appropriate MFA.

12.3 🔴 Vulnerable: request-body logging

// ══════════════════════════════════════════════════════════════
// 🔴 VULNERABLE
// ══════════════════════════════════════════════════════════════

app.use((req, res, next) => {
  console.log({
    path: req.path,
    headers: req.headers, // May include Authorization and Cookie.
    body: req.body         // May include passwords or payment data.
  });

  next();
});

12.4 🟢 Secure: explicitly selected fields

// ══════════════════════════════════════════════════════════════
// 🟢 SECURE
// ══════════════════════════════════════════════════════════════

const crypto = require("node:crypto");

app.use((req, res, next) => {
  const requestId = crypto.randomUUID();
  req.requestId = requestId;

  const event = {
    timestamp: new Date().toISOString(),
    event: "http_request",
    request_id: requestId,
    method: req.method,
    route: req.route?.path ?? req.path,
    // Do not log Authorization, Cookie, or entire request bodies.
  };

  securityLogger.info(event);
  next();
});

An allowlist of fields is generally safer than attempting to redact an unrestricted copy of every request. Redaction rules can miss new fields or unexpected nesting.

12.5 🟢 Detection pseudocode: source silence

# ══════════════════════════════════════════════════════════════
# 🟢 MONITOR THE MONITORING SYSTEM
# ══════════════════════════════════════════════════════════════

EXPECTED_SOURCES = {
    "production-api",
    "identity-provider",
    "deployment-pipeline",
    "cloud-audit",
}

for source in EXPECTED_SOURCES:
    last_seen = get_last_event_timestamp(source)

    if last_seen is None or minutes_since(last_seen) > 10:
        create_high_priority_alert(
            rule="security_log_source_silent",
            source=source,
            description="Expected security events are not arriving.",
        )

Thresholds should reflect each source’s normal event frequency. A service that legitimately emits one event per day needs a different heartbeat strategy from a busy API.

1. Tools and Standards

No tool automatically solves A09. The important questions remain: Are the right events present? Are detections tested? Are alerts owned? Can responders act?

1. Interactive Review Widget

The following disclosure widget works in Markdown renderers that permit basic HTML. Renderers that strip HTML will still show the checklist below it.

<details> <summary><strong>🧪 Five-minute A09 self-assessment — click to expand</strong></summary>

Ask your team:

1. If a production administrator disables audit logging, who receives an alert?
2. Can an application administrator delete centrally stored security events?
3. Can you trace a suspicious request across all relevant services?
4. Can you identify every bulk export performed by one account last week?
5. When did you last test a detection rule end to end?

If any answer is “we do not know,” that uncertainty is itself an A09 finding.

</details>

Note: Animated HTML or JavaScript widgets require an HTML-capable publishing pipeline. Basic .md files do not provide portable JavaScript interactivity; Mermaid diagrams, tables, checkboxes, and <details> are the Markdown-compatible alternatives used here.

1. ✅ Ultimate Checklist

Event design

• [ ] Authentication successes and failures are recorded.
• [ ] MFA enrollment, removal, and failures are recorded.
• [ ] Privilege and permission changes are recorded.
• [ ] Sensitive data exports are recorded.
• [ ] Administrative configuration changes are recorded.
• [ ] Events contain a timestamp, outcome, actor reference, and request ID.
• [ ] Event names and fields follow a documented schema.
• [ ] Relevant systems synchronize their clocks.

Sensitive-data protection

• [ ] Passwords are never logged.
• [ ] Session cookies and live tokens are never logged.
• [ ] Authorization headers are excluded.
• [ ] Payment and health data are excluded unless a narrowly defined requirement permits specific fields.
• [ ] Log-field choices are reviewed for privacy impact.
• [ ] Log viewers safely render attacker-controlled text.

Collection and integrity

• [ ] Security logs are forwarded to central storage.
• [ ] Access to log storage follows least privilege.
• [ ] Application identities cannot delete centrally stored logs.
• [ ] Appropriate retention and immutability controls are configured.
• [ ] Missing log sources trigger alerts.
• [ ] Logging-agent failures trigger alerts.
• [ ] Log ingestion and storage failures are tested.

Detection and response

• [ ] High-risk behaviors have documented detection rules.
• [ ] Alerts have owners and severity levels.
• [ ] Critical alerts have response playbooks.
• [ ] Detection rules are tested with realistic events.
• [ ] False positives are reviewed and tuned.
• [ ] Incident exercises verify that responders can retrieve needed evidence.
• [ ] Monitoring covers production and CI/CD infrastructure.

Cloud and containers

• [ ] Cloud audit logging covers required accounts and regions.
• [ ] Kubernetes audit logs are collected where applicable.
• [ ] Ephemeral workload logs are forwarded before workloads disappear.
• [ ] Deployment and artifact-publication events are monitored.
• [ ] Cross-service request or trace IDs are propagated.

1. Conclusion

Security logging and monitoring are not a pile of log files. They are an operational promise:

When something important happens, we will record it accurately, preserve the evidence, recognize the danger, and act.

Five takeaways

1. Record security decisions, not just application errors.
2. Protect logs as evidence; do not rely only on files stored on the affected server.
3. Minimize sensitive data so logging does not create another breach surface.
4. Monitor the monitoring system for missing sources and disabled controls.
5. Test the entire chain, from event generation to human response.

Final rule: If your team cannot explain how it would discover and investigate a specific attack, that attack may already be happening without anyone knowing.

1. Further Reading

Category: OWASP Top 10 · A09:2021 · Security Logging · Monitoring · Detection Engineering · Incident Response · DevSecOps

A log that nobody can find is not evidence.

An alert that nobody owns is not a response.

Visibility is a security control only when it leads to action.