lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <404912DA.3040007@onryou.com>
From: lists2 at onryou.com (Cael Abal)
Subject: E-Mail viruses

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curt Purdy wrote:

>> Personally I'd dispute this solution's elegance, anything
>> which requires substantial user behaviour change (and doesn't
>> drastically improve the virus/worm situation across the board)
>> is an ugly kludge.
>
> I would say that completely eliminating all virus infected
> attachments, past/present/future without any further interaction by IT
> dramatically improve the virus/worm situation across the board.

The problem is, though, you're training your users and customers (likely
at significant expense) to use some bizarre munging method to satisfy
the whims of your particular mail gateway.

Although it will stem the flow of incoming automated worms/viruses on
your end, this will not help reduce virus/worm propagation anywhere else.

This, to me, is not what I would call dramatically improving the
virus/worm situation across the board.

Think about the implementation nightmare.  What will you do when someone
attempts to send an attachment to one of your users?  Will you fire off
an automated response, instructing them to use your .xyz solution?  How
will you prevent sending notifications to forged From: addresses?

Will you instead simply silently kill all attachments, passing the body
of the message -- that's ugly too, it requires the recipient to notify
the sender their attachment was blocked, describe your solution to them,
and hope the attachment gets resent.  Do you trust your users to
accurately describe file renaming to other users?  Are your users
comfortable with the variety of OSes still out there?  Are your users
smart enough to realize they shouldn't start renaming attachments they
send to other folks?

Also, keep in mind your users will still get hammered by all those
annoying e-mail virus/worm messages (sans executables), unless you also
continue to implement an anti-virus scanner.  Didn't you hope to be rid
of that?

Finally, what if you decide to change procedure in the future?
Everything you've taught your users is completely useless to them, all
that time and effort ends up being a complete writeoff, and you'll have
to *untrain* them all.

Your idea is interesting and certainly deserves further thought and
discussion, but it's no panacea.  Instead of implementing this
particular solution (with all its costs), I'd instead recommend Old
Faithful:

1) Continue following industry Best Practices.
2) Educate your users as best you can.

In my mind this is much, much better (for everyone) in the long run.

Sincerely,

Cael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFASRLaR2vQ2HfQHfsRAn2lAKCLVmeuD+RyFnccu88K8jWDXP0qHACfXlj1
ysYMFduEuVon2BUgdKhtwgk=
=/sDh
-----END PGP SIGNATURE-----


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ