No, you do not _need_ a realtime scanner if you know what you're
doing.
This is true - but requires:
1) A well-defined perimeter
You can only on-demand scan if given the opportunity, i.e. the content
has to stand still in inactive form and in a form that is scannable,
before it is "opened".
Any number of coding defects can drill through that, and these often
apply even if the affected subsystem (e.g. IE) is present but not
used. Removing such subsystems helps, but may bring its own problems.
Most email apps hide incoming attachments within mailboxes in a form
that cannot be assumed scannable, and then will create the file and
jump into it in one action when you "open" the attachment from the
link to it within the email message.
2) A clued user base
You can design your system to remove these problems, i.e. plug holes
(note that Windows Update needs IE), choose an email application that
doesn't hide attachments, and so on.
But you still have to be clued enough to always electively scan
incoming material before use, every time. For plural values of "you"
(i.e. families, house mates, cow-orkers, etc.) this can quickly become
a minefield of recriminations etc.
For this reason I do advocate on-access scanning in new Windows PCs
that can pull the overhead, but that doesn't do away with the need for
an on-demand scanner. The needs are:
1) Multiple scanning engines
F-Secure bundles two or three (what's the third one?) engines into a
single resident scanner, but if you want to use multiple scanners,
it's best not to have more than one (or even none) running resident.
Non-resident scanners can be applied serially via Start /W as a way of
testing new suspicious stuff more exhaustively. This is perhaps an
esoteric need, pertinant to hi-risk systems (ADSL) or research.
2) Cleaning up active malware
So far, all discussion has been about catching malware before it runs,
based on the assumption that malware will never penetrate our
protective layers and go active.
Once active, a Windows-based av is a poor choice of cleaner, though
slightly less silly than on-line scanners. The potential exists for
active malware to out-maneuver informal scanning, with potentially
disasterous results; it's foolish to assume the malware coder will not
exploit such opportunities from goodness of heart.
So you need an av that runs completely independently, without running
any (potentially infected) code off the HD whatsoever. DOS-based
scanners can do that as long as they can read the file system, which
is where NTFS creates a crisis. What we now need are NTFS-native
scanners that can run from a PE-generated XP boot CDR, i.e.:
- do not need to be installed
- have their own methods of registry access
- do not need to write to the boot drive (which is a CDR)
- ideally, do not need writable HD workspace (RAM drive?)
- do not need to run any code off HD
- do not a pre-existing installed presence on the HD
- can read their sig data (and engine?) off a USB flash drive
That's the challenge we need av vendors to rise to - and ideally these
should work both with the "official" MS PE builder (which is
conspicuously NOT available to most of us) and 3rd-party PE builders.
---------- ----- ---- --- -- - - - -
A dog will give its life to save yours.
A cat will be annoyed by all the yelling and sirens.
