From: Craig Thomas Elrod (celrodnetcontinuum.com)
Date: Thu May 31 2007 - 13:12:59 CDT

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

I agree with Mark Kraynak's comments, as I am a WAF Vendor as well. My
comments:

~biased vendor response~
PCI has certainly raised the awareness at the Application layer. What is
best for your environment usually comes down to time & money.

To comply with PCI, you are going to have to put your efforts somewhere.
Section 6.5 calls for development of secure code. Section 6.6 calls for a
WAF or Code Review by a qualified organization. If you have a lot of time
and money, hire a firm to review your code, if you don't have a lot of time
or money, install a WAF. Will a code review firm recommend a WAF turning
6.6 into an AND rather than an OR? There is a high probability, but this
remains to be seen.

Working for a WAF vendor, I believe in the solid security that a WAF can
provide. I also understand there are many sites that choose not to install
WAF's and choose to perform secure coding practices and implement homegrown
solutions.

The perception that WAFs are difficult to implement is old school and
lingers. The modern WAF has several different deployment modes, including
one that does transparent bridging and fails-open, such that service is
never disrupted.

Can the WAF control every part of the application? It can if you put that
type of logic into it, especially with regard to access control and
authentication. The modern WAF is integrated with CA SiteMinder and RSA
Access Manager. There are also options for sending cookies back/forth to
the servers. Additional application information can be passed in the headers
through macros.

I have attempted to install the OWASP SiteGenerator software, but am having
some trouble getting the documentation to match my implementation, so I have
yet to get it working. Aside from that, it looks promising.

Kind Regards,
Craig Elrod
NetContinuum, Inc.

-----Original Message-----
From: Mark Kraynak [mailto:markimperva.com]
Sent: Thursday, May 31, 2007 10:44 AM
To: WASC Forum; webappsec OWASP; webappsecsecurityfocus.com
Cc: Raymond Forbes; Bubba Gump; James Landis; Ory Segal
Subject: RE: [WEB SECURITY] Re: [Webappsec] PCI 6.6 Questions

I realize I'm a few days behind, but I also had some comments I wanted
to add.

First, two disclaimers:
1 - I work for a WAF vendor (Imperva)
2 - I'm in marketing...but I will do my best to stay away from "spin"

Here's my response to your questions, sorry for the redundancy, but for
easier reading I'm pasting in the original questions I wanted to touch
on:

> > > 1. Assuming a company only has enough resources to do one or the
> > > other, which would you recommend, and why? Which option is the
> > > easier/cheaper route to compliance? Which is likely to lead to
> > > the most real improvement in security?

First, I'd recommend both in a more ideal situation, but that's not the
question. I would recommend WAF (see disclaimer), let me say why:

a) WAF is likely to be a faster route to improvement. The reason is
that the process of finding errors and recoding them (along with QA
cycles, etc.), in my experience, takes much longer than deploying a WAF
and protecting from the same issue.

b) WAF is also likely to be less costly (as the time and effort to fix
code can be very high as others have stated).

That said there are some important disclaimers:

Raymond: I think that you are correct to mention performance and
operational maintenance of WAFs as important considerations. These are
two of the key areas of differentiation between competitors in the WAF
market. I feel that some vendors (in my opinion, notably my employer)
have provided very strong answers to these challenges. Though, as with
any technology product, mileage may vary and it's best to see how it
works in your environment (lucky for you, most WAF vendors are willing
to let you test drive)

> > > 3. Does "all custom application code" mean all of our credit card

> > > processing code, or every line of code behind every one of our
> > > Internet-facing websites?

I'm not in a position to say what PCI auditors will accept. I can say
that this question points to another area of consideration between the
two approaches. A good WAF will make this decision basically moot.
Deploy it to protect everything so you don't have to make a risky
choice. (again: this means you need to find a WAF that can handle the
performance load and is easy enough to operate to make this feasible).

Mark Kraynak
Director of Product Marketing, Imperva

-----Original Message-----
From: listbouncesecurityfocus.com [mailto:listbouncesecurityfocus.com]
On Behalf Of James Landis
Sent: Tuesday, May 29, 2007 7:34 AM
To: Ory Segal
Cc: Raymond Forbes; Bubba Gump; webappsec OWASP; WASC Forum;
webappsecsecurityfocus.com
Subject: Re: [WEB SECURITY] Re: [Webappsec] PCI 6.6 Questions

The qualified ASV list below is not valid for the new PCI reqs; there
is a separate certification process to make the list for source
review.

There has already been a ton of great discussion on WAF vs. source
assessment, but there are a few pieces missing I'd like to throw on
the fire:

1) Expect the PCI reqs to say AND instead of OR at some point down the
road; an investment in either category is not likely to be wasted
unless of course it is spent with a vendor/consultant that is not
giving you what you paid for.

2) WAFs can do a lot of good things at runtime that even perfectly
secure static code can't; I've been harping on the "Web Application
IPS" angle for a while now, especially with behavior-based signatures.
No one is seriously playing in this space, but it's the natural
progression, just as things evolved from FW to IDS to IPS on the
network side. IPS at the app layer has a number of other advantages
compared to NIPS and significant security improvement can be gained
very quickly with a minimal set of rules. $billions to the first
player to own this market - I'd recommend you to every one of my
customers.

-j

On 5/25/07, Ory Segal <osegalwatchfire.com> wrote:
> Hi,
>
> Take a look at this list:
> https://www.pcisecuritystandards.org/pdfs/asv_report.html , which
> contains ASVs.
>
> Thanks,
> -Ory
>
>
>
> > -----Original Message-----
> > From: Raymond Forbes [mailto:rforbese-stalkers.net]
> > Sent: Friday, May 25, 2007 2:17 AM
> > To: Bubba Gump
> > Cc: webappsec OWASP; WASC Forum; webappsecsecurityfocus.com
> > Subject: [WEB SECURITY] Re: [Webappsec] PCI 6.6 Questions
> >
> > There are some interesting questions in there....
> >
> > 1) that really depends on the org and the size of your
> > infrastructure.
> > Web App Firewalls seem ok if you aren't pushing too much
> > traffic and are willing to do spend the time maintaining it.
> > Most of them seem to have some level of heuristics but I
> > can't imagine there is no administration necessary. On the
> > other side, however, having a 3rd party audit your code can
> > be really expensive, not even counting the time it takes to
> > remediate all the problems found.
> >
> > 2)That is still a controversial question. One of the SPI
> > guys exchange mailed with the PCI committee who agreed the
> > SPI pen test tool was sufficient. I have talked to a couple
> > of auditors who do not agree.
> > From what I understand this is still being hashed out and we
> > should know better by the end of the summer.
> >
> > 3) Personally, I am looking at that as "in scope" code.
> > Which means, only apps that deal with credit card data.
> >
> > 4) That hasn't really been defined. I am guessing we will
> > get further clarification by the end of the summer or when
> > the new standard is released. It is always possible that it
> > will be at the auditors discretion.
> >
> > -Raymond
> >
> >
> > Bubba Gump wrote:
> > > I have a couple of questions about PCI section 6.6. It states
that
> > > companies will need to do one of the following two things:
> > >
> > > Having all custom application code reviewed for common
> > vulnerabilities
> > > by an organization that specializes in application security
> > >
> > > or
> > >
> > > Installing an application layer firewall in front of web-facing
> > > applications.
> > >
> > > I have the following questions about this requirement:
> > >
> > > 1. Assuming a company only has enough resources to do one or the
> > > other, which would you recommend, and why? Which option is the
> > > easier/cheaper route to compliance? Which is likely to lead to
the
> > > most real improvement in security?
> > >
> > > 2. Would hiring a company to do black-box scanning and
> > testing of our
> > > websites satisfy the first option? Or would we actually
> > need to have
> > > the company go through our code line by line and review it for
> > > security defects?
> > >
> > > 3. Does "all custom application code" mean all of our credit card
> > > processing code, or every line of code behind every one of our
> > > Internet-facing websites?
> > >
> > > 4. If we go with the code review option and the company
> > that we hire
> > > finds a bunch of issues with our code, are we required by
> > PCI to fix
> > > all of the issues, just certain types of issues, or none of
> > the issues?
> > >
> > > Thanks,
> > > Bubba
> > >
> >
----------------------------------------------------------------------
> > > --
> > >
> > > _______________________________________________
> > > Webappsec mailing list
> > > Webappseclists.owasp.org
> > > https://lists.owasp.org/mailman/listinfo/webappsec
> > >
> >
> >
> > --------------------------------------------------------------
> > --------------
> > Join us on IRC: irc.freenode.net #webappsec
> >
> > Have a question? Search The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/
> >
> > Subscribe via RSS:
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
>
>
------------------------------------------------------------------------
----
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
>

------------------------------------------------------------------------
-
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have
seen,
and outlines a guideline for developing secure web applications.
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
------------------------------------------------------------------------
--

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

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

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

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------

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