[15602] in cryptography@c2.net mail archive
Re: Is finding security holes a good idea?
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Sun Jun 13 18:53:31 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: lists@notatla.org.uk
Cc: cryptography@metzdowd.com
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Jun 2004 15:15:17 -0700
In-Reply-To: <20040611211315.D0D1D8559@notatla.org.uk> (lists@notatla.org.uk's
message of "Fri, 11 Jun 2004 22:13:15 +0100 (BST)")
lists@notatla.org.uk writes:
> From: Eric Rescorla <ekr@rtfm.com>
>
>> Is finding security holes a good idea?
>
>>Paper: http://www.dtc.umn.edu/weis2004/rescorla.pdf
>>Slides: http://www.dtc.umn.edu/weis2004/weis-rescorla.pdf
>
> In section 1 there's a crucial phrase not properly followed up:
> "significant opportunity cost since these researchers
> could be doing other security work instead of finding
> vulnerabilities".
> What "other security work" is being used for comparison ?
> - finding and fixing non-program flaws (such as in configuration)
> I do a lot of this - and I'm not about to run out of it.
> I know that _finding_ the flaws is easy. Even finding
> many of them systematically is easy. Fixing them is
> often gets stuck on the problem of that's Fred's piece
> of work and he doesn't feel like doing it.
> - fixing long-known and neglected bugs (are there many ?)
> - accelerating patch uptake
> - technical work on tolerant architectures/languages etc
> - advocacy work on tolerant architectures/languages etc
> (Where's Howard Aitken when you need him ?)
> - forensics
> - other ?
All of the above? Probably my favorite would be finding mechanical
ways to make programs more secure--e.g. stuff like Stackguard,
etc. As you say, moving to non-C languages would be a really
good start!
> Footnote 1 mentions an indirect effect of vulnerability research.
> Another one would be programmer education - but reporting yet
> another bug of a common type seems to have low value. People
> do need to be aware that (their!) software can be faulty and in
> roughly what ways.
Good point.
> In 3.4 if proactive WHD is not worth the effort because the bugs
> get discovered anyway when they are widely exploited what does
> this say about finding vulnerabilities through their use in the
> wild ? Is this more costly but better aimed at the bugs that matter ?
> Are there cost-effective ways to do this reactive discovery ? What
> tools would simplify it ?
Excellent point. There's no real data on this topic but my
intuition would be that better IDS/anomaly detection would be
a useful tool here. Also, some kind of automated
forensic network recording so that when intrusions are
detected it's easy to backfigure what happened.
-Ekr
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
