Re: [SC-L] Software security video podcast

2007-10-29 Thread Wisseman, Stan [USA]
 If it isn't in the RFP then it's not a requirement, regardless of what the
customer implicitly expected.

DHS has a draft guide to raise the awareness of those in the acquisition
process about the need for software security and how to include the RFP
language. 

https://buildsecurityin.us-cert.gov/daisy/bsi/resources/dhs/908.html 

The comment period is still open if you have suggestions on how to improve
the guide.

Stan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of John Mason Jr
Sent: Saturday, October 27, 2007 1:12 PM
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.
___


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


Re: [SC-L] Software security video podcast

2007-10-29 Thread Shea, Brian A
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

Re: [SC-L] Software security video podcast

2007-10-27 Thread John Mason Jr
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.
___