🚀 go-pugleaf

>From:    padgett%tccslr.dnet@mmc.com (A. Padgett Peterson)

>>... it should give different
>>"seeds" for each system.  I recall that discussion and that I felt
>>(and still feel!)  it's a good idea, but a tech support nightmare.

>Doesn't have to be, Enigma-Logic's product uses a different "seed" for
>each machine that is entered once by the user at installation time &
>is never encountered by either user or tech again.

>Also, about a year ago, we discussed a matrix method for a sinple checksum
>algorithm to be produced on the fly.

If the seed is entered by the user, then there might well be problems
of getting "pre-installed" copies within an organization that al share
the same seed.  Just as an example: one site license on FLU_SHOT+
pre-installed it on about 300 machines.  Just by chance the installer
was running DOS 4.01 on his machine, everybody else was running DOS
3.3.  Obviously, the checksums on the system files and COMMAND.COM
were different and I got umpteen tech support calls on the "problem".
Now, this was a major problem because of installation done beforehand.
Imagine my problem if each checksum was altered slightly with a
different seed?  Unless they tell me the seed (or I play games to
derive the seed), I have a major tech support problem.

And if they have the seed stored on the system anywhere -- sorta
required in order for it to work! -- then the bad guy can find it just
as easily as my own code can.  It buys the end user nothing, in my
opinion, but causes a major support headache.

Hey!  Didn't I say that on the other side of the album or last year?

>Anti-Viral software should now be in its third generation:
>1) Initial design
>2) Take care of exceptions & annoyances
>3) Make it "user-friendly"

Actually, I think each of those phases are sorta endless loops. Lots of
changes in the next cut of my code due to enduser feedback, responding
to competitors, etc.

>To me "good enough" is a product that will detect any change to a system
>or authenticated file that is unauthorized without flagging. At the same time
>actions that are authorized for a product will be passed without challenge.
>I haven't seen any yet though some come close.

If you want RACF on a PC, you'll have to change operating system, I
think.  It looks like you're speaking of authenticity and access
control -- these must be considered important *parts* of an anti-viral
package.  But not the whole thing.

>I will make a stab at some targets:

Forgive me if I "stab" you back?  <g>

>  1) Simple to install - should only give user opeions that are based on
>     the machine in question.

Pre-installed products will have a problem as mentioned above. Many sites
don't want to install each package individually on individual machines.

>  2) Should recognize incompatable products

Once advised, sure.  Until then...how does one know?  This will always
be a one-version-off problem.

>  3) Should be robust enough not to require program updates unless new
>     features are added. Simple data files updates of new signature strings
>     should be all that is necessary

See the compatability problem you mention above.  A bug has to be fixed
and not all compatability problems can be determined at release time. As for
virus scanners:  my first product in the arena used a brute force method
of scanning, back when I had about 50 strings.  I have about 500 now. The
same technique would have you waiting ten times longer.  One method was quite
appropriate a year ago, a different one now.  Once DOS 2.x ruled the earth,
but lots of dinosaurs get extinct.  Upgrades are required in many cases, says
this mammal.

>  4) Each machine should have a different algorithm if only a unique seed.

See above.

>  5) Must make provision for routine mainenance (defrag, etc.) while
>     maintaining functionality

Difficult to maintain system integrity there while doing "dangerous" things,
though.  But agreed.

>  6) Must be easy to remove for troubleshooting

Hey, *my* code never needs to be removed! <grin>

>  7) Must recognize ANY change and be smart enough not to bombard the user
>     with notices when authorized.

Should be user selectable, allowing a sys admin (even on a PC!) to determine
just how "loud" an alert should be.

>Unfortunately, I know of many mainframe packages that do not meet these
>criteria.

Yeah, RACF.  Remember: this is not your father's Oldsmobile...

Ross