Sometimes all a administrator needs is a indication
on how a "hacker | outsider" would view the system
and while attempting to penetrate. Black-Box is
the best choice in this instance. But... this does not
properly outline a framework for testing....

I see the distinction... a few results of a black box
test may indicate the need for a white box test
afterwards. However, I also would imagine that there
are potentially thousands of possible black-box
results that may indicate a need for a white box test.
Too many in fact to make a framework feasible,
and I dont think the proper course of action anyhow.

In my view... a framework of security requirements
would have to be approached and discussed from a
non-technical point of view.

More of...what (type | level) of security does a
system require...here are the suggested test
mechanisms... ie ...(black box, white box, glass
box.... blue box ;) )...

then within in these mini-framework models... what
technical building blocks make up a "black box | white box "
test.

Taking this approach may gain some ground (if I made
any sense).

Jeremiah-

The Owasp Project wrote:

> 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 ......

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