Threat Tribunal

Threat Tribunal · Demonstration Review

Azure Cloud Security Review

A demonstration of how the review maps a running Azure environment, gathers safe read-only evidence, checks access at every boundary, and verifies monitoring and controlled releases.

Audience Security leaders, architects and operators Evidence Safe read-only Azure inspection Coverage Architecture, deployment and operations Companion AI/LLM and application review Formats Chaptered · single page for reading or print

Informed by OWASP LLM Top 10 OWASP Top 10 / ASVS NIST AI RMF (GenAI Profile) MITRE ATLAS / CWE Microsoft Zero Trust

Executive Summary

Cloud-security conclusions should be tied to the environment that is actually deployed, not inferred solely from diagrams or infrastructure templates.

This review method starts by reconstructing what is actually deployed in Azure and how data moves through it from start to finish. It then uses safe, read-only records to examine identities, network boundaries, settings, stored credentials, data services, containers, releases, logging and alerts.

The resulting architecture view shows which service path each security control protects.

Assessment Principle

  • Treat every cloud claim as a statement that needs a reproducible source, a clear explanation of what the evidence can and cannot prove, and an explicit confidence level.

Scope and What the Evidence Can Prove

The Example System

Click or tap a zone or checkpoint on the diagram to jump to the related illustrative security examples.

Component diagram of a fictional Azure platform. A browser connects through Microsoft Entra ID to a web app, API and background worker in Azure Container Apps. The worker uses Azure AI Document Intelligence and Azure OpenAI, then stores results in Azure data services. Azure DevOps handles planned releases, while Azure Monitor and Log Analytics collect security events.
The illustrative reference platform assessed across both reports. The architecture is fictional and representative: it names Azure services to anchor the review method and contains no client environment details. See also the document-processing flow and the trust-boundary view.

What We Check in Each Azure Service

Azure service What we check What could go wrong
Application hosting and delivery
Azure Container Apps Who can reach the application, which identity each service uses and which restrictions apply while containers run
  • A public application address accepts requests without checking identity
  • Services share an identity with too much access
  • A container can change its own system files
Azure Container Registry Who can upload or download container images, whether the built-in administrator account is enabled and whether releases use a fixed image version
  • Administrator credentials are reused
  • Anyone can download images
  • A release name can later point to different software
Data, configuration and secrets
Azure Blob + Queue Storage Who can connect, which networks can reach stored files and work items, and when they are deleted
  • Applications use shared storage keys
  • Storage remains reachable from public networks
  • Deleting a record leaves files or work items behind
Azure Cosmos DB How people and applications sign in, which records each role can read or change and which database actions the application exposes
  • Applications use reusable database keys
  • Roles can reach too much data
  • Database connection details are stored in settings
Azure App Configuration Which settings each application can read and whether secrets are kept in Azure Key Vault instead of stored as ordinary values
  • Every application can read the same settings
  • Passwords or access keys are stored as ordinary text
Azure Key Vault Who can read or list secrets, how deleted secrets are protected and whether applications retrieve them directly from the vault
  • People or applications can read every secret
  • Deleted secrets can be permanently removed
  • Secrets are copied into other settings
Identity and operations
Microsoft Entra ID How users sign in, which identities applications use and what each role is allowed to do
  • Applications rely on long-lived secrets
  • Roles gain more access than they need and keep it
Azure Monitor + Log Analytics Which security events are recorded, how long logs are kept and who receives each alert
  • Access to stored data is not recorded
  • Logs disappear before an investigation
  • Alerts reach no named owner

Review Areas

Each review area has its own page with worked, explicitly fictional severity examples.

Relationship to the Application Review

This review leads with deployed configuration and cloud identity: which services are reachable, which identities can use them and whether monitoring and release controls are active. The Application review proves the companion boundary in source code, customer-record authorization, AI handling and application tests.

See how the Application review verifies behaviour inside the deployed boundary.

What You Are Reading

This demonstration shows what a Threat Tribunal engagement delivers and how each chapter uses evidence.

This site contains no client names, identifiers, resource names, source paths, or any combination of details that could reconstruct a client environment.

Cross-reference links lead only to fictional examples created for this demonstration. They never lead to client code, Azure resources or engagement test output.

Limitations

This report explains what the review covers, how it works and what it checks. It does not include client findings, ratings, evidence, fix status or current cloud settings.

It is not a penetration test, certification or assurance opinion. Inclusion of a topic means it was assessed, not that a finding existed.

Public References