Canada Luggage Depot - Secure SDLC
Logging, Monitoring, and SIEM

14. Logging, Monitoring, and SIEM #

14.1 Objectives #

Applications must generate tamper‑resistant, SIEM‑ready security and audit telemetry that enables incident detection, investigation, and compliance verification. Logging must cover identity, authorization, administrative activity, data movement, and security control outcomes across all environments, with production as the primary focus.

14.2 Event coverage (minimum) #

Vendors must emit events for, at minimum:

  • Authentication and MFA outcomes (success/failure, reason).
  • Authorization decisions (allow/deny), including scope/role evaluated.
  • Permission/role changes and policy updates.
  • Account lifecycle events (create, enable/disable, delete; JIT provisioning).
  • Administrative and configuration changes (who/what before/after).
  • API calls (verb, route, caller, status, latency) and client/service principal identity.
  • File uploads/downloads/exports (name/type/size, AV scan result, disposition).
  • Security control blocks and detections (WAF/IDS/EDR/CSPM), rate‑limit triggers.
  • Key/secret operations (issue/rotate/revoke/use) where applicable.
  • Error conditions that may indicate attack or abuse (e.g., repeated 4xx/5xx patterns).

14.3 Log content and structure #

Each event must include fields sufficient for reliable correlation:

  • Who: user/identity or client/service principal (unique, human‑readable ID).
  • When: UTC timestamp with timezone.
  • Where: source IP/device/agent/user‑agent as applicable.
  • What: action verb and target/resource identifier (record ID, route, object).
  • Outcome: success/failure with reason/error code.
  • Correlation: request ID/trace ID/span ID for distributed tracing.
  • Privilege flag: indicator for privileged/admin operations.

Sensitive data (passwords, tokens, full PAN/passport numbers, raw secrets) must never be logged. Where partial identifiers are needed, mask or hash appropriately.

14.4 Time synchronization #

All systems generating logs must use synchronized time (e.g., NTP) and emit timestamps in UTC. Clock drift should be monitored and alerted upon.

14.5 Protection and retention #

Logs must be protected at rest and in transit and access‑controlled on a least‑privilege basis. Integrity safeguards (append‑only storage, write‑once/immutable options where feasible) are required for security logs. Retain security logs for at least PENDING: __ months; CLD baseline is 12 months and longer if required by contract or law.

14.6 SIEM operation and forwarding #

Per contract, vendors must operate a SIEM that ingests the events above, correlates detections, and produces periodic reports. CLD may also require forwarding of selected logs or alerts to CLD’s SIEM. If forwarding is required, specify:

  • PENDING: Forwarding requirement — Yes/No
  • PENDING: Ingestion method — Syslog/REST API/OpenTelemetry/Other
  • PENDING: Namespace/tenant and authentication method for ingestion
  • PENDING: Event mapping (field names) and normalization format

14.7 Alerting and routing #

Define actionable detections with severity and routing. At minimum, vendors must alert on:

  • Multiple failed logins and MFA failures across accounts (threshold‑based).
  • Impossible travel or anomalous location/device patterns.
  • Privilege escalation, role/policy changes outside approved windows.
  • WAF/IDS spikes, DDoS indicators, repeated 5xx on critical endpoints.
  • Malware/AV detections on file uploads or storage.
  • Large or unusual data exports/queries. Alerts must be routed to on‑call with acknowledgment/response targets of PENDING: Sev1 ack ≤ __ minutes; Sev2 ack ≤ __ minutes and documented update cadence during active incidents. CLD must be notified for events meeting the thresholds in Section 13.10 or the Incident Response Policy.

14.8 Access to logs and queries #

Vendors must provide CLD with timely access to log searches and extracts relevant to security investigations, either via:

  • A secure portal/API with role‑based access; or
  • On‑request exports delivered via a secure channel within agreed timelines. PENDING: Preferred access model and target turnaround times

14.9 Health, dashboards, and tests #

Provide basic operational dashboards (availability, error rates, latency, queue depth) and security dashboards (auth trends, WAF blocks, upload scan results, top alerts). Exercise alert paths at least quarterly (tabletop or live tests) and document results and fixes. PENDING: Dashboard list and quarterly test requirement confirmation

14.10 Storage location and data flows #

Log storage and processing must respect residency constraints. If logs contain or can reveal Restricted Data, they must remain in Canada unless an exception is approved per Section 9.2. Data flows for log forwarding must be documented in the design and updated upon change.

14.11 Exceptions #

Any deviation (e.g., temporary reduction in fields, delayed forwarding during migration) requires a documented exception stating scope, rationale, compensating controls (e.g., increased local retention, manual extracts), owner, approval (ISO and Executive Sponsor), and expiry.