# Security monitoring: connect important events to an owner who can act

Canonical: https://www.web3sec.news/blog/security-monitoring-runbook
Author: Raiders (https://www.web3sec.news/about)
Format: guide
Topic: Monitoring
Published: 2026-11-08
Updated: 2026-11-08

Build a small, testable detection system around identity changes, deployments, data access and treasury authority.

## Start with the decisions the business must notice

Assign a monitoring owner and choose a short list of events whose consequences justify interruption: new privileged identity, changed recovery method, unexpected deployment, disabled audit logging, unusual export or changed treasury authority. For each event, name the source system, available fields, expected delay, responder and possible containment action. A dashboard is not an operating control if nobody is responsible for the event it displays.

Use a coverage map rather than a product inventory. Identify which high-impact actions have no retained audit event and which logs cannot distinguish actors or tenants. AWS CloudTrail documents different recording mechanisms and event categories; confirm the configuration needed for the specific activity you intend to investigate. Do not assume that an enabled cloud logging service captures every object read or application-level decision.

## Collect enough context without collecting secrets

OWASP’s logging guidance distinguishes security event selection, useful context and information that should be excluded. Design events with time, actor, action, resource, outcome and a correlation identifier. Keep credentials, bearer tokens and unnecessary sensitive bodies out of ordinary logs. Sanitize untrusted text so a crafted value cannot forge a convincing event or break downstream parsing.

Store important logs under a boundary that an ordinary application identity cannot alter or delete. Define retention from the investigation needs, detection delays and applicable constraints. Restrict query access because metadata can itself reveal customer or internal information. Monitor collection failures, unusual volume and missing heartbeat events; a silent pipeline failure can make every detection rule appear reassuringly quiet.

## Write alerts as actionable incident leads

An alert should explain the observed event, why it matters, which identity or resource is involved and where the responder can verify it. Include the approved containment path and an alternate contact. Add enough context to distinguish a planned change from suspicious activity, but do not suppress every action by an administrator simply because that role is expected to perform sensitive work.

Tune with the service owner using actual legitimate patterns and controlled exercises. Track false positives, missed tests, acknowledgment time and unresolved alerts. Avoid automatically taking destructive action on weak signals. For high-confidence events, agree on reversible containment in advance and document the business consequences so the responder does not improvise during an outage.

## Prove collection, routing and response end to end

Generate a harmless test event using a designated identity: a temporary role grant, denied API operation or synthetic export. Verify the raw event, parsed fields, detection result, notification and human acknowledgment. Then test the documented containment in a non-production environment. Record where the pipeline fails rather than declaring success because one notification arrived.

Repeat after provider migrations, schema changes, staffing changes and alert-routing updates. Keep a way to contact responders outside the potentially affected identity or chat platform. Review stale alerts and exceptions with expiration dates. Completion evidence is a detected test event with a traceable responder action and a clear account of what remains outside monitoring coverage.

## Controls to take away

- Monitoring coverage follows recorded actions, not installed products.
- A quiet alert channel may indicate a failed pipeline.
- Useful alerts connect evidence to an authorized decision.

## Working checklist

Assign owners and record supporting evidence in your team's system.

- [ ] Map high-impact actions to specific audit sources.
- [ ] Record collection delay, retention and known gaps.
- [ ] Exclude secrets and protect log integrity.
- [ ] Give alerts a responder and containment procedure.
- [ ] Test raw event through acknowledged response end to end.

## Sources & further reading

- [OWASP: logging cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [AWS: CloudTrail recording and event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)

Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis.

[Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)