Threat Tribunal

Passwords, Settings and Data Protection

Review application settings, stored credentials and data services as one access path. Removing a password from application code does not help if another widely accessible service exposes the same access or data.

Control pattern. Use managed identities, restricted network paths and one protected place for stored credentials. Rotate credentials, encrypt data, keep each customer's access separate, verify backups and record who accessed personally identifiable information (PII) or other protected customer information.

Fictional Security Examples

Illustrative Data Protection Examples

Illustrative only - not an engagement finding

Long-Lived Cloud Credentials Exist in Source or Build History

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP7 workload identity federation
Business summary
A reusable cloud credential can remain valid after it is deleted from the latest source file because repository history and copied build outputs may still contain a working value.
Assessment profile
Ease of attack
Low effort after obtaining a copyReusable cloud credentials are committed to repository history, copied into build output or retained in a release package.
Impact
Cloud impersonation, cost or data access
  • Anyone who obtains the credential could use paid services as the application.
  • They could reach any protected data that the credential permits.
Detection difficulty
Visible in repository and artifact secret scanning
  • Scan current files, repository history and Azure DevOps build outputs.
  • Do not attempt to use any discovered credential.
Pattern
Example rotation and identity pattern
Expected fix Verification
  1. Expected fix Revoke and rotate exposed material, then review service logs for unauthorized use during its exposed lifetime
    Verification The previous credential must be rejected, and log review must cover its known exposure window
  2. Expected fix Purge the value from current files, repository history, Azure DevOps output, caches and retained artifacts
    Verification Current files, repository history, Azure DevOps output, caches and retained artifacts must contain no copy
  3. Expected fix Replace the credential with an Entra ID managed identity scoped to the required resource operations
    Verification The application must operate through managed identity with only its approved resource permissions
  4. Expected fix If a reusable secret is unavoidable, store it in Azure Key Vault, restrict readers and automate rotation
    Verification A planted test secret must block merge and release
  5. Expected fix Block merge and release when scanning of source history or build output finds a credential
    Verification If a Key Vault secret remains, rotation must complete without an outage and a failed rotation must alert its owner

Related illustrative findings: Key Vault access and secret rotation; secrets in source, Git history and build output.

Illustrative only - not an engagement finding

Passwords and Access Keys Are Stored as Shared Settings

High See where this finding applies on the diagrams: Azure Key Vault · CP4 secrets boundary
Business summary
Treating passwords and access keys as ordinary configuration broadens the number of services and people that can read them and increases the damage caused by any one compromise.
Assessment profile
Ease of attack
Requires access to shared configurationPasswords, access keys or connection strings are stored as ordinary settings that several applications can read.
Impact
Reusable credentials for sensitive services
  • A compromise of any permitted reader could disclose reusable credentials.
  • Those credentials could provide access to more sensitive services or data stores.
Detection difficulty
Visible in configuration store review
  • Classify App Configuration values.
  • Identify every identity that can read them.
  • Check whether Key Vault references and managed identities can provide the same access without a stored credential.
Pattern
Example credential-free access pattern
Expected fix Verification
  1. Expected fix Use managed identity instead of passwords or access keys wherever the target service supports Microsoft Entra ID
    Verification Unauthorized application identities must be denied every tested secret path
  2. Expected fix Store any unavoidable secret in Azure Key Vault rather than App Configuration
    Verification The public web workload must be unable to read backend credentials or equivalent reusable values
  3. Expected fix Give each workload a separate identity and narrowly scoped permission to the specific secret it needs
    Verification Approved services must complete their work through managed identity or narrowly scoped Key Vault access
  4. Expected fix Automate secret rotation and alert on failed or overdue rotation
    Verification A test rotation must complete without an outage, and failed or overdue rotation must alert its owner
  5. Expected fix Prevent the public web workload from reading backend credentials or equivalent reusable values
    Verification The App Configuration inventory must contain no password or access key that belongs in Key Vault

Related illustrative findings: source credentials; frontend configuration access.

Illustrative only - not an engagement finding

Deleting a Record Can Leave Related Files and Queue Items Behind

Medium See where this finding applies on the diagrams: data and configuration zone
Business summary
A deletion can appear complete to a user while copies remain in storage or processing queues, creating privacy, retention and incident-response obligations that the application can no longer track reliably.
Assessment profile
Ease of attack
Triggered by partial failure or retryAn application deletes its database record while uploaded files or derived objects remain in storage after a partial failure.
Impact
Unexpected retention of customer data and PII
  • Customer records, uploaded documents or PII could remain beyond their intended retention period.
  • It could become disconnected from normal access and deletion controls.
Detection difficulty
Requires testing deletion when a step fails midway
  • Trace deletion across Cosmos DB records, Blob Storage files and Queue Storage work items.
  • After retries or interrupted processing, compare every remaining item with the expected state.
Pattern
Example lifecycle-reconciliation pattern
Expected fix Verification
  1. Expected fix Make the application own one explicit deletion state across Cosmos DB, Blob Storage and Queue Storage
    Verification Normal access to a test record must stop as soon as deletion begins
  2. Expected fix Block normal access as soon as deletion starts
    Verification Interrupt each Cosmos DB, Blob Storage and Queue Storage cleanup stage, then retry the operation
  3. Expected fix Make every cleanup step safe to retry and record which resources have completed
    Verification Repeated cleanup calls must not restore data or create duplicate work
  4. Expected fix Send exhausted retries to an owned recovery path instead of silently abandoning partial deletion
    Verification Exhausted retries must appear in the owned recovery path
  5. Expected fix Retain a minimal completion record containing no PII, document content or credentials, showing that every related item reached its approved deleted or retained state
    Verification Every related item must reach its approved deleted or retained state with a completion record containing no PII, document content or credentials

Related illustrative findings: investigation evidence; protected record updates in the companion review.

Illustrative only - not an engagement finding

Unused Settings Still Point to a Retired Service

Low See where this finding applies on the diagrams: App Configuration edges
Business summary
Stale destinations make deployments harder to reason about, create noisy failures and can route traffic unexpectedly if an abandoned name is later reused.
Assessment profile
Ease of attack
Requires configuration influenceAn unused setting continues to reference a service destination that has been renamed, retired or never provisioned.
Impact
Routing ambiguity and operational failure
  • A stale value could send traffic to the wrong place.
  • It could create confusing errors.
  • It could make it unclear which setting is correct.
Detection difficulty
Visible when configuration is reconciled against live services
  • List App Configuration settings.
  • Trace how the API and worker use each setting.
  • Separate active settings from values kept only for compatibility.
Pattern
Example startup-validation pattern
Expected fix Verification
  1. Expected fix Keep one versioned, authoritative schema and owner for application settings
    Verification A clean deployment must contain only settings defined by the authoritative schema
  2. Expected fix Remove stale and duplicate App Configuration values
    Verification Unknown, deprecated and conflicting settings must fail deployment
  3. Expected fix Reject unknown, deprecated or conflicting settings during deployment
    Verification A deliberately invalid required destination must stop startup before the API or worker serves traffic
  4. Expected fix Validate every required setting when the API and worker start
    Verification The startup error must be clear without exposing a credential or sensitive value
  5. Expected fix Stop before serving traffic with a clear, non-sensitive error when a required destination or value is invalid
    Verification A valid versioned configuration and its approved rollback version must both start successfully

Related illustrative findings: destination trust; build-input consistency.