Engagement Findings
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 new Findings System in PenTest.WS aims to make this process of collection & documentation as easy as possible.
Current Findings List
Example URL: https://pentest.ws/e/{engagement.id}/findings
Visiting the Findings tab in an Engagement brings up the Engagement Findings screen. Here you will see all of the previously identified vulnerabilities with their various details. The colors of the Findings are defined in your Findings Admin screen.
Auto ID
Auto ID is a time-saving feature that automatically sets the Finding's ID value based on a template you define for each Engagement. Use any format you need and include hash marks (#) where you want the system to sequentially number each finding.
In this example we have defined "ACME.##" as the Auto ID format. The Findings System then numbers the Findings:
ACME.01
ACME.02
ACME.03
The numbers are left padded with zeros based on the number of hash marks.
Auto ID values are automatically updated when you re-sort the Findings list.
Drag-Drop Sorting
Most things in PenTest.WS can be drag-and-dropped to sort the objects, including your Findings. Drag a Finding card up or down and the system will not only sort them as requested, but also re-number the Findings according to your Auto ID format.
Using the Findings Library
Example URL: https://pentest.ws/e/{engagement.id}/findings/add
Click an entry in the Findings list to import the Finding into your current Engagement.
Finding Preview
Before a Finding from your Findings Library is imported into the current engagement, you are presented with a Finding Preview window.
This allows you to review the details of the Findings Library entry and decide to Add To Engagement or not. This step is useful if you have multiple listings describing the same issue but each have slightly different information or circumstances.
Add / Edit Findings
Example URL: https://pentest.ws/e/{engagement.id}/findings/{findings.id}
Main Info
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.
CVSS
Enter details about the Finding's Common Vulnerability Scoring System (CVSS) score. More information about CVSS scoring is available here:
DREAD
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)
Background
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.
Description
Brief Fields
The Description, Impact and Recommendation fields have Brief variants of their values. These are meant to be short descriptive versions of the full language field. For example, "Description - Brief" summarizes the Finding's "Description" in one or two sentences. These brief fields are useful for short executive summaries where the longer version is not needed.
Describe the vulnerability in detail. Consider including the following information:
What you saw
Where you saw it
When you saw it
How you discovered it
Variables, URLs or file paths relevant to the Finding
Another import detail to include in the Description is the authorization and/or authentication required to exploit this vulnerability as this can greatly affect the Impact and Risk Level of the vulnerability.
Impact
The Impact of a vulnerability is a description of the harm an attacker could inflict on a client when exploiting the vulnerability. This is often related to the confidentiality, integrity and availability of the client's assets, known as the CIA Triad.
Confidentiality - be sure to consider the type of data exposed in a loss of confidentiality. When Personally Identifiable Information (PII) is leaked, the Impact can be greatly increased.
Integrity - adjust the risk to integrity in accordance with the control an attacker would gain over a client's data. Can the attacker modify existing data or inject new records such as hidden admin accounts? What about removing event logs to hide the attack's evidence?
Availability - during a Denial of Service (DoS) attack, data and services may be slow or unreachable, but these attacks are typically temporary. The Impact might be greater if an attacker can delete data or completely crash a service that requires human intervention to recover.
Recommendation
Provide a list of recommended steps to remediate the vulnerability. Classic recommendations include validating user supplied data, implementing the Principle of Least Privilege and practicing Defense in Depth.
Increase the value of your recommendation by providing an effort level and time-frame the client can expect to fully patch a system or implement additional security controls.
References
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.
Targets
A single Finding may apply to single or multiple Targets. List the vulnerability end-points, systems or networks where your Finding applies.
Evidence
Provide supporting evidence to your Finding. Common evidence includes screenshots and command logs. Timestamps are a great idea to help the client's investigation during a debrief.
Validation Steps
Once the client has remediated the vulnerability outlined in your Finding, validation should be performed. It may be easiest for the original penetration tester to describe the steps needed to conduct this validation, and the Validation Steps is a convenient way to document these details at the time the Finding is discovered.
Many times the validation can occur weeks or months after the initial report, and sometimes conducted by a different penetration test, team or the client themselves. A few quick notes on how to validate the solution can save everyone a bit of time in the future.
Remediation Log
The Remediation Log is meant to be an internal field for keeping track of the remediation status the client has reported. This data is not necessarily meant to be shared with the client. Date and time stamps, along with the name of the person updating the log, is good information to include for long running remediation processes.
Tier Availability
Engagement Findings are available on Hobby Tier and Pro Tier.
Last updated
