diff --git a/.github/workflows/preview.yml b/.github/workflows/preview.yml
deleted file mode 100644
index 573b9a0..0000000
--- a/.github/workflows/preview.yml
+++ /dev/null
@@ -1,25 +0,0 @@
-name: Preview Environment
-
-env:
- VERCEL_ACCESS_TOKEN: ${{ secrets.VERCEL_PREVIEW_ACCESS_TOKEN }}
- VERCEL_PROJECT_ID: prj_gXKEVY0vt6eS7uIN8IMduRblu4JM
-
-on:
- pull_request:
- types: [opened, synchronize, closed]
- branches:
- - main
-
-jobs:
- deploy:
- if: ${{ github.event.action == 'opened' || github.event.action == 'synchronize' }}
- runs-on: ubuntu-latest
- steps:
- - uses: snaplet/vercel-action@v3
- delete:
- if: ${{ github.event.action == 'closed' }}
- runs-on: ubuntu-latest
- steps:
- - uses: snaplet/vercel-action@v3
- with:
- delete: true
diff --git a/pages/_meta.ts b/pages/_meta.ts
index 39b797a..5fd2e31 100644
--- a/pages/_meta.ts
+++ b/pages/_meta.ts
@@ -3,6 +3,7 @@ export default {
"integrations": "Integrations",
"oneleet-agent": "Oneleet Agent",
"guides": "Guides",
+ "penetration-testing": "Penetration Testing",
"support": {
"title": "Support",
"type": "page",
diff --git a/pages/penetration-testing/_meta.ts b/pages/penetration-testing/_meta.ts
new file mode 100644
index 0000000..2e54a73
--- /dev/null
+++ b/pages/penetration-testing/_meta.ts
@@ -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"
+};
diff --git a/pages/penetration-testing/documents.mdx b/pages/penetration-testing/documents.mdx
new file mode 100644
index 0000000..ad679d8
--- /dev/null
+++ b/pages/penetration-testing/documents.mdx
@@ -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 |
diff --git a/pages/penetration-testing/faq.mdx b/pages/penetration-testing/faq.mdx
new file mode 100644
index 0000000..4ac1d37
--- /dev/null
+++ b/pages/penetration-testing/faq.mdx
@@ -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.
diff --git a/pages/penetration-testing/final-report.mdx b/pages/penetration-testing/final-report.mdx
new file mode 100644
index 0000000..3c05182
--- /dev/null
+++ b/pages/penetration-testing/final-report.mdx
@@ -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.
+
+
+ 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.
+
+
+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.
diff --git a/pages/penetration-testing/findings-decisions.mdx b/pages/penetration-testing/findings-decisions.mdx
new file mode 100644
index 0000000..d4d6e6f
--- /dev/null
+++ b/pages/penetration-testing/findings-decisions.mdx
@@ -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.
+
+---
\ No newline at end of file
diff --git a/pages/penetration-testing/pci-dss.mdx b/pages/penetration-testing/pci-dss.mdx
new file mode 100644
index 0000000..fcfd4bb
--- /dev/null
+++ b/pages/penetration-testing/pci-dss.mdx
@@ -0,0 +1,50 @@
+# PCI DSS Penetration Test
+
+If you hired Oneleet for a PCI DSS penetration test, there will be a few minor differences compared to our regular penetration testing process. The primary objectives of the PCI DSS penetration test are to:
+
+- Validate that the cardholder data environment (CDE) is isolated, secure, and compliant with PCI DSS standards.
+- Ensure that cardholder data (CHD) is protected from unauthorized access.
+- Identify and remediate vulnerabilities that could compromise cardholder data.
+
+As a result, the following processes will be slightly different:
+
+- The scope of the penetration test.
+- The documentation before the PCI DSS Application penetration test.
+- The frequency of penetration testing.
+
+## Scoping of a PCI DSS Application Penetration Test:
+
+During the scoping call, in addition to the already mentioned points, the following aspects will also be considered for a PCI DDS application penetration test:
+
+- **Application Security Testing**
+ - Test all applications within the CDE that handle CHD to identify security vulnerabilities, including those that adhere to OWASP standards. This involves evaluating for common threats such as SQL injection, Cross-Site Scripting (XSS), authentication vulnerabilities, and authorization flaws.
+- **External Application Testing**
+ - Simulate attacks on externally accessible applications that provide access to or protect CHD. External testing verifies the security of internet-facing applications by identifying misconfigurations, exposed ports, and external access vulnerabilities.
+- **Internal Application Testing**
+ - Perform assessments on applications accessible from within the internal network. This involves testing for unauthorized access, privilege escalation, and potential risks of lateral movement if a user gains unauthorized access to the CDE.
+- **Segmentation Testing**
+ - Confirm that network segmentation effectively isolates CHD-related applications from the rest of the environment, minimizing the PCI scope.
+
+## Documentation provided before the PCI DSS Application Penetration Test:
+
+Consider providing the following documentation after or before the scoping call:
+
+- A network diagram illustrating all network segments within the scope of the test;
+- A cardholder data flow diagram;
+- A list of all anticipated services and ports exposed at the CDE perimeter;
+- Details on how authorized users access the CDE;
+- A list of all network segments that have been isolated from the CDE to minimize the scope.
+
+## Frequency of PCI DSS penetration tests
+
+According to **PCI DSS Requirements 11.3.1 and 11.3.2**, penetration testing is mandatory at least annually and after any substantial alterations to the network environment. These alterations may encompass infrastructure upgrades, application modifications, or the installation of novel system components.
+
+The definition of a **“significant change”** fluctuates based on an **organization’s risk assessment** process and the specific configuration of its environment. Since PCI DSS doesn’t provide a rigid definition of a significant change, it’s up to each entity to assess whether a change could potentially compromise network security or expose cardholder data. If a modification could potentially affect security or access to cardholder data, it’s generally regarded as significant and should prompt a penetration test.
+
+### Example of a Significant Change
+
+**Migration to a New Firewall System**: Upgrading or replacing the firewall safeguarding the CDE is a substantial change because it directly affects network security. This transition could introduce novel configurations, alter network paths, and influence data flow, potentially compromising cardholder data. Given the critical role firewalls play in security, a penetration test is essential to validate that security controls are functioning as intended.
+
+### Example of a Non Significant Change
+
+**Patch for a Non-CDE System**: Applying a minor software patch to a system outside the CDE that doesn’t interact with or impact cardholder data would be considered a non-significant change. This maintenance doesn’t alter security controls in the CDE or affect access to sensitive data, so a penetration test under PCI DSS is not necessary.
diff --git a/pages/penetration-testing/pentesting-classification/_meta.ts b/pages/penetration-testing/pentesting-classification/_meta.ts
new file mode 100644
index 0000000..10b958f
--- /dev/null
+++ b/pages/penetration-testing/pentesting-classification/_meta.ts
@@ -0,0 +1,4 @@
+export default {
+ "access-level": "Black, Grey and White-box",
+ "attack-vector": "Internal and External"
+ }
\ No newline at end of file
diff --git a/pages/penetration-testing/pentesting-classification/access-level.mdx b/pages/penetration-testing/pentesting-classification/access-level.mdx
new file mode 100644
index 0000000..1581e9f
--- /dev/null
+++ b/pages/penetration-testing/pentesting-classification/access-level.mdx
@@ -0,0 +1,29 @@
+import { Callout } from "nextra/components";
+
+# Black, Grey and White-box Penetration Testing
+
+At Oneleet, we tailor our approach to meet each client’s needs.
+We recognize that businesses vary in size, goals, and requirements, so we develop customized strategies for success.
+
+Generally, there are three types of penetration testing scenarios. Let’s break it down:
+
+## White Box Penetration Testing
+
+The tester possesses complete knowledge of the system’s source code, architecture, and network details.
+This scenario resembles an attacker with in-depth understanding of the system’s inner workings.
+Such an attacker could be a disgruntled employee, a contractor, or someone who has gained unauthorized access to sensitive internal information.
+
+## Gray Box Penetration Testing
+
+The tester may have limited access to internal documentation or user credentials, which could be exploited by an attacker with some inside information or limited access to the system.
+
+
+ This is the type of penetration testing we most often recommend to our
+ clients, as it provides a balanced approach in terms breadth, and depth.
+ However, depending on the company's nature, product, and likely attack
+ vectors, other types of penetration testing might be more relevant.
+
+
+## Black Box Penetration Testing
+
+The tester, lacking prior knowledge of the system, adopts an external hacker’s perspective. The simulated attacker embodies a hacker attempting to breach the system from the outside. They employ techniques such as reconnaissance, social engineering, and vulnerability scanning to identify potential weaknesses.
\ No newline at end of file
diff --git a/pages/penetration-testing/pentesting-classification/attack-vector.mdx b/pages/penetration-testing/pentesting-classification/attack-vector.mdx
new file mode 100644
index 0000000..96053f7
--- /dev/null
+++ b/pages/penetration-testing/pentesting-classification/attack-vector.mdx
@@ -0,0 +1,8 @@
+# Internal and External Penetration Testing
+
+Sometimes, there’s also a distinction made between internal and external penetration testing.
+If the previous Black/Grey/White categorizes tests by what the tester knows/can access, the Internal/External one categorizes tests by where the testing originates.
+
+**External Penetration Testing** simulates an attack originating from outside the organization, specifically targeting internet-facing assets such as web applications, firewalls, and public servers. The primary objective is to uncover vulnerabilities that an external attacker could potentially exploit. Common targets include websites, virtual private networks (VPNs), and cloud resources. These tests encompass a range of scenarios, including misconfigurations, compromised passwords, and outdated software.
+
+**Internal Penetration Testing** simulates an attacker who has already gained access to the internal network. It focuses on internal security controls, access permissions, and lateral movement capabilities, targeting internal systems, applications, and sensitive data.
diff --git a/pages/penetration-testing/process-overview.mdx b/pages/penetration-testing/process-overview.mdx
new file mode 100644
index 0000000..822658b
--- /dev/null
+++ b/pages/penetration-testing/process-overview.mdx
@@ -0,0 +1,38 @@
+# Penetration Testing High-level Overview
+
+
+
+1. **Scope**
+
+- 30-minute scoping call, in which our penetration tester will be present.
+- We expect you to provide a comprehensive overview of the product, including a demo of the application. While an architectural design is not mandatory, it would be appreciated.
+- A showcase of Oneleet’s platform used for vulnerability management is provided.
+- The assigned penetration tester will attend the meeting and ask questions to better understand your application/infrastructure.
+- The Rules of Engagement will be discussed (timeline, scope, ways of communication, etc.)
+- After the scoping call we will send over a summary of what was discussed.
+
+2. **Prepare**
+
+- Provide the necessary permissions and details of the environment discussed during the scoping call, including user accounts, IP addresses, and possibly required credentials. A summary of the required information will be provided after the scoping call.
+- An invitation will be sent to your team in charge of supervising the penetration test to create an account on Oneleet’s platform.
+
+3. **Test**
+
+- Any found critical vulnerabilities will be immediately brought to your attention via Slack.
+- Using various tactics, techniques and procedures to identify security caveats, our penetration testers will attempt to exploit the identified vulnerabilities to assess how deeply they can penetrate the system.
+
+4. **Report**
+
+- All discovered vulnerabilities will be uploaded on Oneleet’s platform.
+- After the engagement concludes, our internal team will revise the Penetration Test Report, which will be made available within 2 to 3 business days.
+- The final Penetration Test Report will include an executive summary, risk ratings, detailed findings, and recommendations.
+
+5. **Remediate**
+
+- If necessary, you can remediate the vulnerabilities, and our penetration tester will retest the system within a couple of days.
+- At this stage, you also have the option to accept the risk or reject the vulnerability.
+- Once all findings have been addressed, an updated report will reflect the new state of each finding.
+
+6. **Evaluate**
+
+- For instance, discuss any unaddressed risks that your company accepted, confirming that these decisions align with your risk management strategy. Ensure that the risk remains acceptable over time.
diff --git a/pages/penetration-testing/ptaas.mdx b/pages/penetration-testing/ptaas.mdx
new file mode 100644
index 0000000..b9cde87
--- /dev/null
+++ b/pages/penetration-testing/ptaas.mdx
@@ -0,0 +1,20 @@
+# Penetration Testing as a Service (PtaaS)
+
+## About Us
+
+Oneleet is a U.S.-based cybersecurity company founded and run by experienced penetration testers. We offer flexible penetration testing options and a comprehensive platform to manage and address security vulnerabilities, helping your organization build and maintain a strong security posture. Backed by venture capital firms like Y Combinator, Oneleet combines expert testing services with an intuitive management system, serving clients ranging from enterprises to early-stage startups. With a focus on support, effectiveness, and communication, Oneleet has established itself as a leading provider in the cybersecurity and compliance space.
+
+## Our Penetration Testing Goal
+
+> Identifying vulnerabilities to reduce risk. Simulating real world attacks on your applications, systems and networks.
+>
+
+The primary goal of penetration testing at Oneleet is to uncover vulnerabilities before they can be exploited by malicious actors. We look forward to partnering with you to identify risks and implement effective protection measures.
+
+## Services
+
+Oneleet provides expertly conducted penetration testing services, delivered by a team of highly qualified professionals from NATO countries. Our experts hold advanced certifications such as OSCP, OSCE, and OSWE, attesting to their high level of technical competance. Their expertise spans network penetration (wired and wireless), web and mobile application security, social engineering, and code reviews. This diverse skill set allows them to identify vulnerabilities across a wide range of systems and technologies.
+
+We offer flexible retesting options as part of our standard penetration testing package, along with a comprehensive platform for managing vulnerabilities.
+
+At Oneleet, we frequently conduct penetration tests to help organizations meet compliance requirements for frameworks like SOC 2, ISO 27001, PCI DSS, HIPAA, and more.
diff --git a/pages/penetration-testing/services/_meta.ts b/pages/penetration-testing/services/_meta.ts
new file mode 100644
index 0000000..96fb541
--- /dev/null
+++ b/pages/penetration-testing/services/_meta.ts
@@ -0,0 +1,4 @@
+export default {
+ "areas": "Pentesting Engagements",
+ "packages": "Pentesting Packages"
+}
\ No newline at end of file
diff --git a/pages/penetration-testing/services/areas.mdx b/pages/penetration-testing/services/areas.mdx
new file mode 100644
index 0000000..dd88563
--- /dev/null
+++ b/pages/penetration-testing/services/areas.mdx
@@ -0,0 +1,7 @@
+# Penetration Test Engagements
+
+Oneleet’s penetration testing team specializes in several types of engagements, including:
+
+| Network Pentesting | Mobile App Pentesting | Web App Pentesting | Wireless Network Pentesting | Social Engineering Pentesting |
+| :-----------------------------------------------------------------: | :------------------------------------------------------------: | :----------------------------------------------------------: | :--------------------------------------------------------------: | :---------------------------------------------------------: |
+| Pentest Program Management | IoT Ecosystem Testing | Red Team Assessment | Digital Risk Assessment | Secure Code Review |
diff --git a/pages/penetration-testing/services/packages.mdx b/pages/penetration-testing/services/packages.mdx
new file mode 100644
index 0000000..7793e29
--- /dev/null
+++ b/pages/penetration-testing/services/packages.mdx
@@ -0,0 +1,20 @@
+# Penetration Test Packages
+
+At Oneleet, we offer **3** different types of penetration test packages.
+
+| Feature | Compliance | Comprehensive | Custom |
+| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Description** | A high-level assessment of your application, evaluating the effectiveness of your security measures. | A penetration test that examines all aspects of your application's attack surface to identify vulnerabilities across all categories. | A penetration test that examines all aspects of your application's attack surface to identify vulnerabilities across all categories. |
+| **Target** | Web Applications
Mobile Applications
APIs
| Web Applications
Mobile Applications
APIs
Networks
Cloud Assessmentss
Secure Code Reviews
Social Engineering
| Web Applications
Mobile Applications
APIs
Networks
Cloud Assessmentss
Secure Code Reviews
Social Engineering
Red Teaming
IoT Devices
|
+| **Use cases** | Vulnerability testing of existing & new features. Often sufficient for early-stage companies going through SOC 2 | Vulnerability testing of existing & new features. Microservices testing. Testing based on several OWASP frameworks | Companies with multiple applications, red teaming, etc. |
+| **Testers** | Manual test with a penetration tester that is at minimum OSCP & OSCE/OSWE certified | Manual test with a penetration tester that is at minimum OSCP & OSCE/OSWE certified | Manual test with a penetration tester that is at minimum OSCE/OSWE certified |
+| **Customizable Report** | Not Included | Included | Included |
+| **Support** | Answer within 48H | Dedicated point of contact that answers within 24H | Dedicated point of contact that answers within 24H |
+| **Free Retesting** | 12 months | 12 months | 12 months |
+| **Rush delivery** | Optional | Optional | Included |
+| **Letter of Engagement** | Included | Included | Included |
+| **Letter of Attestation** | Included | Included | Included |
+| **Customized Letters** | Not included | Included | Included |
+| **Onboarding Support** | Slack | Slack & Live | Slack & Live |
+| **Dedicated Customer Success Manager** | Not included | Included | Included |
+| **Used Standards** | Pentest conducted in accordance with industry-standard methodologies such as OWASP Top-10 | Pentest conducted in accordance with industry-standard methodologies such as OWASP WSTG, OWASP ASVS, etc. | Pentest conducted in accordance with industry-standard methodologies such as OWASP WSTG, OWASP ASVS, etc. |
diff --git a/public/penetration-testing/process.png b/public/penetration-testing/process.png
new file mode 100644
index 0000000..4c771ec
Binary files /dev/null and b/public/penetration-testing/process.png differ