Directed Logging, Monitoring and Response

Illustrative Findings Boundary

The severity-labelled scenarios below are newly authored fictional examples informed by the control domains assessed in this work. They do not reproduce or summarize any engagement finding, do not describe the reviewed environment, and do not indicate that any weakness was observed, confirmed, remediated or remains outstanding. Severity labels apply only to these examples and illustrate prioritization methodology.

Each example combines a plain-English business summary, a technical condition, potential impact, the evidence an assessment would seek, the expected control and a measurable way to check the fix.

DevOps includes dependable operation as well as delivery. Telemetry becomes an operational control only when a signal has a defined purpose, owner, response path and verification step.

Operational layer	Expected outcome
Structured application logging	Events contain consistent context without exposing sensitive information.
Azure activity and data-plane monitoring	Security-relevant changes and access patterns become observable.
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

Privileged Changes and Sensitive Access Produce No Actionable Signal

Critical See where this finding applies on the diagrams: operations zone · CP9 alert routing

Ease of Attack: Not an attack path; extends undetected compromise
Impact: Serious changes continue without response
Detection Difficulty: Requires testing alert delivery end to end
Pattern: Example detection-and-response pattern

Business Summary: Preventive controls cannot contain every failure. If privileged changes and sensitive access produce no actionable signal, a serious compromise can continue without a timely owner or response.
Possible Weakness: High-impact identity changes and sensitive data access occur without a signal that reaches an accountable responder.
Potential Impact: A serious compromise could continue undetected while privileges, configuration or protected information are changed.
What an Assessment Verifies: Trace diagnostic sources into Azure Monitor and Log Analytics, then alert rules, notification delivery, ownership and a safe test event through the complete response path.
Expected Fix: Enable dependable audit signals in Azure Monitor, route them to an owned on-call path and retain evidence that delivery and response are tested.
How to Check the Fix: A safe test event that simulates a privileged change must create the expected alert, reach the accountable owner within the target time and leave retained evidence of acknowledgement and response.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how a configured signal is traced through collection, delivery and response. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example Azure diagnostic and alert configuration record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example delivery result for a simulated test event
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```
Example application logging reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```

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

Ease of Attack: Not an attack path; weakens investigation
Impact: Access scope cannot be reconstructed
Detection Difficulty: Visible in diagnostic settings and retention review
Pattern: Example retention-and-query pattern

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.
Possible Weakness: Authentication, authorization and data-plane events remain scattered across short-lived service logs.
Potential Impact: Investigators may be unable to reconstruct access, distinguish normal behaviour from misuse or determine the affected scope.
What an Assessment Verifies: Map which application and data services produce security logs, centralized collection in Log Analytics, retention periods, query access and protection against unauthorized alteration.
Expected Fix: Centralize security-relevant telemetry in Log Analytics, protect access, retain it for the required period and maintain tested investigation queries.
How to Check the Fix: Test sign-in and data access events must appear in the central store with usable context, and retention, query access and protection against alteration must match the approved policy.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

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

Ease of Attack: Not an attack path; delays containment
Impact: Important alerts become unactioned noise
Detection Difficulty: Apparent from an inventory of alert owners
Pattern: Example ownership-and-escalation pattern

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.
Possible Weakness: Alert rules exist in configuration but lack a named owner, response runbook, escalation path or delivery test.
Potential Impact: Important signals can become noise, remain unread or reach people who cannot take timely action.
What an Assessment Verifies: Review Azure Monitor alert ownership, severity, notification targets, runbooks, escalation timing and the result of an end-to-end alert test.
Expected Fix: Give every actionable Azure Monitor alert an owner, response procedure, escalation route and retained evidence from regular delivery tests.
How to Check the Fix: A scheduled end-to-end test must be delivered, acknowledged and escalated within the approved response times, with retained evidence that the owner followed the current runbook.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Azure Review · Control Domain 5 of 5 · Public Edition

Part of the two-report public security-review portfolio.

Report overview