RE: This mornings Security Wire Perspectives - Ira's proof of concept code article.

[robert () dyadsecurity com]

To summarize the first article titled "New Year's resolution: Select
alternative hardware and software Monoculture continues to pose its
share of security threats.":

"We don't know how to secure any one vendor's products, so we believe
that selecting several vendors is key to not having everything owned by
the same worm".  Plenty of Spafford, Gere, and Lindstrom, CISSP quotes
to go around.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Article "PATCH TUESDAY LINKED TO EXPLOIT TIME FRAME":

"Look, hackers are too stupid to find bugs on their own.  They have to
wait for Microsoft to release patches before they know what to
compromise".

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Article "VeriSign report shows Microsoft's patch releases coincide with
new exploits with such regularity they can almost be plotted on a
calendar.":

"You don't have to worry about unscheduled attacks anymore.  Just look
for your vendors release date, and brace for an attack 1-day to 1-week
later".  Button down the hatches, storms a brewin!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

And now the main event. This article is not the first to state the
concept, but is definitely one of the more clearly articulated versions.

Article: "SOME CONCEPTS DON'T NEED PROVING; Proofs of concept help no
one but attackers."

> By Ira Winkler, CISSP
>
> So-called proofs of concept have been around for awhile. While it is
> otherwise completely legitimate to search for security flaws in
> products, putting together a proof of concept, then distributing and
> publicizing it is just plain wrong. Frankly, these people are
> enablers to criminals and vandals around the world.

So are gun makers, and the Sharpie pen company, spray paint
manufacturers, baseball bat makers, etc. etc.  The tools have dual
purposes.  Security Researchers are not responsible for the criminal
actions of others.

> There is a big difference between responsibly finding and reporting
> vulnerabilities, and going the extra step to put out proof of concept
> code. Finding vulnerabilities and getting them fixed is clearly
> important. When done responsibly, discoverers tend to be acknowledged
> in the associated vendor alerts and, if significant, tech
> publications as well.

"If I do all of the security Quality Assurance work for the vendor for
free, I should be thrilled that they get to dictate when that
information can be made public.  If I'm a good little security
researcher and work on their schedule, they might just be nice enough to
give me credit in their version of the advisory".

> However, more attention is generated by distributing actual attacks
> to compromise systems. When someone releases a new attack, especially
> within the first three months of an available patch, it isn't due
> solely to wanting exposure, or to be perceived as being elite.

I think proof of concept code and advisories should come out before a
patch is available.  Who is the security research community serving ..
the end user or the vendor? As an information owner, I would ideally
know my risks as soon as possible. Remember folks, the problem is still
there whether I know about it yet or not.  Just because a "good guy" was
willing to share the security problem they found doesn't mean that it
wasn't already found by a "bad guy".  I am far more concerned about
directed malice than I am worms.

While a a worm's impact can account for a large amount of total "loss",
the overall impact to any individual organization is far less than that
of a directed malicious attack.  A worm is annoying.  A directed attack
can be devastating.  We need to not punish security researchers for the
work they are doing for us.

I'm reminded of a childhood experience.  When I was 6 my parents bought
me a bike.  I had a chain to lock up my bike when I was away from home. 
One day my little sister was playing with the lock and broke it.  I was
angry with her for finding this vulnerability in my security system
until my father pointed out that if my little sister could easily break
my lock, then so could a person who wanted to steal my bike.  Sometimes
it's better to know your risks so you don't make uninformed decisions
based on a perception of security.

> Anyone who claims that security professionals need access to the
> attacks so that they can test their clients for susceptibility to the
> exploit doesn't understand the true job of a security professional.
> Security professionals need to test for the presence of the
> underlying vulnerability, but this can be done with a scanning tool
> or examining the software version and settings -- it doesn't require
> the exploit.

People who follow this advice clearly have no concept of what their
automated scanners are doing or even how they are developed.

> Some perform penetration testing and may need to legitimately use the
> attack, but I would contend that these people should be capable of
> writing their own attack after reviewing the documentation, use
> commercially available tools, or just use other exploits to
> accomplish their mission.

Ira, what do you mean by this statement?  It's not a matter of being
able to write an exploit, it's a matter of being able to Verify findings
versus Identify findings in a reasonable time frame.  It's one thing to
say "based on version information, we believe this application may be
vulnerable" and quite another to say "This application has been verified
to be vulnerable".  Oh, and how exactly would "other exploits" be of any
use?  I'm not sure if your original words got edited, but that last
paragraph illustrates a fundamental misunderstanding of thorough
security testing.

> The benefit provided by one legitimate use does not overcome the large
> scale malicious use of an attack by hackers around the world. If the
> attack is incorporated into worms, which happened with the Blaster
> worm, the damage goes into the billions of dollars.

I'd like to throw the "monoculture" crap back at you on this one.  If
the attack payload is easily identifiable and reused, then the gateway
devices should be able to mitigate the risk.  I've never been a fan of
IDS or IPS systems as I don't believe they are properly labeled.  They
do not detect or prevent intrusions.  However they are getting
particularly good at detecting and in some cases preventing (at the
gateways) worms.  This is where your Worm Prevention System (WPS/WDS)
can help you... that is of course until a vulnerability is distributed
to attack them :).

Robert

-- 
Robert E. Lee
CTO, Dyad Security, Inc.
W - http://www.dyadsecurity.com
E - robert () dyadsecurity com
M - (949) 394-2033
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave