Security Monitoring: What to Watch in Your Logs

Last verified on Nov 8, 2026.

Security monitoring is the practice of reading your own telemetry for signs that someone is attacking, misusing or could easily exploit your systems. The evidence of an attack is often already in the logs and nobody reads it, or the right event was never logged in the first place.

This guide is the map. It lists the main problem types, what each one looks like in logs, and links to a detailed guide for each.

Start with what you log

The 2021 edition of the OWASP Top 10 lists Security Logging and Monitoring Failures as a category, and its examples are concrete: auditable events such as logins, failed logins and high-value transactions are not logged; warnings and errors generate no or unclear messages; logs of applications and APIs are not monitored for suspicious activity; logs are only stored locally.

The OWASP Logging Cheat Sheet says authentication successes and failures should always be logged, and also recommends logging authorization failures and input validation failures. NIST SP 800-92, the Guide to Computer Security Log Management, covers log management practices in more depth.

A minimum set for a web application: authentication results, authorization denials, privilege and role changes, password and token resets, rejected input, administrative actions and data exports. Each with a timestamp, an account or client identifier, a source address and an outcome.

The five problem types

Active attacks. Someone is probing or exploiting you now: credential stuffing, injection attempts, scanning for known vulnerable paths. Evidence is in request logs and edge or firewall logs. See authentication anomalies and attack payloads.

Suspicious access. A valid account or key behaves unlike its owner: new locations, new resources, bulk reads, role changes. Evidence is in application audit logs and cloud audit trails. See access anomalies, privilege changes and unusual data egress.

Exposure. A weakness exists but nobody has used it yet. See the exposure guide, new advisories, risky code and supply chain attacks.

Abuse and fraud. Real features used at scale for profit. See abuse and fraud and bots and scraping.

Agent misbehavior. AI agents acting outside their remit. See agent misbehavior and rogue AI agents.

A worked example: failed logins

Authentication events are the best first detection because the data is small and the signal is strong. Example log lines:

2026-11-08T03:12:44Z event=login result=failure user=ana@example.test ip=203.0.113.40 reason=bad_password
2026-11-08T03:12:45Z event=login result=failure user=ben@example.test ip=203.0.113.40 reason=bad_password
2026-11-08T03:12:45Z event=login result=failure user=cy@example.test ip=203.0.113.40 reason=unknown_user

One address failing against many accounts is a different attack from many addresses failing against one account. OWASP's cheat sheet makes the same distinction: watch for repeated failures for the same account and failures from multiple addresses. Query for both:

-- Example: one source, many accounts (spraying or stuffing)
SELECT ip, count(*) AS failures, count(DISTINCT user_id) AS accounts
FROM auth_events
WHERE result = 'failure' AND ts >= now() - interval '15 minutes'
GROUP BY ip
HAVING count(DISTINCT user_id) >= 10;

-- Example: one account, many sources (targeted guessing)
SELECT user_id, count(*) AS failures, count(DISTINCT ip) AS sources
FROM auth_events
WHERE result = 'failure' AND ts >= now() - interval '15 minutes'
GROUP BY user_id
HAVING count(DISTINCT ip) >= 5;

Follow either with a check for a success from the same source shortly afterward. A success after a run of failures is the finding that matters.

Thresholds and pitfalls

• Set thresholds from your own history. A service with a shared office network sees many accounts from one address on a normal Monday.
• Compare with the same hour in earlier weeks. Password resets after an outage or a forced rotation spike failures legitimately.
• Do not alert on every blocked request. Alert on a change in rate, a success after failures or a new action by a privileged identity.
• Attackers use many addresses, so counting by address alone misses distributed attempts. Count by account and by target route too.
• Keep logs long enough. Intrusions are sometimes found long after they start, and short retention removes the evidence.
• Protect the logs themselves. Anyone who can edit them can hide.

What to do when it fires

Contain first: block the source, force a reset for affected accounts, revoke sessions and keys. Then scope: search the same actor or key across all log sources for what it touched. Record the timeline while it is fresh.

Cloud audit sources add a second view. For AWS, see CloudTrail and WAF logs, and the general AWS integration. For edge traffic see Cloudflare. The exposure and abuse and fraud guides cover the neighboring problems.