27 lines
2.8 KiB
Typst
27 lines
2.8 KiB
Typst
|
||
#let render() = {
|
||
[
|
||
== Penetration Testing Box Scenarios
|
||
|
||
Penetration testing engagements are classified by the level of information provided to the testing team. This classification directly impacts the methodology, scope, and findings. The three standard scenarios are *Black Box*, *Grey Box*, and *White Box*. While Black Box and White Box refer to quite clear and precise situations, Grey box is a bit vague, in-between of both. Due to this, these terms should always be interpreted in the current situation and not be seen as precise and clear terminology. Nonetheless, the selection of the box scenario directly determines the scope of findings and realism of threat simulation. Black box tests external risks, grey box evaluates insider-adjacent threats, and white box provides the deepest technical analysis.
|
||
|
||
=== Black Box Testing
|
||
|
||
The testing team has no prior knowledge of the target system (e.g., internal architecture, source code, credentials, or network topology). Testing simulates an external attacker with only publicly available information. The purpose is to evaluate realistic attack surfaces, unpatched vulnerabilities exposed to the internet, and the effectiveness of perimeter defenses.
|
||
|
||
For example: a penetration test against a company’s public-facing e-commerce website. Testers are provided only the domain name and must identify vulnerabilities using only publicly available and gathered information. No access to internal systems or credentials is granted.
|
||
|
||
=== Grey Box Testing
|
||
|
||
The testing team is provided limited, realistic information (e.g., user credentials, network diagrams, or documentation). This simulates a threat actor with compromised credentials or insider access. The purpose is to bridge the gap between external and internal testing; uncover vulnerabilities exploitable by authenticated users or partial insider knowledge.
|
||
|
||
For example: testing a corporate web application where testers are given a low-privileged user account (e.g., "standard employee" credentials). Testers identify issues like privilege escalation, insecure data handling, or business logic flaws that an internal user could exploit.
|
||
|
||
=== White Box Testing
|
||
|
||
The testing team has complete, detailed access to the target system (e.g., source code, infrastructure diagrams, credentials, and system configurations). This simulates a highly motivated insider threat with deep system knowledge. The purpose is to perform exhaustive code-level analysis, identify root causes of vulnerabilities, and validate secure development practices.
|
||
|
||
For example: reviewing the source code of a custom mobile banking application. Testers are provided full access to the code repository, database schemas, and API documentation to identify flaws like hardcoded secrets, cryptographic misconfigurations, or insecure API endpoints.
|
||
]
|
||
}
|