This is the last part 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
Part 13 - we looked at Boundary Defense
Part 14 - we looked at Maintenance, Monitoring and Analysis of Audit Logs
Part 15 - we looked at Controlled Access Based on the Need to Know.
Part 16 - we looked at Account Monitoring and Control
Part 17 - we looked at Data Protection
18. Incident Response and Management
Section 18 is all policy and procedure. Other than documentation tools, which isn’t really the purpose of this blog, there are not many tools I could think of to enable you to meet these recommendations.
18-1 - Ensure that there are written incident response procedures that include a definition of personnel roles for handling incidents. The procedures should define the phases of incident handling.
18-2 - Assign job titles and duties for handling computer and network incidents to specific individuals.
18.3 - Define management personnel who will support the incident handling process by acting in key decision-making roles.
18-4 - Devise organization-wide standards for the time required for system administrators and other personnel to report anomalous events to the incident handling team, the mechanisms for such reporting, and the kind of information that should be included in the incident notification.
18-5 - Assemble and maintain information on third-party contact information to be used to report a security incident (i.e., maintain an e-mail address of email@example.com or have a web page http://organization.com/security).
AUTHORS NOTE - I would advise against using the security@ email address, since many spammers know security@ is a common address in an organization.
18-6 - Publish information for all personnel, including employees and contractors, regarding reporting computer anomalies and incidents to the incident handling team. Such information should be included in routine employee awareness activities.
18-7 - Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.
19. Secure Network Engineering
19-1 - Design the network using a minimum of a three-tier architecture (DMZ, middleware, and private network). Any system accessible from the Internet should be on the DMZ, but DMZ systems should never contain sensitive data. Any system with sensitive data should reside on the private network and never be directly accessible from the Internet. DMZ systems should communicate with private network systems through an application proxy residing on the middleware tier.
I have diagrammed how this would look.
19-2 - To support rapid response and shunning of detected attacks, engineer the network architecture and its corresponding systems for rapid deployment of new access control lists, rules, signatures, blocks, blackholes, and other defensive measures.
This is referring to a system that enables the network admin to rapidly deploy ACLs (AAA) to network devices such as a Network Management System (NMS).
- HP iMC - Ability to batch deploy switch configurations, set a configuration baseline, and much more.
- Cisco ISE - NMS for Cisco devices and other devices as well.
19-3 - Deploy domain name systems (DNS) in a hierarchical, structured fashion, with all internal network client machines configured to send requests to intranet DNS servers, not to DNS servers located on the Internet. These internal DNS servers should be configured to forward requests they cannot resolve to DNS servers located on a protected DMZ. These DMZ servers, in turn, should be the only DNS servers allowed to send requests to the Internet.
Not really a tool, but a way to securely centralize your DNS zones, called Shadow Master.
Essentially, all of your DNS servers (Internal and public facing) are getting the zone information from a single (or multiple in failover setting) DNS server that is not accessible by clients. In the case of Active Directory Domains, where all DCs are DNS servers, the primary DC is your shadow master. It is the master server for any non-AD integrated zone (public zones) and all of your public DNS servers receive their zones from this server. This way, if your public DNS servers are compromised, the zone records cannot be tampered with. Note: this can lead to a pivoting attack - in which case, the architecture described in section 19-1 may help.
19-4 - Segment the enterprise network into multiple, separate trust zones to provide more granular control of system access and additional intranet boundary defenses.
For example, not only workstations on one VLAN and servers on another, but a configuration where each department is on their own VLAN. Database servers and other extremely sensitive systems should be separate on their own VLAN.
- Domain Isolation - While not a single tool, it is a common best practice to separate your network into zones and define higher security standards for zones that contain sensitive data using IPsec. Intro to Domain Isolation may help.
20. Penetration Tests and Red Team Exercises
20-1 - Conduct regular external and internal penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully. Penetration testing should occur from outside the network perimeter (i.e., the Internet or wireless frequencies around an organization) as well as from within its boundaries (i.e., on the internal network) to simulate both outsider and insider attacks.
This is much more than just vulnerability scanning using Nessus or OpenVAS. This includes attempting to exploit the vulnerabilities found by these systems. I could write an entire book on this one little section alone, so instead, I will point to some common all-in-one tools, and let you read the books already published!
- Backbox Linux - Pentesting distro built on Ubuntu. DOES NOT REQUIRE RUNNING AS ROOT!
- Kali Linux – Kind of the defacto pentesting distro out there. Most schools teach from this distro in security classes. Requires you to run as root all the time.
- PenTesters Framework (PTF) - Framework of tools that can be installed and updated on any dostro (currently only limited to Kali, Debian, and Ubuntu)
20-2 - Any user or system accounts used to perform penetration testing, should be controlled and monitored to make sure they are only being used for legitimate purposes, and are removed or restored to normal function after testing is over.
This is just common sense.
20-3 - Perform periodic Red Team exercises to test organizational readiness to identify and stop attacks or to respond quickly and effectively.
This is basically 20-1 written using different words.
20-4 - Include tests for the presence of unprotected system information and artifacts that would be useful to attackers, including network diagrams, configuration files, older penetration test reports, e-mails or documents containing passwords or other information critical to system operation.
This is more procedure than tools.
20-5 - Plan clear goals of the penetration test itself with blended attacks in mind, identifying the goal machine or target asset. Many APT-style attacks deploy multiple vectors--often social engineering combined with web or network exploitation. Red Team manual or automated testing that captures pivoted and multi-vector attacks offers a more realistic assessment of security posture and risk to critical assets.
Again, libraries are written on this topic. I could list tools here, but it would be a million lines long, and still people would be offended because I left off some obscure DNS fuzzer that they enjoy using... HOWEVER, there is one tool I can absolutely recommend...
- Penetration Testing Framework - Not updated recently, but a treasure trove of information.
20-6 - Use vulnerability scanning and penetration testing tools in concert. The results of vulnerability scanning assessments should be used as a starting point to guide and focus penetration testing efforts.
Refer to section 4-1
20-7 - Devise a scoring method for determining the results of Red Team exercises so that results can be compared over time.
This might help:
- DREAD Scoring Template - I have attached a template that helps me organize vulnerabilities found based on criticality. This helps me focus my efforts where they are needed most.
20-8 - Create a test bed that mimics a production environment for specific penetration tests and Red Team attacks against elements that are not typically tested in production, such as attacks against supervisory control and data acquisition and other control systems.
Because, you know...having your Red Team take down your main website in the middle of the day is never a good thing.