2

My day to day activities consist primarily of penetration testing (white/grey/black). Throughout my engagements, I try to educate my clients on the differences of testing types. E.g., credentialed test from an internal perspective (low level user) versus a complete "zero knowledge" plug and play test. For anyone with experience in either performing the tests, engaging a pentester, what has been the best value in terms of security intelligence.

I opine, and try to sway my clients to engage in low level credentialed tests. These tests often cover zero knowledge, as I can demonstrate exploitation, and escalation with privileges, as well as without privileges. This type of testing can cover the insider threat, as well as a threat actor performing a client side (compromising) an employee's access.

Often times, I find from the results perspective, attackers are leveraging the common low hanging fruit but only after they've "client sided" an employee. "Zero knowledge" external attacks have been highly minimized, and many clients dislike web application testing as they feel it will "bring the house down" and often serves no purpose as many organizations moved their infrastructure to the cloud.

What, from a design/security/network/systems perspective, would you feel is the best value if you were engaging in these types of tests?

munkeyoto
  • 8,682
  • 16
  • 31
  • Stop penetration testing and start red teaming with red team table-top exercises and red team active/live simulations. Do what the real threats do. If real threats use credentials then use credentials. – atdre May 18 '16 at 06:32

2 Answers2

1

It depends what your goals are. If the goal is to find as many vulnerabilities and risks as possible, white box is the best approach. If the goal is "What can an attacker do given X amount of time to my application", then black box is the best approach.

We perform both at our clients and the main difference on when they want what generally depends on what type of resilience they are testing. The white box approach is what we commonly will do for continious and structured testing of applications. The goal here is not to find a single vulnerability and then close shop once you have pawned their systems. It is to provide as much coverage as possible and discover as many vulnerabilities as possible, going from good practice (CSP and HSTS headers) to proper vulnerabilities like XSS.

The latter we use more during engagements where the client wants to test their incident response or detection capability. The focus is on getting in by any means nescessary using any information found in the wild.

In the end it also comes down with what type of client you are dealing, but is also your job to inform your clients about the reason why they need this type of testing. I always tell them that if it is a first time thing the chances are we will discover a lot of things. It's important to make them and their management understand this is not a bad thing and that it is something they can use as an opportunity to improve or request more budgetting to attract more people with security related skills. The client still decides, you can inform them on what you suggest they need, but if they have made up their mind you need to respect that as well, it's their money after all.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
0

Non credential IMO, we called it black box testing. It shows the client what could happen if an attacker broke network and was able to 'explore'. This I think is more valuable as how many systems are going to give credentials away without knowledge. It's a way of testing with no 'help' from the inside, as a real attacker would face.

Bryan
  • 21
  • 4
  • At times it is ok. My secondary work is incident response, forensics, and malware analysis so I see both sides of the equation. Over time, the vast majority of incidents occurred because of a client side attack (browser exploit, phishing, etc). At this stage an attacker is moving around similar to pentesting with a low level credentialed account. It's similar to zero knowledge most times, and we can confirm during tester, whether or not we can perform a similar exploit with zero credentials - which covers black box. – munkeyoto May 18 '16 at 01:06