Front cover - IBM Redbooks

146 Lotus Security Handbook
At this point we have defined the four types of security zones and the various
types of firewall functions we can implement at the zone boundaries. The last
stage of the model involves defining the criteria we will use to determine what
zone a particular system should be located in, and what firewall functions we
need to provide on the data flows between zones. We will be able to make these
determinations by defining our data flow policies, meaning how must we protect
data of various classifications that is traversing two zones.
4.2.4 Interzone connectivity: Data flow policies
Now that we have defined our four types of security zones and the firewall
functions we can employ at the various boundaries between any two adjacent
zones, we next need to know how to apply these building blocks in a practical
network architecture design. We need to define rules for connectivity between
zones that support our organization’s security policy.
In fact, the data flow policies are an integral part of our security policy. We do not
want to undermine or bypass the business purpose behind separation of
resources into specific zones by providing improper connections. We need
specific security controls for communication between different zones. Some of
the controls we will require are provided by the zone boundary firewall devices,
while other controls must be provided by the hosts, the host applications, or both.
We first describe the criteria we use to categorize data flow policies. So what do
we mean by data flow policies? We simply mean we have policies or rules for a
client in “zone x” to communicate with a server in “zone y.” This is assuming a
client in zone x is permitted to connect to a server in zone y under at least one
set of criteria. Keep in mind that data flows are defined uni-directionally. The
requirements for one direction of data flow may be different for flow in the
opposite direction. Our data flow policies are directionally dependent.
In our four-zone model, we allow for multiple Proxy zones and Data Access
zones. There is by definition only one Internet zone, and for practical purposes,
one Intranet zone. In some organizations, there are multiple Intranets, but in our
experience this is usually not by intention but is a product of circumstances such
as mergers or international organizational separations. Although the typical
Intranet has several subnets and routers, there is normally little to no filtering
being done within the Intranet itself. Figure 4-8 depicts the logical connections
we are going to allow for our four types of zones.