Logging & Monitoring Failures (OWASP A09)

Why this category is different

Every other OWASP category asks whether something can be exploited. This one asks whether you would know. It cannot be answered by reviewing a logging configuration, because the question is not whether logs exist but whether the events that matter are captured, retained, correlated and acted upon.

A penetration test is the only routine opportunity to answer it with real data, because for the duration of the engagement your production systems are under genuine attack by someone who will tell you exactly what they did.

What we assess for logging and monitoring gaps

Coverage of security events: authentication outcomes, authorisation denials, privilege changes, credential and factor changes, exports and administrative actions
Detection of our activity — which phases produced alerts, which produced log entries nobody read, and which left no trace
Log integrity: whether an authenticated user can suppress, forge or inject entries, including through log injection
Retention and availability, and whether logs would still exist when an incident is discovered months later
Correlation across application, gateway, database and cloud audit sources, since single-source logs rarely reconstruct an attack
Sensitive data in logs, which turns your logging platform into an additional exposure
Alert quality — whether thresholds fire on real attacks and stay quiet otherwise, and whether anyone is on the other end
Response capability: whether the logged data would actually support an investigation

How we test for logging and monitoring gaps

We keep a timestamped record of our own activity throughout the engagement: enumeration, credential attempts, authorisation probing, exploitation and data access. At the end we compare that timeline against what your systems recorded and what your team noticed.

The result is usually uncomfortable and highly actionable. Teams frequently discover that a sustained authorisation probing campaign across thousands of requests produced no alert, while a single failed login triggered a notification. That gap is a detection engineering problem, and it is precisely specifiable once you have the timeline.

Where you want it, we run specific detection test cases and tell you which fired, giving you a measured baseline rather than an assumption.

What you receive on logging and monitoring gaps

Our full attack timeline, so you can replay it against your logging platform whenever you change it
A gap list: events that should have been logged and were not, and logged events that should have alerted
Suggested detection logic for the attack patterns we used against your specific application
Findings where logs contained sensitive data that should have been redacted
An assessment of whether the retained data would support an investigation after the fact

Common questions

Why is logging part of a penetration test?

Because a test is the only time you get an authentic attack with a known ground truth. Comparing what actually happened against what your systems recorded gives you a measured detection capability rather than an assumed one, and the gap list is specific enough to act on immediately.

Should we tell our security team the test is happening?

That is your decision and both options produce value. Announced testing verifies that events are logged and correlatable. Unannounced testing, agreed with a small number of stakeholders, additionally tests whether anyone notices and responds. We recommend the second at least once, because detection without response is not detection.

What if we find we logged nothing at all?

That is a common and useful result, and it is far better to learn it from us than during an incident. The remediation is incremental: start with authentication outcomes, authorisation denials and administrative actions, get those correlated and alerting, then widen coverage. Our attack timeline gives you a concrete test set to validate each step.

Which events should we be logging for security?

Start with authentication outcomes including failures, authorisation denials, privilege and role changes, credential and second-factor changes, administrative actions, and bulk data access or export. Each entry needs enough context to answer who, what, when and from where. That set alone will let you reconstruct most incidents, and it is a much shorter list than logging everything.

How long should we retain security logs?

Long enough to investigate an incident you have not noticed yet, which is longer than most teams assume — breaches are frequently discovered months after the initial access. Where a framework sets a floor, meet it; PCI-DSS is explicit about retention. Otherwise choose a period based on how long it realistically takes you to detect something, then keep more than that.

Do you provide detection rules we can implement?

Yes. Because we keep a timestamped record of our own activity, we can tell you which patterns your systems missed and describe detection logic for those specific patterns against your application. That is more useful than generic rules, because it is tuned to what an attacker actually did to your system rather than to a vendor's default set.

Is sensitive data in logs a serious finding?

It can be one of the more serious, because it multiplies your exposure surface. Logging platforms are typically accessible to more engineers than production databases, are replicated to more places, are retained longer, and are frequently excluded from the access reviews applied to the primary data store. Credentials, tokens and personal data in logs get reported accordingly.

Let's scope your infrastructure.

Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.

Request a Technical Scope Direct line himanshu@wimd.in +91 88600 00832