An interested sc-l reader who wishes to remain anonymous responded by mail to
my PCI article.  Here is what the reader had to say (posted with permission).


I have been involved in some of the PCI efforts here at my company.
There's not much that my company would probably allow me to say on-the-record.

However, here are my impressions from where I sit (tech lead of our
company's application security team, a team where we help IT dev teams
implement designs and write secure code that's compliant with our
corporate information security team's [InfoSec] corporate security policies,
which they set).

We have almost 2 dozen apps affected by PCI. For the most part, our team
has been instructing dev teams about crypto and white-listing of data to
prevent XSS, SQL injections, etc. My team also has also developed Java
and .NET class libraries that try to make some of this stuff simpler for
your run-of-the-mill app developer. These libraries are used a lot with
these applications affected by PCI DSS.

Our corporate InfoSec team deals directly with PCI auditors. I've only
been able to _indirectly_ interact with them via email filtered through
my InfoSec contacts.

Despite this, I have formed quite a few opinions about both PCI DSS and these
PCI auditors, which I will share. Note that these opinions do not reflect the
official position of my company, but probably are representative of
peers within my group.

1) 99% of the PCI DSS is what any good IT organization should be doing
   already. There is very little new here. As you (GEM) put it, it sets
   a low bar. It only seems like a high bar to IT because most IT departments,
   in fact, do not do these things. (Our company was probably already
   doing about 1/2 of the requirements in DSS v1.0.)

2) What makes PCI effective is the fear that businesses will be found
   to be non-compliant and as a result have to pay fines or higher interest
   rates to the credit card companies. Either way, it costs them cash if
   the fail to comply so it makes the SROI a bit easier to measure than

3) A "threat" that doesn't seem to be considered is a "rubber hose attack"
   that a company might aim at PCI auditors themselves. The PCI consortium
   may (and could) deal with this effectively mandating that PCI auditors
   be randomly selected and restricting the duration and number of audits
   that the auditors may perform at a specific company. However, it was
   my impression (based on InfoSec feedback) that our company has had the
   same auditor for over a year, so I don't think this is probably happening.

4) The PCI DSS is vague if one attempts to read them as "specifications", but
   they work OK as simple general "guidelines". As specs, they leave too much
   "wiggle room". Where this causes problems is where you need to be able
   to *test* for PCI DSS compliance BEFORE the PCI auditor comes around.
   Whether or not you pass, could (in theory at least) depend on the auditor
   you end up with. (Which is perhaps why we have the same auditor for the
   past 2 yrs or so.)

   Example: Think of all the incorrect ways that one could implement the
   encryption requirements. The DSS doesn't mention which ciphers are
   acceptable, which cipher modes to use, etc. This could result in
   some poorly implemented crypto in the applications but still satisfy
   the letter of the requirements. (If you don't believe that, just look
   at the whole WEP fiasco. The IEEE used adequately strong crypto algorithms
   but in an incorrect manner.)

5) Several of the PCI auditors are fairly low on the security clue meter.

   Example: For PCI DSS v1.0, I asked (via InfoSec) what the PCI requirement
   3.6.4 was with respect to the encryption key rotation period? After about
   two weeks, I more or less received an "it depends" answer. So I rephrased
   my question as "Is it sufficient to only change keys every 1000 years?
   Or every 5 years?  Or every year? Or every month? Or every day? Or every
   hour? etc." Finally, after another two weeks, an answer came back that
   changing keys once a year was sufficient. Later, I found out from one
   of our InfoSec people who was working with the auditor that the auditor
   couldn't even understand WHY it mattered! Ugh! I thought it was pretty
   obvious...if it is done once a year, we probably can get by with manually
   changing crypto keys. OTOH, if they needed to be done hourly or even
   daily, we certainly would need some sort of automated process and most
   likely a fully functional secured key management system. Eventually,
   when DSS v1.1 came out, section 3.6.4 had these two qualifiers:

        - As deemed necessary and recommended by the associated application
          (for example, re-keying); preferably automatically
        - At least annually.

   Example: Our PCI auditor also did not seem to understand my questions about
   which cipher modes were acceptable. There are reasons to suspect that
   s/he did not even know what cipher modes are, as I had to explain
   the meanings acronyms ECB, CBC, IV, etc. The standard response was
   "we don't try to dictate implementation" and to brush off such questions

   Of course, I could be to harsh to rush to judgement on this. Our company
   has only dealt with two different PCI auditors since its involvement with
   PCI. So maybe we just got a few of the bad apples by (un)luck of the draw.

6) For app dev teams, PCI DSS mostly is a "checklist" mentality. (The
   exception is for the crypto-related requirements 3 and 4.) But I personally
   have seen no real evidence that anything is being done to address
   vulnerabilities such as those described in requirement 6.5. We've done
   a lot of education / training, but there's not much indication people
   are really doing anything about it. I think that the really sharp PCI
   auditors realized this was happening which was why 6.6 was added to
   DSS v1.1.

7) Web Application Firewalls (WAF) are alluded to in requirement 6.6 of
   PCI DSS v1.1 as an "application layer firewall":

        6.6 Ensure that all web-facing applications are protected
            against known attacks by applying either of the following
            - Having all custom application code reviewed for common
              vulnerabilities by an organization that specializes in
              application security
            - Installing an application layer firewall in front of
              web-facing applications.
        Note: This method is considered a best practice until June 30, 2008,
        after which it becomes a requirement.

   Notice that WAF is not required per se, but the alternative of inspecting
   all application code by an organization that specialized in application
   security is very seldom feasible. In fact, InfoSec first approached our
   team to do code inspections, but when we heard that there were more than
   1M LOC, we told them that this was impossible given our current team size.

   Code inspection *might* work for some small company who exclusively uses
   some custom code using CC info with something like a small, custom
   a shopping cart application, but it is not going to be economical for
   most medium to large companies.

   I also think that there is going to be significant push-back by
   companies where PCI audits are required. I wouldn't be surprised if that
   date gets pushed out to Jan, 2009. On the positive side at least, the
   PCI auditor who was interacting with our company said that we could
   configure an Apache proxy together with Ivan Ristic's "mod_security"
   and that would qualify as a legitimate WAF to satisfy section 6.6.
   So at least we can experiment on-the-cheap. (Of course YMMV at other
   companies; check with your assigned PCI auditor to see what WAF is
   right for you! ;-)

8) I personally have mixed feelings about WAF. Specifically, I have some
   anxiety about that app dev teams will start relying on the WAF to
   filter out the PCI auditors pen testing attempts rather than on
   correcting it within the application itself. I don't have too much of a
   problem of using a WAF to address DoS type attacks (6.5.9). (IMO, DoS
   attacks are often very difficult to handle within the application itself,
   especially when the app itself is using some J2EE container; addressing
   DoS at the app level almost always requires some significant amount
   of redesign which only complicates the app, making it more likely to
   be vulnerable to other vulnerabilities.) However, inevitably some
   clever 0-day is going to get past most WAFs, especially if they are
   solely signature based. (Those which are also anomaly-based *might* have a

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.

10) The multitude of NIST security standards--with which our company has
    to be compliant to get a contract an unnamed government project--
    are doing much more to push the overall security envelope than PCI DSS
    has ever done. For one, NIST has much clearer, as well as much
    more stringent, standards.

Anyhow, those are my thoughts. Hopefully, I will remember it was me that
posted them and not criticize them as coming from some idiot!

Gary: Thanks for allowing them to be posted while remaining anonymous.
(This is so much easier than posting from a new temporary email address
at Hushmail through several layers of Onion routers! :-)

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