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
