This example demonstrates a typical public-facing application stack with moderate-to-high sensitivity and a hybrid deployment.
| Scenario | Internet Services | Apps | DBs | Users | Sensitivity | East-West | Recommended Zones | Estimated Rules |
|---|---|---|---|---|---|---|---|---|
| Hybrid commerce | 6 | 18 | 6 | 450 | High | High | 7 | ~1,200 |
| Vendor-heavy SaaS | 10 | 42 | 10 | 1,200 | Regulated | Very high | 9 | ~4,000 |
| Internal tools | 0 | 8 | 2 | 220 | Some PII | Medium | 5 | ~400 |
The calculator produces a Risk Score from 0 to 100 using normalized inputs and weights:
+ 0.16·EastWest + 0.08·CloudMix + 0.06·Availability)
The Recommended Zones are derived from the score, then adjusted for OT and high sensitivity:
The Estimated Rule Count is based on zone-pairs and a density factor driven by service complexity:
Density ≈ 6..35 (depends on apps, databases, exposure, sensitivity, east-west traffic)
Rules ≈ ZonePairs × Density × 0.55
These formulas are planning estimates. Replace assumptions with real application maps, identity boundaries, and change-control requirements for implementation.
- Enter counts for public services, apps, databases, users, and third parties.
- Select sensitivity and traffic to reflect your data scope and east-west complexity.
- Mark constraints like remote administration or OT/ICS networks if present.
- Calculate to generate zone recommendations, flows, and rule sizing.
- Export to CSV or PDF and review with network, security, and app owners.
- Start with default-deny between zones; open only documented flows.
- Prefer identity-based controls for service-to-service traffic where possible.
- Keep a management plane separate; use bastions and session logging.
- Validate the plan with threat modeling and tabletop change scenarios.
Zone count as a governance signal
The planner’s recommended zone count is not just a network diagram metric; it is a governance signal. More zones usually indicate more owners, more change approvals, and more dependency mapping work. When the calculator suggests seven or more zones, treat it as a prompt to formalize request intake, document standard services, and define who clearly can approve cross-zone connectivity.
Risk score inputs that move the needle
Internet-facing services, data sensitivity, and east-west complexity are weighted heavily because they drive attack surface and lateral movement risk. Raising sensitivity from “Some PII” to “Regulated” typically increases segmentation pressure by requiring stronger boundaries for databases, backups, privileged access, and logging. Increasing east-west complexity signals more service-to-service flows, which often benefits from identity-based policies and tighter allow-lists at zone boundaries.
Rule estimate and policy density planning
Estimated rule count is derived from zone pairs and a density factor that grows with application volume, database presence, exposure, and internal traffic. Use this sizing to plan operational capacity: firewall object groups, naming conventions, review cadence, and automated testing of policy changes. If the rule estimate is high, prioritize standard service templates and eliminate “any/any” exceptions. Maintaining fewer, well-justified rules improves audit outcomes and reduces major outage risk.
Common zone patterns that scale
Mature environments tend to stabilize around consistent patterns: an Internet edge zone for routing and filtering, a DMZ for public entry points, an application zone for business logic, and a data zone for sensitive stores. A separate management zone supports bastions, directory services, and privileged tooling. Vendor access often belongs in a distinct third-party zone with strict routes, time bounds, and monitoring. If OT/ICS exists, keep it isolated with minimal conduits and strong inspection.
Using exports in reviews and audits
The CSV export is useful for collaborative review: populate owners per zone, list approved flows, and track exceptions with expiry dates. The PDF is ideal for approvals and evidence, showing the score, the recommended segmentation, and the control checklist. For best results, validate the exported plan against an application dependency map and confirm that logging is centralized and protected from tampering.
FAQs
1) Does the calculator replace a network security assessment?
No. It provides planning estimates and a structured starting point. Confirm results with application dependency mapping, threat modeling, and review of identity, routing, and operational constraints.
2) What should I do if the recommended zones feel too high?
Start with core zones, then add dedicated zones only where boundaries reduce risk materially. Standardize common services and tighten allow-lists before increasing segmentation complexity.
3) How accurate is the firewall rule estimate?
It is a sizing guide based on zone pairs and assumed policy density. Actual counts depend on consolidation, object reuse, application standardization, and whether identity-based controls reduce port rules.
4) Why is a management zone recommended so often?
Privileged access is a frequent attack path. Separating management limits exposure, supports bastion workflows, and centralizes auditing for administrative sessions and sensitive tooling.
5) When should I add a dedicated logging or SIEM zone?
Add it when logs are security-critical, retained for compliance, or need protection from tampering. A dedicated zone helps restrict access and enforce immutable storage and retention policies.
6) How do I turn the example flows into implementable rules?
Replace generic ports with application-approved services, scope sources and destinations to exact objects, add identity or device posture where possible, and require expiry dates for exceptions.