A widely adopted working-definition of “network security zone” is a group of nodes on a network that are able to communicate without traversing a secured perimeter. As discussed in the preamble, that “secured perimeter” is typically a network firewall, and this matters because network firewalls enforce statefulness in the traffic that they forward.
If two nodes (“A” and “B”) on the network in different network security zones attempt to establish a TCP session with each other, network firewalls that are in-path for that flow will validate the state data of each TCP segment and refuse to forward traffic for which it perceives the TCP state to be invalid. Validating state in this manner requires that the validator see all messages in the TCP session (B->A messages and B->A messages).
If the paths that the network selects for B->A flows and A->B flows don’t include the same set of network firewalls, the aforementioned connections between them will fail.
The Chicken or the Egg
Before we abstract and generalize too much, it’s important to consider what we mean when we use the term “network security zone.”
From an information-security perspective, the essence of a network security zone is the mitigation and partitioning of risk at specific (secured perimeter) nodes. From this persepctive, it is natural/reasonable to consider a network security zone’s defining element as the shared characteristics of the (non-perimeter) nodes that are located “in” that zone.
From a networking perspective, our primary concern is determining the topology of the graph; and what rules to use in selecting paths between nodes in the graph. Looking through that lens:
A *network security zone is a group of nodes in the graph for which:
- There is at least one path between every unique unordered pair of nodes which does not include a secure-perimeter-node
- All nodes in the group with a path to a node not in the group are secured-perimeter-nodes
From our network (topology/pathing) perspective, the “secured-perimeter nodes” are different from all the other nodes in regards to path-selection in particular. Specifically:
- If the selected path from any node (A) to any other node (B) includes a “secured-perimeter-node” (C),
- Then the selected path from node (A) to node (B) must also include node (C)
Note that the requirement is not for fully symmetric bidirectional paths between nodes A and B, just that if a state-enforcing node “C” is present in the A->B path, that node “C” be present in the B->A path.
We previously described the “security-zone” property of nodes as signifying membership in a group of nodes between which there is a path that includes no secured-perimeter nodes. In our formalized graph, we assign each node a “security-zone” property whose “value” is a label used to uniquely identify each such group. This brings us to the proverbial chicken/egg confusion.
We’ve declared that that the security-zone is a group of nodes, with the grouping defined by the topology of the graph and the distribution of “secure perimeter nodes” throughout it. This raises a requirement for all nodes to have a “secure-perimeter-node” (SPN) property (a boolean value). Given an arbitrary graph with any distribution of SPN=true, and SPN=false nodes, we can catalog any existing security zones by enumerating the all between every pair of nodes and evaluating them against our definition.
There is not a corresponding requirement that we assign a corresponding “security zone identifier” property to every node. So, why do we add this additional property to the nodes of our graph? In short, so that we are able to store information (labels to distinguish between security zones) about the graph in the graph. It provides a mechanism for us to encode design intent (with regards to security-zone membership), and a corresponding mechanism for the nodes that will (once we get that far) be responisble path selection to ingest that intent.
Generalizing to “symmetric perimeter zones”
In the preceding section, we explained how and why network firewalls (our “secured-perimeter” nodes) introduce the path selection requirements that they do. They are not the only type of devices that perform stateful enforcement though, and there are other use-cases beyond state enforcement that present the same requirement.
The terms “network security zone” and “secured-perimeter” are overly specific for the behavior we’re modeling, so we will adapt some broader terminology to replace them. Rather than “network security zones”, we will refer to “symmetric perimeter zones” (“SP zones” or “SPZs”) (we will use this term to refer to the zone itself, as well as the name of the node-property carrying the associated label/value). We will likewise re-name the associated node property (which will remain a number expressed in decimal/octet notation) to “symmetric perimeter service” (SPS).
Before we do all of that abstraction though, we need to examine two aspects of network security zones that are directly related to each other, and that we will need our graph-oriented model to model accurately.