This is Part 13 of a 'How-To' effort to compile a list of tools (free and commercial) that can help IT administrators comply with what was formerly known as the "SANS Top 20 Security Controls". It is now known as the Center for Internet Security (CIS) Security Controls. A summary of the previous posts is here:
Part 1 - we looked at Inventory of Authorized and Unauthorized Devices.
Part 2 - we looked at Inventory of Authorized and Unauthorized Software.
Part 3 - we looked at Secure Configurations.
Part 4 - we looked at Continuous Vulnerability Assessment and Remediation.
Part 5 - we looked at Malware Defenses.
Part 6 - we looked at Application Security.
Part 7 - we looked at Wireless Access Control.
Part 8/9 – we looked at Data Recovery and Security Training.
Part 10/11 - we looked at Secure Configurations for Network Devices such as Firewalls, Routers, and Switches and Limitation and Control of Network Ports, Protocols and Services.
Part 12 - we looked at Controlled Use of Administrative Privileges
Now we are taking on Boundary Defense.
13-1 - Deny communications with (or limit data flow to) known malicious IP addresses (black lists), or limit access only to trusted sites (whitelists).
This is one of those, "Easy to say, hard to do, policies." But if you consider starting with things like public servers, internal servers, switches, VOIP phones, and other network device VLANs, really, those devices don't need much access to the internet, and whitelisting becomes a bit easier. For workstations...good luck, unless you're a military contractor.
13-2 - On DMZ networks, configure monitoring systems (which may be built in to the IDS sensors or deployed as a separate technology) 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. This traffic should be sent to a properly configured Security Information Event Management (SIEM) or log analytics system so that events can be correlated from all devices on the network.
See section 3-8 for tools
13-3 - 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.
- SPFwizard - create your SPF record for free online.
- MXToolBox - Test your SPF and other domain records
- Learn more about SPF
13-4 - 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.
Look at section 5-8. Both of these tools provide signature and/or anomaly based network intrusion detection.
13-5 - Network-based IPS devices should be deployed to complement IDS by blocking known bad signature or behavior of attacks.
- Suricata - I rarely see this tool used alone, since it is so popular among vendors it is often included with larger security appliances for its IPS features.
- Snort - Probably the most used open source IPS. Don't forget to get an OinkCode!
Most Firewall devices offer network IPS.
13-6 - 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. The proxy should support logging individual TCP sessions; blocking specific URLs, domain names, and IP addresses to implement a black list; and applying whitelists of allowed sites that can be accessed through the proxy while blocking all other sites. Organizations should force outbound traffic to the Internet through an authenticated proxy server on the enterprise perimeter. Proxies can also be used to encrypt all traffic leaving an organization.
The immediate security risks of not implementing this control are not completely obvious. You are effectively whitelisting outbound communication through a channel that monitors everything. This makes data-exfiltration very difficult, and enforces your company's internet acceptable use policy by eliminating means whereby users can circumvent network controls (like content blockers).
Most modern firewalls provide transparent and non-transparent proxy servers. However, this can severely degrade total throughput. Consider:
- Squid - Standalone proxy server.
- IP Fire - open source firewall/proxy that uses squid.
- Endian - One of my personal favorites. It also uses squid. Very friendly interface.
- PFSense - Well supported; with frequent updates fixing vulnerabilities as they are detected. Also uses squid, and several others through means of a 3rd party package manager.
All of the above tools have paid for enterprise features.
Rather than list ALL of the firewalls, and eventually make some fan-boy scream BIAS! Here is the Gartner Magic Quadrant for UTM devices for 2014.
13-7 - 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.
See section 12-12
13-8 - All enterprise devices remotely logging into the internal network should be managed by the enterprise, with remote control of their configuration, installed software, and patch levels.
The security scan comes from Network health checks and NPS as outlined in section 1-6.
- Spiceworks with MaaS360 - Features are lacking for a free solution, but better than nothing.
- Meraki MDM - Features are rich for a free solution, but leaves you wanting MOAR (like on prem AD integration, come on Meraki - Where you at!!!) Works very well ith Apple iOS, and they are constantly rolling out new features for both iOS and Android. Compatible not only with phones, but workstations as well.
- Miradore - Free, unlimited devices, no time limit.
- Again, I will direct you to the Gartner Magic Quadrant for 2014 MDM vendors.
13-9 - 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.
I will refer you to HIDS in section 3-8.
13-10 - To limit access by an insider, untrusted subcontractor/vendor, or malware spreading on an internal network, devise internal network segmentation schemes to limit traffic to only those services needed for business use across the organization's internal network.
This is a best-practice, rather than a tool set. In other words, split up your departments, and security zones into separate broadcast domains (VLANS). A zone can be a collection of subnets/VLANs.
13-11 - 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.
Publicly accessible servers should NEVER communicate with internal systems (I have actually found an acceptable exception - When that publicly accessible server is only accessed from a whitelist of trusted hosts/domains). Web servers should never write directly to SQL servers. They should communicate with a system that performs business layer transactions, which writes/reads to the database. That business layer sits on this middle-man network. Likewise, internal systems should (as much as possible) not communicate directly to public systems. I can accomplish both by creating a middle-man network (VLAN) of servers that can talk to both external and internal systems. External systems talk to this middleman, Internal systems talk to this middleman.
Here is a quick diagram explaining how this looks:
This model also meets the requirements for section 19-1.
13-12 - To help identify covert channels exfiltrating data through a firewall, configure the built-in firewall session tracking mechanisms included in many commercial firewalls 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.
This is really only something you can do, if your firewall allows you to do it.
13-13 - Deploy NetFlow collection and analysis to DMZ network flows to detect anomalous activity.
Refer to section 3-8.