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