Patch Your Systems and Run Vulnerability Scans: Ensure all security patches are up to date, as unpatched systems can create vulnerabilities that may affect the accuracy and effectiveness of your penetration test. Additionally, run vulnerability scans to identify any known issues before the test. This will help focus the penetration test on high-risk areas and ensure that previously identified vulnerabilities are addressed.
Collaborate with Your MSSP: Many penetration testing companies prefer to test without interference from security tools, so they may request that your Managed Security Service Provider (MSSP) “lower their shields.” While this allows for thorough testing, it’s crucial to test the MSSP’s response capabilities. Collaborate with them to spot any threats early and allow for whitelisting once the system is detected.
Define the Scope of the Test: Clearly outline what is in scope and out of scope for the penetration test. Determine which systems, applications, or networks are to be tested, and make sure the testing team is aligned with your expectations. Defining boundaries helps avoid any confusion during the test and ensures a focused approach. Also, ensure that you’re clear on the types of tests that will be run—whether it’s external, internal, web application, phishing, or physical testing.
Ensure All Prior Findings Have Been Remediated: Before starting the test, review any previous penetration test findings and confirm that all critical vulnerabilities have been addressed. This ensures that you’re testing a more secure environment and prevents previously identified issues from skewing results.
Understand Testing Approaches: Familiarize yourself with the different types of testing that can be performed:
Internal Penetration Testing: Focuses on threats from within your organization.
External Penetration Testing: Simulates attacks from external hackers.
Web Application Penetration Testing: A deep dive into your applications to uncover vulnerabilities. Ensure tests are performed with and without credentials, and include API penetration testing to test for weaknesses in your backend services.
Phishing Simulations: Tests your employees’ awareness of phishing attacks.
Physical Penetration Testing: Evaluates physical security measures and how an attacker might bypass them.
Blue Team: Defensive testing to evaluate your detection and response capabilities.
Purple Team: Combines the strengths of red and blue teams for improved collaboration and real-time knowledge sharing.
Red Team (The Holy Grail): A comprehensive, multi-layered attack simulation that combines all aspects of a threat actor’s tactics.
Cloud Infrastructure Testing: Ensure that your cloud environments (e.g., AWS, Azure, GCP) are also tested. Focus on configurations, permissions, and services that may be vulnerable to attack.
Authorized Testing: Always get an authorized letter to test before proceeding. This ensures that you’re operating within legal and organizational boundaries, reducing the risk of inadvertently crossing ethical lines during testing, particularly in sensitive data environments and cloud-based infrastructure.
Ken’s Take
If you’ve been doing penetration tests year over year and aren’t finding much, it may be time to shake things up. Consider negotiating a performance-based testing agreement with your testing partner. Under this model, you pay based on the severity of the findings: for example, $15k for each extreme finding, but only $500 for low-level issues. This ensures your testing partner is incentivized to thoroughly investigate and find critical vulnerabilities, making them work for the test.
Also, ensure that “trophies”—such as domain controller access or the ability to manipulate sensitive company data—are properly addressed in your testing. Many times, testing may focus on access points without considering the real-world impact, like compromising sensitive information, payroll, or earnings reports before they’re released. This should be part of your performance-based testing requirements. It’s crucial to highlight these risks to your CFO and Board, so they understand not just the technical breaches but also the potential for manipulating key data, such as an earnings report, rather than just saying “we compromised the ERP system.”
By doing so, you provide your leadership team with a better understanding of the risks, making cybersecurity more tangible and relatable to business outcomes.
