• caglararli@hotmail.com
  • 05386281520

Are peripheral issues and systems normally considered in a white box penetration testing scope?

Çağlar Arlı      -    10 Views

Are peripheral issues and systems normally considered in a white box penetration testing scope?

As Wikipedia defines:

White-box testing is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing).

When the code is a target of its own, this is not (only) a penetration test but a source code security audit (or security review).

... "white-box" originally meant using the source code ...

While this is narrowly defined and quite specific and could be defined to a specific repository and branch to be tested. What do we do with peripheral issues or peripheral systems that (could indirectly) affect the intended scope? For example:

  • Behavior. Walking around the target office and finding post-its with passwords of developers?
  • Organizational. Not having a cooperate information security policy?
  • Developer devices being unmanaged, not having EXR/XDR/SIEM/full disk encryption in place?
  • The developer office having an open or WEP-protected WiFi-network with a weak password and no network isolation?
  • Relevant cloud services not having multi-factor authentication (MFA)?
  • All employees having root or global administrator permissions?

These are just a few random examples that could (severely) impact the security of the production systems that run on the source-code that's intended to be tested. When to consider such "indirect" risk, or lack of systems in a white box test, if at all? Should those type of findings be reported in a white box penetration testing report as well or not? Are there any open (white box) penetration testing standards that define how to deal with this?