Today’s post is all about Control 20 of the CSIS 20 Critical Security Controls – Penetration Tests and Red Team Exercises (the last post pertained to Control 19). Here I’ll explore the (15) 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
- Contract If You Can. My bet is that most organizations don’t need to hire a dedicated penetration testing team. Some do. My recommendation is to find a reputable group of people that do this day in and day out. Have some internal security guys geek out with the red team for a while before, during, and after – they’ll learn from it. But, you’ll probably get more for your dollar by outsourcing this function. Take this with a grain of salt, because your organizational mission and/or industry may dictate otherwise.
- If You Can’t, Then Do Something. Peppered throughout my notes below are some ideas for starting small, again with a group of passionate, willing participants. At the very least the little you’re able to accomplish with such a grass roots effort will begin to bring visibility to the purpose of security. Start with things that matter – physical access, social engineering – then move to the trickier domain of logical pen testing.
Potential Areas Of Improvement
- Add Metrics And Tests. There are no metrics presented for Control 20. Again.
Requesting Feedback On
- Requirement 6.
- Description: Conduct regular external and internal penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully.
- Notes: I could conduct ‘regular’ penetration tests every five years. I would much prefer to see this specify a range of some kind, or at least indicate that the enterprise should pick something that keeps up with the pace of change in the landscape.
- Description: 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.
- Notes: Whatever you do, involve legal with this and have your documentation squared away. If an external penetration test goes awry and your organization’s losses mount as a result, you will have achieved the exact opposite of what the security function is supposed to achieve. No, that does not look good.
- Description: If any user or system accounts are used to perform penetration testing, those accounts should be carefully controlled and monitored to make sure they are only being used for legitimate purposes.
- Notes: Enforce separation of duties during the penetration testing. This is pretty simple, really. But again, make sure you’re documenting what you’re going to do, what you’re doing, and what you’ve done.
- Description: Perform periodic red team exercises to test the readiness of organizations to identify and stop attacks or to respond quickly and effectively.
- Notes: Some of this you can start immediately and with low risk. Remember all those Incident Detection and Response requirements? Why not get a core group of people who love doing this stuff to ‘prank’ the organization in non-threatening ways just to test your Incident Detection and Response program. That’s an easy way to get started and show results with minimal risk. Then you can iterate to the more advanced stuff where you’re really discovering serious vulnerabilities.
- Description: Ensure that systemic problems discovered in penetration tests and red team exercises are fully tracked and mitigated.
- Notes: Fully tracked is one thing, but mitigated is another. The truth is that we live in a resource constrained world and we need to prioritize. Prioritization of these issues should be based on proper risk evaluations.
- Description: Set up automated processes to find: Cleartext e-mails and documents with “password” in the filename or body
- Notes: To me, mail servers or even operating systems should provide this type of feature straightaway. If not, go find a tool – someone has to have done this before. If you’ve done this, but haven’t shared, get it up on git already. Anyone?
- Description: Set up automated processes to find: Critical network diagrams stored online and in cleartext
- Notes: This really seems silly. Does anyone know of a tool that does this or have they implemented something they use? How would I know that a particular file conatins a network diagram without prior knowledge? Maybe I’m being too abstract and this really means that you should scour your systems and Google for known file names. That would make more sense.
- Description: Set up automated processes to find: Critical configuration files stored online and in cleartext
- Notes: See comment above. Unless you’re looking for something with prior knowledge of its characterisitcs, how are you going to know that OmniGraffle file A is a topology diagram and that text file B is really a configuration file for your production load balancers?
- Description: Set up automated processes to find: Vulnerability assessment, penetration test reports, and red team finding documents stored online and in cleartext
- Notes: See previous previous.
- Description: Set up automated processes to find: Other sensitive information identified by management personnel as critical to the operation of the enterprise during the scoping of a penetration test or red team exercise.
- Notes: See previous comment.
- Description: Social engineering should be included within a penetration test. The human element is often the weakest link in an organization and one that attackers often target.
- Notes: The human element is the weakest link, and that’s what makes social engineering testing so fun. If you’re part of a larger organization, identify some people (or even the newest hires) to socially engineer people in other divisions.
- Description: 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.
- Notes: This requirement harkens back to having really great documentation for the penetration test. If you don’t have it planned appropriately, people won’t understand the scope of intent, and that’s when people get fired. Most organizations won’t have an internal Red Team. Some will. If you don’t, find one with references, check the references, and don’t think they’re all like Robert Redford in the movie ‘Sneakers.’
- Description: 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.
- Notes: This seems like common sense. But, be careful if you’re trying to use a Red Team in this case, because most real-world attacks won’t have a tidy vulnerability report to review before getting started. If you’re doing plain-old penetration testing, on the other hand, the vunlerability assessment is indeed useful.
- Description: Devise a scoring method for determining the results of red team exercises so that results can be compared over time.
- Notes: I have little knowledge of such scoring systems, but this seems like something that should be shared in the industry. When it comes down to it, organizations will be held to the standards commonly practiced and/or prescribed by law. If we’re all scoring in the same way, we can have a better comparison when the legal issues come up. Think about where we’d be if GAAP and the international accounting rules didn’t exist.
- Description: 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.
- Notes: If you have the resources to do this, have at it. Most will not have such resources.
Other Controls Reviewed In This Series
- Control 1: Inventory of Authorized and Unauthorized Devices
- Control 2: Inventory of Authorized and Unauthorized Software
- Control 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- Control 4: Continuous Vulnerability Assessment and Remediation
- Control 5: Malware Defenses
- Control 6: Application Software Security
- Control 7: Wireless Device Control
- Control 8: Data Recovery Capability
- Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- Control 11: Limitation and Control of Network Ports, Protocols, and Services
- Control 12: Controlled Use of Administrative Privileges
- Control 13: Boundary Defense
- Control 14: Maintenance, Monitoring, and Analysis of Audit Logs
- Control 15: Controlled Access Based on the Need to Know
- Control 16: Account Monitoring and Control
- Control 17: Data Loss Prevention
- Control 18: Incident Response and Management
- Control 19: Secure Network Engineering
- Control 20: Penetration Tests and Red Team Exercises
* A method and format explanation can be found at the beginning of Control 1.
Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.
- Don’t Reinvent the Wheel: Phil Agcaoili on the Cyber Security Framework
- Configuration Compliance Also Includes Vulnerability Management
- Understanding What You Know You Don’t Know
- Cyber Security Solutions for the DoD and Intelligence Community
P.S. Have you met John Powers, supernatural CISO