Re: [SC-L] PCI: Boon or bust for software security?
Worse than that, I think that until businesses universally understand the value of secure coding practices, they will resist the up-front cost to take on such a transformational program. SOX vs PCI would make for a good case study. SOX is very high level and generic, which led to much confusion and wasted money initially. Some orgs were able to leverage it for the first year or two to drive improved security practices, but it seems that, for the most part, this leverage is gone. PCI, on the other hand, is for the most part quite specific (despite some ambiguity due to poor writing quality). It has primarily resulted in a checklist-oriented approach to "compliance" and has not seemingly led to transformational change, but rather many spot fixes. While it is still usable to leverage organizations, and it has moved the needle a little bit in terms of baseline security practices, overall I'd put it's effect on par with SOX. Thus, you have two sets of regulations that used very different approaches, but with very similar results: relative ineffectiveness. For me, this raises the question, Can regulation be used to stimulate the business to undertake transformational change to adopt and integrate holistic, pervasive security practices? The problem, I think, is that PCI is too easily relegated by the business to IT. This can be the case because PCI is technically specific. SOX, on the other hand, was not specific enough, and so eventually became almost dismissable by the business, eventually with minimal involvement from IT (perhaps a gross oversimplification). The key, then, seems to be in trying to construct requirements that will stick with the business instead of being easily delegated. Perhaps something risk-oriented would have the desired effect... fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ "In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." Edward P. Tryon On Tue, March 4, 2008 09:02, Andy Murren wrote: > Overall I concur with Bruce on this. PCI has too broad of a > constituent base to cover to be truly effective. Some fixes were > added after the TJX breach, but look at how much TJX paid versus how > much the laid aside to pay. I am betting that the TJX lawyers > produced documents showing that they were PCI compliant, and that Visa > had accepted the annual findings. In the end TJX was able to claim > that they were not negligent because they were PCI compliant. While > PCI 1.1 points to OWASP for in house developed web applications, where > are the standards for 'PCI Approved' vendor development? How secure > is the development process at the middleware vendor that is part of > that web app, how good are the standards those organizations use and > are held to? > > I think until there is an industry wide generally accepts, and pushed, > standard for integrating secure development into the SDLC we will see > band aid approaches like the updated PCI. > > Andy > ___ > 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. > ___ > ___ 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. ___
Re: [SC-L] PCI: Boon or bust for software security?
Overall I concur with Bruce on this. PCI has too broad of a constituent base to cover to be truly effective. Some fixes were added after the TJX breach, but look at how much TJX paid versus how much the laid aside to pay. I am betting that the TJX lawyers produced documents showing that they were PCI compliant, and that Visa had accepted the annual findings. In the end TJX was able to claim that they were not negligent because they were PCI compliant. While PCI 1.1 points to OWASP for in house developed web applications, where are the standards for 'PCI Approved' vendor development? How secure is the development process at the middleware vendor that is part of that web app, how good are the standards those organizations use and are held to? I think until there is an industry wide generally accepts, and pushed, standard for integrating secure development into the SDLC we will see band aid approaches like the updated PCI. Andy ___ 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. ___
Re: [SC-L] PCI: Boon or bust for software security?
On Mon, 3 Mar 2008, Kenneth Van Wyk wrote: > So here's a question to ponder. Now that PCI DSS 1.1 is out there (save a > couple June 2008 deadlines still looming), has it been good or bad for > software security as a whole? It's a wash. And that only because PCI has mild good effects, to counteract "The Business" using it as a bludgeon to get some other concessions they want from various IT departments. Let's face it, current management and business practice is to regard all programmers as plug-compatible, and to put all their emphasis on the unattainable Holy Grail of "repeatable processes" (http://www.idiom.com/~zilla/Work/Softestim/softestim.html and http://www.idiom.com/~zilla/Work/kcsest.pdf). Maybe they need "repeatable processes" if they outsource to guys who can just barely spell "Java", but that's really another rant. In any case, the same management that puts all its faith in the prima facie nonsense of "repeatable processes" just did some checklist-style PCI remediation, implementing it without wisdom or imagination. Management, thy name is "CYA". They hired the minimum bid network scanners, who really didn't do much, but did turn in a spectacularly-well-formatted "Word" doc with lots of buzzwords in it. "The Business" put whatever effort is left over after plotting Corporate Domination (none) into understanding the PCI remediation checklist, and now believes that security is well taken care of, now and forever. PCI compliance is like boycotting gas stations for a day: that day's sales look pitiful, bu over the course of a week, it will all even out, since "compliance" gives "The Business" a false sense of security. ___ 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. ___
[SC-L] PCI: Boon or bust for software security?
Greetings SC-L, So here's a question to ponder. Now that PCI DSS 1.1 is out there (save a couple June 2008 deadlines still looming), has it been good or bad for software security as a whole? It does require secure development processes (as prescribed by OWASP). It does require sensitive cardholder data to be encrypted at rest and in transit. Has it improved the overall state of affairs, worsened it, or have things pretty much remained the same. Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ 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. ___
