Great reply.

"Again though, whatever methods are employed, they
always should reflect the needs of the system."

This is exactly why the requirements project is so
important. How can you test unless you know what you
are testing against ?

Does anyone have any thoughts on how you link black
box and white box testing methodically ? ie if you
find you can push very long url paramaters into a
field which returns an HTTP 500, would you / should
you then go look for overflows ASAP ?

It sounds to me that there is a clear line as well
that black box testing is a pure hackers eye
view ......

---- Jeremiah Grossman <jeremiahwhitehatsec.com>
wrote:
> The Owasp Project wrote:
>
> > As you know we are going to capture a topic a week
> > and compile the best knowledge into some of the
> > testing Framework sections at www.owasp.org. So
this
> > weeks topic is Black Box vs White Box testing.
> >
> > What is black box and white box testing;
>
> My take is that "black box" you know nothing about
the system
> and "white box" is you know or have access to
everything within
> the box. Easy enough.
>
>
> > when is it appropriate to use one or the other;
should you do
>
> > both; what can you find with one that you can't
find
> > with another;
>
> In my experience systems have different needs and
expectations
> on security or how secure something needs to be.
These expectations
> can range from "Low"..
to "Decent"...to "High"...to......
> "Ulta-Paranoid-my-system-isnt-even-powered-by-a-
wall-socket".
>
>
> So, the type of pen-tests one should perform should
reflect the
> security needs of the system or who the system
needs to be protected
> from.
>
> Generally speaking, if a modest level of security
required
> to protect against "outsiders", then a
thorough "black box" test
> should be a good choice. Remember, even after a
great
> "black box" test, system insecurity may still exist
and commonly
> do... this is why only expect a "modest" level of
security
> as a result.
>
> If the system requires an increased level of
security above
> the "black box" test, then a "white box" test is a
good choice.
> This type of test will uncover many more system
insecurities and
> instabilities that cause weaknesses than a "black
box" test will.
> Many times "white box" tests are done during a QA
phase.
>
>
> Then, when you need the best measures.... employ
both
> "black box" and "white box". "white box" the system
> to secure it.... then "black box" to estimate the
effectiveness.
>
>
> Done with the babble so, my take....
>
> "black box" == "modest security evaluation"
> "white box" == "better security evaluation"
> "black box + white box" == "best security
evaluation"
>
>
> > is one more skilled; does one cost
>
> > more to do; does one take longer; which one
produces
> > better results etc
> >
>
> Its hard to say what requires more skill.... what
one can say
> that whatever method is employed "due diligence"
should
> be assumed. "white box" testing does indeed take the
> longest and does produce the best information
feedback
> to help increase the security of the system.
>
> Again though, whatever methods are employed, they
> always should reflect the needs of the system.
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]