Pages on Brewed in the Cloud by Chris Hailes

Azure Reachability Assurance: Reader Toolkit

Tue, 27 Oct 2026 00:00:00 +1100

Can you show what an assumed-compromised workload can do, remove an unwanted operation, and verify that required service still works?

I built and tested this lab to provide examples you can recreate and adapt. It accompanies Azure Reachability Assurance Lab, planned for February 16-March 4, 2027, and is available independently so you can inspect the code first.

Download and start offline

Download toolkit 0.1.1-preview and its SHA-256 checksum.

Extract the ZIP and read README.md. Python 3.10+ and its standard library are enough for the offline exercise; no Azure account or dependencies are needed. The deliberately incorrect fictional comparison should fail validation. Explain why, inspect the corrected example, then use the worksheet to define required and prohibited operations for your own environment.

The package includes Bicep, a guarded runner, fixed-target probe, evidence validator, query, runbook, approval checklist, worksheet, tests and sanitized lab findings. Filled approvals, raw operational logs and keys are excluded.

Inspect the artifacts

What the lab established

The isolated experiment compared required, spare-container and separate-canary marker reads. Identity-only controls denied the spare and canary reads. Network-only controls left the spare read working but the canary timed out. Combined controls preserved required access. Narrow recovery restored only the required grant while the unwanted operations remained unavailable.

An initial required read still succeeded shortly after role removal; one recorded readiness retry later observed denial. That is not immediate revocation or a measured revocation SLA. The first deployment also exposed a Run Command response-format bug, corrected before a fresh source-bound run. Both groups were deleted, with final absence confirmed.

These are finite observations, not tenant-wide containment proof. A timeout alone does not establish cause. The lab permits broad AzureCloud HTTPS management egress through NAT; it is not zero-egress. DNS faults, existing sessions and hostile control-plane administrators were not tested.

Preview status and safe adaptation

This is an author-approved limited preview, not an independently reproduced assurance pack. Independent reader replay and settled-cost review are still outstanding. Billing initially had no rows and later throttled; no zero-cost claim is made. Local extracted-package tests do not substitute for another operator’s replay.

Use only a disposable environment you own or are explicitly authorized to operate. Obtain current region/SKU, quota, policy, permissions and pricing checks, a numeric spend cap, and a cleanup owner before any cloud action. Read the approval checklist; the example approval is not permission to deploy.

Adapt the evidence model to your business operations first on paper. Do not repoint the runner to production or arbitrary hosts. A tested sample is a starting point for your own review, not a production remediation script or certification.

Operate Through Compromise: Reader Toolkit

Tue, 27 Oct 2026 00:00:00 +1100

Can your evidence distinguish a blocked operation from an unexplained timeout, while keeping a healthy peer available?

This toolkit accompanies Operate Through Compromise, a six-article series planned for January 26-February 11, 2027. It is available independently so you can inspect the code and safety constraints before using it.

Download and start offline

Download toolkit 1.0.0 and its SHA-256 checksum.

Extract the ZIP, read README.md, and begin with the Node.js 22+ offline exercise. It needs no Azure account or dependencies. The archive includes the guide, tests, Bicep templates, PowerShell runner, token-free Python probe, incident runbook and tabletop pack.

The sample is explicitly illustrative. The validator rejects malformed or non-comparable evidence and preserves INCONCLUSIVE when a worker receives no service response. A structurally valid record is not an authenticated approval or an isolation certificate.

Inspect individual artifacts

These are downloadable Markdown documents; the same files are included in the ZIP:

What was observed, and what was not

An authorized disposable Australia East lab and a corrected-workflow replay were exercised on October 27, 2026 (Sydney). Both workers initially returned HTTP 200. During the worker-scoped restriction, the worker received no response within approximately 15 seconds while its healthy peer returned HTTP 200. Both returned HTTP 200 after restoration. Both lab groups were deleted and their resource inventories confirmed empty.

The timeout is compatible with containment, not proof of its cause or universal isolation. The experiment did not establish token revocation, identity rebuilding, existing-session termination, automatic drift detection, production DNS/route recovery or workshop performance.

Before any cloud execution

Use only a disposable environment you own or are explicitly authorized to operate. Read every approval, permission, cost, rollback and cleanup requirement in the guide. The optional lab incurs Azure charges and requires current region/SKU, quota, policy and permission checks. An illustrative approval record is not permission to deploy.

The code was exercised against the versions and configuration in the report, not every subscription. Recheck current authoritative documentation before use. Do not copy production credentials or confidential incident evidence into the sample, commit them to Git, or publish them with the worksheets.

About

Wed, 01 Jul 2026 00:00:00 +0000

Who is Chris Hailes?

I’m a cloud architect, consultant, writer, and Microsoft MVP who spends most of his time helping organisations design, secure, and modernise Azure environments. Brewed in the Cloud is where I share the practical lessons that come from real-world delivery work: the patterns that scale, the trade-offs that matter, and the mistakes worth avoiding.

The Technologist

My background spans infrastructure, networking, security, architecture, and platform design, with more than two decades working across enterprise technology. While Azure is the main focus here, I care less about hype and more about building environments that are secure, resilient, observable, and actually workable for the teams who run them day to day.

The Writer, Teacher & Advocate

I learn best by breaking things down and explaining them clearly, which is exactly why this site exists. I write for architects, engineers, consultants, and technical leaders who want practical guidance rather than marketing gloss. That means content grounded in implementation details, operational reality, and the broader why behind good technical decisions.

The Professional

My work usually sits at the intersection of cloud strategy and hands-on delivery: landing zones, networking, security controls, governance, monitoring, identity, and operating model decisions that shape how platforms behave over time. If a design looks great on a diagram but falls apart in production, that’s the kind of gap I’m interested in closing.

What you’ll find here

Azure architecture, networking, identity, and security content with a strong practical bias.
Lessons from consulting, delivery, and platform operations translated into clear, usable guidance.
Occasional reflections on community, career growth, tooling, and the process of learning in public.

Connect

If you’d like to learn more, connect, or dive deeper into my background, these links are a good place to start:

Privacy Policy

Sun, 31 Aug 2025 00:00:00 +0000

Introduction

Welcome to Brewed in the Cloud (“we,” “our,” or “us”). We are committed to protecting your privacy and personal data. This Privacy Policy explains how we collect, use, and protect your information when you visit our blog at blog.brewedinthecloud.com.

This policy complies with the EU General Data Protection Regulation (GDPR) and other applicable data protection laws.

Information We Collect

1. Analytics Data

We use Microsoft Clarity and Google Analytics to understand how visitors interact with our website.

Microsoft Clarity (cookieless by default): Clarity runs on every page in its no-consent mode until you approve cookies. In this mode Clarity sets no cookies, assigns a new random identifier to each page view, and cannot link your visits together. We use it to count page views and understand how pages are used (for example, scrolling and clicks). Clarity masks sensitive text by default. If you approve cookies, Clarity may also set cookies so that multiple page views in one visit are recognised as a single session.

Google Analytics (only with your consent): Google Analytics loads only after you approve cookies. It may collect:

IP address (anonymized)
Browser type and version
Operating system
Pages visited and time spent
Referring website
General geographic location (country/city level)
Device information (screen resolution, device type)

Legal Basis: Legitimate interest for cookieless Microsoft Clarity measurement; your consent for Google Analytics and for Clarity cookies.

2. Cookies and Similar Technologies

We use cookies to enhance your browsing experience. You can manage your cookie preferences through our cookie consent banner.

Essential Cookies:

Cookie consent preferences
Basic functionality cookies

Analytics Cookies (requires consent):

Google Analytics cookies (_ga, _ga_*, _gid)
Microsoft Clarity cookies (_clck, _clsk, CLID, MUID)

If you deny or don’t respond to the cookie banner, no analytics cookies are set. Microsoft Clarity still records page views in cookieless mode, as described above.

3. Embedded Content

Our website may include embedded content from third-party services:

YouTube Videos: We use YouTube’s privacy-enhanced mode (youtube-nocookie.com) when available, which reduces data collection until you interact with the video.

GitHub Gists: Code examples may be embedded from GitHub, which may set cookies according to GitHub’s privacy policy.

4. Server Logs

Our hosting provider may collect standard server log information including:

IP addresses
Request timestamps
HTTP status codes
Referrer information

This data is used for security, performance monitoring, and technical troubleshooting.

How We Use Your Information

We use collected information for:

Website Analytics: Understanding visitor behavior to improve content and user experience
Performance Monitoring: Ensuring optimal website performance and uptime
Security: Protecting against malicious activity and maintaining site security
Content Optimization: Creating relevant and useful content based on popular topics

We share data with the following third-party services:

Microsoft Clarity

Purpose: Page view measurement and usage insights (cookieless unless you approve cookies)
Data Shared: Pages viewed, interactions such as clicks and scrolling, device and browser type, approximate location derived from your IP address
Privacy Policy: Microsoft Privacy Statement
Data Location: May be processed in Microsoft data centres globally
Retention: Clarity’s standard retention (aggregated metrics for up to 13 months, recordings for 30 days unless favourited)

Google Analytics

Purpose: Website analytics and performance measurement
Data Shared: Anonymized usage data, IP addresses (anonymized)
Privacy Policy: Google Privacy Policy
Data Location: May be processed in the United States
Retention: 26 months (Google Analytics default)

Hosting Provider

Purpose: Website hosting and content delivery
Data Shared: Technical logs and visitor data necessary for site operation
Provider: Microsoft Azure (Azure Static Web Apps)
Data Location: May be processed in Microsoft Azure data centers globally
Privacy Policy: Microsoft Privacy Statement
Data Protection: Microsoft Azure complies with GDPR and other international data protection frameworks

If you are located in the European Economic Area (EEA), you have the following rights:

Right of Access

You can request information about the personal data we hold about you.

Right to Rectification

You can request correction of inaccurate personal data.

Right to Erasure (“Right to be Forgotten”)

You can request deletion of your personal data in certain circumstances.

Right to Restrict Processing

You can request limitation of how we process your personal data.

Right to Data Portability

You can request a copy of your personal data in a structured, machine-readable format.

Right to Object

You can object to processing of your personal data for direct marketing or legitimate interests.

Where processing is based on consent, you can withdraw it at any time through our cookie settings.

You can control cookies through:

Our Cookie Banner: Accept or deny non-essential cookies when you first visit. To change your choice, delete the cookie-notice-option cookie (or clear this site’s data) and the banner will reappear
Browser Settings: Configure your browser to block or delete cookies, or block clarity.ms to opt out of cookieless measurement
Opt-out Tools: Use Google Analytics opt-out browser add-on

Data Retention

Analytics Data: Retained for 26 months through Google Analytics; up to 13 months through Microsoft Clarity
Cookie Preferences: Stored for 31 days
Server Logs: Typically retained for 30-90 days for security purposes

International Data Transfers

Some of our service providers (particularly Google Analytics) may transfer and process data outside the EEA. We ensure appropriate safeguards are in place:

Google Analytics: Covered by Google’s compliance with data protection regulations and appropriate transfer mechanisms
Microsoft Clarity: Covered by Microsoft’s data protection commitments and appropriate transfer mechanisms

Security Measures

We implement appropriate technical and organizational measures to protect personal data:

HTTPS encryption for data transmission
Regular security monitoring
Access controls for any collected data
Secure hosting infrastructure

Azure Exposure Reduction Toolkit

Mon, 01 Jan 0001 00:00:00 +0000

This companion supports the six-part Engineering Exposure Reduction series. Its purpose is to make a bounded engineering decision reproducible: name the path, choose the boundary, test the operation, preserve necessary dependencies and compare the evidence.

It is a practitioner toolkit, not a Microsoft standard, a complete attack graph or a production auto-remediation framework. Version 1 supplies six review templates, inspection queries and locally tested evidence-comparison tooling. Azure procedures are proposed checks, not observed tenant outcomes. No Azure deployment or live enforcement result is claimed; this version does not include Bicep deployment modules.

Download and local quick start

Download the v1 toolkit ZIP and its SHA-256 checksum.

The bundle contains everything needed to run the local example:

File	Purpose
`README.md`	Runtime, instructions, expected results and limitations
`Workbook.md`	Six reusable templates, assumption ledger and sign-off checks
`Compare-ExposureEvidence.ps1`	Read-only validation and comparison of sanitized JSON
`Test-ExposureEvidence.ps1`	Fixture assertions and 11 mutation cases
`fixtures\before.json`, `fixtures\after.json`	Synthetic baseline/after inputs, not observations
`queries\PrivateEndpointInventory.kql`	Resource Graph inventory of automatic connections
`queries\FirewallNetworkEvidence.kql`	Log Analytics network-rule context

Windows PowerShell 5.1 is the validated local runtime. No Azure credentials or external PowerShell modules are needed for the comparator or self-test. Review the downloaded scripts, extract the ZIP, then open PowerShell in the extracted directory:

1
2
3
4
5
6
7


powershell -NoProfile -File .\Test-ExposureEvidence.ps1
if ($LASTEXITCODE -ne 0) { throw "Toolkit self-test failed." }

powershell -NoProfile -File .\Compare-ExposureEvidence.ps1 `
 -BeforePath .\fixtures\before.json `
 -AfterPath .\fixtures\after.json
if ($LASTEXITCODE -ne 0) { throw "Evidence comparison failed." }

The test prints PASS: fixture comparison and 11 mutation cases; no Azure calls made. It creates uniquely named temporary JSON files and cleans them up. The comparator reads its inputs and prints JSON without changing the files. If execution policy blocks a script, follow your organization’s approved process rather than disabling machine policy.

To check the ZIP, run Get-FileHash -LiteralPath .\azure-exposure-reduction-toolkit-v1.zip -Algorithm SHA256 and compare the hash with the downloaded checksum. This detects different bytes; it is not a signature or proof of publisher authenticity.

Series and modules

Series article	Toolkit module
From Finding to Path: Model Azure Exposure as Reachability	Path record and inventory context
WAF, Firewall, DDoS or Network Security Perimeter? Choose by Threat Boundary	Threat-to-control decision matrix
Constrain Shared Network Paths with Azure Firewall and AVNM Security Admin Rules	Enforcement and scope test matrix
Private Access with Explicit Egress and Exfiltration Guardrails	Destination/operation and residual-risk worksheet
Make Remediation Repeatable with Policy, IaC and Expiring Exceptions	Change and exception workflow
Measure Exposure Reduction, Not Just Control Deployment	Evidence-pack contract and local comparison

The series is scheduled for November 3, 5, 10, 12, 17 and 19, 2026. Article links become available as each article is published. The downloaded workbook and local comparison can be used independently of those pages.

Prerequisites and safety boundary

Use only a disposable, author-owned Azure scope with synthetic data and explicit deployment/test authorization. Separate read-only inventory permissions, configuration write permissions and service data permissions. The illustrative service is Blob on supported general-purpose v2 Storage; do not assume equivalent behavior for DFS, Files or another PaaS service.

Record the selected Azure cloud/region, SKU, API/resource versions, CLI/module versions, diagnostic table schema and test principal. Confirm current documentation and resource support before execution. Set a cost/time cap before enabling Firewall, AVNM or billable diagnostics.

Nothing here deploys Azure resources automatically. Do not use an existing tenant merely because a command accepts its identifiers. Never collect tokens, keys or sensitive object contents in evidence exports.

1. Path record and read-only inventory

Use a stable record for each source/principal/destination/operation relationship:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "pathId": "lab-app-to-controlled-blob-write",
 "source": "<declared-source-workload>",
 "principal": "<declared-test-principal-id>",
 "destination": "<controlled-destination-resource-id>",
 "operation": "synthetic-blob-write",
 "intent": "prohibited",
 "dnsContext": "<resolver-and-zone-links>",
 "routeContext": "<effective-route-evidence-reference>",
 "authorityContext": "<scoped-data-role-evidence-reference>",
 "reopeningAuthority": "<control-plane-owner-and-scope>",
 "expectedAfter": "blocked",
 "positiveControls": ["approved-blob-read", "telemetry", "responder-access"],
 "retestTriggers": ["role-change", "route-change", "dns-change", "service-change"]
}

This is a practitioner record, not an Azure resource payload. The finding’s provenance and observation time should accompany it.

Run the bundle’s inventory query in Azure Resource Graph, not Log Analytics:

1
2
3
4
5
6
7
8


resources
| where type =~ "microsoft.network/privateendpoints"
| mv-expand connection = properties.privateLinkServiceConnections
| project endpointId = id,
 subnetId = tostring(properties.subnet.id),
 targetId = tostring(connection.properties.privateLinkServiceId),
 groupIds = connection.properties.groupIds,
 location

It discovers declared automatic Private Endpoint connections, not usable operations. Manually requested connections use a different property and need separate inspection. Empty output can reflect missing read scope, inventory delay or no matching resources; it does not prove no path exists. For a supported VM NIC, this read-only Azure CLI inspection collects routing context:

1
2
3
4
5


az network nic show-effective-route-table `
 --resource-group "<lab-resource-group>" `
 --name "<lab-source-nic>" `
 --output json
if ($LASTEXITCODE -ne 0) { throw "Route inspection failed." }

Record the selected destination and route, not just the existence of an exported table. Read failures or missing scope make the context unknown.

2. Threat-to-control matrix

Path failure	Candidate	Required boundary evidence	Counterexample
Unwanted application request	WAF on selected supported host	Effective policy/mode and harmless rule-match result	Direct-origin access or an authorized harmful operation remains possible
Unwanted traversing connection	Azure Firewall	Selected route, effective parent/child policy and rule result	An alternate route never reaches the appliance
Unwanted supported PaaS public access	NSP	Supported association, mode and service-specific access result	Private Endpoint traffic is not blocked by explicit NSP rules
Network-layer availability pressure	Eligible DDoS offering	Actual coverage configuration and support review	Application-layer overload or dependency failure remains

Use a harmless test marker against an author-owned application. Do not provide exploit payloads or generate DDoS traffic. Coverage review is not a mitigation experiment.

3. Shared-path enforcement matrix

Case	Expected documented relationship	Required observation
AVNM Allow plus NSG deny	NSG may reject	Fresh connection, supported target and effective configuration
AVNM Deny plus NSG allow	Admin deny blocks	Same case with corroborating enforcement evidence
AVNM AlwaysAllow plus NSG deny	Further NSG evaluation bypassed	Narrow approved case; record the loss of workload-level restriction
Firewall application restriction plus broad network allow	Earlier matching network rule can terminate evaluation	Policy hierarchy, rule types and actual flow
Out-of-scope source/target	Claimed central boundary may not apply	Separate result; never fold into an in-scope pass

Current AVNM documentation excludes Private Endpoints from security admin-rule application and describes eventual consistency. Check the full current exclusion list for the chosen topology.

This module is a bounded test matrix, not a deployable Firewall/AVNM configuration. If you implement it, select supported API versions and a disposable canary scope, compile your IaC, inspect the deployment diff, and document permissions, convergence, rollback and cleanup. Do not reuse historical AVNM examples or assume a simulation mode.

4. Controlled egress and residual risk

From the actual source context, resolve the normal service name and inspect TCP connectivity:

1
2
3
4
5
6
7


$name = "<lab-storage-account>.blob.core.windows.net"
Resolve-DnsName -Name $name -ErrorAction Stop
$connection = Test-NetConnection -ComputerName $name -Port 443 `
 -InformationLevel Detailed
if (-not $connection.TcpTestSucceeded) {
 throw "TCP probe failed; investigate before interpreting service access."
}

This deliberately stops on a failed diagnostic probe; it is not the prohibited-operation acceptance test. A blocked data operation needs its own service result and control attribution.

For each destination record source resolver, returned address, principal, subresource, operation, expected/actual result, error/request reference, control evidence and residual. Test approved reads, controlled unintended writes, separately declared public access, telemetry continuity and responder access.

Keep service-side onward movement separate from workload egress. Identify the owner and review export, replication or downstream consumers rather than claiming the first-hop restriction covers them.

5. Change and exception workflow

Use this sequence: reviewed path claim -> versioned diff -> scoped preflight -> approved canary -> operation/positive-control tests -> expansion or stop -> residual/rollback record.

The exception record needs owner, approver, resource/assignment scope, waiver or mitigated rationale, expiry, compensating test, renewal conditions and an expiry action. Azure Policy’s expiresOn ends honoring the exemption; Microsoft documents that the object remains. Do not assume expiry immediately changes existing deployed state.

Validate actual policy effects, aliases, remediation identity roles and applicability. Add an incident override that prevents routine automation restoring unsafe reachability while responders contain a workload. Test the override’s expiry and reconciliation process too.

6. Evidence comparison

The local PowerShell helper compares sanitized exports only. It does not query Azure, deploy controls or calculate a security score.

Each input contains scopeVersion, configurationVersion, observedAtUtc, and cases. Each case contains pathId, source, principal, destination, operation, intent (prohibited or required), status (reachable, blocked or unknown) and evidenceRefs.

Comparisons reject mismatched scope, changed case identities, duplicate/missing cases, invalid states, non-UTC observation times and absent evidence references. A scope change needs a new comparison contract, not a silently smaller denominator. For unknown cases, an evidence reference can identify the failed collection or test record; it must not invent the missing observation.

Use the quick-start commands above with the bundled fixtures. Their dates are invented ordering inputs, not observations. Expected results deliberately include both an improved candidate and a newly reachable path:

Report field	Fixture result
`assuranceStatus`	`not-assessed`
`candidateRemoved`	`unwanted-write`
`newlyReachable` and `remainingReachableProhibited`	`alternate-write`
`inconclusive`	`unknown-export`
`baselineRequiredNotReachable` and `requiredNotReachable`	empty arrays

The report lists candidate removed prohibited paths, remaining reachable paths, newly reachable prohibited paths, unknowns and failed required cases. A candidate-removed classification is a bookkeeping result, not proof of attributable enforcement or durable containment. Verify raw evidence, recovery checks and reopening authority before drawing that conclusion.

For your own evidence, copy the fixtures to new files, preserve stable case identities and replace synthetic values with authorized, sanitized observations. Use actual configuration versions and UTC timestamps. Evidence references must identify real records, including collection failures for unknown cases. The comparator does not open or authenticate those referenced records.

The bundle’s Firewall query runs in an authorized Log Analytics workspace with resource-specific network-rule logging and AZFWNetworkRule available. Replace the illustrative window and addresses:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


let windowStart = datetime(2026-11-10T00:00:00Z);
let windowEnd = datetime(2026-11-10T00:05:00Z);
let sourceIp = "10.20.1.4";
let destinationIp = "10.30.1.4";
AZFWNetworkRule
| where TimeGenerated between (windowStart .. windowEnd)
| where SourceIp == sourceIp and DestinationIp == destinationIp
| project TimeGenerated, _ResourceId, Protocol, SourceIp, SourcePort,
 DestinationIp, DestinationPort, Action, ActionReason,
 Policy, RuleCollectionGroup, RuleCollection, Rule
| order by TimeGenerated asc

These fields do not supply a deterministic principal-to-Blob-operation join. Time/tuple correlation can be ambiguous with translation or concurrent traffic. Missing rows remain inconclusive until collection, transit and window assumptions are checked.

Validation, acceptance and maintenance

Version 1’s fixture assertions and 11 mutation cases have been run locally on Windows PowerShell 5.1. They cover unchanged and unknown results, required-path failure, scope/case mismatches, duplicate IDs, changed principals, invalid status, missing evidence and timestamp constraints. This validates local comparison behavior, not Azure enforcement. The workbook and queries are documentary/procedural examples; they have not been executed against a live Azure scope.

Before executing an Azure procedure, complete the workbook’s assumption ledger: cloud/region, SKU/service support, selected API versions, client versions, scope/roles, DNS/routes, actual diagnostic schema and collection timing. Record the documentation basis separately from dated lab observations.

Accept a change only when the intended boundary is supported by evidence, required paths still work and residuals have accountable ownership. Newly reachable prohibited paths, failed recovery and unresolved observations need explicit disposition; one removed candidate is not an overall pass.

Retest after API, schema, support, topology or role changes. Run the local self-test after editing the comparator or fixtures. General telemetry collection guidance remains in the Azure Security Telemetry Toolkit; this companion focuses on deciding and validating a bounded exposure change.

References

Azure Security Telemetry Toolkit

Mon, 01 Jan 0001 00:00:00 +0000

This toolkit supports the six-part Azure Security Telemetry series. It is deliberately practical: use it to start a review, validate assumptions, and adapt the patterns to your own subscriptions, workspaces, Sentinel deployment, Defender XDR portal, and Defender for Cloud configuration.

It is not a Microsoft standard. The scorecard included here is Chris Hailes’s practitioner framework for measuring whether Azure security telemetry is useful during real investigations, not merely collected.

Series articles

Prerequisites and boundaries

Azure Activity Log routed to a Log Analytics workspace where the AzureActivity table is available.
Resource diagnostic settings deployed to the services that matter for your investigation scenarios.
Microsoft Sentinel enabled where ASIM parsers and normalized hunting content are used.
Microsoft Defender XDR advanced hunting access in the Defender portal for identity, endpoint, cloud app, and alert-evidence queries.
Defender for Cloud enabled with continuous export configured to Log Analytics where SecurityAlert and SecurityRecommendation are queried.
Tenant-specific validation before production use. Category groups, diagnostic categories, table availability, and Defender XDR schema coverage vary by service, license, connector, and portal integration state.

Control-plane reconstruction KQL

Use this in Azure Monitor Logs or Microsoft Sentinel against the AzureActivity table. It reconstructs security-relevant management operations with caller, correlation, operation, target, result, and timing context.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


let lookback = 14d;
let securityRelevantOperations = dynamic([
 "Microsoft.Authorization/roleAssignments/write",
 "Microsoft.Authorization/roleAssignments/delete",
 "Microsoft.Authorization/policyAssignments/write",
 "Microsoft.Authorization/policyExemptions/write",
 "Microsoft.Insights/diagnosticSettings/write",
 "Microsoft.Insights/diagnosticSettings/delete",
 "Microsoft.Network/networkSecurityGroups/securityRules/write",
 "Microsoft.Network/networkSecurityGroups/write",
 "Microsoft.Network/azureFirewalls/write",
 "Microsoft.KeyVault/vaults/write",
 "Microsoft.Storage/storageAccounts/write",
 "Microsoft.Security/pricings/write"
]);
AzureActivity
| where TimeGenerated >= ago(lookback)
| where CategoryValue in ("Administrative", "Policy", "Security")
| where OperationNameValue in~ (securityRelevantOperations)
 or OperationNameValue has_any ("diagnosticSettings", "roleAssignments", "policyAssignments", "networkSecurityGroups", "keyVault", "storageAccounts")
| extend AuthorizationAction = tostring(Authorization_d.action),
 AuthorizationScope = tostring(Authorization_d.scope),
 RequestMethod = tostring(HTTPRequest.method),
 ClientRequestId = tostring(HTTPRequest.clientRequestId),
 ClaimsAppId = tostring(Claims_d.appid),
 ClaimsUpn = tostring(Claims_d.upn)
| project TimeGenerated,
 Caller,
 ClaimsUpn,
 ClaimsAppId,
 CallerIpAddress,
 CorrelationId,
 OperationId,
 OperationNameValue,
 ActivityStatusValue,
 ActivitySubstatusValue,
 SubscriptionId,
 ResourceGroup,
 ResourceProviderValue,
 ResourceId,
 AuthorizationAction,
 AuthorizationScope,
 RequestMethod,
 ClientRequestId,
 Properties_d
| order by TimeGenerated desc

Assumptions: AzureActivity contains subscription-level or management group level events that have been routed to the workspace. CorrelationId groups events from the same broader action, while OperationId identifies the operation event. Use Authorization_d, Claims_d, and Properties_d where available rather than parsing legacy string fields.

Tiered diagnostic-settings Bicep pattern

This sample shows a resource-class pattern, not a universal diagnostic policy. It uses Microsoft.Insights/diagnosticSettings@2021-05-01-preview, the Audit category group for mandatory evidence, and allLogs for a conditional investigative tier when a service and cost model justify it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


@description('Existing Key Vault name used as the example high-risk resource class.')
param keyVaultName string

@description('Central Log Analytics workspace resource ID.')
param logAnalyticsWorkspaceId string

@allowed([
 'mandatoryEvidence'
 'investigative'
])
@description('mandatoryEvidence sends the Audit category group. investigative sends allLogs for deeper troubleshooting where justified.')
param telemetryTier string = 'mandatoryEvidence'

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
 name: keyVaultName
}

resource diagnosticSetting 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
 name: 'set-by-platform-security-baseline'
 scope: keyVault
 properties: {
 workspaceId: logAnalyticsWorkspaceId
 logAnalyticsDestinationType: 'Dedicated'
 logs: telemetryTier == 'mandatoryEvidence' ? [
 {
 categoryGroup: 'Audit'
 enabled: true
 }
 ] : [
 {
 categoryGroup: 'allLogs'
 enabled: true
 }
 ]
 metrics: [
 {
 category: 'AllMetrics'
 enabled: false
 }
 ]
 }
}

Adaptation guidance: do not copy this blindly across resource providers. First list the diagnostic categories and category groups supported by the target resource type, then decide which categories are mandatory evidence and which are conditional investigation support. Use Azure Policy DeployIfNotExists for scale and drift control, but keep per-resource-class decisions visible in the baseline.

ASIM-aligned Sentinel normalization example

This query uses the Microsoft Sentinel ASIM authentication filtering parser. It is intended for workspaces where authentication sources are onboarded through supported ASIM parsers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


let lookback = 1d;
let failureThreshold = 10;
imAuthentication(starttime = ago(lookback), endtime = now())
| where EventType == "Logon"
| where EventResult in ("Failure", "Success")
| summarize
 FailedLogons = countif(EventResult == "Failure"),
 SuccessfulLogons = countif(EventResult == "Success"),
 FirstSeen = min(EventStartTime),
 LastSeen = max(EventEndTime),
 SourceIps = make_set(SrcIpAddr, 10),
 Products = make_set(EventProduct, 10)
 by TargetUsername, TargetUserId, LogonMethod
| where FailedLogons >= failureThreshold and SuccessfulLogons > 0
| project TargetUsername, TargetUserId, LogonMethod, FailedLogons, SuccessfulLogons, FirstSeen, LastSeen, SourceIps, Products
| order by FailedLogons desc

Assumptions: the parser returns ASIM fields such as EventType, EventResult, EventStartTime, EventEndTime, TargetUsername, TargetUserId, LogonMethod, SrcIpAddr, and EventProduct. Validate parser output with known events before promoting the query to an analytic rule.

Defender XDR advanced hunting examples

These examples run in Microsoft Defender XDR advanced hunting, not Azure Monitor Logs. Use them to add identity, device, cloud app, and alert-evidence context around Azure investigations. Do not assume direct joins to AzureActivity inside Defender XDR unless Microsoft Sentinel tables are onboarded into the Defender portal and visible to your role.

Identity and cloud-app context for privileged activity

1
2
3
4
5
6
7


let lookback = 1d;
let adminIndicators = dynamic(["Add member to role", "Add app role assignment", "Consent to application", "Update application"]);
CloudAppEvents
| where Timestamp >= ago(lookback)
| where IsAdminOperation == true or ActionType has_any (adminIndicators) or ActivityType has_any (adminIndicators)
| project Timestamp, AccountObjectId, AccountId, AccountDisplayName, Application, ActionType, ActivityType, IPAddress, CountryCode, OSPlatform, ObjectName, ObjectType, RawEventData
| order by Timestamp desc

Endpoint process context around a suspicious administrator

1
2
3
4
5
6
7


let lookback = 1d;
let accountUpn = "admin@contoso.com";
DeviceEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessAccountUpn =~ accountUpn
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessSHA1, RemoteIP, RemoteUrl, ReportId
| order by Timestamp desc

Alert evidence for Azure or cloud-resource entities

1
2
3
4
5
6


let lookback = 7d;
AlertEvidence
| where Timestamp >= ago(lookback)
| where CloudPlatform =~ "Azure" or isnotempty(ResourceID) or EntityType in~ ("CloudResource", "AzureResource", "User", "Device")
| project Timestamp, AlertId, Title, Severity, ServiceSource, EntityType, EvidenceRole, AccountUpn, DeviceName, CloudResource, ResourceType, ResourceID, SubscriptionId
| order by Timestamp desc

Defender for Cloud continuous export

For scale, prefer the Microsoft built-in Azure Policy definitions for continuous export:

ffb6f416-7bd2-4488-8828-56585fef2be9 deploys export to a Log Analytics workspace for Defender for Cloud alerts and recommendations.
cdfcce10-4578-4ecd-9703-530938e4abcb deploys export to Event Hubs for Defender for Cloud alerts and recommendations.

Where you manage the automation resource directly, this Bicep pattern exports alerts, recommendations, recommendation snapshots, secure score, and attack paths to a Log Analytics workspace. Validate event-source selection and filters in a non-production subscription before broad assignment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65


param location string = resourceGroup().location
param workspaceResourceId string

resource continuousExport 'Microsoft.Security/automations@2019-01-01-preview' = {
 name: 'export-defender-for-cloud-to-law'
 location: location
 properties: {
 description: 'Continuous export of Defender for Cloud operational security findings to Log Analytics.'
 isEnabled: true
 scopes: [
 {
 description: 'Subscription scope'
 scopePath: subscription().id
 }
 ]
 sources: [
 {
 eventSource: 'Alerts'
 ruleSets: [
 {
 rules: [
 {
 propertyJPath: 'Severity'
 propertyType: 'String'
 expectedValue: 'high'
 operator: 'Equals'
 }
 ]
 }
 {
 rules: [
 {
 propertyJPath: 'Severity'
 propertyType: 'String'
 expectedValue: 'medium'
 operator: 'Equals'
 }
 ]
 }
 ]
 }
 {
 eventSource: 'Assessments'
 }
 {
 eventSource: 'AssessmentsSnapshot'
 }
 {
 eventSource: 'SecureScores'
 }
 {
 eventSource: 'SecureScoreControls'
 }
 {
 eventSource: 'AttackPaths'
 }
 ]
 actions: [
 {
 actionType: 'Workspace'
 workspaceResourceId: workspaceResourceId
 }
 ]
 }
}

Query exported recommendations and alerts from Log Analytics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


let lookback = 30d;
SecurityRecommendation
| where TimeGenerated >= ago(lookback)
| summarize
 LatestTime = max(TimeGenerated),
 States = make_set(RecommendationState, 5),
 Severities = make_set(RecommendationSeverity, 5),
 SnapshotRecords = countif(IsSnapshot == true)
 by AssessedResourceId, RecommendationDisplayName, RecommendationId
| order by LatestTime desc

1
2
3
4
5
6


let lookback = 14d;
SecurityAlert
| where TimeGenerated >= ago(lookback)
| where ProductName has "Defender for Cloud" or ProviderName has "Security Center"
| project TimeGenerated, AlertName, AlertSeverity, Status, ProductName, ProviderName, ResourceId, CompromisedEntity, Tactics, Techniques, SystemAlertId, AlertLink
| order by TimeGenerated desc

Hailes Telemetry Utility Score

The Hailes Telemetry Utility Score is a reusable practitioner scorecard for Azure security telemetry. It measures whether telemetry reduces uncertainty during investigation, not whether a team has collected the most data.

Score each dimension from 0 to 5:

Dimension	What good looks like
Completeness	Critical subscriptions, identities, resources, Defender findings, and response paths are represented.
Freshness	Data arrives fast enough for the response decision it supports.
Accuracy	Fields are mapped correctly, parsers are tested, and source semantics are understood.
Accessibility and coverage	The right teams can query the right workspaces, tables, and portals without over-privilege.
Cost efficiency	Ingestion and retention spend are tied to detection, investigation, assurance, or response value.
Tamper resilience	Diagnostic settings, workspaces, exports, retention, and administrative paths are protected and monitored.

Formula:

1

Hailes Telemetry Utility Score = ((completeness + freshness + accuracy + accessibility + costEfficiency + tamperResilience) / 30) * 100

Thresholds:

Score	Interpretation
85-100	Operationally dependable for the assessed scenario.
70-84	Useful, but one or two dimensions can still break an investigation.
50-69	Partial visibility; suitable for backlog prioritization, not assurance.
Below 50	Collection exists, but the scenario is not defensible.

Example: a production privileged-access scenario scores completeness 4, freshness 4, accuracy 3, accessibility 4, cost efficiency 3, and tamper resilience 2. The score is 66.7. That does not mean the telemetry program failed; it means the next investment should be tamper resilience and parser validation, not another dashboard.

Limitations

KQL examples are starting points. Test against your own tables, connector versions, table retention, parser coverage, and role permissions.
AzureActivity, SecurityAlert, and SecurityRecommendation schemas are documented by Microsoft, but individual fields can be empty depending on provider, connector, export path, and event type.
Diagnostic category groups are not universal. Validate supported categories per resource type before assigning policy or Bicep modules at scale.
Defender XDR advanced hunting tables depend on deployed Defender services, licensing, data availability, portal integration, and role access.
Continuous export requires Defender for Cloud enablement, target write permissions, workspace solution requirements, and tenant-aware design for cross-tenant destinations.

Links

Mon, 01 Jan 0001 00:00:00 +0000

Search

Mon, 01 Jan 0001 00:00:00 +0000

Pages on Brewed in the Cloud by Chris Hailes

Azure Reachability Assurance: Reader Toolkit

Download and start offline

Inspect the artifacts

What the lab established

Preview status and safe adaptation

Operate Through Compromise: Reader Toolkit

Download and start offline

Inspect individual artifacts

What was observed, and what was not

Before any cloud execution

About

Who is Chris Hailes?

The Technologist

The Writer, Teacher & Advocate

The Professional

What you’ll find here

Connect

Privacy Policy

Introduction

Information We Collect

1. Analytics Data

2. Cookies and Similar Technologies

3. Embedded Content

4. Server Logs

How We Use Your Information

Data Sharing and Third Parties

Microsoft Clarity

Google Analytics

Hosting Provider

Your Rights Under GDPR

Right of Access

Right to Rectification

Right to Erasure (“Right to be Forgotten”)

Right to Restrict Processing

Right to Data Portability

Right to Object

Right to Withdraw Consent

Cookie Management

Data Retention

International Data Transfers

Security Measures

Archives

Azure Exposure Reduction Toolkit

Download and local quick start

Series and modules

Prerequisites and safety boundary

1. Path record and read-only inventory

2. Threat-to-control matrix

3. Shared-path enforcement matrix

4. Controlled egress and residual risk

5. Change and exception workflow

6. Evidence comparison

Validation, acceptance and maintenance

References

Azure Security Telemetry Toolkit

Series articles

Prerequisites and boundaries

Control-plane reconstruction KQL

Tiered diagnostic-settings Bicep pattern

ASIM-aligned Sentinel normalization example

Defender XDR advanced hunting examples

Identity and cloud-app context for privileged activity

Endpoint process context around a suspicious administrator

Alert evidence for Azure or cloud-resource entities

Defender for Cloud continuous export

Hailes Telemetry Utility Score

Limitations

Links

Search