Re: [fw-wiz] Botnets, IRC servers and firewalls?
From: Stephen P. Berry (spb_at_meshuggeneh.net)
To: Paul Robertson <email@example.com> Date: Fri, 06 Feb 2004 20:19:41 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Paul Robertson writes:
>The "worst" thing a home user can do
>is execute a virus or trojan- and the interface presents that in
>essentially the same way as non-active content- that's not really an
>end-user problem. Take the execute bit off the place where attachments
>normally get saved, and you'd remove a huge percentage of the problems.
>We at some point must come to the place where "breaking" 2% of
>functionality to save 98% of users is worth doing.
I think this is a specific instance of a more general infosec desiderata:
We need to get to the point where we can address problems -in aggregate-
rather than individually.
If we look at this as an endluser problem then our solution is going
to involve (at least in part) things like luser education and training.
Individually, this is not necessarily a large task, but:
-Educating one luser doesn't help educate other lusers
(This includes the proposition that me educating my lusers
doesn't help you educate your lusers)
-Educating -all- lusers is a large task
-Single lusers crapping out on their training can be as expensive
as multiple lusers crapping out
The point being that solutions to endluser problems (approached from
the endluser end) don't scale. The reason why this is particularly
problematic is that bad guy activities tend to scale extremely well.
I've said things to this effect before (possibly on this list), but
I think it bears reiteration: On any given day, lots of bad guys are
probably working on breaking the latest version of any given application
foo. Even if they aren't all -intentionally- coordinating their efforts,
their common goals (i.e., to compromise foo) creates -effective- cooperation.
Unfortunately, the same is not true of the efforts of the good guys. An
adequate discussion of why this is the case is probably beyond the scope
of this mailing list. Short version: even if all exploitable bugs
disappeared overnight this would not necessarily lead to an overall
improvement in the effective `security' of the internet. This, too, is
another contention that deserves careful discussion, but consider:
there were information security problems before anyone was pushing
data over networks---or even doing mechanical computation, for that matter.
This implies that removing all the security-related problems of
the -technology- of a system will not remove all the information security
problems of the system itself.
The punchline? Solutions to widespread security problems -must-
scale or they are not solutions at all.
0 Mod a nonzero number of lusers in any given population, for which
the problem is intractable.
1 Mod getting the educational infrastructure in place, incremental
gains derived from end lusers educating each other, u.s.w.
2 In other words: in the general case the magnitude of risk is not
linear with respect to the number of untrained lusers (although
it may be in specific cases). Compare the case of something like
virus propagation versus something like unintended information
disclosure (e.g., the shareholder report ends up on Kazaa).
3 And of course there are other sources of effective cooperation
among bad guys, mostly deriving from other common goals.
4 I.e., by having lots of good guys do code auditing together. Again,
there are other way good guys can cooperate; the point is that
they tend not to scale as well as does cooperation among the bad
5 If there was a magic ritual that could render a network device
or host absolutely `secure' (for some arbitrary definition of `secure')
but which required a trained shaman and a couple weeks of
preparation to conduct, it would have no perceptable effect on internet
security in aggregate.
Evidence: we -already- have rituals that will eliminate a huge
portion of known vulnerabilities which takes comparatively
little time (i.e., staying rev on patches) and expertise, and
virtually nobody (in aggregate) uses them.
This suggests that approaches to the problem of this form are
unlikely to be effective.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (OpenBSD)
-----END PGP SIGNATURE-----
firewall-wizards mailing list