Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENG-1742] Add pentesting docs #16

Merged
merged 10 commits into from
Dec 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 0 additions & 25 deletions .github/workflows/preview.yml

This file was deleted.

1 change: 1 addition & 0 deletions pages/_meta.ts
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ export default {
"integrations": "Integrations",
"oneleet-agent": "Oneleet Agent",
"guides": "Guides",
"penetration-testing": "Penetration Testing",
"support": {
"title": "Support",
"type": "page",
Expand Down
11 changes: 11 additions & 0 deletions pages/penetration-testing/_meta.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
export default {
ptaas: "Penetration Testing as a Service (PtaaS)",
"services": "Pentesting Services",
"pentesting-classification": "Types of Pentests",
"process-overview": "Process Overview",
"documents": "Documents",
"final-report": "Penetration Test Report",
"findings-decisions": "Remediation",
"pci-dss": "PCI DSS",
"faq": "Frequently Asked Questions"
};
9 changes: 9 additions & 0 deletions pages/penetration-testing/documents.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Penetration Test Documents

At Oneleet, we offer several types of documents during the penetration testing process.

| Name | Description | Target
|-----|-----|-----
| **Full Report** | Generated at the conclusion of the engagement. This report presents all the findings, accompanied by a **Description**, **Business impact**, **Reproduction steps**, and **Remediation steps** section. It includes an executive summary that highlights positive findings and recommendations. The results section provides a high-level overview, a table listing vulnerabilities, and an overview of the scope of the engagement. After remediation, the report will be updated to reflect the current state of each identified finding. | Internal Usage or External Stakeholders
| **Letter of Attestation** | Verifies the successful completion of a penetration test, offering a succinct summary of the scope, methodologies employed, and the tester's proficiency. Offers a comprehensive evaluation of the application's security, identifying the number of vulnerabilities discovered. | External Stakeholders
| **Letter of Engagement** | Notifies that you are undergoing a penetration test. Offers a comprehensive overview of the test's objectives, scope, methodologies, and the dates of the assessment. Assures you that any vulnerabilities discovered will be promptly reported for remediation. | External Stakeholders |
37 changes: 37 additions & 0 deletions pages/penetration-testing/faq.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Frequently Asked Questions

### Does a Penetration Test at Oneleet include DDoS?

No. At Oneleet, we recognize that such attacks increase the probability of operational disruptions or the risk of collateral damage. We firmly believe that there is no genuine advantage to conducting such tests during a penetration test.

### Which Penetration Test Should I Choose: Black, Gray, or White Box?

Opt for a **White-box Pentration Test** if you're prepared to provide the source code and configuration files to the penetration tester, or if the application is open-source, as it effectively simulates threats that have or had access to the source code. Select a **Gray-box Penetration Test** for a best-of-both-worlds approach, as it allows the penetration tester to uncover most vulnerabilities accessible to both external and internal attackers. Choose a **Black-box Penetration Test** if your main concern is about external threat actors.

### Do I need to set up a staging environment?

We usually conduct tests in the staging environment and advise against testing in the production environment to minimize the risk of operational disruptions or collateral damage. Having said that, testing in staging is discouraged if it doesn’t accurately reflect the production environment or lacks representative data, as this will provide less value from a security perspective.

### Can major system changes be made during the penetration test?

We advise against implementing significant system changes during the penetration test. While pushing small changes is acceptable, we recommend maintaining a stable environment throughout the engagement to ensure the accuracy and reliability of the testing process.

### What should I expect on the penetration testing scoping call? Should I prepare something?

See [this](/penetration-testing/process-overview) section.

### What type of qualifications should I look for in a penetration tester to evaluate their skill level?

Technical background, certifications, communication skills. Evaluate a penetration tester’s technical background and certifications, starting with the industry-standard, the OSCP, and continuing with any other Offensive Security certification that you believe it’s relevant the penetration test, such as OSCE or OSWE. Effective communication is equally important — ensuring clear guidance from the initial scoping call, throughout the assessment, and through support with Letters of Attestation and Engagement.

### What are the lead times for a penetration test?

The time from when we sign the contract to the start of the penetration test is usually a few days if there’s a rush, but it can be up to a week during peak times.

### What are the consequences of 0 discovered vulnerabilities?

Although such engagements are highly unlikely, the outcome depends on the engagement scope and business size. For a startup with over 10 employees and a Gray-box penetration test, vulnerabilities are typically found, especially if it’s the first test. If the scope is limited or the application security is strong, there can be no vulnerabilities, but the tester should explain their methods, failures, and challenges.

### Do I share the penetration test report with customers?

You may share the penetration test report if you will, but we provide a document designed specifically for this purpose. At Oneleet, we offer a Letter of Attestation, which provides a high-level overview of the penetration test, including the tester’s profile and the overall risk score or number of findings. We recommend the Letter of Attestation to be shared with stakeholders.
50 changes: 50 additions & 0 deletions pages/penetration-testing/final-report.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
import { Callout } from "nextra/components";

# Penetration Test Report

The findings from our penetration test form the core of the report you'll receive. Key elements include:

- **Risk Assessment:** The overall risk of the vulnerability, categorized from Low to Critical based on its impact and probability.
- **Vulnerability Description:** A comprehensive overview of each identified vulnerability, written in a clear and accessible manner for a broad audience.
- **Business Impact Analysis:** A brief assessment of the potential consequences of a malicious exploit on the business.
- **Steps to Reproduce:** Detailed instructions for engineers on how to replicate the vulnerability, including the use of publicly available tools whenever feasible.
- **Recommendations:** Specific guidance on how to address the vulnerability, varying in detail depending on the type of finding. These recommendations can range from granular to high-level.

Before comprehending the remediation process for the vulnerabilities discovered during the penetration test, it's important to grasp concepts like **Finding States**, **Characteristics**, or **Overall Risk**.

## Finding States

| Finding State | Description |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Open** | The initial state of every vulnerability once it becomes visible to you. While it's open, you can transition to one of the other states. |
| **Ready for Review** | You mitigated the vulnerability that was ready for retesting. If the penetration tester couldn't reproduce the steps that led to the initial vulnerability, the finding is marked as resolved. However, if the penetration tester managed to reproduce the steps or discovered a similar way to find the vulnerability, the finding is marked as open. |
| **Risk Accepted** | You are prepared to accept the risk that comes with the vulnerability. |
| **Rejected/Closed** | If you deem it appropriate for any reason, the finding will be closed, and further discussions will be held. |

## Finding Characteristics

| Characteristic | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Probability** | The probability of the vulnerability being exploited. Three levels of probability: Low, Medium, or High, based on: Ease of vulnerability exploitation; Attack vectors; Business criticality of the affected asset; System and network complexity. |
| **Impact** | The severity of the vulnerability's effect. The impact of a vulnerability can range from little to no damage to system compromise. The impact can be at 3 levels Low, Medium or High. |

## Risk Levels

| Risk Level | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Informational** | The discovery doesn't directly impact security. However, it could present an opportunity to enhance security, deviate from best practices, or make a security-relevant observation that may lead to exploitable vulnerabilities in the future. For instance, it could involve missing HTTP security headers or documentation that encourages poor security practices. |
| **Low** | Low-risk vulnerabilities are more of a nuisance than a genuine threat. These vulnerabilities are usually those where exploitation wouldn't cause substantial damage, or where the likelihood of exploitation is very low. |
| **Medium** | Medium-risk vulnerabilities are those that could potentially lead to damage if exploited, or where the likelihood of exploitation is moderate. |
| **High** | High-risk vulnerabilities are those that pose a significant risk of causing substantial damage if exploited, or where the likelihood of exploitation is high. |
| **Critical** | Critical risk vulnerabilities are vulnerabilities that have a high potential for exploitation and could lead to data loss or total system compromise. |

> **Note:** Once all remediation efforts have been completed or risks have been deemed acceptable for certain findings, a second report will be generated to reflect the updated status of each individual finding.

<Callout type="warning" emoji="⚠️">
For clients conducting a penetration test for compliance purposes, it's
important to address vulnerabilities in line with your organization's
vulnerability management policy. Failure to do so may lead to concerns raised
by auditors.
</Callout>

If your organization lacks a vulnerability management policy, don't hesitate to reach out to us, and we'll gladly help you establish a reasonable timeline for remediating the identified vulnerabilities.
40 changes: 40 additions & 0 deletions pages/penetration-testing/findings-decisions.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Remediation

After receiving the penetration test report, there are several steps you can take, such as remediation, accepting the risk, or rejecting the findings.

Here’s a brief overview of actions you can take once the penetration test report is ready.

## Analyze

When deciding to address a vulnerability, the first step is to allocate sufficient time to analyze and interpret the report. Your employees responsible for the penetration test should consider the following questions:

- Does this vulnerability meet the risk threshold we've agreed upon internally?
- What's the actual (business) impact of a possible vulnerability exploitation, considering factors that may not be known to the penetration tester?
- Who will be responsible for remediating each finding?

## Remediate

Before taking any further actions, you should verify that the vulnerability is reproducible. This not only enhances your understanding of the issue but also helps identify the systems at risk and different intrusion techniques.

To initiate the remediation phase, you should comprehend the scope of what needs to be fixed. While technical fixes may be necessary, there could also be underlying causes, such as:

- Management practices that require improvements;
- Alternative approaches;
- Ineffective or overly permissive security policies;
- Communication issues within or between departments.

Nevertheless, in most cases, a technical fix must be implemented. We advise remediating the findings as soon as possible, as the chances of the penetration tester still being intimately familiar with the vulnerability are higher, and the probability of an exploitation is lower.

## Retest

As part of our commitment to protecting your organization, we offer free retesting for up to a year after delivering the penetration test, allowing ample time to address vulnerabilities and strengthen your security posture. Remember to align remediation efforts with your internal policies, especially to meet compliance standards like SOC 2, PCI DSS, or ISO 27001.

## Accepting the risk

Marking vulnerabilities as `Accepted Risk` on our platform is entirely at your discretion. We recognize that each client may have a higher or lower internal risk threshold for remediation, and we respect your decision if the analyzed impact is deemed too low to warrant action.

However, we advise against accepting vulnerabilities with a `Medium` or higher risk. As these vulnerabilities pose a growing business risk, they are not a matter of if but when they will impact your organization. Therefore, ensure that you allocate sufficient time and effort to remediate these risks effectively.

Our recommendation is to always provide a clear reason for accepting a risk. This rationale will be included in the penetration test report, allowing you to offer additional context to internal and external stakeholders regarding the acceptability of the risk.

---
Loading