Network Segmentation Approaches

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;
that is:

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
those services.

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
performance.

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.

--
-JH