REPORTS ON COMPUTER SECURITY FOR SCI-HANDLING SYSTEMS

Document Type: 
Collection: 
Document Number (FOIA) /ESDN (CREST): 
CIA-RDP87M00539R000901160028-2
Release Decision: 
RIPPUB
Original Classification: 
T
Document Page Count: 
41
Document Creation Date: 
December 27, 2016
Document Release Date: 
August 17, 2009
Sequence Number: 
28
Case Number: 
Publication Date: 
January 22, 1985
Content Type: 
MEMO
File: 
AttachmentSize
PDF icon CIA-RDP87M00539R000901160028-2.pdf1.48 MB
Body: 
Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Next 3 Page(s) In Document Denied Iq Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 TfP SFrPFT The Director of Central Intelligence Washington. D. C. 20505 NFIC-9.11/1 22 January 1985 MEMORANDUM FOR: See Distribution SUBJECT: Reports on Computer Security for SCI-Handling Systems 1. The DCI's Computer Security (COMPUSEC) Project began in April 1983 and is intended to support the DCI in assessing the security of automated systems processing information derived from sensitive methods and sources, to identify the threats to automated systems processing such materials, and to recommend actions for the DCI that will allow him to attest to the acceptability of operating risks. 2. As part of the DCI's COMPUSEC Project, the COMPUSEC Project Team developed an assessment on the threat to US automated Intelligence Community systems (See Attachment 1). Representatives from the NFIC Community have provided input to this document. This formulation of the "threat" is being used in conjunction with security assessments of the Intelligence Community's "critical" automated SCI systems to set program and budget priorities for immediate security upgrades. This threat point paper also se~to fulfill one of the DCI's continuing distinctive responsibilities. 3. The SAFEGUARDS document (Attachment 2) identifies security requireri?ents for the protection of SCI information in the "critical" systems evaluated as part of the DCI's Computer Security (COMPUSEC) Project. When fully implemented in the "critical" systems, the SAFEGUARDS will correct the security shortfalls and reduce to an acceptable level the risks currently associated with processing this sensitive information in the "critical" systems. I intend to direct that the SAFEGUARDS be imposed as mandatory standards for the 13 "critical" SCI-handling systems by the end of FY 86. These SAFEGUARDS will also be imposed as voluntary standards for other SCI-handling systems. 4. In June 1984, an interagency Computer Security Technology Panel was established to assess the application of computer security technologies against known operational deficiencies within Intelligence Community computer systems. The panel focused on what could be done, in the near term, with existing computer security technology and administrative/management actions to provide security upgrades for our "critical" systems. Specific emphasis was given to three areas of computer security vulnerability: authentication of REGRADE AS SECRET/NOFORN UPON REMOVAL OF ATTACHMENTS AND CAVEATS UMBRA TAP SFrRFT Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 TOP SECRET SUBJECT: Reports on Computer Security for SCI-Handling Systems users; accountability of operating actions; and labeling of SCI information. The findings and recommendations of the Technology Panel are provided to you for your use and comment (See Attachment 3). When these "action-oriented" recommendations are arrayed against the identified vulnerabilities of the "critical" systems and the threat against them, it will lead to a plan for significant improvement in Community COMPUSEC. I intend to pursue these " es to recommendations, in coordination with other computer security initia strengthen the protection of SCI material in computer-based systems. 5. These documents are also being provid the appropriate officials with responsibilities assigned by NSDD/145. Attachments: 1) BYE-2227-84 2) Computer Security Technology Assessment Report 3) Uniform SAFEGUARDS for Protection of "Critical Systems" Processing Intelligence Information TOP SFCRFT Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 TOP SECRET SUBJECT: Reports on Computer Security for SCI-Handling Systems Distribution: Copy 1 - DCI (William J. Casey) 2 - SecDef (Caspar W. Weinberger) 3 - DDCI (John N. McMahon) 4 - EXDIR~CIA (Jim Taylor) 5 - ASD(C I) (Don Latham) 6 - D/INR (Hugh Montgomery) 7 - D/DIA (LtGen James A. Williams, USA) 8 - D/NSA (LtGen Lincoln D. Faurer, USAF) 9 - D/DNI (Rear Admiral John Butts, USN) 10 - Assistant Director, Intel. Div., FBI (Edward J. O'Malley) 11 - DOE/DAS, Intelligence (Charles Boykin) 12 - Treasury (Douglas Mulholland) 13 - Air Force, Under Secretary (Edward C. Aldridge, Jr.) 14 - Army/ACSI (LtGen William E. Odom, USA) 15 - Air Force/ACSI (MajGen James C. Pfautz, USAF) 16 - USMC/DI (BG Lloyd W. Smith, USMC) 17 - NSC (Ken deGraffenreid) 18 - National Security Advisor (Robert McFarlane) 19 - DUSD/P (Gen. Richard G. Stilwell, USA Ret.) 20 - Justice Dept (Mary C. Lawton) 21 - DOC (Irving P. Margulies) 22 - Chm/IPC/CIA (Richard Kerr) UMBRA TOP SECRET Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 STAT Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 SECRET Supplement to Security Policy on Intelligence Information in Automated Systems and Networks DCID 1/16 dated 4 January 1983 Uniform SAFEGUARDS for Protection of "Critical Systems" Processing Intelligence Information December 1984 SECRET 002 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 STAT Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 SECRET UNIFORM SAFEGUARDS FOR PROTECTION OF "CRITICAL SYSTEMS" PROCESSING INTELLIGENCE INFORMATION Supplement to Security Policy on Intelligence Information in Automated Systems and Networks DCID 1/16, 4 January 1983 December 1984 SECRET Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 UNCLASSIFIED FOREWORD The Deputy Director of Central Intelligence (DDCI) directed that security SAFE- GUARDS be developed to reduce the vulnerabilities associated with processing information derived from sensitive intelligence sources and methods in "critical" automated systems and networks. These "critical systems" were identified by the senior members of the Intelligence Community and uniform assessments of the security of these systems were made using an early draft of these SAFEGUARDS. These SAFEGUARDS identify security requirements which, when satisfied, will significantly reduce the vulnerabilities identified in the assess- ments of the "critical systems." These SAFEGUARDS requirements are intended as a transitional step for the Intelligence Community to reduce security risks that are inherent in existing "critical systems." The Intelligence Community will use the trusted security products and services of the Department of Defense (DoD) Computer Security Center as soon as such products and services are developed and are available to be incorporated into the Community's inventory of automated systems. These SAFEGUARDS reflect the Director of Central Intelligence's (DCI) requirements for reducing near-term risks until trusted systems are available and therefore are intended to complement the DoD Computer Security Evaluation Criteria. The SAFEGUARDS are mandatory for all "critical systems" and voluntary for all other systems processing information derived from sensitive intelligence sources and methods. (U) UNCLASSIFIED Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 UNCLASSIFIED Table of Contents Page 1. INTRODUCTION (U) ............................................................................................ 1 II. OBJECTIVE AND GUIDELINES (U) .................................................................. 3 III. ACCREDITATION OF "CRITICAL SYSTEMS" FOR VARIOUS MODES OF OPERATION (U) .............................................................................. 7 IV. DEDICATED MODE OF OPERATION AND UNIFORM SAFEGUARDS (U) .................................................................................................. 13 V. SYSTEM HIGH MODE OF OPERATION AND UNIFORM SAFEGUARDS (U) .................................................................................................. 17 VI. COMPARTMENTED MODE OF OPERATION AND UNIFORM SAFEGUARDS (U) .................................................................................................. 23 VII. MULTILEVEL MODE OF OPERATION AND UNIFORM SAFEGUARDS (U) .................................................................................................. 31 VIII. NETWORK SECURITY FOR "CRITICAL SYSTEMS" (U) ............................ 39 IX. GLOSSARY (U) ...................................................................................................... 43 Table 1 Security SAFEGUARDS by Mode of Operation (U) .......................................... 10 Table 2 Modes of Operation for Processing Intelligence Information (U) ................................................................................................................ 11 V UNCLASSIFIED Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Next 36 Page(s) In Document Denied Iq Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 UNCLASSIFIED IX. GLOSSARY ACCESS. A specific type of interaction between a subject and an object that results in the flow of information from one to the other. (U) AUTHENTICATION. A positive identification, with a degree of certainty sufficient for permitting certain rights or privileges to the person or thing positively identified. (U) COMPARTMENTED MODE. See Section VI. (U) "CRITICAL SYSTEM. " For this document, a "critical system" is a computer system processing and/or storing intelligence information that has been selected by senior officials in the National Security Community. (U) DATAGRAM. A datagram is an internet protocol packet; the packet is made up of a header and trailer. For the purpose of this document the datagram is the equivalent packet of data as defined by the network being utilized. (U) DCI. Director of Central Intelligence. (U) DCID. Director of Central Intelligence Directive. (U) DDCI. Deputy Director of Central Intelligence. (U) DEDICATED MODE. See Section IV. (U) ESCORT. Duly designated personnel who have appropriate clearances and access approvals for the material contained in the ADP system and are sufficiently knowledgeable to understand the security implications and to control the activities and access of the individual being escorted. (U) ISSO. Information System Security Officer. (U) INTELLIGENCE INFORMATION. For purposes of this policy statement, intelligence information means foreign intelligence, and foreign counterintelligence involving sensitive intelligence sources and methods, that has been classified pursuant to Executive Order 12356 (or successor order). "Foreign intelligence" and "counterintelligence" have meanings as- signed them in Executive Order 12333. "Intelligence," as used herein, also includes Sensitive Compartmented Information (SCI) as defined in the DCI Security Policy Manual for SCI Control Systems, effective 28 June 1982. (U) LOW WATER MARK. Of two or more security levels, the least of the hierarchical classifications, and the set intersection of the nonhierarchical categories. (U) MULTILEVEL MODE. See Section VII. (U) NFIB. National Foreign Intelligence Board. (U) NSO. Network Security Officer. (U) OBJECT. A passive entity that contains or receives information. Access to an object potentially implies access to information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bytes, words, fields, processors, video displays, keyboards, clocks, printers' network nodes, etc. (U) 43 UNCLASSIFIED Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 UNCLASSIFIED SBI. Special Background Investigation. (U) SENSITIVE COMPARTMENTED INFORMATION (SCI). All information and materials requiring special Community controls indicating restricted handling within present and future Community intelligence collection programs and their end products. These special Community controls are formal systems of restricted access established to protect the sensitive aspects of intelligence sources and methods and analytical procedures of foreign intelligence programs. The term does not include Restricted Data as defined in Section II, Public Law 585, Atomic Energy Act of 1954, as amended. (U) SENSITIVITY LABEL. A piece of information that represents the security level of an object and that describes the sensitivity (e.g., classification) of the data in the object. (U) SESSION. An activity for a period of time; the activity is access to a computer/network re- source by a user; a period of time is bounded by session initiation (a form of logon) and session termination (a form of logoff). (U) SESSION SECURITY LEVEL. The security level of a session is the low water mark of the security levels of: the user, the terminal, a level specified by the user, and the system from which the session originates. (U) STORAGE OBJECT. An object that supports both read and write accesses. (U) SUBJECT. An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. (U) SUBJECT'S SECURITY LEVEL. A subject's security level is equal to the security level of the objects to which it has either read only or both read and write access. A subject's security level must always be dominated by the session security level. (U) SYSTEM HIGH MODE. See Section V. (U) TRUSTED SYSTEM. Employing sufficient integrity measures to allow its use for processing intelligence information involving sensitive intelligence sources and methods. (U) USER. A user is an individual and/or processes operating on his/her/its behalf. (U) 44 UNCLASSIFIED Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Next 1 Page(s) In Document Denied Iq Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Lae Director of Central Intelligence Computer Security Technology Assessment Report MPUSE An Executive Overview Prepared for The Deputy Director of Central Intelligence by the Computer Security Technology Panel DCI/ICS 84-4036 December 1984 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Computer Security Technology Assessment Report An Executive Overview Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 In support of the Deputy Director of Central Intelligence, in June 1984, the Director of the COMPUSEC Program established a Computer Security Technology Panel to address what could be done, in the near term, with existing computer security technology to improve the security of critical systems currently operating within the Intelligence Community. Specific emphasis was given to three areas of security: authentication of users to an automated system, accountability of user actions in such systems, and labelling of information handled by them. Over a six months period, members of the Technology Panel met on six different occasions to evaluate state-of-the-art technology against known vulnerabilities within Intelligence Community computer-based systems. This report presents the findings and conclusions of the Technology Panel and presents specific recommendations for future actions. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Preface ........................................................ iii Members of the DCI's Computer Security Technology Panel ...... vii Introduction .................................................... 1 Context ........................................................ 1 Technology in General .......................................... 2 Software ....................................................... 3 Security Compliance ............................................ 4 Authentication .................................................. 6 Labelling ....................................................... 8 Accountability .................................................. 13 Guard Technology .............................................. 15 Certification and Accreditation ............................ . ..... 16 Information Sharing ............................................ 17 Specific Vendor Systems ........................................ 18 General Security Upgrading .................................... 19 Research ....................................................... 20 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 MEMBERS OF THE DCI'S COMPUTER SECURITY TECHNOLOGY PANEL Organization CHAIRMAN COMPUSEC PROJECT DIRECTOR EXECUTIVE SECRETARY Principal Laboratory NSA of Standards NSA Alternate FBI Mr. William E. Kardash, Jr. Mr. Franklin Standifer Federal Emergency Dr. John LaBarre Mr. Bruce J. Campbell Management Agency OUSDRE CIA Aerospace Corporation Naval Intelligence Command Captain Phil McKnight Department of State Mr. Lynn McNulty System Development Corporation DARPA Dr. Steve Squires Chemical Abstracts Dr. Ronald Wigington Service Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Report of the Technology Panel This is the executive overview of the report of the Technology Panel of the DCI's Compusec project. It offers the DCI a series of action-oriented recommendations that he can use to improve the security status of critical systems and to assist system managers of Community automated information systems. It addresses primarily the short term "quick fix" actions that can be promptly initiated. When these technology oriented recommendations are arrayed against the identified vulnerabilities of the critical systems and the threat against them, it can lead to a plan for significant security improvements. By extension, it also addresses key ingredients that should be included in the planning for and implementation of systems coming into the inventory. The views expressed here are those of the individual Panel members who participated as skilled practitioners of the information system art. Specifically the views may not reflect the position of the organizations from which the Panel members were drawn. We address three issues which were selected for the specific attention of the Panel: authentication of users to an automated system, accountability of user actions in such systems, and labelling of information handled by them. Two of the three--accountability and labelling--are primarily software issues; the third, authentication, involves specialized hardware as well as accompanying terminal-level and host-level software. Although we were told that the critical systems did use commercially available hardware and software, neither the technical details nor the operational names of the "critical systems" were made available to the Panel. This impeded our ability to relate our experience with various hardware/software combinations to system- specific suggestions for remedial actions to the critical systems. There is consequently a risk that our observations and intuitions will be incorrect, with the result that our recommendations may be slightly off-target. Notwithstanding the arms-length arrangement and lack of specific details, our comments and recommendations below are based on the collective knowledge of the Panel and on its composite experience with many systems installed elsewhere. We believe that the DCI's critical systems, even though implemented to handle security sensitive information, are not likely to be very different from those of our experience. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Since there is a temptation to believe that technology can readily be invoked to fix a wide class of computer-related problems, some general observations are in order. Some aspects of security safeguards for automated infomation systems have long been understood; e.g., TEMPEST, physical protection, COMSEC. However, those safeguards which depend on software processes and/or a combination of software features plus supporting hardware features do not yet have a well-established foundation such as that found in the COMSEC area. Thus, there is not yet a wide variety of off- the-shelf products that can be simply "dropped in" to achieve some significant gain in security protection. Therefore, we conclude that A. In the near term the DCI can not expect there to be a plethora of sophisticated technology that can be readily applied to the problems of his critical systems. On the contrary, we conclude that B. The DCI should expect to utilize low-level technology and management/administrative actions that can be promptly applied for important security improvement over the short term, i.e. 2 to 4 years. The first order quick fix is not even technology, but rather upgrading installed systems to the level of guidance now regularly supplied to Community contractors; all systems should be brought into compliance with security safeguards that are well understood and readily employed, e.g., proper generation and management of passwords. Such procedural, administrative, and in-hand technology approaches must be exploited prior to seeking elegant technical "magic solutions" to security shortfalls. The explosive growth in technology indicates that ongoing attention must be given to security safeguards; it is not and will not be a static issue. Dramatically new operational circumstances will arise and require new approaches to security policy and corresponding safeguards. For example, computer terminals are being connected to broad-band local area networks, and the COMSEC protective mechanisms are being incorporated directly into each terminal. In contrast, key generators traditionally have been protected in locked physical spaces. Again, newer terminals--especially the so-called smart ones--have local storage which may include removable media such as floppy discs and permanent disc storage; thus, the protective mechanisms that are now required in the main computer will in the future have to be implemented in each terminal as well. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Since many desirable security safeguards must eventually be implemented in either the system's so-called "operating system software" or in other specially designed software packages, some specific observations and cautions in regard to software upgrades and modifications are essential. Retrofitting an existing system with appropriate software to provide security safeguards is not only a potentially major task, but it also may have collateral consequences unrelated to the software task proper; e.g., restructuring all the computer files or the database. Moreover, only a few software products have been evaluated by the Computer Security Center, although a number of vendors (both hardware and independent software houses) do offer software products that might be useful in the critical systems. Given the present state of art, however, with regard to software security, we conclude that C. Comprehensive security safeguards as implied by the Guidelines of the Computer Security Center can not be retrofitted to existing installed hardware/software configurations. Moreover, there may be substantial deterrents against doing major software upgrades especially on old hardware; e.g., existing maintenance contracts for vendor-supplied software, lack of an in-house programming group or one of sufficient expertise to do the job, operational restrictions against changing the software (such as interconnect arrangements), lack of a stand-alone machine separate from the operational one on which to do software development (the so-called Life-Cycle-Support facility), a too-small operational hardware configuration to accommodate new software. Therefore, given the schedule and funding risks attached to major software modifications in the critical systems, plus the possibility that mission support might be disrupted, we recommend that 1. The DCI direct that an economic cost-benefit analysis be submitted to him for any proposal that seeks to retrofit extensive technical safeguards to an existing system by modifying its vendor-supplied software, as opposed to an expedited equipment upgrade bringing with it new safeguards in both hardware and vendor software. This recommendation addresses proposals for specialized modifications to software whose operational life is limited, and to vendor software for which improved products can be made available but may require new hardware. [In this regard, SEE: Recommendations 27 and and 28.] Software changes may be needed to install some safeguards that we have suggested in other recommendations (e.g., machine-generated passwords) but even then, a careful cost analysis is warranted. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 In this regard, it should be noted that both computing technology and computer science are both very dynamic with the result that the sophistication of the threat against computer systems, especially networked systems, tends to increase rapidly over time. Therefore, the "security lifetime" of an installed computer system is likely to be much shorter than the amortized economic lifetime. We conclude that D. Equipment may have to be upgraded or replaced more frequently in order to maintain an adequate threshold of security protection against the developing threat. Our recommendations are grouped by topic and presented below. For each topic there is a short background discussion; and a short commentary or explanation is interspersed between many of the recommendations. Background Technology cannot be a panacea for security vulnerabilities; every dimension of security must be attended as well, e.g., physical security COMSEC, personnel security. Such things are well understood in contrast to those safeguards that are implemented'in hardware and/or software. Moreover, the latter safeguards tend to be technically intricate and their need tends not to be appreciated. Since automated-information-system security safeguards of any kind are defensive in nature and do not directly contribute to mission performance, COMPUSEC generally has a low level of visibility and priority at management levels. Thus, decisions tend to favor operational and mission obligations, especially when it comes to funding decisions. 2. The DCI task his Compusec project to review the documented assessments of the critical systems, to report within 90 days where his critical system(s) is (are) deficient relative to the "best documentation" available for implementation of security safeguards, to report what actions can be taken to bring his system(s) into compliance, and the cost to do so. Various guideline documents exist for specifying broad and comprehensive security practices in computer systems, e.g., CIA's Contractor Security Manual, DIA's DIAM 50-4. In general these all derive from DCID 1/16. For the initial examination, we mean by "best documentation" the most Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 comprehensive and current guidance that can be assembled, whether it be material that has been prepared for internal use, for contractor use, or is a combination of the above. However, recently updated documents that may be available from other (external to the agency) sources should also be examined. Although the DCI might have tasked his system managers to make the reviews, it is expedient to task his Compusec project in view of the work that it has already accomplished. 3. The DCI task each system manager to make similar compliance checks on an annual basis, and to take such actions as may be necessary to bring his system(s) into compliance with the then existing best guidance and documentation. 4. The DCI (concurrently with [2] above) cause to be prepared a Community standard security-guidelines document that will become the standard required of each present and new system within the Community, both at initial operational status and on periodic examinations thereafter. The DCI's "Safeguards document" is a start on such a comprehensive "Computer System Security Manual," but it must be supplemented with or reference sources of information about other dimensions of system security, e.g., generation and management of passwords, handling of audit trail information, assignment of management responsibilities. Much of this can come from extant documents if they are consistent, complete, contain all relevant terms, assignments of responsibility, etc. Documents to be examined for relevant other information include ones from CIA, DIA, NSA, probably CSC, perhaps DODCI, probably NBS. 5. The DCI have DCID 1/16 updated and revised to remove any anomalies and limitations related to obsolescent technologies and their operational employment. To the maximum extent possible, the policies should be technology independent and permit interpretation in the environment of contemporary technology. New technology--and uses of it--have appeared that DCID 1/16 did not anticipate. For example, it overlooks communications networks between computers, and the data networking of personal computers. Moreover, technology has raised policy issues that are not addressed in the most recent edition of DCID 1/16. E. System managers must promptly institute security improvements that can be made now, and not await updated policy guidance. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 AUTHENTICATION Background In the contemporary environment of information systems that are networked not only within themselves but also among one another, the word "user" must be understood to include: (1) an individual at a terminal, (2) an internal software process executing in behalf of a person at a terminal, and (3) an external computer or communication system. In this discussion, the emphasis is on (1) with some consideration for (3). The process aspect [item (2)] is largely a matter of trusted software for which the Computer Security Center is the national focal point; trusted solutions to the process authentication issue can not be expected to be operationally deployed in the near term, i.e. 2 to 4 years. In the present state of development of the art, the DCI can not expect elaborate and technically complex schemes for authenticating system users to be available for presently installed computer and system architectures. In general, such schemes will be most needed when multilevel-secure systems become operationally widespread. However, he can expect the development of authentication devices that measure some biometric feature of a person (e.g., fingerprint, retinal pattern) and of devices that depend on something that the individual must possess (e.g., magnetic card, smart card). Each such device will have different operational appeal and shortcomings; but all have the same attribute that integration into the terminal and the automated system per se is required. Recommendations We recommend that 6. The DCI reiterate his requirement that DIA take the Community lead for the authentication issue; and Specifically task DIA to promptly examine possibilities for utilizing "low-level" technology to install or to improve personal authentication procedures in the critical systems, and to make recommendations as appropriate to system managers. The technology for installing devices at terminals to do personal authentication is not quite here, but significant improvements can be made promptly through administrative and procedural means. Examples of such "low-level" technology include: (1) the use of daily authentication codes which are made available to an individual upon reporting to duty, together with corresponding internal software changes to maintain such code tables in encrypted form; (2) the proper generation, management and periodic changing of passwords; (3) the automatic disconnection of an idle terminal after a prescribed period of time. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 7. The DCI task NSA to promptly issue guidance on the proper generation of and management controls for passwords; and task system managers to implement such guidance within 180 days. 8. The DCI task DIA to conduct a comprehensive comparative study to evaluate various approaches to authentication, taking into account the best information on each, the costs of each, and the operational environments of the systems for which the techniques will be used. Such a study should include such factors as: User convenience at the terminal. Does it force him to take some awkward or unusual action; does it require him to have or carry something; does it make a biometric measurement? ? Bottlenecks at the entry/exit to the facility if physical access to protected space is part of the scheme. ? Cost per terminal and per authentication object (e.g., individual, other system); device cost, integration cost and TEMPEST recertification costs all must be included. ? Perceived threat to the installation and/or system. Does an approach provide a cost/beneficial solution or will some techniques be an overkill for the anticipated threat? ? Sensitivity of the facility to be protected. How should the effectiveness of an authentication technique be related to system, facility, and information sensitivity? ? Availability of the technology to implement an approach. Is it here now, or is R&D or engineering development needed? ? The operational environment in which the device must function. For example, will the individual wear protective clothing during an authentication action, or will he have to function under extreme stress that would make some complicated approach unworkable, or might he be physically impaired or disabled? Is there risk of losing a physical object? ? Operational acceptance. Would it be acceptable to utilize an item to be left at the workplace, or invoked many times during an operational shift? ? The time to complete an authentication. Are some approaches so time consuming that individuals would be tempted to circumvent them, or would operational inefficiencies result? ? The technical consequences for system integration. In particular, what are the software consequences in the host system? Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 As appropriate, biometric techniques (e.g., retinal recognition) could be tasked to CIA. Finally, the study should recommend the long-term executive agent to attend the authentication issue for the Community, and develop a requirements statement that can be incorporated into a system specification for Community procurements. 9. The DCI task NSA to formulate and proceed with an aggressive program to examine new physical-object techniques; e.g., smart cards, magnetic cards, (so-called) ignition keys. 10. The DC1 direct DIA to accelerate its program for investigating authentication devices (including the studies above) to assure that high-confidence personal-user authentication devices are available and fully integrated into commonly used Community systems by 1990. 11. The DCI provide funding wedges now for procurement of personal authentication devices that promise to be in the $500-$1000 range by the late 1980s or very early 1990s. Techniques such as retinal pattern recognition, smart cards, ignition keys, etc. could be available and fully integrated into operational systems in the late 1980s or early 1990s with proper programmatic emphasis. Based on background briefings to the Panel, we believe that present per-terminal costs will decline to $2000-$3000 by 1987-88 and into the $1000 or less range no later than the early 1990s. Background The technical issue is to associate the proper set of security labels with each database, file, or record in a computer system (or possibly with individual data element components in any one of them); and to assure that such labels accompany the information as it moves elsewhere, e.g., displayed, printed, handed-off to a communication system. As such, it is primarily a software issue and can have significant collateral consequences; e.g., installation of a comprehensive labelling system might require restructuring all the databases, files, or records. With regard to the host computer software aspects, labelling is an especially troublesome software issue because retrofitting existing systems may require modification of not only the operating system software but also database management software. Either undertaking could be a major undertaking. In the short run (i.e., 2 to 4 years), there may be little that can be done, but such a conclusion is very Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 dependent on system hardware/software details. For some systems, it may be that there are newer database management systems that could be installed and would provide some capability for associating security labels with information. [In this regard, SEE: Recommendations 27 and For some systems, there may fortuitously exist some software capability to accommodate labelling, but any actions to exploit such an opportunity will be system dependent. Given the minimal knowledge provided to the Panel about the systems, we can not offer specific suggestions. In the long run, so-called trusted systems are expected to provide labelling capability, but they will have to be certified to B-1 (or better; by the Computer Security Center. One system (MULTICS) is a candidate for a B-2 rating but it is specific to a vendor's machines that are not widely used in the Community. However, products from other vendors have been submitted to the Center with the expectation that a rating of at least B-1 will be obtained. While evaluation of them is not yet complete, such systems. clearly offer significantly better safeguards than software presently installed in the field, and should be considered for near-term installation. [In this regard, SEE: Recommendations 27 and 28.] F. There may exist near-term (i.e., 2 to 4 years) opportunities for providing one or more of the critical systems with some labelling capability; but any decision to do so is system specific and must take account of possible collateral consequences; e.g., complete restructuring of the files, disruption of mission support, retraining of operators and/or users, the necessity to replace hardware or upgrade the configuration of presently installed equipment. There is a second nontechnical operational aspect of great importance; namely, does the information now in the critical systems carry the proper security labels? For example, a decision may have been made for a dedicated system not to associate labels with information, on the grounds that the entire facility and all users function at the same classification. It is unlikely, but possible, that a similar decision would have been made for a dedicated or compartmented system; but the Panel was not given such information. If the critical systems have not captured labelling information and/or have not associated it with the substantive information in the database, then the near-term outlook (i.e., 2 to 4 years) is likely to be bleak because of the intellectual effort to assign classification labels for all items of information and because of the corresponding effort to enter such information into the databases, files, and records. The best that could be done--but it may represent an important security advance--is to build simple labelling conventions into the software that outputs information to terminals, communication systems, other software Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 processes, and printers. Even this may be a major software undertaking and we caution against undertaking it without a thorough examination of the consequences to the system, to user training, to operator training, to operational procedures, etc. The decision is very system dependent, especially with regard to possible side effects. The only system for which a simple remedy appears possible is the dedicated one, all of whose users function with a uniform set of security labels. Paper could be preprinted with security labels; permanent physical security labels could be attached to each terminal; communication processors could be modified to attach security labels to all messages. Since the Panel did not have detailed information about the critical systems, this suggestion may already have been implemented.' When hardware/software configurations that can support full-scope labelling become operational, we conclude that G. The Community is likely to find that it has not made the necessary investment in assigning labels to all computer-storec information; and ff. Will have to make a significant one-time investment to achieve such a state. For classifying and labelling sensitive materials, the government uses a very complex schema to which there is no analog in business and industry; there, relatively simple classification and labelling schemes are satisfactory. Given such a business and industry view, computer vendors may not spontaneously develop systems that have the scope and flexibility to fully meet the DCI (and other government) labelling requirements. Thus, we conclude that 1. Labelling, in the complexity required by DCI systems, appears to be a security objective that will require government R&D support to achieve. Furthermore, as systems internet with one another the necessity for a Community-wide standard set of security labels becomes more important, as does the need for having everything properly labelled. Technology i seen as offsetting a lack of standardization; but, in fact, the system designers need a more consistent schema than now exists. Moreover, systems which internet must be mutually assured that security labels have not been perturbed in transit, nor has the association between the information and its rightful label been disturbed. This is the "label integrity" issue which has not yet been examined by the Computer Security Center. For some, perhaps all, of t1 critical systems, it may be possible to assure label integrity through the communication portions even though the internal (to the computer) aspect of labelling can not be accommodated. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 12. The DCI task his Compusec project to review the documented assessments of the critical systems with regard to the technical opportunities that each has for incorporating some form of labelling; and to recommend within 180 days what near-term actions can be taken, at what cost, and on what schedule. This examination must consider many software details of the various systems, include consideration of the difficulty and cost of taking such actions, and take account of new software products such as are referenced in recommendations [27] and [28]. It must also consider collateral effects, such as the need to restructure all databases, files and records. There should be some assessment of the improvement in security posture that can be achieved for the kind of labelling that might be done in each of the critical systems. Although the DCI might have tasked his system managers to make the reviews, it is expedient to task his Compusec project in view of the work that it has already accomplished. The project may, however, require the cooperation of the system managers to provide technical details, especially of software, that may not exist in the documented assessments. 13. The DCI establish a requirement that no later than the end of FY 85 all information entered into general-user Community systems be accompanied by relevant security labels; and Task system managers to implement this requirement in a way that will afford flexibility and adaptability in utilizing label information in the database when systems providing full-scope labelling become available. The first part of this is to assure that all new information flowing into Community systems carries proper security labels. Otherwise, the situation outlined in conclusions [G] and [H] will continue unabated. Software, as well as operational or system, changes may be required; and therefore, implementation may depend on the outcome of recommendation [12] above. The phrase "general-user" is included in order that specialized or research systems that may not need security controls are not needlessly burdened. The second part relates to future hardware/software replacements that will take place when B-1 systems become available. It is unlikely that the database, file and record structures in new equipment will be the same as in the old. Since label information acquired in the present systems may be represented differently in the new, and its association with the substantive information may be treated differently, it is important to take the steps now to facilitate conversion to new equipment at a later date. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 It may not be possible to do a perfect job of planning for an equipment transition whose details are unknown, but the technical issue must be considered and a best-effort attempt made to assure transferability of label information and its relationship to database entries. The Panel raised the question of security label standardization, but did not reach a satisfactory resolution to the issue. There may be some differences in meaning or usage of security labels that will have to be standardized. However, we know from our collective knowledge and experience that there is great consistency in meaning and usage of many security labels. Therefore, planning for and acquisition of security label information can proceed while resolution of any residual details is concurrently under way. 14. The DCI establish a requirement that all new Community systems designed or implemented after 1 January 1985 be able to (at least) capture and maintain security labels in association with the related information as it enters the system, and to do so in a way that will facilitate utilizing such security information for eventual full-scope labelling applications in B-1 or equivalent systems. This is simply an extension of [13] to include new, as opposed to presently operational, systems. It must apply to R&D systems which are prototypes of operational systems. In this regard, note the "Background" discussion above [paragraph 3], and recommendation [30]. Jointly, they suggest that B-1 systems incorporating labelling should be available by 1988. Thus the collection of security labelling information in presently operating and soon-to-be-designed systems should begin as soon as possible. If new systems are implemented in less than B-1 equipments, the same concerns for transferability will apply as in recommendation [13] above. 15. The DCI issue or cause to be issued a policy that requires security label integrity throughout communication networks. Label integrity implies that security labels are guaranteed not to have been changed in transit through a communication network, and that the association between a message and its security labels has not been perturbed. It is a matter that needs to be examined, but has been dealt with in only one network (SACDIN). In this regard, however, the Community should transition as soon as possible to communication processors (which handle plain-text material) that have been certified A-1 by the Computer Security Center. 16. The DCI task NSA to issue guidance on the vulnerability of security labels to traffic flow analysis. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 There appears to be no doctrinal position on the matter. Traffic flow analysis of unencrypted security labels in transit through a communications network might prove to be an important vulnerability. Such a circumstance is likely to exist in packet-switched networks; for example, in the Defense Data Network, security labels will be in-the- clear at the node switches which are protected to only SECRET level. It is not apparent whether the issue is one of COMSEC or OPSEC; thus the matter might be appropriate to NSA or to system managers. 17. The DCI support R&D programs to develop automated schemes that can assist in determining classification of information as it is aggregated, disaggregated, or combined. The so-called knowledge-based system is one technique to be examined. Such an approach might be able to mimic the activities of people in making security judgments about information. Background The issue is to equip a computer-based information system with an array of internal record-keeping processes that collectively can be used to do such things as monitor the operational and ongoing security status of the system, conduct a damage assessment in case of a security breach, trace the sequence of events/actions taken by users (personal, process, other system) in case of a security breach, and detect/identify illegal actions by a user or an attempted penetration. The technique is commonly referred to as "audit trails." Like labelling, it is largely a software matter with consequences primarily for the operating system software. Unlike labelling, there are business and industrial needs for systems of audit trails so that the DCI and his system managers can expect some commercial capabilities to be available. Because of the software dominance, the near-term actions are limited to administrative/procedural ones plus exploitation of whatever audit trail capability that the installed critical systems might happen to have. 18. The DCI task system managers to identify and report within 90 days what audit data is now collected, how it is used, what tools for analyzing the data might make audit data more useful, and what audit capability may exist within their systems for potential use, but is not presently used. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Many vendor-supplied operating systems include audit trails for such things as accounting and resource charge-back. We believe that much more relevant activity data is, or could be, collected and exploited in present systems for security assurance purposes. 19. The DCI task system managers to institute procedures for maximally exploiting the audit data which is collected or could be collected; and that he take steps to have appropriate analytic tools and capability provided to the system managers. 20. The DCI task the CIA to take the Community lead for the accountability issue; to assemble working groups as may be necessary to identify technical, operational or policy aspects; to make recommendations to DCI for establishment of new policy; and to conduct a study of the accountability issue. The study should examine such matters as: ? Types of information that can be collected. ? Security relevance of such information. ? Threats against which audit trails can protect. ? Operational requirements. ? Standards for what will be audited. ? Standards for representation of the audit trail. ? Processing standards for audit trails. Development of conventional audit trail techniques. Development of knowledge-based systems for auditing. Development of appropriate work stations for auditors. Development of an on-line auditing capability. Development of mechanisms for the security auditor to control the system when needed. Development of the appropriate operational concepts for the audit trail process (e.g., one- or two-man control). Development of analytic tools for the security officer to examine audit data. The study should develop the required conceptual and technical foundation for a comprehensive set of audit trails, and a requirements statement that can be incorporated into a system specification for Community procurements. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Policy issues that will require attention include: ? The dependence of audit trail details on system aspects. ? One- or two-man control of access to audit trail information. ? The authority of the audit team to intrude on the system operational mission in case of trouble. ? The nature of actions to be taken in case of detected penetration attempts. ? The security audit positions required per system, and the manning profile for the audit team. ? A statement of responsibility and authority for the audit team. Operational details include: ? The operational concept that will assure that audit trails will function as intended in an operational system and provide the security protection expected. ? An examination of the tradeoff between the necessity for ongoing operation of the system in its operational support vs. security actions to be taken in case of security compromise or detection of a penetration. Background Several organizations have sponsored projects to develop a so-called Guard device. It sits astride a communication channel into or out of a computer, and allows only information with specified security labels to pass. It behaves, so to speak, as a security filter. Although the devices were designed for specific applications, it appears that they could be exploited for some security aspects of the critical systems. At least one of them could be available as a commercial product. 21. The DCI have conducted a comprehensive state-of-art survey of the several Guard projects under way or completed. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 The study should examine such details as: ? The availability of operational equipment. ? The flexibility for monitoring different combinations of security labels. ? Any special hardware/software details that such equipments might impose on cooperating computer and communication systems. 22. The DCI task system managers to prepare an implementation plan for the incorporation of Guard (or equivalent) technology into those systems which are serving "subscribers" of different levels of access. A "subscriber" may be an individual, a terminal, or another system. When the level of access is not uniform, Guard technology should be considered a prominent option for security improvement. CERTIFICATION AND ACCREDITATION Background The process of certification is an examination by a technically qualified organization as to the security strength of an intended operational system. The process of accreditation is a statement by the system manager of the operational system that, having compared the mission requirement with the threat against the system and with the findings of the certification, he finds the system qualified to operate with information of specified levels of sensitivity. Based on our collective experience within the Community, we believe that these two processes are quite variable from agency to agency, are applied with different degrees of rigor by different agencies, and lead to circumstances in which systems have never been accredited or are operating under a waiver. 23. The DCI have prepared policy guidelines to improve the quality of system certification and accreditation, plus an apppropriate manual that describes the steps that are necessary in (1) the certification process for a system, and (2) the ensuing accreditation action. The process of examinii.g a system for its security-worthiness, and then contrasting it with the threat and operational need should be a Community-wide standardized process. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 An example of quality improvement would be the "licensing" of organizations that conduct certification so that each would follow the same process, consider the same technical factors, utilize the same procedures, etc. Such a step would be analogous to the situation with TEMPEST testing; many organizations conduct such tests but all do so according to procedures prescribed by NSA. 24. The DCI require recertification and reaccreditation of all systems on a periodic calendar-time interval, or when operational circumstances change substantially. The periodicity of such actions should be related to the development of the threat and also take account of the progress of technology for affording new security safeguards. Moreover, the operational environment of systems will change from time to time. Some changes will have security implications; others will not. For example, adding a few new users or terminals at the same clearance level is not likely to raise a security concern, but adding a new group of users at a different security level or connecting to a new network will. 25. The DCI task each Designated Approving Authority to monitor on a regular basis the security status of systems for which he is cognizant, and to invoke appropriate parts of the certification and/or accreditation process when changes in the operational environment warrant reconsideration of the security posture and practices, or when other circumstances indicate. Judgment will clearly be needed on the part of the DAA; he will have to determine whether changes in the operational environment raise security concerns. "Other circumstances" can include anomalous behavior of the system that might suggest a security vulnerability, the results of deliberate penetration testing, the detection of an attack against the system, or the appearance of a new threat. INFORMATION SHARING Background User groups have proved very effective information transfer mechanisms in the commercial world. Such a group offers a forum in which users with common problems can discuss them and decide on appropriate remedial actions. It should be possible to achieve the same information sharing among Community systems. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 26. The DCI have created under his auspices a "user group" for each of the commonly occurring hardware/software configurations in the critical systems. Such user groups would be able to: ? Compile a "catalog" of systems or places where users might turn for ideas, available software, preferred practices, etc. ? Provide a secure environment in which to exchange ideas/techniques/procedures/etc. that relate to security aspects of their operational systems. In the short run, user groups organized by commonly occurring hardware/software configurations are administratively and jurisdictionally easier to establish; but in the long run, there should exist a Community-wide security forum in which all system managers and operational personnel can exchange information and work toward problem solutions. Background With regard to operating system software (also calleu executive system software), vendors phase out such systems from time to time and will no longer provide ongoing support to them. The DCI must be cautious not to invest in such dead-end software systems. It is likely that some of the operational critical systems already contain them. Similarly, vendors are continuously upgrading both their hardware and system software. Presentations made to us indicate that newer software incorporates security features that could materially improve the situation in the critical systems. 27. The DCI direct that a review be made of all DEC PDP-11 systems running with RSX or IAS software for upward conversion to a VAX with VMS-4 software. If feasible, procurement of the new systems should be expedited on a priority basis. Alternatively, if cost and schedules permit, system managers need not be constrained to the same vendor. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 This is an instance of software which is being abandoned by the vendor who, however, is offering newer systems with significant added security safeguards in the operating system. VMS-4 includes such improvements. 28. The DCI direct that a review be made of all IBM and all Burroughs systems to ascertain the feasibility of using security-enhancing software products available either from the equipment vendors or from independent software vendors. Software products now on the Evaluated Products List of the Computer Security Center or those submitted for evaluation should be considered especially. 29. The DCI direct that the information about security aspects of Wang systems being regularly obtained by the Department of State be circulated on a periodic basis throughout the Community. The Department of State has an established contractor to examine the security risks of Wang equipments and systems as they appear on the market. GENERAL SECURITY UPGRADING Background The Community should point toward a general upgrade of equipment and software as rapidly as such products become available and are evaluated by the Computer Security Center. However, the Community should make known its interests in better security products. Meanwhile, the Center should be tasked to be reponsive to the special needs of the Community. 30. The DCI institute policy that, by 1988, the Community intends to acquire only systems that are certified B-1 or better by the Computer Security Center, and that he make known such policy to vendors. 31. The DCI task the Computer Security Center to review on a priority basis certain software products of especial concern to the Community for its critical systems, e.g., M-204, Inquire, Recon-Guard, KAIS-Guard. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Background Since computer security does not now have a fully developed theoretical foundation, R&D on various technical aspects must be pursued. For example, modelling of security policy is essential and must be supported for a high rate of achievement. The Computer Security Center is the national focal point for coordinating and conducting computer security R&D. The Center sponsors generalized R&D with the understanding that sytem- or agency-specific R&D will be done by the military services or by other agencies, but with the cognizance of the Center. 32. The DCI formally make known all of his needs for computer security R&D to the Computer Security Center, and that he evaluate the Center's program as it relates to his needs. To the extent that it does not meet his needs, he should conduct his own R&D efforts; but assure that they interface and are coordinated with the program of the Center. It is essential that the DCI exploit the achievements of the Center, with regard not only to technical advances but also with regard to policy implications. At the same time, the DCI must be free to conduct his own R&D when the Center can not meet his needs. Conversely, members of the Community may be qualified to carry out a part of the Center's program. Under any circumstances, it is essential that the knowledge and progress of R&D efforts be shared, that the total R&D effort of the Community and the Center be coordinated, and that all participants be mutually informed. Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 STAT Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2 Approved For Release 2009/08/17: CIA-RDP87M00539R000901160028-2