Findings Library
Last updated
Last updated
URL: https://pentest.ws/findings-library
During a security assessment we often discover vulnerabilities in web applications, network infrastructure, and Active Directory environments, generally called Findings. These issues need to be documented and later reported back to the client for remediation.
The Findings Library is a repository of documentation templates for vulnerabilities such as SQL Injection and add generic text for background information, descriptions, impact, recommendations, as well as a default risk level and reference links. During a live security assessment, these findings templates can quickly be added to the engagement in real-time as you discover them. Further refinements can then be captured with unique details about each specific finding.
Title: the main title of the Finding, such as "SQL Injection".
Environment: custom or pre-defined environment where the Finding was discovered
Category: the category of the Finding. In a web application assessment, this might map to the OWASP Top 10.
Risk Level: rate how critical this Finding typically is. This value can be adjusted when creating an Engagement Finding if required.
Enter details about the Finding's Common Vulnerability Scoring System (CVSS) score. More information about CVSS scoring is available here:
Assign values for each of DREAD categories:
Damage – how bad would an attack be?
Reproducibility – how easy is it to reproduce the attack?
Exploitability – how much work is it to launch the attack?
Affected users – how many people will be impacted?
Discoverability – how easy is it to discover the threat?
https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)
Provide some general background information about the vulnerability. This is not meant to include specific details about the client's environment, application, system, people, etc. Background should provide context for the client to better understand the nature of the vulnerability.
Findings Library entries should not contain specific details such as URLs, variables or file paths. Rather, the Description field should give the penetration tester who is reporting the vulnerability a good starting point to describe what was observed during the pentest.
The Impact of the vulnerability can be fairly static from Engagement to Engagement, although the depth of the Impact might change. For example, a SQL Injection vulnerability would generally allow an attacker to read arbitrary data from a database. This would make a good starting point for the report.
However, in the example of a SQL Injection, the Impact would be greatly increased if protected data, such as Personally Identifiable Information (PII) was leaked as a result of the exploit. Try to build your Impact statements accordingly.
As with Impact, the Recommendation for vulnerabilities is often similar when discovered. Continuing our SQL Injection example, the recommended fix might be to filter and validate all incoming user supplied data before passing to a back-end database engine.
Consider adding reference URLs to support the Background, Impact and Recommendations your are providing to your client. Try to limit your reference links to primary sources of information.
Findings Library is available on Hobby Tier and Pro Tier.
To get started, click the button to start building a Findings Template.
