Is inbound and outbound traffic to critical servers restricted using an allow-list approach?
Servers have small, predictable communication patterns. That makes them the place where allow-listing is actually practical.
What the carrier is actually asking
The carrier is asking whether inbound and outbound traffic to critical servers is restricted to explicitly permitted sources and destinations, rather than being generally permitted within the network.
Why it is underwritten
Restricting inbound limits which compromised device can reach a server. Restricting outbound prevents a compromised server from reaching command and control infrastructure or shipping data out. Both apply directly to the sequence a ransomware operator follows.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Cloud workloads make this measurable through network security groups and private endpoints.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Azure | Network security group rules on critical workload subnets | Inbound restricted to the tiers that need access, on the ports they need |
| Azure | Outbound rules on those subnets | Egress restricted to known destinations rather than the default allow-internet rule |
| Azure | Application security groups | Rules expressed by workload role rather than by address, which keeps the allow-list maintainable |
| Azure | Private endpoints for platform services used by those servers | Platform traffic on private paths, which reduces what egress rules must permit |
| On-premises | Access control lists in front of critical server segments | Bidirectional restriction. Attested |
Allow-listing the whole estate is a programme. Allow-listing the domain controllers, the database servers, and the backup infrastructure is a week of work and covers the systems that determine the severity of a ransomware event.
What a defensible yes requires
- Critical servers are identified explicitly.
- Inbound access is restricted to specific sources and ports.
- Outbound is restricted to known destinations rather than left at the default.
- Rules are expressed by role so they remain maintainable.
- Backup infrastructure is included, since it is the highest-value target.
How this answer goes wrong
Inbound rules are tight and outbound is entirely unrestricted, which is the default in most cloud networks. A compromised server can reach any address on the internet, which is all an implant needs.
Frequently asked
Is this practical?
For servers, yes, because their communication patterns are stable. It is much harder for user devices, which is why the question names servers.
What counts as critical?
Domain controllers, databases holding regulated data, backup infrastructure, and anything internet-facing. Define it narrowly enough to actually implement.
How do we build the allow-list?
Observe traffic first using flow logs, then restrict. Building rules from observed behaviour avoids breaking things you did not know were connected.
Does this replace segmentation?
It is segmentation applied at the workload level. Both answers should be consistent.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture