home *** CD-ROM | disk | FTP | other *** search
/ Compu-Fix / Compu-Fix.iso / pubnews / vir04002.txt < prev    next >
Text File  |  1993-03-01  |  27KB  |  630 lines

  1.  
  2.  
  3.           VIRUS-L Digest   Wednesday,  2 Jan 1991    Volume 4 : Issue 2
  4.  ******************************************************************************
  5.  
  6.  
  7.  
  8. Today's Topics:
  9.  
  10. VIRUS-L administrivia
  11. Various Comments
  12. Re: Job Market (PC)
  13. Antiviral evaluation guidelines
  14. FPROT review (PC)
  15.  
  16. VIRUS-L is a moderated, digested mail forum for discussing computer
  17. virus issues; comp.virus is a non-digested Usenet counterpart.
  18. Discussions are not limited to any one hardware/software platform -
  19. diversity is welcomed.  Contributions should be relevant, concise,
  20. polite, etc.  Please sign submissions with your real name.  Send
  21. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  22. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  23. anti-virus, documentation, and back-issue archives is distributed
  24. periodically on the list.  Administrative mail (comments, suggestions,
  25. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  26.  
  27.    Ken van Wyk
  28.  
  29. ---------------------------------------------------------------------------
  30.  
  31. Date:    Wed, 02 Jan 91 08:57:35 -0500
  32. From:    Kenneth R. van Wyk <krvw@cert.sei.cmu.edu>
  33. Subject: VIRUS-L administrivia
  34.  
  35. Happy New Year everyone!  In case you haven't noticed already, we're
  36. now up to VIRUS-L volume number 4.  I've updated the archives on
  37. cert.sei.cmu.edu to reflect this.  The pub/virus-l/archives/1990
  38. directory now contains the entire volume 3 set, and there's a new
  39. directory for 1991 (volume 4).
  40.  
  41. I hope everyone had a pleasant holiday season.  I kept myself busy
  42. downstairs in my brewery (read: basement).  :-P  Any other homebrewers
  43. out there?
  44.  
  45. Cheers,
  46.  
  47. Ken
  48.  
  49. ------------------------------
  50.  
  51. Date:    23 December, 1990
  52. From:    Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
  53. Subject: Various Comments
  54.  
  55. Note: Thanks to flakey routing have missed posts 194-203. Apolgise
  56.       for not responding to comments in the interim. Happy Christmas.
  57.  
  58. >From:    jmolini@nasamail.nasa.gov (James E. Molini)
  59.  
  60. >From what I have seen over the years, anyone who ever loaded a key
  61. >into a piece of crypto gear has called themselves a Computer Security
  62. >Expert at one time or another...
  63. >So what does it take to be competitive in this field?  It takes at
  64. >least a bachelor's degree in Computer Science and a strong background
  65. >generally in security.
  66.  
  67. Am reminded of the quip attributed to Mozart about what it took to
  68. write an opera. When given an answer that would require the better
  69. part of thiry years, the inquirer said "But Herr Mozart, you wrote
  70. your first opera at sixteen." to which the composer replied, "Ah yes,
  71. but I did not have to ask."
  72.  
  73. Having cut many a KG-13/KY-26 card & possessing an ME degree (from
  74. GMI), this would place me in the first category, however, I did not
  75. ask anyone (besides, who could you ask in 1966 ?) & feel there is a
  76. point that needs to be made. At present, there are really two
  77. different computer security fields: the first which Mr. Molini appears
  78. to address is the traditional multi-user mainframe which has access
  79. control as its primary requirement and provides insulation between
  80. users and applications. In most cases the user has neither concern nor
  81. care where WordPerfect resides, the system managers take care of this.
  82. PCs are another story altogether.
  83.  
  84. Here there is no access control or partitioning other than a pseudo
  85. one.  The user and any application called can do anything it/he/she
  86. wants. There is no RACF or CA/Top Secret and no user/kernel
  87. separation. Since mainframe manufacturers make the innards of the O/S
  88. a secret from the general public, often just a good knowlege of the
  89. package in use is all that is necessary.  (Though RACF is the only
  90. security system I know of that will tell you where its holes are and
  91. not trigger a violation for asking.)
  92.  
  93. To de-virus a PC (not just using CLEAN), the technician must
  94. understand the iapx80X86 machine code at hex and assembly language,
  95. operation of the BIOS, and the steps of loading a PC. Obviously the
  96. writers of JOSHI had some coaching on this as the first level mistakes
  97. are not made. These are entirely different skills than are generally
  98. needed on a mainframe. I know of few places outside of defense
  99. contractors where computer architecturists are still being utilized
  100. (and to anyone who has ever been stuck with making a
  101. Mil-Std-1750A/Jovial system work, my condolences but you probably have
  102. the right skills.)
  103.  
  104. The biggest difference even with a unix environment is that in the PC
  105. (and the MAC) environment things happen at such a low level that
  106. little information is available (other than in fifty or sixty feet of
  107. books at BookStop) and few bother to read it (did my bibliogaphy of a
  108. few issues ago get posted ?)
  109.  
  110. Just for an example, many readers of Virus-L use VAXes (my favorite
  111. PC) but how many know CHME, CHMK, & CHMS ? Its just not necessary
  112. unlike REPNZ MOVSW or LODSB/STOSB that should throw up warning flags
  113. to an observer in a PC.
  114.  
  115. The point is that these are just not skills that are taught anywhere
  116. that I know of (possibly, I'll be pleasently surprised as when several
  117. people reported that Logic is still taught in a few institutions)
  118.  
  119. >I have to read Virus-L at home because I
  120. >have a "real" computer security job to go to every morning.  I am not
  121. >alone in this respect.  Most companies don't realize the amount of
  122. >"phantom dollars" they are spending on viruses today.  When they do,
  123. >we'll see a much more effective response to this problem.
  124.  
  125. Exactly ! Perhaps the problem is that management expects miracles
  126. because we keep delivering them. In any event, I expect that nothing
  127. much will happen until the lawyers get into the act with some massive
  128. "negligence" suits from either stockholders of attacked companies or
  129. customers who suffer loss. The the Snake-Oil salesmen will really
  130. decend upon us.
  131.  
  132.                                 Enough,
  133.                                         Padgett
  134.  
  135. These opinions are free and worth what you paid for them.
  136.  
  137. ------------------------------
  138.  
  139. Date:    24 Dec 90 11:05:18 +0000
  140. From:    frisk@rhi.hi.is (Fridrik Skulason)
  141. Subject: Re: Job Market (PC)
  142.  
  143.   DRAGON@RCN.BITNET writes:
  144.  
  145. >...  What kind of job market is there for computer programmers who
  146. >specialize on detecting and eliminating viruses from other systems?
  147. >Is it a job that one can make a decent living at?  What languages
  148. >(Computer) are best suited for combatting viruses?  And who
  149. >(Corporations) would hire a computer anti-hacker?  Thanks for all
  150. >your help.
  151.  
  152. Well...as I am one of the people who partially make a living out of
  153. fighting viruses, I have a few suggestions.
  154.  
  155. You can indeed make a decent living by fighting viruses, but it is hard to
  156. get rich.  Anyhow, there are three options:
  157.  
  158.         1 - writing and selling anti-virus software...it is possible, but
  159.             not easy...I just barely make enough money from my own programs
  160.             to continue writing them.  If you want to write such programs,
  161.             be warned...it is a difficult market and crowded...but if you
  162.             still want to try...here is what you need:
  163.  
  164.             Very good knowledge of assembly language...I am not talking
  165.             about a one-semester course or anything like that...you need
  166.             the kind of practice you get by writing assembly-language programs
  167.             for several years.
  168.  
  169.             Very good knowledge of the operating system in question - you
  170.             must know every documented call, and also quite a few of the
  171.             undocumented ones.
  172.  
  173.             Very good knowledge of the hardware...I/O ports, absolute
  174.             addresses etc.
  175.  
  176.             Decent knowledge of at lest one high level language...C or
  177.             Pascal recommended.
  178.  
  179.             Last, but not least...samples of most of the different viruses,
  180.             just to make sure your programs work.  On a PC this means nearly
  181.             350 different viruses...and a lot of work...
  182.  
  183.             The problem of course is to sell your program...having the best
  184.             anti-virus program is not of much use, if nobody knows of
  185.             its existence.
  186.  
  187.         2 - Anti virus service...no programming, you just help people clean
  188.             up viruses and recover from attacks.  This also involves
  189.             installing anti-virus programs.
  190.  
  191.         3 - Writing about viruses...write a book...or magazine articles or
  192.             anything.
  193.  
  194.             The problem, in my opinion, is that all the virus-books available
  195.             only increase the "popularity" of viruses, leading to the writing
  196.             of still more viruses.
  197.  
  198. - -frisk
  199.  
  200. Fridrik Skulason      University of Iceland  |
  201. Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
  202. E-Mail: frisk@rhi.hi.is    Fax: 354-1-28801  |
  203.  
  204. ------------------------------
  205.  
  206. Date:    Sun, 23 Dec 90 00:06:04 -0800
  207. From:    Robert Slade <USERQBPP@SFU.BITNET>
  208. Subject: Antiviral evaluation guidelines
  209.  
  210. Attached herewith is an article outlining the different classes of
  211. anti-viral software, and features to check for in each class.  This is
  212. meant as an introduction to the anti-viral product reviews, which will
  213. be coming out every few weeks for the next little while.  (The first
  214. review should be included in this same issue of the digest.  It is
  215. for FPROT.)
  216.  
  217. [Ed. A wholehearted thanks for the effort, Robert!  I normally just
  218. place articles of this length into the archives with a pointer to them
  219. in the digests, but I'm making an exception in this case.  In
  220. addition, I'm placing this and any other reviews in the archives, on
  221. cert.sei.cmu.edu in pub/virus-l/docs/reviews.]
  222.  
  223. Reviewing Anti-virus Products
  224.  
  225. Robert Michael Slade
  226. 3118 Baird Road
  227. North Vancouver, B. C.
  228. V7K 2G6
  229. (604) 988-4097
  230.  
  231.  
  232. I am quite certain that the first question to do with "anti-
  233. viral" or other data security packages will be "which one is
  234. best?"  This ignores two vitally important points.  The first is
  235. that "the best" may not be good enough by itself.  No security
  236. force would ever pick "the best" guard, and then leave him to
  237. guard an entire refinery by himself.
  238.  
  239. The second point is that, even within the limited realm of anti-
  240. viral programs, data security software operates in many different
  241. ways.  Thus, one type of security may be better in one situation,
  242. while another variety may be better in a different environment.
  243. (Which make better guards, dogs or men?  Wise security firms use
  244. both.)  There are basically five "classes" of anti-viral
  245. packages; vaccines, change detection software, operation
  246. restricting software, encrypting software and scanners.  Each
  247. type has it's own strengths and weaknesses.
  248.  
  249. Vaccine
  250.  
  251. Vaccine software is memory resident and watches for "suspicious"
  252. activity.  It may, for example, check for any calls to "format" a
  253. disk while a program other than the operating system is "in
  254. control".  It may be more sophisticated, and check for any
  255. program that attempts to alter or delete a program file.
  256.  
  257. It is, however, very hard to tell the difference between a word
  258. processor updating a file and a virus infecting a file.  Vaccine
  259. programs may be more trouble than they are worth by continually
  260. asking for confirmation of valid activities.  They also may be
  261. bypassed by viri that do "low level" programming rather than
  262. using the standard operating system "calls".
  263.  
  264. It is very difficult to specify, in advance, what you should
  265. check for in vaccine software, since the developers are loath to
  266. state, in specific detail, exactly what the vaccine will be
  267. checking for.  (This reluctance is understandable: if a vaccine
  268. developer "advertises" exactly what the product checks for, virus
  269. or "trojan" writers will simply use another route.)  Vaccine
  270. software should be thoroughly tested in a "real" working
  271. environment (one that uses all the programs you normally do, in
  272. the ways you normally use them) for some time in order to ensure
  273. that the vaccine does not conflict with "normal" operation.
  274.  
  275. Change detection software
  276.  
  277. Change detection software examines system and/or program files
  278. and configuration, stores the information, and compares it
  279. against the actual configuration at a later time.  Most of these
  280. programs perform a "checksum" or "cyclic redundancy check" (CRC)
  281. that will detect changes to a file even if the length is
  282. unchanged.
  283.  
  284. The disadvantages of this system are 1) it provides no
  285. protection, but only notification after the fact, 2) some change
  286. detection software is limited to operating system software only,
  287. 3) you must "inform" the software of any changes you make in the
  288. system and 4) change detection software may not "see" changes
  289. made by "stealth" viri.  Some versions of this software run only
  290. at "boot time", others check each program as it is run.  Some of
  291. these programs attach a small piece of code to the programs they
  292. are "protecting", and this may cause programs which have their
  293. own change detection features to fail.
  294.  
  295. A major factor in judging change detection systems is that of
  296. installation and operation time.  Since the system will be
  297. calculating "signatures" of all (or all selected) programs on
  298. your system (sometimes with very sophisticated algorithms), it
  299. may take some time to install, and to "re-install" each time you
  300. make a change to your system.  It may also take an unacceptable
  301. amount of time to check out a program before it will allow it to
  302. run.
  303.  
  304. You should also find out how and where the security system will
  305. "store" the necessary program signatures, particularly if you run
  306. programs from diskette.  Also, since these types of systems are
  307. heavily influenced by the mini- and mainframe data security
  308. community, it is important to query whether they have made
  309. provisions for checking for boot sector viri, or other viri that
  310. may not show up as changes to program files.
  311.  
  312. Operation restricting software
  313.  
  314. Operation restricting software is similar to vaccine software,
  315. except that instead of watching for suspicious activities it
  316. "automatically" prevents them.  As with mainframe security
  317. "permission" systems, some of these packages allow you to
  318. restrict the activities that programs can perform, sometimes on a
  319. "file by file" basis.
  320.  
  321. However, the more options these programs allow, the more time
  322. they will take to set up.  Again, the program must be modified
  323. each time you make a valid change to the system, and, as with
  324. vaccine programs, some viri may be able to evade the protection
  325. by using low level programming.
  326.  
  327. It is important, with this software, that the operator is given
  328. the option of "allowing" an operation.  It is also important that
  329. the operator be informed, not only that a particular program or
  330. operation should be halted, but also why.  There should not be
  331. too many "false alarms" generated by the software, and it would
  332. be helpful to have the option of "tuning" the software to be
  333. less, or more, sensitive to a given type of activity.
  334.  
  335. Encrypting software
  336.  
  337. Encrypting software writes programs and/or data onto your disks
  338. in a non-standard way  and then "decrypts" the program or file
  339. when you need to use it.  This means that if a virus does try to
  340. infect the system, it usually only scrambles the data and is
  341. easily detectable.  Used in conjunction with operation
  342. restricting software features, encrypting software essentially
  343. changes the whole operating environment, hopefully to one that a
  344. virus cannot survive in.
  345.  
  346. Again, there is the need to do a lot of work in setting up the
  347. protection system, and keeping it up to date when you make
  348. changes.  (It is also possible, if the system is not configured
  349. properly to begin with, to end up with a system that you cannot
  350. use and cannot repair.)  There are two major "holes" in the
  351. security of the system, 1) some part of the system must remain
  352. "unencrypted" and is therefore vulnerable to "attack" and 2) if
  353. you start with already infected files, the system will quite
  354. happily encrypt the virus and allow it to operate.
  355.  
  356. One vitally important feature to consider in encrypting software,
  357. particularly if it is coupled with operation restricting
  358. software, is the ability to recover if anything goes wrong.  Do
  359. you have a recoverable backup, or are all your backup files
  360. encrypted, and useless without the proper code?  Can you boot off
  361. a floppy to recover if your "security" program dies?  If you can
  362. boot off a floppy, what provisions guard against boot sector
  363. viri?
  364.  
  365. Scanners
  366.  
  367. Scanning software is, paradoxically, the least protective and
  368. most useful of anti-viral software.  These programs examine
  369. files, boot sectors and/or memory for evidence of viral
  370. infection.  They generally look for viral "signatures", sections
  371. of program code that are known to be in specific viri but not in
  372. most other programs.  Because of this, scanning software will
  373. only detect "known" viri, and must be updated regularly.  Some
  374. scanning software has "resident" versions that check each file as
  375. it is run, but most require that you run the software "manually".
  376. It is also the classic case of "bolting the door after the horse
  377. is gone" since "scanners" only find infections after they occur.
  378.  
  379. Why then, with all the disadvantages of scanning software, are
  380. they the most successful of anti-viral packages?  Generally
  381. speaking, it is because they force the user to pay attention to
  382. the system.  Again, when a user relies on one particular method
  383. of protection they are most vulnerable.
  384.  
  385. Scanning software should be able to identify the largest possible
  386. number of viri, and should be able to identify variations on the
  387. more important sections of code (that is, it should be able to
  388. "accept" the removal of text strings and other simple
  389. modifications that "bush league hackers" might make.)  For ease
  390. and speed of updating, the "signatures" should be stored in a
  391. separate file and there should be a source for the addition of
  392. new viral signatures to the file.  For security, both scanning
  393. software program and signature files should be renameable.
  394.  
  395. Areas scanned should include not only the identifiable program
  396. files, but all files, if necessary.  Scanners should have the
  397. ability to search the more common archiving formats as well,
  398. particularly those that support "self extraction" functions.
  399. Disk boot sector and hard disk partition boot records should be
  400. scanned, as well (in this day of stealth viri) as memory.
  401.  
  402. copyright 1990 Robert M. Slade
  403.  
  404. ------------------------------
  405.  
  406. Date:    Sun, 23 Dec 90 00:11:24 -0800
  407. From:    Robert Slade <USERQBPP@SFU.BITNET>
  408. Subject: FPROT review (PC)
  409.  
  410. Antiviral Protection Comparison Review
  411.  
  412. Company and product:
  413.  
  414. Fridrik Skulason
  415. Box 7180
  416. IS-127 Reykjavik
  417. Iceland
  418. frisk@rhi.hi.is
  419. F-PROT-Virus detection/protection/disinfection and utilities
  420.  
  421. Summary:
  422.  
  423. Highly recommended for any situation.  Best "value for cost" of
  424. any package reviewed to date.  Installation may require knowledge
  425. of MS-DOS.
  426.  
  427. Cost
  428. Site license
  429.     Education      $1(US) per computer (minimum $20)
  430.     Other          $2(US) per computer
  431.  
  432. Rating (1-4, 1 = poor, 4 = very good)
  433.       "Friendliness"
  434.             Installation      2
  435.             Ease of use       3
  436.             Help systems      2
  437.       Compatibility           4
  438.       Company
  439.             Stability         2
  440.             Support           3
  441.       Documentation           2
  442.       Hardware required       4
  443.       Performance             3
  444.       Availability            3
  445.       Local Support           ?
  446.  
  447. General Description:
  448.  
  449. Of the five classes of anti-viral systems, the only one that
  450. FPROT does not provide for is encryption.  It provides vaccine
  451. (F-LOCK), change detection (F-OSCHK, F-XLOCK), operation
  452. restricting (F-DLOCK, F-XCHK) and scanning (F-DRIVER.SYS, F-FCHK,
  453. F-DISINF, F-SYSCHK) protection.  The package also includes
  454. various system information utilities
  455.  
  456.  
  457.                   Comparison of features and specifications
  458.  
  459.  
  460.  
  461. User Friendliness
  462.  
  463. Installation
  464.  
  465. The installation of FPROT is not a one step process, since the
  466. package contains a number of different programs for different
  467. protective purposes.  The user must decide which programs to use,
  468. and therefore the installation must be done in stages.
  469.  
  470. There is no installation program, but the documentation does have
  471. a separate installation file.  This file states that the user
  472. should have a knowledge of MS-DOS, and that is likely necessary.
  473. The installation process, however, is described clearly, and is
  474. quite complete.
  475.  
  476. The package is distributed as "shareware", and therefore any user
  477. who obtains it is likely to have the necessary skills for its
  478. installation.
  479.  
  480. The installation procedure does "allow" one possible point of
  481. infection if the computer is infected when the program is
  482. installed, but the program will immediately detect the infection
  483. unless it is not found in the signature file.  Since the program
  484. is "posted" in archived format, the user should be able to clear
  485. the infection and start with fresh files.
  486.  
  487. Ease of use
  488.  
  489. All the functions of FPROT are found in different programs, and
  490. all are invoked from the command line, so when a user knows what
  491. function is desired it is a simple matter to obtain it.  Only two
  492. of the programs have any "switches" other than file or path
  493. specification.
  494.  
  495. Help systems
  496.  
  497. As all packages are invoked from the command line for a single
  498. function, there is no need for "online" help.  When programs are
  499. called without necessary file or path specifications, a message
  500. explaining what is needed appears.
  501.  
  502. Compatibility
  503.  
  504. The various programs have been tested on a wide variety of
  505. computers, and have not created any problems with hardware, even
  506. on systems that have serious problems with TSR programs.
  507.  
  508. The documentation lists a number of "contra-indicated" software
  509. packages and systems which may conflict with program operations.
  510. However, in six months of testing, no normal character based
  511. program or TSR has been found to conflict with any FPROT program.
  512.  
  513. Company Stability
  514.  
  515. Unfortunately, the future of FPROT is currently in doubt.  It may
  516. continue as a shareware product, or it may be sold to commercial
  517. interests.
  518.  
  519. Company Support
  520.  
  521. No problems have been encountered with the program so far.
  522. Fridrik Skulason is available through the Internet, and replies
  523. to queries can be expected within a week or less.
  524.  
  525. Documentation
  526.  
  527. Being shareware, the package has no printed documentation.  The
  528. text files included with the programs are very clear and
  529. thorough, and provide an excellent primer on virus functions and
  530. protection.  Novice users may, however, find the USAGE.TXT
  531. document to be daunting.  Fortunately only the INSTALL.TXT
  532. document is required to use the product.  The virus listings are
  533. comprehensive as to the number of viri, if somewhat less
  534. technical and detailed than the Brunnstein and Hoffman listings.
  535.  
  536. Hardware Requirements
  537.  
  538. No special hardware is required.
  539.  
  540. Performance
  541.  
  542. During testing, FPROT has consistently identified more viri than
  543. the "current release" of any other product.  It has occasionally
  544. given a "false positive", but only in the case of identifying a
  545. definite virus with two different names, or when scanning another
  546. virus scanning product.  FPROT is generally slower at scanning,
  547. and the separate signature file renders it slower still, but the
  548. separate file also allows new signatures to be added without
  549. waiting for a product upgrade.
  550.  
  551. The user is in control of FPROT at all times, with the exception
  552. that F-DRIVER.SYS will not allow the boot sequence to continue in
  553. the case of a boot sector infection at startup.
  554.  
  555. FPROT, in six months of testing, has not given a false positive
  556. alarm on any normal program, nor has it interfered with any
  557. normal program operation.
  558.  
  559. Local Support
  560.  
  561. Since FPROT is shareware, there are no local dealers to obtain
  562. support from.  FPROT has fewer users in North America than SCAN,
  563. and so local help may be harder to obtain, but the documentation
  564. should make up any deficiencies.
  565.  
  566. For users in Europe, FPROT is available as a commercially
  567. distributed product.  For those in Canada, some support is
  568. available through the new SUZY Information Service, through
  569. INtegrity, the data security and anti-viral IN (Information
  570. Network.)
  571.  
  572. Support Requirements
  573.  
  574. In a situation where technical support is available for the user
  575. base, installation may best be performed by the support group.  A
  576. corporate environment will likely wish to have security policies,
  577. and support for the package in addition to installation would
  578. best be coordinated by this group.
  579.  
  580.                                  General Notes
  581.  
  582.  
  583. Because of its "shareware" distribution, FPROT is best compared
  584. against John McAfee's SCAN program.
  585.  
  586. FPROT is definitely the more complex package, but that is because
  587. of far greater functionality.  SCAN, in it's most recent
  588. releases, has offered a minor disinfection feature, but for most
  589. disinfection one must obtain, separately and at separate cost,
  590. the CLEAN and/or the older M-DISK programs.  Resident
  591. "vaccination" is also available, but again it is in the separate
  592. SENTRY or VSHIELD programs.  Finally, for use of any of these on
  593. a network, NETSCAN is required.  None of the SCAN family of
  594. programs offers the system information utilities that FPROT comes
  595. bundled with.
  596.  
  597. FPROT is kept up to date with regular additions to the signature
  598. file, and constant improvements to the program.  SCAN versions
  599. are released at approximately the same frequency as FPROT, but in
  600. a six month trial period from June to November of 1990, FPROT
  601. releases consistently identified more viri, and with greater
  602. accuracy than did the "same level" releases of SCAN.  (During
  603. this period, McAfee had to release four "bug fix" versions,
  604. Skulason only one.)  Fridrik Skulason also publishes the
  605. signatures of new viri on the VIRUS-L (Usenet comp.virus)
  606. distribution lists, and signature files can be updated between
  607. releases.
  608.  
  609. FPROT, distributed as shareware, is free for individual users.
  610. For a $15 US fee, Fridrik Skulason will mail out a "registered"
  611. copy.  The cost of the SCAN program is apparently subject to
  612. negotiation, but the "list price" in the documentation,
  613. shareware, for home use, is $25 US.  For the full set of four
  614. programs (SCAN, CLEAN, SENTRY and VSHIELD, not including NETSCAN)
  615. mailed on disk from McAfee Associates the cost is $119 US.  Site
  616. licenses for FPROT are available for $2 US per CPU, $1 for
  617. educational institutions.  Site licenses for SCAN alone are
  618. quoted at $8 US per CPU.
  619.  
  620. copyright 1990 Robert M. Slade
  621.  
  622. ------------------------------
  623.  
  624. End of VIRUS-L Digest [Volume 4 Issue 2]
  625. ****************************************
  626.  
  627.  
  628.  
  629.  
  630.