From: Chris McDonald STEWS-IM-CM-S (1/26/93) To: orvis%llnl.gov@wsmr-simtel20.ar, Mail*Link¨ SMTP Product Test 16 ******************************************************************************* PT-16 Revised February 1991 ******************************************************************************* 1. Product Description: PC/DACS is a software package which operates on an IBM PC, PC\XT, PC\AT, or 100% BIOS compatible microcomputer with at 512KB of random access memory running MS-DOS or PC-DOS 2.0 or greater. The package adds Identification and Authentication (I&A), Discretionary Access Control (DAC), Object Reuse and Audit features to the DOS operating system. The National Computer Security Center (NCSC) has evaluated the package under its Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria, 16 Sep 88 (reference CSC-EPL-89/009). 2. Product Acquisition: PC/DACS is available from PYRAMID Development Corp., 20 Hurlbut Street, West Hartford, CT 06110. Their telephone number is 203- 953-9832. The retail value is $249.00. Site licenses are available. 3. Product Tester: Chris Mc Donald, Computer Systems Analyst, Directorate of Information Management, White Sands Missile Range, NM 88002-5030, DSN 258-7548 or DDN: cmcdonal@wsmr-emh03.army.mil. 4. Product Test: a. I obtained a free copy of PC/DACS, version 1.02, in April 1989 by attending a PYRAMID Development Corp. seminar in Dallas, TX. I upgraded to version 2.0 for a $50.00 charge in September 1989. NCSC officially evaluated PC/DACS and added the package to its Evaluated Products List on 28 September 1989. In October 1990 version 2.02 became available. The major features announced included support of Novell networks, additional virus disabling capabilities, and an interrupt control assurance to address attempts at tampering with DACS internal control mechanisms. b. I tested the product on a Unisys PC, Model 3137, MS-DOS 3.10, 512K. VIRUSCAN and VIRUCIDE scanning of the program disks was negative for the identification of known computer viruses and certain trojan horses. c. PC/DACS is proof one can have mainframe controls on a personal computer. Installation procedures are concise. Version 2.0 consists of an installation disk with four program disks. The installation is menu-driven with feedback as to the success or non-success of any particular operation. There are default settings for various security options. The detailed operating manual advises the user of those defaults in the event a change is necessary. The default is that PC/DACS will install without boot protection. This is an EXTREMELY important safeguard, particularly when a user may have had no previous experience with PC/DACS or with a comparable security package. d. The key to PC/DACS is the establishment of a Security Administrator. The administrator establishes user accounts, sets security options, determines the privileges of each user, and has exclusive access to extensive audit trail records. It would be impossible to describe each feature of the package and keep this product test evaluation short. Therefore, I have chosen to comment on specific items which I think are important. e. The identification and authentication of users, to include the security administrator, relies on individual passwords. The administrator has the option to set minimum password length (1-15 characters); the number of incorrect login attempts which will be permitted (1-99); and the number of days to password expiration (none, 1 to 365). The administrator can also ensure that users actually change their password by enabling an option "number of expired passwords". Under this option the administrator can set a value for the number of previously expired passwords to be stored and checked whenever a user has the requirement to change an authentication password. I tested all of these options with no problem. f. The system administrator can also enable two other options to protect users who have successfully entered their authentication password. The first option addresses the user who walks away from a system without properly logging off or turning the system off. The administrator can set an automatic timeout feature to secure the system after a specified period of keyboard inactivity. The timeout period can range from 1 minute to a maximum of 9 hours and 59 minutes. When the idle time has been reached, the administrator can either have the system reboot and present the initial user identification and authentication screen; or deactivate the active application, clear the screen, and wait for the user to enter his or her password. I thoroughly tested the the latter feature which presented no difficulty. g. The second option to make life easier for users is for the administrator to enable a timeout hot key combination. With this option the user, who has to temporarily leave the system, or who wishes to protect information on the screen without logging off, can simultaneously depress three keys: left shift+right shift+alt. This sequence will deactivate the active application, clear the screen, and wait for the user to enter his or her password. The menu to reenter the user authentication password is identical to the menu generated by the automatic timeout option. This option worked as advertised. h. One might attempt to bypass the password protection scheme by using a system disk to boot from the system's floppy drive. The system administrator can enable boot protection as an option upon successful installation of the PC/DACS package. I tested boot protection and found that it worked to deny me access to the hard drive. Attempts to view the hard drive with Norton Utilities were unsuccessful. i. Object reuse refers to the ability of a subsystem to clear storage objects to prevent subjects (i.e., users/programs) from scavenging data from storage objects which have been previously used. Object reuse subsystems must assure that no previously used storage objects can be used to scavenge residual information. Information remaining in previously used storage objects can be destroyed by overwriting it with meaningless or unintelligible bit patterns. An alternate approach is to deny read access to previously used storage objects until the user who has just acquired them has overwritten them with his own data. The NCSC evaluation confirmed that PC/DACS "implements this feature". j. Discretionary access control is in the hands of the system 2 administrator. The administrator can establish "views" for each individual user by constructing access rules. There is a tutorial in the PC/DACS documentation which gives examples on how this can be done. The documentation also has an additional section on constructing and applying access rules. Access rules can apply to a hard disk, to all files of one type on the entire hard disk, to all the files in one type in a directory or a sub-directory, to a group of files, or to a single file. Access rights include Read, Write, Open, Create, Delete, Purge, Search, Modify, Execute and Administrate (i.e., create or remove sub-directories). I created five different user accounts with different access rights and "views". The controls functioned as documented. Attempts to bypass access rules or to use Norton Utilities to circumvent any particular "view" restriction were unsuccessful. k. The Audit mechanism of PC/DACS is extensive. The system administrator has the discretion to select what to audit. The selection process is menu-driven. There are three categories of events audited:. (1) Session Statistics: user logons, user logoffs, automatic timeouts, relogon after timeout (2) Operational Statistics: program starts, program exit, program exit and stay resident, sub-directory creates, sub-directory removals, open/create/update/delete/rename a file, logon password changes, add/delete/change a user, add/delete/change access rules, add/remove/change a password protected resource, create/remove encrypted area, printer port access, communications port access, change file attributes (3) Violation Statistics: logon user ID not found, logon password error, resource password error, attempt to write to printer, attempt to access com:port, unauthorized read attempt, unauthorized write attempt, unauthorized open attempt, unauthorized create attempt, unauthorized delete attempt, unauthorized rename attempt, unauthorized mkdir attempt, unauthorized rmdir attempt, unauthorized program execute attempt, unauthorized mofify file attempt, unauthorized disk format attempt l. I tested all of the options and generated various types of reports. I found that with all events chosen for audit the size of the audit file can increase rapidly. The system administrator by default has exclusive access rights for the audit records, and must take explicit action to reset the log file. "Reset" removes previous statistics collected. All of the audit features performed as indicated. I note that the NCSC evaluation expressed concern that users could access the system clock which is used by Audit for timestamp information. But, while the "time" of an event might be changed, NCSC did not indicate a user could tamper with an actual session, operational or violation statistic. m. The final option which I tested was the DES data encryption utility. This program will encrypt and decrypt any data using the algorithm published by the National Institute of Standards and Technology (NIST). The specific implementation is the Electronic Code Book (ECB) mode described in Federal Information Processing Standard Publication 81. The ECB mode is a basic, block 3 cryptographic method which transforms 64 bits of input to 64 bits of output as specified in Federal Information Processing Standard Publication 46-1. The analogy to a codebook arises because "the same plain text block always produces the same cipher text block for a given cryptographic key" (Appendix B, FIPS 81). Since FIPS Publication 46-1 only authorizes DES implementations in hardware, all software implementations require a waiver from NIST. The NCSC evaluation made no attempt to evaluate the strength of the data encryption scheme, only that data was successfully transformed. I have been unable to determine if NIST has evaluated the PC/DACS implementation. n. My test of the DES encryption confirmed that features worked as documented. The utility is menu-driven with plenty of options available. The user supplies up to an 8 character "key" for the encryption/decryption operation. The "key" is not displayed on the screen, nor is it stored with the file encrypted or on the system. If the user forgets the "key", then the ability to decrypt is lost. I measured the speed of the utility to encrypt/ decrypt with these results: Size of File Time to Encrypt/Decrypt 22,885 Bytes 14.67 seconds 59,760 Bytes 38.28 seconds 165,296 Bytes 102.53 seconds 225,434 Bytes 140.57 seconds I am not sure how these times compare to the capabilities of other commercial and public domain software implementations. The INTERNET has had some discussion of this subject. Readers might also consider contacting NIST directly. Speed of execution was not a major consideration during my testing. o. PC/DACS offers these additional features which I did not test for a variety of reasons. (1) Passwords for additional resource protection for sub-directories and files (2) Resource encryption for text files (non-DES) (3) Full disk encryption (non-DES) (4) Partition encryption (non-DES) (5) Restricted guest accounts p. With version 2.0 PC/DACS advertised its ability to address viral infection. The specific mechanisms proposed included these options: (1) The assignment of access rules to executables through the use of available "view" rights. (2) The use of the low level I/O prevention feature to prevent reads or 4 writes, issued at the BIOS level, from reaching the target sector. (3) Utilization of resource encryption to protect files against modification at the BIOS level. Conceptually the approach to restrict program modification appears to be a viable option. It addresses a major weakness in existing viral scanning programs to the extent that it does not depend upon knowing specific viral signatures or characteristics. Constructing "views", however, is not an easy task. Although PC/DACS has menu-driven instructions for assigning access rules, and although there is a very instructive section in the manual on specific rules for viral protection, a user will have to have some training on how to implement this protection efficiently. Encryption should similarly make it more difficult to spread an infection. My expertise in this area is just insufficient to make any further comment. 5. Product Advantages: a. PC/DACS has formal evaluation by NCSC. b. The package appears to function as documented. c. The system administrator has maximum flexibility to choose what features will be enabled. d. The documentation for the package is extensive. e. The vendor provides telephonic support at no additional charge. 6. Product Disadvantages: a. The price of PC/DACS, even with discounts for a site license, may be prohibitive for some users. The DESKTOP III contract, for example, has an access control package for $20.00 a copy. While cost should never be the only criteria, government organizations have a "low bidder" syndrome. [NOTE: I have issued a product test report on this DESKTOP III product, reference PT-15, December 1990, PROTEC). b. There is user resistance to any type of control on personal computers. It may be difficult, in the absence of written policy which mandates the installation of an access control package, to find an audience for PC/DACS. The construction of "views" will in my opinion be a major obstacle. c. While PC/DACS has evaluation by NCSC as a subsystem, there are legitimate questions as to what this actually means. The NCSC subsystem criteria addresses the problem of evaluating a product against a subset of the requirements given in the Trusted Computer System Evaluation Criteria (TCSEC). Ratings under the subsystem criteria are not identical to those in the TCSEC or Orange Book. d. The concept of a system administrator for a personal computer demands 5 a management commitment of resources and personnel, particularly in those cases where the installed PC/DACS community is large. Formal training of administrators and continuity of operations plans to support users who will require assistance in using PC/DACS is essential. 7. Comments: PC/DACS is a nice package. There are other software programs available which offer comparable features. Some of these programs are also on the NCSC's subsystem Evaluated Products List. Therefore, users should evaluate more than just one package before making a decision. Clearly the use of PC/DACS must be a function of a realist assessment of one's particular threat operating environment. It would be a mistake to impose the mandatory implementation of an access control package without such an assessment. The virus protection capabilities of version 2.0 and the enhancements at 2.02 require a more robust examination by those directly involved in viral examination. It should be noted that there are other approaches to access control on a personal computer which employ hardware and/or a combination of hardware and software techniques. Various authors have commented on the increased protection in those products which have a hardware foundation (i.e., DES hardware versus software implementation). I personally have no prejudice one way or the other. But in the interest of completeness I would be remiss if I failed to mention this fact. [The opinions expressed in this evaluation are those of the author, and should not be taken as representing official Department of Army positions or a commercial endorsement.] 6 ------------------ RFC822 Header Follows ------------------ Received: by internetqm.llnl.gov with SMTP;26 Jan 1993 20:48:26 U Received: from icdc.llnl.gov by icdc.llnl.gov (PMDF #12441) id <01GTZKWHVD2OERWQE4@icdc.llnl.gov>; Tue, 26 Jan 1993 20:48 PST Received: from pierce.llnl.gov by icdc.llnl.gov (PMDF #12441) id <01GTZKW1E5XSERWQ8O@icdc.llnl.gov>; Tue, 26 Jan 1993 20:47 PST Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA16207; Tue, 26 Jan 93 20:42:26 PST Received: from WSMR-SIMTEL20.ARMY.MIL by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA16134; Tue, 26 Jan 93 20:40:09 PST Received: from wsmr-emh03.army.mil by WSMR-SIMTEL20.ARMY.MIL with TCP; Tue, 26 Jan 1993 21:39:14 -0700 (MST) Resent-date: Tue, 26 Jan 1993 20:48 PST Date: Tue, 26 Jan 93 21:35:06 MST From: Chris McDonald STEWS-IM-CM-S Subject: Product Test 16 Resent-to: BILL_ORVIS@QUICKMAIL.llnl.GOV To: orvis%llnl.gov@wsmr-simtel20.army.MIL Resent-message-id: <01GTZKWHVD2OERWQE4@icdc.llnl.gov> Message-id: <9301270440.AA16134@pierce.llnl.gov> X-Envelope-to: BILL_ORVIS@QUICKMAIL.llnl.gov X-VMS-To: IN%"orvis%llnl.gov@wsmr-simtel20.army.MIL" ======================================================================