Thanks for this, many interesting points. Many of them, such of
quality of auditors and the vagueness of requirements/specifications
are structural issues present in all industries that will never go
away. There's never enough good people. If you're a shit hot
accountant you're going to be off making millions at a hedge fund or
an IB, not ticking the same boxes every other day in an audit.
Similarly, if you're able to make intelligent decisions regarding ECB
or CBC you're probably not going to enjoy spending your days checking
companies keep their av definitions up to date.

One of the problems with standards/policies/audits is it's easier to
focus on adhering to policy or passing the audit than actually
securing things. Especially if you're a corporate drone (and I say
this as a corporate drone). Realising that policy is wrong, or
standardised audits full of gaping holes, and actually getting people
to do something about it is a difficult, messy, never-ending and
usually thankless task (cause hey, if it was meant to be that way why
wouldn't it say so in the policy?). It's a lot easier to ask if they
want a blue or black pen used to check the boxes.

Policy is useful to beat people over the head with after the event
though, and even a token effort at PCI DSS compliance is going to be a
good thing.

> 9) The dirty little secret that no one is talking about are the operational
>    issues with WAF. Our company discussed possible use with WAF/XML firewalls
>    years before PCI DSS made it "popular".
>    We never got much beyond initial discussions because we couldn't
>    identify any existing personnel within our company who had all the
>    required skills to troubleshoot it AND would be willing to do so.
>    (Think additional "pager duty".) We talked with stakeholders from
>    InfoSec, our company's network engineering team who manages our border
>    firewalls and routers, some *nix and Windows OS system administration
>    teams, and amongst our team. I think there might be only 2, possibly
>    3, people who have sufficient skills to operate and troubleshoot a
>    WAF, and all of those people are smart enough to know that it would be
>    a thankless job and they aren't really looking for additional opportunities
>    to carry pagers. Chances are, we would have to probably hire a few people
>    fully dedicated to this, but even then, there is the question where would
>    they fit organizationally? One possible option not explored--because we had
>    no stakeholders represented who could finance such a thing--would be to
>    outsource the management of WAF to some managed security company such
>    as BT Counterpane, ISS, etc. Anyhow, it's a big problem and one that
>    isn't going to go away.
>    At first, intuition would suggest at first that usual FW teams would be 
> best
>    suited (and that indeed is what most WAF vendors suggest), but for the most
>    part, the usual FW teams' understanding of attacks at layer 7 is often
>    very limited.
>    If you or anyone you know ever comes up with a solution on how to address
>    this particular issue, please let me know. I think it is a show stopper.

IMO the FW team is where it should be. If you have otherwise competent
FW people, they should be able to pick it up. If PCI is a standard
there's going to be a lot of companies requiring WAF expertise, so you
would hope the existing team would be open to learning a new,
desirable skillset/technology.

At my company we have a 24x7 global/follow the sun IDS monitoring
team, and it would probably fall to them.

As I see it, you either implement a boilerplate PCI DSS compliant
policy from your vendor, or hire a consultant to help come up with a
policy that agrees with your company policy as well as PCI DSS.
Infastructure project to implement it, then pass it off to the FW/IDS
team for monitoring.

Like you say in 1) 99% of the PCI DSS is what any good IT organization
should be doing already. The cost to reach PCI compliance shouldn't be
to excessive, but I wonder if it would be cheaper to start your own
PCI auditing company ;-)
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to