White Box Approach
A white box approach to testing requires full knowledge and access:
- We know everything you know
- We have access to everything you have access to
Any competent testing firm will recommend a white box approach because it aligns with industry standards and enables full test coverage. We still offer black box testing as an option, but you may receive a significantly lower ROI by paying for unnecessary reconnaissance and enumeration.
White box is always going to be a better value. There’s nothing black box testing provides that cannot also be achieved through a properly executed white box approach. No tests are skipped - all tests are still performed. We’ve calculated white box to be ~20x more thorough compared to black box in terms of the number and thoroughness of tests that can be performed in the same amount of time, which directly impacts cost. Black box can take twice as long or more while delivering less thorough results. This reflects measured differences in time allocation between reconnaissance and active testing across real engagements.
However, white box requires more preparation and setup on the client side.
By default, all engagements are scoped and quoted assuming full white box access will be provided.
Access & Knowledge Standards
Full white box testing assumes that all requested access, credentials, and environment details can be provided before or during testing.
This typically includes:
- User and administrative credentials (where applicable)
- In-scope IP ranges, domains, and applications
- Architecture and environment details
- Visibility into security controls (e.g., firewalls, WAFs, EDR)
These are not conveniences - they are required to perform testing efficiently and at full depth.
What Happens If Full White Box Access Is Not Available
If full white box access is not available, we do not remove testing phases or reduce scope, except within our Basic Tier.
Instead, the approach shifts toward gray or constrained testing, where additional effort is required for discovery, access acquisition, and validation, increasing total time and cost.
This results in:
- Increased effort
- Increased time and cost
- Reduced efficiency
- Reduced depth or coverage
The breakdown below shows how missing access or knowledge impacts effort and cost.
The items below define the required access and knowledge across testing areas. The percentages reflect measured increases in effort (and cost) when specific access or knowledge is not provided.
- All testing types:
- Configuring firewalls, WAFs, VLANs, EDRs, AV, etc. to allow unmitigated testing from a whitelisted IP (Note: we will also test from non-whitelisted IPs): +45% on the low end, up to scenarios where testing cannot be performed in many cases outside of red teaming (adversary simulation).
- Testing credentials/accounts for each role
- Standard user role
- Net: +25%
- Web: +50%
- Administrator role: +15%
- Net: Domain Admin. Note: For testing limited to external systems, user credentials are sufficient, with support from client administrators to run necessary commands under domain admin, and reduces this to +10%.
- Web: Application Administrator role. Note: If app admins do not login directly to the app being tested, but instead access data and manage users via an out-of-scope system (ex. 3rd party data platform), that reduces this to +10%.
- Standard user role
- IP ranges and domains - the testing scope
- Net: +20%
- Web: Required
- Note: We require, at minimum, IP addresses and domain names that are in scope for legal purposes. Pentest and red team engagements can sometimes delay that knowledge until later into testing, but, at some point, it must be provided and verified before any testing begins.
- Password and lockout policies: +15%
- DNS exports: +10%
- Architecture diagrams: +5%
- Log/SIEM access – especially important for web app testing, or if a goal is to validate detection capabilities
- Net: optional
- Web: +10%
- Any information that could reasonably be gathered or access obtained by an attacker, given enough time.
- Networking testing:
- Importing our internal testing VM, which we call a dropbox
- Required use of client Windows VDI: +80 hours
- Required use of client Linux host: +12 hours
- Remote access to an internal workstation: +15%
- Email account(s): +10%
- Importing our internal testing VM, which we call a dropbox
- Web/app testing:
- Source code - web app, mobile app, etc.: +25%
- Backend privileged access to servers (ex. via SSH): +20%
- Access to cloud infrastructure (ex. AWS console and API access): +5%
- Red Teaming (time/costs of each are scenario dependent)
- Adversary Simulation can utilize a trusted insider to:
- provide insider knowledge and assistance
- planning
- testing payloads
- monitoring security dashboards, logs, and alerts
- facilitating a victim-0
- etc.
- Technique Simulation requires the above, as well as close coordination with the SOC/blue team - equivalent to what the blue team has
- Adversary Simulation can utilize a trusted insider to:
- Additional benefits
- Syncs with the red team (during a purple team approach)
- Red team knows what blue knows and has been granted access to everything blue has access to
More information about white box vs black box can be found here: https://penconsultants.com/graybox
*The above is a general list of typical items and the testing they apply to. Specifics may vary based on your unique environment.