[179713] in North American Network Operators' Group
RE: Network Segmentation Approaches
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Tue May 5 09:01:16 2015
X-Original-To: nanog@nanog.org
Date: Tue, 05 May 2015 07:01:11 -0600
In-Reply-To: <20150505025540.GA19516@bludgeon.org>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
It is called the Purdue Enterprise Reference Architecture ...
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of
> nanog1@roadrunner.com
> Sent: Monday, 4 May, 2015 20:56
> To: nanog@nanog.org
> Subject: Network Segmentation Approaches
>
> Possibly a bit off-topic, but curious how all of you out there segment
> your networks. Corporate/business users, dependent services, etc. from
> critical data and/or processes with remote locations thrown in the mix
> which could be mini-versions of your primary network.
>
> 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:
>
> - "Business Zone" - This would be where workstations live,
> web browsing occurs, VoIP and authentication services live too.
> Probably consider this a somewhat "dirty" zone, but I should
> generally be OK letting anything in this zone talk fairly unfettered
> to anything else in this zone (for example a business network at my
> HQ location should be able to talk unfettered to an equivalent
> network at a remote site).
>
> I'd probably have VoIP media servers in this zone, AD, DNS, etc.
>
> - Some sort of management zone(z) - Maybe accessible only via jump host
> -- this zone gives "control" access into key resources (most likely
> IT resouces like network devices, storage devices, etc.). Should
> have sound logging/auditing here to establish access patterns outsid
> the norm and perhaps multi-factor authentication (and of course
> FW's).
>
> - Secure Zone(s) - Important data sets or services can be isolated from
> untrusted zones here. May need separate services (DNS, AD, etc.)
>
> - I should think carefully about where I stick stateful FW's --
> especially on my internal networks. Risk of DoS'ing myself is high.
>
> 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.
>
> Perhaps some of you have some fairly simple rules of thumb that could
> 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),
> but maybe some sort of passive monitoring would make sense.
>
> (Yes, I've also read the famous thread on stateful firewalls[1]).
>
> Thanks!
>
> [1]
> http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc7=
4
> fuu2+state:results
