Skip to main content

Practical Cases of Monitoring and Detection

This annex presents practical examples of the application of the monitoring, logging, alert and correlation recommendations. The scenarios described here help to understand how to apply the prescriptions of this chapter to concrete cases.

🚀 Case 1 - API Gateway with structured logging and alerts​

🛡️ Risk classification: L3 - Application with public exposure and critical operations

Context: Application exposed through an API Gateway, token-based authentication, with critical endpoints (checkout, transfers).

Controls applied:

  • JSON logging with ECS via customised NGINX
  • Fields included: user.id, request.path, status, latency, geo.country
  • Alerts:
    • Consecutive 5xx responses from one IP within a 5-minute interval
    • Access to /checkout outside the 06:00–22:00 window
  • Logs sent to the Elastic Stack via Filebeat
  • Dashboards with metrics per endpoint, errors, geo, by profile

Result: Reduction of MTTD for login anomalies and abuse by automated scripts.

💰 Case 2 - Monitoring of uploads in a document management application​

🛡️ Risk classification: L3 - Application with sensitive data and risk of exfiltration

Context: Internal platform for the management of sensitive documents with a review workflow.

Controls applied:

  • Logging of upload, download, delete events, with user ID and checksum
  • Event table replicated to the SIEM (QRadar) via structured syslog
  • Active correlation: upload of >100MB + unusual IP + user role "editor"
  • Generates a "potential internal exfiltration" alert
  • Playbook triggers an investigation with log tagging and temporary isolation

Result: Detection of unauthorised movement in the context of team turnover.

👨‍💼 Case 3 - Monitoring of CI/CD pipelines and detection of unusual execution​

🛡️ Risk classification: L2 - Internal pipeline with supply chain impact

Context: Pipelines with automatic execution via GitHub Actions + Kubernetes. The team wants to track changes in behaviour.

Controls applied:

  • Structured logging of jobs, with the pipeline.start, pipeline.command, pipeline.result events
  • Logs sent to Loki + Grafana Tempo with trace.id
  • Alerts:
    • Execution of shell commands outside the usual ones (curl, rm, base64)
    • Job that lasts >2x the historical average time
    • Pipeline executed from a "legacy/" branch + unusual user
  • Correlation with the image used in the job (e.g. ubuntu:latest outside the baseline)

Result: A corrupted build incident was detected and blocked before it reached the release.

🔎 Case 4 - Correlation of authentication logs with session movements​

🛡️ Risk classification: L3 - Multi-user application with sensitive profiles and risk of hijacking

Context: Application with internal and external users, with long sessions. Misuse was reported.

Controls applied:

  • Session identified by session.id + trace.id
  • Login, token refresh, logout and API call logs aggregated per session
  • Correlation:
    • Login via an old token with a different IP/UA origin
    • Token refresh triggered without normal use of the session
  • Triggers a "ghost / hijacked session" alert
  • Cross-validation with load balancer and WAF logs

Result: Session blocking and revocation in real time. Reinforced timeout and earlier alerting.

🧪 Case 5 - Low-criticality internal application with local logging and manual validation​

🛡️ Risk classification: L1 - Technical support application, limited use

Context: Internal application used only by the technical support team, with no external access and no sensitive data.

Controls applied:

  • Local logging to a rotating file in a structured format (JSON)
  • Events recorded: login, erro, config.change
  • Retention of 30 days on local disk with weekly backups
  • Manual validation of the logging operation in release reviews
  • No SIEM, no automatic correlation and no real-time alerts

Result: Fulfilment of the minimum requirements of level L1, with basic visibility and sufficient traceability for internal audits.

✅ Example of application proportional to the risk, without over-engineering.

📊 Summary Table of the Cases​

CaseRiskMain ContextKey controls applied
1L3API Gateway with critical endpointsECS logging, out-of-hours alerts, Elastic Stack
2L3Document management with risk of leakageSyslog, correlation, isolation, SOAR
3L2CI/CD with anomalous executionPipeline logs, correlation by command and branch
4L3Multi-user with session hijackingtrace.id, login/token/session correlation
5L1Internal support applicationLocal logging, no SIEM, manual review

These practical cases demonstrate how the integrated application of the logging, alert and correlation controls makes it possible to detect behaviours that would be invisible in isolation.

✅ For high-risk applications (L3), it is recommended to keep a validated repository of real and simulated examples, with validation of trigger and response.