4

My resources are limited, and thus i am wondering what methodology can I apply to know where black box testing is best fit, where white box testing is best fit? Or even where pen testing is better than code scanning or than code review?

Please elaborate in details on the HOW such a methodology would help me determine my decisions.

smiley
  • 1,214
  • 2
  • 13
  • 21

1 Answers1

4

It is important to understand that security assessment methods can use either black-box or white-box methods, and can be based upon either automated or manual methods. All 4 combinations are possible (e.g., automated black-box pentesting tools; manual black-box pentesting; automated source code scanners; manual source code review). Also, it is important to understand the difference between a security architecture review (looking for architectural/design issues) and a code assessment (looking for implementation bugs); usually, black-box and automated methods are mostly focused on the latter. I'm going to assume you are focused on a code assessment, looking for implementation bugs.

With that background, here's a suggested checklist to help you decide which method to use:

  1. Do you have source code? If no, use black-box testing. White-box methods require source code.

  2. Have you ever done any kind of security testing, pen testing, security code audit, or other security assessment before? If no, use black-box testing. It is cheaper. Start small and work your way up.

  3. Are you just in it to comply with a mandate, or are you trying to protect your own systems? If this is just about compliance, choose whatever the cheapest answer that will get you to the checkbox (typically black-box testing).

  4. If you've made it to here, you'll need to do a cost-benefit analysis. I would suggest starting with the cheapest methods, use them to improve your security software development lifecycle. Then start by gradually easing into white-box and manual methods, and evaluate the value to your business.

Generally speaking, black-box testing is cheaper than white-box methods, but black-box testing finds fewer bugs. Generally speaking, automated tools are cheaper than manual methods, they scale a lot better to large codebases, and they are better-suited to periodic scans/reviews, but automated tools may find fewer bugs than manual methods.

See also White-box vs. Black-box, Do blackbox penetration tests make sense if a whitebox audit would be possible as well?, Expected cost and time frame for black box pen testing?, How much does a security audit cost?. Don't forget to try using search before posting a new question -- there's lots of good stuff already on this site!

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • THX!!! A follow-up as it is missing in all answers: I assume one would recommend pen testin and/or code review when having a threat model based on the trust boudaries defined. Do you know clear rules when to specify a boundaries as a trust boundary? – smiley May 17 '12 at 15:03
  • @smiley, I don't know about your assumption, but as for [trust boundaries](https://www.fortify.com/vulncat/en/vulncat/java/trust_boundary_violation.html), the short answer is: whenever the stuff on one side of the boundary is trusted and the stuff on the other side is untrusted, that's a [trust boundary](https://en.wikipedia.org/wiki/Trust_boundary). See, e.g., [Microsoft's STRIDE](http://msdn.microsoft.com/en-us/magazine/cc163519.aspx) and its DFDs for some help with identifying trust boundaries. – D.W. May 17 '12 at 17:45