Secure Coding mailing list archives

Re: informIT: Modern Malware


From: iarce <iarce () corest com>
Date: Fri, 25 Mar 2011 18:19:22 -0300

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
_______________________________________________


Current thread: