IMO (IANAL) this is a position that is increasingly untenable as we move forward, especially in the consumer markets. As a customer I do, in fact, expect software to operate "correctly" (per features and functions promised / contracted) but also "securely" in that is doesn't contain bugs or insecure data handling that could compromise the app, data, or my systems. I agree that a corporation should be wary of the contract / RFP language and commitments, but I can't and don't expect consumers to. Frankly even corporations should be able to expect "reasonable performance and quality" from their software vendors without being expected to explicitly ask.
Apparently the UK House of Lords sees the issue as described in their Fifth Report here: http://www.publications.parliament.uk/pa/ld200607/ldselect/ldsctech/165/ 16502.htm And Commented on by a participant here: http://www.lightbluetouchpaper.org/2007/08/10/house-of-lords-inquiry-per sonal-internet-security/ "The third area, and this is where the committee has been most far-sighted, and therefore in the short term this may well be their most controversial recommendation, is that they wish to see a software liability regime, viz: that software companies should become responsible for their security failures." -Richard Clayton, from the blog linked above. If a company produces a product that contain preventable safety issues, even ones not explicitly requested, would a you let them stay above liability? If car company built a car that exploded when it was hit would you allow them to avoid liability because no one asked for that to NOT happen? If a drug company produced a drug that caused serious health issues or death when using it, would they be exempt from liability because you fixed their heart as requested, but no one asked for the liver to stay healthy in the process? Most wouldn't and they would cite the reasonable person concept (see: http://en.wikipedia.org/wiki/Reasonable_person ) as justification for not including the droves of issues that COULD be listed explicitly but are implied due to a "reasonable person" expecting them to be in place. Again IMO in a Kano model (http://en.wikipedia.org/wiki/Kano_model ), software security has moved from Indifference (customer doesn't care if it is present or not), to currently being a Performance feature (more is better, but less is acceptable) as part of software today. It is moving ever closer to Basic (this feature is a Must Have for a product in the field) and will likely be making that transition in the next 4-8 years. Disclaimer: personal views here, not representative of the company I work for etc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Mason Jr Sent: Saturday, October 27, 2007 10:12 AM To: Secure Coding Subject: Re: [SC-L] Software security video podcast J.M. Seitz wrote: >> Software security can be tricky when it comes to requirements, >> mostly because customers and consumers don't explicitly demand > security, rather they impicitly expect it. > > Wait a second here, don't customers also implicitly expect that the > software is going to run? I mean I haven't seen a requirements document > _ever_ that has said "The software must start.". They just implicitly > expect that its going to do that. > > Doesn't seem like a big surprise that most customers will _expect_ that > "Hey, I don't want this software pwnable after you're done with it." > > Not sure where the trickiness you are referring to comes from? > > JS > > ps. Didn't AW publish your book(s)? :) I would be real surprised > [turning on Tom Ptaceks snarky bit] if there's any mention of them. If it isn't in the RFP then it's not a requirement, regardless of what the customer implicitly expected. The customers don't see a value to the added cost(s) of a secure system, unless they have a business requirement to adhere to such as PCI compliance, or HIPAA. If a requirement is important to the business it must be explicit, but this means the folks writing the RFP must have the understanding to make sure it is in the RFP, otherwise the you could end up with the better system (more secure) not being selected because it costs more. Now the company who bids the project in a more secure fashion will also get a tangible benefit from code review and other processes that make for a secure system, but they won't invest in this avenue until the RFP requires it. John _______________________________________________ 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. _______________________________________________