I've just caught up with 6 weeks of backlogged messages in this group, and wanted to offer some thoughts on topics that have been hashed out, but haven't seen these points made.
(1) SOX is a waste, as several people said, because it's just a way to give auditors more ways to demand irrelevant things on checklists - but not to pay attention to actual security. I've had customers demand that I support AES because their auditors says "SOX requires it", while meanwhile having unchanged default passwords. Another customer demanded that we support 6144 bit RSA keys (no, that's not a typo) because "SOX requires it". Neither customer asked anything about software security - just about the check boxes on the auditor's list. Ask people to go *read* SOX, and they'll be surprised what it actually says (or more accurately, doesn't say). (2) PCI, by contrast, is dramatically better, because it's got actual things you can measure, and some of them have some relevance to software security. However, it's having an effect that I think was unintended by the folks who wrote it (or at least the ones I met at a recent conference) - merchants are pushing the requirements down to all of their suppliers, regardless of whether they're applicable. So, for example, we have to certify that we treat all credit card information in the required way - even though we don't ever get credit card numbers. [This is a requirement that might make sense for a merchant to push to an outsourced processor, but not to a software supplier. Can you certify that Windows or Linux handles credit card numbers correctly?] (3) Vendors do what their customers ask for. If my customers ask for better security, we'll put our engineering resources into improving security - just as Microsoft has done. If our customers ask for more whizbang cool GUIs, that's where we'll put our effort. We *know* that the products aren't as secure as they could be (and perhaps should be) - but as a business, we respond to our customers. I hear what customers are asking for, and when it comes to enterprise software, the top three priorities are features, more features, and yet more features. And we actually have a metric for whether we're investing in the right places: how often do we lose deals because of missing features (security or otherwise) vs. security assurance (i.e., software security). [Of course there are other reasons for losing deals too, like price, long term vision, company reputation, etc., but I'm focusing on the software ones.] When the balance of where we lose deals changes, we change our investments. As always, my opinions, which don't necessarily represent the views of my employer, or Alberto Gonzales or anyone else tapping my phone. --Jeremy Jeremy Epstein Senior Director, Product Security & Performance P 703.460.5852 | C 703.989.8907 | F 703.460.2599 | W 202.456.1111 AIM jeremyepstein | Skype jjepstein www.webMethods.com _______________________________________________ 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. _______________________________________________