Insufficient Logging & Monitoring

What Is Insufficient Logging & Monitoring?

This is a detection failure rather than an access failure. When a request is authorized, no access control will reject it, so the audit trail is the only thing that catches abuse. You'll use a valid support-agent token to read a customer's date of birth, national ID and account balances with no ticket behind the request. Then you are asked which agent read that record, and cannot say. The fix logs actor, subject, action, ticket, source IP and timestamp to an append-only sink, and alerts on a ticketless read.

What You'll Learn in Insufficient Logging & Monitoring

• Recognize insufficient logging and monitoring as a detection failure: sensitive access is not recorded with enough context, or not monitored, so misuse goes unseen and cannot be reconstructed
• Understand that authorized access (a valid credential used abusively) can only be caught by an audit trail and alerting, since no access control will reject it
• Distinguish it from access-control, data-exposure, and rate-limiting flaws; here a single authorized read is allowed and the missing control is attribution and visibility, not a block or a cap
• Apply the fix: emit an immutable audit event (actor, subject, action, ticket or reason, source IP, timestamp) to an append-only sink, and alert on suspicious access such as a sensitive read with no ticket
• Understand that the fix is detection and accountability, not prevention: a legitimate read stays allowed and still returns 200, while its abuse becomes attributable and alertable

Insufficient Logging & Monitoring — Training Steps

1. An agent with access

   Norvane is a digital bank. Its support agents look up customer accounts all day to handle tickets, using an internal console backed by the customer API. Bob is one of those agents, and he sells what he can reach. A fraud ring has paid him for a complete identity, so he has picked a Norvane customer with a large balance, someone he has no ticket for and no reason to touch. His access is real and his token is valid, so nothing he is about to do will be rejected. He opens the agent console to pull her record.

2. The lookup endpoint

   The customer lookup returns a full profile, and Bob's agent token is allowed to call it. Lookups are meant to reference the ticket the agent is working, but the API itself does not require one.

3. Pull the record

   Bob calls the lookup endpoint for the customer he was paid to steal, carrying his agent token and no ticket. It is a single, ordinary-looking request, the same call he makes dozens of times a day for real tickets, which is exactly why it will not stand out.

4. One person's whole life

   The token works. The server returned the customer's complete record.

5. Knowledge check

   You just watched a support agent pull one customer's entire identity with a valid token and no ticket. Lock in what kind of failure this is.

6. Which agent read this?

   You own audit logging and monitoring for Norvane's customer API. A customer's identity has been stolen and used for fraud, and the details could only have come from inside Norvane. Trust & Safety has emailed you with one question they can't answer on their own.

7. Read the application log

   Before touching code, you check what the API actually recorded. Tail the application log and look for anything that ties a lookup to an agent or to the customer whose data leaked.

8. No way to answer

   This is everything the API recorded about those lookups.

9. Open the lookup handler

   Open the customer-lookup handler and look at what it records when it serves a request.

10. Spot the flaw

    The handler checks the agent token, reads the customer, and returns the full profile. The one line it logs is the line you just saw: a note that a lookup happened, with none of the context that would make it an audit record.