When deciding on what type of security assessment to get, an organization should consider how much information they are willing to share. Several types of assessments exist, and the key differentiator is how much access an organization grants the testers from the beginning. The terms blackbox, greybox, and whitebox refer to whether a client chooses not to share any information, to share some information, or to share everything.
Benefits of a Whitebox Approach
Whitebox assessments are completely knowledge-based, which means the client shares diagrams, internal documentation, source code, etc. Going the full knowledge route provides benefits during the assessment that other approaches do not. It allows for solving more complex problems, and particularly adds value in the areas of reconnaissance and analysis.
Ultimately, a whitebox assessment can allow us at Praetorian to maximize our value added in pursuit of client goals and within constraints. Whether the goal is to make a product as secure as possible or to be compliant, the more information we begin with, the better we can help a client meet their goal. Likewise, a whitebox assessment acknowledges common constraints such as time or budget. Simply stated, this type of assessment requires less reconnaissance, which leads to a key benefit that minimizes those two limitations.
Whitebox testing allows a tester to more closely emulate an attacker. This may read as a contradiction, and indeed, potential clients often say (or at least probably think to themselves), “surely, an attacker on the Internet knows as much as an engineer on a blackbox engagement?” Blackbox testing can appear equivalent to an attacker on the Internet, but only at a surface level. In reality, the attacker is not bound by rules of engagement or time, so whitebox testing allows us to emulate an advanced persistent threat in a cost effective manner. Less time spent on reconnaissance translates to more time spent analyzing. For this reason, whitebox assessments tend to result in the discovery of more hard-to-find vulnerabilities.
An assumed-breach scenario is an excellent example of a whitebox approach that delivers high value. With full knowledge from the client, the testers can simulate an insider threat more effectively. They can truly act as if a trusted insider, possessing key knowledge, were launching an attack.
Additionally, whitebox testing is not as noisy as blackbox or greybox testing since testers need to knock on fewer doors, so to speak. Clients find this less disruptive to their daily operations as their organization carries on while in a testing phase.
Praetorian Methodology
At Praetorian, we pair a specialized set of tools with an attacker mindset to perform all of our assessments, regardless of the amount of information the client provides at the start. The tools help us find common vulnerabilities and secrets, and ultimately make us more efficient. We use Burp Active Scans and Semgrep to find common vulnerabilities both dynamically and statically. For secret scanning, we use Nosey Parker (developed in house) and other SAST tools.
We also believe that humans can come up with creative attacks by using their intuition and more manual processes. In that process we use Obsidian to record important details for both the current engineer and the next one. This helps to make sure we are more efficient now and in the future.
Taking this blended approach while exploiting full information from the client during a whitebox assessment may seem like “stacking the deck” in Praetorian’s favor. However, doing so allows us to create a threat model and specifically target our activities to maximize our efforts. In fact, source-code and threat model-driven testing provides our clients with the most value possible in the time window available to perform the assessment. The benefits of a whitebox approach align with our focus on delivering the best value possible to our clients.
