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. _______________________________________________