On Mon, May 4, 2015 at 9:55 PM, <nanog1@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