20 Critical Security Controls: Control 13 – Boundary Defense
Senior Manager, Corporate Communications
Today’s post is all about Control 13 of the CSIS 20 Critical Security Controls – Boundary Defense (the last post pertained to Control 12). Here I’ll explore the (29) requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found [*].
Key Take Aways
- Use Proxies and Monitor. This Control isn’t bad (though see Improvement Area number one) and it provides what I think is some really great advice. Use proxies when you can, and when you do use proxies detect any traffic bypassing that proxy. The idea is to allow traffic through known locations and monitor based on those “choke points.” Some of those who won’t want to be monitored will try to get around the choke point, which would then, presumably, be detected by appropriate monitoring. Some of those who won’t want to be monitored will simply tunnel out – but you should be able to monitor for that as well.
Potential Areas Of Improvement
- Focus. To me, this Control could easily be merged with Control 19 (Secure Network Engineering) and it should be – appropriate boundary defense is part of engineering a secure network. If what this control is really seeking to convey is how to secure the services you provide through your boundary (i.e. VPN, SMTP, and so on), then the control could be renamed.
- Key Management Requirements. Don’t forget that when you recommend that things can be encrypted or signed that you’re also recommending the key management that comes with it. Key management is not easy, and you won’t be able to rely on your users to do it well – we can’t rely on users to manage their passwords well, right?
Requesting Feedback On
- Requirement 6
- Requirement 10
- Requirement 14
- Requirement 15
- Description: Deny communications with (or limit data flow to) known malicious IP addresses (black lists), or limit access only to trusted sites (white lists).
- Notes: See my notes for requirement three below – essentially, find a service that updates black lists and use it. If you actually know the communication patterns required throughout your organization well enough, then white lists are the way to go. But, ensure that you control IP address changes otherwise using a white list could just be another way in.
- Description: Tests can be periodically carried out by sending packets from bogon source IP addresses (unroutable or otherwise unused IP addresses) into the network to verify that they are not transmitted through network perimeters.
- Notes: I have to be honest with you, I thought bogon was a typo for logon. It turns out that it’s not (http://en.wikipedia.org/wiki/Bogon_(address)). If you have many devices, you’re going to want to manage this blacklist in one location and propagate that list throughout your infrastructure.
- Description: Lists of bogon addresses are publicly available on the Internet from various sources, and indicate a series of IP addresses that should not be used for legitimate traffic traversing the Internet.
- Notes: Find a couple of sources and merge them. Or, find an authoritative source of these and subscribe to the list (here’s one: http://www.team-cymru.org/Services/Bogons/)
- Description: On DMZ networks, monitoring systems (which may be built in to the IDS sensors or deployed as a separate technology) should be configured to record at least packet header information, and preferably full packet header and payloads of the traffic destined for or passing through the network border.
- Notes: Notice the two requirement levels. At a minimum, grab header information. For those who are more advanced, or perhaps under attack by more capable adversaries, then grab entire packets. To determine which is right for you, you’ll need to perform a risk assessment.
- Description: This traffic should be sent to a properly configured Security Event Information Management (SEIM) or log analytics system so that events can be correlated from all devices on the network.
- Notes: I know this makes sense from an industry momentum perspective, but SIEMs have really come under scrutiny lately for being dustware (they’re purchased, then sit on the shelf collecting dust because they’re unusable). If you’re going to get into this, then do so with the knowledge that you need to have competent personnel to manage the SIEM.
- Description: To lower the chance of spoofed e-mail messages, implement the Sender Policy Framework (SPF) by deploying SPF records in DNS and enabling receiver-side verification in mail servers.
- Notes: I don’t know enough about the details of SPF (maybe one of our readers does and can comment), but I know this is worth doing. The work it takes to set this up will be far less than the time and energy it takes to deal with spam and it’s associated issues (spending too much time tuning filtering rules, receiving questions from users, cleaning up after users click on things – and they will).
- Description: Deploy network-based IDS sensors on Internet and extranet DMZ systems and networks that look for unusual attack mechanisms and detect compromise of these systems. These network-based IDS sensors may detect attacks through the use of signatures, network behavior analysis, or other mechanisms to analyze traffic.
- Notes: A simpler way of stating this: Use network IDS especially in externally facing networks such as the DMZ. Everything else seems to make this overly prescriptive.
- Description: Design and implement network perimeters so that all outgoing web, file transfer protocol (FTP), and secure shell traffic to the Internet must pass through at least one proxy on a DMZ network.
- Notes: Good advice and a clear requirement.
- Description: The proxy should support logging individual TCP sessions; blocking specific URLs, domain names, and IP addresses to implement a black list; and applying white lists of allowed sites that can be accessed through the proxy while blocking all other sites.
- Notes: Specific requirements for the proxy mentioned in the previous requirement. Nice. Notice the blacklist integration – remember the service I shared with you above? Take some time to ensure that your proxy is being updated appropriately with that information when it changes (I’d check daily).
- Description: Organizations should force outbound traffic to the Internet through an authenticated proxy server on the enterprise perimeter.
- Notes: This seems pretty clear. Does anyone out there have experiences they can share? How has use of an authenticated proxy helped your organization’s security posture?
- Description: Proxies can also be used to encrypt all traffic leaving an organization.
- Notes: Sure, but only to known locations, right? It’s probably a good idea, though, especially if you’re connected to different geographic locations.
- Description: Require all remote login access (including VPN, dial-up, and other forms of access that allow login to internal systems) to use two-factor authentication.
- Notes: We’ve seen two-factor authentication before, and at that time I claimed that two-factor authentication should be used everywhere. This is no exception. It’s really not that expensive to implement when compared to the safety of what could be compromised. Yes, that’s a blanket statement, so be sure to perform a risk assessment.
- Description: All devices remotely logging into the internal network should be managed by the enterprise, with remote control of their configuration, installed software, and patch levels.
- Notes: The question I have here is this: How is the internal network defined? Does this imply a VPN type of situation, or does it include configuring your iPhone to use the corporate Exchange server? In both cases you have a BYOD problem to consider. I don’t think organizations realize just how much productivity they lose with requirements such as this. I, for example, do not use a corporate-issued machine (sorry IT) to get my real work done. Instead, I use my personal machine with my own software, because I get more done that way (and I’m a geek). There must be a way to allow BYOD and protect the enterprise at the same time. I don’t know what that really looks like, but one solution could use a mix of VMs and services like SpiderOak.
- Description: Periodically scan for back-channel connections to the Internet that bypass the DMZ, including unauthorized VPN connections and dual-homed hosts connected to the enterprise network and to other networks via wireless, dial-up modems, or other mechanisms.
- Notes: If you’re looking for unauthorized VPN connections, you’re going to need a tight list of access rules to check against. Another interpretation of this requirement might be that you need to check for VPN traffic outbound from your internal network to some non-organizationally provided VPN (like one to Amsterdam). If you’re logging all your packets at the boundary (like previous requirements say), then you shouldn’t have a problem looking for common VPN protocols – until you get to an SSL VPN, in which case you’re going to need a list of VPN services and their IP addresses to check the traffic. It seems like host configuration is a better way to go about this – are there any good configuration mechanisms you use to meet this requirement?
- Description: To limit access by an insider or malware spreading on an internal network, organizations should devise internal network segmentation schemes to limit traffic to only those services needed for business use across the internal network.
- Notes: OK. Who out there has guidance for meeting this requirement? I can segment my networks without any meaning and meet this requirement. Some guidance is needed. I believe there was, once upon a time, a PCI Scoping SIG that my have done some public work in this area. Does anyone have advice?
- Description: Develop plans to rapidly deploy filters on internal networks to help stop the spread of malware or an intruder.
- Notes: I don’t know if you need to develop plans here – get your incident detection and response planning down pat and ensure automated configuration deployment. That should be enough. What you want is the ability to update your filtering on demand, and that demand will be driven from incident detection and response.
- Description: To minimize the impact of an attacker pivoting between compromised systems, only allow DMZ systems to communicate with private network systems via application proxies or application-aware firewalls over approved channels
- Notes: It’s all about detection and response at this point. We know that attackers will, when they want, find a way in. Our job is to minimize the time they have to do damage, which is to minimize the time to detect, contain, and expunge. That’s what this requirement is about.
- Description: To help identify covert channels exfiltrating data through a firewall, built-in firewall session tracking mechanisms included in many commercial firewalls should be configured to identify TCP sessions that last an unusually long time for the given organization and firewall device, alerting personnel about the source and destination addresses associated with these long sessions.
- Notes: I’m happy that this is an advanced requirement, because it requires some notion of what normal is before it can work. The catch here, as usual, is that you should do what you can to ensure you’re capturing normal in the first place. Of course, now attackers know that longer sessions are bad, so they’ll turn to slow and low to subvert.
- Description: Deploy NetFlow collection and analysis to DMZ network flows to detect anomalous activity.
- Notes: I’ll be honest with you. I’m not a network security guru. But, I’m educated and well-read enough on flows to know that they can be invaluable when detecting anomalies. In fact, they shouldn’t be relegated to the DMZ (see http://link.springer.com/chapter/10.1007%2F978-0-387-68768-1_1 for more information).
- Description: Packet sniffers should be deployed on DMZs to look for Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies.
- Notes: This can be applied for anything that should traverse a proxy by policy. HTTP, SMTP, FTP, SSH, and so on. By enforcing a proxy, you can detect odd behaviors more easily.
- Description: The system must be capable of identifying any unauthorized packets sent into or out of a trusted zone and ensure that the packets are properly blocked and/or trigger alerts.
- Notes: This is a pretty big metric, but it’s binary. I’d like to see percentages and things of that nature in metrics rather than binary. I’m not sure why.
- Description: Any unauthorized packets must be detected within 24 hours, with the system generating an alert or e-mail for enterprise administrative personnel.
- Notes: Again, 24 hours, as stated in the document, is an upper bound. If there are unauthorized packets traversing your network, notify as quickly as you can, and not just administrative personnel, but your incident response team as well.
- Description: Alerts must be sent every hour thereafter until the boundary device is reconfigured.
- Notes: The obligatory nag.
- Description: To evaluate the implementation of Control 13 on a periodic basis, an evaluation team must test boundary devices by sending packets from outside any trusted network to ensure that only authorized packets are allowed through the boundary. All other packets must be dropped.
- Description: In addition, unauthorized packets must be sent from a trusted network to an untrusted network to make sure egress filtering is functioning properly. The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the unauthorized packets within 24 hours.
- Description: It is important that the evaluation team verify that all unauthorized packets have been detected.
- Description: The evaluation team must also verify that the alert or e-mail indicating that the unauthorized traffic is now being blocked is received within one hour.
- Description: The evaluation team must verify that the system provides details of the location of each machine with this new test software, including information about the asset owner.
- Description: It is also important that the evaluation team test to ensure that the device fails in a state where it does not forward traffic when it crashes or becomes flooded.
Esta noticia ha sido vista por