Network Segmentation Approaches
mysidia at gmail.com
Tue May 5 12:52:43 UTC 2015
On Mon, May 4, 2015 at 9:55 PM, <nanog1 at roadrunner.com> wrote:
> There's quite a bit of literature out there on this, so have been
> considering an approach with zones based on the types of data or
> processes within them. General thoughts:
It depends on the users and tasks on the network.. Different
segmentation strategies / tradeoffs get selected by people dependent
upon what there is to be protected, Or where needed to control
broadcast domain size, and value tradeoffs.
Segmenting certain systems, or segmenting certain data, Or more
likely both are called for to mitigate selected risks: both
security risks, as well as network risks, Or to facilitate certain
networks being moved independently to maintain continuity after DR.
> - "Business Zone" - This would be where workstations live,
> but I should [....]
> generally be OK letting anything in this zone talk fairly unfettered
> to anything else in this zone
Since you imply all workstations would live on the same zone as each
other, instead of being isolated or placed into job-role-specific
access segments, then what you have here is a non-segmented network;
It sounds like this begins to look like your generic "non-segmented"
zone "with small numbers of exceptions" strategy; you wind up with a
few huge business zones which tend to become larger and larger over
time -- are really still at highest risk, then a small number of tiny
exception zones such as 'PCI Card Environment' zone, which are okay,
until some users inevitably develop a requirement to connect
workstations from the massive insecure zone to the tiny zone.
Workstations talking to other workstations directly is an example of
one of the higher risk things, that is probably not necessary, but
remains unrestricted by having one single large 'Business' segment.
A stronger segmentation model would be that workstations don't get to
talk to other workstations directly; only to remote devices servicing
data that the user of a given workstation is authorized to be using,
with every flow being validated by a security device.
> I'd probably have VoIP media servers in this zone, AD, DNS, etc.
AD + DNS are definitely applications that should be at a high
integrity protection level compared to generic segment from security
standpoint; Especially if higher-security zones are dependent on
An AD group policy configuration change can cause arbitrary code
execution on a domain-joined server in any segment attached to a
domain using that AD server.
> Presumably I should never allow *outbound* connectivity from a more
> secure zone to a less secure zone, and inbound connectivity should be
> carefully monitored for unusual access patterns.
Never? No internet access?
Never say never, but there should be policies established based on
needs / requirements and dependent on the characteristics of a zone
and the assumed risk level of other zones.
An example for some high risk zone might be that outbound connections
to A, B, and C only through a designated application-layer proxy
itself residing in a security service zone.
> be built off of? I'm especially interested to hear how VoIP/RTP
> traffic is handled between subnets/remote sites within a "Business
> Zone". I'm loathe to put a FW between these segments as it will
> put VoIP performance at risk (maybe QoS on FW's can be pretty good),
The ideal scenario is to have segments dedicated to primary VoIP use,
so VoIP traffic should stay in-segment, except if interconnecting to
a provider, and the firewalls do not necessarily have to be stateful
firewalls; if VoIP traffic leaves a segment, some may use a simple
packet filter or application-aware proxy designed to maintain the
If the security requirements of the org implementing the network are
met, then very specific firewall devices can be used for certain
zones that are the most suitable for that zone's traffic.
> but maybe some sort of passive monitoring would make sense.
More information about the NANOG