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