A private Secrets Manager connection still needs an endpoint access policy that matches the intended callers and secrets.
\nSecrets Manager supports interface VPC endpoints through AWS PrivateLink. With private DNS enabled, applications can use the Region’s normal Secrets Manager hostname through the endpoint. AWS documents a default endpoint policy allowing full Secrets Manager access through that endpoint and allows a custom policy specifying principals, actions and resources. Endpoint routing and endpoint-policy scope are therefore separate configuration choices.
\nSource: AWS — Using an AWS Secrets Manager VPC endpoint.
\nThis concerns the Secrets Manager interface endpoint. Review endpoint access policies for application and Lambda rotation callers.
\nDSE recommends mapping each application and rotation function that should use the endpoint. Define a narrow endpoint policy using the required actions and secret identifiers, then review it alongside the rest of the access design. Check DNS behavior from the actual workload network. Preserve an approved administrative recovery path before enforcing conditions that could exclude legitimate service calls. Require the network and secret owners to approve the same workload-to-secret access matrix. Keep an endpoint-specific denial in the test plan and identify the recovery contact before tightening policy, so a connectivity incident does not prompt an unreviewed full-access exception.
\nProposed verification: from an authorized test workload, resolve the regional hostname and inspect the selected endpoint path. Verify retrieval of a permitted test secret and rejection of a secret outside the intended scope. Exercise rotation dependencies separately, retaining metadata and access outcomes while keeping secret values out of the evidence.
\nAWS — Using an AWS Secrets Manager VPC endpoint. Reviewed October 20, 2026.
", "content_text": "A private Secrets Manager connection still needs an endpoint access policy that matches the intended callers and secrets.\nSource facts\nSecrets Manager supports interface VPC endpoints through AWS PrivateLink. With private DNS enabled, applications can use the Region’s normal Secrets Manager hostname through the endpoint. AWS documents a default endpoint policy allowing full Secrets Manager access through that endpoint and allows a custom policy specifying principals, actions and resources. Endpoint routing and endpoint-policy scope are therefore separate configuration choices.\nSource: AWS — Using an AWS Secrets Manager VPC endpoint.\nApplicability\nThis concerns the Secrets Manager interface endpoint. Review endpoint access policies for application and Lambda rotation callers.\nDSE recommendation\nDSE recommends mapping each application and rotation function that should use the endpoint. Define a narrow endpoint policy using the required actions and secret identifiers, then review it alongside the rest of the access design. Check DNS behavior from the actual workload network. Preserve an approved administrative recovery path before enforcing conditions that could exclude legitimate service calls. Require the network and secret owners to approve the same workload-to-secret access matrix. Keep an endpoint-specific denial in the test plan and identify the recovery contact before tightening policy, so a connectivity incident does not prompt an unreviewed full-access exception.\nVerification\nProposed verification: from an authorized test workload, resolve the regional hostname and inspect the selected endpoint path. Verify retrieval of a permitted test secret and rejection of a secret outside the intended scope. Exercise rotation dependencies separately, retaining metadata and access outcomes while keeping secret values out of the evidence.\nOfficial reference\nAWS — Using an AWS Secrets Manager VPC endpoint. Reviewed October 20, 2026.", "content_markdown": "A private Secrets Manager connection still needs an endpoint access policy that matches the intended callers and secrets.\n\n## Source facts\n\nSecrets Manager supports interface VPC endpoints through AWS PrivateLink. With private DNS enabled, applications can use the Region’s normal Secrets Manager hostname through the endpoint. AWS documents a default endpoint policy allowing full Secrets Manager access through that endpoint and allows a custom policy specifying principals, actions and resources. Endpoint routing and endpoint-policy scope are therefore separate configuration choices.\n\nSource: [AWS — Using an AWS Secrets Manager VPC endpoint](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html).\n\n## Applicability\n\nThis concerns the Secrets Manager interface endpoint. Review endpoint access policies for application and Lambda rotation callers.\n\n## DSE recommendation\n\nDSE recommends mapping each application and rotation function that should use the endpoint. Define a narrow endpoint policy using the required actions and secret identifiers, then review it alongside the rest of the access design. Check DNS behavior from the actual workload network. Preserve an approved administrative recovery path before enforcing conditions that could exclude legitimate service calls. Require the network and secret owners to approve the same workload-to-secret access matrix. Keep an endpoint-specific denial in the test plan and identify the recovery contact before tightening policy, so a connectivity incident does not prompt an unreviewed full-access exception.\n\n## Verification\n\nProposed verification: from an authorized test workload, resolve the regional hostname and inspect the selected endpoint path. Verify retrieval of a permitted test secret and rejection of a secret outside the intended scope. Exercise rotation dependencies separately, retaining metadata and access outcomes while keeping secret values out of the evidence.\n\n## Official reference\n\n[AWS — Using an AWS Secrets Manager VPC endpoint](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-secrets-manager-block-public-policy-review-boundary/", "slug": "aws-secrets-manager-block-public-policy-review-boundary", "url": "https://update.dsesecurity.com/updates/aws-secrets-manager-block-public-policy-review-boundary/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-secrets-manager-block-public-policy-review-boundary.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-secrets-manager-block-public-policy-review-boundary/" }, "title": "Review IAM and key policies alongside Secrets Manager public-policy checks", "summary": "A resource-policy validation result covers one access path rather than every permission affecting a secret.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:17+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 270, "potentially_affected": "This concerns Secrets Manager resource-based policy validation. It does not assert that a particular policy combination is safe, or replace reviewing the actual principals, actions and encryption-key access.", "dse_recommendation": "DSE recommends listing intended readers and administrators before writing the secret policy.", "primary_source": { "name": "AWS — Resource-based policies", "url": "https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 resource-policy validation result covers one access path rather than every permission affecting a secret.
\nSecrets Manager validates resource policies attached in its console and offers BlockPublicPolicy for API or CLI use. AWS says these checks help prevent public access through policies directly attached to the secret. It also instructs administrators to inspect associated identity policies and resource policies on related resources, including KMS keys. An attached-policy check is therefore not a complete effective-access review.
\nSource: AWS — Resource-based policies.
\nThis concerns Secrets Manager resource-based policy validation. It does not assert that a particular policy combination is safe, or replace reviewing the actual principals, actions and encryption-key access.
\nDSE recommends listing intended readers and administrators before writing the secret policy. Review the secret’s policy, relevant role policies and key permissions as one access path. Keep cross-account grants explicit and preserve the previous policy for an approved rollback. Use validation as an additional gate while retaining a human review of the complete intended access boundary. Have a reviewer trace one intended reader through all relevant permission layers and explain the expected deny case. Preserve that access matrix with the validation result so future reviewers understand the intended boundary instead of treating a passed policy check as the entire approval.
\nProposed verification: in an approved test setup, validate the proposed resource policy and compare access for an intended role and an unapproved role. Record the evaluated secret and key identifiers without revealing values. Retain effective-policy findings and explain any denied request before broadening a policy to make it succeed.
\nAWS — Resource-based policies. Reviewed October 20, 2026.
", "content_text": "A resource-policy validation result covers one access path rather than every permission affecting a secret.\nSource facts\nSecrets Manager validates resource policies attached in its console and offers BlockPublicPolicy for API or CLI use. AWS says these checks help prevent public access through policies directly attached to the secret. It also instructs administrators to inspect associated identity policies and resource policies on related resources, including KMS keys. An attached-policy check is therefore not a complete effective-access review.\nSource: AWS — Resource-based policies.\nApplicability\nThis concerns Secrets Manager resource-based policy validation. It does not assert that a particular policy combination is safe, or replace reviewing the actual principals, actions and encryption-key access.\nDSE recommendation\nDSE recommends listing intended readers and administrators before writing the secret policy. Review the secret’s policy, relevant role policies and key permissions as one access path. Keep cross-account grants explicit and preserve the previous policy for an approved rollback. Use validation as an additional gate while retaining a human review of the complete intended access boundary. Have a reviewer trace one intended reader through all relevant permission layers and explain the expected deny case. Preserve that access matrix with the validation result so future reviewers understand the intended boundary instead of treating a passed policy check as the entire approval.\nVerification\nProposed verification: in an approved test setup, validate the proposed resource policy and compare access for an intended role and an unapproved role. Record the evaluated secret and key identifiers without revealing values. Retain effective-policy findings and explain any denied request before broadening a policy to make it succeed.\nOfficial reference\nAWS — Resource-based policies. Reviewed October 20, 2026.", "content_markdown": "A resource-policy validation result covers one access path rather than every permission affecting a secret.\n\n## Source facts\n\nSecrets Manager validates resource policies attached in its console and offers BlockPublicPolicy for API or CLI use. AWS says these checks help prevent public access through policies directly attached to the secret. It also instructs administrators to inspect associated identity policies and resource policies on related resources, including KMS keys. An attached-policy check is therefore not a complete effective-access review.\n\nSource: [AWS — Resource-based policies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html).\n\n## Applicability\n\nThis concerns Secrets Manager resource-based policy validation. It does not assert that a particular policy combination is safe, or replace reviewing the actual principals, actions and encryption-key access.\n\n## DSE recommendation\n\nDSE recommends listing intended readers and administrators before writing the secret policy. Review the secret’s policy, relevant role policies and key permissions as one access path. Keep cross-account grants explicit and preserve the previous policy for an approved rollback. Use validation as an additional gate while retaining a human review of the complete intended access boundary. Have a reviewer trace one intended reader through all relevant permission layers and explain the expected deny case. Preserve that access matrix with the validation result so future reviewers understand the intended boundary instead of treating a passed policy check as the entire approval.\n\n## Verification\n\nProposed verification: in an approved test setup, validate the proposed resource policy and compare access for an intended role and an unapproved role. Record the evaluated secret and key identifiers without revealing values. Retain effective-policy findings and explain any denied request before broadening a policy to make it succeed.\n\n## Official reference\n\n[AWS — Resource-based policies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-secrets-manager-rotation-window-utc-not-exact-time/", "slug": "aws-secrets-manager-rotation-window-utc-not-exact-time", "url": "https://update.dsesecurity.com/updates/aws-secrets-manager-rotation-window-utc-not-exact-time/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-secrets-manager-rotation-window-utc-not-exact-time.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-secrets-manager-rotation-window-utc-not-exact-time/" }, "title": "Translate Secrets Manager rotation windows into the operations team’s local time", "summary": "A rotation window permits execution within an interval and uses UTC rather than the operator’s local timezone.", "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": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:16+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 267, "potentially_affected": "This describes Secrets Manager scheduling. It does not identify an exact credential-change minute or prove an application is ready to handle a rotation during that interval.", "dse_recommendation": "DSE recommends recording both UTC and the relevant local maintenance interval in the credential change plan.", "primary_source": { "name": "AWS — Rotation schedules", "url": "https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 rotation window permits execution within an interval and uses UTC rather than the operator’s local timezone.
\nSecrets Manager rotation schedules use UTC. AWS states that rotation occurs at some time during the configured window, whose start is always on the hour. Cron expressions can set its start time. The configured window must not extend into the next rotation window. AWS documents hour-based and day-based schedules with different default window lengths.
\nSource: AWS — Rotation schedules.
\nThis describes Secrets Manager scheduling. It does not identify an exact credential-change minute or prove an application is ready to handle a rotation during that interval.
\nDSE recommends recording both UTC and the relevant local maintenance interval in the credential change plan. Review seasonal clock changes with the application owner if local staffing or business hours are important. Check the entire possible execution interval against maintenance, release and support coverage. Assign an escalation owner for rotation failures and avoid scheduling downstream work around an assumed exact start minute. Put the complete possible window in the maintenance calendar rather than a single appointment time. Ask the on-call owner to confirm coverage across that interval and record how the team will interpret UTC event timestamps during a rotation investigation.
\nProposed verification: inspect the saved expression, window duration and next expected interval. In an authorized test secret, compare observed rotation events with the approved window. Confirm monitoring and the operator runbook display time references clearly, and test the application’s credential refresh without treating one execution time as a future guarantee.
\nAWS — Rotation schedules. Reviewed October 20, 2026.
", "content_text": "A rotation window permits execution within an interval and uses UTC rather than the operator’s local timezone.\nSource facts\nSecrets Manager rotation schedules use UTC. AWS states that rotation occurs at some time during the configured window, whose start is always on the hour. Cron expressions can set its start time. The configured window must not extend into the next rotation window. AWS documents hour-based and day-based schedules with different default window lengths.\nSource: AWS — Rotation schedules.\nApplicability\nThis describes Secrets Manager scheduling. It does not identify an exact credential-change minute or prove an application is ready to handle a rotation during that interval.\nDSE recommendation\nDSE recommends recording both UTC and the relevant local maintenance interval in the credential change plan. Review seasonal clock changes with the application owner if local staffing or business hours are important. Check the entire possible execution interval against maintenance, release and support coverage. Assign an escalation owner for rotation failures and avoid scheduling downstream work around an assumed exact start minute. Put the complete possible window in the maintenance calendar rather than a single appointment time. Ask the on-call owner to confirm coverage across that interval and record how the team will interpret UTC event timestamps during a rotation investigation.\nVerification\nProposed verification: inspect the saved expression, window duration and next expected interval. In an authorized test secret, compare observed rotation events with the approved window. Confirm monitoring and the operator runbook display time references clearly, and test the application’s credential refresh without treating one execution time as a future guarantee.\nOfficial reference\nAWS — Rotation schedules. Reviewed October 20, 2026.", "content_markdown": "A rotation window permits execution within an interval and uses UTC rather than the operator’s local timezone.\n\n## Source facts\n\nSecrets Manager rotation schedules use UTC. AWS states that rotation occurs at some time during the configured window, whose start is always on the hour. Cron expressions can set its start time. The configured window must not extend into the next rotation window. AWS documents hour-based and day-based schedules with different default window lengths.\n\nSource: [AWS — Rotation schedules](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html).\n\n## Applicability\n\nThis describes Secrets Manager scheduling. It does not identify an exact credential-change minute or prove an application is ready to handle a rotation during that interval.\n\n## DSE recommendation\n\nDSE recommends recording both UTC and the relevant local maintenance interval in the credential change plan. Review seasonal clock changes with the application owner if local staffing or business hours are important. Check the entire possible execution interval against maintenance, release and support coverage. Assign an escalation owner for rotation failures and avoid scheduling downstream work around an assumed exact start minute. Put the complete possible window in the maintenance calendar rather than a single appointment time. Ask the on-call owner to confirm coverage across that interval and record how the team will interpret UTC event timestamps during a rotation investigation.\n\n## Verification\n\nProposed verification: inspect the saved expression, window duration and next expected interval. In an authorized test secret, compare observed rotation events with the approved window. Confirm monitoring and the operator runbook display time references clearly, and test the application’s credential refresh without treating one execution time as a future guarantee.\n\n## Official reference\n\n[AWS — Rotation schedules](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-secrets-manager-alternating-user-permission-drift/", "slug": "aws-secrets-manager-alternating-user-permission-drift", "url": "https://update.dsesecurity.com/updates/aws-secrets-manager-alternating-user-permission-drift/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-secrets-manager-alternating-user-permission-drift.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-secrets-manager-alternating-user-permission-drift/" }, "title": "Keep permissions aligned for alternating Secrets Manager database users", "summary": "Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:15+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 277, "potentially_affected": "This concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.", "dse_recommendation": "DSE recommends reviewing the database’s ownership and permission model before selecting alternating users.", "primary_source": { "name": "AWS — Lambda function rotation strategies", "url": "https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-strategy.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.
\nFor Lambda-based database rotation, Secrets Manager supports single-user and alternating-user strategies. The alternating strategy creates a clone and switches which user’s password is updated. It needs privileged credentials in a separate secret. AWS states that later permission changes to the original user must also be made to the clone. AWS recommends single-user rotation where cloned users do not have equivalent permissions.
\nSource: AWS — Lambda function rotation strategies.
\nThis concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.
\nDSE recommends reviewing the database’s ownership and permission model before selecting alternating users. Put both user identities in the access review and link permission changes to both when that strategy is used. Identify the owner of the privileged rotation secret and keep application permissions separate from rotation permissions. Plan retry and recovery behavior with the application owner rather than assuming the rotation strategy eliminates every interruption. Keep the clone identity in the database permission-change checklist after the first rotation. Require the owner to explain how a later grant or revocation will be applied and verified for both users before selecting this strategy for a long-lived application.
\nProposed verification: in a permitted test database, inspect both users’ effective privileges and run representative allowed and denied operations after rotation. Apply an approved permission change and confirm the intended alignment. Retain identity names and outcomes, with no passwords or secret values in the evidence record.
\nAWS — Lambda function rotation strategies. Reviewed October 20, 2026.
", "content_text": "Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.\nSource facts\nFor Lambda-based database rotation, Secrets Manager supports single-user and alternating-user strategies. The alternating strategy creates a clone and switches which user’s password is updated. It needs privileged credentials in a separate secret. AWS states that later permission changes to the original user must also be made to the clone. AWS recommends single-user rotation where cloned users do not have equivalent permissions.\nSource: AWS — Lambda function rotation strategies.\nApplicability\nThis concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.\nDSE recommendation\nDSE recommends reviewing the database’s ownership and permission model before selecting alternating users. Put both user identities in the access review and link permission changes to both when that strategy is used. Identify the owner of the privileged rotation secret and keep application permissions separate from rotation permissions. Plan retry and recovery behavior with the application owner rather than assuming the rotation strategy eliminates every interruption. Keep the clone identity in the database permission-change checklist after the first rotation. Require the owner to explain how a later grant or revocation will be applied and verified for both users before selecting this strategy for a long-lived application.\nVerification\nProposed verification: in a permitted test database, inspect both users’ effective privileges and run representative allowed and denied operations after rotation. Apply an approved permission change and confirm the intended alignment. Retain identity names and outcomes, with no passwords or secret values in the evidence record.\nOfficial reference\nAWS — Lambda function rotation strategies. Reviewed October 20, 2026.", "content_markdown": "Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.\n\n## Source facts\n\nFor Lambda-based database rotation, Secrets Manager supports single-user and alternating-user strategies. The alternating strategy creates a clone and switches which user’s password is updated. It needs privileged credentials in a separate secret. AWS states that later permission changes to the original user must also be made to the clone. AWS recommends single-user rotation where cloned users do not have equivalent permissions.\n\nSource: [AWS — Lambda function rotation strategies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-strategy.html).\n\n## Applicability\n\nThis concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.\n\n## DSE recommendation\n\nDSE recommends reviewing the database’s ownership and permission model before selecting alternating users. Put both user identities in the access review and link permission changes to both when that strategy is used. Identify the owner of the privileged rotation secret and keep application permissions separate from rotation permissions. Plan retry and recovery behavior with the application owner rather than assuming the rotation strategy eliminates every interruption. Keep the clone identity in the database permission-change checklist after the first rotation. Require the owner to explain how a later grant or revocation will be applied and verified for both users before selecting this strategy for a long-lived application.\n\n## Verification\n\nProposed verification: in a permitted test database, inspect both users’ effective privileges and run representative allowed and denied operations after rotation. Apply an approved permission change and confirm the intended alignment. Retain identity names and outcomes, with no passwords or secret values in the evidence record.\n\n## Official reference\n\n[AWS — Lambda function rotation strategies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-strategy.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-secrets-manager-replica-database-connection-endpoint/", "slug": "aws-secrets-manager-replica-database-connection-endpoint", "url": "https://update.dsesecurity.com/updates/aws-secrets-manager-replica-database-connection-endpoint/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-secrets-manager-replica-database-connection-endpoint.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-secrets-manager-replica-database-connection-endpoint/" }, "title": "Check the database endpoint inside a replicated Secrets Manager secret", "summary": "A secret replica can be local to a Region while still naming the original database endpoint.", "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": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:14+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 275, "potentially_affected": "This concerns Secrets Manager regional replication. It does not create or fail over a database, rewrite application routing or guarantee that the credentials work against every regional database.", "dse_recommendation": "DSE recommends documenting the intended relationship among the secret Region, application Region and actual database endpoint.", "primary_source": { "name": "AWS — Replicate AWS Secrets Manager secrets across Regions", "url": "https://docs.aws.amazon.com/secretsmanager/latest/userguide/replicate-secrets.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 secret replica can be local to a Region while still naming the original database endpoint.
\nSecrets Manager replicates encrypted secret data and metadata across selected Regions. AWS warns that a replicated database secret contains the same source-database connection information as the original; replication does not substitute a local database endpoint. Additional key-value pairs can hold regional connection information. When rotation is enabled on the primary secret, updated values propagate to its associated replicas.
\nSource: AWS — Replicate AWS Secrets Manager secrets across Regions.
\nThis concerns Secrets Manager regional replication. It does not create or fail over a database, rewrite application routing or guarantee that the credentials work against every regional database.
\nDSE recommends documenting the intended relationship among the secret Region, application Region and actual database endpoint. Review connection fields during disaster-recovery planning instead of treating a local secret lookup as evidence of local data access. Define who manages regional connection metadata and how applications choose it. Include replica state and primary rotation ownership in the credential handoff. Include the connection destination as an explicit recovery acceptance item for each consuming application. Ask the database and application owners to approve the same regional mapping, with a separate decision for credential propagation and for the endpoint the application will actually use.
\nProposed verification: from an authorized test application in each intended Region, inspect nonsecret connection metadata and verify the actual database destination. Test authentication against the approved endpoint after a controlled rotation. Confirm the recovery runbook distinguishes reading a replica from switching the application to a recovered database.
\nAWS — Replicate AWS Secrets Manager secrets across Regions. Reviewed October 20, 2026.
", "content_text": "A secret replica can be local to a Region while still naming the original database endpoint.\nSource facts\nSecrets Manager replicates encrypted secret data and metadata across selected Regions. AWS warns that a replicated database secret contains the same source-database connection information as the original; replication does not substitute a local database endpoint. Additional key-value pairs can hold regional connection information. When rotation is enabled on the primary secret, updated values propagate to its associated replicas.\nSource: AWS — Replicate AWS Secrets Manager secrets across Regions.\nApplicability\nThis concerns Secrets Manager regional replication. It does not create or fail over a database, rewrite application routing or guarantee that the credentials work against every regional database.\nDSE recommendation\nDSE recommends documenting the intended relationship among the secret Region, application Region and actual database endpoint. Review connection fields during disaster-recovery planning instead of treating a local secret lookup as evidence of local data access. Define who manages regional connection metadata and how applications choose it. Include replica state and primary rotation ownership in the credential handoff. Include the connection destination as an explicit recovery acceptance item for each consuming application. Ask the database and application owners to approve the same regional mapping, with a separate decision for credential propagation and for the endpoint the application will actually use.\nVerification\nProposed verification: from an authorized test application in each intended Region, inspect nonsecret connection metadata and verify the actual database destination. Test authentication against the approved endpoint after a controlled rotation. Confirm the recovery runbook distinguishes reading a replica from switching the application to a recovered database.\nOfficial reference\nAWS — Replicate AWS Secrets Manager secrets across Regions. Reviewed October 20, 2026.", "content_markdown": "A secret replica can be local to a Region while still naming the original database endpoint.\n\n## Source facts\n\nSecrets Manager replicates encrypted secret data and metadata across selected Regions. AWS warns that a replicated database secret contains the same source-database connection information as the original; replication does not substitute a local database endpoint. Additional key-value pairs can hold regional connection information. When rotation is enabled on the primary secret, updated values propagate to its associated replicas.\n\nSource: [AWS — Replicate AWS Secrets Manager secrets across Regions](https://docs.aws.amazon.com/secretsmanager/latest/userguide/replicate-secrets.html).\n\n## Applicability\n\nThis concerns Secrets Manager regional replication. It does not create or fail over a database, rewrite application routing or guarantee that the credentials work against every regional database.\n\n## DSE recommendation\n\nDSE recommends documenting the intended relationship among the secret Region, application Region and actual database endpoint. Review connection fields during disaster-recovery planning instead of treating a local secret lookup as evidence of local data access. Define who manages regional connection metadata and how applications choose it. Include replica state and primary rotation ownership in the credential handoff. Include the connection destination as an explicit recovery acceptance item for each consuming application. Ask the database and application owners to approve the same regional mapping, with a separate decision for credential propagation and for the endpoint the application will actually use.\n\n## Verification\n\nProposed verification: from an authorized test application in each intended Region, inspect nonsecret connection metadata and verify the actual database destination. Test authentication against the approved endpoint after a controlled rotation. Confirm the recovery runbook distinguishes reading a replica from switching the application to a recovered database.\n\n## Official reference\n\n[AWS — Replicate AWS Secrets Manager secrets across Regions](https://docs.aws.amazon.com/secretsmanager/latest/userguide/replicate-secrets.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-secrets-manager-version-staging-label-current-previous/", "slug": "aws-secrets-manager-version-staging-label-current-previous", "url": "https://update.dsesecurity.com/updates/aws-secrets-manager-version-staging-label-current-previous/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-secrets-manager-version-staging-label-current-previous.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-secrets-manager-version-staging-label-current-previous/" }, "title": "Identify Secrets Manager versions by staging labels rather than a presumed history order", "summary": "A secret’s current value is selected through a staging label, not by assuming every stored version forms an archive.", "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": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:13+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 286, "potentially_affected": "This concerns Secrets Manager value versions and labels. A secret version is not an independent database account state, and moving a label does not by itself establish credential validity in the target service.", "dse_recommendation": "DSE recommends recording the version identifier and label mapping during rotation investigations without recording plaintext credentials.", "primary_source": { "name": "AWS — What's in a Secrets Manager secret?", "url": "https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 secret’s current value is selected through a staging label, not by assuming every stored version forms an archive.
\nSecrets Manager creates a new version when a secret value changes or rotates. AWS labels the current, previous and pending versions AWSCURRENT, AWSPREVIOUS and AWSPENDING. A normal value retrieval returns AWSCURRENT by default. Staging labels cannot be shared by two versions. Labeled versions are retained, while unlabeled versions are deprecated and can be removed under the documented cleanup rules.
\nSource: AWS — What’s in a Secrets Manager secret?.
\nThis concerns Secrets Manager value versions and labels. A secret version is not an independent database account state, and moving a label does not by itself establish credential validity in the target service.
\nDSE recommends recording the version identifier and label mapping during rotation investigations without recording plaintext credentials. Decide which consumers intentionally request a specific version and which use the current label. Keep any proposed label change linked to verification of the underlying service credential. Do not rely on unlabeled versions as the organization’s permanent history or recovery archive. Define who may approve a staging-label move during an incident and how the receiving application will be checked. Keep the version metadata separate from the usable value, and document any deliberate retained label instead of relying on unlabelled versions as an informal archive.
\nProposed verification: use a permitted test secret to inspect version identifiers and staging labels before and after a controlled update. Confirm the value-retrieval path selects the intended version through a harmless test comparison. Check application authentication separately, and retain only metadata and test outcomes in the operational record.
\nAWS — What’s in a Secrets Manager secret?. Reviewed October 20, 2026.
", "content_text": "A secret’s current value is selected through a staging label, not by assuming every stored version forms an archive.\nSource facts\nSecrets Manager creates a new version when a secret value changes or rotates. AWS labels the current, previous and pending versions AWSCURRENT, AWSPREVIOUS and AWSPENDING. A normal value retrieval returns AWSCURRENT by default. Staging labels cannot be shared by two versions. Labeled versions are retained, while unlabeled versions are deprecated and can be removed under the documented cleanup rules.\nSource: AWS — What’s in a Secrets Manager secret?.\nApplicability\nThis concerns Secrets Manager value versions and labels. A secret version is not an independent database account state, and moving a label does not by itself establish credential validity in the target service.\nDSE recommendation\nDSE recommends recording the version identifier and label mapping during rotation investigations without recording plaintext credentials. Decide which consumers intentionally request a specific version and which use the current label. Keep any proposed label change linked to verification of the underlying service credential. Do not rely on unlabeled versions as the organization’s permanent history or recovery archive. Define who may approve a staging-label move during an incident and how the receiving application will be checked. Keep the version metadata separate from the usable value, and document any deliberate retained label instead of relying on unlabelled versions as an informal archive.\nVerification\nProposed verification: use a permitted test secret to inspect version identifiers and staging labels before and after a controlled update. Confirm the value-retrieval path selects the intended version through a harmless test comparison. Check application authentication separately, and retain only metadata and test outcomes in the operational record.\nOfficial reference\nAWS — What’s in a Secrets Manager secret?. Reviewed October 20, 2026.", "content_markdown": "A secret’s current value is selected through a staging label, not by assuming every stored version forms an archive.\n\n## Source facts\n\nSecrets Manager creates a new version when a secret value changes or rotates. AWS labels the current, previous and pending versions AWSCURRENT, AWSPREVIOUS and AWSPENDING. A normal value retrieval returns AWSCURRENT by default. Staging labels cannot be shared by two versions. Labeled versions are retained, while unlabeled versions are deprecated and can be removed under the documented cleanup rules.\n\nSource: [AWS — What’s in a Secrets Manager secret?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html).\n\n## Applicability\n\nThis concerns Secrets Manager value versions and labels. A secret version is not an independent database account state, and moving a label does not by itself establish credential validity in the target service.\n\n## DSE recommendation\n\nDSE recommends recording the version identifier and label mapping during rotation investigations without recording plaintext credentials. Decide which consumers intentionally request a specific version and which use the current label. Keep any proposed label change linked to verification of the underlying service credential. Do not rely on unlabeled versions as the organization’s permanent history or recovery archive. Define who may approve a staging-label move during an incident and how the receiving application will be checked. Keep the version metadata separate from the usable value, and document any deliberate retained label instead of relying on unlabelled versions as an informal archive.\n\n## Verification\n\nProposed verification: use a permitted test secret to inspect version identifiers and staging labels before and after a controlled update. Confirm the value-retrieval path selects the intended version through a harmless test comparison. Check application authentication separately, and retain only metadata and test outcomes in the operational record.\n\n## Official reference\n\n[AWS — What’s in a Secrets Manager secret?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/whats-in-a-secret.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-restore-missing-operational-settings/", "slug": "aws-dynamodb-pitr-restore-missing-operational-settings", "url": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-restore-missing-operational-settings/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-restore-missing-operational-settings.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-dynamodb-pitr-restore-missing-operational-settings/" }, "title": "Rebuild the DynamoDB settings that a point-in-time restore does not carry over", "summary": "A newly restored table needs more than recovered items before it is ready for application traffic.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:12+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 286, "potentially_affected": "This concerns the documented DynamoDB point-in-time restore workflow. Restored data and indexes are not evidence that application routing, event processing or retention behavior is ready.", "dse_recommendation": "DSE recommends preparing a post-restore configuration checklist before an incident.", "primary_source": { "name": "AWS — Restoring a DynamoDB table to a point in time", "url": "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 newly restored table needs more than recovered items before it is ready for application traffic.
\nDynamoDB point-in-time recovery restores to a new table while the source remains available. AWS lists operational settings that must be set up again after restoration, including auto scaling policies, IAM policies, CloudWatch alarms, tags, Streams, Time to Live and PITR settings. Restore duration depends on data volume and rebuilt secondary indexes; AWS does not guarantee a fixed completion time.
\nSource: AWS — Restoring a DynamoDB table to a point in time.
\nThis concerns the documented DynamoDB point-in-time restore workflow. Restored data and indexes are not evidence that application routing, event processing or retention behavior is ready.
\nDSE recommends preparing a post-restore configuration checklist before an incident. Assign owners for table protection, identity permissions, monitoring, TTL and stream consumers. Decide which indexes are essential before choosing a faster restore that omits them. Keep the restored table isolated until those choices are verified, then approve the application’s transition to the new table and the handling of writes made during recovery. Prepare a comparison sheet with a named owner for every setting that must be restored separately. Make application cutover conditional on closing those gaps and record any intentionally omitted index as an explicit performance or functionality decision for the recovery target.
\nProposed verification: restore an authorized test table and compare each omitted setting against the checklist. Exercise a representative application read and write, the intended stream integration and the selected retention behavior. Record actual recovery elapsed time and remaining gaps instead of converting a completed restore job into an unsupported recovery-time guarantee.
\nAWS — Restoring a DynamoDB table to a point in time. Reviewed October 20, 2026.
", "content_text": "A newly restored table needs more than recovered items before it is ready for application traffic.\nSource facts\nDynamoDB point-in-time recovery restores to a new table while the source remains available. AWS lists operational settings that must be set up again after restoration, including auto scaling policies, IAM policies, CloudWatch alarms, tags, Streams, Time to Live and PITR settings. Restore duration depends on data volume and rebuilt secondary indexes; AWS does not guarantee a fixed completion time.\nSource: AWS — Restoring a DynamoDB table to a point in time.\nApplicability\nThis concerns the documented DynamoDB point-in-time restore workflow. Restored data and indexes are not evidence that application routing, event processing or retention behavior is ready.\nDSE recommendation\nDSE recommends preparing a post-restore configuration checklist before an incident. Assign owners for table protection, identity permissions, monitoring, TTL and stream consumers. Decide which indexes are essential before choosing a faster restore that omits them. Keep the restored table isolated until those choices are verified, then approve the application’s transition to the new table and the handling of writes made during recovery. Prepare a comparison sheet with a named owner for every setting that must be restored separately. Make application cutover conditional on closing those gaps and record any intentionally omitted index as an explicit performance or functionality decision for the recovery target.\nVerification\nProposed verification: restore an authorized test table and compare each omitted setting against the checklist. Exercise a representative application read and write, the intended stream integration and the selected retention behavior. Record actual recovery elapsed time and remaining gaps instead of converting a completed restore job into an unsupported recovery-time guarantee.\nOfficial reference\nAWS — Restoring a DynamoDB table to a point in time. Reviewed October 20, 2026.", "content_markdown": "A newly restored table needs more than recovered items before it is ready for application traffic.\n\n## Source facts\n\nDynamoDB point-in-time recovery restores to a new table while the source remains available. AWS lists operational settings that must be set up again after restoration, including auto scaling policies, IAM policies, CloudWatch alarms, tags, Streams, Time to Live and PITR settings. Restore duration depends on data volume and rebuilt secondary indexes; AWS does not guarantee a fixed completion time.\n\nSource: [AWS — Restoring a DynamoDB table to a point in time](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html).\n\n## Applicability\n\nThis concerns the documented DynamoDB point-in-time restore workflow. Restored data and indexes are not evidence that application routing, event processing or retention behavior is ready.\n\n## DSE recommendation\n\nDSE recommends preparing a post-restore configuration checklist before an incident. Assign owners for table protection, identity permissions, monitoring, TTL and stream consumers. Decide which indexes are essential before choosing a faster restore that omits them. Keep the restored table isolated until those choices are verified, then approve the application’s transition to the new table and the handling of writes made during recovery. Prepare a comparison sheet with a named owner for every setting that must be restored separately. Make application cutover conditional on closing those gaps and record any intentionally omitted index as an explicit performance or functionality decision for the recovery target.\n\n## Verification\n\nProposed verification: restore an authorized test table and compare each omitted setting against the checklist. Exercise a representative application read and write, the intended stream integration and the selected retention behavior. Record actual recovery elapsed time and remaining gaps instead of converting a completed restore job into an unsupported recovery-time guarantee.\n\n## Official reference\n\n[AWS — Restoring a DynamoDB table to a point in time](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-status-continuous-backups-distinction/", "slug": "aws-dynamodb-pitr-status-continuous-backups-distinction", "url": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-status-continuous-backups-distinction/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-dynamodb-pitr-status-continuous-backups-distinction.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-dynamodb-pitr-status-continuous-backups-distinction/" }, "title": "Inspect DynamoDB PITR status instead of relying on ContinuousBackupsStatus", "summary": "An ENABLED continuous-backup status does not itself show that point-in-time recovery has been enabled.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:11+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 276, "potentially_affected": "This concerns DynamoDB PITR configuration and reported recovery windows. It does not establish that an existing table has the required protection or that a restore has been exercised.", "dse_recommendation": "DSE recommends making the PITR-specific state and actual earliest and latest restorable times visible in the protection inventory.", "primary_source": { "name": "AWS — Enable point-in-time recovery in DynamoDB", "url": "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 ENABLED continuous-backup status does not itself show that point-in-time recovery has been enabled.
\nAWS distinguishes ContinuousBackupsStatus from PointInTimeRecoveryStatus. ContinuousBackupsStatus is always ENABLED for a DynamoDB table, while PITR is disabled by default until enabled separately. PITR can use a recovery period between one and thirty-five days. Increasing that period does not immediately move the earliest recovery point backward because the longer history still needs to accumulate.
\nSource: AWS — Enable point-in-time recovery in DynamoDB.
\nThis concerns DynamoDB PITR configuration and reported recovery windows. It does not establish that an existing table has the required protection or that a restore has been exercised.
\nDSE recommends making the PITR-specific state and actual earliest and latest restorable times visible in the protection inventory. Compare the selected period with the data owner’s recovery needs. Treat a period increase as a future coverage change until the reported history catches up. Review a proposed reduction carefully, identifying any recovery dates that would become unavailable before applying it. Use the PITR-specific field in the protection acceptance checklist and retain the reported time range with it. Ask the data owner to approve the interval that is actually available today, and schedule a later check when an increased history period is expected to have accumulated.
\nProposed verification: for an approved test table, inspect both status fields and the reported recovery range before and after enabling PITR. Confirm that monitoring distinguishes the two fields. After a period change, observe the actual range and perform a permitted restore within it rather than assuming the configured number of days already exists.
\nAWS — Enable point-in-time recovery in DynamoDB. Reviewed October 20, 2026.
", "content_text": "An ENABLED continuous-backup status does not itself show that point-in-time recovery has been enabled.\nSource facts\nAWS distinguishes ContinuousBackupsStatus from PointInTimeRecoveryStatus. ContinuousBackupsStatus is always ENABLED for a DynamoDB table, while PITR is disabled by default until enabled separately. PITR can use a recovery period between one and thirty-five days. Increasing that period does not immediately move the earliest recovery point backward because the longer history still needs to accumulate.\nSource: AWS — Enable point-in-time recovery in DynamoDB.\nApplicability\nThis concerns DynamoDB PITR configuration and reported recovery windows. It does not establish that an existing table has the required protection or that a restore has been exercised.\nDSE recommendation\nDSE recommends making the PITR-specific state and actual earliest and latest restorable times visible in the protection inventory. Compare the selected period with the data owner’s recovery needs. Treat a period increase as a future coverage change until the reported history catches up. Review a proposed reduction carefully, identifying any recovery dates that would become unavailable before applying it. Use the PITR-specific field in the protection acceptance checklist and retain the reported time range with it. Ask the data owner to approve the interval that is actually available today, and schedule a later check when an increased history period is expected to have accumulated.\nVerification\nProposed verification: for an approved test table, inspect both status fields and the reported recovery range before and after enabling PITR. Confirm that monitoring distinguishes the two fields. After a period change, observe the actual range and perform a permitted restore within it rather than assuming the configured number of days already exists.\nOfficial reference\nAWS — Enable point-in-time recovery in DynamoDB. Reviewed October 20, 2026.", "content_markdown": "An ENABLED continuous-backup status does not itself show that point-in-time recovery has been enabled.\n\n## Source facts\n\nAWS distinguishes ContinuousBackupsStatus from PointInTimeRecoveryStatus. ContinuousBackupsStatus is always ENABLED for a DynamoDB table, while PITR is disabled by default until enabled separately. PITR can use a recovery period between one and thirty-five days. Increasing that period does not immediately move the earliest recovery point backward because the longer history still needs to accumulate.\n\nSource: [AWS — Enable point-in-time recovery in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html).\n\n## Applicability\n\nThis concerns DynamoDB PITR configuration and reported recovery windows. It does not establish that an existing table has the required protection or that a restore has been exercised.\n\n## DSE recommendation\n\nDSE recommends making the PITR-specific state and actual earliest and latest restorable times visible in the protection inventory. Compare the selected period with the data owner’s recovery needs. Treat a period increase as a future coverage change until the reported history catches up. Review a proposed reduction carefully, identifying any recovery dates that would become unavailable before applying it. Use the PITR-specific field in the protection acceptance checklist and retain the reported time range with it. Ask the data owner to approve the interval that is actually available today, and schedule a later check when an increased history period is expected to have accumulated.\n\n## Verification\n\nProposed verification: for an approved test table, inspect both status fields and the reported recovery range before and after enabling PITR. Confirm that monitoring distinguishes the two fields. After a period change, observe the actual range and perform a permitted restore within it rather than assuming the configured number of days already exists.\n\n## Official reference\n\n[AWS — Enable point-in-time recovery in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-rds-retained-automated-backup-expiry-final-snapshot/", "slug": "aws-rds-retained-automated-backup-expiry-final-snapshot", "url": "https://update.dsesecurity.com/updates/aws-rds-retained-automated-backup-expiry-final-snapshot/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-rds-retained-automated-backup-expiry-final-snapshot.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-rds-retained-automated-backup-expiry-final-snapshot/" }, "title": "Put an expiry date on retained RDS automated backups after instance deletion", "summary": "Retaining automated backups does not turn their rolling backup history into an indefinite archive.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:10+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This applies to retained automated backups of RDS DB instances, not Multi-AZ DB clusters. Retention choices and snapshot existence do not prove that recovery configuration is complete.", "dse_recommendation": "DSE recommends assigning an owner and review date to every retained backup set during retirement.", "primary_source": { "name": "AWS — Retaining automated backups", "url": "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Retaining.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Retaining automated backups does not turn their rolling backup history into an indefinite archive.
\nWhen an RDS instance is deleted, retained automated backups use the retention period configured at deletion. No new snapshots or logs are created, so the retained set eventually expires. Final snapshots are independent and do not expire automatically. AWS also states that retained automated backups do not include parameter- or option-group information and cannot be modified.
\nSource: AWS — Retaining automated backups.
\nThis applies to retained automated backups of RDS DB instances, not Multi-AZ DB clusters. Retention choices and snapshot existence do not prove that recovery configuration is complete.
\nDSE recommends assigning an owner and review date to every retained backup set during retirement. Record the last available recovery window and decide whether a final snapshot is needed for longer retention. Preserve the parameter and option-group design separately. Include backup storage and deletion decisions in the retirement record so a later cleanup does not silently remove the only approved recovery route. Record an explicit last review date before the retained range ends, with a named owner who can arrange any required longer-lived copy. Include recovery configuration alongside the data-retention decision so a future restore does not depend on a retired administrator’s memory.
\nProposed verification: inspect the retained set’s identifiers and reported recovery range after an approved test deletion. Verify the separately retained final snapshot when one was requested. Perform a permitted restore with the intended configuration, then confirm that retention review and eventual cleanup have an accountable owner.
\nAWS — Retaining automated backups. Reviewed October 20, 2026.
", "content_text": "Retaining automated backups does not turn their rolling backup history into an indefinite archive.\nSource facts\nWhen an RDS instance is deleted, retained automated backups use the retention period configured at deletion. No new snapshots or logs are created, so the retained set eventually expires. Final snapshots are independent and do not expire automatically. AWS also states that retained automated backups do not include parameter- or option-group information and cannot be modified.\nSource: AWS — Retaining automated backups.\nApplicability\nThis applies to retained automated backups of RDS DB instances, not Multi-AZ DB clusters. Retention choices and snapshot existence do not prove that recovery configuration is complete.\nDSE recommendation\nDSE recommends assigning an owner and review date to every retained backup set during retirement. Record the last available recovery window and decide whether a final snapshot is needed for longer retention. Preserve the parameter and option-group design separately. Include backup storage and deletion decisions in the retirement record so a later cleanup does not silently remove the only approved recovery route. Record an explicit last review date before the retained range ends, with a named owner who can arrange any required longer-lived copy. Include recovery configuration alongside the data-retention decision so a future restore does not depend on a retired administrator’s memory.\nVerification\nProposed verification: inspect the retained set’s identifiers and reported recovery range after an approved test deletion. Verify the separately retained final snapshot when one was requested. Perform a permitted restore with the intended configuration, then confirm that retention review and eventual cleanup have an accountable owner.\nOfficial reference\nAWS — Retaining automated backups. Reviewed October 20, 2026.", "content_markdown": "Retaining automated backups does not turn their rolling backup history into an indefinite archive.\n\n## Source facts\n\nWhen an RDS instance is deleted, retained automated backups use the retention period configured at deletion. No new snapshots or logs are created, so the retained set eventually expires. Final snapshots are independent and do not expire automatically. AWS also states that retained automated backups do not include parameter- or option-group information and cannot be modified.\n\nSource: [AWS — Retaining automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Retaining.html).\n\n## Applicability\n\nThis applies to retained automated backups of RDS DB instances, not Multi-AZ DB clusters. Retention choices and snapshot existence do not prove that recovery configuration is complete.\n\n## DSE recommendation\n\nDSE recommends assigning an owner and review date to every retained backup set during retirement. Record the last available recovery window and decide whether a final snapshot is needed for longer retention. Preserve the parameter and option-group design separately. Include backup storage and deletion decisions in the retirement record so a later cleanup does not silently remove the only approved recovery route. Record an explicit last review date before the retained range ends, with a named owner who can arrange any required longer-lived copy. Include recovery configuration alongside the data-retention decision so a future restore does not depend on a retired administrator’s memory.\n\n## Verification\n\nProposed verification: inspect the retained set’s identifiers and reported recovery range after an approved test deletion. Verify the separately retained final snapshot when one was requested. Perform a permitted restore with the intended configuration, then confirm that retention review and eventual cleanup have an accountable owner.\n\n## Official reference\n\n[AWS — Retaining automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Retaining.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-rds-snapshot-restore-configuration-defaults/", "slug": "aws-rds-snapshot-restore-configuration-defaults", "url": "https://update.dsesecurity.com/updates/aws-rds-snapshot-restore-configuration-defaults/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-rds-snapshot-restore-configuration-defaults.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-rds-snapshot-restore-configuration-defaults/" }, "title": "Review RDS snapshot restore defaults before reconnecting an application", "summary": "A restored snapshot creates a new instance whose surrounding configuration must be reviewed before use.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:09+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This concerns RDS DB-instance snapshot restores. Engine-specific option groups, storage choices and licensing requirements still need separate review for the actual source snapshot.", "dse_recommendation": "DSE recommends maintaining a restore configuration sheet alongside each important snapshot.", "primary_source": { "name": "AWS — Restoring to a DB instance", "url": "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 restored snapshot creates a new instance whose surrounding configuration must be reviewed before use.
\nRDS cannot restore a DB snapshot over an existing DB instance; a restore creates a new instance. Unless changed, the restored instance uses default parameter and network-related settings described by AWS. AWS recommends retaining custom parameter groups with snapshots. A restored database can become available while data continues loading from S3 in the background, so initial availability and full initialization are different states.
\nSource: AWS — Restoring to a DB instance.
\nThis concerns RDS DB-instance snapshot restores. Engine-specific option groups, storage choices and licensing requirements still need separate review for the actual source snapshot.
\nDSE recommends maintaining a restore configuration sheet alongside each important snapshot. Include the intended VPC, subnet group, security groups, parameter group and application owner. Restore first into an approved recovery environment and compare those settings with the intended target design. Decide whether any change is deliberate rather than copying a default into production. Schedule representative workload checks before switching clients to the new instance. Make the endpoint switch conditional on an owner-reviewed configuration comparison and representative queries. Keep the source snapshot identifier and the deliberate target differences together so the next operator can distinguish a recovery choice from an accidentally accepted default.
\nProposed verification: inspect the restored instance’s configuration and initialization indicators. Validate connectivity only from intended clients and confirm rejection from an unapproved test path. Run representative application queries against approved data, record their results and compare performance after initialization before approving the endpoint cutover.
\nAWS — Restoring to a DB instance. Reviewed October 20, 2026.
", "content_text": "A restored snapshot creates a new instance whose surrounding configuration must be reviewed before use.\nSource facts\nRDS cannot restore a DB snapshot over an existing DB instance; a restore creates a new instance. Unless changed, the restored instance uses default parameter and network-related settings described by AWS. AWS recommends retaining custom parameter groups with snapshots. A restored database can become available while data continues loading from S3 in the background, so initial availability and full initialization are different states.\nSource: AWS — Restoring to a DB instance.\nApplicability\nThis concerns RDS DB-instance snapshot restores. Engine-specific option groups, storage choices and licensing requirements still need separate review for the actual source snapshot.\nDSE recommendation\nDSE recommends maintaining a restore configuration sheet alongside each important snapshot. Include the intended VPC, subnet group, security groups, parameter group and application owner. Restore first into an approved recovery environment and compare those settings with the intended target design. Decide whether any change is deliberate rather than copying a default into production. Schedule representative workload checks before switching clients to the new instance. Make the endpoint switch conditional on an owner-reviewed configuration comparison and representative queries. Keep the source snapshot identifier and the deliberate target differences together so the next operator can distinguish a recovery choice from an accidentally accepted default.\nVerification\nProposed verification: inspect the restored instance’s configuration and initialization indicators. Validate connectivity only from intended clients and confirm rejection from an unapproved test path. Run representative application queries against approved data, record their results and compare performance after initialization before approving the endpoint cutover.\nOfficial reference\nAWS — Restoring to a DB instance. Reviewed October 20, 2026.", "content_markdown": "A restored snapshot creates a new instance whose surrounding configuration must be reviewed before use.\n\n## Source facts\n\nRDS cannot restore a DB snapshot over an existing DB instance; a restore creates a new instance. Unless changed, the restored instance uses default parameter and network-related settings described by AWS. AWS recommends retaining custom parameter groups with snapshots. A restored database can become available while data continues loading from S3 in the background, so initial availability and full initialization are different states.\n\nSource: [AWS — Restoring to a DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html).\n\n## Applicability\n\nThis concerns RDS DB-instance snapshot restores. Engine-specific option groups, storage choices and licensing requirements still need separate review for the actual source snapshot.\n\n## DSE recommendation\n\nDSE recommends maintaining a restore configuration sheet alongside each important snapshot. Include the intended VPC, subnet group, security groups, parameter group and application owner. Restore first into an approved recovery environment and compare those settings with the intended target design. Decide whether any change is deliberate rather than copying a default into production. Schedule representative workload checks before switching clients to the new instance. Make the endpoint switch conditional on an owner-reviewed configuration comparison and representative queries. Keep the source snapshot identifier and the deliberate target differences together so the next operator can distinguish a recovery choice from an accidentally accepted default.\n\n## Verification\n\nProposed verification: inspect the restored instance’s configuration and initialization indicators. Validate connectivity only from intended clients and confirm rejection from an unapproved test path. Run representative application queries against approved data, record their results and compare performance after initialization before approving the endpoint cutover.\n\n## Official reference\n\n[AWS — Restoring to a DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-rds-pitr-latest-restorable-time-new-instance/", "slug": "aws-rds-pitr-latest-restorable-time-new-instance", "url": "https://update.dsesecurity.com/updates/aws-rds-pitr-latest-restorable-time-new-instance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-rds-pitr-latest-restorable-time-new-instance.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-rds-pitr-latest-restorable-time-new-instance/" }, "title": "Use the RDS latest-restorable timestamp before selecting a recovery point", "summary": "A database recovery timestamp must be inside the reported backup window, not simply equal to the current clock.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "video-evidence", "label": "Video evidence & analytics", "alt": "Multiple synchronized camera views converging into a verifiable evidence frame.", "card_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/video-evidence-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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:08+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 298, "potentially_affected": "This describes RDS DB-instance recovery. Aurora clusters and engine-specific exceptions have separate requirements. The page does not guarantee that a chosen timestamp or restored instance meets application acceptance criteria.", "dse_recommendation": "DSE recommends recording the earliest and latest restorable timestamps together with the incident’s time reference before starting recovery.", "primary_source": { "name": "AWS — Restoring a DB instance to a specified time for Amazon RDS", "url": "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 database recovery timestamp must be inside the reported backup window, not simply equal to the current clock.
\nAmazon RDS point-in-time recovery creates a new DB instance without modifying the source. RDS uploads instance transaction logs to S3 every five minutes and exposes LatestRestorableTime. Recovery can target a time within the backup retention period. Restored instances initially use default parameter and option groups unless custom groups are supplied through the supported restore workflow.
\nSource: AWS — Restoring a DB instance to a specified time for Amazon RDS.
\nThis describes RDS DB-instance recovery. Aurora clusters and engine-specific exceptions have separate requirements. The page does not guarantee that a chosen timestamp or restored instance meets application acceptance criteria.
\nDSE recommends recording the earliest and latest restorable timestamps together with the incident’s time reference before starting recovery. Choose a unique target identifier and review network, parameter and option settings as an explicit recovery configuration. Keep the source isolated from the recovery decision until data checks establish the intended outcome. Plan the application endpoint change and the treatment of writes made after the selected recovery time. Put the selected recovery timestamp and endpoint cutover decision in separate approval fields. Ask the application owner which transaction examples will establish the intended data boundary, then retain those checks with the restored instance configuration for a later repeatable recovery exercise.
\nProposed verification: restore an authorized test database to a timestamp inside the reported range. Compare known records on both sides of that time, inspect the target configuration, and exercise the intended client connection. Retain the source and target identifiers, timestamps and application checks without presenting the restore request itself as proof of recovery.
\nAWS — Restoring a DB instance to a specified time for Amazon RDS. Reviewed October 20, 2026.
", "content_text": "A database recovery timestamp must be inside the reported backup window, not simply equal to the current clock.\nSource facts\nAmazon RDS point-in-time recovery creates a new DB instance without modifying the source. RDS uploads instance transaction logs to S3 every five minutes and exposes LatestRestorableTime. Recovery can target a time within the backup retention period. Restored instances initially use default parameter and option groups unless custom groups are supplied through the supported restore workflow.\nSource: AWS — Restoring a DB instance to a specified time for Amazon RDS.\nApplicability\nThis describes RDS DB-instance recovery. Aurora clusters and engine-specific exceptions have separate requirements. The page does not guarantee that a chosen timestamp or restored instance meets application acceptance criteria.\nDSE recommendation\nDSE recommends recording the earliest and latest restorable timestamps together with the incident’s time reference before starting recovery. Choose a unique target identifier and review network, parameter and option settings as an explicit recovery configuration. Keep the source isolated from the recovery decision until data checks establish the intended outcome. Plan the application endpoint change and the treatment of writes made after the selected recovery time. Put the selected recovery timestamp and endpoint cutover decision in separate approval fields. Ask the application owner which transaction examples will establish the intended data boundary, then retain those checks with the restored instance configuration for a later repeatable recovery exercise.\nVerification\nProposed verification: restore an authorized test database to a timestamp inside the reported range. Compare known records on both sides of that time, inspect the target configuration, and exercise the intended client connection. Retain the source and target identifiers, timestamps and application checks without presenting the restore request itself as proof of recovery.\nOfficial reference\nAWS — Restoring a DB instance to a specified time for Amazon RDS. Reviewed October 20, 2026.", "content_markdown": "A database recovery timestamp must be inside the reported backup window, not simply equal to the current clock.\n\n## Source facts\n\nAmazon RDS point-in-time recovery creates a new DB instance without modifying the source. RDS uploads instance transaction logs to S3 every five minutes and exposes LatestRestorableTime. Recovery can target a time within the backup retention period. Restored instances initially use default parameter and option groups unless custom groups are supplied through the supported restore workflow.\n\nSource: [AWS — Restoring a DB instance to a specified time for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html).\n\n## Applicability\n\nThis describes RDS DB-instance recovery. Aurora clusters and engine-specific exceptions have separate requirements. The page does not guarantee that a chosen timestamp or restored instance meets application acceptance criteria.\n\n## DSE recommendation\n\nDSE recommends recording the earliest and latest restorable timestamps together with the incident’s time reference before starting recovery. Choose a unique target identifier and review network, parameter and option settings as an explicit recovery configuration. Keep the source isolated from the recovery decision until data checks establish the intended outcome. Plan the application endpoint change and the treatment of writes made after the selected recovery time. Put the selected recovery timestamp and endpoint cutover decision in separate approval fields. Ask the application owner which transaction examples will establish the intended data boundary, then retain those checks with the restored instance configuration for a later repeatable recovery exercise.\n\n## Verification\n\nProposed verification: restore an authorized test database to a timestamp inside the reported range. Compare known records on both sides of that time, inspect the target configuration, and exercise the intended client connection. Retain the source and target identifiers, timestamps and application checks without presenting the restore request itself as proof of recovery.\n\n## Official reference\n\n[AWS — Restoring a DB instance to a specified time for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-maximum-duration/", "slug": "aws-ssm-session-manager-maximum-duration", "url": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-maximum-duration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-maximum-duration.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-ssm-session-manager-maximum-duration/" }, "title": "Set a total Session Manager duration for long-running staff sessions", "summary": "A total session limit gives an administrator a separate decision from how long an idle connection may remain open.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:07+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 280, "potentially_affected": "This applies to the Session Manager maximum-duration preference. The source does not guarantee that ending a session reverses commands already executed or supplies an application recovery procedure.", "dse_recommendation": "DSE recommends choosing the duration from actual support and maintenance tasks, with input from the service owner.", "primary_source": { "name": "AWS — Specify maximum session duration", "url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-max-timeout.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 total session limit gives an administrator a separate decision from how long an idle connection may remain open.
\nSession Manager allows a maximum duration after which a session ends. AWS documents no maximum session duration by default. When enabled in Session Manager preferences, the configured value must be between one and 1,440 minutes. The setting controls the total session duration described by this page; AWS provides idle timeout as a separate preference topic.
\nSource: AWS — Specify maximum session duration.
\nThis applies to the Session Manager maximum-duration preference. The source does not guarantee that ending a session reverses commands already executed or supplies an application recovery procedure.
\nDSE recommends choosing the duration from actual support and maintenance tasks, with input from the service owner. Record how an operator should reconnect safely and how lengthy approved work will be handed off. Avoid setting an arbitrarily short limit that encourages bypassing the approved access method. Include maximum duration in the remote-access checklist so a later preferences change receives the same review as other staff access controls. Ask the support owner to identify tasks that need a planned reconnection or handoff, and include those instructions beside the approved duration. Keep any temporary exception time-bounded in the access record and restore the intended preference after the authorized work.
\nProposed verification: in an authorized test environment, set a short temporary limit and observe when a harmless session ends. Record its start and end times and confirm the documented reconnection procedure works. Restore the approved production value after testing, then inspect the saved preference rather than relying only on the edit screen.
\nAWS — Specify maximum session duration. Reviewed October 20, 2026.
", "content_text": "A total session limit gives an administrator a separate decision from how long an idle connection may remain open.\nSource facts\nSession Manager allows a maximum duration after which a session ends. AWS documents no maximum session duration by default. When enabled in Session Manager preferences, the configured value must be between one and 1,440 minutes. The setting controls the total session duration described by this page; AWS provides idle timeout as a separate preference topic.\nSource: AWS — Specify maximum session duration.\nApplicability\nThis applies to the Session Manager maximum-duration preference. The source does not guarantee that ending a session reverses commands already executed or supplies an application recovery procedure.\nDSE recommendation\nDSE recommends choosing the duration from actual support and maintenance tasks, with input from the service owner. Record how an operator should reconnect safely and how lengthy approved work will be handed off. Avoid setting an arbitrarily short limit that encourages bypassing the approved access method. Include maximum duration in the remote-access checklist so a later preferences change receives the same review as other staff access controls. Ask the support owner to identify tasks that need a planned reconnection or handoff, and include those instructions beside the approved duration. Keep any temporary exception time-bounded in the access record and restore the intended preference after the authorized work.\nVerification\nProposed verification: in an authorized test environment, set a short temporary limit and observe when a harmless session ends. Record its start and end times and confirm the documented reconnection procedure works. Restore the approved production value after testing, then inspect the saved preference rather than relying only on the edit screen.\nOfficial reference\nAWS — Specify maximum session duration. Reviewed October 20, 2026.", "content_markdown": "A total session limit gives an administrator a separate decision from how long an idle connection may remain open.\n\n## Source facts\n\nSession Manager allows a maximum duration after which a session ends. AWS documents no maximum session duration by default. When enabled in Session Manager preferences, the configured value must be between one and 1,440 minutes. The setting controls the total session duration described by this page; AWS provides idle timeout as a separate preference topic.\n\nSource: [AWS — Specify maximum session duration](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-max-timeout.html).\n\n## Applicability\n\nThis applies to the Session Manager maximum-duration preference. The source does not guarantee that ending a session reverses commands already executed or supplies an application recovery procedure.\n\n## DSE recommendation\n\nDSE recommends choosing the duration from actual support and maintenance tasks, with input from the service owner. Record how an operator should reconnect safely and how lengthy approved work will be handed off. Avoid setting an arbitrarily short limit that encourages bypassing the approved access method. Include maximum duration in the remote-access checklist so a later preferences change receives the same review as other staff access controls. Ask the support owner to identify tasks that need a planned reconnection or handoff, and include those instructions beside the approved duration. Keep any temporary exception time-bounded in the access record and restore the intended preference after the authorized work.\n\n## Verification\n\nProposed verification: in an authorized test environment, set a short temporary limit and observe when a harmless session ends. Record its start and end times and confirm the documented reconnection procedure works. Restore the approved production value after testing, then inspect the saved preference rather than relying only on the edit screen.\n\n## Official reference\n\n[AWS — Specify maximum session duration](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-max-timeout.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-ssm-automation-manual-approval-timeout/", "slug": "aws-ssm-automation-manual-approval-timeout", "url": "https://update.dsesecurity.com/updates/aws-ssm-automation-manual-approval-timeout/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-ssm-automation-manual-approval-timeout.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-ssm-automation-manual-approval-timeout/" }, "title": "Make an SSM Automation approval step expire with a defined failure path", "summary": "A manual approval is an execution step with approvers, a threshold and a bounded wait.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:06+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 276, "potentially_affected": "This applies to the aws:approve runbook action. It does not establish an organization’s change policy or imply that notification delivery constitutes an approval.", "dse_recommendation": "DSE recommends placing the approval immediately before the consequential operation and supplying a readable description of its target and impact.", "primary_source": { "name": "AWS — aws:approve – Pause an automation for manual approval", "url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-approve.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 manual approval is an execution step with approvers, a threshold and a bounded wait.
\nThe aws:approve Automation action pauses a runbook until designated principals approve or reject the action. Execution resumes after the required approval count is met. AWS documents a seven-day default timeout and a thirty-day maximum, adjustable with timeoutSeconds. The action does not support multi-account and Region automations. MinRequiredApprovals cannot exceed the number of configured approvers.
\nSource: AWS — aws:approve – Pause an automation for manual approval.
\nThis applies to the aws:approve runbook action. It does not establish an organization’s change policy or imply that notification delivery constitutes an approval.
\nDSE recommends placing the approval immediately before the consequential operation and supplying a readable description of its target and impact. Select principals who can assess that change and decide how rejection, expiry and approver absence should be handled. Set an explicit timeout that fits the maintenance window. Keep execution permissions and the authority to approve distinct in the documented runbook ownership model. Write an explicit operational response for a missed approval window, including whether the target and change description must be reviewed again. Ask approvers to verify the actual execution target rather than accepting an approval message solely because its runbook name is familiar.
\nProposed verification: run a harmless approval workflow in a test account. Exercise approval, rejection and timeout paths, and inspect the resulting step states. Verify the configured threshold with multiple approvers where applicable. Retain the execution ID, reviewed message and decision history before applying the runbook to production targets.
\nAWS — aws:approve – Pause an automation for manual approval. Reviewed October 20, 2026.
", "content_text": "A manual approval is an execution step with approvers, a threshold and a bounded wait.\nSource facts\nThe aws:approve Automation action pauses a runbook until designated principals approve or reject the action. Execution resumes after the required approval count is met. AWS documents a seven-day default timeout and a thirty-day maximum, adjustable with timeoutSeconds. The action does not support multi-account and Region automations. MinRequiredApprovals cannot exceed the number of configured approvers.\nSource: AWS — aws:approve – Pause an automation for manual approval.\nApplicability\nThis applies to the aws:approve runbook action. It does not establish an organization’s change policy or imply that notification delivery constitutes an approval.\nDSE recommendation\nDSE recommends placing the approval immediately before the consequential operation and supplying a readable description of its target and impact. Select principals who can assess that change and decide how rejection, expiry and approver absence should be handled. Set an explicit timeout that fits the maintenance window. Keep execution permissions and the authority to approve distinct in the documented runbook ownership model. Write an explicit operational response for a missed approval window, including whether the target and change description must be reviewed again. Ask approvers to verify the actual execution target rather than accepting an approval message solely because its runbook name is familiar.\nVerification\nProposed verification: run a harmless approval workflow in a test account. Exercise approval, rejection and timeout paths, and inspect the resulting step states. Verify the configured threshold with multiple approvers where applicable. Retain the execution ID, reviewed message and decision history before applying the runbook to production targets.\nOfficial reference\nAWS — aws:approve – Pause an automation for manual approval. Reviewed October 20, 2026.", "content_markdown": "A manual approval is an execution step with approvers, a threshold and a bounded wait.\n\n## Source facts\n\nThe aws:approve Automation action pauses a runbook until designated principals approve or reject the action. Execution resumes after the required approval count is met. AWS documents a seven-day default timeout and a thirty-day maximum, adjustable with timeoutSeconds. The action does not support multi-account and Region automations. MinRequiredApprovals cannot exceed the number of configured approvers.\n\nSource: [AWS — aws:approve – Pause an automation for manual approval](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-approve.html).\n\n## Applicability\n\nThis applies to the aws:approve runbook action. It does not establish an organization’s change policy or imply that notification delivery constitutes an approval.\n\n## DSE recommendation\n\nDSE recommends placing the approval immediately before the consequential operation and supplying a readable description of its target and impact. Select principals who can assess that change and decide how rejection, expiry and approver absence should be handled. Set an explicit timeout that fits the maintenance window. Keep execution permissions and the authority to approve distinct in the documented runbook ownership model. Write an explicit operational response for a missed approval window, including whether the target and change description must be reviewed again. Ask approvers to verify the actual execution target rather than accepting an approval message solely because its runbook name is familiar.\n\n## Verification\n\nProposed verification: run a harmless approval workflow in a test account. Exercise approval, rejection and timeout paths, and inspect the resulting step states. Verify the configured threshold with multiple approvers where applicable. Retain the execution ID, reviewed message and decision history before applying the runbook to production targets.\n\n## Official reference\n\n[AWS — aws:approve – Pause an automation for manual approval](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-approve.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-ssm-run-command-error-threshold-concurrency/", "slug": "aws-ssm-run-command-error-threshold-concurrency", "url": "https://update.dsesecurity.com/updates/aws-ssm-run-command-error-threshold-concurrency/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-ssm-run-command-error-threshold-concurrency.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-ssm-run-command-error-threshold-concurrency/" }, "title": "Pair Run Command error limits with concurrency before a fleet rollout", "summary": "Stopping further dispatch does not stop commands already executing on managed nodes.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:05+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.", "dse_recommendation": "DSE recommends treating both settings as part of the approved change.", "primary_source": { "name": "AWS — Run commands at scale", "url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Stopping further dispatch does not stop commands already executing on managed nodes.
\nSystems Manager Run Command accepts max-concurrency and max-errors as separate controls. The error limit stops dispatch to additional managed nodes after the allowed error count is exceeded. Commands already running are allowed to complete and may also fail. AWS advises concurrency of one when strict sequential failure control is required. The documented default for max-errors is zero, which stops additional dispatch after the first returned error.
\nSource: AWS — Run commands at scale.
\nThis describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.
\nDSE recommends treating both settings as part of the approved change. Start with a small, explicitly named target set and a harmless command, then decide how many simultaneous failures the service can tolerate. Write down the cancellation and recovery plan for nodes already running. Keep dynamic tag targeting under review so a larger target population cannot silently alter the intended rollout boundary. Separate the dispatch decision from the node-level recovery decision in the rollout record. Ask the change owner to identify the maximum acceptable in-flight population and explain how an operator will find those nodes if further dispatch stops during the pilot.
\nProposed verification: retain the target list, command ID, chosen limits and per-node results from a controlled pilot. Induce a harmless failure on an approved test node and compare subsequent dispatch with in-flight completions. Verify the rollback procedure separately before using the same pattern for a disruptive command.
\nAWS — Run commands at scale. Reviewed October 20, 2026.
", "content_text": "Stopping further dispatch does not stop commands already executing on managed nodes.\nSource facts\nSystems Manager Run Command accepts max-concurrency and max-errors as separate controls. The error limit stops dispatch to additional managed nodes after the allowed error count is exceeded. Commands already running are allowed to complete and may also fail. AWS advises concurrency of one when strict sequential failure control is required. The documented default for max-errors is zero, which stops additional dispatch after the first returned error.\nSource: AWS — Run commands at scale.\nApplicability\nThis describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.\nDSE recommendation\nDSE recommends treating both settings as part of the approved change. Start with a small, explicitly named target set and a harmless command, then decide how many simultaneous failures the service can tolerate. Write down the cancellation and recovery plan for nodes already running. Keep dynamic tag targeting under review so a larger target population cannot silently alter the intended rollout boundary. Separate the dispatch decision from the node-level recovery decision in the rollout record. Ask the change owner to identify the maximum acceptable in-flight population and explain how an operator will find those nodes if further dispatch stops during the pilot.\nVerification\nProposed verification: retain the target list, command ID, chosen limits and per-node results from a controlled pilot. Induce a harmless failure on an approved test node and compare subsequent dispatch with in-flight completions. Verify the rollback procedure separately before using the same pattern for a disruptive command.\nOfficial reference\nAWS — Run commands at scale. Reviewed October 20, 2026.", "content_markdown": "Stopping further dispatch does not stop commands already executing on managed nodes.\n\n## Source facts\n\nSystems Manager Run Command accepts max-concurrency and max-errors as separate controls. The error limit stops dispatch to additional managed nodes after the allowed error count is exceeded. Commands already running are allowed to complete and may also fail. AWS advises concurrency of one when strict sequential failure control is required. The documented default for max-errors is zero, which stops additional dispatch after the first returned error.\n\nSource: [AWS — Run commands at scale](https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html).\n\n## Applicability\n\nThis describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.\n\n## DSE recommendation\n\nDSE recommends treating both settings as part of the approved change. Start with a small, explicitly named target set and a harmless command, then decide how many simultaneous failures the service can tolerate. Write down the cancellation and recovery plan for nodes already running. Keep dynamic tag targeting under review so a larger target population cannot silently alter the intended rollout boundary. Separate the dispatch decision from the node-level recovery decision in the rollout record. Ask the change owner to identify the maximum acceptable in-flight population and explain how an operator will find those nodes if further dispatch stops during the pilot.\n\n## Verification\n\nProposed verification: retain the target list, command ID, chosen limits and per-node results from a controlled pilot. Induce a harmless failure on an approved test node and compare subsequent dispatch with in-flight completions. Verify the rollback procedure separately before using the same pattern for a disruptive command.\n\n## Official reference\n\n[AWS — Run commands at scale](https://docs.aws.amazon.com/systems-manager/latest/userguide/send-commands-multiple.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-transcript-tunnel-boundary/", "slug": "aws-ssm-session-manager-transcript-tunnel-boundary", "url": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-transcript-tunnel-boundary/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-ssm-session-manager-transcript-tunnel-boundary.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-ssm-session-manager-transcript-tunnel-boundary/" }, "title": "Separate Session Manager shell transcripts from SSH and port-forwarding tunnels", "summary": "A Session Manager connection record does not mean every tunneled command has a readable transcript.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:04+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 277, "potentially_affected": "This applies to AWS Systems Manager Session Manager. Connection history, shell content, operating-system auditing and application activity are different evidence types with separate configuration needs.", "dse_recommendation": "DSE recommends classifying approved remote-access methods before selecting audit controls.", "primary_source": { "name": "AWS — Enabling and disabling session logging", "url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 Session Manager connection record does not mean every tunneled command has a readable transcript.
\nAWS states that Session Manager can record session commands and output according to session preferences. Logging is not available for Session Manager sessions using SSH or port forwarding: Session Manager serves as a tunnel for the SSH connection. AWS also warns that sensitive information entered during logged sessions can appear in the logs and describes options for limiting echoed secret input.
\nSource: AWS — Enabling and disabling session logging.
\nThis applies to AWS Systems Manager Session Manager. Connection history, shell content, operating-system auditing and application activity are different evidence types with separate configuration needs.
\nDSE recommends classifying approved remote-access methods before selecting audit controls. Record which methods produce shell transcripts and which require another source of command or application evidence. Give log readers only the access needed for their role and define a retention owner. Provide operators with an approved way to handle credentials without printing them. Do not claim full session recording merely because the connection passed through Session Manager. Publish a small access-method matrix for support showing the evidence expected from each permitted session type. Require the workload owner to approve the compensating audit source for tunnel-based access before anyone describes the resulting access path as fully recorded.
\nProposed verification: in an authorized environment, compare an ordinary shell session with the permitted tunnel methods. Confirm the expected log destination and actual captured fields for each. Use harmless sample commands, never real passwords. Record any unobservable activity and its compensating evidence source in the access-control design.
\nAWS — Enabling and disabling session logging. Reviewed October 20, 2026.
", "content_text": "A Session Manager connection record does not mean every tunneled command has a readable transcript.\nSource facts\nAWS states that Session Manager can record session commands and output according to session preferences. Logging is not available for Session Manager sessions using SSH or port forwarding: Session Manager serves as a tunnel for the SSH connection. AWS also warns that sensitive information entered during logged sessions can appear in the logs and describes options for limiting echoed secret input.\nSource: AWS — Enabling and disabling session logging.\nApplicability\nThis applies to AWS Systems Manager Session Manager. Connection history, shell content, operating-system auditing and application activity are different evidence types with separate configuration needs.\nDSE recommendation\nDSE recommends classifying approved remote-access methods before selecting audit controls. Record which methods produce shell transcripts and which require another source of command or application evidence. Give log readers only the access needed for their role and define a retention owner. Provide operators with an approved way to handle credentials without printing them. Do not claim full session recording merely because the connection passed through Session Manager. Publish a small access-method matrix for support showing the evidence expected from each permitted session type. Require the workload owner to approve the compensating audit source for tunnel-based access before anyone describes the resulting access path as fully recorded.\nVerification\nProposed verification: in an authorized environment, compare an ordinary shell session with the permitted tunnel methods. Confirm the expected log destination and actual captured fields for each. Use harmless sample commands, never real passwords. Record any unobservable activity and its compensating evidence source in the access-control design.\nOfficial reference\nAWS — Enabling and disabling session logging. Reviewed October 20, 2026.", "content_markdown": "A Session Manager connection record does not mean every tunneled command has a readable transcript.\n\n## Source facts\n\nAWS states that Session Manager can record session commands and output according to session preferences. Logging is not available for Session Manager sessions using SSH or port forwarding: Session Manager serves as a tunnel for the SSH connection. AWS also warns that sensitive information entered during logged sessions can appear in the logs and describes options for limiting echoed secret input.\n\nSource: [AWS — Enabling and disabling session logging](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html).\n\n## Applicability\n\nThis applies to AWS Systems Manager Session Manager. Connection history, shell content, operating-system auditing and application activity are different evidence types with separate configuration needs.\n\n## DSE recommendation\n\nDSE recommends classifying approved remote-access methods before selecting audit controls. Record which methods produce shell transcripts and which require another source of command or application evidence. Give log readers only the access needed for their role and define a retention owner. Provide operators with an approved way to handle credentials without printing them. Do not claim full session recording merely because the connection passed through Session Manager. Publish a small access-method matrix for support showing the evidence expected from each permitted session type. Require the workload owner to approve the compensating audit source for tunnel-based access before anyone describes the resulting access path as fully recorded.\n\n## Verification\n\nProposed verification: in an authorized environment, compare an ordinary shell session with the permitted tunnel methods. Confirm the expected log destination and actual captured fields for each. Use harmless sample commands, never real passwords. Record any unobservable activity and its compensating evidence source in the access-control design.\n\n## Official reference\n\n[AWS — Enabling and disabling session logging](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-backup-overlapping-start-windows-retention-optimization/", "slug": "aws-backup-overlapping-start-windows-retention-optimization", "url": "https://update.dsesecurity.com/updates/aws-backup-overlapping-start-windows-retention-optimization/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-backup-overlapping-start-windows-retention-optimization.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-backup-overlapping-start-windows-retention-optimization/" }, "title": "Account for full start windows when AWS Backup rules overlap", "summary": "A longer-retention backup rule can suppress expected shorter-retention jobs across its entire start window.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:03+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 267, "potentially_affected": "This concerns backup-plan scheduling and overlap optimization. A chosen schedule does not establish a guaranteed backup completion time or an application recovery objective.", "dse_recommendation": "DSE recommends drawing the daily start windows for every effective rule on one timeline.", "primary_source": { "name": "AWS — Backup plan options and configuration", "url": "https://docs.aws.amazon.com/aws-backup/latest/devguide/plan-options-and-configuration.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 longer-retention backup rule can suppress expected shorter-retention jobs across its entire start window.
\nWhen AWS Backup rule start windows overlap, AWS Backup retains the backup under the longer-retention rule. Its optimization considers the full start window rather than only the nominal scheduled time. A job can remain CREATED while waiting to start and can become EXPIRED when its start window runs out. Snapshot scheduling and continuous point-in-time protection have different behavior.
\nSource: AWS — Backup plan options and configuration.
\nThis concerns backup-plan scheduling and overlap optimization. A chosen schedule does not establish a guaranteed backup completion time or an application recovery objective.
\nDSE recommends drawing the daily start windows for every effective rule on one timeline. Calculate the recovery-point pattern produced by overlapping windows before interpreting fewer jobs as a failure. Separate start deadlines from completion deadlines in monitoring. Ask the application owner to approve the resulting gap between usable recovery points, and review maintenance-window conflicts before reducing a start window to force a desired count. Give the recovery owner a simple timeline showing the resulting usable points, not only the configured rule names. Review that timeline whenever another rule is added so a well-intended retention change does not leave an unexplained monitoring expectation.
\nProposed verification: observe a full approved test schedule and compare actual job start times, expiry states and retained recovery points with the planned timeline. Check the longest gap between usable backups. Keep failed-start alerts separate from intentionally optimized overlapping rules so operators can investigate the right condition.
\nAWS — Backup plan options and configuration. Reviewed October 20, 2026.
", "content_text": "A longer-retention backup rule can suppress expected shorter-retention jobs across its entire start window.\nSource facts\nWhen AWS Backup rule start windows overlap, AWS Backup retains the backup under the longer-retention rule. Its optimization considers the full start window rather than only the nominal scheduled time. A job can remain CREATED while waiting to start and can become EXPIRED when its start window runs out. Snapshot scheduling and continuous point-in-time protection have different behavior.\nSource: AWS — Backup plan options and configuration.\nApplicability\nThis concerns backup-plan scheduling and overlap optimization. A chosen schedule does not establish a guaranteed backup completion time or an application recovery objective.\nDSE recommendation\nDSE recommends drawing the daily start windows for every effective rule on one timeline. Calculate the recovery-point pattern produced by overlapping windows before interpreting fewer jobs as a failure. Separate start deadlines from completion deadlines in monitoring. Ask the application owner to approve the resulting gap between usable recovery points, and review maintenance-window conflicts before reducing a start window to force a desired count. Give the recovery owner a simple timeline showing the resulting usable points, not only the configured rule names. Review that timeline whenever another rule is added so a well-intended retention change does not leave an unexplained monitoring expectation.\nVerification\nProposed verification: observe a full approved test schedule and compare actual job start times, expiry states and retained recovery points with the planned timeline. Check the longest gap between usable backups. Keep failed-start alerts separate from intentionally optimized overlapping rules so operators can investigate the right condition.\nOfficial reference\nAWS — Backup plan options and configuration. Reviewed October 20, 2026.", "content_markdown": "A longer-retention backup rule can suppress expected shorter-retention jobs across its entire start window.\n\n## Source facts\n\nWhen AWS Backup rule start windows overlap, AWS Backup retains the backup under the longer-retention rule. Its optimization considers the full start window rather than only the nominal scheduled time. A job can remain CREATED while waiting to start and can become EXPIRED when its start window runs out. Snapshot scheduling and continuous point-in-time protection have different behavior.\n\nSource: [AWS — Backup plan options and configuration](https://docs.aws.amazon.com/aws-backup/latest/devguide/plan-options-and-configuration.html).\n\n## Applicability\n\nThis concerns backup-plan scheduling and overlap optimization. A chosen schedule does not establish a guaranteed backup completion time or an application recovery objective.\n\n## DSE recommendation\n\nDSE recommends drawing the daily start windows for every effective rule on one timeline. Calculate the recovery-point pattern produced by overlapping windows before interpreting fewer jobs as a failure. Separate start deadlines from completion deadlines in monitoring. Ask the application owner to approve the resulting gap between usable recovery points, and review maintenance-window conflicts before reducing a start window to force a desired count. Give the recovery owner a simple timeline showing the resulting usable points, not only the configured rule names. Review that timeline whenever another rule is added so a well-intended retention change does not leave an unexplained monitoring expectation.\n\n## Verification\n\nProposed verification: observe a full approved test schedule and compare actual job start times, expiry states and retained recovery points with the planned timeline. Check the longest gap between usable backups. Keep failed-start alerts separate from intentionally optimized overlapping rules so operators can investigate the right condition.\n\n## Official reference\n\n[AWS — Backup plan options and configuration](https://docs.aws.amazon.com/aws-backup/latest/devguide/plan-options-and-configuration.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-backup-restore-test-tag-selection-recovery-point/", "slug": "aws-backup-restore-test-tag-selection-recovery-point", "url": "https://update.dsesecurity.com/updates/aws-backup-restore-test-tag-selection-recovery-point/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-backup-restore-test-tag-selection-recovery-point.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-backup-restore-test-tag-selection-recovery-point/" }, "title": "Check AWS Backup restore-test selection against the recovery point actually restored", "summary": "Tag matching selects protected resources; it does not guarantee the selected historical recovery point has those tags.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:02+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 272, "potentially_affected": "This describes restore-testing selection semantics. Eligibility and resource inclusion are separate from application validation, permissions and successful cleanup of the temporary restored resource.", "dse_recommendation": "DSE recommends listing the protected resources expected in each test before execution.", "primary_source": { "name": "AWS — Restore testing", "url": "https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Tag matching selects protected resources; it does not guarantee the selected historical recovery point has those tags.
\nAWS Backup restore testing first selects protected resources, then restores at most one eligible recovery point for each selected resource. Tag conditions are evaluated against the latest recovery point for resource selection. They do not choose the recovery point restored. The plan then applies its vault, age and latest-or-random criteria. If no recovery point is eligible, the protected resource is omitted from that test.
\nSource: AWS — Restore testing.
\nThis describes restore-testing selection semantics. Eligibility and resource inclusion are separate from application validation, permissions and successful cleanup of the temporary restored resource.
\nDSE recommends listing the protected resources expected in each test before execution. Choose the selection window to fit backup cadence and the allowed start window. Keep a separate field for the recovery point actually chosen, especially when testing random historical backups. Define application validation and cleanup ownership in advance. Investigate missing resources instead of interpreting a completed plan as evidence that every protected workload was exercised. Keep the selection decision and the application validation result as separate lines in the test report. Require an explanation for every expected resource that was omitted, and make the actual restored recovery-point identifier part of acceptance rather than relying on the plan name.
\nProposed verification: compare the expected resource list with actual restore-job resource IDs and recovery-point IDs. Check one deliberately ineligible test resource and confirm its omission is understood. Retain validation findings and deletion status for restored resources; assign cleanup when automatic deletion fails.
\nAWS — Restore testing. Reviewed October 20, 2026.
", "content_text": "Tag matching selects protected resources; it does not guarantee the selected historical recovery point has those tags.\nSource facts\nAWS Backup restore testing first selects protected resources, then restores at most one eligible recovery point for each selected resource. Tag conditions are evaluated against the latest recovery point for resource selection. They do not choose the recovery point restored. The plan then applies its vault, age and latest-or-random criteria. If no recovery point is eligible, the protected resource is omitted from that test.\nSource: AWS — Restore testing.\nApplicability\nThis describes restore-testing selection semantics. Eligibility and resource inclusion are separate from application validation, permissions and successful cleanup of the temporary restored resource.\nDSE recommendation\nDSE recommends listing the protected resources expected in each test before execution. Choose the selection window to fit backup cadence and the allowed start window. Keep a separate field for the recovery point actually chosen, especially when testing random historical backups. Define application validation and cleanup ownership in advance. Investigate missing resources instead of interpreting a completed plan as evidence that every protected workload was exercised. Keep the selection decision and the application validation result as separate lines in the test report. Require an explanation for every expected resource that was omitted, and make the actual restored recovery-point identifier part of acceptance rather than relying on the plan name.\nVerification\nProposed verification: compare the expected resource list with actual restore-job resource IDs and recovery-point IDs. Check one deliberately ineligible test resource and confirm its omission is understood. Retain validation findings and deletion status for restored resources; assign cleanup when automatic deletion fails.\nOfficial reference\nAWS — Restore testing. Reviewed October 20, 2026.", "content_markdown": "Tag matching selects protected resources; it does not guarantee the selected historical recovery point has those tags.\n\n## Source facts\n\nAWS Backup restore testing first selects protected resources, then restores at most one eligible recovery point for each selected resource. Tag conditions are evaluated against the latest recovery point for resource selection. They do not choose the recovery point restored. The plan then applies its vault, age and latest-or-random criteria. If no recovery point is eligible, the protected resource is omitted from that test.\n\nSource: [AWS — Restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html).\n\n## Applicability\n\nThis describes restore-testing selection semantics. Eligibility and resource inclusion are separate from application validation, permissions and successful cleanup of the temporary restored resource.\n\n## DSE recommendation\n\nDSE recommends listing the protected resources expected in each test before execution. Choose the selection window to fit backup cadence and the allowed start window. Keep a separate field for the recovery point actually chosen, especially when testing random historical backups. Define application validation and cleanup ownership in advance. Investigate missing resources instead of interpreting a completed plan as evidence that every protected workload was exercised. Keep the selection decision and the application validation result as separate lines in the test report. Require an explanation for every expected resource that was omitted, and make the actual restored recovery-point identifier part of acceptance rather than relying on the plan name.\n\n## Verification\n\nProposed verification: compare the expected resource list with actual restore-job resource IDs and recovery-point IDs. Check one deliberately ineligible test resource and confirm its omission is understood. Retain validation findings and deletion status for restored resources; assign cleanup when automatic deletion fails.\n\n## Official reference\n\n[AWS — Restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/aws-backup-vault-lock-mode-grace-period/", "slug": "aws-backup-vault-lock-mode-grace-period", "url": "https://update.dsesecurity.com/updates/aws-backup-vault-lock-mode-grace-period/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/aws-backup-vault-lock-mode-grace-period.md", "json": "https://update.dsesecurity.com/api/v1/posts/aws-backup-vault-lock-mode-grace-period/" }, "title": "Choose the AWS Backup Vault Lock mode before its grace period closes", "summary": "A retention lock needs a deliberate mode, expiry review and final decision before it becomes immutable.", "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": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:01+00:00", "modified_at": "2026-10-20T18:34:30+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 282, "potentially_affected": "This concerns AWS Backup Vault Lock and recovery-point lifecycle settings. It does not establish that a particular legal retention requirement is met, or that an application can restore successfully.", "dse_recommendation": "DSE recommends inventorying existing recovery-point expiry dates before proposing a lock.", "primary_source": { "name": "AWS — AWS Backup Vault Lock", "url": "https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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 retention lock needs a deliberate mode, expiry review and final decision before it becomes immutable.
\nAWS distinguishes governance mode, whose lock can be removed by sufficiently authorized users, from compliance mode. A compliance lock becomes unchangeable after its grace period while recovery points remain. New jobs whose retention conflicts with configured minimum or maximum limits fail; those limits do not rewrite recovery points already in the vault. An indefinite recovery point can therefore create a permanent retention commitment.
\nSource: AWS — AWS Backup Vault Lock.
\nThis concerns AWS Backup Vault Lock and recovery-point lifecycle settings. It does not establish that a particular legal retention requirement is met, or that an application can restore successfully.
\nDSE recommends inventorying existing recovery-point expiry dates before proposing a lock. Have the data owner approve the retention schedule and the administrator record the selected mode and exact lock date. Pilot the policy with disposable data. Schedule a decision meeting before the grace period expires, with explicit responsibility for removing an incorrect configuration while changes remain possible. Keep the retention owner and recovery operator separate in the written handoff. Make the final lock review a dated operational task with a named substitute approver. Ask the reviewer to identify the longest-lived existing point and explain its intended retirement, rather than approving only the settings that will affect future jobs.
\nProposed verification: in an approved pilot vault, inspect lock mode, retention bounds and lock date. Submit test jobs with valid and invalid retention values and retain their results. Confirm an existing recovery point keeps its original lifecycle. Review the final configuration before the recorded deadline.
\nAWS — AWS Backup Vault Lock. Reviewed October 20, 2026.
", "content_text": "A retention lock needs a deliberate mode, expiry review and final decision before it becomes immutable.\nSource facts\nAWS distinguishes governance mode, whose lock can be removed by sufficiently authorized users, from compliance mode. A compliance lock becomes unchangeable after its grace period while recovery points remain. New jobs whose retention conflicts with configured minimum or maximum limits fail; those limits do not rewrite recovery points already in the vault. An indefinite recovery point can therefore create a permanent retention commitment.\nSource: AWS — AWS Backup Vault Lock.\nApplicability\nThis concerns AWS Backup Vault Lock and recovery-point lifecycle settings. It does not establish that a particular legal retention requirement is met, or that an application can restore successfully.\nDSE recommendation\nDSE recommends inventorying existing recovery-point expiry dates before proposing a lock. Have the data owner approve the retention schedule and the administrator record the selected mode and exact lock date. Pilot the policy with disposable data. Schedule a decision meeting before the grace period expires, with explicit responsibility for removing an incorrect configuration while changes remain possible. Keep the retention owner and recovery operator separate in the written handoff. Make the final lock review a dated operational task with a named substitute approver. Ask the reviewer to identify the longest-lived existing point and explain its intended retirement, rather than approving only the settings that will affect future jobs.\nVerification\nProposed verification: in an approved pilot vault, inspect lock mode, retention bounds and lock date. Submit test jobs with valid and invalid retention values and retain their results. Confirm an existing recovery point keeps its original lifecycle. Review the final configuration before the recorded deadline.\nOfficial reference\nAWS — AWS Backup Vault Lock. Reviewed October 20, 2026.", "content_markdown": "A retention lock needs a deliberate mode, expiry review and final decision before it becomes immutable.\n\n## Source facts\n\nAWS distinguishes governance mode, whose lock can be removed by sufficiently authorized users, from compliance mode. A compliance lock becomes unchangeable after its grace period while recovery points remain. New jobs whose retention conflicts with configured minimum or maximum limits fail; those limits do not rewrite recovery points already in the vault. An indefinite recovery point can therefore create a permanent retention commitment.\n\nSource: [AWS — AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html).\n\n## Applicability\n\nThis concerns AWS Backup Vault Lock and recovery-point lifecycle settings. It does not establish that a particular legal retention requirement is met, or that an application can restore successfully.\n\n## DSE recommendation\n\nDSE recommends inventorying existing recovery-point expiry dates before proposing a lock. Have the data owner approve the retention schedule and the administrator record the selected mode and exact lock date. Pilot the policy with disposable data. Schedule a decision meeting before the grace period expires, with explicit responsibility for removing an incorrect configuration while changes remain possible. Keep the retention owner and recovery operator separate in the written handoff. Make the final lock review a dated operational task with a named substitute approver. Ask the reviewer to identify the longest-lived existing point and explain its intended retirement, rather than approving only the settings that will affect future jobs.\n\n## Verification\n\nProposed verification: in an approved pilot vault, inspect lock mode, retention bounds and lock date. Submit test jobs with valid and invalid retention values and retain their results. Confirm an existing recovery point keeps its original lifecycle. Review the final configuration before the recorded deadline.\n\n## Official reference\n\n[AWS — AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-the-completed-rollback-target-before-relying-on-an-ecs-circuit-breaker/", "slug": "check-the-completed-rollback-target-before-relying-on-an-ecs-circuit-breaker", "url": "https://update.dsesecurity.com/updates/check-the-completed-rollback-target-before-relying-on-an-ecs-circuit-breaker/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-the-completed-rollback-target-before-relying-on-an-ecs-circuit-breaker.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-the-completed-rollback-target-before-relying-on-an-ecs-circuit-breaker/" }, "title": "Check the completed rollback target before relying on an ECS circuit breaker", "summary": "Automatic rollback requires an eligible prior deployment.", "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": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:14:00+00:00", "modified_at": "2026-10-20T18:34:29+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 235, "potentially_affected": "This applies to the supported ECS rolling-update deployment controller rather than every deployment strategy.", "dse_recommendation": "DSE recommends identifying the known-good deployment and its artifact dependencies before a release.", "primary_source": { "name": "AWS Documentation", "url": "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Automatic rollback requires an eligible prior deployment.
\nThe ECS deployment circuit breaker evaluates whether a rolling deployment reaches steady state. With rollback enabled, it selects the most recent deployment in COMPLETED state. If no eligible completed deployment exists, the deployment stalls without launching new tasks. AWS exposes rollout state, reasons and deployment events for investigation.
\nSource: AWS Documentation.
\nThis applies to the supported ECS rolling-update deployment controller rather than every deployment strategy.
\nDSE recommends identifying the known-good deployment and its artifact dependencies before a release. Review container and load-balancer health checks so the circuit breaker evaluates meaningful readiness. Assign an owner to deployment-failure alerts and record the manual recovery route for a first deployment or missing rollback target. Preserve the expected task definition and rollback evidence. Do not describe the feature as unconditional recovery; include the completed-target requirement in the release checklist. Keep the rollback artifact and task definition identifiable in the release record, with a named person responsible for first-deployment recovery. Ask that person to explain the manual response when no completed target exists before accepting the automated rollback option.
\nProposed verification: use a disposable service with a completed deployment, introduce a controlled failing revision and observe rollout state and rollback events. Review behavior for an initial deployment separately. Confirm the expected healthy task definition returns before reporting a successful recovery test.
\nAWS Documentation. Reviewed October 20, 2026.
", "content_text": "Automatic rollback requires an eligible prior deployment.\nSource facts\nThe ECS deployment circuit breaker evaluates whether a rolling deployment reaches steady state. With rollback enabled, it selects the most recent deployment in COMPLETED state. If no eligible completed deployment exists, the deployment stalls without launching new tasks. AWS exposes rollout state, reasons and deployment events for investigation.\nSource: AWS Documentation.\nApplicability\nThis applies to the supported ECS rolling-update deployment controller rather than every deployment strategy.\nDSE recommendation\nDSE recommends identifying the known-good deployment and its artifact dependencies before a release. Review container and load-balancer health checks so the circuit breaker evaluates meaningful readiness. Assign an owner to deployment-failure alerts and record the manual recovery route for a first deployment or missing rollback target. Preserve the expected task definition and rollback evidence. Do not describe the feature as unconditional recovery; include the completed-target requirement in the release checklist. Keep the rollback artifact and task definition identifiable in the release record, with a named person responsible for first-deployment recovery. Ask that person to explain the manual response when no completed target exists before accepting the automated rollback option.\nVerification\nProposed verification: use a disposable service with a completed deployment, introduce a controlled failing revision and observe rollout state and rollback events. Review behavior for an initial deployment separately. Confirm the expected healthy task definition returns before reporting a successful recovery test.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.", "content_markdown": "Automatic rollback requires an eligible prior deployment.\n\n## Source facts\n\nThe ECS deployment circuit breaker evaluates whether a rolling deployment reaches steady state. With rollback enabled, it selects the most recent deployment in COMPLETED state. If no eligible completed deployment exists, the deployment stalls without launching new tasks. AWS exposes rollout state, reasons and deployment events for investigation.\n\nSource: [AWS Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html).\n\n## Applicability\n\nThis applies to the supported ECS rolling-update deployment controller rather than every deployment strategy.\n\n## DSE recommendation\n\nDSE recommends identifying the known-good deployment and its artifact dependencies before a release. Review container and load-balancer health checks so the circuit breaker evaluates meaningful readiness. Assign an owner to deployment-failure alerts and record the manual recovery route for a first deployment or missing rollback target. Preserve the expected task definition and rollback evidence. Do not describe the feature as unconditional recovery; include the completed-target requirement in the release checklist. Keep the rollback artifact and task definition identifiable in the release record, with a named person responsible for first-deployment recovery. Ask that person to explain the manual response when no completed target exists before accepting the automated rollback option.\n\n## Verification\n\nProposed verification: use a disposable service with a completed deployment, introduce a controlled failing revision and observe rollout state and rollback events. Review behavior for an initial deployment separately. Confirm the expected healthy task definition returns before reporting a successful recovery test.\n\n## Official reference\n\n[AWS Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-ecr-tag-rule-priority-before-explaining-an-unexpired-image/", "slug": "check-ecr-tag-rule-priority-before-explaining-an-unexpired-image", "url": "https://update.dsesecurity.com/updates/check-ecr-tag-rule-priority-before-explaining-an-unexpired-image/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-ecr-tag-rule-priority-before-explaining-an-unexpired-image.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-ecr-tag-rule-priority-before-explaining-an-unexpired-image/" }, "title": "Check ECR tag-rule priority before explaining an unexpired image", "summary": "Tag matching and expiration selection are separate stages in ECR lifecycle evaluation.", "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": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-10-20T18:13:55+00:00", "modified_at": "2026-10-20T18:34:29+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 265, "potentially_affected": "Review tag matching, rule precedence and manifest-list eligibility in ECR lifecycle policies.", "dse_recommendation": "DSE recommends writing a rule matrix for representative release and development digests before diagnosing a cleanup gap.", "primary_source": { "name": "AWS Documentation", "url": "https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html", "published_on": null, "authority": "docs.aws.amazon.com" }, "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": "Tag matching and expiration selection are separate stages in ECR lifecycle evaluation.
\nECR evaluates all lifecycle rules before applying their priorities; a lower number has higher priority. An image can be expired or archived by at most one rule. An image matching a higher-priority rule’s tagging requirements cannot be expired or archived by a lower-priority rule. An image referenced by a manifest list cannot expire or archive before that list is deleted or archived.
\nSource: AWS Documentation.
\nReview tag matching, rule precedence and manifest-list eligibility in ECR lifecycle policies.
\nDSE recommends writing a rule matrix for representative release and development digests before diagnosing a cleanup gap. Include each image’s tags, matching rules, priority numbers and the intended disposition. Check the higher-priority tagging match before widening a lower-priority cleanup pattern or shortening its count or age threshold. A different expiration result may be an intended consequence of precedence rather than a failed cleanup job. Keep approved rollback digests and multi-architecture manifest relationships visible to the release owner. Preserve the exact policy JSON and preview with an explanation for each deliberately retained image, so a later rule edit can be reviewed against the original selection decision.
\nProposed verification: in a controlled repository, preview two overlapping tag rules with different priorities and compare each selected digest with the written matrix. Include an image referenced by a manifest list and inspect its eligibility separately. Confirm the preview and expected precedence agree before authorizing any real cleanup; do not delete production release images merely to demonstrate the rule.
\nAWS Documentation. Reviewed October 20, 2026.
", "content_text": "Tag matching and expiration selection are separate stages in ECR lifecycle evaluation.\nSource facts\nECR evaluates all lifecycle rules before applying their priorities; a lower number has higher priority. An image can be expired or archived by at most one rule. An image matching a higher-priority rule’s tagging requirements cannot be expired or archived by a lower-priority rule. An image referenced by a manifest list cannot expire or archive before that list is deleted or archived.\nSource: AWS Documentation.\nApplicability\nReview tag matching, rule precedence and manifest-list eligibility in ECR lifecycle policies.\nDSE recommendation\nDSE recommends writing a rule matrix for representative release and development digests before diagnosing a cleanup gap. Include each image’s tags, matching rules, priority numbers and the intended disposition. Check the higher-priority tagging match before widening a lower-priority cleanup pattern or shortening its count or age threshold. A different expiration result may be an intended consequence of precedence rather than a failed cleanup job. Keep approved rollback digests and multi-architecture manifest relationships visible to the release owner. Preserve the exact policy JSON and preview with an explanation for each deliberately retained image, so a later rule edit can be reviewed against the original selection decision.\nVerification\nProposed verification: in a controlled repository, preview two overlapping tag rules with different priorities and compare each selected digest with the written matrix. Include an image referenced by a manifest list and inspect its eligibility separately. Confirm the preview and expected precedence agree before authorizing any real cleanup; do not delete production release images merely to demonstrate the rule.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.", "content_markdown": "Tag matching and expiration selection are separate stages in ECR lifecycle evaluation.\n\n## Source facts\n\nECR evaluates all lifecycle rules before applying their priorities; a lower number has higher priority. An image can be expired or archived by at most one rule. An image matching a higher-priority rule’s tagging requirements cannot be expired or archived by a lower-priority rule. An image referenced by a manifest list cannot expire or archive before that list is deleted or archived.\n\nSource: [AWS Documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html).\n\n## Applicability\n\nReview tag matching, rule precedence and manifest-list eligibility in ECR lifecycle policies.\n\n## DSE recommendation\n\nDSE recommends writing a rule matrix for representative release and development digests before diagnosing a cleanup gap. Include each image’s tags, matching rules, priority numbers and the intended disposition. Check the higher-priority tagging match before widening a lower-priority cleanup pattern or shortening its count or age threshold. A different expiration result may be an intended consequence of precedence rather than a failed cleanup job. Keep approved rollback digests and multi-architecture manifest relationships visible to the release owner. Preserve the exact policy JSON and preview with an explanation for each deliberately retained image, so a later rule edit can be reviewed against the original selection decision.\n\n## Verification\n\nProposed verification: in a controlled repository, preview two overlapping tag rules with different priorities and compare each selected digest with the written matrix. Include an image referenced by a manifest list and inspect its eligibility separately. Confirm the preview and expected precedence agree before authorizing any real cleanup; do not delete production release images merely to demonstrate the rule.\n\n## Official reference\n\n[AWS Documentation](https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html). Reviewed October 20, 2026." } ] }