Critical Control 5 - Boundary Defence

Published: 2011-10-07
Last Updated: 2011-10-08 01:03:30 UTC
by Mark Hofman (Version: 1)
3 comment(s)

http://www.sans.org/critical-security-controls/control.php?id=5

The next control on the list is boundary defence. It has been recognised by many organisations that protecting the perimeter, whilst important, is no longer what it is all about.  Many organisations have what what we generally consider a hard crunchy outside and a soft squishy centre. The "internal" network is expanding into people's homes via VPN, onto mobile devices, into partner organisations and more. So boundary protection is nowadays more appropriate than perimeter protection. This is reflected in some of the standards that are around (think PCI and various government specific standards). A few years ago internal network segmentation was not very common.  Today we are starting to see more network segmentation within organisations and people are exercising more control over traffic that flows through the network.

Many of the more spectacular breaches in the past year or two have been traced back to client side attacks.  This is where good boundary defences can help reduce the risk.  For example an organisation that has thought about the different types of uses for their network, the location of their data and how that data is to be accessed can start segmenting the network. They can implement measures to control the traffic or monitor it at the different boundaries.  Client side attacks may still work, but the exfiltration of data may be detected and the impact of the breach is reduced as the infected machine no longer has full access to whole network.

When thinking about boundary defence it also pays to think about how traffic is supposed to flow through the environment.  As part of this make sure you have policies in place that help you enforce this flow, e.g. no direct connections to the internet, all traffic must flow through a DMZ, etc. Once you have the architecture straight and you understand how information flows within the environment and how people access it, then it is time to start adding controls.

To control flows between network segments:    

  • Firewalls, external facing and internal.
  • Routers with ACLs (Ok for certain internal uses, but you might want to steer clear of using this as you only defence at the perimeter).
  • Intrusion Prevention System (IPS)
  • Consider jump servers for management of sensitive network segments.



Controlling specific Traffic flows:

  • Web traffic - Web filter to detect malware, filter access to malicious domains, perform URL filtering.
  • Mail - Mail relay in DMZ, Implement Sender Policy Framework (SPF) and/or DKIM to help others identify your authorised mail senders. Use AV/Malware and Anti SPAM filtering in the DMZ. (you might want to do the same on the internal mail filter)
  • Remote Access - Use 2 factor authentication, and control network traffic



Visibility

  • DLP solutions - Monitor all traffic for information regarding your crown jewels.
  • Intrusion Detection - look for threats in traffic flows on the network or use a host IDS to identify specific host threats.
  • Central logging and review (e.g. SIEM).


There are many other ways of defending the boundary, let us know what you have found to be effective.

Mark

3 comment(s)

Comments

If you are referring to ‘jump servers’ as I assume you are (servers dual homed on the separated networks, to allow mgmt of one from another), isn’t this a security weakness?

When we segregate our networks, how do you recommend that we securely administer them?

I’m thinking from a point of view of VLANs on a corporate internal network. For simplicity, let’s say you have three VLANs:

VLAN A: Hosts the domain controllers, common-to-all servers
VLAN B: Hosts all users
VLAN C: Hosts the accounting server(s)

Is this an insecure design method?

Would you put the accounting *workstations* in VLAN B or C?

I assume you’d allow communication like this:

B <--> A (talks both ways)
C <--> A (talks both ways)
B <-!-> C (no talking)


Wouldn’t it be a bad idea to use a ‘jump server’ to sit on the border of the accounting VLAN? Or in this case are the domain controllers and common-to-all servers considered jump servers because they are essentially dual homed between VLANs B & C?


Thoughts?

Thanks for all you do!
With respect to allowing remote access for employees from their homes, do you permit access from their PCs, or do you only allow access via company laptops (thinking VPN)?

Or maybe you only permit access via RDP!

Which would be the preferable solution from a security pov?

I, personally, would not allow a windows box to be accessible from the Internet, but I don't always get my way. :(

Thanks for the content, it is very helpful.
"If you are referring to ‘jump servers’ as I assume you are (servers dual homed on the separated networks, to allow mgmt of one from another), isn’t this a security weakness?"

It reduces the improvement in security gained from segmentation; if you have a physical air gap, that is more secure.

Even with a "jump server"; this can be more secure than not segmenting at all.

Your jump server can be configured to only allow IPSEC secured management traffic from an administrator on the less secure interface.

Other devices on the segmented network might be inherently more vulnerable to attack, hence the segmentation.

Diary Archives