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).
gem
=================
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
normal.
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
altogether.
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
methods:
- 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
prayer.)
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) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
