DOJ D 3896732 SECRET ' AFirst Generation Technical Viral Defense U I I i I P L 86-36 1lIt3 81 dele is elasslAtd 888R 'P it its cali at I 1 Editor's note This paper was awarded second prize in the Computer Security and Information Sciences Institute Essay Competition Cat gory of the 1987 Computer - j Computer viruses are a form of Trojan horses with a self-propagating property They cein be extr mely infectious and virulent when used maliciously in computer syste s Many defenses are available to System Security Officers SSOs which will limit or detect viruses Most meth ds are easy to implement yet provide the SSO with a high degree of effective viral contr ol These defenses include sealing the program by encryption techniques comparind the pre- and post-fix portions of programs limiting the domains the executable code inha8it andcontrolling the flow and access rights of programs Second generation viral deferkes will use heuristics to detect viruses audit the system looking for specific I viral-indie ators or compare the coding style in program Standard personnel and procedural techniques will not be discussed I I INTRODUCTION Syster l Security Officers have a wide variety of options to defend against software sabotage They can institute technical measures to prevent or detect unauthorized alterations investigate the backgrounds oftheir employees and implement procedures to I limit opportunities of introducing malicious code This paper will discuss the former measure that of compiling a suite of technical means to limit and detect software sabotage primarily that sabotage via computer viruses Compoter viruses are a form of Trojan horse Their mission is usually malicious and triggered y some event such as a certain system date or the disappearance of a certain name from the payroll database They have the additional property of being able to copy themselves from one program to another When introduced into a system with little or no ' defenses they can quickly take over the system obtain full privileges 5 9 131 Emph sis on computer viruses as opposed to the general class'of rrojan horses was chosen fori two reasons first because their propagation property makes them potentially more dan erous relative to ' ordinary Trojan horses 3 11 and second because their propagation property makes them potentially easier to detect than ordinary 'Trojan horses Technical methods which are germane to this problem will be discussed while generic pe'rsonnel and procedural security measures will not i DEFINITIO S 1 i i I t A computer virus is' a form of Trojan horse which has the additional property of being abl to copy itself to another program other than the program it inhabits Both a program irifected with a virus and a virus-free program are called hosts ' 1 ' ' ' ' eclassified and approved for release by NSA n 09-06-2011 ursuantto E O 13526 seCRET CRYPTOLOGIC QUARTERLY A viru has thiee components 2 the first is the propagation component that part which causes the virus to' propagate to other hosts second is the mission which is the ultimate goal of the virus and is usually malicious delete all files usurp the system etc and the third is theltrigger mechanism The trigger directs the virus when to execute the other two componeAts y' ASSUMPTIONS We assume tha the programs used to detect viruses are themselves not infected with yiruses and that they contain no other form of malicious logic If this is riot assumed it is easy to construct scenarios where··they fail A program which ostentatiously checks fpIviruses could be mJdified such that it would work except when it found apiirticular virus in which case the checker would ignore the infection I DEFENSIVE CLASSES 1 Defensive measures will be divided into three classes The first class att mpts to save an attribute of a pn gram that is initially pure Then it will periodically recompute arid compare this attribute to check for contamination A routine in this class cannot determine if a prog am is initially infected The class is entitled attribute monitors The second clas s is called virus detectors A routine in this class 'can determine whether a file is inltially ·infected These routines examine the program by itself or in relation to other prpgrams to determine whether infection has occurred The previous class established a' baseline and then checked to ensure that the basel ine was still accurate Both the first and second class detect viruses in a nondynamic way that is they do not rely on the bJhaiJior of the program during execution to work rather they rely on 1 the appearance The third class is execution limitations This class imposes a priori controls on executables to prever-t virus propagation After discussing some examples under each class three measures tha t will require much innovative work and engineering will be examined I ' ' ATTRIBUTE MONITORS I Checksum Routine I The first routin in this cl'ass is a checksum routine 1 11 The check fliin routine first computes a checksum on a file to be protected This initial value is storep and access protected 1 if the sy teril itself cannot provide sufficient control then th checksum is protected by reducing it to hardcopy or writing the value to write-once media Synchronously or 0 0 demand the checksum for the file is recomputed and compared 1 One can not simply access protect the' file being checksummed in the same manner The checksum s may be protected with the s me constraints the system would use to protect the password file This level of protection cannot be applied to every users' files Also the checksum s m t be protected from any write access some files may b written to from authorized programs but not by others The system may not provide the needed granularity f control SEERET 28 s r i' DOClD 3896732 SECRn A FIRST GENERATION TECHNICAL VIRAL DEFENSE I against the stored value If the values differ the SSO knows that the file has been I ' modified If an authorized change to the file is made the initial checksum must be updated ft is assumed that updates to operational systems will be infrequent and can be closely coq trolled AlthoHgh this scheme and others below may be too costly to implement for every executable or file on the system it may be used to protect a subset of especially critical programs This subset should include essential operational routines or software development routines such as translators or compilers as well as whatever security relevant programs lexist such as the login password responder or auditor It is also possible to store the checksum with the file itself and at run-time recompute and compare it This method has the advantage of cat hing an infected file before it executes and potentially infecting ·others but the disadvantage of increasirtg the executionioverhead This system may be modified by allowing the owner to specify an option at nvocation time that would cause the checksum to be re computed and compared Encryptiort I ' I A me hod which relies on the pairing of a decryption key with the protected file is a routine that uses public key encryption techniques PubIi I key or asymmetric encryption uses t o keys to encrypUdecrypt where K 1 K2 lOne of the keys is derivable from the other say K2 is derivable from Ky however given K2 by itself it is extremely hard to derive K 1 see fig i Kl is referred to i rI -' t i ' j EASY TO DO ' b II l'O - - HARD TO DO _ Fig 1 Public and Secret Keys I I as the s cret key and K2 is the public key When the public key is published anyone can use it to encrypt a message which only the holder of the secret key can decrypt see fig 2 all wing secrecy or to decrypt a message which purports to be from the holder of the secret key see fig 3 which if successful authenticate the message as being sent from the holder of the secret key 7 10 -' 29 EtR T' CRYPTOLOGIC QUARTERLY ' Kl I I USERl PLAINTEXT I CIPHER TEXT II USERN PLAINTEXT - P 'III I il l ill PLAINTEXT CIPHERTEXT t I Fig 2 Private Cbmmunication - Anybody Encrypts with K 2 Only Holder ofK j Can Decrypt I ' i I I I USER 1 PLAINTEXT CIPHERTEXT USERN • _ _ ' J - I Fig 3 A' lthenticated Communication - Cipher Text Decryptable by Anyone with the Public Key j j SECRET 30 J j 11 i ro DOClO 3896732 SECAH A FIRST GENERATION TECHNICAL VIRAL DEFENSE The ethod ii1Volves encrypting an executable using KI the secret key Then K 1 is destroyed K2 the public key is published for everyone to use to decrypt the executable file for US¢ 2 As long as no one has K 1 it is impossible for a virus to infect the executable seefig 4 The virus cannot write directly to the executable without being decoded to I -1 PROGRAM IS ENCRYPTED WITH THE SECRET KEY I I - ' ' USERl USERN '1'• 1 1 1 PROGRAM IS DECRYPTED WITH THE I 'UBLIC KEY AND PROVIDED TO THE USER ' Fig 4 - I Progra s Encrypted with Secret and pubif' 'ifeys ' gibberisn see fig 5 because the executable is encrypted and wql be decrypted to run If the virud decrypts the file and then attaches itself and writes the corrupt version back out the OS decrypt it into meaningless bits whenever anyone attempts exe ution3 see will 2 There oula'be an operating system service such that whenever'someOl requests an encrypted program be executed the operating system would first decrypt the executable with the atching public key 3 ObvioiJsly the operating system must not have a Trojan horse which allows th decrypting of protected executables to be bypassed Otherwise the virus would decrypt the execut lble insert itself and write the executable back to memory flagging the OS not to decrypt it to execute I 31 SEOt T SECRET CRYPTOLOGIC QUARTERLY I I I fig 6 The virus 1cannot use K2 for encryption purposes and it cannot derive Kl to reencryp·t the exec table properly Fig 5 Plain Teit Virus is Decoded into Random Bits when Program is Decrypted to Execute I _ Fig 6 Plain Text ProgramNirus Pair Fares No Better A key-per-executable or one key for all executables are two alternative methods to ·use see fig 7 If key-per-executable is chosen installation of the encrypted executable and the list of public keys must be protected like the checksums were protected Otherwise a virus would decrypt the executable insert itself obtain a public secret key-pair encrypt the infected versio then write out the new good public key into its spot on the public key list Of course 'if the other method is used a new executable or a change to any of the protecte ones will necessitate decrypting· all ex cutables indThen reencriPting them with the new secret key The new executable cannot just be encrypted and added because K 1 was destroyed If the key was not destroyed sufficient precautions must be taken to guard an unauthorized user from obtaining it to undetectably insert viruses A compromise ethod would be to group files and have a key per n files Files which are almost guaranteed hot to change could have their own key This guarantees that no more than n files must be decryptedJreencrypted to add a file or change an existing one · I Other routines in this class may focus on saving file characteristics such as length in bytes samplings from known positions or date-and-time-of-last-change Althougn a clever virus can optimize a program so that the length does not change such an attack would be detected t rough the checksum protection method I 1 32 1 j 'I I I Ii I tI I t- - ' - -- '_'- - '- - '---'c- - - '7'7 --_ _ » c-' o H-- - tI w 00 J en K1 -J W K2 _-'u'l- -_- _ -- --_-''- II _ '- - ' ONE KEY PAIR FOR ALL EXECOTABLES r J l c i tXJ Z tXJ 0 I Kl l w w ' K2 1 l ' ' 'l ' _1·11 _ I I _ '·1 t 0 V _ fl I tXJ ' I Z i t t 0 • ti I tf·_ Kl N o tXJ l tXJ Z rJJ tXJ K2 N· ONE KEY PAIR FOR EACH EXECUTABLE I oz Fig 7 Key Pairs for Executables CREI CRYPTOLOGIC QUARTERLY VIRUS DETECTORS I Pre-iPost-fix Test r I I The first viru sdetect relieson the virus always appending itself either to the front or end of a progra m A siniple virus will likely insert itself at the beginning of a program This is the simple st action that ensure ·thatthe virus will be run before the host program If the virus appeq ds itself to the end of a program execution assurance is more difficult The virus must either depend on control falling through the host to the virus or code at the top of the hos must Q e hanged or added to cause executiop ofthe virus The benefit to the SSO is that a -simple program can e amine a number of files to' determin _jOh prst 0 last n bytes are i entical If'sucha ch cker de er-mines that several programs have ldentIcal pre-fixes It can assume that a Vlrus has mfected them all The checker must be intelligent enough to discount standard headings or pre-fixes before it starts to xamine the code ' Pre- and postJfix checkers will evolve into something more sophisticated Succeeding checkers must haye even more intelligence built in If a virus knew that only the first 20' bytes were compared it could create its o n unique header by inserting a jump instruction to the real viral code followed by 15 random bytes A smart checker could detect that the first few bytes were alike in several different programs and have the I ability to compar an ar itrary number of bytes even shifting sequences between one file and another i As iruses aie designed to be more sophisticated checkers wit have to rely on statistIcal techniques to detect viruses A very smart virus programmer might concoct a scheme where the virus apportions itself up into 20 byte chunks with a 10 byte chunk being random bits perhaps get clock value and insert It would know enough to jump around these ran40m pool$ and to insert new values each time it propagates That way a checker would hot find more than 10 bytes alike out of 20 But if the' checker has I • sampled clean executables and knows that 15 percent of a small target subpart some section of code mi us standard headers is a reasonable amount of identical code to find in different programs a 50 percent figure may be enough to trigger an alarm The virus is then forced to hare more random bytes but that takes up more space which further increases the risk of detection and one or two instructions would start showing up in some unnatural regularity the jump instruction This see-saw battie will continue as checkers and viruses become more sophisticated An advantagel that the simple pre- and post-fix checker shares with the checksum routine is that it can work on object files quite handily Humans have enough trouble reading high-level source code let alone machine code A program that can examine these types of fil s can be a useful tool A disadvantage of the pattern matcher the smarter pre- po t-fix checker is that it can take even more CPU tiIJ1e than the checksum routine Run in backgrpund mode the pattern matcher acts to detect viruses Once a virus is found· it can be used to find other hosts infected by that virus by looking in the same relative place for· the same bytes in the other hosts I EXECUTION LIMITATIONS I I Th next metHods discussed will be used primarily to prevent viruses from infecting files as opposed td the above methods which were used to detect infections except for the encryption method I I 34 DOCID 3896732 I A FIRST GENERATION TECHNICAL VIRAL DEFENSE 5 'Cft T I Access C ntrols I I '0 ' ' • y' These ro utines try to ensure that e ecutables are never written too directly or if so then only by a selected group' of files The easiest way to accomplish this is to set the privilege for executables to execute only In Unix the privileges would look like --x--x--x aepending on who was given execute rights Of course the file may need to be deleted ot the program modified and recompiled all of which potentially allow infection to occur Ahd if one program normally writes to an executahle this allows any program with Sim ilar priyileges to write to the executable ' There are several methods that could I obviate the protection ofthis scheme A user could delete an executable and then rename one of his own that is infected with the name of the deleted file If the user knows the path that thesht m searches to' execute th 'file he may be ableto insert a like-named- file into the path tructuresuch that it is found before the OS gets to the real program Ifthe file to be protected is a user file it may bernore appropriate to allow the user to determine who ifanyone may execute or eVen write to it This may be accomplished by the use deu ser Defined Domains l2 or domain type enforced systems 4 The' idea behind t ese two systems is to allow oniy needed prespecified access to files These systems can constrain unauthorized access but allow those actions that are otherwis required · If the user has a program whicH writes into an executable that fact cant e encoded within these schemes as permissable while still denying other files the right to write into that executable The granularity of access control may be taken all the way 'down toa program level That is one could specify precisely which programs had access to another Most popular discretion'ary access' schemes allow the granularity to be specifiediat the user level one can indicate which users 'are allowed access but cannot specify which programs of that user are allowed access and which are not The use of the domaih type enforcer can further restrict the ability to contaminate executables by restricting those subjects which have the privilege to create executables SSOs may wish to tightly control this right granting it only to compilers or other system routines which take some file and transform it to an executable object Further they would ha e to control who could access these transformers This defense narrows the vulnerability of the system greatly and allows the SSO to concentr te his attention and efforts With protected' executables virus originators are forced to examine other levels of the system for their attacks One way this can be done is toinfect ht the source code level Then the originator has only to corrupt the executable to force Irecompilation or wait until some other change is made and the program recompiledfor the viral propagation to be effected ' ' FlowMo els Flow model protection can be used as a defense against viruses One way of implemei1ting flow control would be to ·tag information with a number which represents I the number of processes which have touched it flow distance 5 Processes have a preset threshold of shareability Once information has been touched so many times it will exce edthis threshold and be rejected This 'Policy at best only limits the damage that can be done through a virus which sequentially spreads If program A is' infected every other program in the system can be corrupted from it and thus become infected themselJes This policy limits those infections which are spread through long chains of contamination where program A infect program B which irifects program C and so on A smart I virus- could void the flow limit if it were known by building the same limit minus one into its propagation trigger ' - - ' -- $ CREi CRYPTOLOGIC QUARTERLY Another way of limiting flow is to tag information with the names of USers who have touched it' flow list 5D Then users may indicate who they wish to share with and also condition sharing 6n the number of names that appear in the list If one user knows that the person across' the hall regularly brings in freeware he may not accept any information that has be en to hed by the freeware user Flow model pro ection isjusta way of limitiIlg or conditioning the accesses allowed to executables Systems that allow users to set the privileges to their executables provide I ' mechanisms for limiting viruses as noted above since viruses can only exploit the privileges that they naturally obtain excepting any security flows that can be 'actively exploited If the v irus is allowed to change accesses while still under program control this will not affect them very much If the OS requires a trusted path coimection to change privileges 1the system is ffiore secure Regrettably flow model protection is a prime example of a security functionality trade off The more secure the system in terms of this model the less sharing functionality is possible Conversely the more sharing allowed the less security is added by flow controls Labeling Labeling certaln executables at the lowest level -1 1 on a system which has mandatory security will also prevent those executables from being infected frorrr viruses ' ' at higher levels This works because mandatory security prevents any subject from writing to an object which has a lower classification level than the'subject Thus if the' executable has a le el which i_s less than veryone else's nobody can' write to it But this method requires th t each executable be downgraded to be protected as well as requi ing the data that thes executables use be at the same lowest -1 level This is a counter ' intuitive method of using levels to protect information Also all' of the executables downgraded to that level must be virus-free as they could potentially'write to each other ROMs Installation on read-only device will allow SSOs to use the physical qualities of the medium to prevent writing to executables Of course this method incurs problems ifthe executables must be modified It must then be possible to write another executable which will be executed instead of the old version But if this is possible then it may also be possible for someone to create a contamin ated version of the executable and write it out to be executed instead 1 of the correct ' version The goal of keeping development systems separate from ope ti onal ones is much the same here ROMs are 'generally safel' Naturally the oflgInal source code and the compIler must be protected from contamination as wku as the transition to executable code and the underiying microcode ' 1 FUTURE DEFENSES I Future defense also called second generation defenses are those which in general utilize artificial in elligence programming techniques The methods discussed include' I 4 A mechanism by which a person at a terminal can communicate directly with the Trusted Computing Base This mechanisn1 can only 'be activated by the person or the Trusted Computing Base and cannot be imitated by untrusted software DoD Trusted Computer System Evaluation Criteria DoD 5200 28-ST D December 1985 ' $i CREI 36 DOCID '3896732 A FIRST GENERATION TECHNICAL VIRAL DEFENSE 51 CkEI i aprogr m which examines other programs and determines whether malicious software is imbedded within it a very smart audit program which looks for viral activity in the system ctivity and a program which examines other programs and looks for changes in the coding style which would indicate a change of authorship Virus Filter' I Wepelieve that the task of writing a computer program which would examine other and determine whether or not the examinee is infected with a virus is impossiple However it is possible to detect certain types of viruses in certain environments as well as locate sections of code which look suspicious The program that does thi must know'a lot about what viruses look like and also be cognizant of the system' environment withinwhich it is opel'ating To rite this progmm instructions and usage must be researched Viruses have certain properties which many if not most other progmms d not For example many viruses will need to call system routines to find the names of xec ltableftles to infect whereas many user programs already know which programs that they will access The implem ntation of these properties should show up in the instructions of the virus Moreov r the clustering appearance in close proximity of these instructions as in a virus wliichappends or inserts itself in toto would be a significant fingerprint A normal us er program may have many of the same instructions hat a virus does but is more likely to have them spread throughout This program would attempt to locate viral-like code assign' some value as to the perceived likelihood of it being a virus and then pass that information and the section sl of suspiJious code back to a user for any final decision or action progra s I I Au ditor J 1 I The audit routine would determine when a program s was suspicious by examining their behavior It may sample the global system state toestablish-whether viruses had infected Iprograms Certain viruses may beeasilydetectedtht' ughtheir behavior from a single ogram where the effects of oth rs may not be' seen except through an aggregation The auditor would also be comparing and analyzing behavior through time since vi uses may construct their triggers to mask their pr pagation properties L2 • Ana uditor which uses templates of user activity and then compa-res current actions gainst his template has already been proposed 6 81 An authorized us r may spend most of his time doing real work or computiri'g where a masquerader may sperid an ino dina te amount of time browsing through direcWries or checking statuses An implementation of this type of auditor could simply so u nd an aler t h¢n ti J ecoIp pared di fferen e was-gr at enough or it could provide more Information to the S to mere closely tedict exactly what type ofattack is or has occurred Author Checker I I The last second generation viral defense is a program which examines code and then tries to answer questions such as how many authors does this program have and where does one author's code end and another's begin -- Certain techniques exist to answer these questions for noncomputer-like documents Such techniques would look at such items as the length of sentences or paragraphs the tense and inflection the use and type of certain grammatical characteristics or ploys not to mention simple ha ndwriting analysis A program could be constructed to examine source code with similar'intentions I' I I I 37 SECRET SECRET RYPTOLOGIC QUARTERLY I I • Perhaps t would examine indentation the use of comments loop construction or even characteristics of variable names As ystem routi es transform the source code in preparation for machine execution such analysis wouldibecome'IIlOre difficult although not impossible Once the source code is verified to be uninfected tHe object code source code run through the compiler needs to be tested Here certain of the above characteristics cannot be used The c·ompiler would strip out comments ' for instance but the basic structure of the program would remain If a program is optimized that would increase the amount of personal characteristics filtered out or ma ked decreasing the confidence level of finding and identifying differences ' CONCLUSIONS Certain measutes may be undert ken to provide SSOs with some assurance that programs or executables cannot undetectably be infected with computer viruses These measures rely upori the changes that must occur for infection to take place Once the protection of the routines and the data that they require the list of checksums or the list of public keys is assured these toutinesprovide a high degree of assurance that viral I activity will be prevented or detected Other more sophisticated mechanisms are poss ble but require furthe research before implementation SECkEl 38 r DOCrD 3896732 SEERef A FIRST GENERATION TECHNICAL VIRAL DEFENSE REFERENCES 1 _ _ _ _ _ _---l · The Susceptibility of Multics to Viral Attacks Cryptologic Quarterly Fall 1985 I 2 3 _ _ _- -_ __ - - I ComputerVirus O ganiza ion A Definitive Taxonollly and Anatoqly of Comput r Viruses CrjJptologu Quarterly Fall 1986 ' I I 1· Why Use 'a Virus Inst ad f a Trojan H rse Informal TechfiicalNote 198T I 4 ' ' ' ' -- ' ---- Boebert Earl and Richard Kain Pr ticalAlt rl1ative to Hier chicallntegrity Policies Proceedings of the 8th National·NaSfNC$C Computer 'Security Conference 1985 A I I 5 Cohen Fred Computer Viruses Proceedings of the 7th National NBS NOSe CQmputer Security Conference 1984 ' I 6 DJnning Dorothy An Intrusion-DetectionMOdel Proceedings of the 19 86 IEEE Symposium on Security an dPriuacy 7-9 April 1986 7 Dime Whitfield and Marti n E Hellman New Directions in Cryptology IEEE· T1iansactions on Information Theory Vol IT-22 No 6 November 1976 8 Halme LawrenceR and John Van Horne A tbm ted Analysis of CQm uter S stem Audit Trails for Security Purposes ' Proceedings of the 9th National NBS NCSC Computer Security Conference 1986 9 K rger Paul and Roger Schell Multics Security Evaiuation Vulnerability Analysis ESD-TR-74 1 3 Vol II June 1974 I ' I ' ' t 10 Rivest R L A Shamir andL Adleman A M tho«i for Obtaining Digital Signatures and Public KeyCryptOsystems CACM Vol 21 No 2 Februal-y 1978 11 '---_----- ·ComputerVirus Infections Cryptoiogic Quarterly Fall 1985 12 Srpith Terry·A User Definable Domains as a Mechanism for Implementing the Least Privilege Principle Proceedings of the 9th NatioOOl' NBBINCSC Computer Security Conference 1986 I 13 Thompson Ken Reflections on Trusting Trust CACM Vol 27 No 8 August 1984 -- ' - • I 39 SECRE'f' P L 86-36 SEERE-f CRYPTOLOGIC QUARTERLY I I I I Appendix 1 I· I '1 Viral Defenses and System Security U The effective ness of these defenses will vary depending on the· security of the system they inhabit A n All system should be able to adequately protect a list of keys for instance where D 2 sy tem may not There are two questions to answer when examining viral defenses and system security one is a specific vi'Faraefense necessary in an Al or above some level system and two would a defense do any good ina D or below some level system The ansWer both is yes Ther is already ll a paper which details a vulnerability in a B2 level system It is obvious that without spec fic mechanisms which can be used to defeat viruses a system built to an' Al level of'security is still vulnerable to viruses This I vulnerability is probably not the' risk of disclosure but that of -integrity or denial' of service That is a system built to Al 'with no additional security functionality is susceptible to ceftain classes ofcomputer viruses However it is true that an Al syste'm provides the assurance tha1 when viral defenses are added they are much less likely to be subverted I A D level system may still benefit from the addition of viral defenses There are three ways that defens s may be used First it may be announced that they are being installed Although this wpuld allow a cognizant viral designer to create ' 'defense-r·esistant viruses any imported viruses stand a good chance of being caught Second defenses may be added surrep itiously Whereas this incurs the limitations of depending on secre9 instead o strength for security it is ar-guably better than announcing its emplacement The third me thod requires t9-eSSO to logout all users from the system perform' a shutdown boot t e OS from a physically protected medium and then perform the check for viruses Of course this last is only applicable to those defenses which'attempt to ferret out viru'ses from the appearance of the host ptogram and could' not work fot those which rely on the progr ms behavior to detect viruses ' An SSO'inayfind eit'her of th first two methods adequate in a benign'imvironment but m-ustimptement the last if warrallted It may also be reasonable to use method one or two duringt1 J e m9nth but at the end ofthemontheffect the more secure sweep tp 'j j il I ' 1 · 1 ' i ' l 1 See DoD TCSEC OoD 5200 28·STD I 2 Ibid I I I ECREI j I 1 I I 40