In this article, we will address various points on how pentesters should move once they have uncovered vulnerabilities within client engagements. We take to account the methods of reporting instances of vulnerabilities as well as the process of patching discovered vulnerabilities.
How Should Pentesters Proceed?
When penetration testers notice a flaw or hole in network security, do they notify the company right away or complete the testing beforehand to file a full report? What are the steps in the reporting process? Penetration testers will always be looking for security holes within the organization, bug bounty hunting or during a client engagement. This is almost always a continuous exercise and often demands considerable time and effort. Testing and reporting will usually be based on a methodology that defines the necessary steps to be taken. Most of the pentesting methodologies will require that the pentester document findings across all phases of testing. Once testing is complete, the tester consolidates the findings into a full report that is then shared with the management. However, this may not happen immediately once testing is complete; it will depend on the scope of the engagement, hence the size of the report. Generally, the pentest team requests an exit meeting from the client to mark the end of the pentest. During the meeting, discussions are held on the findings and a “management response” document is shared. This is when the client responds to the uncovered risks, choosing to either avoid, mitigate or accept the risk. Avoiding the risk focuses on eliminating the risk. Some risks cannot be avoided, and thus mitigation allows for the reduction of their impact. Accepting the risk means the client is just going to live with the risk. The date when the client should expect the final report is discussed, and the report is submitted on the agreed date. Some clients may request a retest to be executed once they have responded effectively to the report. Due to variances in environments, various factors will influence the turnaround time for a report submission. Some of these include:
Scope of Work
An environment with numerous hosts within the scope of testing will require more assessment as compared to one with less. Each host will require comprehensive scanning to reveal vulnerabilities. However, testing an environment with a smaller scope will often result in faster documentation. The client may also require a certain depth of testing, or request retests to be performed before the final report is issued. This will also influence the turnaround time for report submission. Maintaining an inventory of what needs to be tested is an important step that organizations must make before the pentest. “The inventory process is still an issue for many organizations,” says David Goldsmith, New York regional director of professional services for information security firm @stake. (See Sources.) “The problem scales with the size of the organization — if your network is small, manual systems may work well. But as the size of your network increases, collecting and maintaining the inventory data becomes a major undertaking, requiring automated tools.”
Number of Vulnerabilities
Multiple vulnerabilities within an environment will require more documentation time as compared to an environment with less discovered vulnerabilities. This is because each instance of an affected asset has to be documented, along with severity of risk, recommendations and proof of concept to reproduce the issue.
Type of Test
Most often, vulnerability assessments take much less time as compared to penetration tests. This is because pentests require much more in terms of effort. There are also manual pentests and heavily automated ones. For instance, as a test requiring manual tests using the OWASP Top 10 methodology list might take more time, this will eventually affect the turnaround time for report delivery.
How Do Companies Proceed?
How do companies proceed when they are informed of network vulnerabilities? Who is responsible for developing patches, new processes and maintenance in the aftermath? What is the range of time-commitment and effort needed to do so? When a pentest is complete and the report submitted to the client, the client management will require the IT department to deal with applying the necessary patches to resolve identified issues. The IT team will then reach out to the process owners of the different affected systems and submit a Request for Change. This involves signing a written form, outlining the changes to be made within the system or application. This document is then submitted for approval from the process owner, who may be the head of networks, databases, applications, security systems etc. Once approved, the necessary changes are carried out within the affected systems, and the request-for-change form filed for reference purposes. The time and effort required to patch security issues depends on the vulnerability. Some vulnerabilities will require entire system patches that must be tested in a special environment before being applied to the live system. Some may require upgrading affected software, which can sometimes only be done by the vendor that made the installation. Thus, the level of effort varies greatly. The crown jewels within the organization will often be attended to first to minimize possible risk exposure. Prioritization is key! Another thing affecting most organizations is bureaucracy. Before simple patches can be applied, the request for change goes through multiple levels of approval, especially within sensitive environments such as financial institutions, resulting in a period of a week or two before necessary patches are applied. This greatly affects the time patches are applied and varies from organization to organization.
What Information Do Pentesters Need to Convey?
Part of a pentester’s job is to report their results in such a way that ensures the vulnerability will be looked into. Pentesters must ensure that as they are reporting a vulnerability, they also provide their recommendations, remediation information and details of the steps needed to reproduce the vulnerability. This ensures that the technical team at the client site will be able to monitor the vulnerability, confirm it exists and apply the necessary patches. Remediation information may include anything from links to patches to step-by-step instructions detailing the actions to be taken. The level of difficulty of patching the vulnerabilities should also be included, to allow the technical team to assess their level of effort.
How Do Reporting and Network Patching Vary?
Pentesters will discover a range of vulnerabilities within the network that will affect network nodes in a number of ways. For instance, an old IP camera might be discovered to have a firmware backdoor that is unpatched by the vendor, with no signs of being patched in the near future. Such an issue will require replacing the IP cameras within the organization. This is something the pentester needs to effectively communicate this within the report. Or suppose that a number of Windows systems on the network are found to be vulnerable to a certain exploit, but the problem can be resolved with a Windows OS hotfix. In this case, the pentester should include links to the Microsoft Security Bulletin in their report, with Microsoft’s instructions on how to perform the OS patch. Some environments will have devices with default credentials for multiple pieces of equipment, such as databases, radios, IP cameras and even reused passwords for multiple client PCs. In this case, the pentester needs to document the steps required to reproduce how the discovery of the default credentials was made. Some vulnerabilities will require simple fixes that may include making additional entries to configuration files within the affected servers. In such cases, the pentester needs to clearly give instructions on affecting the changes within the technical summary section of the report.
How Do Pentesters Explain Important Details to Non-Technical Clients?
When writing a report, it is important for pentesters to understand that the report is going to target both technical and non-technical personnel within the client organization. Reporting thus needs to be done in a manner that accommodates both parties. For instance, getting root on an enterprise server containing sensitive information such as credit card information is impressive, but it means absolutely nothing to the key decision-makers if not communicated in a language they can understand. And if the report can’t be read by C-suite personnel, it will likely be overlooked, and this is only going to demoralize everyone involved. The best way of writing a report is to ensure that there are two primary sections. These will be the Executive Summary and the Technical Summary. The Executive Summary section will include the details of findings, summarized in a way understandable to top-level management, while the Technical Summary will contain the technical jargon that will communicate with the technical team. Let’s look at an example of one finding and how it could be represented within the Executive and Technical Summary sections:
Executive Summary
Vulnerability: Directory Listing (Apache) Observation: A vulnerability that allows individuals to browse through the contents of the website was discovered. Risk and Business Impact: The issue may allow attackers to obtain source code and sensitive files such as configuration files from the website’s back end. Recommendation: It is strongly recommended that the proper configuration be performed on the files and folders within the web server to ensure that the files cannot be accessed by unauthorized individuals.
Technical Summary
Vulnerability: Directory Listing (Apache)
Observation: We discovered a directory listing issue on the website. The web server responded with a list of files located in the target directory. Risk and Business Impact: An attacker can see the files located in the directory and could potentially access files which disclose sensitive information Recommendation: Change the server configuration file. A recommended configuration for the requested directory should be in the following format:
Remove the Indexes option from configuration. Also make sure to remove MultiView as well. Configure the server to disallow directory listing requests
Conclusion
Penetration testers must ensure that as they develop their technical skills, they also develop their communication skills. Communication with C-suite-level personnel, both within the report and in person, should be simple and understandable. Care should be taken not to lose them in lingo that is intended for more technical staff. While communicating to the technical team, pentesters should ensure that they provide solutions to the discovered vulnerabilities. This accommodates the technicians and makes their work easier when patching affected systems and applications.
Sources
Four steps to sound security vulnerability management, TechTarget
