[Dailydave] The monetization of information insecurity

[Brad Spengler]

Hi Dave,

How to avoid repeating the mistake of AV: this is a difficult problem.
I don't have much experience in defense, so if I were to ponder a
solution to this problem, I would look toward the paradigm-shifters in
the infosec industry.  Being an avid reader of Wired and other such
online magazines, my immediate thought was Google's Project Zero.

We've learned from the failure of AV that ex post facto detection
and remediation of single pieces of malware is a losing battle given
the ever increasing number of malware samples in the wild.  It seems
like for every malware detected, two more take its place.

That's why I really admire Project Zero's approach -- it took these
lessons to heart, producing a real game-changer.  They're focused
on ex post facto detection and remediation of single bugs, a highly
effective approach given the ever increasing number of bugs in the
software today.

What's really unique about Project Zero's approach though, is that
unlike AV, Project Zero pairs its work with copious quantities of
self-advertisement -- because when one's goal is making the world
a safer place, one needs to make sure everyone knows it.

We need to change course.  Let's resolve to put the monetary focus
of the industry to where it really belongs: bug bounties.  Let's
ensure fuzzers are employed for the next decade while we reap the
bountiful rewards of their endless trickle of bugs.  If we make
sure this strategy dominates, we can be sure we don't hamstring
the industry by focusing efforts on what produces real improvement.
We know bug bounties work because their associated monetary offerings
continue to increase -- the market has spoken.

If we take our cues from such visionaries, I think we can avoid the
parasitic growth of the infosec industry and break the chain of
strategies that haven't worked for their entire reign.

Respectfully submitted for your consideration,
-Brad

On Mon, Sep 08, 2014 at 10:07:02AM -0400, dave aitel wrote:
> So I'm heading to a conference shortly and I was going to promote
> them in this email but they're apparently not a public conference.
> I'm on a panel called "Identification of Emerging and Evolving
> Threats" with some non-US Government people who seem pretty nice.
> 
> Anyways, now that I've guaranteed myself an exciting visit from
> security services, I wanted to point out the one question everyone
> should be asking when they go to any conference and a new technology
> of any kind is proposed as any kind of forward movement for defense.
> And that is this: "How can we avoid making the mistake of
> Anti-Virus" ever again?
> 
> Because much like the Internet has been hamstrung at birth by the
> parasitic growth of the advertising industry, the information
> security community has been devastated for almost its entire
> existence by the dominance of anti-virus companies and products
> which demonstrably haven't worked for almost their entire reign, and
> in theory never could have scaled. They are broken by design. And
> because they sucked all the money and research and people from the
> defensive community, no actual defenses were ever created for IT
> that had a hope of working.
> 
> So the only question any team of government executives working on
> defense needs to be thinking about is "How is this different from
> Anti-Virus in the long term? How can we avoid making that mistake
> ever again?" Because until you know how that mistake was made, and
> can avoid it for the next generation, "Emerging and Evolving"
> threats will always be beyond your power to stop.
> 
> -dave
> 
> 
> 
> 
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140908/15897250/attachment.sig>