home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / virusl / vl04_002.txt < prev    next >
Encoding:
Internet Message Format  |  1996-09-04  |  26.3 KB

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