Re: [WEB SECURITY] Re: The Great WAF Debate

[Pete Herzog <lists@xxxxxxxxxx>]

Sorry you dislike analogies. I was only trying for clarity.

> First issue: You cannot declare something as being secure. Security 
is not a
> declaration or proclamation. Security must be proven every single 
day, at
> every single use.

Perhaps.  I was referring to operational security, which is more about
protection than about "freedom from risk" which I agree doesn't exist.
Ever. It's a bad definition. So bad that it's not possible to discuss
security in those terms.  In the case of operational security, where
the controls leverage the interactions through the established
protection, it is possible to have operational security continuously
in a non-physical environment.  This requires a defined scope,
processes, services, and controls over the environment. Then, the only
patching that should ever be necessary is for improving functionality.
 This is also something a WAF should be capable of providing on its
own, regardless if its defensive functionality as a WAF is imperfect.

>
> Second: Your example is for a specific piece of compiled software 
that was
> written and designed to perform a very specific function.  At that
> functional level it is possible to enumerate all the inputs & 
outputs, it is
> a specific finite operation and so it therefore can be secured, 
compiled,
> and stamped with the USDA grade A seal of approval from inspector 
12... but
> this was never at issue.  At issue here is entire operating systems &
> platforms, development environments, etc.

My example was just an example to counter your argument which was
itself extreme.  So why isn't security software, like a WAF, built, as
you say, where they "...enumerate all the inputs & outputs..." with
"...a specific finite operation..." to "...be secured, compiled, and
stamped with the USDA grade A seal of approval from inspector 12."?
It IS security software.  This is my problem with it. Why do we accept
security solutions to be as bad as the services they are defending?
I'm alright with services not built for security because they have
another function and should be able to successfully meet it.  But if
they are built for security, shouldn't the designers/developers be a
bit more careful?

> 	MY issue was never that a programmer is not able to write secure
> code, it is that the whole application will remain vulnerability free
> throughout all the design updates, platform migrations, code reuse. The
> issue is not that release 11.4.203 of *whatever* is not secure, but 
that all
> releases of all versions are secure - including the software that  my
> programmers didn't write that interfaces with the code that they 
DID write
> using backend api's in an insecure fashion...

So why are WAFs then developed to exist on insecure systems?  Why does
the WAF have transparent interactions (Visibilities and Accesses in
OSSTMM terminology) for which it can't be protected?  So a WAF on
insecure architecture sold as a security solution sort of missed the
point.  Otherwise, it should be sold as a web input filter, for
example, and then it doesn't have to be a WAF security
product/solution for which it cannot deliver.

-pete.
isecom.org

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA