Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!iggy.GW.Vitalink.COM!widener!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw From: microsoft!c-rossgr@uunet.uu.net Newsgroups: comp.virus Subject: re: FSP and sales figures (was: Into the 1990s) Message-ID: <0011.9105311330.AA00359@ubu.cert.sei.cmu.edu> Date: 30 May 91 22:23:56 GMT Sender: Virus Discussion List Lines: 105 Approved: krvw@sei.cmu.edu >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? > 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! > 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