Network Security Group (NSG)

What the NSG does in Azure network security

An NSG is a stateful filtering control for Azure traffic paths. It sits on subnets and network interfaces to allow or deny flows, which makes it one of the first places analysts look when a workload is unexpectedly reachable, isolated, or unable to communicate during an incident.

Because NSGs operate at the network boundary, they often determine whether a compromise can move laterally, whether management access is possible, and whether a containment action will actually hold. For broader Azure context, the Microsoft Azure Security Guide places NSGs alongside identity, logging, and platform hardening controls.

How NSG rules shape traffic decisions

NSG behaviour is driven by ordered rules, priorities, directions, and source and destination scopes. The practical point is not just whether a rule exists, but which rule wins when multiple entries overlap, and whether the rule set actually reflects the intended network boundary.

That makes NSGs useful for segmentation between application tiers, for reducing exposed management ports, and for enforcing basic east-west and north-south traffic boundaries. In Azure, those decisions are usually interpreted together with ASGs, route design, private endpoints, and flow logs, which is why the Azure Virtual Network Security Guide is the most direct companion reference.

Where NSGs fit in incident response and investigation

In investigations, an NSG helps answer a simple but important question: did the network path permit the alerting traffic at all? If a service was compromised, the NSG may explain why a scanner, attacker, or containment step succeeded or failed, especially when the workload is behind multiple Azure networking layers.

Analysts should treat NSG state as evidence about exposure, not proof of safety. A workload can still be risky even when the NSG is restrictive, because compromise may arrive through allowed management channels, internal east-west paths, or other trusted routes. The broader investigation model is covered well in the Cloud Network Security Guide, which ties boundary controls to inspection and egress decisions.

Common NSG mistakes and operational trade-offs

NSGs are easy to misapply when teams assume a single rule set fully defines exposure. In practice, traffic may be affected by route tables, other Azure controls, platform defaults, and the placement of the NSG itself. That means an apparently “blocked” service can still be reachable through a different interface or a different segment.

Another common trade-off is between tight segmentation and day-two operability. Overly broad allow rules simplify troubleshooting but expand blast radius, while overly narrow rules can break patching, monitoring, or administrative access. For a concrete Azure hardening view, the Cloud Misconfiguration Guide shows how open ports, drift, and default settings create exposure.

Risk and Threat Considerations

NSGs reduce exposure, but they can also create a false sense of containment if the rule set is stale, overly broad, or misunderstood. The main risk is that a workload appears segmented while still allowing the exact traffic an attacker needs for scanning, pivoting, or command-and-control.

Failure mechanism: Weak rule design, rule precedence mistakes, or drift between intended and deployed policy can leave management ports, internal services, or outbound paths open enough for exploitation or lateral movement.

Impact: Attackers may reach sensitive workloads, move between subnets, or preserve access even after partial containment, which turns a network control into an incomplete barrier rather than a real boundary.

Practitioner Guidance

Why practitioners should care: Treat NSGs as an enforceable part of the Azure attack surface, not as a checkbox. The value comes from matching the rule set to the workload’s actual communication needs and from verifying that the deployed boundary matches the design.

What to watch for: Pay close attention to broad allow rules, inherited defaults, asymmetric expectations between subnet and NIC placement, and changes that bypass intended segmentation. If an alert or containment action does not behave as expected, the NSG is one of the first places to verify.

Practitioner takeaway: Use NSGs to prove where traffic is supposed to flow, then confirm that logging, routing, and adjacent Azure controls support that same boundary in practice.

Related resources from NHI Mgmt Group

• Guide: Network Security Guide
• Security Group
• Group
• What is the difference between using security group references and using IP ranges for AWS network controls?
• How do you detect Azure network security group changes?