For the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. Microsoft Learn.
\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. Microsoft Learn.
\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.
\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.
\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.
\nMicrosoft Learn: Action groups.
", "content_text": "Source facts\nFor the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. Microsoft Learn.\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. Microsoft Learn.\nApplicability\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.\nDSE recommendation\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.\nVerification\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.\nOfficial references\nMicrosoft Learn: Action groups.", "content_markdown": "## Source facts\n\nFor the documented key-based Function action, Azure Monitor saves the HTTP-trigger endpoint and its access key in the action definition. Microsoft instructs administrators to remove and recreate that action after changing the Function key. The endpoint must accept HTTP POST. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups).\n\nAn action group must be saved before testing, including after edits. Its test provides Success or Failed status and error details when unsuccessful. Closing the running test window stops the test and prevents results from being returned. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups).\n\n## Applicability\n\nUse this procedure for Azure Monitor action groups invoking Azure Functions through a saved endpoint and access key. It is not a procedure for the separately documented managed-identity preview. Identify the authentication actually configured before choosing a rotation path.\n\n## DSE recommendation\n\nDSE recommends adding the dependent function action to the key owner’s rotation record. Arrange a safe test payload and notify the workflow owner before recreating it. Keep secrets out of tickets and screenshots; record only the action identity, change reference and outcome. Do not assume that changing the Function key automatically updates an existing action definition.\n\n## Verification\n\nSave the replacement action, run the selected action-group test and leave its result view open. Correlate the reported outcome with the Function owner’s observed invocation and intended downstream result. Retain sanitized errors if either observation fails, and keep the change open until the two sides agree.\n\n## Official references\n\n[Microsoft Learn: Action groups](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "slug": "dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend", "url": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/" }, "title": "Check missing summary-rule intervals before accepting a Log Analytics trend", "summary": "How should an operator distinguish a quiet interval from an unsuccessful summary-rule bin?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:50+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 255, "potentially_affected": "Log Analytics workspaces using summary rules in the public cloud.", "dse_recommendation": "Reconcile successful bin execution with the reporting interval before accepting an aggregate trend.", "primary_source": { "name": "Aggregate data in a Log Analytics workspace with summary rules - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Summary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.
\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.
\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.
\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.
\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.
\nMicrosoft Learn: Aggregate data with summary rules.
", "content_text": "Source facts\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.\nApplicability\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\nDSE recommendation\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\nVerification\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\nOfficial references\nMicrosoft Learn: Aggregate data with summary rules.", "content_markdown": "## Source facts\n\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\n## Applicability\n\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules). Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\n\n## DSE recommendation\n\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\n\n## Verification\n\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\n\n## Official references\n\n[Microsoft Learn: Aggregate data with summary rules](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/", "slug": "dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link", "url": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-007-make-a-workbook-arm-action-visibly-different-from-a-navigation-link/" }, "title": "Make a workbook ARM action visibly different from a navigation link", "summary": "What should a workbook reviewer inspect before exposing a link that executes an ARM request?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:49+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 239, "potentially_affected": "Azure Monitor workbooks with ARM action links.", "dse_recommendation": "Expose the intended target and operation clearly, and inspect the resolved request before enabling an operational workbook action.", "primary_source": { "name": "Azure Workbooks link actions - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Workbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. Microsoft Learn.
\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. Microsoft Learn.
\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.
\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.
\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.
\nMicrosoft Learn: Workbook link actions.
", "content_text": "Source facts\nWorkbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. Microsoft Learn.\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. Microsoft Learn.\nApplicability\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.\nDSE recommendation\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.\nVerification\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.\nOfficial references\nMicrosoft Learn: Workbook link actions.", "content_markdown": "## Source facts\n\nWorkbook link actions include both navigation and ARM operations. The ARM action configuration specifies an API path, method, parameters, headers and JSON body; its method choices include POST, PUT, PATCH and DELETE. Parameters and grid-column values can supply request content. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions).\n\nSelecting the link opens a configured run view. The action executes when the user selects its run button. View Request Details exposes the request method and endpoint, while an Azure portal notification reports progress and outcome. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions).\n\n## Applicability\n\nThis review concerns Azure Monitor workbooks with ARM action links. Keep it separate from ordinary resource navigation and workbook formatting. Do not describe an action as a harmless detail view merely because both begin with a click.\n\n## DSE recommendation\n\nDSE recommends wording the link and run button around the actual operation. Include the intended resource in the description and identify which row or parameter supplies it. Review every dynamic input against the operator’s intended selection. For a destructive request, require the existing change-approval process and an explicit target check; publishing a workbook is not approval to execute its actions.\n\n## Verification\n\nUse a disposable resource and inspect the resolved request before execution. Compare the displayed target with the endpoint and body, then record the notification and resulting resource state. Repeat with a different row to detect a fixed or incorrectly bound target. Keep the reviewed workbook version with these observations.\n\n## Official references\n\n[Microsoft Learn: Workbook link actions](https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/workbooks-link-actions)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "slug": "dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request", "url": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/" }, "title": "Validate the HANA host role before submitting a NetApp volume-group request", "summary": "Can the same NetApp application-volume-group payload be reused for the first and every additional HANA host?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:48+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Use this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source's networking, placement and protocol requirements before deployment.", "dse_recommendation": "Make host role and expected volume roles explicit inputs to the deployment review.", "primary_source": { "name": "Configure application volume groups for SAP HANA using REST API | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.
\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.
\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.
\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.
\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.
", "content_text": "Source facts\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.\nApplicability\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\nDSE recommendation\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\nVerification\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\nOfficial references\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.", "content_markdown": "## Source facts\n\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api).\n\n## Applicability\n\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\n\n## DSE recommendation\n\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\n\n## Verification\n\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\n\n## Official references\n\n[Microsoft Learn: Configure application volume groups for SAP HANA using REST API](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/", "slug": "dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack", "url": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-009-choose-what-happens-when-a-resource-leaves-an-azure-deployment-stack/" }, "title": "Choose what happens when a resource leaves an Azure deployment stack", "summary": "Make removal from a stack an explicit detach-or-delete decision, with special scrutiny for resource-group deletion.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:47+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 211, "potentially_affected": "Azure resources managed by deployment stacks.", "dse_recommendation": "Approve the intended detach-or-delete outcome for each removed resource before updating the stack.", "primary_source": { "name": "Create and deploy Azure deployment stacks in Bicep - Azure Resource Manager | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Removing a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.
\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. Microsoft Learn.
\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.
\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.
\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.
\nMicrosoft Learn: Create and deploy Azure deployment stacks in Bicep. Source retrieved September 9, 2026.
", "content_text": "Source facts\nRemoving a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. Microsoft Learn.\nApplicability\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.\nDSE recommendation\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.\nVerification\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.\nOfficial references\nMicrosoft Learn: Create and deploy Azure deployment stacks in Bicep. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nRemoving a resource from a deployment stack’s template can detach that resource or delete it; the stack’s actionOnUnmanage setting determines the outcome.\n\nMicrosoft warns that deleting managed resource groups with deleteAll also deletes everything inside those groups. The impact therefore extends beyond an individual resource removed from a template. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks).\n\n## Applicability\n\nUse this review for a stack update or retirement. Identify the stack scope, managed resources, underlying template, and proposed removal behavior. Include group contents in the review whenever a resource group could be deleted.\n\n## DSE recommendation\n\nDSE recommends a removal manifest with one intended outcome per resource: retain outside the stack or delete under an approved retirement. Have the workload owner confirm dependencies and data-retention needs. Keep the reviewed template and stack settings together, and reject an unexplained change from retention to deletion. Do not use environment cleanup as implicit approval to remove shared resources.\n\n## Verification\n\nRehearse the exact removal in a disposable stack. Compare the surviving Azure resources with the stack’s managed-resource list, then check the intended retained resource directly. For a group-deletion rehearsal, inventory every child beforehand and reconcile the result afterward. Preserve that evidence before approving the production update.\n\n## Official references\n\n[Microsoft Learn: Create and deploy Azure deployment stacks in Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/", "slug": "dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store", "url": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-010-distinguish-a-managed-application-package-url-from-its-byos-definition-store/" }, "title": "Distinguish a managed-application package URL from its BYOS definition store", "summary": "Which storage location retains the managed-application definition after a BYOS publication?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:46+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 242, "potentially_affected": "Azure Managed Applications service-catalog definitions using bring-your-own storage.", "dse_recommendation": "DSE recommends recording both locations and the writer identity before publication.", "primary_source": { "name": "Bring your own storage to create and publish an Azure Managed Application definition - Azure Managed Applications | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "In a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. Microsoft Learn.
\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. Microsoft Learn.
\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.
\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.
\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.
\nMicrosoft Learn. Source retrieved September 9, 2026.
", "content_text": "Source facts\nIn a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. Microsoft Learn.\nApplicability\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. Microsoft Learn.\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.\nDSE recommendation\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.\nVerification\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nIn a managed-application BYOS definition, packageFileUri identifies the input ZIP, while storageAccountId identifies the account used to retain definition files. Deployment creates an applicationdefinitions container there and copies the package’s files into it. Microsoft requires the Appliance Resource Provider identity to have Contributor at that storage account so it can write those files. BYOS definition deployment supports ARM templates or REST. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage).\n\n## Applicability\n\nManaged Applications accepts ARM languageVersion 1.0, not 2.0. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage).\n\nIdentify the package source and the definition-storage destination as separate roles, even if a design places them close together. This review concerns definition publication, not the later application’s runtime storage or the publisher’s access to a customer’s managed resource group.\n\n## DSE recommendation\n\nDSE recommends recording both locations and the writer identity before publication. Have the storage owner verify the destination account and scoped role assignment, and compare the package URL against the approved release artifact. Review the complete supported deployment path rather than substituting a source URL for the destination account identifier. Keep storage-security changes under their own approval.\n\n## Verification\n\nAfter an approved definition deployment, inspect the destination account’s applicationdefinitions container and confirm the expected definition files are present. Compare that evidence with the input archive and publication record. Verify the intended reader can access the definition separately from the service identity’s write access. Do not report a successful upload to the package-source container as proof that BYOS definition publication completed.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/publish-service-catalog-bring-your-own-storage). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "slug": "dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup", "url": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/" }, "title": "Do not equate a MARS volume snapshot with application-consistent backup", "summary": "Does the MARS agent's use of VSS establish application-consistent recovery for the files it protects?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:45+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 235, "potentially_affected": "Identify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server's stored data.", "dse_recommendation": "Match the required application recovery behavior to the selected backup method before accepting coverage.", "primary_source": { "name": "Architecture Overview - Azure Backup | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/backup/backup-architecture", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "For direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.
\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.
\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.
\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.
\nMicrosoft Learn: Architecture Overview.
", "content_text": "Source facts\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.\nApplicability\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\nDSE recommendation\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\nVerification\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\nOfficial references\nMicrosoft Learn: Architecture Overview.", "content_markdown": "## Source facts\n\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/backup/backup-architecture).\n\n## Applicability\n\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\n\n## DSE recommendation\n\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\n\n## Verification\n\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\n\n## Official references\n\n[Microsoft Learn: Architecture Overview](https://learn.microsoft.com/en-us/azure/backup/backup-architecture)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/", "slug": "dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull", "url": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-012-check-the-registry-support-boundary-before-retrying-a-private-aci-image-pull/" }, "title": "Check the registry support boundary before retrying a private ACI image pull", "summary": "Will private network reachability make any private registry usable by Azure Container Instances?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:44+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 232, "potentially_affected": "Apply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.", "dse_recommendation": "Confirm the registry type before expanding network access or repeating deployment.", "primary_source": { "name": "Troubleshoot common issues - Azure Container Instances | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. Microsoft Learn.
\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.
\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.
\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.
\nMicrosoft Learn: Troubleshoot common issues.
", "content_text": "Source facts\nMicrosoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. Microsoft Learn.\nApplicability\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.\nDSE recommendation\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.\nVerification\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.\nOfficial references\nMicrosoft Learn: Troubleshoot common issues.", "content_markdown": "## Source facts\n\nMicrosoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting).\n\n## Applicability\n\nApply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.\n\n## DSE recommendation\n\nConfirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.\n\n## Verification\n\nInspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.\n\n## Official references\n\n[Microsoft Learn: Troubleshoot common issues](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/", "slug": "dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access", "url": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-013-separate-machine-configuration-service-access-from-custom-package-access/" }, "title": "Separate Machine Configuration service access from custom package access", "summary": "Review the service path and package location separately when restricting Machine Configuration network access.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:43+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 223, "potentially_affected": "Azure VMs and Arc-enabled servers using Machine Configuration.", "dse_recommendation": "Record the service connection and every custom package location before approving egress restrictions.", "primary_source": { "name": "Azure Machine Configuration network requirements - Azure Machine Configuration | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "For the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.
\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.
\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. Microsoft Learn.
\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.
\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.
\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.
\nMicrosoft Learn: Azure Machine Configuration network requirements. Source retrieved September 9, 2026.
", "content_text": "Source facts\nFor the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. Microsoft Learn.\nApplicability\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.\nDSE recommendation\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.\nVerification\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.\nOfficial references\nMicrosoft Learn: Azure Machine Configuration network requirements. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nFor the Azure virtual-network path, Microsoft requires outbound port 443 access and identifies both AzureArcInfrastructure and Storage service tags. Storage is needed because it hosts configuration packages.\n\nAzure VMs using the documented private-link path do not need publicly reachable regional GAS endpoints. However, a custom package at a public Storage or non-Azure URL still needs a reachable, allowed URL. Built-in packages on Arc-enabled servers using private link follow that link without additional server tags.\n\nThe Arc built-in-package behavior is documented separately from the Azure VM tagging procedure. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements).\n\n## Applicability\n\nIdentify whether each target is an Azure VM or an Arc-enabled server, and whether its package is built in or custom. Do not copy one platform’s network assumptions to the other.\n\n## DSE recommendation\n\nDSE recommends a two-column access record: service communication and package download. Record the actual package URI from the assignment, its hosting boundary, and the approved route. Review public package dependencies before closing egress. Ask the configuration owner to identify a representative assignment for each distinct package-hosting pattern.\n\n## Verification\n\nOn approved test machines, compare service reporting with package retrieval and assignment execution. Preserve the target type, assignment, observed destination, and outcome separately. Investigate a successful service connection alongside a failed package download before declaring the restricted design ready.\n\n## Official references\n\n[Microsoft Learn: Azure Machine Configuration network requirements](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/03-network-requirements). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/", "slug": "dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection", "url": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-014-place-nat-gateway-behind-azure-firewall-without-bypassing-spoke-inspection/" }, "title": "Place NAT Gateway behind Azure Firewall without bypassing spoke inspection", "summary": "Keep the spoke route, firewall policy, and NAT association aligned when expanding outbound connectivity.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:42+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 219, "potentially_affected": "Azure Firewall hub-and-spoke networks considering NAT Gateway integration.", "dse_recommendation": "Review spoke-to-firewall routing and the AzureFirewallSubnet NAT association as one egress change.", "primary_source": { "name": "Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network - Azure NAT Gateway | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.
\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. Microsoft Learn.
\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.
\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.
\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.
\nMicrosoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network. Source retrieved September 9, 2026.
", "content_text": "Source facts\nMicrosoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. Microsoft Learn.\nApplicability\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.\nDSE recommendation\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.\nVerification\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.\nOfficial references\nMicrosoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’s example associates NAT Gateway with AzureFirewallSubnet. The spoke route table points to Azure Firewall’s private address, and firewall policy must permit the spoke traffic. NAT integration therefore accompanies an explicit route through the firewall.\n\nThis placement does not extend to a Virtual WAN hub: Microsoft says NAT Gateway is unsupported there and instead must be attached directly to the relevant spoke networks for that architecture. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall).\n\n## Applicability\n\nConfirm that the design is a conventional hub-and-spoke network before adopting this tutorial. Record each spoke subnet, its route table, the firewall address, and the proposed NAT association; keep Virtual WAN designs in a separate review.\n\n## DSE recommendation\n\nDSE recommends treating this as an egress-path change, not just creation of a NAT resource. Obtain the application owner’s approved destinations and the network owner’s expected translated address. Compare the route and firewall policy before associating the gateway. Retain the previous configuration and an agreed rollback decision.\n\n## Verification\n\nFrom a test spoke, exercise an allowed internet destination and a deliberately prohibited one. Check the observed outbound address and firewall evidence together. A successful internet request alone should not satisfy acceptance; reconcile the actual next hop and policy result with the approved design.\n\n## Official references\n\n[Microsoft Learn: Integrate NAT Gateway with Azure Firewall in Hub and Spoke Network](https://learn.microsoft.com/en-us/azure/nat-gateway/tutorial-hub-spoke-nat-firewall). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-017-separate-new-child-inheritance-from-existing-data-lake-acl-remediation/", "slug": "dse-20260909-017-separate-new-child-inheritance-from-existing-data-lake-acl-remediation", "url": "https://update.dsesecurity.com/updates/dse-20260909-017-separate-new-child-inheritance-from-existing-data-lake-acl-remediation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-017-separate-new-child-inheritance-from-existing-data-lake-acl-remediation.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-017-separate-new-child-inheritance-from-existing-data-lake-acl-remediation/" }, "title": "Separate new-child inheritance from existing Data Lake ACL remediation", "summary": "Test old and newly created children separately after changing a Data Lake Storage directory's default ACL.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:39+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 227, "potentially_affected": "Azure Data Lake Storage directories governed by POSIX-style ACLs.", "dse_recommendation": "Plan existing-child remediation separately from the default ACL applied to future children.", "primary_source": { "name": "Access control lists (ACLs) in Azure Data Lake Storage - Azure Storage | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Data Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.
\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. Microsoft Learn.
\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.
\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.
\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.
\nMicrosoft Learn: Access control lists (ACLs) in Azure Data Lake Storage. Source retrieved September 9, 2026.
", "content_text": "Source facts\nData Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. Microsoft Learn.\nApplicability\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.\nDSE recommendation\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.\nVerification\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.\nOfficial references\nMicrosoft Learn: Access control lists (ACLs) in Azure Data Lake Storage. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nData Lake Storage keeps an item’s permissions on that item. A directory’s default ACL supplies inheritance when a child is created; changing the default afterward does not update existing children. Existing access ACLs and default ACLs therefore require their own review.\n\nWhen access is granted only through ACLs, a file reader or writer also needs Execute permission on the container root and every intervening directory. That qualification matters when testing the resulting access path. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control).\n\n## Applicability\n\nApply this distinction to ACL-based directory permissions. Identify the caller and authorization route before testing, and record any broader role grants rather than assuming an access result came from the ACL alone.\n\n## DSE recommendation\n\nDSE recommends separating the change request into future-child defaults and the explicitly approved existing-child population. Inventory both before making changes. Have the data owner specify intended access for each population, and preserve the original ACLs so an incorrect broad change can be investigated and reversed deliberately.\n\n## Verification\n\nUse a controlled directory containing a preexisting file, then create a second file after the default change. Compare the stored permissions and actual authorized-user access for both. Check directory traversal separately, and include an unintended user in the denial test. Retain object paths and ACL evidence without copying sensitive file contents.\n\n## Official references\n\n[Microsoft Learn: Access control lists (ACLs) in Azure Data Lake Storage](https://learn.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-access-control). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/", "slug": "dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group", "url": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-018-choose-the-key-identity-before-creating-an-encrypted-elastic-san-volume-group/" }, "title": "Choose the key identity before creating an encrypted Elastic SAN volume group", "summary": "Distinguish customer-managed-key setup during volume-group creation from configuration of an existing group.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:38+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 226, "potentially_affected": "Azure Elastic SAN volume groups using customer-managed encryption keys.", "dse_recommendation": "Prepare a user-assigned identity for creation-time key access, and review later identity changes separately.", "primary_source": { "name": "Configure Customer-Managed Keys for Azure Elastic SAN | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.
\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. Microsoft Learn.
\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.
\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.
\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.
\nMicrosoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN. Source retrieved September 9, 2026.
", "content_text": "Source facts\nA new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. Microsoft Learn.\nApplicability\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.\nDSE recommendation\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.\nVerification\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.\nOfficial references\nMicrosoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nA new Elastic SAN volume group using customer-managed keys requires a user-assigned identity. A system-assigned identity is not available before the group exists, so that identity can be configured for key access only afterward, with appropriate permissions.\n\nThe key vault must have both soft delete and purge protection enabled. These are prerequisites for the documented customer-managed-key configuration, not substitutes for granting the chosen identity access to the key. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys).\n\n## Applicability\n\nUse this review when deciding whether encryption is configured during creation or added to an existing volume group. Record the group, identity, vault, key, and selected key-version update method before adapting the source’s examples.\n\n## DSE recommendation\n\nDSE recommends making identity readiness a deployment prerequisite. Have the storage and key-vault owners agree which identity should retain access, then document the approved grant and its scope. Do not silently switch identity types to work around an authorization failure. Treat any later identity replacement as a separate change with dependency evidence.\n\n## Verification\n\nRehearse the chosen creation or update path in a nonproduction volume group. Inspect the resulting encryption configuration, the actual identity identifier, and the corresponding vault grant. Check an approved read/write workload afterward and retain the result. Record key identifiers and permissions, never secret key material, in the deployment evidence.\n\n## Official references\n\n[Microsoft Learn: Configure Customer-Managed Keys for Azure Elastic SAN](https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-configure-customer-managed-keys). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-019-include-file-sync-s-paired-region-destinations-in-a-grs-firewall-review/", "slug": "dse-20260909-019-include-file-sync-s-paired-region-destinations-in-a-grs-firewall-review", "url": "https://update.dsesecurity.com/updates/dse-20260909-019-include-file-sync-s-paired-region-destinations-in-a-grs-firewall-review/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-019-include-file-sync-s-paired-region-destinations-in-a-grs-firewall-review.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-019-include-file-sync-s-paired-region-destinations-in-a-grs-firewall-review/" }, "title": "Include File Sync's paired-region destinations in a GRS firewall review", "summary": "Review File Sync regional and discovery destinations against the storage redundancy choice.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:37+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 221, "potentially_affected": "Azure File Sync servers connected to geo-redundant Azure storage accounts.", "dse_recommendation": "Check primary-region, paired-region, and discovery destinations together before accepting the File Sync allowlist.", "primary_source": { "name": "Azure File Sync on-premises firewall and proxy settings | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-firewall-and-proxy", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "For public-cloud File Sync service endpoints, Microsoft distinguishes storage redundancy choices. LRS and ZRS use the listed primary endpoint; GRS requires the primary region’s endpoint, its paired region’s endpoint, and the region’s discovery URL.
\nAfter server registration, Test-StorageSyncNetworkConnectivity and ServerRegistration.exe can test communications with that server’s service endpoints. These checks help identify incomplete proxy or firewall access. Microsoft Learn.
\nIdentify the storage account’s actual redundancy configuration and the Storage Sync Service region. Use the current table for the correct Azure cloud. Treat the regional service list as one part of the complete File Sync network requirements, not the entire dependency inventory.
\nDSE recommends recording each required destination alongside its role: primary service, paired-region service, or discovery. Ask the firewall owner to reconcile explicit entries with the deployed region rather than copying another server’s allowlist. Include a review trigger for region, redundancy, proxy, or endpoint-policy changes, and retain the previous rules.
\nRun the documented endpoint test from the registered server and preserve the per-destination results. Investigate any blocked paired-region or discovery destination even when routine synchronization appears healthy. Recheck after approved firewall changes. Record this as connectivity evidence only; schedule a separate recovery exercise if recovery behavior must be proven.
\nMicrosoft Learn: Azure File Sync on-premises firewall and proxy settings. Source retrieved September 9, 2026.
", "content_text": "Source facts\nFor public-cloud File Sync service endpoints, Microsoft distinguishes storage redundancy choices. LRS and ZRS use the listed primary endpoint; GRS requires the primary region’s endpoint, its paired region’s endpoint, and the region’s discovery URL.\nAfter server registration, Test-StorageSyncNetworkConnectivity and ServerRegistration.exe can test communications with that server’s service endpoints. These checks help identify incomplete proxy or firewall access. Microsoft Learn.\nApplicability\nIdentify the storage account’s actual redundancy configuration and the Storage Sync Service region. Use the current table for the correct Azure cloud. Treat the regional service list as one part of the complete File Sync network requirements, not the entire dependency inventory.\nDSE recommendation\nDSE recommends recording each required destination alongside its role: primary service, paired-region service, or discovery. Ask the firewall owner to reconcile explicit entries with the deployed region rather than copying another server’s allowlist. Include a review trigger for region, redundancy, proxy, or endpoint-policy changes, and retain the previous rules.\nVerification\nRun the documented endpoint test from the registered server and preserve the per-destination results. Investigate any blocked paired-region or discovery destination even when routine synchronization appears healthy. Recheck after approved firewall changes. Record this as connectivity evidence only; schedule a separate recovery exercise if recovery behavior must be proven.\nOfficial references\nMicrosoft Learn: Azure File Sync on-premises firewall and proxy settings. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nFor public-cloud File Sync service endpoints, Microsoft distinguishes storage redundancy choices. LRS and ZRS use the listed primary endpoint; GRS requires the primary region’s endpoint, its paired region’s endpoint, and the region’s discovery URL.\n\nAfter server registration, Test-StorageSyncNetworkConnectivity and ServerRegistration.exe can test communications with that server’s service endpoints. These checks help identify incomplete proxy or firewall access. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-firewall-and-proxy).\n\n## Applicability\n\nIdentify the storage account’s actual redundancy configuration and the Storage Sync Service region. Use the current table for the correct Azure cloud. Treat the regional service list as one part of the complete File Sync network requirements, not the entire dependency inventory.\n\n## DSE recommendation\n\nDSE recommends recording each required destination alongside its role: primary service, paired-region service, or discovery. Ask the firewall owner to reconcile explicit entries with the deployed region rather than copying another server’s allowlist. Include a review trigger for region, redundancy, proxy, or endpoint-policy changes, and retain the previous rules.\n\n## Verification\n\nRun the documented endpoint test from the registered server and preserve the per-destination results. Investigate any blocked paired-region or discovery destination even when routine synchronization appears healthy. Recheck after approved firewall changes. Record this as connectivity evidence only; schedule a separate recovery exercise if recovery behavior must be proven.\n\n## Official references\n\n[Microsoft Learn: Azure File Sync on-premises firewall and proxy settings](https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-firewall-and-proxy). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-020-review-queue-storage-message-updates-before-chaining-another-work-queue/", "slug": "dse-20260909-020-review-queue-storage-message-updates-before-chaining-another-work-queue", "url": "https://update.dsesecurity.com/updates/dse-20260909-020-review-queue-storage-message-updates-before-chaining-another-work-queue/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-020-review-queue-storage-message-updates-before-chaining-another-work-queue.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-020-review-queue-storage-message-updates-before-chaining-another-work-queue/" }, "title": "Review Queue Storage message updates before chaining another work queue", "summary": "Consider message-state and invisibility updates for multi-step workers, then test interruption and retry behavior explicitly.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:36+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 227, "potentially_affected": "Applications processing multi-step work in Azure Queue Storage.", "dse_recommendation": "Compare an in-message progress design with the existing queue handoff before changing the worker.", "primary_source": { "name": "Performance and scalability checklist for Queue Storage - Azure Storage | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/queues/storage-performance-checklist", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Queue Storage’s update-message operation can change message state information or extend its invisibility timeout. Microsoft describes this as an alternative to passing a job between queues after each step. Each update still contributes to the service’s scalability target.
\nFor direct REST callers, Microsoft warns against retrying an unchanged malformed request: a Bad Request response is not corrected by sending the same request again. Microsoft Learn.
\nReview the actual worker’s steps, progress representation, processing duration, and error handling. Keep the decision focused on one workflow; do not assume every queue handoff is unnecessary or that an update proves business processing finished.
\nDSE recommends documenting the meaning of each stored progress state before altering queue topology. Specify when the worker should update progress, when it should extend the invisibility period, and who owns a stalled job. Classify invalid requests separately from retryable failures. Compare the proposed update rate with the workload’s measured transaction pattern.
\nIn a test queue, interrupt the worker between two documented steps and observe what the next processing attempt sees. Check the saved state and actual business-side effects separately. Exercise a malformed request and confirm that the application reports it without an uncontrolled retry loop. Retain the test sequence and observed messages with sensitive payloads removed.
\nMicrosoft Learn: Performance and scalability checklist for Queue Storage. Source retrieved September 9, 2026.
", "content_text": "Source facts\nQueue Storage’s update-message operation can change message state information or extend its invisibility timeout. Microsoft describes this as an alternative to passing a job between queues after each step. Each update still contributes to the service’s scalability target.\nFor direct REST callers, Microsoft warns against retrying an unchanged malformed request: a Bad Request response is not corrected by sending the same request again. Microsoft Learn.\nApplicability\nReview the actual worker’s steps, progress representation, processing duration, and error handling. Keep the decision focused on one workflow; do not assume every queue handoff is unnecessary or that an update proves business processing finished.\nDSE recommendation\nDSE recommends documenting the meaning of each stored progress state before altering queue topology. Specify when the worker should update progress, when it should extend the invisibility period, and who owns a stalled job. Classify invalid requests separately from retryable failures. Compare the proposed update rate with the workload’s measured transaction pattern.\nVerification\nIn a test queue, interrupt the worker between two documented steps and observe what the next processing attempt sees. Check the saved state and actual business-side effects separately. Exercise a malformed request and confirm that the application reports it without an uncontrolled retry loop. Retain the test sequence and observed messages with sensitive payloads removed.\nOfficial references\nMicrosoft Learn: Performance and scalability checklist for Queue Storage. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nQueue Storage’s update-message operation can change message state information or extend its invisibility timeout. Microsoft describes this as an alternative to passing a job between queues after each step. Each update still contributes to the service’s scalability target.\n\nFor direct REST callers, Microsoft warns against retrying an unchanged malformed request: a Bad Request response is not corrected by sending the same request again. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/queues/storage-performance-checklist).\n\n## Applicability\n\nReview the actual worker’s steps, progress representation, processing duration, and error handling. Keep the decision focused on one workflow; do not assume every queue handoff is unnecessary or that an update proves business processing finished.\n\n## DSE recommendation\n\nDSE recommends documenting the meaning of each stored progress state before altering queue topology. Specify when the worker should update progress, when it should extend the invisibility period, and who owns a stalled job. Classify invalid requests separately from retryable failures. Compare the proposed update rate with the workload’s measured transaction pattern.\n\n## Verification\n\nIn a test queue, interrupt the worker between two documented steps and observe what the next processing attempt sees. Check the saved state and actual business-side effects separately. Exercise a malformed request and confirm that the application reports it without an uncontrolled retry loop. Retain the test sequence and observed messages with sensitive payloads removed.\n\n## Official references\n\n[Microsoft Learn: Performance and scalability checklist for Queue Storage](https://learn.microsoft.com/en-us/azure/storage/queues/storage-performance-checklist). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-021-finish-azure-table-queries-by-following-continuation-tokens/", "slug": "dse-20260909-021-finish-azure-table-queries-by-following-continuation-tokens", "url": "https://update.dsesecurity.com/updates/dse-20260909-021-finish-azure-table-queries-by-following-continuation-tokens/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-021-finish-azure-table-queries-by-following-continuation-tokens.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-021-finish-azure-table-queries-by-following-continuation-tokens/" }, "title": "Finish Azure Table queries by following continuation tokens", "summary": "Test completion against continuation state, not merely the number of entities returned in one response.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:35+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 1, "word_count": 218, "potentially_affected": "Applications retrieving multiple entities from Azure Table Storage.", "dse_recommendation": "Make continuation handling an explicit acceptance test for every multi-entity Table Storage reader.", "primary_source": { "name": "Azure storage table design patterns | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-patterns", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Table Storage can return a continuation token when a query exceeds a response’s entity or execution-time limit, or crosses a partition boundary. The token lets the caller request the next segment rather than treating the current response as the whole result.
\nMicrosoft also notes that a segment can contain fewer entities than requested while still supplying a continuation token. A short segment therefore does not by itself establish query completion. Microsoft Learn.
\nReview readers that populate inventories, exports, or reports from multiple entities. Identify whether the selected client library follows continuation automatically or whether application code owns that loop; confirm behavior in the actual implementation.
\nDSE recommends documenting the reader’s stopping rule and preserving a stable query definition throughout retrieval. Separate a deliberately bounded business result from accidental truncation. Define how an interrupted export should resume or restart, and make an incomplete run visibly different from a completed empty or short result.
\nUse a known test dataset spanning several segments and partitions. Compare the completed output with expected entities, then test a response smaller than the requested page size that still carries a token. Check interruption handling and the final completion marker. Keep the dataset definition and run evidence together.
\nMicrosoft Learn: Azure storage table design patterns. Source retrieved September 9, 2026.
", "content_text": "Source facts\nTable Storage can return a continuation token when a query exceeds a response’s entity or execution-time limit, or crosses a partition boundary. The token lets the caller request the next segment rather than treating the current response as the whole result.\nMicrosoft also notes that a segment can contain fewer entities than requested while still supplying a continuation token. A short segment therefore does not by itself establish query completion. Microsoft Learn.\nApplicability\nReview readers that populate inventories, exports, or reports from multiple entities. Identify whether the selected client library follows continuation automatically or whether application code owns that loop; confirm behavior in the actual implementation.\nDSE recommendation\nDSE recommends documenting the reader’s stopping rule and preserving a stable query definition throughout retrieval. Separate a deliberately bounded business result from accidental truncation. Define how an interrupted export should resume or restart, and make an incomplete run visibly different from a completed empty or short result.\nVerification\nUse a known test dataset spanning several segments and partitions. Compare the completed output with expected entities, then test a response smaller than the requested page size that still carries a token. Check interruption handling and the final completion marker. Keep the dataset definition and run evidence together.\nOfficial references\nMicrosoft Learn: Azure storage table design patterns. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nTable Storage can return a continuation token when a query exceeds a response’s entity or execution-time limit, or crosses a partition boundary. The token lets the caller request the next segment rather than treating the current response as the whole result.\n\nMicrosoft also notes that a segment can contain fewer entities than requested while still supplying a continuation token. A short segment therefore does not by itself establish query completion. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-patterns).\n\n## Applicability\n\nReview readers that populate inventories, exports, or reports from multiple entities. Identify whether the selected client library follows continuation automatically or whether application code owns that loop; confirm behavior in the actual implementation.\n\n## DSE recommendation\n\nDSE recommends documenting the reader’s stopping rule and preserving a stable query definition throughout retrieval. Separate a deliberately bounded business result from accidental truncation. Define how an interrupted export should resume or restart, and make an incomplete run visibly different from a completed empty or short result.\n\n## Verification\n\nUse a known test dataset spanning several segments and partitions. Compare the completed output with expected entities, then test a response smaller than the requested page size that still carries a token. Check interruption handling and the final completion marker. Keep the dataset definition and run evidence together.\n\n## Official references\n\n[Microsoft Learn: Azure storage table design patterns](https://learn.microsoft.com/en-us/azure/storage/tables/table-storage-design-patterns). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-022-prepare-scale-set-workloads-for-automatic-os-disk-replacement/", "slug": "dse-20260909-022-prepare-scale-set-workloads-for-automatic-os-disk-replacement", "url": "https://update.dsesecurity.com/updates/dse-20260909-022-prepare-scale-set-workloads-for-automatic-os-disk-replacement/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-022-prepare-scale-set-workloads-for-automatic-os-disk-replacement.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-022-prepare-scale-set-workloads-for-automatic-os-disk-replacement/" }, "title": "Prepare scale-set workloads for automatic OS disk replacement", "summary": "What must be reproducible before an Azure scale set receives automatic OS image upgrades?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:34+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 255, "potentially_affected": "Operators considering automatic OS image upgrades for Azure Virtual Machine Scale Sets.", "dse_recommendation": "Prove that the application can be reconstructed from the scale-set model before enabling automatic image replacement.", "primary_source": { "name": "Automatic OS image upgrades with Azure Virtual Machine Scale Sets - Azure Virtual Machine Scale Sets | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An automatic OS image upgrade replaces each instance’s operating-system disk, reruns configured extensions and custom-data scripts, and preserves attached data disks. Microsoft requires the image version to be latest. Non-Service Fabric scale sets need application-health monitoring, using either the health extension or a load-balancer probe, not both. For multiple placement groups, the documented probe requirement specifies a Standard Load Balancer. Automatic image upgrades must not be combined with AutomaticByPlatform guest-patch orchestration. Microsoft Learn.
\nScope this readiness check to Uniform orchestration outside Service Fabric. The documentation identifies automatic OS upgrades for Flexible orchestration as preview and gives that mode additional restrictions. Check the supported image list before choosing the mechanism. Mode and image requirements.
\nProve that the application can be reconstructed from the scale-set model before enabling automatic image replacement. Ask its owner to identify every change made manually inside an instance, then decide where each required setting or artifact will be maintained. Include bootstrap credentials and the intended data-disk attachment behavior in that review. Choose an application-health response that represents readiness to serve the actual workload.
\nUse an approved test scale set to observe an image transition. Compare the resulting application configuration with the declared model, exercise the service transaction, and record the health signal that allowed progression. Resolve missing customizations before expanding the rollout. Preserve upgrade-history evidence alongside the tested image reference; do not treat a deployment flag alone as acceptance.
\nMicrosoft Learn: Automatic OS image upgrades with Azure Virtual Machine Scale Sets. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAn automatic OS image upgrade replaces each instance’s operating-system disk, reruns configured extensions and custom-data scripts, and preserves attached data disks. Microsoft requires the image version to be latest. Non-Service Fabric scale sets need application-health monitoring, using either the health extension or a load-balancer probe, not both. For multiple placement groups, the documented probe requirement specifies a Standard Load Balancer. Automatic image upgrades must not be combined with AutomaticByPlatform guest-patch orchestration. Microsoft Learn.\nApplicability\nScope this readiness check to Uniform orchestration outside Service Fabric. The documentation identifies automatic OS upgrades for Flexible orchestration as preview and gives that mode additional restrictions. Check the supported image list before choosing the mechanism. Mode and image requirements.\nDSE recommendation\nProve that the application can be reconstructed from the scale-set model before enabling automatic image replacement. Ask its owner to identify every change made manually inside an instance, then decide where each required setting or artifact will be maintained. Include bootstrap credentials and the intended data-disk attachment behavior in that review. Choose an application-health response that represents readiness to serve the actual workload.\nVerification\nUse an approved test scale set to observe an image transition. Compare the resulting application configuration with the declared model, exercise the service transaction, and record the health signal that allowed progression. Resolve missing customizations before expanding the rollout. Preserve upgrade-history evidence alongside the tested image reference; do not treat a deployment flag alone as acceptance.\nOfficial references\nMicrosoft Learn: Automatic OS image upgrades with Azure Virtual Machine Scale Sets. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAn automatic OS image upgrade replaces each instance’s operating-system disk, reruns configured extensions and custom-data scripts, and preserves attached data disks. Microsoft requires the image version to be latest. Non-Service Fabric scale sets need application-health monitoring, using either the health extension or a load-balancer probe, not both. For multiple placement groups, the documented probe requirement specifies a Standard Load Balancer. Automatic image upgrades must not be combined with AutomaticByPlatform guest-patch orchestration. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade).\n\n## Applicability\n\nScope this readiness check to Uniform orchestration outside Service Fabric. The documentation identifies automatic OS upgrades for Flexible orchestration as preview and gives that mode additional restrictions. Check the supported image list before choosing the mechanism. [Mode and image requirements](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade).\n\n## DSE recommendation\n\nProve that the application can be reconstructed from the scale-set model before enabling automatic image replacement. Ask its owner to identify every change made manually inside an instance, then decide where each required setting or artifact will be maintained. Include bootstrap credentials and the intended data-disk attachment behavior in that review. Choose an application-health response that represents readiness to serve the actual workload.\n\n## Verification\n\nUse an approved test scale set to observe an image transition. Compare the resulting application configuration with the declared model, exercise the service transaction, and record the health signal that allowed progression. Resolve missing customizations before expanding the rollout. Preserve upgrade-history evidence alongside the tested image reference; do not treat a deployment flag alone as acceptance.\n\n## Official references\n\n[Microsoft Learn: Automatic OS image upgrades with Azure Virtual Machine Scale Sets](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-024-separate-extension-install-time-version-selection-from-ongoing-azure-upgrades/", "slug": "dse-20260909-024-separate-extension-install-time-version-selection-from-ongoing-azure-upgrades", "url": "https://update.dsesecurity.com/updates/dse-20260909-024-separate-extension-install-time-version-selection-from-ongoing-azure-upgrades/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-024-separate-extension-install-time-version-selection-from-ongoing-azure-upgrades.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-024-separate-extension-install-time-version-selection-from-ongoing-azure-upgrades/" }, "title": "Separate extension install-time version selection from ongoing Azure upgrades", "summary": "Why are AutoUpgradeMinorVersion and EnableAutomaticUpgrade separate decisions for an Azure VM extension?", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:32+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 249, "potentially_affected": "Operators configuring supported extensions on Azure virtual machines or virtual machine scale sets.", "dse_recommendation": "Record the creation-time and ongoing-upgrade settings separately for each extension, with an explicit major-version change owner.", "primary_source": { "name": "Automatic Extension Upgrade for VMs and scale sets in Azure - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-extension-upgrade", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "AutoUpgradeMinorVersion selects the latest stable minor extension version during VM creation or a configuration update. EnableAutomaticUpgrade governs later upgrades on existing VMs instead. Neither setting automatically crosses a major-version boundary. Each supported extension is enrolled separately. For a scale set using manual upgrade mode, changing its model does not propagate the setting to existing instances without an instance update. Microsoft Learn.
\nReview the extension’s publisher, type, configured version, and automatic-upgrade support before deciding its policy. Distinguish an individual Azure VM from a scale-set model and its currently deployed instances. Do not use an extension-version decision as the approval for an operating-system image replacement.
\nRecord the creation-time and ongoing-upgrade settings separately for each extension, with an explicit major-version change owner. Ask that owner to explain any pinned minor version and the condition for removing the pin. For manually managed scale sets, add a deliberate instance-update step to the change record rather than stopping after the model edit. Keep exceptions extension-specific instead of assigning one unexplained fleet-wide value.
\nInspect the configured properties and the installed version on a representative existing instance and on an approved newly created instance. Compare both observations with the intended policy. Where a manual scale-set update is needed, confirm propagation on each targeted instance. Preserve failures and version mismatches for investigation; absence of a major-version change is not evidence that the minor-version controls failed.
\nMicrosoft Learn: Automatic Extension Upgrade for VMs and scale sets in Azure. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAutoUpgradeMinorVersion selects the latest stable minor extension version during VM creation or a configuration update. EnableAutomaticUpgrade governs later upgrades on existing VMs instead. Neither setting automatically crosses a major-version boundary. Each supported extension is enrolled separately. For a scale set using manual upgrade mode, changing its model does not propagate the setting to existing instances without an instance update. Microsoft Learn.\nApplicability\nReview the extension’s publisher, type, configured version, and automatic-upgrade support before deciding its policy. Distinguish an individual Azure VM from a scale-set model and its currently deployed instances. Do not use an extension-version decision as the approval for an operating-system image replacement.\nDSE recommendation\nRecord the creation-time and ongoing-upgrade settings separately for each extension, with an explicit major-version change owner. Ask that owner to explain any pinned minor version and the condition for removing the pin. For manually managed scale sets, add a deliberate instance-update step to the change record rather than stopping after the model edit. Keep exceptions extension-specific instead of assigning one unexplained fleet-wide value.\nVerification\nInspect the configured properties and the installed version on a representative existing instance and on an approved newly created instance. Compare both observations with the intended policy. Where a manual scale-set update is needed, confirm propagation on each targeted instance. Preserve failures and version mismatches for investigation; absence of a major-version change is not evidence that the minor-version controls failed.\nOfficial references\nMicrosoft Learn: Automatic Extension Upgrade for VMs and scale sets in Azure. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAutoUpgradeMinorVersion selects the latest stable minor extension version during VM creation or a configuration update. EnableAutomaticUpgrade governs later upgrades on existing VMs instead. Neither setting automatically crosses a major-version boundary. Each supported extension is enrolled separately. For a scale set using manual upgrade mode, changing its model does not propagate the setting to existing instances without an instance update. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-extension-upgrade).\n\n## Applicability\n\nReview the extension’s publisher, type, configured version, and automatic-upgrade support before deciding its policy. Distinguish an individual Azure VM from a scale-set model and its currently deployed instances. Do not use an extension-version decision as the approval for an operating-system image replacement.\n\n## DSE recommendation\n\nRecord the creation-time and ongoing-upgrade settings separately for each extension, with an explicit major-version change owner. Ask that owner to explain any pinned minor version and the condition for removing the pin. For manually managed scale sets, add a deliberate instance-update step to the change record rather than stopping after the model edit. Keep exceptions extension-specific instead of assigning one unexplained fleet-wide value.\n\n## Verification\n\nInspect the configured properties and the installed version on a representative existing instance and on an approved newly created instance. Compare both observations with the intended policy. Where a manual scale-set update is needed, confirm propagation on each targeted instance. Preserve failures and version mismatches for investigation; absence of a major-version change is not evidence that the minor-version controls failed.\n\n## Official references\n\n[Microsoft Learn: Automatic Extension Upgrade for VMs and scale sets in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-extension-upgrade). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-030-include-the-attestation-endpoint-in-trusted-launch-integrity-monitoring-checks/", "slug": "dse-20260909-030-include-the-attestation-endpoint-in-trusted-launch-integrity-monitoring-checks", "url": "https://update.dsesecurity.com/updates/dse-20260909-030-include-the-attestation-endpoint-in-trusted-launch-integrity-monitoring-checks/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-030-include-the-attestation-endpoint-in-trusted-launch-integrity-monitoring-checks.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-030-include-the-attestation-endpoint-in-trusted-launch-integrity-monitoring-checks/" }, "title": "Include the attestation endpoint in Trusted Launch integrity-monitoring checks", "summary": "What should be checked when a Trusted Launch VM's Guest Attestation extension fails behind network controls?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:26+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 252, "potentially_affected": "Azure Trusted Launch VM operators configuring or troubleshooting Guest Attestation.", "dse_recommendation": "Review the attestation communication path before treating an extension-provisioning failure as a boot-integrity finding.", "primary_source": { "name": "Boot integrity monitoring overview - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/boot-integrity-monitoring-overview", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Azure Trusted Launch uses guest attestation through Azure Attestation to monitor the boot sequence. Installing the attestation extensions requires both Secure Boot and vTPM. Microsoft identifies NSG or proxy configuration as a possible cause of Guest Attestation provisioning failure: the extension needs communication with the attestation endpoint. The documented NSG procedure permits outbound access using the AzureAttestation service tag. Microsoft Learn.
\nUse this check for a Trusted Launch VM whose integrity-monitoring deployment or reporting needs investigation. Record its security settings and actual extension status. Distinguish the investigation of an unavailable attestation path from an assessment of the VM’s boot evidence.
\nReview the attestation communication path before treating an extension-provisioning failure as a boot-integrity finding. Ask the network owner to inspect the relevant outbound policy and proxy route. Propose only the narrowly scoped change justified by the documented endpoint requirement. Keep the VM security configuration, extension deployment, and network exception in the same investigation record so one team’s successful change does not close another team’s unresolved check.
\nAfter an approved correction, inspect the Guest Attestation extension’s provisioning result and the corresponding integrity-monitoring status. Confirm that the intended outbound rule applies to the tested VM and that unrelated access was not broadened. Preserve any remaining error message with the tested configuration. Require the responsible security reviewer to interpret the resulting attestation information; a successful network connection alone should not be used as the investigation’s final acceptance criterion.
\nMicrosoft Learn: Boot integrity monitoring overview. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAzure Trusted Launch uses guest attestation through Azure Attestation to monitor the boot sequence. Installing the attestation extensions requires both Secure Boot and vTPM. Microsoft identifies NSG or proxy configuration as a possible cause of Guest Attestation provisioning failure: the extension needs communication with the attestation endpoint. The documented NSG procedure permits outbound access using the AzureAttestation service tag. Microsoft Learn.\nApplicability\nUse this check for a Trusted Launch VM whose integrity-monitoring deployment or reporting needs investigation. Record its security settings and actual extension status. Distinguish the investigation of an unavailable attestation path from an assessment of the VM’s boot evidence.\nDSE recommendation\nReview the attestation communication path before treating an extension-provisioning failure as a boot-integrity finding. Ask the network owner to inspect the relevant outbound policy and proxy route. Propose only the narrowly scoped change justified by the documented endpoint requirement. Keep the VM security configuration, extension deployment, and network exception in the same investigation record so one team’s successful change does not close another team’s unresolved check.\nVerification\nAfter an approved correction, inspect the Guest Attestation extension’s provisioning result and the corresponding integrity-monitoring status. Confirm that the intended outbound rule applies to the tested VM and that unrelated access was not broadened. Preserve any remaining error message with the tested configuration. Require the responsible security reviewer to interpret the resulting attestation information; a successful network connection alone should not be used as the investigation’s final acceptance criterion.\nOfficial references\nMicrosoft Learn: Boot integrity monitoring overview. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAzure Trusted Launch uses guest attestation through Azure Attestation to monitor the boot sequence. Installing the attestation extensions requires both Secure Boot and vTPM. Microsoft identifies NSG or proxy configuration as a possible cause of Guest Attestation provisioning failure: the extension needs communication with the attestation endpoint. The documented NSG procedure permits outbound access using the AzureAttestation service tag. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/boot-integrity-monitoring-overview).\n\n## Applicability\n\nUse this check for a Trusted Launch VM whose integrity-monitoring deployment or reporting needs investigation. Record its security settings and actual extension status. Distinguish the investigation of an unavailable attestation path from an assessment of the VM’s boot evidence.\n\n## DSE recommendation\n\nReview the attestation communication path before treating an extension-provisioning failure as a boot-integrity finding. Ask the network owner to inspect the relevant outbound policy and proxy route. Propose only the narrowly scoped change justified by the documented endpoint requirement. Keep the VM security configuration, extension deployment, and network exception in the same investigation record so one team’s successful change does not close another team’s unresolved check.\n\n## Verification\n\nAfter an approved correction, inspect the Guest Attestation extension’s provisioning result and the corresponding integrity-monitoring status. Confirm that the intended outbound rule applies to the tested VM and that unrelated access was not broadened. Preserve any remaining error message with the tested configuration. Require the responsible security reviewer to interpret the resulting attestation information; a successful network connection alone should not be used as the investigation’s final acceptance criterion.\n\n## Official references\n\n[Microsoft Learn: Boot integrity monitoring overview](https://learn.microsoft.com/en-us/azure/virtual-machines/boot-integrity-monitoring-overview). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-032-reconcile-physical-zones-before-using-a-shared-capacity-reservation/", "slug": "dse-20260909-032-reconcile-physical-zones-before-using-a-shared-capacity-reservation", "url": "https://update.dsesecurity.com/updates/dse-20260909-032-reconcile-physical-zones-before-using-a-shared-capacity-reservation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-032-reconcile-physical-zones-before-using-a-shared-capacity-reservation.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-032-reconcile-physical-zones-before-using-a-shared-capacity-reservation/" }, "title": "Reconcile physical zones before using a shared capacity reservation", "summary": "Why can matching zone numbers in two subscriptions still select different physical locations for shared reserved capacity?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:24+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 236, "potentially_affected": "Teams evaluating preview sharing of zonal Azure capacity reservation groups across subscriptions.", "dse_recommendation": "Build a provider-to-consumer zone mapping for the selected shared reservation before approving a deployment.", "primary_source": { "name": "Share a Capacity Reservation Group in Azure - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-group-share", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Sharing Azure capacity reservation groups across subscriptions is preview. Availability-zone numbers are logical labels with subscription-specific physical mappings, so equal labels need not identify the same location. Microsoft requires zone remapping when deploying through a shared zonal reservation group. The provider and consumer subscriptions each need their own applicable quota. Microsoft Learn.
\nScope the review to a named provider subscription, consumer subscription, region, and shared reservation. Record both subscriptions’ actual zone mappings rather than transplanting the documentation’s illustrative zone numbers. Check the documented sharing permissions and preview limitations before planning an operational trial.
\nBuild a provider-to-consumer zone mapping for the selected shared reservation before approving a deployment. Have both subscription owners review the physical location behind the requested consumer zone and the reservation’s provider-side label. Include independent quota checks in that review. Keep the mapping with the deployment parameters so a later operator does not replace it with an apparently simpler same-number choice.
\nIn an approved preview trial, compare the requested zone, resolved physical mapping, reservation identifier, and resulting VM placement. Ask a second operator to reconstruct the mapping from the retained evidence. Investigate a mismatch before changing unrelated VM settings or requesting more capacity. Record the two subscription identifiers explicitly; a successful deployment from one consumer is not the acceptance result for another consumer’s mapping.
\nMicrosoft Learn: Share a Capacity Reservation Group in Azure. Source reviewed September 9, 2026.
", "content_text": "Source facts\nSharing Azure capacity reservation groups across subscriptions is preview. Availability-zone numbers are logical labels with subscription-specific physical mappings, so equal labels need not identify the same location. Microsoft requires zone remapping when deploying through a shared zonal reservation group. The provider and consumer subscriptions each need their own applicable quota. Microsoft Learn.\nApplicability\nScope the review to a named provider subscription, consumer subscription, region, and shared reservation. Record both subscriptions’ actual zone mappings rather than transplanting the documentation’s illustrative zone numbers. Check the documented sharing permissions and preview limitations before planning an operational trial.\nDSE recommendation\nBuild a provider-to-consumer zone mapping for the selected shared reservation before approving a deployment. Have both subscription owners review the physical location behind the requested consumer zone and the reservation’s provider-side label. Include independent quota checks in that review. Keep the mapping with the deployment parameters so a later operator does not replace it with an apparently simpler same-number choice.\nVerification\nIn an approved preview trial, compare the requested zone, resolved physical mapping, reservation identifier, and resulting VM placement. Ask a second operator to reconstruct the mapping from the retained evidence. Investigate a mismatch before changing unrelated VM settings or requesting more capacity. Record the two subscription identifiers explicitly; a successful deployment from one consumer is not the acceptance result for another consumer’s mapping.\nOfficial references\nMicrosoft Learn: Share a Capacity Reservation Group in Azure. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nSharing Azure capacity reservation groups across subscriptions is preview. Availability-zone numbers are logical labels with subscription-specific physical mappings, so equal labels need not identify the same location. Microsoft requires zone remapping when deploying through a shared zonal reservation group. The provider and consumer subscriptions each need their own applicable quota. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-group-share).\n\n## Applicability\n\nScope the review to a named provider subscription, consumer subscription, region, and shared reservation. Record both subscriptions’ actual zone mappings rather than transplanting the documentation’s illustrative zone numbers. Check the documented sharing permissions and preview limitations before planning an operational trial.\n\n## DSE recommendation\n\nBuild a provider-to-consumer zone mapping for the selected shared reservation before approving a deployment. Have both subscription owners review the physical location behind the requested consumer zone and the reservation’s provider-side label. Include independent quota checks in that review. Keep the mapping with the deployment parameters so a later operator does not replace it with an apparently simpler same-number choice.\n\n## Verification\n\nIn an approved preview trial, compare the requested zone, resolved physical mapping, reservation identifier, and resulting VM placement. Ask a second operator to reconstruct the mapping from the retained evidence. Investigate a mismatch before changing unrelated VM settings or requesting more capacity. Record the two subscription identifiers explicitly; a successful deployment from one consumer is not the acceptance result for another consumer’s mapping.\n\n## Official references\n\n[Microsoft Learn: Share a Capacity Reservation Group in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-group-share). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved/", "slug": "dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved", "url": "https://update.dsesecurity.com/updates/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-035-treat-proximity-placement-intent-as-a-compatibility-constraint-not-reserved/" }, "title": "Treat proximity-placement intent as a compatibility constraint, not reserved capacity", "summary": "What does a proximity placement group's VM-size intent establish before deployment, and what remains unguaranteed?", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:21+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 266, "potentially_affected": "Teams placing Azure VMs of multiple sizes in a proximity placement group.", "dse_recommendation": "Declare the workload's complete intended VM-size combination and keep a separate plan for allocation failure.", "primary_source": { "name": "Proximity placement groups - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/co-location", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A proximity placement group constrains Azure compute resources to nearby physical placement. Its optional intent lists expected VM sizes so Azure can select a datacenter supporting their combination. Intent neither reserves capacity nor guarantees allocation; deployment can still fail if capacity is exhausted. Changing an existing group’s intent requires all its VMs to be deallocated; intent needs API version 2021-11-01 or later. A zone can accompany intent only at group creation, and that zone choice cannot later be changed. Microsoft Learn.
\nUse this design check when a workload requires proximity across several VM sizes. Ask the application owner to justify that requirement with its own measurements. Identify the full size combination and any intended zone before approving the placement-group definition.
\nDeclare the workload’s complete intended VM-size combination and keep a separate plan for allocation failure. Review an existing group’s intent before introducing a new size or redeploying a removed tier. Have the capacity and application owners agree on an acceptable alternate configuration rather than assuming that successful group creation proves the future deployment will fit. Record the zone choice as a deliberate design decision.
\nDeploy the agreed combination in an approved test and compare the actual resources with the declared intent. Capture any allocation error together with the group definition and requested sizes. Measure the application’s relevant latency rather than accepting proximity configuration as a measured outcome. Before a later size change, repeat the compatibility review and preserve the previous intent so the change can be explained and investigated.
\nMicrosoft Learn: Proximity placement groups. Source reviewed September 9, 2026.
", "content_text": "Source facts\nA proximity placement group constrains Azure compute resources to nearby physical placement. Its optional intent lists expected VM sizes so Azure can select a datacenter supporting their combination. Intent neither reserves capacity nor guarantees allocation; deployment can still fail if capacity is exhausted. Changing an existing group’s intent requires all its VMs to be deallocated; intent needs API version 2021-11-01 or later. A zone can accompany intent only at group creation, and that zone choice cannot later be changed. Microsoft Learn.\nApplicability\nUse this design check when a workload requires proximity across several VM sizes. Ask the application owner to justify that requirement with its own measurements. Identify the full size combination and any intended zone before approving the placement-group definition.\nDSE recommendation\nDeclare the workload’s complete intended VM-size combination and keep a separate plan for allocation failure. Review an existing group’s intent before introducing a new size or redeploying a removed tier. Have the capacity and application owners agree on an acceptable alternate configuration rather than assuming that successful group creation proves the future deployment will fit. Record the zone choice as a deliberate design decision.\nVerification\nDeploy the agreed combination in an approved test and compare the actual resources with the declared intent. Capture any allocation error together with the group definition and requested sizes. Measure the application’s relevant latency rather than accepting proximity configuration as a measured outcome. Before a later size change, repeat the compatibility review and preserve the previous intent so the change can be explained and investigated.\nOfficial references\nMicrosoft Learn: Proximity placement groups. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nA proximity placement group constrains Azure compute resources to nearby physical placement. Its optional intent lists expected VM sizes so Azure can select a datacenter supporting their combination. Intent neither reserves capacity nor guarantees allocation; deployment can still fail if capacity is exhausted. Changing an existing group’s intent requires all its VMs to be deallocated; intent needs API version 2021-11-01 or later. A zone can accompany intent only at group creation, and that zone choice cannot later be changed. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/co-location).\n\n## Applicability\n\nUse this design check when a workload requires proximity across several VM sizes. Ask the application owner to justify that requirement with its own measurements. Identify the full size combination and any intended zone before approving the placement-group definition.\n\n## DSE recommendation\n\nDeclare the workload’s complete intended VM-size combination and keep a separate plan for allocation failure. Review an existing group’s intent before introducing a new size or redeploying a removed tier. Have the capacity and application owners agree on an acceptable alternate configuration rather than assuming that successful group creation proves the future deployment will fit. Record the zone choice as a deliberate design decision.\n\n## Verification\n\nDeploy the agreed combination in an approved test and compare the actual resources with the declared intent. Capture any allocation error together with the group definition and requested sizes. Measure the application’s relevant latency rather than accepting proximity configuration as a measured outcome. Before a later size change, repeat the compatibility review and preserve the previous intent so the change can be explained and investigated.\n\n## Official references\n\n[Microsoft Learn: Proximity placement groups](https://learn.microsoft.com/en-us/azure/virtual-machines/co-location). Source reviewed September 9, 2026." } ] }