Re: [SC-L] Re: Comparing Scanning Tools (false positives)
Gary McGraw wrote: Hi all (especially david), The story you repeated about ITS4 finding a vulnerability that can't happen is wrong. The tool FIST (a fault injection tool for security) which we decribed in an Oakland paper from 1998 was what you were thinking of. (FIST was also produced at cigital...the paper was by anup ghosh, tom o'connor, and myself.). FIST found a vulnerbility that we could not figure out how to exploit. Some 6 months later, a security researcher figured out how and published the sploit. Ah! That explains why I couldn't find it. Right basic story, and right company... but wrong tool. Thanks for the correction. I think it's a very good cautionary tale, and not everyone's heard it. Could you post a little more information about that here, with citations (URLs where possible)? I believe a preprint of the FIST paper you mean is here, correct?: http://www.cigital.com/papers/download/ieees_p98_2col.pdf --- David A. Wheeler ___ 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
Re: [SC-L] Re: Comparing Scanning Tools (false positives)
Crispin Cowan wrote: I would like to introduce you to my new kick-ass scanning tool. You run it over your source code, and it only produces a single false-positive for you to check out. That false positive just happens to be the complete source code listing for your entire program :) If you can guarantee it is a false positive, this is a very useful tool indeed :-) Indeed. Unfortunately, there seems to be a distinct shortage of software that will trigger the false positive :-) :-). --- David A. Wheeler ___ 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
RE: [SC-L] RE: Comparing Scanning Tools
Title: Re: [SC-L] RE: Comparing Scanning Tools I think I should have been more specific in my first post. I should have phrased it as I have yet to find a large enterprise whose primary business isn't software or technology that has made a significant investment in such tools. Likewise, a lot of large enteprrises are shifting away from building inhouse to either outsourcing and/or buying which means that secure coding practices should also be enforced via procurement agreements. Has anyone here ran across contract clauses that assist in this regard? -Original Message-From: Gunnar Peterson [mailto:[EMAIL PROTECTED]Sent: Friday, June 09, 2006 8:48 AMTo: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)Subject: Re: [SC-L] RE: Comparing Scanning ToolsRight, because their customers (are starting to) demand more secure code from their technology. In the enterprise space the financial, insurance, healthcare companies who routinely lose their customers data and provide their customers with vulnerability-laden apps have not yet seen the same amount of customer demand for this, but 84 million public lost records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to change.-gpOn 6/9/06 1:45 AM, "Brian Chess" [EMAIL PROTECTED] wrote: McGovern, James F wrote: I have yet to find a large enterprise that has made a significant investment in such tools. Ill give you pointers to two. Theyre two of the three largest software companies in the world.http://news.com.com/2100-1002_3-5220488.htmlhttp://news.zdnet.com/2100-3513_22-6002747.htmlBrian ___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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
RE: [SC-L] RE: Comparing Scanning Tools
Title: Re: [SC-L] RE: Comparing Scanning Tools At the RSA Conference in February, I went to a reception hosted by a group called "Secure Software Forum"(not to be confused with the company Secure Software Inc, which offers a product competitive to Fortify). They had a panel session where representatives from a couple of companies not in the software/technology business claimed that they're making contractual requirements in this area (i.e., that vendors are required to assert as part of the contract what measures they use to assure their code). So I guess there's proof by construction that companies other than Microsoft Oracle care. Having said that, it's completely at odds compared to what I see working for an ISV of a non-security product. That is, I almost never have prospects/customers ask me what we do to assure our software. If it happened more often, I'd be able to get more budget to do the analysis that I think all vendors should do:-( --Jeremy P.S. Since Brian provided a link to a press release about Oracle using Fortify, I'll offer a link about a financial services company using Secure Software: http://www.securesoftware.com/news/releases/20050725.html From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT)Sent: Friday, June 09, 2006 12:10 PMTo: Secure Mailing ListSubject: RE: [SC-L] RE: Comparing Scanning Tools I think I should have been more specific in my first post. I should have phrased it as I have yet to find a large enterprise whose primary business isn't software or technology that has made a significant investment in such tools. Likewise, a lot of large enteprrises are shifting away from building inhouse to either outsourcing and/or buying which means that secure coding practices should also be enforced via procurement agreements. Has anyone here ran across contract clauses that assist in this regard? -Original Message-From: Gunnar Peterson [mailto:[EMAIL PROTECTED]Sent: Friday, June 09, 2006 8:48 AMTo: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)Subject: Re: [SC-L] RE: Comparing Scanning ToolsRight, because their customers (are starting to) demand more secure code from their technology. In the enterprise space the financial, insurance, healthcare companies who routinely lose their customers data and provide their customers with vulnerability-laden apps have not yet seen the same amount of customer demand for this, but 84 million public lost records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to change.-gpOn 6/9/06 1:45 AM, "Brian Chess" [EMAIL PROTECTED] wrote: McGovern, James F wrote: I have yet to find a large enterprise that has made a significant investment in such tools. Ill give you pointers to two. Theyre two of the three largest software companies in the world.http://news.com.com/2100-1002_3-5220488.htmlhttp://news.zdnet.com/2100-3513_22-6002747.htmlBrian ___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php*This communication, including attachments, isfor the exclusive use of addressee and may contain proprietary,confidential and/or privileged information. If you are not the intendedrecipient, any use, copying, disclosure, dissemination or distribution isstrictly prohibited. If you are not the intended recipient, please notifythe sender immediately by return e-mail, delete this communication anddestroy all copies.* ___ 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
RE: [SC-L] RE: Comparing Scanning Tools
At 2:32 PM -0400 6/9/06, Jeremy Epstein wrote: Having said that, it's completely at odds compared to what I see working for an ISV of a non-security product. That is, I almost never have prospects/customers ask me what we do to assure our software. I don't even get those questions for our security product ! -- Larry Kilgallen LJK Software ___ 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
