Azure NSG

Import Azure Network Security Group configurations exported with the Azure CLI. netbobr parses Allow rules from NSG JSON, extracting source/destination addresses, protocols, and port ranges for compliance analysis. Azure NSG is the highest-accuracy native cloud format, and the only one that supports Tier 2 rules (both specific source and destination CIDRs).

Export Commands

# Export a single NSG
az network nsg show --resource-group myRG --name myNSG > nsg.json

# Export all NSGs in a resource group
az network nsg list --resource-group myRG > nsgs.json

# Export all NSGs in a subscription
az network nsg list > all-nsgs.json

Supported JSON Shapes

netbobr accepts three JSON structures from the Azure CLI:

Shape 1: Single NSG object (from az network nsg show)

{
  "name": "web-nsg",
  "properties": {
    "securityRules": [
      {
        "name": "allow-https-inbound",
        "properties": {
          "access": "Allow",
          "protocol": "Tcp",
          "direction": "Inbound",
          "sourceAddressPrefix": "10.0.0.0/8",
          "destinationAddressPrefix": "172.16.1.0/24",
          "destinationPortRange": "443",
          "priority": 100,
          "description": "HTTPS from internal to web tier"
        }
      },
      {
        "name": "allow-sql-outbound",
        "properties": {
          "access": "Allow",
          "protocol": "Tcp",
          "direction": "Outbound",
          "sourceAddressPrefix": "172.16.1.0/24",
          "destinationAddressPrefix": "172.16.2.0/24",
          "destinationPortRange": "1433",
          "priority": 200,
          "description": "SQL from web tier to DB tier"
        }
      }
    ]
  }
}

Shape 2: Array of NSGs (from az network nsg list)

A JSON array with a value wrapper containing multiple NSG objects, each with properties.securityRules.

Shape 3: Flat object with securityRules directly

A simplified format where securityRules is a top-level property without the properties wrapper.

Parser Behavior

Access filtering

Only Allow rules are parsed. Deny rules are skipped because netbobr evaluates risk exposure, not enforcement. If you need to see what a Deny rule would block, create an equivalent Allow rule for analysis.

Direction handling

Outbound rules have their source and destination swapped to normalize flow direction. This means if you see a flow that looks "reversed" compared to the NSG rule, it is working as intended -- the parser normalizes all flows to represent the perspective of the traffic initiator.

Port handling

• Port * (any port) maps to 0-65535
• Port ranges like 8000-9000 are preserved
• Multiple ports via destinationPortRanges array produce one flow per port/range

Address handling

• sourceAddressPrefixes and destinationAddressPrefixes arrays are expanded, producing one flow per source/destination/port combination
• Azure NSG is the only cloud format where both source and destination can be specific CIDRs (Tier 2 support)

Service Tag Handling

Azure NSGs use service tags to reference groups of Azure IP ranges. netbobr resolves known tags and warns about unresolvable ones:

Resolved tags

Unresolvable tags (skipped with warning)

The following service tags cannot be resolved to static CIDR blocks because they represent dynamic Azure-managed IP ranges:

VirtualNetwork, AzureLoadBalancer, AzureTrafficManager, GatewayManager, AzureCloud, Storage, Sql, AzureCosmosDB, AzureKeyVault, EventHub, ServiceBus, AzureContainerRegistry, AzureActiveDirectory, AzureMonitor, AppService

Rules using these tags generate a warning:

Azure service tag "VirtualNetwork" in web-nsg rule "allow-internal" cannot be resolved to CIDR

To include these flows, replace service tags with explicit CIDR ranges in your NSG rules or add the flows manually in netbobr.

Accuracy

Azure NSG has the highest accuracy among native cloud formats:

• 91.8% overall -- highest match rate of any single-provider format
• 100% Tier 2 -- the only native format that supports rules with both specific source and destination CIDRs
• 100% field accuracy -- when a flow matches, risk scores, risk levels, and verdicts are identical to the CSV baseline

The 21 unmatched Tier 1 flows involve protocol ANY with full port ranges, where Azure's * port semantics interact with baseline representation.

Troubleshooting

No flows parsed

Verify the JSON has properties.securityRules (single NSG from az network nsg show) or a value array (NSG list from az network nsg list). The raw ARM template format is different from CLI output -- use the CLI commands above to export.

Missing rules

Check if rules use Azure service tags like VirtualNetwork or AzureLoadBalancer. These generate warnings in the import results banner but do not produce flows. Review the warnings to see which tags were skipped.

Outbound flows look reversed

This is expected. Outbound NSG rules have their source and destination swapped during parsing to normalize flow direction. The flow represents traffic from the initiator's perspective.

Deny rules not showing

By design. netbobr only processes Allow rules since it evaluates risk exposure, not enforcement policy. Deny rules are silently skipped.

Rules with multiple address prefixes produce many flows

If a rule uses sourceAddressPrefixes and destinationAddressPrefixes arrays, netbobr creates one flow for each source/destination/port combination. This is correct -- it represents the full cross-product of allowed traffic.

Usage

CLI:

npx @netbobr/cli analyze nsg.json --cloud-format azure-nsg

Browser: Drag and drop the .json file onto the import area. The format is auto-detected.