Threat Tribunal

Logging, Alerts and Incident Response

Secure delivery also depends on dependable operation after release. Logs and alerts become real controls only when each signal has a defined purpose, owner, response path and test.

Operational layer Expected outcome
Visibility
Structured application logging Events contain consistent context without exposing personally identifiable information (PII), credentials or document content.
Azure activity and monitoring of access to stored data Security-relevant changes and access patterns become observable.
Response and proof
Actionable alerts Defined signals reach an owner through a tested response path.
Evidence retention Teams can show what happened, what decision followed and how the outcome was verified.

Fictional Security Examples

Illustrative Monitoring and Response Examples

Illustrative only - not an engagement finding

No Alert Reaches an Owner After PII Access or Privileged Changes

Critical See where this finding applies on the diagrams: operations zone · CP9 alert routing
Business summary
Preventive controls cannot contain every failure. If no useful alert follows a privileged change or access to PII or other protected data, a serious compromise can continue without reaching an owner in time.
Assessment profile
Ease of attack
Not an attack path; extends undetected compromiseHigh-impact identity changes and access to PII or other protected customer data occur without an alert that reaches an accountable responder.
Impact
Serious changes continue without response
  • A serious compromise could continue undetected.
  • Privileges, configuration or protected information could be changed without a timely response.
Detection difficulty
Requires testing alert delivery end to end
  • Trace security events into Azure Monitor and Log Analytics.
  • Follow alert rules, notification delivery and ownership.
  • Follow a safe test event through the complete response path.
Pattern
Example detection-and-response pattern
Expected fix Verification
  1. Expected fix Emit structured audit events for sign-in failures, permission denials, role changes, configuration changes and operations involving PII or other protected customer data
    Verification Safe test events must contain the approved actor, resource, action, result and correlation context
  2. Expected fix Send application, Container Apps and Azure resource events to the owned Log Analytics workspace
    Verification Safe test events for sign-in failure, permission denial, role change, configuration change and access to PII or other protected customer data must reach Log Analytics
  3. Expected fix Redact document and customer content before events leave the application
    Verification Planted document or customer content must not appear in the security events
  4. Expected fix Create Azure Monitor alert rules and action groups with a named owner, severity and escalation path
    Verification Each high-priority test event must trigger the expected alert and reach its accountable owner within the target time
  5. Expected fix Alert when expected security events or log delivery stop, not only when a known bad event occurs
    Verification Stopping expected log delivery must trigger a separate health alert
  6. Expected fix Retain evidence from regular end-to-end delivery and response tests
    Verification The test must retain evidence of delivery, acknowledgement and response

Related illustrative findings: centralized security logs; alert ownership.

Illustrative only - not an engagement finding

Security Logs Are Not Centralized or Retained for Investigation

High See where this finding applies on the diagrams: operations zone · CP8 telemetry separation
Business summary
Logs become useful only when investigators can find, trust and retain them. Short-lived service logs can disappear before a team knows that an investigation is required.
Assessment profile
Ease of attack
Not an attack path; weakens investigationSign-in, permission and data-access events remain scattered across short-lived service logs.
Impact
Access scope cannot be reconstructed
  • Investigators may be unable to reconstruct access.
  • They may be unable to distinguish normal behaviour from misuse.
  • They may be unable to determine the affected scope.
Detection difficulty
Visible in diagnostic settings and retention review
  • Map which application and data services produce security logs.
  • Check whether Log Analytics collects the logs centrally and how long they are kept.
  • Check who can search or change the logs.
Pattern
Example retention-and-query pattern
Expected fix Verification
  1. Expected fix Centralize structured security events in Log Analytics with actor, resource, action, result and correlation identifiers
    Verification Test sign-in, permission and data-access events must appear centrally with usable actor, resource, result and correlation context
  2. Expected fix Minimize and redact PII, document content and model content before logging
    Verification Planted PII, document content and model content must not appear in ordinary security logs
  3. Expected fix Give query and configuration access only to the roles that need it
    Verification Unauthorized identities must be unable to query, reconfigure or delete retained evidence
  4. Expected fix Protect retained evidence from unauthorized alteration or early deletion
    Verification Retention and protection against early deletion or alteration must match the approved policy
  5. Expected fix Apply the approved retention period and maintain tested investigation queries
    Verification The tested investigation queries must reconstruct the expected test sequence

Related illustrative findings: security-event delivery and alerting; PII minimization before persistence or output.

Illustrative only - not an engagement finding

Alerts Exist Without an Owner or Tested Response Path

Medium See where this finding applies on the diagrams: operations zone · CP9 alert routing
Business summary
An alert that nobody owns is not an operational control. It becomes noise until a tested process shows who receives it, what they do and when the issue escalates.
Assessment profile
Ease of attack
Not an attack path; delays containmentAlert rules exist in configuration but lack a named owner, response procedure, escalation path or delivery test.
Impact
Important alerts become unactioned noise
  • Important signals can become noise or remain unread.
  • Signals can reach people who cannot take timely action.
Detection difficulty
Apparent from an inventory of alert owners
  • Review Azure Monitor alert ownership and severity.
  • Review notification targets, response procedures and escalation timing.
  • Review the result of an end-to-end alert test.
Pattern
Example ownership-and-escalation pattern
Expected fix Verification
  1. Expected fix Give every actionable Azure Monitor alert a named owner, severity and response procedure
    Verification A scheduled end-to-end test must be delivered, acknowledged and escalated within the approved response times
  2. Expected fix Route notifications through an approved action group with an escalation path and a secondary delivery method
    Verification The secondary delivery method must work when the primary notification path is unavailable
  3. Expected fix Use managed identity or secure authentication for automated alert actions
    Verification Automated actions must authenticate without a reusable secret and succeed only with their approved permissions
  4. Expected fix Manage alert rules, action groups and planned suppression through reviewed configuration
    Verification An unreviewed alert-rule or action-group change must fail the configuration gate
  5. Expected fix Test delivery, acknowledgement and escalation regularly, and retain the result
    Verification Planned suppression must expire as configured, and retained evidence must show that the owner followed the current procedure

Related illustrative findings: actionable detection; retained investigation evidence.