Penetration testing is an important tool for uncovering vulnerabilities in systems and applications before malicious hackers can exploit them. Organizations should define a process for regularly conducting penetration tests using independent third parties. The results of these tests should feed into a continuous cycle of risk assessment and remediation.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full Cloud Controls Matrix here. The CCM provides a comprehensive set of security controls specifically designed for cloud computing environments. For more on pentesting, check out the OWASP Web Security Testing Guide.

Who should care?

• Security managers responsible for assessing and managing risk
• Compliance officers who need to ensure adherence to relevant laws and regulations
• Developers who build cloud-based systems and applications
• IT operations teams tasked with securing production environments

What is the risk?

Without regular penetration testing, organizations may have unknown vulnerabilities lurking in their systems. Even with penetration testing this will be the case but the exposure may be different. Malicious attackers could exploit these flaws to gain unauthorized access, steal sensitive data, deploy malware, or disrupt business operations. The risk is especially high for internet-facing systems and those that handle sensitive customer or financial data. Penetration tests significantly reduce the likelihood of a breach by proactively identifying security gaps to be closed as a priority.

What's the care factor?

For organizations operating in the cloud, penetration testing should be a high priority. Cloud environments are complex with a large attack surface. A single vulnerability can jeopardize the entire stack. The reputational and financial damage from a cloud breach can be severe. Penetration testing is a relatively low-cost way to manage this risk and instill confidence in the security of your cloud deployments.

When is it relevant?

Penetration testing is most important for:

• Public-facing production systems
• Applications that process sensitive data
• Systems subject to regulatory requirements (e.g. PCI DSS, HIPAA)
• Cloud environments with a large number of interconnected services
• Organizations with a low risk tolerance

It may be less critical for:

• Small-scale, low-risk applications
• Systems with no internet connectivity or user interaction
• Well-hardened environments that undergo rigorous security testing as part of the SDLC

What are the trade offs?

Penetration tests can be time-consuming and require special expertise to perform well. Tests on production may cause some disruption, though usually minimal. Results can be a flood of hard-to-prioritize issues if the environment is in poor shape. Some firms may be reluctant to grant third parties access required for a thorough test. Ultimately, the insight gained is well worth the effort and expense for most.

How to make it happen?

1. Define the scope of the penetration test. What systems and apps are in bounds?
2. Identify a reputable third party to conduct the test. Many specialize in cloud environments.
3. Ensure the vendor has sufficient access and permissions to perform a complete test. This may include temporary IAM credentials, VPN access, etc.
4. Schedule testing for a time that minimizes disruption to the business. Notify stakeholders.
5. Perform the penetration test, which may include:
   • Reconnaissance to gather information about the target
   • Scanning to identify possible entry points
   • Attempts to exploit vulnerabilities and gain access
   • Post-exploitation activities to determine impact
6. Review results and prioritize findings based on risk severity
7. Develop a remediation plan to address identified vulnerabilities
8. Retest systems after remediation to validate fixes
9. Feed learnings back into development processes and environment hardening

What are some gotchas?

• Penetration testers will need broad permissions in the environment, such as the ability to launch new EC2 instances, access S3 buckets, invoke Lambdas, etc. Coordinate these permissions carefully and revoke them immediately after the test.
• Be aware of any regulations that restrict the type of penetration testing that can be performed. For example, PCI DSS has specific requirements around cardholder data.
• Focus on the quality of the penetration testing firm, not the quantity of scans. An experienced tester will find flaws that automated tools miss.
• Ensure rules of engagement are crystal clear in writing. You don't want an eager tester taking down production systems unexpectedly.

What are the alternatives?

While penetration testing by independent third parties is ideal, other vulnerability assessment techniques can be used to supplement or prepare for rigorous testing:

• Automated vulnerability scanning tools like Nessus or OpenVAS
• Static application security testing (SAST) and dynamic application security testing (DAST)
• In-house red team exercises
• Bug bounty programs to crowdsource testing

Explore further

• OWASP Top 10 Web Application Security Risks
• Penetration Testing Execution Standard (PTES)
• NIST Technical Guide to Information Security Testing and Assessment

This control maps to:

• CIS Control 20: Penetration Testing and Red Team Exercises

‍