United States Office of Information Environmental Protection Resources Management Agency Washington DC 20406 December 1989 £EPA EPA INFORMATION SECURITY MANUAL ------- Information Security Manual 12/15/89 PREFACE Recently, information security has achieved a new and unfamiliar prominence. In- formation security issues have appeared on the covers of both "Time" and "Business Week" magazines. Congress has emphasized the importance of information secu- rity through its passage of the Computer Security Act of 1987. What this newfound prominence seems to highlight is that we are now truly in the Age of Information. The explosion in personal computing is the latest step in creating this information society. As we have become more dependent on our information re- sources, so have we also become more concerned about what might happen if those resources were lost or misused. At the Environmental Protection Agency (EPA), the Agency information security policy is contained in a formal policy statement. (The policy statement, issued in 1987, is reproduced here as Appendix A.) The policy statement recognizes that information is an Agency asset and that the EPA is highly dependent on its informa- tion resources to carry out program and administrative functions in a timely, efficient, and accountable manner. The policy statement formally establishes a comprehensive, Agency-wide informa- tion security program and describes individual and organizational responsibilities under the program. Two procedural manuals which explain to EPA managers and staff how to comply with these responsibilities have now been developed. This is one of the two manuals and it deals comprehensively with all types of infor- mation assets (paper records, mainframes and minicomputers, information sys- tems, PCs, and word processors). The other manual deals exclusively with PC security. Because PC security affects the most employees and is a relatively new area of security vulnerability, it is important to handle it separately so that the PC procedures will be accessible and will not get lost in discussions of mainframe or software development security. Each manual begins with similar introductory sections. Information security and in- formation sensitivity are defined in terms of the three objectives of the EPA program, which are to maintain information availability, integrity, and confidentiality. The in- formation security problem is then described in terms of threats to the objectives. ------- Information Security Manual 12/15/89 Each manual is structured to allow the reader, whether manager or staff member, to tailor it to his/her own particular security situation by completing one or two work- sheets and by reading selected portions of the text. Specifically, each reader works through a sensitivity evaluation table to determine if he/she has sensitive informa- tion. If not, only minimal security controls need to be implemented. If the reader does have sensitive information, he/she uses a worksheet to identify why the information is sensitive and which of the three security objectives are relevant. The reader is then referred to later sections of the manual as appropriate. For example, there is a subsection on safeguards for maintaining the availability of critical PC ap- plications and a subsection on safeguards for preserving the confidentiality of confidential paper records. Because a common problem in information security is determining exactly who is re- sponsible for what aspects of security, each manual devotes a chapter to information security roles and responsibilities. While the manuals are as user friendly as pos- sible in explaining to readers howto fulfill those responsibilities, they are not painless. To ensure that information resources are adequately protected, they describe three different control processes. The processes establish a structure of security checks and balances by approaching security both from an equipment perspective and from an application or information system perspective. ------- Information Security Manual 12/15/89 TABLE OF CONTENTS Section Page 1. GENERAL INFORMATION 1-1 2. INFORMATION SECURITY ROLES AND RESPONSIBILITIES 2-1 3. MINIMAL SECURITY CONTROLS FOR MINICOMPUTER/MAINFRAME INSTALLATIONS, PCs, PC LANS, AND WORD PROCESSORS 3-1 4. DETERMINING THE NEED FOR ADDITIONAL CONTROLS 4-1 5. PERSONNEL SECURITY AND TRAINING 5-1 6. SECURITY FOR MINICOMPUTER AND MAINFRAME INSTALLATIONS 6-1 7. SECURITY FOR PERSONAL COMPUTERS AND PC LANs 7-1 8. SECURITY FOR WORD PROCESSORS 8-1 9. SECURITY FOR APPLICATION SYSTEM DEVELOPMENT, OPERATIONS AND MAINTENANCE 9-1 10. SECURITY FOR PAPER RECORDS 10-1 APPENDIX A: POLICY A-1 APPENDIX B: APPLICATION RISK ANALYSIS AND APPLICATION CERTIFICATION B-1 APPENDIX C: INSTALLATION RISK ANALYSIS C-1 APPENDIX D: DISASTER RECOVERY AND CONTINUITY OF OPERATIONS PLANS D-1 in ------- Information Security Manual 12/15/89 1. GENERAL INFORMATION 1.1 PURPOSE, SCOPE, AND APPLICABILITY In accordance with the Agency's Information Security Policy, this manual estab- lishes security procedures for safeguarding Agency information resources and provides overall guidance to EPA managers and staff in implementing those procedures. The security controls specified in this manual are designed to ensure that information resources are adequately protected and that EPA organizations and staff are in compliance with all requirements of the policy. As used in this manual, information resource (or information asset) is a broad term. It includes automated information systems, computerized data bases, computer programs, collections of paper records, information on microfiche or microfilm, and computer installations. Consistent with the Information Security Policy, this manual applies to a! EPA or- ganizations and their employees. It also applies to the personnel of agents (including contractors and grantees) of the EPA who are involved in designing, developing, operating, or maintaining Agency information and information systems. The specific purposes of this manual are as follows: To save organizations money by ensuring that only focused, cost- effective security safeguards (or controls) are implemented To protect organizations and individuals from the embarrassment of an unauthorized disclosure or from the disruption that would result if critical information were destroyed To help organizations meet internal control review requirements by providing them with a sound basis for assuring that automated information systems are adequately protected To assist staff in developing the system documentation required by the "EPA System Design and Development Guidance" To enable organizations to successfully undergo any security audits that may be conducted by the Office of the Inspector General. 1-1 ------- Information Security Manual 12/15/89 1.2 INTRODUCTION TO THE EPA INFORMATION SECURITY PROGRAM Through the Information Security Policy, the EPA has established a comprehensive, Agency-wide information security program to adequately safeguard the Agency's in- formation resources. (The policy, which is Chapter 8 of the EPA's "Information Resources Management Policy Manual," is reproduced here as Appendix A.) The concept of adequacy means that security controls should be neither overapplied nor underapplied. Overapplication wastes financial and ADP resources, and underap- plication exposes the information to various security threats. The policy categorizes information and applications (or systems) as either sensitive or not sensitive. Sensitive information means information that requires protection due to the loss or harm that could result from inadvertent or deliberate disclosure, al- teration, ordestruction of the information. Examples of sensitive information include Confidential Business Information (CBI), Privacy Act Information, and data critical to the performance of primary Agency missions. A sensitive application is an applica- tion that processes sensitive information or an application that requires protection because of the loss or harm that could result from the improper operation or deliberate manipulation of the application itself. In short, information security involves the precautions taken to protect sensitive in- formation resources from potential loss and misuse. The three major objectives of the EPA program, as illustrated in Exhibit 1-1, are to maintain: Information Availability Information Integrity Information Confidentiality The availability objective is associated with information where the loss of the infor- mation would cause serious problems, either because it would be costly to replace the information or because it would be difficult to function without the information. Thus, availability involves both the dollar value and the time value (or criticality) of the information. An example of an Agency information system or application where availability is important is the Resource Conservation and Recovery Information System (RCRIS). The integrity objective is associated with information or applications where accuracy 1-2 ------- Information Security Manual 12/15/89 EXHIBIT 1-1 INFORMATION SECURITY OBJECTIVES Prevent Information Loss Prevent Information Corruption Prevent Information Disclosure 1-3 ------- Information Security Manual 12/15/89 and reliability are of particular concern. In short, integrity is concerned with protecting information from corruption. An example of an Agency information system where in- tegrity is important is the Integrated Financial Management System (IFMS). The confidentiality objective is concerned with information where disclosure would be undesirable or unlawful. Examples of information of this type include Toxic Substances Control Act (TSCA) CBI or personnel files. As Exhibit 1-1 indicates, a particular application could involve only one objective or could involve some combination of objectives. For example, a data base could contain information critical to a primary Agency mission and yet contain no confiden- tial information. In other words, while the availability objective is key, confidential- ity is not a factor and the information in the data base could be widely disseminated without any damage resulting from disclosure. On the other hand, anotherdata base could be both critical and confidential. 1.3 THE INFORMATION SECURITY PROBLEM The EPA is highly dependent on its information resources to carry out program and administrative functions in a timely, efficient, and accountable manner. For example, the Agency relies on its information collection authority under various enabling statutes to fulfill its environmental missions. The willingness of the regu- lated community and state and local agencies to supply requested information in a cooperative and timely fashion depends on their confidence that the information will be adequately protected. The nature of the information security problem is illustrated in Exhibit 1-2. A wide range of intentional or unintentional events can threaten Agency information resources. These threats include: External and environmental threats, such as fire, waterdamage, or power failure Hardware and software error, such as disk or operating system failure for automated information systems Operations/procedural error, such as accidental modification or destruc- tion of data Malicious actions, such as theft or data sabotage. 1-4 ------- Information Security Manual 12/15/89 EXHIBIT 1-2 THE SECURITY PROBLEM Environmental Threats Hardware & Software Errors Malicious Actions \ lp 'ersonnel jijil Controls -^V i>X Software X4i| rJrV &Data MT^T WM, Controls rVr1 X <*' v ;;l x- ^ -,,,, // '">*', , ,y , ' , '"-, '' ' ', INF PLJI^ Equipment 4jM TV & Physical S? ptt Controls 44 ORMATION g Administrative S g Controls g RESOURCES Programs Data Equipment ' ' ' - '-y1- ^L-i 1-5 ------- Information Security Manual 12/15/89 How vulnerable a particular information resource is to these threats depends on two basic factors. The first is the type or nature of information involved, that is, the relevance of each of the three security objectives. The second factor is the environ- ment in which the information asset is used, for example, is a PC stand-alone or part of a network. Information security involves identifying threats and applying controls to prevent threats from being realized. When threats are realized (for example, dis- closure or damage/loss of information), the three security objectives are not achieved. 1.4 STRUCTURE OF THIS MANUAL Security manuals are typically organized by type of security and include chapters on physical security, data security, and communications security. While such manuals provide good technical discussions of security controls, they typically overwhelm the reader with a hodgepodge of safeguards that leave him/her unclear about exactly which safeguards should be implemented. In addition, these manuals provide little overall implementation guidance. This manual is structured in a completely different manner. It is organized to allow each reader, whether manager or staff member, to tailor it to his/her own particular security situation. In a very real sense, the manual allows each reader to work through his/her security problem by completing one or two worksheets and by reading selected portions of the text. Following the introductory material presented in this first section, Section 2 ad- dresses individual and organizational information security responsibilities and is to be read by all EPA managers and staff. Because it is not easy to coordinate the diverse elements of an information security program, Section 2 recommends that one management official, the Senior Information Resources Management Official (SIRMO), be the focal point for information security in each major organizational unit. Section 3 describes minimal security controls to be used regardless of the type of information involved. Section 3 should also be read by all EPA managers and staff. Section 4 is the last section that needs to be read by all managers and staff. Section 4 analyzes the need for additional security controls by determining whether or not the reader has a sensitive information asset. Based on the Section 4 determination, the 1-6 ------- Information Security Manual 12/15/89 reader is referred to later sections of the manual as appropriate. 1.5 RELATIONSHIP TO OTHER SECURITY PROCEDURES In this manual, the Office of Information Resources Management (OIRM) is estab- lishing overall, Agency-wide security procedures for safeguarding EPA information resources. Other EPA organizations have developed specialized procedures in particular information security areas. As an important example, the National Data Processing Division (NDPD) in Research Triangle Park issues technical policies concerning systems (for example, Prime or VAX) supported and approved by it. These policies are contained in the "NDPD Operational Policies Manual." In addition, EPA organizations with statutory authority for certain types of information (for example, the Office of Toxic Substances for TSCA CBI) issue security proce- dures dealing exclusively with a certain type of information. Nothing contained in this manual is intended to contradict or replace the specialized security procedures of these other organizations. Those specialized procedures supplement the core procedures presented in this manual. EPA organizations that issue such procedures must ensure that they are consistent with this manual. EPA employees must make sure they adhere to all such specialized procedures, as well as to the procedures presented in this manual. 1-7 ------- Information Security Manual 12/15/89 2. INFORMATION SECURITY ROLES AND RESPONSIBILITIES 2.1 BACKGROUND Information security involves much more than technical hardware and software issues. Above all, a successful information security program needs strong organ- izational and administrative controls. Administrative/managerial factors such as top management support and employee awareness contribute significantly to program success. An information security program needs to involve all employees and to be a part of the day-to-day operations of an organization. Because of these factors, the Information Security Policy assigns information secu- rity responsibilities to top management, to supervisors, and to employees. This manual is intended to explain to EPA managers and staff how to comply with these responsibilities without burdening programs and individuals. The remainder of this section describes a suggested overall framework for implementing the Information Security Policy. The framework of security roles set forth in this section is not mandatory. While programs must meet the requirements of the Information Security Policy, they may find they are able to do so by creating somewhat different roles than those defined here. OIRM recognizes that programs may need to modify the framework to meet unique program needs. The framework is not meant to be inflexible and bureau- cratic; instead, its intent is to assist programs and individuals in implementing adequate protection of sensitive information. 2.2 INFORMATION SECURITY ROLES: AN INTRODUCTION A common problem in information security is determining exactly who is responsible for what aspects of security. In determining accountability for information security, it is extremely useful to start with a framework of owner/user/custodian. Throughout this manual, security actions are cast in terms of this framework, while oversight and coordinating actions are the responsibility of management. The framework is described in detail in the next subsection. 2-1 ------- Information Security Manual 12/15/89 It is important to recognize that there may not always be a one-to-one correspon- dence between individuals and roles. In other words, at times it may be more efficient to have several individuals share the responsibilities of a role. Again, the framework described here is meant to be a flexible implementation tool. 2.2.1 Owners. Users, and Custodians These three roles are defined as follows: Application (or Information) Owner: The owner of the information is the individual or organization who creates and sponsors it. Ownership in- volves authority and responsibility forthe information, either in a program- matic or administrative sense. For example, the Office of Solid Waste and Emergency Response is the owner of RCRIS. The Office of Administra- tion and Resources Management is the owner of IFMS. The owner determines the sensitivity of the application (or information system), assigns custody of the application, and decides who will be allowed to use the application. Consulting with the custodian as appropriate, the owner specifies and approves security controls and ensures that the application is protected on an ongoing basis. The owneralso determines backup and availability requirements and communicates them to the custodian. Application (or Information) User: Users are individuals who are author- ized by the owner to access an application or collection of information. Custodian: Custodians possess (or have physical custody of) ADP equip- ment or the files housing paper records. For example, for PCs and word processors (WPs), the custodian is the individual to whom the PC or WP is assigned, that is, the person responsible for the equipment in the property management sense. In the minicomputer or mainframe environ- ment, custodians are typically suppliers of information services who possess, store, process, and transmit the information. For certain major applications, the custodial role is shared by OIRM and the National Computer Center (NCC). In these cases, OIRM acts as a "software custodian," that is, OIRM acts as a custodian of the files, databases, libraries, and programs that are stored and processed at NCC. These roles are not always discrete; the owner can be the principal user and cus- todian of the information. For example, an individual who develops an end-user ap- plication for stand-alone processing on his or her own PC is at once the PC custodian, application owner, and application user. 2.2.2 The SIRMO as Focal Point Because information security covers a variety of information resources and involves 2-2 ------- Information Security Manual 12/15/89 so many different employees and supervisors, it is important to have one manage- ment official in each major organizational unit coordinate the security program for that organization. This individual will serve as a security focal point by identifying all owners, custodians, and users, and by disseminating security-related information throughout the organization. While each Primary Organization Head (as defined in the policy statement) may designate whomever he/she wishes for this coordinating role, the SIRMO is strongly recommended for this function. The designate may delegate portions of this security function (for example, identifying owners) to other knowledgeable individuals in the organization, as long as the Primary Organization Head approves and as long as the coordinating role is retained. 2.2.3 Managerial and Administrative Roles In addition to owners, users, custodians, and SIRMOs, the implementation of the se- curity procedures in this manual also requires the involvement of several other individuals in eight different roles. The first six of these roles exist at present while the remaining two are unique to the security program. The eight roles are: Primary Organization Head First-line supervisors PC Site Coordinators Records Management Officer (paper and microform) Systems Analyst/Application Programmer Local Area Network (LAN) System Administrator Certifying Official: A management official(s) appointed by the Primary Or- ganization Head. This official certifies that the security safeguards in place for each sensitive application are adequate. Minicomputer/Mainframe Security Officer: An official(s) appointed by the Primary Organization Head to be responsible for security at the organiza- tion's own on-site computer processing installation(s). The term computer installation covers the range of computer processing capabilities from large scale service center support for multiple users (such as NCC) down to smaller general purpose systems for multiple users or dedicated use (such as Prime or VAX systems). The term does not include personal computer installations. 2-3 ------- Information Security Manual 12/15/89 2.2.4 Tying Roles to Information Assets It is important to recognize that not all roles apply to all types of information assets. Clearly, the role of Minicomputer/Mainframe Security Officer does not apply to PCs and a PC site coordinator is not relevant for paper record systems. Table 2-1 ties roles to the various types of assets. 2.3 ASSIGNING RESPONSIBILITIES TO THE SECURITY ROLES: IMPLEMENTING INFORMATION SECURITY Ensuring that information resources are adequately protected involves three differ- ent management control processes. First, basic common-sense security measures need to be implemented for ADP equipment, regardless of whether or not it processes sensitive information. Second, an application certification process must be established to determine the sensitivity of each automated application and to certify that the security safeguards for each sensitive automated application are ade- quate. Third, an installation risk analysis process needs to be established to make sure that the security measures in place at the installation adequately protect the sensitive automated applications stored and processed there. Note that the second and third processes establish a structure of security checks and balances. They approach information security both from an installation or equipment perspective and from an application (or information system) perspective. Each of the three management control processes is described in more detail below. Table 2-2 lays out the security responsibilities associated with the processes on a role-by-role basis. 2.3.1 Minimal Controls Section 3 describes the safeguards that need to be in place to ensure the basic physical and environmental protection of ADP equipment and magnetic media. Section 3 also sets forth administrative procedures governing the use of computers and commercial software. Minimal controls for PCs and word processors are imple- mented by custodians or users as appropriate, with oversight provided by the cognizant PC site coordinator. Minimal controls for minicomputer/mainframe instal- lations are implemented by the Minicomputer/Mainframe Security Officer. 2-4 ------- Information Security Manual 12/15/89 TABLE 2-1 TYING SECURITY ROLES TO INFORMATION ASSETS Primary Organization Head SIRMO Owner PC/WP Custodian Mini/Mainframe Security Officer User Supervisor PC Site Coordinators Certifying Officer LAN Administrator Records Management Officer Application Programmer/ Systems Analyst Information Resource or Asset Mini/ Mainframe Installation PC WP Paper/ Software Microform Development/ Records Maintenance 2-5 ------- Information Security Manual 12/15/89 TABLE 2-2 IMPLEMENTING A MANAGEMENT CONTROL PROCESS FOR INFORMATION SECURITY: RESPONSIBILITIES BY ROLE Role Primary Organization Head SIRMO Application (or Information System Owner) PC/Word Processor Custodian Minicomputer/Mainframe Security Officer Application (or Information System) User Supervisor PC Site Coordinator Certifying Officer LAN System Administrator Records Management Officer Applications Programmer/Systems Analyst Responsibilities Implements the organization-wide security pro- gram. Designates Certifying Officer(s). Assigns a person the responsibility for information security at each installation. Coordinates the organization-wide security program. Identifies owners, users, and custodians. Determines information sensitivity. Assigns cus- tody. Initiates application certification process. Authorizes users. Specifies and approves security controls. Specifies backup and avail- ability requirements. Makes sure users and custodian adhere to security requirements. Responsible for the security of his/her equip- ment. Must implement minimal controls. Performs risk analysis. Responsible for the security of the equipment at the installation. Implements minimal controls. Performs risk analysis. Establishes disaster recovery/continuity of operations plan. Assists owner in selecting controls during system development/operation. Adheres to security requirements of owner. Reviews application certification form. Ensures employees fully comply with information security responsibilities. Ensures minimal controls are in place. Advises owner on application certification process. Certifies sensitive applications. Advises owner on application certification process. Coordinates the selection of security safe- guards for networks. Responsible for ensuring that controls are in place for his/her "manual" record systems. Incorporates controls into software. Coordinates selection of safeguards with owner and custodian. 2-6 ------- Information Security Manual 12/15/89 2.3.2 Sensitivity Determination. Automated Application Risk Analysis, and Automated Application Certification The requirements of the certification process, including the completion of the Appli- cation Certification Worksheet, are described in detail in Appendix B. Key elements of the process are summarized below: Each Primary Organization Head will designate one or more Certifying Of- ficials for his/her organization. Each application/information owner will determine the sensitivity of each of his/her applications or collections of information. This determination will be made in accordance with the instructions set forth in Section 4 of this manual. Each sensitive automated application must undergo initial certification and then review or audit leading to re-certification every three years. The certification or recertification process will begin with the application owner's completion of the Application Certification Worksheet. The work- sheet will capture basic information on application sensitivity, security specifications, design reviews, and tests of security safeguards. When the worksheet is complete, it will be forwarded through the owner's immediate supervisorto the cognizant Certifying Official for approval/dis- approval. The worksheet will be used by the application owner to communicate the sensitivity of the application and the required security procedures to the users of the application. It should be noted that in developing the worksheet, the owner performs a qualitative risk analysis, that is, the owner assesses the relative vulnera- bilities and threats to the application and then specifies safeguards. 2.3.3 Installation Risk Analysis Process All Agency installations, including PCs and word processors, are requiredto undergo a risk analysis. A risk analysis is a means of measuring and assessing the relative vulnerabilities and threats to an installation. Its purpose is to determine how security safeguards can be effectively applied to minimize potential loss. In everyday terms, risk analysis is a procedure for identifying what could go wrong, how likely it is that things could go wrong, and what can be done to prevent them from going wrong. There are two accepted methods for performing a risk analysis quantitative and 2-7 ------- Information Security Manual 12/15/89 qualitative. For all Agency installations, a qualitative risk analysis approach may be used. Simply put, this method handles typical situations quickly and efficiently by combining the analysis of risks with safeguard selection. It consists of the following basic components: Determine what information is sensitive and non-sensitive. This determi- nation will be made in accordance with the instructions set forth in Section 4 of this manual. If the installation does not process any sensitive information, the risk analysis is at an end and only minimal controls need to be implemented. If the installation does process sensitive information, categorize the sensitive information, for example, "confidential" sensitive. For each category of sensitive information, determine the level of sensi- tivity, for example, highly confidential. Decide on an overall set of safeguards or security controls to use. Tie subsetsof those safeguardstoparticularcategories of information and to levels of sensitivity. Implementation of a PC or word processor installation risk analysis is the responsi- bility of the custodian. Implementation of a minicomputer/mainframe installation risk analysis is the responsibility of that installation's Security Officer. By working through this manual, an informal and qualitative risk analysis will be performed. The custodian or Security Officer need only adhere to the procedures presented in this document and complete the Risk Analysis Worksheet described in Appendix C. No special analytical process has to be undertaken. Under certain circumstances, PC custodians and Security Officers may feel that more rigorous, quantitative methods are warranted. OIRM does not wish to prohibit quantitative analyses. Interested individuals should reviewthe last section of Appen- dix C for more information. 2.4 STREAMLINING THE IMPLEMENTATION OF INFORMATION SECURITY In establishing these management control processes, OIRM wants to achieve ade- quate security throughout the Agency without unduly burdening programs and indi- viduals. To that end, organizations may find that the following can help streamline the management control processes discussed above: In some organizations, one individual (or a handful of individuals) may be knowledgeable enough about an information asset (forexample, PCs and 2-8 ------- Information Security Manual 12/15/89 the information contained on them) to function as a composite or aggre- gate owner, user, and custodian for the asset. In other words, the individual has the requisite knowledge to complete the organization's Application Certification and Risk Analysis Worksheets, not just the work- sheets for his/her own hardware and applications. This aggregated approach is consistent with the owner/user/custodian framework and is an acceptable approach to achieving compliance. In identifying applications for sensitivity determination and certification, in- dividuals/organizations may find that some applications are subsystems or "children" of larger "mother" applications. Similarly, some applications may be so related that the boundaries between them are fuzzy and that for the purposes of this document they can be thought of as one. In implementing the certification process, such sensitive applications may be combined into a single sensitive application. A key test of whether or not a sensitive application has been properly delineated is whether or not the questions on the certification worksheet can be meaningfully an- swered. If the responses are full of exceptions and two-part answers, the aggregation is probably incorrect. 2.5 ORGANIZATIONAL SECURITY REPORT To tie together the diverse elements of its information security program, each major organizational unit (corresponding to each Primary Organization Head) will prepare an annual security report. In establishing this reporting requirement, OIRM wants to make sure organizations are implementing and maintaining security safeguards; OIRM does not want to bog organizations down in atime-consuming paper exercise. To that end, the report will be a compilation of the worksheets and documents prepared during the day-to-day implementation of each organization's security program. Specifically, the report should contain the following: A listing of all sensitive automated information systems in the organization Copies of Application Certification Worksheets and Installation Risk Analysis Worksheets prepared in the organization within the past year Copies of installation disaster recovery/continuity of operations plans or quantitative installation risk analyses prepared or updated in the last year Copies of any local security procedures developed in the last year A statement, signed by the SIRMO, that all employees in the organization 2-9 ------- Information Security Manual 12/15/89 have completed basic security awareness training (per Section 5.5) Descriptions of any security concerns or weaknesses that the organiza- tion may wish to discuss. This could include weaknesses identified as part of audits, vulnerability assessments, or other internal control review processes. The security report should be sent by the end of each calendar year to the Director, OIRM. The first report will be due at the end of 1990. The report will provide OIRM with evidence of compliance with the security program. 2.6 SECURITY PLANS The Computer Security Act of 1987 required the EPA to prepare security plans for certain of its applications and computer processing installations. The purpose of the security plan was to provide a basic overview of the security requirements of the subject application or installation and EPA's plan for meeting those requirements. The plan was not intended to be a detailed technical description of risks or security mechanisms. The plans were a new reporting requirement for agencies; they were not designed to replace such existing processes as application certification. Completed security plans were submitted in FY 1989 to the National Institute of Standards and Technology (NIST) (formerly the National Bureau of Standards) and to the National Security Agency (NSA) for comment and review. Requirements for FY 1990 and beyond have not yet been determined by NIST, NSA or the Office of Management and Budget. Organizations will be informed of any reporting require- ments under separate cover. 2-10 ------- Information Security Manual 12/15/89 3. MINIMAL SECURITY CONTROLS FOR MINICOMPUTER/MAINFRAME INSTALLATIONS, PCs, PC LANs, AND WORD PROCESSORS 3.1 INTRODUCTION This section applies to all individuals with security responsibilities for minicomputer/ mainframe installations, PCs, or word processors (such as PC users, PC custodians, LAN Administrators, or Computer Installation Security Officers). This section does not apply to individuals with security responsibilities for paper records or for applica- tion system development. Because there are no minimal security controls associ- ated with paper records or application system development, individuals responsible only for these types of assets should skip to Section 4. The purposes of this section are: (1) to describe the security measures that need to be taken to ensure the basic physical and environmental protection of ADP equipment and magnetic media, and (2) to set forth administrative procedures governing the use of computers and commercial software. All measures described in this section can be implemented at little or no cost, ensuring their overall cost- effectiveness. The emphasis here is on common-sense measures that are justified without a risk analysis. Section 3.2 below deals with PCs and word processors; Section 3.3 addresses minimal controls for minicomputer/mainframe installations. 3.2 MINIMAL CONTROLS FOR PCs, PC LANS, AND WORD PROCESSORS The responsibility for making sure these controls are in place rests with custodians or users as indicated below. Cognizant PC site coordinators should ensure compli- ance with these requirements through periodic, informal inspections. 3.2.1 Physical Controls Agency physical security procedures issued by the Facilities Management and Services Division (FMSD) state that: "All office equipment...should be locked up when not in use...Cables and anchor pads can be used to secure typewriters, calculators, computer peripherals, and the like. See SCR 1-08 for information about locking de- vices." (Directives Volume 4850-1, SCR 1-06, page 7) 3-1 ------- Information Security Manual 12/15/89 Consistent with these procedures, the following controls for PCs and word proces- sors are required to prevent theft and physical damage. Custodians are responsible for ensuring that these controls are in place. Locate equipment away from heavily traveled and easily accessible areas to the extent possible. When possible, install the device in a locked room, making sure the lock is used whenever the room is unoccupied (and not just at night). If the device cannot be installed in a locked room, a locking device such as a locking anchor pad or hardened cables can be used. For further informa- tion or assistance, contact the Security Management Section of FMSD. All IBM PC/AT and most compatible microcomputers are delivered with standard system locks which prevent the system from being operated and prevent the cover from being removed, guarding against component theft. Use these locks. When adding valuable expansion boards (such as additional memory or graphics interfaces) to PCs that do not have factory- installed locks, install a cover lock. Place equipment and peripherals on stable and secure platforms away from objects that could fall on them. Portable PCs require additional security considerations because their portability increases their vulnerability to theft. In addition to the physical security measurers already mentioned, store all portable PCs in a locked cabinet when not in use. For further information or assistance, contact the Security Management Section of FMSD. Assign a person to track the location of the portable PCs on a regular basis, log them out for use to authorized users, and ensure the portable PCs have been returned to the locked storage area when not in use. Moreover, any employee removing a portable PC from an EPA building for official use must have a property pass. 3.2.2 Environmental Controls Custodians are responsible for ensuring that the following controls are in place: PCs and word processors are sensitive to surges in electrical power. To provide protection against current surges, install a surge protection device. Good quality, multi-stage surge protectors are available for under $100. Do not install the device in direct sunlight or in a location with extremes of hot and cold temperatures (less than 50 degrees Fahrenheit or greater than 100 degrees Fahrenheit). Do not leave a portable PC in a parked car, which would also subject it to temperature extremes. 3-2 ------- Information Security Manual 12/15/89 Equipment (and media) are sensitive to contamination from dirt, smoke, or magnetic fields. Do not eat or drink in the immediate vicinity of the equipment and media. In accordance with the Agency's smoking policy, do not smoke in the vicinity of the equipment. (Smoke is drawn into the vents and through the disk units, covering the units with tar. Tar reduces the life of the disk and the read head.) To avoid problems from dust and possible overhead water leaks, protect equipment with inexpensive plastic covers when not in use. Install the equipment as far as practical from overhead water pipes or sprinkler heads. Control static electrical charges by placing antistatic mats under the equipment or workstation or by using antistatic sprays. (Laundry fabric softeners containing antistatic ingredients can be used for this purpose and they are quite inexpensive when compared to special purpose antistatic sprays.) Because the problem of static electricity is increased when the air is extremely dry, it can be reduced by the use of humidifiers if these are available. 3.2.3 Magnetic Media Controls At present, virtually all information on microsystems is stored on magnetic media in the following forms: Diskettes Fixed disks inside the computer Cartridge tapes Removable disk cartridges (for example, Bernoulli cartridges). PC and word processor users need to treat the magnetic media with special care. Flexible diskettes are especially susceptible to damage. Keep all magnetic media away from all electrical devices and magnets to avoid magnetic fields. This includes magnetic paper clip holders, building passes or credit cards with magnetized strips, PC hard drive units, and telephones. For example, if a diskette is left on a desk and a telephone is placed over the diskette, data on the diskette may be destroyed when the telephone rings. Do not flex diskettes. Bending the media can damage its delicate surface and destroy data. Store diskettes in their jackets as soon as they are removed from the equipment. The jackets are made of a special material that is intended to 3-3 ------- Information Security Manual 12/15/89 protect the diskette. Cartridge tapes and removable disk cartridges should also be stored in their original containers. Never touch the surface of the diskette platter. Do not write on a diskette with a pencil or hard-tipped pen. Useonlyasoft- tipped marker. Keep diskettes in a disk file container when not in use. Dust and other par- ticulate materials can scratch and damage the disk. To prevent permanent loss of data on the fixed disk drive, all files need to be backed up and the heads need to be parked before a PC is moved. Some portable PCs also may require that the heads be parked and/or a disk inserted into the disk drive when transporting the portable. 3.2.4 Backups When it comes to making backups of data and programs, it unfortunately seems that experience is the best teacher. A user often needs to lose an important file before he/she realizes the importance of backup. For certain types of applications (discussed later in Sections 4 and 6), routine and systematic backups are of particular importance and this manual sets forth specific backup procedures. As a minimal control, however, users should be in the habit of regularly backing up their work. While a precise set of criteria for determining how often to make these backups cannot be provided, how active the data file is and how long it took to create are key factors to consider. The appropriate backup media can vary and can include floppy disks, cartridge tapes, removable disk cartridges, or remote hosts such as minicomputers. Users should note that if they are using their PC as a terminal for processing data and programs stored at another site (such as a minicomputer, LAN file server, or mainframe facility like the National Computer Center), that site may already be backing up the data on a regular basis. Consult the manager of the remote facility or the LAN System Administrator for information. 3.2.5 Software Copyrights/Licenses and Master Copies Owners and users who purchase commercial software must follow the procedures below. Supervisors are responsible for ensuring that their employees adhere to these procedures. 3-4 ------- Information Security Manual 12/15/89 Commercial software is typically under copyright and accompanied by a licensing agreement which specifies whether copies may be made. EPA employees must adhere to these licensing agreements; unauthorized duplication of software is strictly prohibited and is not condoned by the Agency under any circumstances. A copyright means that any duplicat- ing, selling, or other distribution of the software for other than backup use by the lawful user(s) is a crime. Willful violations of U.S. copyright law can result in significant penalties (civil damages of up to $50,000 in addition to actual damages plus criminal penalties of up to one year in jail and/or a $10,000 fine). In general, there are two types of licensessingle-machine and site. A single-machine license allows the user to install the master copy of the software on his/her machine only. With a site license, the software may be installed on more than one machine, typically for a higher fee. Software purchased by EPA must be used exclusively on PCs and word processors owned by EPA. Software licensing agreements should be signed upon receipt and imme- diately filed with the vendor. A copy of the agreement containing the registration number should be filed in a safe place. Returning the agree- ment to the vendor will register the purchase and may result in free user assistance, free or reduced price software upgrades, and other advan- tages. Registration of the software will also provide the basis for getting assistance from the manufacturer if the software is lost, stolen, or damaged. Existing OIRM procedures concerning master copies of software state that each Primary Organization Head needs to establish a central reposi- tory for the organization's master copies to ensure accountability and control. The Washington Information Center (WIC) can be used for this purpose if an organization executes an Operational Service Agreement for Archiving of PC Software. 3.2.6 Unauthorized Use of Personal Computers. Word Processors, and Associated Software EPA PCs, word processors, and associated software are for official EPA business only. Use of these devices is not allowed for personal business of any kind, even if it is done on the employee's own time. Appropriation of EPA-owned software for personal use, whether done by unauthorized copying or by actual removal of the master software, is prohibited. Training and practice on EPA PCs and word processors should be done using work-related examples. Employees who use this equipment for other than official Agency business are subject to disciplinary action ranging from a reprimand to dismissal. 3-5 ------- Information Security Manual 12/15/89 3.2.7 Non-EPA Software and Viruses Computer viruses have received a great deal of attention in the press. While some of the coverage is sensational, it is clear that the problem is real and that risk does exist. The threat of viruses has made the need for regular backups (per Section 3.2.4) even greater. In general, a computer virus is an extra program hidden within an apparently normal program or software package referred to as the virus "host" or 'Trojan Horse". Like a biological virus, the computer virus has two important characteristics it can replicate itself and it can cause harm or mischief. This replicating ability means that a virus can quickly spread via shared diskettes, networks, electronic bulletin boards, or file servers as programs or files are stored, executed, uploaded, or downloaded. Potentially infected host software includes operating system tools such as an editor or file utility, data base management software, or spreadsheet macro languages. Some viruses are relatively harmless and only flash a message on the monitor before destroying themselves. Others are truly malicious and modify or destroy programs and data. To detect and combat viruses, a number of specialized programs or software "vaccines" have been developed. Because various computer viruses op- erate in different ways, no single vaccine is currently effective against all of them. Indeed, some of the vaccines have harbored viruses themselves. Under these circumstances, it is not possible to develop a set of generic, straightfor- ward procedures to ensure the integrity of non-EPA or public domain software. Consequently, EPA employees should not install non-EPA or public domain soft- ware on theircomputers without the express approval of their SIRMOortheSIRMO's designate. In addition, EPA employees and contractors who use PCs or LANs supported and approved by NDPD are also subject to virus prevention policies set forth in the "NDPD Operational Policies Manual." Those policies include recom- mendations related to new software, backups, and regular checks for program/file size changes. Readers may also wish to consultthe additional guidance presented in NIST Special Publication 500-166, entitled "Computer Viruses and Related Threats: A Manage- ment Guide." The publication, which was issued in August 1989, provides general guidance for managing the threats of computer viruses and unauthorized use. It deals with different computing configurations such as multi-user systems, personal 3-6 ------- Information Security Manual 12/15/89 computers, and networks. A copy is available in the EPA Headquarters Library or through the Government Printing Office. 3.3 MINIMAL CONTROLS FOR MINICOMPUTER/MAINFRAME INSTALLATIONS Computer Installation Security Officers are responsible for making sure the following controls are in place. 3.3.1 Physical Controls Locate computer installations away from heavily traveled and easily ac- cessible areas, and away from potential sources of explosions (such as boiler rooms, laboratories, or hot water heaters). When choosing a site, take advantage of existing physical security. Avoid locating installations on the ground floor, where an intruder is more likely. Install locks on doors and windows. Make sure the lock is used whenever the room is unoccupied (and not just at night). Limit the number of entrances to the installation to those needed for effective, efficient operations. 3.3.2 Environmental Controls When possible, locate master power switches near emergency exits. The switch should cut all power to the computer system and should also turn off the air conditioning system if it is not designed to filter out smoke. Make sure these master switches are clearly labeled to avoid an accidental power shut-down. Mount hand-held fire extinguishers in visible, accessible areas. Usetypes that will not damage computer equipment, that is, do not use extinguishers that emit water or powder. Install smoke and heat detectors. Avoid installing the computer room underneath water pipes or steam pipes. If this is not possible, use water sensors to detect water seepage. Store waterproof plastic in a visible, accessible location so that it can be draped over equipment in the event of an emergency. Computer equipment (and media) are sensitive to contamination from dirt, 3-7 ------- Information Security Manual 12/15/89 dust, and smoke. Prohibit eating, drinking, and smoking in the computer room. To cut down on dust, avoid coat racks, throw rugs, Venetian blinds, and other furnishings that collect dust and static electricity. Vacuum carpeted areas frequently. Control static electrical charges by using antistatic carpeting or sprays. Laundry fabric softeners containing antistatic ingredients can be used for this purpose and they are quite inexpensive when compared to special purpose antistatic sprays. To reduce fire hazards, never store flammables in the computer room. Keep on-site paper supplies to a minimum. 3.3.3 Configuration Management and Change Control Because threats can be introduced through unauthorized hardware or software, only Agency authorized hardware and software should be used. Before installation, changes to both hardware and software need to be tested and properly authorized. To help achieve effective configuration management, adhere to the following procedures: Maintain accurate records of hardware/software inventories, configura- tions, and equipment locations. Comply with the terms of software licensing agreements. Penalties for violations of U.S. copyright law are set forth in Section 3.2.5 above. Adhere to the procedures concerning non-EPA software and viruses that are set forth in Section 3.2.7 above. More detailed guidance concerning configuration management and change control as they relate to the software life cycle is contained in the EPA "Operations and Maintenance Manual." 3.3.4 Unauthorized Use of Computers and Software EPA computers and associated software are for official EPA business only. Use of these computers is not allowed for personal business of any kind, even if it is done on the employee's own time. Employees who use hardware and software for other than official Agency business are subject to disciplinary action ranging from a reprimand to dismissal. 3-8 ------- Information Security Manual 12/15/89 4. DETERMINING THE NEED FOR ADDITIONAL CONTROLS The minimal controls described in Section 3 are always required regardless of information sensitivity. The purpose of this section is to determine whether or not additional controls are necessary. Application/information owners use this section to evaluate the sensitivity of each of his/her applications or collections of information. Determining sensitivity is an owner responsibility. If sensitive applications/information are owned, later sections of this manual need to be consulted to determine safeguards and to develop the information required for the application certification process and the Application Certification Worksheet (see Appendix B). Application/information users review this section to develop a working understand- ing of information sensitivity. Users can also use this section to determine the sensitivity of applications or collections of information not yet evaluated by the owner (for example, existing applications that are undergoing certification). Later sections of this manual should then be reviewed as appropriate. PC custodians. LAN System Administrators, and Minicomputer/Mainframe Security Officers review this section to develop a working understanding of information sensitivity. They then combine this understanding with owner sensitivity designa- tions to determine the number and type of sensitive applications being processed by users of his/her installation. This determination becomes an input to the risk analy- sis process outlined in Appendix C. 4.1 DETERMINING SENSITIVITY AND THE TYPE OF INFORMATION The reader should review Section 2.4 before proceeding. That section contains in- formation on combining applications or collections of information for sensitivity determination purposes. The questions presented in the sensitivity evaluation table (Table 4-1) are designed to determine whether a particular application or collection of information is sensitive. To use the table, first read through all 11 questions presented in columns (1 )-(11) of 4-1 ------- r Nameol Application/ Information EXAMPLE- QUESTIONS 0) National Security (2) Drtlcalto 'ertormlng a Primary Agency Mission? YES 3) Lie Critical? 4) Financial Where riisuse Could Causa Loss? 5) Automated Decision- Making Application? 6) Subject to the Privacy Act? YES 7) Confidential Jtnlnoss rtormatton? B) nforooment Conlldentlal? 9) ludgetary Prior to OMB Release? 10) High Value? 11) Other Sensitive? OBJECTIVE/LEVEL I HIGH £ I HIGH i MEDIUM ~ o 03 I m n O 3-H z > 05 DO HI- is D) 3 C 0) NOTES: Question (2) Question (3) Question (4) Question (5) Question (10) Question (11) Answer YES il disablement or unavailability ol the application, or the loss, compromise, or undesired alteration of the information could jeopardize the Agency's ability to perform a primary mission. Answer YES il the loss ol information or disruption ol the application could jeopardize human life or welfare. Relates to check issuance, funds transfer, etc., where misuse could cause loss. Answer YES if the application makes unsupervised automated decisions based on programmed criteria (for example, issuing checks, ordering supplies, or performing similar asset accounting/control functions) and if the wrong automated decision could cause loss. Answer YES il this is an application/information of "High Value' to the Agency or a particular organization. The term 'High Value' must be defined by the owner ol the information or application. While a precise set of criteria for determining High Value cannot be provided, the cost of replacing the information and the problems that would result from doing without the information are primary factors to consider. Answer YES if: (1) you answered NO to all other questions, and (2) this is an application/information whose loss would acutely embarrass the Agency, subject the Agency to litigation, or impair the long-run ability of the Agency to fulfill its mission. cn 00 CD ------- Information Security Manual 12/15/89 the table. If all questions can be answered "No" for all applications/information, the remainder of this manual does not apply. If any question can be answered "Yes" for any application or collection of information, continue with the instructions in the next paragraph. (After completing the table, make sure to have it reviewed as described in Section 4.3.) The table has been designed to be a worksheet for evaluating sensitivity. To use the table, list in the first column the name of each application or collection of information for which at least one question can be answered "Yes." For each listed application or collection of information, answer each question. A sample entry is provided. (Leave the last three columns (security objectives) blank for the time being; how to use these columns is explained below.) If more than one type of sensitive information asset is at issue (for example, three sensitive paper record systems and two sensitive PC applications), fill out a separate worksheet for each type of asset. 4.2 DETERMINING RELEVANTSECURITY OBJECTIVES AND THE DEGREE OF SENSITIVITY The next step is to determine the degree of sensitivity and the relevance of each of the three security objectives. Table 4-2 maps each type of information to its corresponding objective(s) and sensitivity level (that is, high versus medium). (Cases of little or no sensitivity are covered by the minimal controls specified in Section 3.) For each application or collection of information, determine the relevant security objective(s) and sensitivity level(s) based on the type of information the application/ collection contains. Note that the time value of critical information/applications must be evaluated to determine sensitivity level, and the approximate dollar value of high value information/applications must be estimated to determine sensitivity level. Most life critical and mission critical applications will probably involve high level sensitivity. It may be helpful to make notes about security objectives and sensitivity levels in the last three columns of the Table 4-1 worksheet. A sample entry is provided. In instances where an application or collection of information turns out to be at both the 4-3 ------- Information Security Manual 12/15/89 TABLE 4-2 DETERMINING RELEVANT SECURITY OBJECTIVES AND DEGREE OF SENSITIVITY Availability Integrity Confidentiality High Med. High Med. High Med. Type of Information Level Level Level Level Level Level National Security Information x Critical to Performing a Primary Agency Mission -Must be Available Continu- ously or Within 1 Day x x -Must be Available Within 1 -5 Days x x Life Critical -Must be Available Continu- ously or Within 1 Day x -Must be Available Within 1-5 Days x Financial Where Misuse Could Cause Loss x Automated Decision- Making Application x Subject to the Privacy Act x Confidential Business Information x Enforcement Confidential x Budgetary Prior to OMB Release x High Value -Very High Value* x -Other High Value x Other** xxx "While a precise set of criteria for distinguishing between "very high value" and "other high value" cannot be provided, the cost of replacing the information is the primary factor to consider. Clearly, an automatedinformationsystemthatcost$3,000,000ormoretodevelopandprogramwouldbeof"very high value." " Reader must determine which objectives are relevant based on characteristics of information/ application. 4-4 ------- Information Security Manual 12/15/89 high and medium sensitivity levels vis-a-vis an objective, the higher level dominates. For example, an application that contained both National Security Information (high level confidentiality) and Privacy Act data (medium level confidentiality) would be of high level confidentiality. By completing the Table 4-1 worksheet, a security profile is developed that includes information on types of sensitive information or applications, security objectives, and sensitivity levels. The security profile contains the basic information owners need to complete the top of the Application Certification Worksheet. It also contains the basic information PC custodians and Security Officers need to complete the top of the Installation Risk Analysis Worksheet. 4.3 VALIDATING SENSITIVITY RESULTS Determinations of sensitivity and degree of sensitivity must always be reviewed by the cognizant supervisor. Because implementing security safeguards can involve considerable expense and investment of staff time, management review of these determinations is important. Management review is also important because some of these determinations can in- volve an element of judgment for which an organizational perspective is important. Critical or high value information is not as easily identified as Confidential Business Information or Privacy Act data. There may be a tendency for individuals to overdesignate theirapplication as critical or high value. SIRMOs should be consulted when employees and supervisors need guidance in making a sensitivity determina- tion. 4.4 USING THE REST OF THIS MANUAL The next section, Section 5, discusses personnel security. This section needs to be read by all EPA managers and staff who have sensitive applications or information. The remainder of the manual, Sections 6-10, is organized on an information resource-by-information resource basis, such as PCs or paper records. Within each of these sections, procedures are presented in terms of security objective, for 4-5 ------- Information Security Manual 12/15/89 example, security procedures to maintain high-level availability. Read only those sections and subsections that are applicable. If more than one security objective is applicable (for example, an application where both availability and confidentiality are relevant), make sure to read the subsection pertaining to each applicable objective. 4-6 ------- Information Security Manual 12/15/89 5. PERSONNEL SECURITY AND TRAINING 5.1 INTRODUCTION Given the large number of Agency information resources, security is as much a people issue as it is a technical issue. SIRMOs need to make sure that cognizant supervisors in their organizations adhere to the following procedures. 5.2 SCREENING AND CLEARANCE Federal regulations require clearance of all persons involved in the design, develop- ment, maintenance, and operation of sensitive automated systems and facilities. These requirements apply to Federal employees and to the personnel of agents (including contractors and grantees) of the EPA who have access to sensitive EPA information. Determinations of the degree of sensitivity of each position are accom- plished by the program office. The level of screening required should then vary from minimal checks to full background investigations, depending upon the sensitivity of the information to be handled by the individual in the position and the risk and mag- nitude of loss or harm that could be caused by the individual. The responsibility for the implementation and oversight of the personnel clearance program rests with the Office of the Inspector General and the Personnel Management Division. EPA organizations should consult with them when obtaining clearances or designating sensitive positions. 5.3 SEPARATION OF DUTIES An individual has a hardertime concealing errors and irregularities if he/she does not control all aspects of an activity or transaction. For example, by separating the functions of cash handling and bookkeeping, the bookkeeper cannot get to the cash and the cash register clerk cannot adjust the books to hide cash shortages. To the extent possible, the following 11 functions should be assigned to different individuals: Data Creation and Control Functions: 1. Data collection and preparation 2. Data entry 5-1 ------- Information Security Manual 12/15/89 3. Data base administration 4. Custody of data Software Development and Maintenance Functions: 5. Applications programming 6. Design review 7. Application testing and evaluation 8. Application maintenance Administrative Functions: 9. Security planning 10. Security implementation 11. Security audit. Given the very definition of personal computing, it is often impractical to separate functions for PCs. The same individual often collects data, programs the application, enters the data, and generates the reports. Given the realities of computer-related staffing, it is also sometimes difficult to separate functions in the minicomputer or mainframe environment. To minimize the potential for fraud, abuse, or sabotage, these functions should be performed by separate individuals to the maximum extent practicable. When it is not possible to have each function performed by a different individual, try to separate the following: (1) data creation/control functions from software development/maintenance functions, (2) application programming and maintenance functions from design review and testing/evaluation functions, and (3) security audit from all other functions. In the case of all financial applications (relating to check issuance, funds transfer, and the like) where misuse could cause loss, separation of functions or duties is mandatory. This separation also applies to financial applications which may be PC- based. For example, the task of preparing payment vouchers must be kept separate from the task of approving payments. For such financial applications, other preven- tive measures include periodically rotating jobs and asking people to take vacations of one to two weeks. Because the perpetrator of a fraud often has to manipulate accounts on a daily basis to avoid detection, these measures may be a strong deterrent. 5.4 TERMINATION/SEPARATION In the event an employee must be removed or laid off, it is a good idea to rotate the employee to a non-sensitive position prior to giving notice of the action. While this 5-2 ------- Information Security Manual 12/15/89 may seem extreme, angry and demoralized employees have been known to sabotage programs, erase data bases, or plant computer viruses. Regardless of the type of separation (resignation, removal, etc.), supervisors need to make sure the following actions are performed for personnel separating from a sensitive position: Change or cancel all passwords, codes, user IDs, and locks associated with the separating individual Collect all keys, badges, and similar items Reconcile any financial accounts over which the employee had control. The SIRMO or his/herdesignate should then certify thatthese procedures have been accomplished by signing and dating a short statement that says: "Information security procedures for separating employee (NAME) have been completed." These statements should be kept on file for inspection by OIRM or the Office of the Inspector General. 5.5 TRAINING The Office of Administration and Resources Management (OARM) is coordinating the development of a comprehensive information security training program for the Agency to supplement the procedures in this manual. Details and requirements of the program will be issued under separate cover. These requirements will include mandatory basic security awareness training for every employee. The program will include both information security awareness training for all employees and training in accepted security practices for those employees involved in the management, use, or operation of sensitive information. The program will identify and reference, as appropriate, existing training in the information security area, such as training done by NDPD. 5-3 ------- Information Security Manual 12/15/89 6. SECURITY FOR MINICOMPUTER AND MAINFRAME INSTALLATIONS 6.1 INTRODUCTION This section sets forth security procedures for minicomputer and mainframe instal- lations. Installations of this type coverthe range of computer processing capabilities from large scale service center support for multiple users (such as the NCC) down to smaller general purpose systems for multiple users or dedicated use (such as Prime or VAX systems). Minicomputer/Mainframe Security Officers are responsible for implementing the procedures in this section. Because of the size of WIC and NCC, certain of the procedures below apply only to the Security Officers of those two installations. However, NCC/WIC procedures may also be appropriate for other installations, depending on the results of the risk analyses performed for those installations. Pro- cedures that distinguish between NCC/WIC and other installations will be clearly identified. The remainder of this section is organized as follows. Because the selection of safeguards or security measures fora minicomputer/mainframe installation needs to begin with a risk analysis, Subsection 6.2 introduces techniques for performing this analysis. Subsection 6.3 introduces a second important technique disaster recovery and continuity of operations planning. Subsection 6.4 specifies controls that help achieve all three security objectives simultaneously. The last three subsections set forth specific controls for ensuring the availability, integrity, or confidentiality of installation information resources. If more than one objective applies to the installation (for example, availability and confidentiality), make sure to review the subsection for each applicable objective. The reader must note that NDPD issues technical policies (for example, governing passwords or backup frequency) for systems supported and approved by it. Readers also need to refer to these policies, which are contained in the "NDPD Operational Policies Manual". These policies are typically more hardware specific and technically oriented than the procedures presented here. Security Officers must also comply with NDPD policies when applicable. 6-1 ------- Information Security Manual 12/15/89 6.2 RISK ANALYSIS As explained in Section 2, each Minicomputer/Mainframe Security Officer must perform a risk analysis for his/her installation. For all installations, a qualitative risk analysis may be used. Detailed procedures for performing the analysis are pre- sented in Appendix C. Any harm to an installation will manifest itself as a loss of information integrity, a loss of information confidentiality, and/or a loss of processing availability. One of the key outputs of the risk analysis process will be an understanding of the threats (fire, theft, etc.) likely to cause harm to the installation. In selecting control measures from Subsections 6.4-6.7, Security Officers must always consider the reduction in risk the security measures will achieve. In other words, do not implement the procedures in this section in a vacuum; instead implement these procedures only in conjunction with the Appendix C risk analysis. 6.3 DISASTER RECOVERY AND CONTINUITY OF OPERATIONS PLANNING Security Officers are responsible for preparing a plan for disaster recovery and continuity of operations for each minicomputer/mainframe installation. Procedures for preparing the plan are presented in Appendix D. Such plans are particularly important for ensuring the availability of critical or high value Agency applications. To the extent an installation limits itself to confidential or integrity-oriented applications, contingency planning is less important. Appendix D requires a less extensive plan for installations of this type. 6.4 PROCEDURES FOR ALL SENSITIVE INSTALLATIONS For sensitive minicomputer/mainframe installations, there are a number of controls that help achieve all three security objectives simultaneously. For example, requiring the user to provide a password when logging on to a system can prevent disclosure by denying unauthorized users access to the host computer. The password scheme can also reduce the potential for fraud or sabotage by effectively locking-out unauthorized users. Finally, the chance of accidental data destruction 6-2 ------- Information Security Manual 12/15/89 (a threat to availability) is reduced if inexperienced users are unable to access the host computer due to password protection. Universal controls of this type fall into four broad categories: (1) hardware controls, (2) software controls, (3) procedural controls, and (4) communications controls. All four categories are discussed below. 6.4.1 Hardware Controls Many important security safeguards can be built into hardware. Hardware-based protection mechanisms are often cost-effective because they can be applied to so many different information systems and files. By way of contrast, most application- based controls are limited in usefulness to the one application. Hardware-based controls are also typically more difficult to circumvent. To determine what hardware security features are standard and what features can be obtained at additional cost, contact the appropriate vendor representative. From a security perspective, the following hardware features need to be imple- mented when they are available and cost-effective: User Isolation: This is the capability to isolate users from each other. Alarm: An audible alarm notifies the computer operator when certain events occur, such as an unauthorized access attempt. Identifiable Remote Terminals: This is the capability of knowing the identity of remote terminals. This feature augments a password scheme which authorizes each user. With terminal identification, an intruder must have a valid password and access to a valid terminal. Error Detection During Processing: This feature involves checking for errors each time memory is accessed. The error checks typically take the form of parity and address bounds checks. Error detection is particularly useful for maintaining integrity. Memory Access Control: This capability limits each user to the memory of his/her own partition. Privileged Command Control: With this feature, certain commands are only executed when the computer is in a master or executive mode (as opposed to a user mode). Commands of this type include input/output instructions and partition transfers, and are generally available only to operators or system programming personnel. 6-3 ------- Information Security Manual 12/15/89 6.4.2 Software Controls The following controls need to be implemented using the operating system and other system software (unless they have already been built into the hardware): User programs must be prevented from executing privileged instructions. Users must be isolated from each other. Hardware and software error logs need to be maintained. Error checking needs to occur each time memory is accessed. Atypical occurrences that may indicate a security violation need to be recorded. These include unlocking terminals via operator overrides or access failures, such as incorrect passwords. In addition, the operating system must control the following functions: Information transfers between the main memory and on-line storage, and between the central computer and remote equipment All functions that allocate ADP resources, such as memory or peripher- als Utilities and programs that maintain and change the operating system. 6.4.3 Procedural Controls Memory dumps must be limited to a user's memory partition. System memory dumps need to be strictly controlled. When installation size warrants it, maintain astorage location and a library system for tape and disk storage. - Only the media librarian or individuals authorized by the installation's Security Officer will be allowed access to the storage location. - All media not scheduled for use within the next day should be stored in the library. - Mark each item with a serial number. - Keep a record of each item that includes its sensitivity designation, age, frequency of usage, owner, and cleaning schedule. Maintain console logs and operating logs. 6-4 ------- Information Security Manual 12/15/89 6.4.4 Communications Controls Host-level password protection is required for any on-line access to the computer. (Host-level passwords are those used when first logging on to the computer system, for example, VAX or IBM Mainframe.) In implementing password protection, make sure of the following: Passwords are at least six characters in length. The password must contain at least one alpha and one numeric character. Passwords can be deleted or changed in a straightforward, controlled fashion. Passwords are changed at least quarterly. Consecutive password failures are limited to no more than four before a user is revoked from the system. Passwords are not composed of names or similar personal types of information. 6.5 ADDITIONAL PROCEDURES TO MAINTAIN AVAILABILITY 6.5.1 Procedures for Medium-Level Availability 6.5.1.1 Backups and Continuity of Operations In general, the most important step to be taken to protect information availability is to implement a regular schedule of backups. If information has been backed up and if the backup has been safely stored, the information will be recoverable no matter what happens. Procedures for backup, disaster recovery, and continuity of opera- tions are contained in Appendix D. 6.5.1.2 Power Protection Provide for adequate power to guard against fluctuations and failures through the use of surge protectors. Consider implementation of an Uninterruptible Power Supply (UPS) to avoid system failure during brief power disruptions. 6.5.1.3 Physical Access Control NCC and WIG must maintain a physical access control that includes at least one of the following: key cards, magnetic card locks, remote controlled locks, or closed- circuit television. At night, this system must be supplemented with either an intrusion 6-5 ------- Information Security Manual 12/15/89 alarm or a guard patrol. Other installations must, at a minimum, maintain a list of personnel authorized to enter the installation. At night, this must be supplemented with a guard control. More rigorous access control systems are acceptable for other installations if they are cost-effective. 6.5.1.4 Visitor Control All visitors must log-in/log-out and be escorted during the visit. 6.5.1.5 Fire Control WIC and NCC must install a centralized fire suppression system. 6.5.2 Procedures for High-level Availability Follow all procedures set forth in Subsection 6.5.1. In addition, install an emergency power standby capability. 6.6 ADDITIONAL PROCEDURES TO PRESERVE INTEGRITY To maintain medium level integrity, adhere to the procedures in Subsection 6.5.1 above. To maintain high level integrity, adhere to the procedures in Subsection 6.5.2 above. 6.7 ADDITIONAL PROCEDURES TO PRESERVE CONFIDENTIALITY 6.7.1 Procedures for Medium-Level Confidentiality 6.7.1.1 Control Hard-Copy Reports and Output Control the production and distribution of confidential output. Keep such output in a locked cabinet or room when not in use. Establish safeguards to prevent confi- dential reports from being misrouted. 6-6 ------- Information Security Manual 12/15/89 6.7.1.2 Encryption Some application system owners may determinethat encryption is a needed security control when transmitting confidential data. The NCC will provide encryption where required upon request. Other installations may also provide encryption if it is cost- effective, but they must consult with the NCC regarding potential technical and logistical problems. 6.7.1.3 Physical Access Control See Subsection 6.5.1.3. 6.7.1.4 Visitor Control All visitors must log in/log out and be escorted during the visit. 6.7.1.5 Disposal Practices Shred confidential reports when they are no longer needed. Make sure that confidential data are erased from magnetic tapes before releasing them as work tapes, etc. Assist application system owners who wish to erase confidential data from their disk space before releasing it for other uses. 6.7.2 Procedures for Hiah-Level Confidentiality The EPA has only one type of information in this category - National Security Information (NSI). The amount of NSI possessed by the Agency is extremely small and the need to computerize any of it would be very infrequent. Because of the small quantity of NSI in the Agency and because NSI involves special security considerations (emanations security and TEMPEST devices), NSI should not be placed on computers without the express approval of the Director, OIRM. 6-7 ------- Information Security Manual 12/15/89 7. SECURITY FOR PERSONAL COMPUTERS AND PC LANs 7.1 BACKGROUND This section applies to personal computers (PCs) only. A single PC installation is generally comprised of a microprocessor, a video monitor and various peripheral devices for entering, storing, transmitting and printing data. The PC installation may process in isolation as a standalone personal tool and/or it may function as a smart terminal in a communications configuration (such as PC to mainframe). This section does not apply, however, to other types of microsystems such as Lexitron word processors (see Section 8) or dumb terminals (those that are not programmable). The expanding use of personal computers is creating major new opportunities for productivity improvement at the EPA. At the same time, however, this expanding use of personal computers is placing new information security responsibilities on office managers, research personnel, and others not previously considered to be in- formation processing professionals. This decentralized processing of Agency information means that mainframe and minicomputer processing installations can no longer be relied upon to protect all automated Agency operations. Certain PC characteristics pose special problems in information security. In general, these include the following: Personal computer systems software is typically rudimentary and affords little protection to information and programs. Personal computers typically lack the built-in hardware mechanisms needed to isolate users from each other and from certain system functions (such as reading and writing to memory). PC information is typically in the form of reports, spreadsheets, lists, and memoranda. These relatively final forms mean that PC data are more readily accessed and understood by unauthorized users than are data in larger computer systems. 7-1 ------- Information Security Manual 12/15/89 7.2 DETERMINING THE PROCESSING ENVIRONMENT; RELATIONSHIP TO OTHER PROCEDURES Several of the procedural controls specified in Subsections 7.4-7.6 are presented in terms of the environment in which the application or information is being processed. In using those subsections, be alert to procedures that depend on three key environmental characteristics, which can be defined by answering the following questions: Is the PC a single-user device or is it shared among multiple users? Is the information/application stored on removable media (like a floppy disk) or non-removable media (like a fixed disk) or both (like a fixed disk with a floppy disk backup)? Does the PC process in isolation or does it communicate with other hardware? If it does communicate, which of the following communication configurations applies: - Remotely accessible by modem (dial-up capability)? - PC to resource server? - Local area network (LAN)? Regarding LANs, LAN System Administrators must note that NDPD issues policies (for example, governing access control or backup frequency) for Agency LANs. These policies are contained in Section 310 of the "NDPD Operational Policies Manual." These policies are typically more detailed and technically oriented than the core procedures presented here. LAN System Administrators must make sure that they comply with applicable NDPD policies. 7.3 USING THE REST OF THIS SECTION The remainder of this section is organized by information security objective. Consult completed Table 4-1 to determine which security objective orobjectives are relevant. If availability is a security objective, review Subsection 7.4 If integrity is a security objective, review Subsection 7.5 If confidentiality is a security objective, review Subsection 7.6. 7-2 ------- Information Security Manual _ 1 2/1 5/89 In discussing procedural controls, Subsections 7.4-7.6 reference hardware and software security products that are available under the PC contract. Information on products and prices was current as of December 1989. Because the Agency peri- odically updates contract offerings and prices, the reader should consult with his/her PC site coordinator prior to placing an order. 7.4 MAINTAINING INFORMATION AVAILABILITY 7.4.1 Introduction This subsection sets forth security procedures for owners, users, LAN System Administrators, and custodians of applications of high-level and medium-level availability (as determined in Section 4). This section is to be used as follows: Owners develop the security specifications and the tests needed for ap- plication certification based on the procedures presented here. sure they are in compliance with ownersecurity specifications based on these procedures. In addition, users may consult these proce- dures when an owner has designated an application as sensitive, but has not yet identified his/her security specifications. Custodians and LAN System Administrators use these procedures to make sure that applications can be recovered in the event of a processing disaster and can be run elsewhere if necessary. They also use these procedures to develop the information required for the risk analysis outlined in Appendix C. The remainder of this subsection is organized as follows. The next part catalogs and describes specific threats to information availability. Subsections 7.4.3 and 7.4.4 specify security measures for medium availability applications and high availability applications, respectively. The last part describes some steps that can be taken to recover from a processing disaster. 7.4.2 Threats to Application and Information Availability Specific threats to data availability include: Theft Damage to magnetic media Hardware failure: inability to restart 7-3 ------- Information Security Manual 12/15/89 Hardware failure: failure during use Accidental data destruction or other operator errors Sabotage (deliberate data destruction) Failure of users to back-up data and programs. The threats of theft and damage to magnetic media were addressed in Section 3. The remaining threats are described below. 7.4.2.1 Hardware Failure: Inability to Restart Because of the generally high reliability of microcomputers, users tend to become overconfident and to not protect themselves from system failures. In some cases, microcomputer systems are incapable of being restarted (booted) because of a hardware failure. If the inability to start the system is caused by a failure of the hard disk drive subsystem and it is necessary to repair or replace the drive, the data on the drive will probably be unavailable after the system has been repaired. 7.4.2.2 Hardware Failure: Failure During Use Although microcomputers do not often break down, the hardware can fail during use for a variety of reasons. The most common problem is a disruption or surge of electric power, but the failure of almost any internal component can cause the system to crash. In addition to the problems that may be encountered if the system cannot be booted, failure during use will result in a disruption of ongoing processing. If the system crashes while in use, all data in the volatile, random access memory (RAM) will be lost. In addition, if data files are open at the time of the failure, they may be corrupted. 7.4.2.3 Accidental Data Destruction The most common way that data are accidentally destroyed is by users issuing incorrect commands. For example, it is possible for users to destroy all of the data on a disk by inadvertently reformatting it. This can be especially damaging if the hard disk is reformatted. Files can also be inadvertently deleted. It is also possible to copy a file on top of an existing file if the name of the existing file is used as the destination 7-4 ------- Information Security Manual 12/15/89 of a copy command. Data can also be accidentally destroyed by software malfunctions or incompatibility. A particularly serious potential problem is caused by an incompatibility between versions 2.x and 3.x of PC/MS DOS. Specifically, if a system containing a 20mb or larger fixed disk formatted under version 3.x of DOS is booted from a diskette that contains a 2.x operating system, the File Allocation Table of the hard disk will be damaged when data are written to the hard disk. If this happens, it might not be possible to access data stored on the hard disk. 7.4.2.4 Sabotage Data can be deliberately destroyed by malicious individuals, who may be either authorized or unauthorized users. Such destruction can be the result of vandalism by those outside the office, but it can also be an act by an employee who has been dismissed or disciplined, an act by an individual who is hostile to the mission of an office, or an act by an individual hostile to the implementation of a new computer system. Examples include: An employee may oppose the implementation of performance monitoring software. An individual may use the data overwriting programs in PC utilities packages to erase files or disks. An individual may feel that the automation of the individual's duties may make him or her more expendable. A dismissed employee may plant a "virus" in an organization's software prior to departure. An individual may believe that the implementation of a system intended to make his or her job easier will actually make his or her job more difficult. 7.4.2.5 Failure to Backup Data and Programs When it comes to regular and systematic backup, it unfortunately seems that expe- rience is the best teacher. A user often needs to lose an important file before he/ she realizes the importance of backup. Failure to perform regular backups is probably the most common and the most serious threat to availability. 7.4.3 Procedures to Maintain Medium-Level Availability This part applies to applications that can be unavailable for a period of only one-to- 7-5 ------- Information Security Manual 12/15/89 five days and/or applications that are of other high value. 7.4.3.1 Lock-up Media To avoid theft, store media in a locked cabinet or room. 7.4.3.2 Write Protection Whenever possible, write-protect files and programs to avoid accidental destruction. 7.4.3.3 Isolated Storage Isolate the critical/high value application on its own storage media to the extent possible. For an application residing on a floppy disk, this means dedicating the disk to the one sensitive application. For an application residing on a fixed disk, this could mean dedicating a separate subdirectory or partition to the software. Such isolation speeds the backup process (discussed below). 7.4.3.4 Backups In general, the most important step to be taken to protect information availability is to implement a regular schedule of backups. Backups are performed to provide for easy recovery from a disaster. If information has been backed up and if the backup is safely stored, the information will be recoverable no matter what happens. Note, however, that transactions that have occurred since the last backup may have been lost and may need to be re-input. DATA BACKUPS Each PC user needs to establish a backup loop to protect his/her data and files. The backup loop is a systematic way of creating multiple generations of copies. The frequency and number of backup generations made and stored should be a direct function of the value of the information and the cost of regenerating it. In general, two to five generations are recommended. Two examples involving diskettes are provided below. A two-generation scheme for a floppy disk would be performed as follows: - On the first day, the data on the original diskette would be copied on to diskette 1. - On the second day, the data on the original diskette would be copied on to diskette 2. - On the third day, the data would be copied on to diskette 1, over the backup from the first day. 7-6 ------- Information Security Manual . 12/15/89 A five-generation scheme for a fixed disk system would be performed as follows: - On Monday of the first week, the user's data on the fixed disk would be copied to a set of diskettes designated as set 1. - On Tuesday, the data could be copied to set 2. Wednesday's backup would be copied to set 3, Thursday's to set 4, and Friday's to set 5. - On Monday of the second week, the data would be copied to set 1, over the Monday backup from the previous week. Under a five-generation scheme, the user has a significant level of protection. Even if the original data and one or two of the backups were destroyed, only one or two days of work would be lost. The backup loop does not have to involve diskettes. As discussed below, tape backup systems or Bernoulli boxes can be more efficient. Moreover, if the PC is connected to a LAN file server or remote host (such as a mainframe computer), the remote device may provide backup protection. Consult the manager of the remote facility or the LAN System Administrator for informa- tion. Backup copies stored in the general vicinity of the original data protect against problems such as a system crash or an accidental erasure of data. They do not, however, protect against a threat such as a fire which could affect an entire floor or building. As a result, each month a copy should be taken out of the backup loop and stored in a physically separate location. This archival copy would probably not be completely current in the event of a major disaster, but it would have great data recovery utility. To prevent archival copies from piling up, the copy that has been in archives can replace the one taken out of the backup loop. There may also be advantages in retaining several generations of archival copies. For Headquarters employees, the WIC is recommended as an "off-site" location. The WIC does charge a fee for storing backup copies. Participating organizations execute an "Operational Service Agreement for Archiving of PC Software" with the WIC. If the PC is connected to a remote host or file server, it may be possible to use the remote device as the off-site location. Consult the manager of the remote facility or the LAN System Administrator 7-7 ------- Information Security Manual 12/15/89 for assistance. When files get large, users are tempted to employ the incremental backup approach. An incremental backup focuses only on what has been changed and includes only those files that have been modified since the last backup. The advantage of an incremental backup is that it can be performed faster than the full backups discussed above. The disadvantage of incremental backups is that no single backup will contain all of the files and data. If the original files are destroyed or lost, it will be necessary to reconstruct the data from the most recent full backup and all of the incremental backups that have been performed since. In addition to being inconvenient, this process of reconstructing the files is risky. If the last full backup or any of the incremental backups has anything wrong with it, it may be impossible to perform a fully successful recovery. Because of these difficulties, incremental backups are not recommended. Instead, if the data files are so large that the backup process fills about 15 diskettes, consider using a streaming tape backup system or a Bernoulli box. A streaming tape backup system is available under the PC contract for about $500. The Bernoulli box, which is available for about $800 (10 megabyte) or about $1200 (20 megabyte) under the PC contract, makes backups straight- forward and quick. It also provides certain access controls, for example, partitioning software. If the PC is also used for confidential processing, the box becomes more cost effective. In addition, if software as well as data are stored on Bernoulli disks and a second PC with a Bernoulli box is available, each PC can be a backup facility for the other. SOFTWARE BACKUPS Backups should not be limited to data and files. End user applications (soft- ware developed or maintained locally) should also be backed up and stored at the off-site storage facility. Source program files, loadable versions of all software, and required compiler or interpreter programs should be included. 7.4.3.5 Continuity of Operations Backup computing facilities shall be identified for critical applications and an agreement for the use of the backup facility shall be executed. The agreement for 7-8 ------- Information Security Manual 12/15/89 the backup facility should not be an informal and vague oral agreement, but instead must involve a memorandum between the PC custodians identifying all conditions (for example, the amount of machine time to be made available). 7.4.4 Procedures to Maintain High-Level Availability This part applies to applications that must be available continuously or within one day and/or applications that are of very high value. All procedures set forth in Subsection 7.4.3 also apply here. In addition, the following additional procedures will be adhered to. 7.4.4.1 Uninterruptible Power Obtain an Uninterruptible Power Supply (UPS) device to provide virtually complete surge protection, a filter for line noise, and power in the event of an outage. A UPS is available for approximately $1100 under the PC contract. 7.4.4.2 Manual Fallback Identify and formalize manual procedures to be followed in the event of a complete disaster. 7.4.4.3 More Frequent Backups Consider preparing full backups for off-site storage on a weekly or even daily basis. 7.4.5 Suggestions for Recovering from a Disaster In the event of a problem or disaster, it is often best to stop using the PC and seek help from the PC Site Coordinator. The following may then help restore availability: It may be possible to recover data stored on the undamaged portions of the damaged medium using the DOS DEBUG facility or some other hexadecimal editor. This will be a difficult task and should only be undertaken by individuals with a thorough understanding of theirsystems. Commercially available utility packages (such as the Norton Utilities package available under the PC contract for about $100) can help in recovering data and in unformatting an accidentally formatted disk. If backups have been made, data and software that are not copy-protected can be restored from the backups. Contact the manufacturers of copy- protected software to investigate their policy for replacing damaged software. 7-9 ------- Information Security Manual 12/15/89 If summary data have been damaged, but detailed records or other audit trails were undamaged, it may be possible to recreate the summary data from the detailed records. In some cases it might even be possible to recreate detailed records if sufficient audit trail information is available. 7.5 PRESERVING INFORMATION INTEGRITY 7.5.1 Introduction This subsection sets forth security procedures for owners, users, LAN System Administrators, and custodians of applications of high-level and medium-level integ- rity (as determined in Section 4). This section is to be used as follows: Owners develop the security specifications and the tests needed for ap- plication certification based on the procedures presented here. Users make sure they are in compliance with owner security specifica- tions based on these procedures. In addition, users may consult these procedures when an owner has designated an application as sensitive, but has not yet identified his/her security specifications. Custodians and LAN System Administrators use these procedures to determine what security measures must be in place at his/her installation to maintain integrity. They also use these procedures to develop the information required for the risk analysis outlined in Appendix C. The remainder of this subsection is organized as follows. The next part catalogs and describes specific threats to information integrity. Subsections 7.5.3 and 7.5.4 then specify security measures for applications of medium-level integrity and high-level integrity, respectively. Finally, the last part describes some steps that can be taken to recover from data corruption. 7.5.2 Threats to Integrity 7.5.2.1 Deliberate Distortion of Information: Fraud and Sabotage Data integrity can be damaged by the deliberate actions of system users or other in- dividuals with access to the system. Such damage could take the form of a virus. These actions could be motivated by revenge (for example, by recently disciplined or reprimanded employees) or could be intended to perpetrate or cover up fraudulent activities, mismanagement, or waste. 7-10 ------- Information Security Manual 12/15/89 Fraudulent activities include embezzlement or any other deception intended to cause the deprivation of property or some lawful right. Fraud could be intended to prevent or influence enforcement actions or other operations of the Agency. 7.5.2.2 Accidental Damage Accidental damage to data integrity results when individuals inadvertently and un- knowingly modify data, erase files, input incorrect data, or introduce program bugs. Accidental threats to data integrity overlap with the issues discussed under data availability. The distinction is based on whether the data distortion is discovered. If so, the distortion would be generally be considered to consist of a loss of data and would therefore be considered to be a data availability problem. When the damage remains undetected, decisions may be made or other actions may be taken based upon incorrect information, resulting in a failure of data integrity. 7.5.2.3 Other Considerations In addition to the above, information integrity can also be affected by flaws in soft- ware applications design and development (for example, incorrect algorithms or mathematical formulae). A review of all system design issues that are relevant to data integrity is beyond the scope of this manual. Instead, the reader is referred to the three volume set of "EPA System Design and Development Guidance" issued by OIRM. This comprehensive set of standards includes references to security at appropriate points in the software design/development process. For more explicit guidance on designing security into applications, the reader is also referred to Federal Information Processing Standard (FIPS) 73 and to Section 9 on application system development. FIPS 73 is available in the EPA Headquarters library or through the National Technical Information Service. This section will limit itself to a consideration of threats to data integrity involving deliberate and accidental actions of users and involving other events that can occur during system use. 7.5.3 Procedures to Maintain Medium-Level Integrity The security measures needed to ensure integrity reoresent a mix of-those aaaooi ated with maintaining availability and those associated wnh preserving confidential- ity. Availability and confidentiality are almost opposites; backup copies of a data 7-11 ------- Information Security Manual 12/15/89 base made to enhance availability can aggravate the problem of preventing the disclosure of data stored in the data base. In a very real sense, however, integrity is the objective in the middle. Integrity involves elements of the availability objective because if data are corrupted or partially destroyed, intact backup copies are essential. On the other hand, integrity involves elements of the confidentiality objective because preventing fraud and sabotage are largely problems of controlling access. 7.5.3.1 Availability-Related Procedures Adhere to the procedures described in Subsection 7.4.3, with the exception of those associated with continuity of operations. This will ensure that backups are created. 7.5.3.2 Confidentiality-Related Procedures Adhere to the access control procedures described in Subsections 7.6.3.2 and 7.6.3.3. Also, follow the password management practices outlined in Subsection 7.6.3.1. In addition, for PCs in a local area network (LAN), adhere to the procedures outlined in the following two paragraphs. In a LAN, all points can read traffic on the network. In addition, all points have access to common storage media. Indeed, the ability to share printers or storage (file servers) is often a primary reason why networks are created. The LAN System Administrator is responsible for coordinating the selection of security safeguards for the network to ensure overall effectiveness. LANs some- times have security packages available as pan: of their operating systems. These may be considered in selecting safeguards forthe network. If all network users have access to all information processed on the network, establish a formal list of those authorized users (an administrative control). To the extent possible, bolster this administrative control by keeping each PC on the network under lock and key when not in use. Require users to provide a password when logging on to the network. 7.5.3.3 Audit Trails and User Accountability Tracking if fraud and sabotage are threats, audiUrails and operator tracking should be incor- porated inio the application software. The software should be designed to automati- cally insert the operator identifiers into each record based upon a password supplied during the system sign-on process. Data integrity and user accountability would be 7-12 ------- Information Security Manual 12/15/89 further enhanced if the application software and data base were compiled and encrypted to prevent the password and accountability tracking mechanism from being bypassed. 7.5.4 Procedures to Maintain High-Level Integrity All procedures set forth in Subsection 7.5.3 above also apply here. In addition, the procedures listed below will be followed. 7.5.4.1 Uninterruptible Power Obtain an Uninterruptible Power Supply (UPS) device to provide virtually complete surge protection, a filter for line noise, and power in the event of an outage. A UPS is available for about $1100 under the PC contract. 7.5.4.2 Manual Fallback Identify and formalize manual procedures to be followed in the event of a complete disaster. 7.5.4.3 More Frequent Backups Consider.preparing backups for off-site storage on a weekly or even daily basis. 7.5.5 Suggestions for Recovering from a Disaster In the event of a problem or disaster, it is often best to stop using the machine and seek help from the PC Site Coordinator. The following may then help restore integrity: It may be possible to recover data stored on the undamaged portions of the damaged medium using the DOS DEBUG facility or some other hexadecimal editor. This will be a difficult task and should only be undertaken by individuals with a thorough understanding of theirsystems. Commercially available utility packages (such as the Norton Utilities package available under the PC contract for about $100) can help in recovering data and in unformatting an accidentally formatted disk. If backups have been made, data and software that is not copy-protected can be restored from the backups. Contact the manufacturers of copy- protected software to investigate their policy for replacing damaged software. 7-13 ------- Information Security Manual 12/15/89 If summary data have been damaged, but detailed records or other audit trails were undamaged, it may be possible to recreate the summary data from the detailed records. In some cases it might even be possible to recreate detailed records if sufficient audit trail information is available. 7.6 PRESERVING INFORMATION CONFIDENTIALITY 7.6.1 Introduction This subsection sets forth security procedures for owners, users, LAN System Administrators, and custodians of confidential applications and information. This section is to be used as follows: Owners develop the security specifications and the tests needed for ap- plication certification based on the procedures presented here. Users make sure they are in compliance with owner security specifica- tions based on these procedures. In addition, users may consult these procedures when an owner has designated an application as sensitive, but has not yet identified his/her security specifications. Custodians use these procedures to determine what security measures must be in place to protect the confidential information being stored and processed by users of his/her installation. They also use these proce- dures to develop the information required for the risk analysis outlined in Appendix C. LAN System Administrators must note (per Section 7.6.3.3) that no confidential data may be loaded on to a LAN or made available via a LAN unless specifically approved in writing by the Director, OIRM. The remainder of this subsection is organized as follows. The next part catalogs and describes specific threats to confidentiality. Subsections 7.6.3 and 7.6.4 specify security measures for applications of medium level confidentiality and high level con- fidentiality, respectively. Features of the processing environment are particularly important for preserving confidentiality and are discussed in those subsections as appropriate. Unlike Subsections 7.4 and 7.5, there is no separate discussion here of steps to recover from a breach of confidentiality. Once information has been disclosed, there is little the individual can do to remedy the situation. Instead, the breach must be reported to appropriate Agency officials, as described in the Information Security Policy. 7-14 ------- Information Security Manual 12/15/89 7.6.2 Threats to Application and Information Confidentiality Specific threats to information confidentiality are largely problems of access control. Note that the threats described below apply to confidential information in its various forms, that is, in the computer, in hard copy, on removable media like diskettes, and on printer ribbons. Magnetic media containing confidential data can be accessed by individu- als from whom the data should be restricted. If the computer is not in a secure area, intruders can start the system containing the information and browse information on the fixed disk. If diskettes containing confidential information are not secured, unauthorized individuals can install them on a computer and browse their contents. Unauthorized individuals could see data on a computer screen or printout if confidential data are processed in an unsecured area or if printouts are not protected in storage. Confidential data can be deciphered from printer ribbons used to print confidential reports. Unauthorized individuals could access confidential data across a local area network or other communications device if confidential data are stored or processed on a microcomputer that can be accessed remotely. Files erased from a magnetic disk using only the standard DOS "DEL" or "ERASE" commands are not actually erased from the computer disk they are only marked for deletion and the space on which they are written is freed for use by later files. For this reason, until they have been overwritten, they can be "unerased" using commercially available utility programs. Some software systems use work files that are temporarily stored on disk. Although the systems usually delete these files when they are finished with them, the deleted files may be recoverable using commercially available utility programs. Similarly, information could be left in the volatile (RAM) memory of the computer if the computer is not turned off after confidential data have been processed. Individuals authorized to access confidential information could deliber- ately share printed reports or magnetic media containing confidential data with unauthorized individuals. 7.6.3 Procedures to Preserve Medium-Level Confidentiality Preserving confidentiality involves controlling access to information and applica- tions. How easy or difficult it is to control access is highly dependent on the three 7-15 ------- Information Security Manual 12/15/89 key environmental characteristics (single user versus shared, stand-alone versus communicating, removable versus non-removable media). The simplest situation consists of a single user who does stand-alone processing and stores all confidential information on floppy disks. When the PC is shared or in a communicating configuration, the security situation becomes more complicated. The procedures which follow are presented largely in terms of processing environ- ment. Following a short subsection on controls which apply to all environments, more complicated environments are discussed. The security controls required fall into the following categories: Physical, such as door locks Administrative, such as lists which specify who is allowed access to a given PC System-based, such as password protection Information-based, that is, rendering information unusable (even if it is obtained by unauthorized individuals) through scrambling or encryption techniques. As an example, some commercial software (for example, Lotus 1 -2-3 Version 2) contain data encryption capabilities. The Lotus 1 - 2-3 data encryption capability enables users to password-protect their Lotus spreadsheets. The encrypted spreadsheets cannot be accessed without the assigned password and data in them are encoded to prevent the data files from being read through DOS functions or other utilities. It should be noted that EPA organizations with statutory authority for certain types of confidential information may issue security procedures dealing exclusively with a particular type of information (for example, TSCA or FIFRA CBI). Because of statutory requirements, some of those procedures may be more stringent than those required here. EPA employees must make sure that they also adhere to such organizational standards and procedures. 7.6.3.1 Procedures for all Environments Discourage traffic in the area where the computer is located when in use. Unauthorized individuals should be kept out of the area so that they cannot view data that might appear on the computer screen. Log off or otherwise inactivate the PC whenever leaving it. Store hard-copy reports and removable media containing confidential data in locked cabinets or rooms. Printer ribbons used to print confidential data should be considered confidential as well. Destroy exhausted ribbons so that they cannot be 7-16 ------- Information Security Manual 12/15/89 deciphered by an unauthorized individual. Be careful when disposing of disks, diskettes, or tapes that contain confidential data. Before these media are thrown away or recycled, they must be degaussed, overwritten, or shredded. (Degaussing erases data through demagnetization.) The WIPEDISK program in the Norton Utilities package (available underthe PC contract for about $100) destroys all data on a disk by overwriting them. When erasing individual files on diskettes or fixed disks, use an overwrit- ing program like WIPEFILE in the Norton Utilities package. These over- writing programs are effective; be careful not to erase needed files. It should be noted that programs designed to purge and overwrite individ- ual files (like WIPEFILE) may only overwrite the most recent generation of a file. This would also destroy previous generations of the file if they were physically located in the same disk addresses as the last generation of the file. If the previous generations were located elsewhere on the disk, or if the last generation file is smaller than the previous generations, the previous generations may not be entirely overwritten by the file destruc- tion utility. Recovery of these undestroyed fragments, however, would be extremely difficult and tedious for even the most knowledgeable intruder, and it is unlikely that more than small fragments of the sensitive informa- tion could be recovered.) If passwords are selected as a control measure (based on the procedural guidance below), make sure passwords are selected and handled as follows: - Passwords are at least six characters long - Passwords contain at least one alpha and one numeric character - Passwords are not composed of names or similar personal types of information - Passwords are not shared - Passwords are changed at least quarterly - Passwords are not written out and left where an unauthorized person could find them - Passwords are not incorporated into automated log-on procedures in batch files or application programs (for example, Crosstalk) and they are not defined under function keys. Passwords can either be incorporated into applications systems or imple- mented through add-on circuit boards. While application-based pass- word schemes may prevent casual intruders, they usually do not thwart 7-17 ------- Information Security Manual 12/15/89 the knowledgeable intruder unless special steps are taken (for example, encryption). Knowledgeable intruders may be able to avoid the pass- words altogether or may scan application listings to determine the password. For this reason, the more sophisticated hardware-based password schemes are recommended. Cyiock, available under the PC contract for about $300, is hardware based. 7.6.3.2 Procedures for Stand-Alone Processing This part applies to PCs that process in isolation and do not communicate with any other equipment. CONFIDENTIAL DATA ON REMOVABLE MEDIA ONLY; SINGLE OR SHARED USER PC Clear the system of confidential information after each confidential process- ing session. Power off the unit to clear any volatile memory, that is, random access memory (RAM). CONFIDENTIAL DATA ON NON-REMOVABLE MEDIA; SINGLE OR SHARED USER PC Keep the computer under lock and key when not in use, that is, keep it in a locked cabinet or a locked room. If all users of a shared PC have access to all information processed on the PC, establish a formal list of those authorized users (an administrative control). Limit access to those on this authorized list. If this is not the case, users must be protected from each other via either a password scheme or encryption. Encryption software (Datasafe) is available under the PC contract for under $100. 7.6.3.3 Procedures for Communicating PCs This part applies to PCs that are connected to other equipment such as auto-answer modems, other PCs, or resource-servers. AUTOANSWER MODEM; SINGLE USER OR SHARED PCs are sometimes used as host systems. An autoanswer modem allows a person to use the system remotely. Keep the computer under lock and key when not in use, that is, keep it in a locked room or a locked cabinet. 7-18 ------- Information Security Manual 12/15/89 Use a password scheme that requires both a traditional user identifier and a password logon process. Under no circumstances should users share passwords. TERMINAL EMULATION At times, a PC is used as a terminal device to a large host system. In this situation, security controls are the responsibility of the host system. The host should control access and the extent to which data are sent (uploaded) or received (downloaded). The PC user needs to make sure he/she adheres to all host-imposed security requirements. In addition, the PC must never store host telephone numbers, logon sequences, or passwords in the PC itself. LOCAL AREA NETWORKS; SINGLE USER OR SHARED PC No confidential data may be loaded on to a local area network (LAN) or made available via a LAN unless specifically approved in writing by the Director, OIRM. 7.6.4 Procedures to Preserve High-Level Confidentiality The EPA has only one type of information in this category - National Security Information (NSI). The amount of NSI possessed by the Agency is extremely small and the need to computerize any of it would be very infrequent. Because of the small quantity of NSI in the Agency and because NSI involves special security considerations (emanations security and TEMPEST devices), NSI should not be placed on PCs without the express approval of the Director, OIRM. 7-19 ------- Information Security Manual 12/15/89 8. SECURITY FOR WORD PROCESSORS 8.1 INTRODUCTION This section applies to users of equipment designed primarily for word processing, such as the remaining Lexitrons still in use. Such equipment has little or no programming capability. Under certain circumstances, this section applies to the newer Telex devices (which have been replacing Lexitrons) and to PCs. This section can be used for a Telex or PC if all of the following conditions are met: The Telex or PC is used exclusively for word processing The Telex or PC does not communicate with other computers Confidential documents are never stored on non-removable media like a fixed disk If the above conditions are not met, the Telex or PC is covered by the Section 7 procedures. (The Telex is a programmable, IBM-compatible microcomputer, making Section 7 applicable when the conditions above are not met.) In terms of security threats and safeguards, word processors have much in common with PCs. Both are office automation microsystems used by large numbers of EPA employees. In essence, the procedures presented here are a simpler, quicker-to- use version of the PC procedures set forth in Section 7. The remainder of this section is organized as follows. The next subsection identifies and describes specific threats to information security. Subsections 8.3 and 8.4 specify security measures for maintaining availability and preserving information integrity, respectively. The last subsection specifies security measures for preserv- ing information confidentiality. If more than one security objective applies to the word processor (for example, availability and confidentiality), make sure to review the subsection for each applicable objective. 8.2 THREATS TO SECURITY 8.2.1 Threats to Information Availability Specific threats to information availability include: Hardware Failure: In some cases, word processors are incapable of 8-1 ------- Information Security Manual 12/15/89 being restarted because of hardware failure. In addition, sometimes the hardware fails during use for a variety of reasons. The most common problem is a disruption or surge of electrical power, but the failure of almost any internal component can cause the system to crash. Accidental Data Destruction: The most common way that information is accidentally destroyed is by users issuing incorrect commands. For example, documents can be inadvertently deleted. Sabotage: Information can be deliberately destroyed by malicious individuals. Such destruction can be the result of random vandalism, but it can also be an act by an employee who has been dismissed or disciplined, or an act by an individual who is hostile to the mission of the office. Two additional threats to availabilitytheft and damage to mediawere discussed in Section 3. 8.2.2 Threats to Information Integrity Specific threats to information integrity include: Deliberate Distortion of Information Fraud and Sabotage: Data integ- rity can be damaged by the deliberate actions of system users or other individuals with access to the systems. These actions could be motivated by revenge (for example, by recently disciplined or reprimanded employ- ees) or could be intended to perpetrate or cover up fraudulent activities, mismanagement, or waste. Accidental Damage: This occurs when individuals unknowingly modify information or erase pages and documents. Accidental threats to information integrity overlap with the issues discussed under availability. The distinction is based on whether the distortion is discovered. If so, the distortion would be generally be considered to consist of a loss of information and would therefore be considered to be a availability problem. When the damage remains undetected, decisions may be made or other actions may be taken based upon incorrect information, resulting in a failure of integrity. 8.2.3 Threats to Information Confidentiality Specific threats to information confidentiality are largely problems of access control. Note that the threats described below apply to confidential information in its various forms, that is, in hard copy, on removable media like diskettes, and on printer ribbons. 8-2 ------- Information Security Manual 12/15/89 Magnetic media containing confidential information can be accessed by individuals from whom the information should be restricted. If diskettes containing confidential information are not secured, unauthorized indi- viduals can install them on a microsystem and browse their contents. Unauthorized individuals could see information on a screen or printout if confidential data are processed in an unsecured area or if printouts are not protected in storage. Confidential information can be deciphered from printer ribbons used to print confidential reports. Individuals authorized to access confidential information could deliber- ately share printed reports or magnetic media containing confidential data with unauthorized individuals. 8.3 PROCEDURES TO MAINTAIN AVAILABILITY 8.3.1 Lock-up Media To avoid theft, store media in a locked cabinet or room. 8.3.2 Write Protection Whenever possible, write-protect files to avoid accidental destruction. 8.3.3 Isolated Storage Isolate the critical/high value information on its own storage media. This means dedicating the diskette to the one sensitive document or collection of information. 8.3.4 Backups In general, the most important step to be taken to protect information availability is to make copies of the information. Backups are performed to provide for easy recovery from a disaster. If information has been backed up and if the backup is safely stored, the information will be recoverableno matter what happens. Note, however, that information or documents that have been created since the last backup may have been lost and may need to be re-input. Two backup copies should be made of information or documents of medium-level availability. One of the copies should be a hard copy (paper) version for storage in 8-3 ------- Information Security Manual 12/15/89 the office files. The second copy should be on magnetic media and should be kept in a location other than the original (for example, in the offices of another branch or division). Two backup copies should also be made of information or documents of high-level availability. The paper copy should be stored as above. The copy on magnetic media, however, should be kept in a physically separate, off-site location. 8.4 PROCEDURES TO PRESERVE INTEGRITY The security measures needed to ensure integrity represent a mix of those associ- ated with maintaining availability and those associated with preserving confidential- ity. Availability and confidentiality are almost opposites; backup copies of informa- tion made to enhance availability can aggravate the problem of preventing the disclosure of the information. In a very real sense, however, integrity is the objective in the middle. Integrity involves elements of the availability objective because if information is corrupted or partially destroyed, intact backup copies are essential. On the other hand, integrity involves elements of the confientiality objective because preventing fraud and sabotage are largely problems of controlling access. 8.4.1 Availability-Related Procedures Adhere to all procedures described in Section 8.3. This will ensure that backups are created. 8.4.2 Confidentiality-Related Procedures Adhere to the access control procedures described in Section 8.5. 8.5 PROCEDURES TO PRESERVE CONFIDENTIALITY 8.5.1 Procedures for Medium-Level Confidentiality EPA organizations with statutory authority for certain types of confidential informa- tion may issue security procedures dealing exclusively with a particular type of 8-4 ------- Information Security Manual 12/15/89 information (for example, TSCA or FIFRA CBI). Because of statutory requirements, some of those procedures may be more stringent than those required here. EPA employees must make sure that they also adhere to such organizational standards and procedures. 8.5.1.1 Discourage Traffic Discourage traffic in the area where the word processor is located when in use. Unauthorized individuals should be kept out of the area so that they cannot view data that might appear on the screen. 8.5.1.2 Printer Ribbons Printer ribbons used to print confidential documents should be considered confiden- tial as well. Destroy exhausted ribbons so that they cannot be deciphered by an unauthorized individual. 8.5.1.3 Disposal Be careful when disposing of diskettes or paper containing confidential information. Before the paper is thrown away, it must be shredded or burned. Diskettes must either be degaussed or placed in burn bags. (Degaussing erases information through demagnetization.) 8.5.1.4 Lock-Up Media Lock-up diskettes and paper copies when not in use in a locked cabinet or a locked room. 8.5.1.5 Clear System Clear the system of confidential information after each confidential processing ses- sion. Power-off the unitto clear any volatile memory, that is, random access memory (RAM). 8.5.2 Procedures for High-Level Confidentiality The EPA has only one type of information in this category - National Security Information. Procedures for handling and storing this information are contained in the "National Security Information Handbook" issued by OARM. The Handbook also contains procedures governing self-inspection. 8-5 ------- information Security Manual 12/15/89 9. SECURITY FOR APPLICATION SYSTEM DEVELOPMENT, OPERATIONS AND MAINTENANCE 9.1 INTRODUCTION The determination of application security requirements and appropriate controls requires three-way communication among the owner, application programmer/ system analyst, and processing installation. Once the owner has determined and communicated the system's sensitivity and security objectives, the owner needs to work with the installation and the application programmer/system analyst to develop the appropriate, cost-effective mix of installation and software-based controls. Once the system has become operational, the installation maintains the installation- oriented controls and the owner authorizes users and makes sure the users and the installation adhere to the security requirements. Security issues and concerns must be an essential part of the entire software lifecycle (from development to operation to modification). If they are not, the owner runs the risk the application will be underprotected oroverprotected. Overprotection wastes resources and underprotection requires that security safeguards be imposed afterthe fact. Retrofitting security measures on adeveloped piece of software is both complex and expensive. This section sets forth security procedures for the application system development and operation process. While this section emphasizes the importance of installation involvement in developing a cost-effective mix of system controls, this section deals with security primarily from an application, ratherthan installation, perspective. The focus here is on application systems and the responsibilities of ownership. The responsibilities of installations and custodians are set forth in Sections 6 and 7. This section is to be used as follows: Application Programmers/System Analysts use these procedures to de- termine what security measures must be in place to protect the availability, confidentiality, and integrity of sensitive Agency applications. Owners develop the security specifications and the tests needed for ap- plication certification based on the procedures presented here and based on dialogue with the application developers and processing installation. 9-1 ------- Information Security Manual 12/15/89 Owners then make sure the operational application is protected on an ongoing basis using the procedures presented here. The remainder of this section is organized as follows. The next subsection catalogs and describes the basic application development controls that can be used to achieve the three security objectives. Subsection 9.3 introduces the concept of the software lifecycle and explains how to address, build in, and maintain security controls at the various life cycle stages. The overall structure and content of this section is based in large part on Federal Information Processing Standards Publication (PIPS PUB) 73, entitled "Guidelines for Security of Computer Applications." FIPS PUB 73 is extremely helpful and application developers may wish to consult it for more detailed information on selected topics. A copy is available in the EPA Headquarters library or through the National Technical Information Service. To a lesser extent, this section is also based on the "Management Guide to the Protection of Information Resources" issued by the National Institute of Standards and Technology. 9.2 BASIC DEVELOPMENT CONTROLS This subsection introduces six basic development controls to be used to meet the se- curity objectives of availability, integrity, and confidentiality. The six controls, which are explained in detail below, are as follows: Data Validation User Identity Verification Authorization Joumalling or Logging Variance Detection Encryption Table 9-1 shows the security objective (or objectives) addressed by each of these basic controls. Note that most controls preserve confidentiality and integrity rather than maintain availability. This is because continued availability is often achieved through administrative/procedural safeguards such as backup routines and contin- gency planning. 9-2 ------- Information Security Manual 12/15/89 TABLE 9-1 BASIC CONTROLS AND THE OBJECTIVES THEY ADDRESS Objectives Control Data Validtion User Identity Verification Authorization Joumalling/ Logging Variance Detection Encryption Availability X X X Integrity X X X X X X Confidentiality X X X X X 9-3 ------- Information Security Manual 12/15/89 It should be noted that some of these controls may be partially implemented by the operating system, the hardware, or the management of the processing installation. Such joint implementation results because the boundaries between the application and operating systems or between hardware and software are sometimes fuzzy. 9.2.1 Data Validation Data validation involves checking data to make sure they are accurate, complete, and consistent. This checking or examination should occur both during entry and during processing. In addition, input data elements should be compared with one another to ensure consistency and reasonableness. Techniques for validating data during entry include: Examining fields for various characteristics, including proper format, values within certain bounds, and check digits. Maintaining control totals, record/transaction counts and batch number checks for groups of records or transactions. Techniques for validating data during processing include: Incorporating dummy records into a data base and doing test transactions against these records during normal processing of the application to evaluate processing accuracy. Tracing specially marked transactions through the processing cycle to de- termine if processing was correct. Sampling methods where certain data are selected for close examination to determine their validity. Techniques for ensuring consistency and reasonableness include: Comparing one field against another for a certain relationship, for ex- ample, one field with a value less than half of another field. Evaluating the current record against the previous record. 9.2.2 User Identity Verification User identity verification involves establishing a means to control access to the application by requiring each individual to prove who he/she is. The basic access 9-4 ------- Information Security Manual . 12/15/89 control methods include: (1) passwords, (2) objects like magnetic cards or keys, and (3) personal characteristics such as signatures or voiceprints. User identification based on personal characteristics like signature is prohibitively expensive. For most on-line applications, the most practical technique is a password scheme. There are two predominant types of passwords: (1) Host-level passwords, and (2) information access passwords. Host-level passwords are those used when first logging-on to the computer system, for example, VAX, Prime, or IBM mainframe. A host-level password verifies the identity of the user before the user is allowed to do anything on the system. An information access or "second level" password is used to protect individual files or data sets resident on the computer system. Information access passwords are entered when the logged-on user requests access to a password-protected file or data set. Information access passwords can be either unique like host-level passwords or shared by multiple users needing access to common data. Unique information access passwords require access control software apart from the host- level log-on process. Host-level passwords are administered by the processing installation, as described in Section 6. NDPD (which operates NCC and WIC and supports other sites) does not advocate the use of information access passwords. Instead, the NCC makes Resource Access Control Facility (RACF) available to application owners. RACF bases information access on user identification; Prime and VAX have similar schemes based upon access control lists (ACL). Any contemplated use of information access passwords at an NDPD managed or supported facility must be discussed with the Security Officer for that facility. If information access passwords are selected as a control measure, make sure of the following: Passwords of at least six characters in length can be accepted Passwords must contain at least one alpha and one numeric character Passwords can be deleted or changed in a straightforward, but controlled fashion. 9-5 ------- Information Security Manual 12/15/89 9.2.3 Authorization For automated applications, some users may only be authorized to perform certain functions or to use certain data files. If there are many users of a sophisticated application that has many data files, confidentiality and integrity will be preserved if users are only allowed access to needed functions and files. A basic authorization scheme can be enforced if the application has different interfaces for different purposes, for example, for data entry or for report generation. While the security literature describes many different types of authorization schemes, they all have three essential features. They control: (1) who will have access, (2) what modes of access they will have, and (3) which objects or resources they will be allowed to access. The "who" component includes both users and terminals. Modes of access usually include read-only access, read/Write access, and the like. Objects or resources typically include: Data objects like files, record types, and libraries Executable objects like commands or programs Devices like printers or various storage media such as tapes or disks. Any authorization scheme that is selected should have two basic properties. First, it should operate under the principle of least privilege where users should be limited to only what they need to do. Second, the scheme should be flexible enough to allow for changes in authorization in a straightforward, yet controlled way. 9.2.4 Journalling or Logging Joumalling or logging involves recording particular events as they occur during data entry or processing. Joumalling provides an audit trail for tracking down errors or security violations. Joumalling provides a basis for establishing accountability, that is, a basis for holding individuals responsible for their activities. It also may aid in recovering from a processing mishap or disaster. While it is possible to journal every event and transaction, this is typically impractical and not cost-effective. In selecting what to log, owners and system developers should focus on the type of information and security objectives involved. Clearly a financial system that disburses funds must keep track of who makes each credit and 9-6 ------- Information Security Manual 12/15/89 debit transaction, exactly when each transaction was made, and similar events. In an application where integrity is not as crucial, associating each transaction with a user is probably unnecessary. Any joumalling activity typically falls into one or more of the following categories: Logging the nature of the event (for example, system usage like log-ons, input/output like opening a file, or updates like file changes). Logging the identity of those associated with the event, including users, devices, or files. Logging characteristics of the event such as time, date, or number of data entry errors. 9.2.5 Variance Detection As the term implies, variance detection is concerned with identifying departures from the norm that are deemed to be of significance. Variance detection may either augment an authorization scheme or be used instead of authorization when authorization is impractical. Variance detection can be accomplished through: Review and analysis of the results of the joumalling or logging process External methods such as audits or surprise visits Dynamic monitoring, which involves real-time detection of certain trigger events. For example, an application designed to electronically transmit funds only at certain times could be programmed to warn the console operatoriftransferisattemptedatsomeothertime. As a second example, a system can automatically count the number of attempts made to gain access through password guesses before it ends the log-in session. 9.2.6 Encryption Encryption involves scrambling or encoding information so that it is of no use even if it is obtained by unauthorized individuals. Encryption is the primary means of protecting data during communication. The decision whether or not to encrypt data during communication would depend on the communication configuration. If confi- dential data are being transmitted over a dedicated line, encryption may be unnec- essary unless line tapping is a serious threat. If the data are traveling over a network 9-7 ------- Information Security Manual 12/15/89 where many unauthorized users could potentially intercept the information, encryp- tion may be effective. Information stored off-line in tapes or other media may also be encrypted to prevent it from being read if it is stolen. In most instances, however, physical security measures (such as keeping the media under lock and key) are easier to implement and are adequate. The encryption of on-line data files will be cumbersome unless the operating system and hardware have certain supporting capabilities. In most instances, a password protection scheme should probably be sufficient. In instances where it is deemed necessary to supplement the passwords with encryption, choose a processing location like the NCC where the supporting hardware and operating system features are already in place. 9.3 CONTROLS AND THE SOFTWARE LIFECYCLE 9.3.1 The Software Lifecycle The only way to ensure that the kind of controls described in Section 9.2 are correctly implemented is to make them an explicit part of the software development process. The three-volume "EPA System Design and Development Guidance" issued by OIRM describes the software design and development process at EPA and includes general references to security at appropriate points. The "Operations and Mainte- nance Manual," also issued by OIRM, completes the guidance for managing the software lifecycle by addressing the day-to-day performance of system operations and maintenance activities. It also includes general references to security at appro- priate points. The purpose of this section is to describe more specifically how to incorporate security controls into the lifecycle. The "EPA System Design and Development Guidance" and the "Operations and Maintenance Manual" define four basic lifecycle phases: Phase 1: Mission Need Analysis Phase 2: Preliminary Design and Option Analysis Phase 3: System Design, Development, and Implementation, including system testing and evaluation 9-8 ------- Information Security Manual 12/15/89 Phase 4: Operations and Maintenance At a minimum, application development and operation need to include security specifications, security design reviews, system tests of security controls, and ongoing system monitoring to ensure controls are implemented. Table 9-2 presents the relationship between these requirements, the EPA lifecycle, and the participants or roles associated with the lifecycle. The process begins with the owner's determination of sensitivity and relevant security objectives. The next step is to develop control requirements based on Section 9.2. Determining a cost-effective mix of adequate controls depends on the owner understanding why the application is sensitive (that is, relevant security objectives and degree of sensitivity) and the types of controls the processing installation can provide to address that sensitivity. If the availability objective is relevantto the application, the owner needs to determine backup and availability requirements and communicate them to the installation. The owner then needs to make sure the installation can satisfy any special requirements, such as more frequent backup than is typical or the need for continuous availability (that is, downtime of more than just a few hours would be unacceptable). As the development process proceeds, the owner creates the security information needed for the Application Certification Worksheet. Please see Appendix B. The development process ends with the application being placed into use or produc- tion. This is a formal milestone that clearly separates the developmental version of the system from the operational version. At this point, key security responsibilities transfer to the installation; the required installation controls are specified in Section 6. Once the system is ready to use, the owner needs to make decisions about who can access the system and what kind of access they will have (for example, read- only access). The responsibilities of ownership do not end atthis point, however. On a continuing basis, the owner needs to make sure the application is protected and that the users and installation adhere to security requirements. In the middle of the development process, the focus is on security design and testing. These activities are the subject of Subsection 9.3.2 below. 9-9 ------- Information Security Manual 12/15/89 TABLE 9-2 SECURITY AND THE SOFTWARE LIFECYCLE Lifecycle Phase Security Activity Role/ Participant Mission Need Analysis Preliminary Design and Options Analysis System Design, Development, and Implementation Operations and Maintenance Identification of Security Needs and Considerations Determine Security Requirements and Specifications Design Controls; Conduct Design Review; Test and Review Security Controls; Determine Backup and Availability Requirements Maintain/Alter Security Controls as needed; Authon'ze Users; Monitor Users/Installation for Compliance with Security Requirements Owner Owner with Application Programmer/ System Analyst and Mini/ Mainframe Computer Security Officer Application Programmer/System Analyst with Owner Conducting Reviews; Owner Determines Back- up and Availability Needs Owner with Applic- ation Programmer as needed and Mini/ Mainframe Computer Security Officer Implementing Installation- Based Controls 9-10 ------- Information Security Manual 12/15/89 9.3.2 Implementing Controls: Building Security into the Development Phase 9.3.2.1 Designing for Security This is the stage when decisions about how to implement the basic development controls must be made. Security considerations should be an integral part of the overall design effort because security opportunities missed now will be difficult to recapture later. In designing the necessary basic controls, adhere to the following overall procedures: Restrict user interfaces to the functions and files users need to access. Unnecessary flexibility greatly complicates security. Limit the number of - unsuccessful attempts to access an application or file. It should be noted that certain processing facilities have made access control features readily available. For example, Resource Access Control Facility (RACF) is available on the NCC IBM mainframe and on the logical mainframes. RACF can be used to protect data sets from unauthorized users or from deletion. The NCC and other installations also limit the number of consecutive password failures before a user is blocked from the system. See the "NDPD Operational Policies Manual" for more information. Design user interfaces that are easy to understand. This reduces user errors and the potential for data corruption. Specific engineering tasks can include intelligible system and error messages and on-line help functions. If the application will be used continuously and has significant storage re- quirements, consider dedicating a micro or minicomputer to the applica- tion. The choice of hardware environment involves many other factors, including needed physical security, access controls, and logging/auditing capability. Dedicated hardware, such as a micro or minicomputer, can make it easier to protect software and data. In many circumstances a mainframe environment may be more appropriate. This is why three-way communication among the owner, application developer, and installation is important. Isolate the code that is critical to security. If possible, create separate mod- ules for the security controls, which facilitates both protection and audit. Consider using automated controls to protect these modules. These include: (1) checksums on the object code to detect unauthorized changes, (2) hardware protection states or domains to protect code, and (3) placin g critical code in a fixed area of memory so that read-only memory can be used. Design the system so that it is auditable, that is, so that it is relatively easy to confirm that the system is functioning as it was intended to function. Systems that are not designed for auditability are harder to test and evaluate. If availability is important, design the system so that recovery from minor 9-11 ------- Information Security Manual 12/15/89 problems or major disruptions is facilitated. For example, if a computer at another site has been designated as a backup, make sure the system is readily transportable to the alternative environment. 9.3.2.2 Programming for Security Programming practices can have three impacts on security. First, errors in program- ming security controls (such as joumalling or logging) can limit or cancel the effec- tiveness of the control. Second, programming errors in the non-security-related portions of the code can greatly affect data reliability and accuracy. Finally, unauthorized additions or changes to the code by programmers can result in fraud or abuse. During the programming stage, adhere to the following practices: Have each section of the code peer-reviewed as it is completed. The review should focus on the efficiency, maintainability, and correctness of the code. Have the program library: - Limit access to program modules to authorized individuals - Record all accesses to program modules - Store previous versions of a module so that comparisons with the present version can be made. Document all security-related portions or modules of code. Security- related code is code that implements basic controls, code that accesses sensitive data, or code that processes sensitive data. Once the documen- tation is developed, it also needs to be protected so that the integrity or confidentiality of the system are not compromised. 9.3.2.3 Testing and Evaluating Software The last thing the application developer needs to do is to test the software to make sure it meets the security requirements. Effective testing begins with the develop- ment of a test plan, which describes what will be tested with what methods. For effective security testing, particular emphasis should be placed on how the applica- tion handles unusual, unlikely, and illegal events. The test plan should include both static evaluation and dynamic evaluation. For 9-12 ------- Information Security Manual 12/15/89 static evaluation, the following techniques are recommended: Code review by an independent party Source code analyzers to provide details about selected characteristics of the source program Penetration analysis to determine whether a determined individual could bypass controls. Dynamic evaluation is concerned with testing the operation of portions of the program with dummy data and comparing the results with the expected results. To aid in the evaluation process, the following techniques are recommended: Program analyzers to collect operating data about the executing program, for example, the number of times a particular data file is accessed Comparative analysis, which involves testing the new system for known flaws in similar existing systems. If disclosing confidential information is a security concern, care should be taken when granting individuals testing the software access to "live" data from the operational environment. 9.3.3 Operating and Maintaining Controls Security considerations do not cease once the application becomes operational. Even the best conceived and developed controls need to be managed on a continuing basis. In operating and maintaining security safeguards, adhere to the following procedures: As the system becomes operational, the owner needs to make decisions about who can access the system and what kind of access they will have (for example, read-only access). The responsibilities of ownership do not end at this point, however. On an ongoing basis, the owner needs to make sure that the application is protected and that users and the installation adhere to security requirements. At a very minimum, the application must be re-certified every three years (see Appendix B). Mechanisms for ensuring ongoing compliance can vary from system to system. If, for example, journallmg/logging or variance detection are important controls, the owner can request that the installation produce standard reports. If frequent backup is essential, the owner can simulate a disaster by requesting that certain files be restored within a specified time period. Or, the owner may structure an internal control review or related study as part of the Agency's internal control review process to 9-13 ------- Information Security Manual 12/15/89 gauge user and installation compliance with security requirements. In monitoring compliance, it is not expected that the owner will have a detailed technical understanding of how all his/her security controls work (for example, how an encryption algorithm operates or how variance detection code operates), but ratherthat he/she will take the steps needed to be confident that the system is adequately protected. Maintenance programmers are subject to the same procedures as system development programmers for programming, testing, and evaluating software (see Section 9.3.2). In addition, if disclosing confidential infor- mation is a security concern, care should be taken when granting main- tenance programmers access to "live" confidential systems for problem identification or testing purposes. 9-14 ------- Information Security Manual 12/15/89 10. SECURITY FOR PAPER AND MICROFORM RECORDS 10.1 INTRODUCTION The purpose of this section is to describe the security measures that need to be taken to ensure adequate protection of collections of paper and microform (that is, microfiche and microfilm) records. The focus here is not on normal desk or office files, but rather on significant quantities of records that constitute manual information systems. This section is to be used as follows: Owners develop the security requirements for the information collection based on the procedures presented here. Records Management Officers assign responsibility for the physical custody of the records and make sure that custodians are properly implementing these procedures. Custodians are responsible for making sure the necessary security controls are in place. The remainder of this section is organized as follows. The next subsection explains the relationship between this section and other Agency security procedures, for example, the TSCA CBI Manual." Subsection 10.3 catalogs and describes specific threats to the security of manual information systems. The last three subsections set forth security measures for ensuring the availability, integrity, and confidential- ity of record systems. If more than one objective applies to the record system (for example, availability and confidentiality), make sure to review the subsection for each applicable objective. 10.2 RELATIONSHIP TO OTHER PROCEDURES Over the years, the EPA has developed several sets of procedures governing specific types of sensitive information. The great majority of these existing proce- dures deal with some type of confidential information, especially CBI. These procedures are typically issued by EPA organizations with statutory authority forthe information (for example, the Office of Pesticides and Toxic Substances for TSCA 10-1 ------- Information Security Manual 12/15/89 or FIFRA CBI). EPA employees must make sure they adhere to all of these organizational standards and procedures, as well as to the procedures presented here. The scope and nature of these other, type-of-information procedures is as follows: The Office of Administration and Resources Management has issued procedures governing National Security Information (in the "National Security Information Handbook") and Privacy Act data. The NSI hand- book also contains self-inspection procedures for organizations dealing with National Security Information. The Office of Pesticides and Toxic Substances has developed manuals governing both TSCA and FIFRA CBI. The Office of Solid Waste and Emergency Response has issued proce- dures concerning RCRA CBI. The Office of Enforcement and Compliance Monitoring has established enforcement docket security procedures for handling and disposing of docket reports. Within the Office of Air and Radiation, the Office of Mobile Sources has procedures for the handling of proprietary data received from auto manufacturers and the Office of Air Quality Planning and Standards (Emission Standards and Engineering Division) has procedures for safe- guarding the CBI it receives. The Office of the Inspector General Manual contains sections dealing with confidential information obtained during the course of investigations and audits. The Office of Water has developed procedures related to trade secret data obtained under Section 308 of the Clean Water Act. Most of these procedures contain special instructions and handling requirements. To make sure they are in compliance, EPA employees must review these other procedures when appropriate. 10.3 THREATS TO MANUAL INFORMATION SYSTEMS 10.3.1 Threats to Availability Specific threats to record availability include: Theft: Paper and microform records are small, light, and easily moved. 10-2 ------- Information Security Manual 12/15/89 Accidental Destruction of Records: A record may be accidentally de- stroyed or lost through an act of nature (such as a flood or fire) or through human error (such as inadvertently throwing it away). Deliberate Destruction of Records: Records can be deliberately de- stroyed by malicious individuals. Such destruction can be the result of random vandalism, but it can also be an act by an employee who has been dismissed, disciplined, or is hostile to the mission of the office. 10.3.2 Threats to Integrity Specific threats to record integrity include: Accidental Damage: This occurs when individuals inadvertently and unknowingly change records. While this is a common threat to automated information systems, it is less prevalent for manual systems. It would occur, for example, if a system of records became jumbled. If the disorganization went undetected, decisions could be made based on information that seemed complete, but was not because crucial informa- tion had been misfiled elsewhere. Deliberate Distortion of Records Through Fraud and Sabotage: The integrity of records can be damaged by the deliberate actions of individu- als with access to the records. These actions could be motivated by revenge (for example, by recently disciplined or reprimanded employees) or could be intended to perpetrate or cover up fraudulent activities, mismanagement, or waste. 10.3.3 Threats to Confidentiality Threats to confidentiality are largely problems of access control. Specific threats to record confidentiality include: Unauthorized Disclosure: If rooms or cabinets housing confidential rec- ords are not secure, unauthorized individuals can open them and review the records. Unauthorized disclosure can alsooccurif authorized individu- als deliberately share confidential records with unauthorized individuals. Typewriter and Printer Ribbons: Confidential information can be deci- phered from typewriter and pri nter ribbons that have been used to produce confidential reports. 10-3 ------- Information Security Manual 12/15/89 10.4 PROCEDURES TO MAINTAIN AVAILABILITY 10.4.1 Procedures for Medium-Level Availability 10.4.1.1 Environmental Controls To avoid water damage, do not store the records directly beneath sprinkler heads or water pipes. Do not locate the records near boiler rooms or water heaters. 10.4.1.2 Access Control List The information owner must establish for the custodian a list of individuals who are allowed access to the records. On a quarterly basis, the owner should review the list to update it with employee additions or deletions. 10.4.1.3 Document Control and Tracking To prevent the loss of records, establish a document control and tracking system. This system may be automated or manual. In either the case, the system must include: A unique identifier, the Document Control Number (DCN), for each document in the collection of records. A cradle-to-grave tracking capability which follows a record from the time it is received or written until it is destroyed or transferred elsewhere. For a manual system, the worksheets shown as Exhibits 10-1 and 10-2 can be used. Exhibit 10-1 isaninventoryofallrecordsinthecollection. Exhibit 10-2 is a sign-out log indicating who has which records. Automated tracking systems should capture the same information shown in the exhibits, that is: - Date record created or received - DCN - Dates record checked out and returned - Identity of who has a checked out record - The disposition of a record, that is, transter or destruction 10.4.1.4 Backup Copy Maintain a second copy of the records at an off-site storage location. In the event of a major disaster that destroys the original set of records, this second set will prove invaluable. The backup copy may be in several different forms, including microfiche, 10-4 ------- Information Security Manual 12/15/89 EXHIBIT 10-1 INVENTORY Date No. of Document Received DCN Pages Originator Disposition 10-5 ------- Information Security. Manual 12/15/89 EXHIBIT 10-2 SIGN-OUT LOG Date User Information Date Checked Out DCN User Name EPA ID Number Checked In 10-6 ------- Information Security Manual 12/15/89 paper, or word processing diskettes. 10.4.2 Procedures for High-Level Availability This part applies to all record collections that must be available continuously or within one day and/or collections that are of very high value. All procedures set forth in Subsection 10.4.1 also apply here. In addition, the procedures described below will be followed. 10.4.2.1 Fire Protection Store the records in a fireproof file cabinet. 10.4.2.2 More Accessible Backup Copy For critical collections, make sure the second copy that is being stored at an off-site location can be retrieved within a few hours. Storage locations that require one to two days notice to retrieve records are of limited usefulness. 10.5 PROCEDURES TO MAINTAIN INTEGRITY The security measures needed to ensure integrity represent a mix of those associated with maintaining availability and those associated with preserving confidentiality. As was noted earlier, copies of records made to enhance availability can aggravate the problem of preventing the disclosure of information stored in the record collection. In a very real sense, integrity is the objective in the middle. Integrity involves elements of the availability objective because if information is altered or partially destroyed, an intact backup copy is essential. On the other hand, integrity involves elements of the confidentiality objective because preventing fraud and sabotage are largely problems of controlling access. 10.5.1 Procedures for Medium-Level Integrity 10.5.1.1 Availability-Related Procedures Adhere to all procedures described in Section 10.4.1. 10.5.1.2 Confidentiality-Related Procedures Make sure the records are kept in a locked cabinet or a locked room. Use the lock 10-7 ------- Information Security Manual 12/15/89 whenever the records are not in use, not just at night. If the lock is a combination lock, change the combination at least annually or whenever there is a change in who is allowed access to the records. 10.5.2 Procedures for High-Level Integrity All procedures set forth in Section 10.5.1 above also apply here. In addition, store the records in a fireproof cabinet or container. 10.6 PROCEDURES TO PRESERVE CONFIDENTIALITY Preserving confidentiality involves controlling access to information and records. Access controls for manual information systems are of two types: (1) physical, such as door locks, and (2) administrative, such as lists which specify who is allowed access to the records. 10.6.1 Procedures for Medium-Level Confidentiality 10.6.1.1 Access Control List The information owner must establish for the custodian a list of individuals who are allowed access to the records. On a monthly basis, the owner should review the list to update it with any additions or deletions. 10.6.1.2 Document Control and Tracking To maintain accountability and to further control access, establish a document control and tracking system. This system may be automated or manual. Develop and maintain the system in accordance with the procedures described in Section 10.4.1.3. 10.6.1.3 Lock Up Records Make sure the records are kept in a locked cabinet or a locked room. Use the lock wheneverthe records are notin use, not just at night. If the lockisacombination lock, change the combination at least annually or whenever there is a change in who is allowed access to the records. 10.6.1.4 Photocopies A lack of photocopying controls can defeat strong access controls in other areas. It 10-8 ------- Information Security Manual 12/15/89 does little good to lock everything up and log each document in and out if the person using the document is allowed to make copies at will. Only the owner or custodian should be allowed to make photocopies. Photocopying by all others should be prohibited. All photocopies must be entered into the document control and tracking system under their own DCNs. 10.6.1.5 Disposal All confidential paper documents must be shredded or burned before being thrown away. Place discarded microfiche or microfilm into burn bags for proper disposal. 10.6.1.6 Typewriter and Printer Ribbons Ribbons used to produce confidential documents should be considered confidential as well. Place exhausted ribbons in bum bags so that they cannot be deciphered by an unauthorized individual. 10.6.2 Procedures for High-Level Confidentiality The EPA has only one type of information in this category - National Security Information (NSI). Procedures for handling and storing NSI are contained in the "NSI Handbook" issued by OARM. 10-9 ------- Information Security Manual 12/15/89 APPENDIX A INFORMATION SECURITY * 1. PURPOSE. This document establishes a comprehensive, Agency-wide security program to safeguard Agency information resources. This document sets forth the Agency's information security policy for both manual and automated systems and assigns individual and organizational responsibilities for implementing and administering the program. 2. SCOPE AND APPLICABILITY. This document applies to all EPA organiza- tions and their employees. It also applies to the facilities and personnel of agents (including contractors and grantees) of the EPA who are involved in designing, developing, operating or maintaining Agency information and information systems. 3. BACKGROUND a. Information is an Agency asset, just as property, funds and personnel are Agency assets. The EPA is highly dependent upon its information re- sources to carry out program and administrative functions in a timely, efficient and accountable manner. b. The EPA relies on its information collection authority under various enabling statutes to fulfill effectively its environmental missions. The willingness of the regulated community and State and local agencies to supply requested information in a cooperative and timely fashion depends on their confidence that the information will be adequately protected. c. The Agency's information resources are exposed to potential loss and misuse from a variety of accidental and deliberate causes. This potential loss and misuse can take the form of destruction, disclosure, alteration, delay or undesired manipulation. Moreover, the Agency can be subject to acute embarrassment and litigation if certain business or personal infor- mation is inadvertently or maliciously disclosed. d. As a result, it is essential that an overall program be established to preserve and adequately protect the Agency's information resources. At the same time, it is equally essential that the program not unnecessarily restrict information sharing with other Federal agencies, universities, the Source: EPA Information Resources Management Policy Manual, Chapter 8. A-1 ------- Information Security Manual 12/15/89 public and State and local environmental authorities. Such information sharing has historically played a vital role in the overall fulfillment of the Agency environmental mission. e. The management, control and responsibility for information resources within EPA are decentralized. Consequently, the management and re- sponsibility for information security are also decentralized. An important example of this is the expanding use of personal computers, networking, distributed data bases and telecommunications. These trends place new responsibilities on office managers, research personnel and others not previously considered information processing professionals. The "com- puter center" cannot be relied upon to protect Agency operations. Controls must be implemented and maintained where they are most effective. f. In determining responsibilities for information security, it is useful to define a framework of owner/custodian/user. Owners are those who create or maintain information. Custodians are typically suppliers of information services who possess, store, process and transmit the information. These roles are often not discrete; the owner is often the principal custodian and user of the information. 4. AUTHORITIES a. OMB Circular A-130, Management of Federal Information Resources. 5. POLICY. It is EPA policy to protect adequately sensitive information and sensitive applications, maintained in any medium (e.g., paper, computerized data bases, etc.), from improper use, alteration or disclosure, whether accidental or deliberate. Information and applications will be protected to the extent required by applicable law and regulation in accordance with the degree of their sensitivity in order to ensure the cost-effectiveness of the security program. a. Information security measures will be applied judiciously to ensure that automated systems operate effectively and accurately and to ensure the continuity of operation of automated information systems and facilities that support critical agency functions. b. As required by OMB Circular No. A-130, all automated installations will undergo a periodic risk analysis to ensure that appropriate, cost-effective safeguards are in place. This risk analysis will be conducted on new installations, on existing installations undergoing significant change and on existing installations at least every five years. c. Appropriate administrative, physical, and technical safeguards shall be incorporated into all new ADP application systems (including PC-based applications) and major modifications to existing systems. A-2 ------- Information Security Manual 12/15/89 d. As required by OMB A-130, all new applications will undergo a control review leading to formal certification. Existing sensitive applications will be recertified every three years. e. Access to sensitive personnel information and employment applications will be limited to appropriate personnel in accordance with procedures established by the Office of Personnel Management and monitored by the EPA Office of the Inspector General. f. Appropriate ADP security requirements will be incorporated into specifi- cations for the acquisition of ADP related services and products. g. An information security awareness and training program will be estab- lished so that all Agency and contractor personnel are aware of their information security responsibilities. h. Information security must be a major factor in evaluating the use of microcomputers. Microcomputer systems software is typically rudimen- tary and affords little or no protection to information and programs. Consequently, networked microcomputers, the ability to download data from larger, protected computers onto microcomputers and microcom- puter data processing, generally present problems in information security (for example, problems of access control or control overthe dissemination of information). All EPA employees and managers must be aware of the information security implications of storing and processing sensitive infor- mation on microcomputers, whether networked or stand-alone. i. Therefore, it is EPA policy to discourage the use of microcomputers for storing or processing sensitive information, unless cognizant EPA em- ployees and managers have made sure that adequate information secu- rity measures are in use. If adequate information security cannot be maintained, an alternative system configuration must be used. j. Information security violations will be promptly reported to appropriate officials, including the Inspector General. 6. RESPONSIBILITIES a. The Office of Information Resources Management is responsible for: (1) Developing and issuing an information security policy in accordance with all applicable Federal laws, regulations, and executive orders. (2) Ensuring that all Agency organizational units are in compliance with the information security program. (3) Establishing training criteria and coordinating the development of an information security training and awareness program. A-3 ------- Information Security Manual 12/15/89 (4) Providing guidance on selecting and implementing safeguards. (5) Participating as it deems appropriate, in management and internal control re views conducted by the Office of the Comptroller to ensure compliance with the information security program. b. Each "Primary Organization Head" (defined by EPA Order 1000.24 as the Deputy Administrator, Assistant Administrators, Regional Administrators, the Inspector General and the General Counsel) is responsible for: (1) Ensuring that sensitive information and applications within the organi- zation are adequately protected. (2) Establishing an organization-wide program for information security consistent with organizational mission and Agency policy, including assigning responsibility for the security of each installation to a management official(s) knowledgeable in information technology and security. (3) Assure annually the Assistant Administrator for Administration and Resources Management that organizational information resources are adequately protected. This will be done as part of the internal control review process required under OMB Circular No. A-123 (revised) and implemented under EPA Order 1000.24. (4) Making sure that all automated installations within the organization undergo a periodic "risk analysis" to ensure that appropriate, cost- effective safeguards are in place. (5) Ensuring the continuity of operations of automated information sys- tems and facilities that support critical functions. (6) Making sure that appropriate safeguards are incorporated into all new organizational application systems and major modifications to existing systems, that all new organizational applications undergo an informa- tion security review leading to formal certification and that existing sensitive applications are recertified every three years. (7) Making sure that Federal employees and contractor personnel under- stand their security responsibilities and that organizational security regulations are properly distributed. (8) Making sure that all organizational procurements of ADP equipment, software and services incorporate adequate security provisions. c. The Director, Facilities Management and Services Division, is responsible for: (1) Establishing and implementing physical security standards, guide- lines and procedures in accordance with EPA information security policy. A-4 ------- Information Security Manual ' 12/15/89 (2) Establishing and implementing standards and procedures for National Security Information in accordance with EPA information security policy and all applicable Federal laws, regulations and executive orders. d. The Procurement and Contracts Management Division and the Grants Administration Division are responsible for: (1) Ensuring that Agency grant and contract policies, solicitations and award documents contain provisions concerning the information security responsibilities of contractors and grantees that have been promulgated by OIRM. (2) Establishing procedures to ensure that contractors and grantees are in compliance with their information security responsibilities. Project Officers are responsible for ensuring contractor compliance with security requirements on individual contracts. Violations shall be re- ported to the contracting officer, Inspector General and appropriate OIRM official. Specific violations involving National Security Informa- tion shall be reported to the Director, FMSD and the Contracting Officer. e. The Office of the Inspector General is responsible for: (1) Establishing and implementing personnel security standards, guide- lines and procedures in accordance with EPA information security policy and all applicable Federal laws and regulations. (2) Conducting or arranging investigations of known or suspected person- nel security violations as it deems appropriate. f. The Office of the Comptroller is responsible for: (1) Allowing OIRM to review written internal control reports so that OIRM is aware of the status of information security weaknesses. g. Each EPA Manager and Supervisor is responsible for: (1) Making sure their employees are knowledgeable of their information security responsibilities. (2) Ensuring that their employees adhere to the organizational informa- tion security program established by the applicable Primary Organiza- tion Head. h. Each EPA Employee, Contractor and Grantee is responsible for: (1) Complying fully with his/her information security responsibilities. (2) Limiting his/her access only to information and systems he/she is authorized to see and use. A-5 ------- Information Security Manual 12/15/89 (3) Adhering to all Agency and organizational information security poli- cies, standards and procedures. (4) Reporting information security violations to appropriate officials. Violations involving National Security Information shall also be re- ported to the Director, FMSD. 7. DEFINITIONS. a. "Applications Security" means the set of controls that makes an informa- tion system perform in an accurate and reliable manner, only those functions it was designed to perform. The set of controls includes the fol- lowing: programming, access, source document, input data, processing storage, output and audit trail. b. "Confidential Business Information" includes trade secrets, proprietary, commercial/financial information, and other information that is afforded protection from disclosure under certain circumstances as described in statutes administered by the Agency. Business information is entitled to confidential treatment if: (1) business asserts a confidentiality claim, (2) business shows it has taken its own measures to protect the information, (3) the information is not publicly available or (4) disclosure is not required by statute and the disclosure would either cause competitive harm or impair the Agency's ability to obtain necessary information in the future. c. "Information" means any communication or reception of knowledge such as facts, data or opinions, including numerical, graphic, or narrative forms, whether oral or maintained in any medium, including computerized data bases (e.g., floppy disk and hard disk), papers, microform (microfiche or microfilm), or magnetic tape. d. "Information Security" encompasses three different "types" of security: applications security, installation security and personnel security. In total, information security involves the precautions taken to protect the confi- dentiality integrity and availability of information. e. "Information System" means the organized collection, processing, trans- mission and dissemination of information in accordance with defined procedures, whether automated or manual. f. "Installation" means the physical location of one or more information systems, whether automated or manual. An automated installation consists of one or more computer or office automation systems including related peripheral and storage units, central processing units, telecommu- nications and operating and support system software. Automated instal- lations may range in size from large centralized computer centers to stand-alone personal computers. g. "Installation Security" includes the use of locks, badges and similar measures to control access to the installation and the measures required A-6 ------- Information Security Manual 12/15/89 for the protection of the structure housing the installation from accident, fire and environmental hazards. In addition to the above physical security measures, installation security also involves ensuring continuity of opera- tions through disaster planning. h. "National Security Information" means information that is classified as Top Secret, Secret, or Confidential under Executive Order 12356 or predeces- sor orders. i. "Personnel Security" involves making a determination of an applicant's or employee's loyalty and trustworthiness by ensuring that personnel inves- tigations are completed commensurate with position sensitivity definitions according to the degree and level of access to sensitive information. j. "Privacy" is the right of an individual to control the collection, storage and dissemination of information about himself/herself to avoid the potential for substantial harm, embarrassment, inconvenience or unfairness. k. "Risk Analysis" is a means of measuring and assessing the relative vulnerabilities and threats to a collection of sensitive data and the people, systems and installations involved in storing and processing that data. Its purpose is to determine how security measures can be effectively applied to minimize potential loss. Risk analyses may vary from an informal, quantitative review of a microcomputer installation to a formal, fully quantified review of a major computer center. I. "Sensitive Information" means information that requires protection due to the risk and magnitude of loss or harm that could result from inadvertent or deliberate disclosure, alteration or destruction of the information. For the purposes of this program, information is categorized as being either sensitive or not sensitive. Because sensitivity is a matter of degree, certain sensitive information is further defined as being "highly" sensitive. Highly Sensitive: This is information whose loss would seriously affect the Agency's ability to function, threaten the national security or jeopardize human life and welfare. Specifically, information of this type includes National Security Information, in- formation critical to the performance of a pri- mary Agency mission, information that is life critical and financial information related to check issuance, funds transfer and similar asset ac- counting/control functions. Other Sensitive: This is information whose loss would acutely embarrass the Agency, subject the Agency to litigation or impair the long-run ability of the Agency to fulfill its mission. Information of this A-7 ------- Information Security Manual 12/15/89 type includes Privacy Act information, Confi- dential Business Information, enforcement con- fidential information, information that the Free- dom of Information Act exempts from disclo- sure, budgetary data prior to release by OMB and information of high value to the Agency or a particular organization (see below). The sensitivity if any, of all other information, shall be determined by the organizational owner of the information. While a precise set of criteria for determining the sensitivity of this other information cannot be provided, the cost of replacing the information and the problems that would result from doing without the information are primary factors to consider in de- termining sensitivity. m. "Sensitive Applications (or Systems)" are applications which process highly sensitive or sensitive information or are applications that require protection because of the loss or harm which could result from the improper operation or deliberate manipulation of the application itself. Automated decision-making applications are highly sensitive if the wrong automated decision could cause serious loss. 8. PROCEDURES AND GUIDELINES. Standards, procedures and guidelines for the Agency information security program will be identified and issued under separate cover in the "Information Security Manual." This manual will identify and reference, as appropriate existing procedures in the information security area, such as the "Privacy Act Manual," the "National Security Information Security Handbook," and Confidential Business Information manuals like the TSCA Security Manual. 9. PENALTIES FOR UNAUTHORIZED DISCLOSURE OF INFORMATION. a. EPA employees are subject to appropriate penalties if they knowingly, willfully or negligently disclose sensitive information to unauthorized persons. Penalties may include, but are not limited to, a letter of warning, a letter of reprimand, suspension without pay, dismissal, loss or denial of access to sensitive information (including National Security Information), or other penalties in accordance with applicable law and Agency rules and regulations, which can include criminal or civil penalties. Each case will be handled on an individual basis with a full review of all the pertinent facts. The severity of the security violation or the pattern of violation will determine the action taken. b. Nqn-EPA personnel who knowingly, willfully or negligently disclose sen- sitive information to unauthorized persons will be subject to appropriate laws and sanctions. A-8 ------- Information Security Manual 12/15/89 APPENDIX B APPLICATION RISK ANALYSIS AND APPLICATION CERTIFICATION A. The Certification Process Owners should review Section 2.4 before proceeding with this Appendix. That section contains information on combining applications for certification purposes. Owners should also note that in working through this Appendix a qualitative risk analysis is performed, that is, relative vulnerabilities and threats are assessed and safeguards are specified. 1. New Applications Each new sensitive application must undergo initial certification and then re- certification every three years. This certification must take place prior to the appli- cation being put into use or production. The certification or recertification will begin with the application owner's completion of the Certification Worksheet, Exhibit B-1. The worksheet and specific instructions for completing it are described in Section B. For PC applications, the Certifying Official, PC site coordinator, and PC custodian will be available to answer owner questions on an as needed basis. For minicom- puter/mainframe applications, the Minicomputer/Mainframe Security Officer, the Systems Analyst, and the Applications Programmer must not only answer questions on an as needed basis, but they must also be an integral part of the process. The determination of security requirements and appropriate controls requires communi- cation among all these parties. Safeguards to meet the owner's sensitivity requirements can be placed in the application itself and/or at the installation level. How the application is ultimately protected depends upon the safeguards already in place at the installation (and the results of the installation risk analysis) and the particular threats to the application. After completing the worksheet, the owner will forward it to his/her immediate supervisor for review. The supervisor will review the worksheet for completeness and then forward it to the designated Certifying Official. The Certifying Official will either certify that the application is adequately safe- B-1 ------- Information Security Manual 12/15/89 EXHIBIT B-1 CERTIFICATION WORKSHEET AND EXAMPLE SENSITIVE APPLICATION CERTIFICATION WORKSHEET 1. APPLICATION TITLE RCRA Settlement Offers 2. OWNER ImaSafe OSWER, OSW 3. TYPE(S) OF INFORMATION Enforcement confidential; high value 4. SENSITIVITY LEVEL & OBJECTIVE Confidential: Medium Level Availability: Medium Level 5. PROCESSING ENVIRONMENT Standalone; non-removable and removable media; shared user; Room 1123, West Tower, Washington, D.C. 6. DESCRIPTION Database application that tracks settlement offers by case. All users of PC may see confidential data. 7. SECURITY SPECIFICATIONS/REQUIREMENTS Controls to Maintain Availability - Back-up database to diskettes in accordance with the procedures manual. - Identify backup computing facility. b. Controls to Maintain Integrity (Minimal controls only) Controls to Maintain Confidentiality - Keep PC and removable media in a locked room. - Establish a formal list of authorized users. 8. EVIDENCE OF ADEQUACY/DESIGN REVIEW Check to make sure door took installed. Check to see that formal list of authorized users created. Are backups created by user? Memorandum outlining agreement for backup facility. 9. TEST SCENARIO AND RESULT Lock installed on 6-15-89. List developed on 6-5-89. Local backups kept in adjacent office; archival backup stored in Crystal City. Memorandum with PC custodian in same branch executed 6-15-89. 10. CERTIFIED _NOT CERTIFIED B-2 ------- Information Security Manual 12/15/89 guarded or deny certification by marking the appropriate box on the worksheet and returning it to the supervisor. A Certifying Official may conclude that safeguards are adequate if the application is protected in accordance with the procedures set forth in Sections 6-9 of this manual. When certifying the application, the Certifying Official must mark the appropriate box on the worksheet and sign the one-page certification statement shown as Exhibit B-2. These documents must be retained on file for inspection by OIRM, auditors, or the Office of the Inspector General. Recertification of the operational application should be based on reviews or audits that test and evaluate the adequacy of implemented safeguards and that identify any new vulnerabilities. These reviews or audits should be considered part of vulnera- bility assessments and internal control reviews conducted in accordance with OMB Circular No. A-123. 2. Existing Applications Each existing sensitive application must also undergo initial certification (and recer- tification every three years) in accordance with the instructions above. However, to avoid overwhelming organizations, initial certification may take place on a phased basis over the next two years. All initial certifications of existing systems should be complete by the end of 1991. More sensitive applications (as defined in Section 4) and those for which security plans were prepared (as described in Section 2.6) need to be certified first and as expeditiously as possible (by the end of 1990 at the latest). Because of their overall organizational knowledge, SIRMOs may be able to quickly prioritize applications for certification. B. The Certification Worksheet The certification worksheet should be completed by the application owner as follows. The numbers below correspond to the numbered blocks on the worksheet. The worksheet has been filled in with a PC application as an example of what is expected. In instances where major applications have many security requirements, owners may wish to reproduce the worksheet several times, using one copy for each individual requirement. 1. Application Title: Provide the name of the information system or applica- tion. B-3 ------- Information Security Manual 12/15/89 EXHIBIT B-2 CERTIFICATION STATEMENT I have carefully examined the information presented on the Certification Worksheet for (application name} . dated . Based on my authority and judgement, and weighing any remaining risks against operational requirements, I authorize con- tinued operation of (application name) under the restrictions/conditions listed below. (List any Restrictions and Special Conditions 01 enter "None") (Signature and Date) B-4 ------- Information Security Manual 12/15/89 2. Owner: List the application owner and organization. 3. Type of Information: Indicate the type of sensitive information (for example, CBI or high value) in terms of Section 4 of this manual. 4. Sensitivity Level and Objective: Provide the relevant security objective (for example, availability) and the associated sensitivity level (for ex- ample, high level). 5. Processing Environment: For PC applications, describe the processing environment in terms of shared versus single user PC, removable versus non-removable storage media, and standalone processing versus com- municating with other equipment. Also indicate the physical and geo- graphic location of the system. For other applications, describe the processing hardware, the communications configuration, the user com- munity, and the physical and geographic location of the system. 6. Description: Provide a brief functional description of the application. 7. (a)-(c). Security Specifications/Requirements: For PC applications, ex- press the needed availability, integrity and/or confidentiality security controls in terms of Section 7 of this manual. For other applications, describe the needed availability, integrity, and/or confidentiality controls in terms of Sections 6 and 9. 8. Evidence of Adequacy/Design Review: Indicate how the owner will ensure the security specs are being implemented. 9. Test Scenario and Results: Describe how the owner will satisfy himself/ herself that the safeguards work orthatthe procedures are being followed. 10. Certifying blocks to be checked by the Certifying Officer as appropriate. The application owner should note that the worksheet can also be used as a set of security procedures for the application's users. In other words, the worksheet can be used to communicatethe sensitivity of the application and the security procedures to the user. B-5 ------- Information Security Manual 12/15/89 APPENDIX C INSTALLATION RISK ANALYSIS A. Background A risk analysis is a means of measuring and assessing the relative vulnerabilities and threats to an installation. Its purpose is to determine how security safeguards can be effectively applied to minimize potential loss. In everyday terms, risk analysis is simply a procedure for identifying what could go wrong, how likely it is that things could go wrong, and what can be done to prevent them from going wrong. Risk analyses may vary from an informal, qualitative review of a microcomputer or minicomputer installation to a formal, fully quantified review of a major computer center. Forall Agency installations, including PCs and WP equipment, a qualitative approach may be used (see part C below). B. Applicability and Required Schedule All Agency installations, including PCs and word processors, are required to undergo a risk analysis. An installation risk analysis shall be performed: Prior to the approval of design specifications for a new installation. In the case of a PC or WP, the risk analysis shall be performed at the time the equipment is installed. Whenever a significant change occurs to the installation. ForaPCorWP installation, significant changes include: - Physically moving the equipment to another location - Going from a single user to multiple users, or vice versa - Altering the communication configuration, for example, adding a dial- up capability or becoming part of a LAN. For a minicomputer/mainframe installation, significant changes include, but are not limited to: - Adding new equipment that is not the same as existing equipment - Adding new technology C-1 ------- Information Security Manual 12/15/89 - Adding dial-up capability It is difficult to specify a precise set of criteria for identifying significant changes for mini/mainframe installations. At a large installation like NCC, adding hardware is commonplace and changing network definitions is also common; for the NCC, these do not constitute significant changes. If more guidance is needed to determine if a change warrants a new risk analysis, the Security Officer should consult his/her SIRMO. At least every five years, if no significant change to the installation necessitating an earlier analysis has occurred. Existing installations that have not undergone a risk analysis dun ng the last five years must undergo one by the end of 1990. C. Risk Analysis: Qualitative Approach To perform the qualitative risk analysis required by this manual, the Security Officer or PC/WP custodian should complete the worksheet shown as Exhibit C-1 as follows. The numbers below correspond to the numbered blocks on the worksheet. The worksheet has been filled in for a hypothetical installation as a simple example of what is expected. 1. Location: Provide the physical and geographic location and the organi- zation for the equipment. 2. Custodian and Equipment Type: List the person to whom the equipment is assigned and the type of equipment. 3. Type of Information: Indicate the type of sensitive information (for example, CBI or high value) in terms of Section 4 of this manual. If the Installation does not process any sensitive information, the risk analysis is at an end and only the minimal controls set forth in Section 3 need to be implemented. 4. Number of Sensitive Applications: Indicate the number of sensitive applications processed at the installation. 5. Processing Environment: For a PC/WP, describe the processing envi- ronment in terms of shared versus single user, removable versus non- removable storage media, and standalone processing versus communi- cating with other equipment. For other installations, describe the com- munications environment, the users, the operating system, and installa- tion hardware not described in 2 above. 6. Sensitivity Level and Objective: Provide the relevant security objective (for example, availability) and the associated sensitivity level (for ex- ample, high level). C-2 ------- Information Security Manual 12/15/89 EXHIBIT C-1 INSTALLATION QUALITATIVE RISK ANALYSIS WORKSHEET AND EXAMPLE 1. LOCATION Room 1123, West Tower OIRM 2. CUSTODIAN & EQUIPMENT TYPE R.U. Secure IBM 4381 3. TYPE(S) OF INFORMATION Enforcement confidential; high value 4. NUMBER OF SENSITIVE APPLICATIONS 5. PROCESSING ENVIRONMENT Storage/communications capability located at OIRM: users limited to OIRM and other specifically authorized/trained personnel; OEM operating system. 6. SENSITIVITY LEVEL & OBJECTIVE Confidential: Medium Level Availability: Medium Level 7. CONTROLS TO MAINTAIN AVAILABILITY Disaster recovery/continuity of operations plan developed. Uninterruptible power supply installed. - List of personnel authorized to enter installation established. Visitor log developed; all visitors escorted during visit. 8. CONTROLS TO PRESERVE INTEGRITY See items 7 and 9. 9. CONTROLS TO PRESERVE CONFIDENTIALITY Confidential hard-copy reports stored in a locked cabinet prior to distribution. Confidential reports are delivered by hand in sealed envelopes. Unneeded confidential reports are shredded and outdated magnetic tapes with confiden- tial data are degaussed. Physical access control and visitor control are as described in 7 above. 10. COMMENTS The procedures for all sensitive install- ations described in Section 6.4 have been implemented, including those related to password protection. RACF implemented for sensitive applications. 11. MINIMAL CONTROLS IN PLACE? x YES NO C-3 ------- Information Security Manual 12/15/89 7. Controls to Maintain Availability: Express the needed availability controls in terms of Section 6,7, or 8 of this manual. 8. Controls to Preserve Integrity: Express the needed integrity controls in terms of Section 6,7, or 8 of this manual. 9. Controls to Preserve Confidentiality: E controls in terms of Section 6,7,or 8 of this manual. 10. Comments: Self-explanatory. 11. Minimal Controls in Place: Indicate whether or not the minimal physical and environmental controls described in Section 3 are in place. D. Risk Analysis: Quantitative Approach In essence, a quantitative risk analysis is an exercise in cost/benefit analysis. Specifically, it involves the following steps: Identify the asset to be protected (equipment, application, data, etc.) Determine the threats to the asset - Natural, such as flood or earthquake - Man-made, such as fraud or accidental error Determine the probability the threat will be realized and the dollar loss (re- placement cost, damages, etc.) if the threat is realized. Manipulate the two numbers to obtain the annual loss expectancy (ALE). Calculate the cost of security safeguards. Compare the cost of safeguards with the ALE and implement those controls that are cost-effective. A simple example involving protecting a data base from fire follows: Asset is data base with a replacement cost of $20,000 Threat is fire Rate of occurrence of fire is once every 50 years Annual probability of fire is 2% C-4 ------- Information Security Manual 12/15/89 Annual Loss Expectancy is $400 (.02 x $20,000) Cost of safeguard (fire extinguisher) is $100 with a life of 5 years, or $207 year Obtain the fire extinguisher because it is cost-effective ($20 versus $400). As the example shows, the concept of risk analysis is not difficult and is one the Agency already uses in formulating regulatory policy. What is challenging about risk analysis is identifying all the installation assets and threats and coming up with the needed dollar figures. Once these activities have been performed for the first analysis, however, subsequent risk analyses for the installation should be less time- consuming. There are several different approaches for developing the numbers needed for a quantitative analysis. The procedures presented here are based in large part on Federal Information Processing Standard (FIPS) 65, entitled "Guideline for Auto- matic Data Processing Risk Analysis." Additional analytical concepts presented here are based on information in the HUD "ADP Security Procedures" handbook, the GSA "Automated Information Security" handbook, and the USDA "ADP Security Manual". The approach outlined here should provide a reasonably accurate risk assessment, but other quantitative approaches may also provide accurate results. Security Officers may use alternative approaches if: (1) the approach includes the basic steps outlined at the beginning of this part, and (2) the approach yields all the information required for the risk analysis report (described in Step 5). 1. Step 1: Identify Assets and Determine Threats Any risk analysis must begin with an inventory of installation assets. The essential first question is: "What potentially requires protection?" Basic categories of assets are as follows: Building (furnishings, detection systems, etc.) Supplies Hardware Communication Systems (equipment and service) C-5 ------- Information Security Manual 12/15/89 Environmental "Systems" (power, air conditioning, etc.) Software (operating system and application) Data (source documents, output, files, data bases) Documentation and Procedures. The threats to those assets must then be determined. To assist in this process, Exhibit C-2 has been developed. Exhibit C-2 is a simple matrix which presents assets by threats. To use the worksheet, put a check in each relevant square or matrix cell. For example, fire isathreatto hardware. Note that the threats have been tied to the three security objectives of availability, integrity, and confidentiality. 2. Step 2: Identify Existing Safeguards The next step is to list all security safeguards that are currently in place. Each safeguard also needs to be tied to the asset it is protecting and to the threat it is counteracting. In other words, in terms of the Exhibit C-2 matrix, each safeguard should be tied to one or more squares or cells. It is important to identify existing safeguards early, since additional controls can only be meaningfully selected in light of the existing security baseline. In addition, to the extent that threat/asset combinations are without corresponding safeguards, vul- nerabilities are present. For example, if fire is a threat to hardware and there are no fire protection controls in place, the installation is vulnerable to fire. 3. Step 3: Calculate Annual Loss Expectancies This step involves determining the annual loss expectancy (ALE) of each checked matrix cell. This calculation involves two components: Determining the probability the threat will be realized (or the frequency of occurrence) Determining the dollar loss if the threat is realized (the dollar impact of the occurrence) Note that the frequency of occurrence implicitly incorporates how applicable the C-6 ------- Information Security Manual 12/15/89 Installation: THREAT Availability: Fire Water Storms Earthquakes Environ. System Failures Equip./System Failure Theft Accidental Data Destruction Sabotage Confidentiality: Unauthorized Disclosure Integrity: Fraud Sabotage Accidental Damage EXHIBIT C-2 ASSET/THREAT WORKSHEET Prepared by: Date: Assets Hard- Comm. Environ. Bldg. Sup. ware Systems Systems Soft- ware Data Doc. C-7 ------- Information Security Manual 12/15/89 threat is. For example, if a threat is not relevant to an asset, the frequency of occurrence is zero. To simplify the analysis without reducing its usefulness, the impact and frequency estimates should be rounded to the factors of 10 shown below. This is the approach recommended in FIPS 65. Impact: $ 10 $ 100 $ 1,000 $ 10,000 $ 100,000 $ 1,000,000 $ 10,000,000 $ 100,000,000 Frequency: 100 times a day 10 times a day 1 time a day Once in 10 days Oncejn 100 days Once in 3 years (1000 days) Once in 30 years Once in 300 years This kind of rounding is possible because it really makes little difference to the overall analysis if a threat is realized every 20 years or every 30 years. Similarly, the analysis is not significantly affected by an estimated dollar loss of $80,000 versus $125,000. Impact and frequency estimates can be developed through interviews with Agency operational and technical experts. In many instances, common sense will be of great help. For example, in estimating the frequency of a wind storm, once in three years is probably too often and once in 300 years is probably too long. A more reasonable C-8 ------- Information Security Manual 12/15/89 estimate may be once in 30 years. Similarly, in assigning a dollar impact to fraud involving the payroll system, $1,000,000 is probably too much while $10,000 is too little. $100,000 is probably a reasonable estimate. Oftentimes, impact and frequency estimates are more readily developed for physical or facility-related assets such as buildings or hardware. Estimates for assets such as data or documentation can involve more judgment, making the risk analysis conclusions for such assets less certain. The ALE of a particular asset/threat combination is the product of the annualized fre- quency and impact estimates. To simplify the computation, Exhibit C-3 has been developed. Exhibit C-3 presents ALEs by impact/frequency combinations. For further convenience in performing the analysis, Exhibit C-4 has been developed. Like Exhibit C-2, Exhibit C-4 is a simple matrix which presents assets by threats. The cells in Exhibit C-4 should be filled not with checkmarks, however, but with ALEs. In other words for each checkmark in Exhibit C-2, there should be a corresponding ALE in Exhibit C-4. In developing ALEs, two final items should be noted. First, in developing these estimates, do not factor in the effect of existing safeguards. For example, an existing fire detection system could reduce the dollar loss in the event of a fire, but to include that reduction here would muddy the analysis because it would assume the cost- effectiveness of the existing system. Instead, all ALEs should be developed as if there were no existing security controls. (The cost-effectiveness of existing safe- guards is factored in later in the analysis.) The second item to note is that in many instances it may be useful to make several copies of both Exhibits C-2 and C-4 and to create new asset headings on those copies. For example, Exhibit C-2 includes the assets "software" and "data." Within each of these categories, there may be several different data bases and applications, each with its own unique set of threats. In determining threats for applications and collections of information, always consult with the owner to find out the sensitivity designation and the relevant security objectives. 4. Step 4: Evaluate and Select Safeguards To begin this final analytical step, identify the types of safeguards needed based on C-9 ------- Information Security Manual 12/15/89 EXHIBIT C-3 ALE by IMPACT/FREQUENCY COMBINATION FREQUENCY 1 in 1 in 1 in 1 in 1 in 1 in 10 100 300 30 3 100 10 1 Per Per IMPACT Years Years Years Days Days Day Day Day $10 $300 $3K $30K $300K $100 $300 3K 30K 300K 3M 30M $1,000 $300 3K 30K 300K 3M 30M $10,000 $300 3K 30K 300K 3M 30M $100,000 $300 3K 30K 300K 3M 30M 300M $1,000,000 3K 30K 300K 3M 30M 3COM $10,000,000 30K 300K 3M 30M 300M $100,000,000 300K 3M 30M 300M Source: PIPS 65 C-10 ------- Information Security Manual 12/15/89 EXHIBIT C-4 CALCULATING EXPECTED LOSS ALE WORKSHEET Installation: THREAT Availability: Fire Water Storms Earthquakes Environ. System Failures Equip./System Failure Theft Accidental Data Destruction Sabotage Confidentiality: Unauthorized Disclosure Integrity: Fraud Sabotage Accidental Damage Total Prepared by: Date: Assets Hard- Comm. Environ. Bldg. Sup. ware Systems Systems Soft- ware Data Doc. C-11 ------- Information Security Manual 12/15/89 the procedural guidance in Section 6. This is now the appropriate point to include existing safeguards, so make sure to factor those in to this process. Once the safeguards have been identified, estimate their annual costs. Again, a high degree of precision is unnecessary. For example, if a physical access control system has a cost of $50,000 and a useful life of about 5 years, use $10,000 as the annual cost. Remember, however, that the cost of an existing control is only the annual maintenance cost and does not include the initial installation costs. Those initial costs have already been expended. Construct alternative clusters of safeguards that address the threats to the installa- tion's assets. Compute the costs, benefits, and overall cost-effectiveness of each set of safeguards as shown in Exhibit C-5. Remember that most security measures are effective against more than one threat and will reduce the ALE of several different asset/threat combinations. Indeed, it is this characteristic that makes administrative and physical safeguards so cost- effective. Experiment with various combinations of safeguards until a satisfactory aggregation is achieved. A satisfactory aggregation is one that: (1) addresses all important threats, (2) results in a significant reduction in the ALE, (3) creates overall benefits that are greater than costs, and (4) is affordable for the organization. A satisfactory aggregation need not drive the ALE to 0. Indeed, at an ALE of 0, it is possible that safeguard costs will exceed their benefits. 5. Step 5: Prepare A Report Complete the risk assessment process by documenting the results. There is no standard length required. The report could be 10 pages long or 200 pages long, depending on the size and sensitivity of the installation. The report should include the following sections: Summary of Findings and Recommendations Introduction C-12 ------- Information Security Manual 12/15/89 EXHIBIT C-5 COSTS AND BENEFITS OF SAFEGUARDS (1) ALE Now (2) New ALE with Safeguards (3) Benefits ((1)-(2)) (4) Safeguard Costs (5) Cost-Effectiveness (0) - (4)) Safeguard Safeguard Safeguard Set 1 Set 2 Set 3 C-13 ------- Information Security Manual 12/15/89 Description of Existing Security Controls Discussion of Asset/Threat Combinations and the Overall Risk Profile of the Installation Findings and Recommendations V. Appendix Containing the Risk Analysis Worksheets. C-14 ------- Information Security Manual 12/15/89 APPENDIX D DISASTER RECOVERY AND CONTINUITY OF OPERATIONS PLANNING A. GENERAL A disaster recovery and continuity of operations plan is required for each minicom- puter/mainframe computer processing installation. Preparation of the plan is the responsibility of the installation's Security Officer. The Security Officer may delegate portions of this function to other knowledgeable individuals as long as the coordinat- ing responsibility is retained. These plans cover three distinct areas: Emergency Response Procedures: These are the actions taken during or immediately after an emergency to protect life and property and to minimize the impact of the emergency. Backup: This area involves two components: (1) establishing a routine schedule for backing up programs and data, and (2) determining where those programs and data would run in the event of an emergency. Taken together, the two backup components ensure the continuity of installation operations. Recovery: While the backup area focuses on establishing an alternative, temporary processing capability, the recovery area focuses on restoring a permanent, ongoing capability. Clearly, disaster recovery plans are crucial for ensuring the continued availability of applications identified by owners as being critical or high value Agency applications. To the extent an installation does not process applications of this type, contingency planning is less important. Consequently, installations that only process applica- tions involving confidentiality and integrity should focus primarily on emergency response and recovery; continuity of operations is relatively unimportant for these installations and may be omitted from their plans. Each installation should prepare a plan in accordance with these procedures by the end of 1990. Plans should then by updated on an annual basis. Forward completed plans or updates to your organization's SIRMO. D-1 ------- Information Security Manual 12/15/89 B. STEPS TO DEVELOP THE PLAN 1. Step 1: Determine What Constitutes a Disaster An emergency can vary from a temporary disruption of processing to the complete destruction of the installation. Determine what kinds of events will cause: (1) limited, temporary disruption, (2) major, serious disruption, and (3) catastrophic disruption. If the Asset Threat Worksheets were developed as part of the risk analysis, they can assist in this determination. 2. Step 2: Develop Emergency Procedures Define and describe what needs to happen during and immediately after an emer- gency by developing procedures for: Notifying personnel of the emergency Responding to fire and other acts of nature Evacuating the installation Shutting the hardware down Protecting data and records. These procedures must be written and must identify who will be responsible for what function during the emergency. All installation employees should have an assigned function during an emergency, which may be simply to evacuate the installation immediately and to remain home until called. The procedures should be accompanied by an installation floor plan that shows the location of fire extinguishers, plastic for covering equipment, and other items useful in responding to the emergency. 3. Step 3: Ensure Continuity of Operations Based on owner sensitivity designations, develop a listing of critical and high-value applications. Establish a plan for data and software backup that includes frequency of backup, a retention schedule, and an off-site location for storage. The plan should recognize that transactions that have occurred since the last data backup maybe lost and may need to be re-input. Make sure the plan is responsive to any special owner D-2 ------- Information Security Manual 12/15/89 requirements, such as more frequent backup than is typical. Locate and execute an agreement for an alternative processing site to be used in the event of major or catastrophic damage. Because of cost and compatibility consid- erations, it is probably best to be backed-up by another installation at the EPA, for example, one Prime location backing-up another or WIC and NCC backing each other up. NCC can also back-up regional logical mainframe facilities and will consider backup arrangements for VAX and microVAX. Make sure the agreement is in writing and spells out such key items as the amount of processing capability to be made available, the associated cost, and the extra supplies like blank tapes to be maintained at the backup site. 4. Step 4: Plan for Recovery Develop a plan for re-establishing a permanent, on-going processing installation. Identify a new installation location in the event the old site cannot be rebuilt. Determine how hardware supplies and other needed items will be obtained. Determine how applications will be migrated back to the original processing installation or to the new installation. 5. Step 5: Testing and Training Test the plan. For example, confirm compatibility with the backup processing in- stallation by actually running a critical application there. Train personnel in their emergency responsibilities. 6. Step 6: Prepare a Written Plan Complete the process by documenting the plan. The report should include the following sections: Introduction Definition of Disaster for the Installation Description of Emergency Procedures Strategy for Ensuring Continuity of Operations (not required for installa- tions with only confidentiality and/or integrity as objectives) D-3 ------- Information Security Manual 12/15/89 Plan for Recovery Testing Procedures Training Plan Appendix Containing a Listing of Critical and High Value Applications at Installation. D-4 ------- |