Tag: Security

Nutshell Series

🛡️ Setting Up a DMZ in Azure: Approaches & Best Practices

Manjunath

A DMZ (Demilitarized Zone) in Azure is a network security boundary where incoming and outgoing internet traffic is inspected and controlled before reaching backend workloads. Unlike on-premises, Azure provides multiple virtualized patterns to achieve the same security principles.

1. DMZ with Azure Firewall (Recommended)

  • Place an Azure Firewall in a Hub VNet (DMZ subnet).
  • All inbound/outbound traffic flows through the firewall.
  • Use DNAT for inbound internet traffic (public IP → private workload).
  • Use SNAT for outbound traffic to hide internal IPs.
  • Combine with Application Gateway (WAF) for L7 protection.

Use case: Centralized security, enterprise landing zones, compliance-heavy apps.

2. DMZ with Network Virtual Appliances (NVA)

  • Deploy 3rd party firewalls (Fortinet, Palo Alto, CheckPoint, Cisco ASA) in a DMZ subnet.
  • NVAs provide advanced features like IPS/IDS and SSL inspection.
  • Route internet traffic → NVA → internal VNets.
  • Requires high availability setup (at least 2 NVAs).

Use case: Enterprises with existing firewall vendor lock-in or advanced packet inspection needs.

3. DMZ using Application Gateway + WAF

  • Use Azure Application Gateway (AGW) with WAF as the public-facing endpoint.
  • Only web workloads (HTTP/HTTPS) are exposed.
  • AGW forwards traffic to backend workloads in private VNets.
  • Can be combined with Azure Firewall for layered security.

Use case: Web applications needing L7 security and SSL offloading.

4. DMZ with Bastion Host for Admin Access

  • Use Azure Bastion instead of exposing RDP/SSH via public IPs.
  • Admins log in securely through the Azure Portal over SSL.
  • No inbound ports (22/3389) exposed to the internet.

Use case: Secure administration of VMs without VPN.

5. DMZ in Hub-and-Spoke Architecture

  • Hub VNet = DMZ containing Azure Firewall, Bastion, VPN/ExpressRoute Gateway.
  • Spoke VNets = Workloads such as apps, databases, and services.
  • Internet and on-prem traffic always flows through the Hub (DMZ).

Use case: Enterprise-scale setups with centralized governance.

6. DMZ with Azure Front Door + WAF

  • Use Azure Front Door (AFD) as the global edge entry point.
  • Provides DDoS protection, WAF, SSL offloading, and global load balancing.
  • AFD forwards traffic → App Gateway/Azure Firewall → backend workloads.

Use case: Global apps needing low latency, DDoS protection, and CDN caching.

đź”’ Best Practices for Azure DMZ

  • Enable Azure DDoS Protection on the VNet hosting the DMZ.
  • Use NSGs (Network Security Groups) for subnet-level filtering.
  • Apply User Defined Routes (UDRs) to force traffic through Firewall/NVA.
  • Keep the DMZ in its own subnet, separate from workloads.
  • Log all DMZ traffic to Azure Monitor / Sentinel for auditing.

âś… Summary

  • Modern cloud-native apps: Azure Firewall + Application Gateway (WAF).
  • Web-only apps: Application Gateway WAF or Front Door WAF.
  • Legacy lift-and-shift: NVAs replicate on-prem firewall policies.
  • Enterprise landing zones: Hub-and-Spoke with DMZ hub.
Security

Cybersecurity Frameworks & Standards: Quick Reference

Manjunath

Use this cheat sheet to quickly match popular cybersecurity frameworks and regulations to the industries that rely on them. Each entry includes a short description to help you pick the right control set for audits, assessments, or roadmap planning.

At a Glance

Cybersecurity Frameworks & Standards Cheat Sheet
Framework / Standard Primary Industry / Sector Brief Description
ISO 27001 Finance, healthcare, IT, government International standard for establishing, implementing, maintaining, and continually improving an ISMS (information security management system).
NIST Cybersecurity Framework (NIST CSF) Critical infrastructure (energy, healthcare, finance, transportation) Risk-based guidance organized around Identify, Protect, Detect, Respond, and Recover functions.
HIPAA Healthcare providers, health plans, clearinghouses U.S. regulation protecting the privacy and security of protected health information (PHI).
PCI DSS Merchants, financial institutions, payment processors Security standard for safeguarding cardholder data and reducing payment card fraud.
GDPR Any organization handling EU residents’ personal data EU regulation granting data privacy rights and setting obligations for data controllers and processors.
CIS Controls Organizations of all sizes and sectors Prioritized set of practical security controls to defend against common cyberattacks.
HITRUST CSF Healthcare organizations and business associates Certifiable framework that harmonizes requirements from HIPAA, NIST, ISO, and others.
COBIT All industries IT governance and management framework aligning technology with business objectives.
NERC CIP Electric utilities, power generation companies Standards for protecting the bulk electric system in North America.
FISMA U.S. federal agencies and contractors U.S. law requiring comprehensive information security programs for federal information and systems.
SOC 2 SaaS providers, managed service providers, data centers, cloud platforms Attestation report evaluating controls against Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.
CCPA Businesses collecting personal information from California residents California law providing consumer data privacy rights and business obligations.
CISA Telecoms Framework U.S. telecommunications providers Guidance and best practices for securing telecommunications infrastructure and services.
NIST SP 800-53 U.S. federal agencies and organizations Catalog of security and privacy controls for federal information systems and organizations.
NIST SP 800-171 Non-federal organizations handling CUI Requirements to protect controlled unclassified information (CUI) for the U.S. government.
UK Telecoms (Security) Act 2021 Telecommunications companies operating in the United Kingdom Legal obligations to strengthen security and resilience of UK telecom networks.

How to Use This Cheat Sheet

  • General maturity: Start with ISO 27001 or NIST CSF for a broad security program.
  • Industry specifics: Apply HIPAA/HITRUST for healthcare, PCI DSS for payments, and NERC CIP for energy.
  • Privacy: Map your data practices to GDPR and CCPA obligations.
  • Cloud & services: Use SOC 2 to demonstrate assurance to customers and partners.

Notes & Caveats

  • Frameworks are complementary—organizations often implement more than one.
  • Scope and applicability depend on your data types, geography, and contractual obligations.
  • Always consult current official documentation before audits or certifications.

Last updated: August 2025.

Nutshell Series

Fixing Azure Token Issuer Mismatch Error: “Primary Access Token is from the Wrong Issuer”

Manjunath

A short troubleshooting guide for developers using Azure CLI and C# SDKs

I recently ran into a frustrating Azure authentication error while working with ARM (Azure Resource Manager) APIs.
The error looked like this: 

Cache-Control: no-cache
Pragma: no-cache
WWW-Authenticate: Bearer authorization_uri="https://login.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", error="invalid_token", error_description="The primary access token is from the wrong issuer. It must match the tenant associated with this subscription. Please use correct authority to get the token."
x-ms-failure-cause: gateway
x-ms-request-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

The Problem

The critical clue was:

The primary access token is from the wrong issuer. It must match the tenant associated with this subscription.

When I decoded the token using JWT.io, the iss (issuer)
claim was: 

f8cdef31-a31e-4b4a-93e4-5f571e91255

That GUID is the Microsoft Services tenant — it appears when you sign in with a personal Microsoft account (MSA).
My Azure subscription, however, was tied to a specific Azure Active Directory (AAD) tenant, so Azure rejected the token because the issuer didn’t match.

What Caused It

  • I logged in using a personal Microsoft account (MSA).
  • The subscription belonged to an Azure AD tenant (not the Microsoft Services tenant).
  • Using VisualStudioCodeCredential or DefaultAzureCredential still returned tokens from the wrong issuer because the underlying login session was wrong.

Solution — Steps to Fix

The fix is straightforward: log into the correct tenant, set the subscription, and use credentials that respect the CLI session.

1) Log in to the correct tenant

az login --tenant <your-tenant-id>

2) Set the subscription

az account set --subscription <your-subscription-id-or-name>

3) Use Azure CLI credentials in C#

Instead of DefaultAzureCredential, switch to AzureCliCredential and fetch the token directly (this uses the Azure CLI credentials stored during az login — so make sure you’re logged in from the terminal):

// using Azure.Identity and Azure.Core
// var credential = new DefaultAzureCredential();
var credential = new AzureCliCredential();

string[] scopes = new[] { "https://management.azure.com/.default" };

var token = (await credential.GetTokenAsync(new TokenRequestContext(scopes))).Token;

// Optional alternative with explicit cancellation token
// token = (await credential.GetTokenAsync(new TokenRequestContext(scopes),
//     System.Threading.CancellationToken.None)).Token;

Note: This uses Azure CLI credentials stored during az login, so ensure you are logged in to the correct tenant and subscription in your terminal before running this code.

Key Takeaways

  • If your JWT iss claim is f8cdef31-a31e-4b4a-93e4-5f571e91255, you’re using a Microsoft Services tenant token (MSA) — it won’t work for subscriptions tied to an Azure AD tenant.
  • Fix the login by targeting the correct tenant with az login --tenant <tenant-id> and then set the subscription with az account set --subscription <subscription-id-or-name>.
  • Using AzureCliCredential in C# picks up tokens from your active Azure CLI session and helps avoid issuer mismatch issues.