Communication is key in any project - yet, it’s especially critical during a penetration test. Because pentests are a point-in-time event with a time constraint, it becomes even more important to communicate any findings, blockers, changes to the environment, and/or any other variables that may turn into a hurdle for testers. Additionally, since pentesting can affect applications, environments and the access to them negatively, the importance of communication is amplified. Thus, the timing of communication is crucial to the success of the test.
Communication is a two (or more) way street. Just as it is important for the testers to communicate their progress and findings, it is equally as important for the environment owners to communicate outages, detrimental effects on environments and/or a denial of service for their users. Neither side can afford to wait; here are a few situations where communication, availability, and responsiveness are the most important:
- A blocker presents itself, keeping testers from moving forward
- High/critical exploitable vulnerabilities are found
- The application/environment becomes sluggish or unresponsive
- Testers are investigating out of scope areas such as neighboring networks, or already tested functionality
- Customers are increasing the scope of the test
- Testers appear to be skipping sections of the scope
- The report needs edits or does not meet requirements
- The test needs to be paused or canceled for any reason
Testing time is lost when a blocker presents itself and testers are not able to continue their investigations. As mentioned, pentests are point-in-time and time constrained, meaning any blockers will jeopardize the overall test and due to resourcing, and capacity, it may not be possible to extend the timeframe of the test. These types of snags need to be communicated and acted on quickly in order to make sure the entirety of the scope is tested. While testers can engage in other activities like threat modeling in other areas of the scope, or get a head start on reporting, these activities won’t move the needle on the actual investigation.
Getting the tester what they need when they need it is necessary to ensure completeness and quality. Otherwise, testers will rush to complete scope, or feel forced to skip areas due to time constraints which ultimately jeopardize the quality of the pentest.
When a critical/high finding is discovered, or when the application/environment is negatively affected, the system owners should be notified immediately. These situations represent high risk and system owners should be given the heads up and opportunity to remedy as quickly as possible. When testing is being done in development/beta environments it is essential to communicate findings in real time as these may also be present in the already deployed production environment.
Providing the system owners with a heads up can be crucial in reducing risk immediately in those other environments. Similarly, if the test environment is being affected negatively by the testers activity, this may be an indicator of what the live/production environment may experience under similar activity and load. Knowing this in real time can benefit not just the system owners, but the end users as well.
Real time communication of findings and/or activity is also extremely beneficial for system owner education. When testers provide a play by play of their activity, their findings, their difficulties, it provides development teams and system administrators with a real time look into an attackers mentality. This can benefit how developers and system owners create and deploy in the future; having insider knowledge means they can apply those learnings in future sprints and deploy more secure applications and environments from day one.
When it comes to communication to the testers from developers and system administrators, the more the tester knows the better. Business logic context can be instrumental in how the testers approach the pentest. It can also give them insight on how to attack or how to author their potential exploits specifically for that environment. Remember, at the end of the day testers want to help uncover risk and the more context they have the better they can help surface that risk. Understanding that some tests require no context, there is still a level of communication and knowledge that can be shared without compromising the integrity of the test.
It is also important to be open and collaborative as findings are communicated and reported. This is a great opportunity to discuss the finding, provide context, reasonings, and perhaps share what else might be reducing the perceived risk. Testers should be willing to adjust their initial impressions, and system owners should also be willing to see that risk from an attacker's perspective. Doing so allows for much faster remediation and a better relationship between the builders and the breakers.
As with most areas in life and work, communication is key - the sooner any potential blockers are discussed, the sooner that risk can be remediated. As they say, sharing is caring, and that is definitely true when it comes to penetration tests.
Next up we will talk about how to handle situations when things aren’t going well - escalation handling is an artform all of its own. We will touch on how to best communicate and handle the snafus that can come up during testing.
Next up we will talk about how to handle situations when things aren’t going well - escalation handling is an artform all of its own. We will touch on how to best communicate and handle the snafus that can come up during testing.