For a start, we plan to offer penetration testing services for web applications only. When our first service matures, we will add new services to the list. Our services require personal consultation, so to begin the project, we'll need to talk first. Below you will find the project phases we defined in order to complete the assignment.
|Planning phase||∙ Kick-off meeting
∙ Define scope and strategy
|Reconnaissance phase||∙ Information gathering (OSINT)
∙ Port/services scanning
|Attack phase||∙ Check for vulnerabilities
∙ Write PoC/Exploits
∙ Fuzzing inputs
|Reporting phase||∙ Document findings
∙ Risk assesment
∙ Recommendation and solutions
∙ Executive summary
Before starting the assignment, we need to understand the client's needs and expectations. To do this, we plan a kick-off meeting to discuss what will be tested, the relevant risk scenarios, necessary procedures, and other information that we need before we can start working. We will ask the client to show us a demo of the application to understand its behavior and what it does.
Since each penetration test is unique, we cannot say in advance how much it will cost, and it greatly depends on the complexity of the project and the time needed to complete it. After the kick-off meeting, we will follow up with three offers based on how detailed the test will be and how long it will last. When we reach an agreement, and receive a written permission for the engagement we let the client know when we'll start and finish working on the project.
Before we start attacking the application, we allocate time to perform the information gathering. This phase involves collecting as much information as possible about the application in scope, both active and passive, to start the attack phase with enough information to succeed.
The information being collected includes technologies used by the application, business related information, and optionally leaked credentials from public data breaches (to protect against credential stuffing attacks). We use both automated and manual methods to obtain relevant data.
We start the attack phase with an automated vulnerability scan. Since such scanners often report false positives and cannot discover certain types of issues, like business logic flaws, we don't rely on those results but use them only to get a head start before diving deep into the application.
When the automated scan is finished, we proceed with the manual analysis. This part takes the longest and is usually the most rewarding. We try to make the application behave in ways it wasn't supposed to and identify which bugs are vulnerabilities. We follow the industry testing standards (OWASP, SANS, BSI penetration testing model, and others).
To make it easy to replicate our findings, we write small PoC (proof of concept) scripts that the customer can use for independent testing and check if the issue is fixed later on. Fuzzing is a software testing technique that involved providing invalid, unexpected, or random data as inputs to a computer program. When relevant, we try to fuzz the user inputs and check for the application's behavior if this triggered some error or crashed. We do this either using our PoC scripts or specialized software. When we stumble upon a critical vulnerability during testing, we contact the customer immediately to discuss how to proceed instead of waiting to finish the testing.
When the attack phase is finished, we prepare a comprehensive report documenting our findings, listing actionable recommendations, and more. Please take a look at our publications, for examples. In case the customer asked for deliverables in other format, such as a presentation, we prepare it in addition to the standard report. The document is written for multiple audiences, and consist of the following elements:
- Executive summary - a concise summary in easy to understand language with strategic recommendations if applicable.
- Risk assesment - a prioritized risk rating for the findings mapped to customer's business objectives to help decision makers choose the issues that need to be fixed next according to potential business impact and likelihood.
- Detailed list of vulnerabilities - technical description of exploitable vulnerabilities to help developers understand how an attacker could exploit them.
- Additional findings - non-exploitable security issues that can still be a threat in certain situations.
- Recommendations - for both vulnerabilities and additional findings, actionable recommendations are provided to help developers mitigate, transfer or avoid the occurence of those threats. A root cause analysis is performed to identify if it was a single failure or a systematic issue that requires process improvements in the organization.
- Appendix - this section contains information relevant to the penetration test that doesn't fit in previous parts of the report.
After the customer fixed the vulnerabilities, we recommend doing a follow-up test to see if issues are indeed resolved and whether the measures can be bypassed. This retest takes a short time and is not meant to find new vulnerabilities. However, we will still report them if we find something we missed in the first test.
What influences the cost
Depending on the amount of information with which we start, a test is called a black box, gray box or white box pentest. In a black box pentest, we get no additional information, simulating a third party with public information. A white box test is the opposite, giving us full information going all the way to the inspection of the source code. The most frequently used is the gray box pentest, which is a compromise between the two, giving maximum information, but no provision of the source code. The effort needed to complete the project increases with the amount of information we start with, but so do the findings. Some issues can only be discovered by reading the source code, so a balance needs to be found.
We also offer three different price tiers, depending on the levels of complexity and the customers needs. After the first kick-off meeting, we will come back to you with those packages (This is expected to change as our service matures):
|OWASP Top 10||X||X||X|
|Root cause analysis||X|