Excellent response, Ivan. Malware is a business, not a programming mistake, which Gary's article mentions then sidesteps.
This is the "Secure Coding" list so I can understand the myopia. As for "Long Term Solutions and Wishful Thinking" in the article: It is clear that current solutions are not working, if you step back and look at the malware landscape. Now, some steps we have taken have had significant positive impact, It's been a while since network-replicating worms ripped through every windows box on the Internet. However, the steps taken so far to protect user-land, the browser, and web applications have not proven effective yet on a broad scale....SDLCify sensationalist rhetoric aside. And why is that? Are we missing DEP and SEHOP and such for the web? Or is the web, the browser, and userland malware just where the easy money is, so the attackers focus there? --- Arian Evans Software Security Realism On Fri, Mar 25, 2011 at 2:19 PM, iarce <ia...@corest.com> wrote: > On 3/22/11 12:41 PM, Gary McGraw wrote: >> hi sc-l, >> >> The tie between malware (think zeus and stuxnet) and broken software >> of the sort we work hard on fixing is difficult for some parts of the >> market to fathom. I think it's simple: software riddled with bugs >> and flaws leads directly to the malware problem. > > Non sequitur > > C'mon Gary, I understand the purpose of making such a simplifying > statement on the secure coding mailing list but its logic is untainable. > > Bugs and flaws do not *directly* lead to malware, not even if you > defined bugs and flaws in a way that would nearly make your statement a > tautology (ie. "a bug|flaw is something that proves the existence of > malware possible") > > What leads directly to the malware problem are the individuals and > organizations that develop and deploy malicious software. The fact that > they usually use undocumented APIs (what you call "bugs and flaws") for > their purpose does not make those APIs the cause of the malware. > > You could statically-analyze and SDLCfy all software till kingdom come > and that will still not prevent large consumer electronics or firmware > vendors from developing and shipping their own breed of malware with > their products. > > Advocating development of secure software by "Building Security In" is a > commendable position but in my opinion it is only a necessary > component of a long term solution. I think that a long term solution > also requires us to stop dancing around the issue of abusive EULAs, the > lack of vendor liability and to factor in the adversary's motivations > and incentives. > > I realize the above remark may lead to a discussion that is off topic > for this mailing list so I'll turn to the last paragraph of your article: > >> Fortunately, many leading firms, including Adobe and Microsoft, are >> taking a determined approach to software security and real results >> are coming in the form of more secure software and less vulnerability >> to malicious code. > > How do you measure software security? You say "real results", "more > secure" and "less vulnerable" but this may just be a highly subjective > assessment about the success of the approach of some specific vendors. > > One could also say that despise some vendors' "determined approach" to > software security a decade and hundreth-million dollars into the process > they've still not made a dent to the "malware problem" so how does that > make their current software more secure|less vulnerable in practical terms? > > -ivan > -- > Ivan Arce > CTO - Core Security Technologies > _______________________________________________ > 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. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > _______________________________________________ > _______________________________________________ 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. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
