U. S. DEPARTMENT OF COMMERCE INFORMATION TECHNOLOGY SECURITY MANUAL CHAPTER 10, ATTACHMENT 1 INFORMATION TECHNOLOGY MANAGEMENT HANDBOOK INFORMATION TECHNOLOGY SECURITY INTRODUCTION Information technology is essential for accomplishing government programs in today's world. Managers and employees at all levels require timely access to reliable information processing for routine operations and major decisions. Such availability and reliability is based on the integrity and protection of the information systems. The "Computer Security Act of 1987," Public Law 100-235 and Office of Management and Budget (OMB) Circular A-130 require all federal agencies to plan for the security of all sensitive IT systems throughout their life cycle. OMB Circular A-130 also established a minimum set of controls to be included in federal Information Technology (IT) security programs. The program must include the implementation of policies, standards, and procedures which are consistent with government-wide laws and regulations, to assure an adequate level of protection for IT systems whether maintained in- house or commercially. The circular directs agencies to assure: 1. that IT systems operate effectively and accurately; 2. that there are appropriate technical, personnel, administrative, physical, environmental, and telecommunications safeguards in IT systems; and 3. that the continuity of the operations of IT systems that support critical agency functions is preserved. The Department of Commerce (DOC) complies fully with all federal statutes and directives on IT security and provides protection commensurate with the sensitivity of the system or data processed. The Department has established and implemented an IT security program which will provide reasonable and acceptable assurance that sensitive and classified national security IT systems are performing exactly as specified and doing nothing more; that sensitive and classified information is provided adequate protection; that data and software integrity is maintained; and, that unplanned disruptions of processing will not seriously impact mission accomplishment. People, hardware, software, telecommunications, facilities and data together form an IT system that is highly effective and productive. However, all IT systems involve certain risks that must be addressed adequately through proper controls. The policies contained in the Departmental Administrative Order 212-2, "DOC IT Management Handbook," Chapter 10, IT Security, represent management's commitment to assuring confidentiality, integrity, availability and control of the Department's IT resources. This "DOC IT Security Manual," is Attachment 1 to Chapter 10 of the "DOC IT Management Handbook." It combines all policies, procedures, current detailed guidance and methodologies for accomplishing the Department's IT security program. This document is divided into sections which discuss the requirements of the Department's IT security program for specific subjects. It is intended to provide individuals assigned IT security responsibilities and system owners with a more detailed single-source reference document, which will be up-dated as new policies, procedures, techniques, methodologies or program requirements are developed and issued. Relationship to Other Security Programs The Office of Security is responsible for: (1) physical security of facilities and equipment external to computers or telecommunication lines; (2) all procedural matters relating to national security information; (3) matters relating to background and security clearance investigations of personnel; and (4) national emergency planning. For policies relating to these areas, refer to the appropriate Departmental directives, i.e., DAO 207- series. The Office of the Inspector General provides independent oversight through audit and evaluation of the Department's IT security program in accordance with the "Inspector General's Act of 1978." For policies relating to these areas, refer to the appropriate Departmental directives, i.e., DAO 207-10. SECTION 1 PROGRAM REQUIREMENTS A. Purpose: This section describes the Department of Commerce (DOC) Information Technology (IT) Security program that complies fully with all federal laws, regulations and directives and communicates uniform policies for the protection and control of IT resources directly or indirectly relating to the activities of the Department. This section also describes the policies and responsibilities for the establishment, implementation, maintenance and oversight of the IT security program within the Department, for the protection and control of vital DOC IT resources. Basic elements of the Department's IT security program requirements will be identified in relation to assigned responsibilities. B. Overview: Security of IT systems, as described in OMB Circular A-130, requires the protection of automated systems and information while associated with any automated processing activity, and the assurance that the systems do exactly what they are supposed to do and nothing more. IT security requires management controls to ensure authorized access to the information in the systems and proper handling of input, processing, and output. The implementation of an effective IT security program within the Department begins with the establishment of the organizational IT security structure and the assignment of broad responsibilities. Individuals appointed to positions with IT security responsibilities are accountable for compliance with all DOC or federal laws, regulations and policies related to the assigned responsibilities. C. Background and Authority: The DOC IT Security Program is established in compliance with the "Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems," National Security Directive (NSD) 42, "National Policy for the Security of National Security Telecommunications and Information Systems" and Departmental Organizational Order DOO 20-14. D. Scope: The policies contained in this document are applicable to all DOC IT resources at all levels of sensitivity, whether maintained in-house or commercially. These policies are mandatory on all organizational units, employees, contractors, and others having access to and/or using the IT resources of the Department. These policies apply to all automated technology currently in existence and to any new automated technology acquired after the effective date of this policy document. The IT security program focuses on assuring confidentiality, integrity and availability of all IT resources necessary for processing or transmitting the information. The IT security program consists of a number of different elements, including some that would normally come under other security programs. Those elements that are required by the "Computer Security Act of 1987" or OMB Circular A-130 are considered part of the DOC IT security program and are included in this IT Security Manual. E. Policy: The policies stated in the "IT Management Handbook" require that all DOC organizations establish, implement and maintain an IT security program consistent with the Department and government-wide laws, regulations, policies, procedures and standards. The program must include as a minimum, adequate and appropriate levels of protection for all IT resources within the organization, including hardware, software, physical and environmental facilities, telecommunications, administrative, personnel and data. All IT systems will be identified and appropriate controls implemented in the following categories: 1. Management controls; 2. Acquisition/development/installation/implementation controls; 3. Operational controls; 4. IT security awareness and training; and 5. Technical controls. Guidance for each of these categories of controls are included in later sections of this document. Responsibilities for the DOC IT security program starts at the Department level and flows down through management of all organizations to the individual users. 1. The DOC Office for Information Resources Management is responsible for security of DOC IT resources. Non-IT security programs (e.g., theft of computer resources, physical security, personnel security, safeguarding classified material and Inspector General requirements are stated in Section G. below. 2. The head of each operating unit is responsible for adequate protection of the operating unit IT resources. Staff responsibility for IT security shall be monitored by the operating unit Senior Official for Information Resources Management. 3. System owners are responsible for providing adequate and appropriate levels of protection for the IT resources under their control to prevent unauthorized disclosure, effective and accurate processing and continuity of operations for accomplishment of the organization's mission. 4. Each employee of the Department is responsible for the adequate protection of IT resources within their control or possession. IT security program responsibilities are assigned to the Department and all operating units in line with the requirements outlined in section F. below. F. Responsibilities and Process: Department Level The Director for Information Resources Management (IRM) is responsible for information while being processed and/or transmitted electronically, and for the security of the resources associated with these functions. The Director for IRM is the Designated Approving Authority (DAA) for all IT systems processing classified national security information within the Department. This authority cannot be delegated. The Director for IRM will monitor, evaluate and report, as required, to the Assistant Secretary for Administration on the status of IT security within the Department and the adequacy of operating unit IT Security programs. Within IRM, the authority to perform these responsibilities, except DAA for classified systems, will be exercised by the Departmental IT Security Manager. The DOC IT Security Manager monitors, evaluates and reports, as required, to the Director for IRM on the status of IT security within the Department and the adequacy of the programs administered by the operating units. The DOC IT Security Manager will: 1. Develop policies, procedures and guidance establishing, implementing, maintaining and overseeing requirements for the Department's IT security program to be followed by all DOC organizations. 2. Provide guidance and technical assistance to operating units, including analyzing, evaluating and approving all IT system security plans and requirements for IT systems security. 3. Assure DOC IT security oversight through compliance reviews of operating units and organizations and IT security verification reviews of individual systems and participating in Commerce program management oversight processes. 4. Maintain a tracking system and records concerning implementation of the required controls and accreditation status of all DOC IT systems. 5. Establish an IT Security Coordinating Committee and chair regularly scheduled meetings to discuss and disseminate information on IT security matters and concerns. 6. Coordinate the review of all controls for classified IT systems by the Office of Security and the Telecommunications Management Division and evaluate the adequacy of all technical controls for accreditation. 7. Act as the central point of contact for the Department for IT security related incidents or violations. Investigate or cause to be investigated any incidents or violations, maintain records and prepare reports, disseminate information concerning potential threats and report to the Office of Security any violations that come under their area of responsibilities or to the Assistant Inspector General for Investigations any activity which may constitute a violation of law or otherwise is reportable to that office in accordance with DAO 207-10, "Inspector General Investigations." 8. Coordinate with the Department's Office of Security on security matters of mutual interest. Operating Unit Level Senior IRM Official - Each operating unit Senior IRM Official shall conduct an IT security program that ensures appropriate and adequate levels of protection for all IT systems within the operating unit. The Senior IRM official shall: 1. Be the DAA for all sensitive systems within their organization. This approval authority may only be delegated to a senior management official of a subordinate organizational unit, if that official does not have direct control over the IT system being accredited. Delegation of accreditation authority must be requested and approved in advance by the DOC Director for IRM. 2. Assure ownership is assigned for all IT resources within the operating unit (i.e., hardware, software, data, telecommunications, etc.) 3. Appoint an IT Security Officer (ITSO) and alternate for the operating unit. This individual, or alternate, should have the staff responsibility for the operating unit IT Security program. Operating Unit ITSO - The operating unit ITSO shall serve as the central point of contact for the operating unit IT security program with the Departmental IT Security Manager. The operating unit ITSO shall perform the following functions: 1. Represent the operating unit as a voting member of the DOC IT Security Coordinating Committee, attend regularly scheduled meetings to obtain current information on issues relating to federal or DOC IT security policies, regulations, guidelines, share information with the committee about issues or concerns and participate in special subcommittees working to solve Department-wide issues. 2. Ensure that an ITSO and alternate are appointed for each major subordinate organizational component within the operating unit, if appropriate. These individuals will serve as the point of contact for their organizational component IT security program with the operating unit ITSO. 3. Establish and maintain a list of all IT systems within the operating unit and provide an up-to-date list to the DOC IT Security Manager annually. 4. Ensure that an IT System Security Officer (ITSSO) has been appointed for each IT system within the operating unit. 5. Ensure IT security plans are prepared in the proper format for all sensitive and classified IT systems owned and operated by the operating unit. Review and comment on individual IT security plans, ensuring that all corrective actions are completed and submit all plans to the DOC IT Security Manager. Requirements for IT security plans are contained in Chapter 10, Section 10.2 of the "DOC IT Management Handbook" and Section 2 of the "DOC IT Security Manual." 6. Ensure that risk analysis is completed for all sensitive or classified IT systems within the operating unit. Requirements for risk analysis are contained in Chapter 10, Section 10.7 of the "DOC IT Management Handbook" and Section 7 of the "DOC IT Security Manual." 7. Ensure that contingency and disaster recovery plans are developed for all sensitive or classified IT systems within the operating unit. Requirements for contingency and disaster recovery planning are contained in Chapter 10, Section 10.8 of the "DOC IT Management Handbook" and Section 8 of the "DOC IT Security Manual." 8. Maintain a tracking system concerning implementation of the required controls and accreditation status for all operating unit sensitive and classified IT systems. 9. Act as the central point of contact for accreditation of all sensitive IT systems within the operating unit. Ensure that all certification requirements have been met for each system, prior to accreditation. Certification requirements are contained in Chapter 10, Section 10.3 of the "DOC IT Management Handbook" and Section 3 of the "DOC IT Security Manual." The ITSO will submit an accreditation status report quarterly to the DOC IT Security Manager. Accreditation requirements are contained in Chapter 10, Section 10.4 of the "DOC IT Management Handbook" and Section 4 of the "DOC IT Security Manual." 10. Conduct, or cause to be conducted, IT security verification reviews of all operating unit sensitive IT systems every three years. Requirements for IT security verification reviews are contained in Chapter 10, Section 10.5 of the "DOC IT Management Handbook" and Section 5 of the "DOC IT Security Manual." 11. Ensure that all operating unit personnel are provided appropriate IT security awareness and training. IT security awareness and training requirements are contained in Chapter 10, Section 10.17 of the "DOC IT Management Handbook" and Section 17 of the "DOC IT Security Manual." 12. Act as the central point of contact for the operating unit for any type of IT security related incidents or violations. Investigate or cause to be investigated any incidents or violations, maintain records and ensure reports are submitted to the DOC IT Security Manager and disseminate information concerning potential threats to system owners. Requirements for incident and violation reporting are contained in Chapter 10, Section 10.6 of the "DOC IT Management Handbook" and Section 6 of the "DOC IT Security Manual." 13. Ensure that the operating unit has a malicious software policy in place and the required virus detection and elimination software and procedures are available to protect against these threats. Malicious software protection and reporting requirements are contained in Chapter 10, Section 10.6.1 of the "DOC IT Management Handbook" and Section 6.1 of the "DOC IT Security Manual." 14. Ensure that the operating unit has established a policy against the illegal duplication of Copyrighted software. Ensure that all systems are audited for illegal software at least annually and inventories of all software on each individual system is maintained to verify that only legal copies of software are being used. Requirements for software copyright protection, auditing and reporting are contained in Chapter 10, Section 10.12.1 of the "DOC IT Management Handbook" and Section 10.12.1 of the "DOC IT Security Manual." 15. Coordinate with the operating unit Security Office on security matters of mutual interest. In the absence of the ITSO the alternate shall perform all functions normally assigned to the ITSO for the operating unit IT security program. Subordinate Organization ITSO - Not all operating units within the Department will require this level position. A major subordinate organization is defined to mean any large organizational component that has management responsibility for a number of individual IT systems performing separate functions (i.e., Line Office, Laboratory, Regional Office.) The subordinate organization ITSO shall serve as the central point of contact for the subordinate organization IT security program with the operating unit ITSO. If this level of position is determined to be appropriate for the operating unit, the functions of the ITSO for the subordinate organization will generally parallel those specified for the ITSO. System Owner - Responsibility for the protection of IT resources generally falls into two broad categories: custodial and owner. The fulfillment of the protection responsibilities of each is mandatory. 1. All information resources (hardware, software, facilities, data and telecommunications) will be assigned to an owner designated in writing, to the Senior IRM Official of the operating unit. For example, the "owner" of the resources contained within a general support system may be the manager of that facility. Resources located within user areas (i.e., offices or laboratories) may be "owned" by the manager of those areas. To assist with the determination of ownership, individual system boundaries must be established. A system is identified by logical boundaries being drawn around the various processing, communications, storage and related resources. They must be under the same direct management control with essentially the same function, reside in the same environment and have the same characteristics and security needs. Each system will be designated either a general support system or an application system. Chapter 10, Section 10.2 of the "DOC IT Management Handbook" and Section 2 of the "DOC IT Security Manual" contain definitions for general support and application systems. 2. Ownership of information and/or information processing resources may be assigned to an organization, subordinate functional element, a position , or a specific individual. When ownership is assigned to an organizational or functional element, the head of the unit so designated shall be considered the resource owner. Some, but not necessarily all factors to be considered in the determination of ownership are: (a) The originator or creator of data. (b) The organization or individual with the greatest functional interest. (c) Physical possession of the resource. 3. General support system owners are suppliers of data processing services frequently for applications owned by other organizations. Typically these systems are custodians of software, data, input and output produced by the data processing facility to support one or more application owners. Custodial responsibility includes the obligation to comply with applicable security policies and directives, and to administer application owner specified controls and safeguards for the data and programs of those owners. Many of the Department's local area networks will fit into this category. 4. Each system owner shall be responsible to: (a) Determine the sensitivity of the resources for which responsible. (b) Determine the appropriate level of security required which is consistent with federal and DOC laws regulations and directives and protection requirements of the system for confidentiality, integrity or available and ensure that an adequate level of protection is maintained. (c) Be the certifying official and complete all required certification actions, issue a certification statement and prepare an accreditation package which will be forwarded to the DAA for formal accreditation of the system, every three years or when major changes occur to the system, whichever is less. If the certifying official is at a higher level in the organization, the system owner will complete all required certification actions and forward the accreditation package to the certifying official, who will issue the certification statement. Chapter 10, Section 10.3 of the "DOC IT Management Handbook" and Section 3 of the "DOC IT Security Manual" contain certification requirements. (d) Monitor compliance, and periodically re-evaluate previously specified levels of sensitivity and protection. (e) Ensure that all systems are audited for illegal software at least annually and inventories of all software on each individual system is maintained to verify that only legal copies of software are being used. Requirements for software copyright protection, auditing and reporting are contained in Chapter 10, Section 10.12.1 of the "DOC IT Management Handbook" and Section 10.12.1 of the "DOC IT Security Manual." (e) Ensure that each ADP position (including contract positions) are properly designated in accordance with position sensitivity criteria and receive appropriate investigative processing. Refer to Chapter 10, Section 10.9 of the "DOC IT Management Handbook, Section 9 of the "DOC IT Security Manual" and the "DOC Personnel Security Manual" for further guidance. (g) Appoint an individual to serve as the IT System Security Officer (ITSSO) with responsibility to develop, implement and manage the security of the system. ITSSO - The ITSSO for each classified or sensitive system shall perform the following functions: 1. Advise the IT system owner on matters pertaining to IT systems security. 2. Develop, implement and manage the execution of the IT system security program. 3. Prepare, or cause to be prepared an IT system security plan in the proper format for the IT system. Requirements for IT security plans are contained in Chapter 10, Section 10.2 of the "DOC IT Management Handbook" and Section 2 of the "DOC IT Security Manual." 4. Conduct, or cause to be conducted, a risk analysis on the system when there are major changes to the system or every three years, whichever is less. Requirements for risk analysis are contained in Chapter 10, Section 10.7 of the "DOC IT Management Handbook" and Section 7 of the "DOC IT Security Manual." 5. Ensure that contingency and disaster recovery plans are developed, maintained in an up-to-date condition and tested at least annually. Requirements for contingency and disaster recovery plans are contained in Chapter 10, Section 10.8 of the "DOC IT Management Handbook" and Section 8 of the "DOC IT Security Manual." 6. Establish and maintain liaison with any remote facilities or users served by the IT system, the operating unit ITSO, or if appropriate, the subordinate organization ITSO. 7. Monitor changes in hardware, software, telecommunications, facilities and user requirements to ensure that security is not compromised or degraded. 8. Exercise system responsibility or direct activities for password management and control. 9. Arrange for IT security awareness training for the system staff and monitor the user training programs to ensure that personnel receive security orientation before being allowed access to sensitive IT resources. 10. Ensure that positions requiring access to classified information or resources are identified and that incumbents of these positions receive an appropriate level of security clearance before access is granted. 11. Investigate known or suspected security incidents or violations and prepare reports of findings as required in Chapter 10, Section 10.6 of the "DOC IT Management Handbook" and Section 6 of the "DOC IT Security Manual. Verbal and written reports will be made to the operating unit ITSO through the subordinate ITSO, if appropriate. Incidents involving a physical security violation, such as theft or violations of the personnel security, classified information or industrial security programs will be referred to the operating unit Office of Security for investigation. 12. Ensure that the organization abides by the DOC and operating unit malicious software policies and has the required virus detection and elimination software and procedures available to protect against these threats. Malicious software protection and reporting requirements are contained in Chapter 10, Section 10.6.1 of the "DOC IT Management Handbook" and Section 6.1 of the "DOC IT Security Manual." 13. Audit all the systems within the organization for illegal software at least annually and maintain inventories of all software on each individual system to verify that only legal copies of software are being used. Requirements for software copyright protection, auditing and reporting are contained in Chapter 10, Section 10.12.1 of the "DOC IT Management Handbook" and Section 12.1 of the "DOC IT Security Manual." 14. Review IT related procurement specifications for hardware, software or services to ensure that they include adequate security requirements and/or specifications which are commensurate with the sensitivity of the system. 15. Conduct, or cause to be conducted, all activities required for the certification of the system, including preparing the certification and accreditation packages for final approval every three years or when major changes occur to the system, whichever is less. Certification requirements are contained in Chapter 10, Section 10.3 of the "DOC IT Management Handbook and Section 3 of the "DOC IT Security Manual." 16. Coordinate with the operating unit Security Office or local Security Office on security matters of mutual interest (i.e., IT Security). User Level - The primary purpose of IT systems is to support the missions of using organizations. User management bears a great deal of responsibility for their systems and data. In addition to defining the functions to be performed by the system, and its security requirements, the user is directly responsible for the system resources, such as terminals and printers, located within the user areas. In order to assure adequate security within the user areas where these resources are located, user managers will appoint a user ITSSO to be responsible for the IT security within the user area. This individual is responsible for implementing and enforcing the security program at the user's location. The functions of the user ITSSO generally parallel those specified for the ITSSO. Each employee of the Department is responsible for the adequate protection of IT resources within their control or possession. SECTION 2 INFORMATION TECHNOLOGY SYSTEM IDENTIFICATION AND PLANNING A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy to plan for adequate levels of security for each information technology (IT) system from its initial concept phase throughout its life cycle. The objective of IT security planning is to improve protection of IT resources. In order for plans for the protection of the resources to be adequate, the managers most directly affected by, and interested in the information or processing capabilities, must be comfortable that their information and/or processing capabilities are adequately protected from loss, misuse, unauthorized access or modification, unavailability, or undetected activities. B. Overview: The purpose of the system security plan is to provide a basic overview of the security and privacy requirements of the subject system and the system owner's plan for meeting those requirements. The system security plan may also be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. Thus, it must reflect input from various managers with responsibility concerning the system, including functional "end users" or information owners, the system operator and the IT System Security Officer (ITSSO.) This document will discuss only the preparation and maintenance of the actual IT system security plan required by the "Computer Security Act of 1987", Public Law 100-235 and the format defined in Office of Management and Budget (OMB) Bulletin 90-08. However, security planning is a vital part of the overall IT planning requirements for the system and should be included in the other IT plans as identified in Chapter 1 of the "DOC IT Management Handbook." C. Background and Authority: The DOC IT security plan requirements are established in compliance with the "Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems" and OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information." D. Scope: The policy contained in this document covers all DOC IT resources that have been identified as either sensitive or classified national security systems whether maintained in-house or commercially. E. Policy: The sensitivity level of all IT systems will be determined based on the sensitivity of the data processed or the importance of the system to mission accomplishment. All systems must include security controls that reflect the true importance of the information processed on the system and/or the government investment embodied in the components of the IT system. The sensitivity level of all DOC IT systems will be identified in one of the following categories: 1. Classified National Security Systems contain information which requires protection against unauthorized disclosure in the interest of national security at either the Top Secret, Secret or Confidential level. Procedural protection requirements for classified systems are contained in DAO 207-2, "DOC National Security Information Manual." Technical protection requirements are contained in Chapter 10, Section 10.19 of the "DOC IT Management Handbook" and Section 19 of the "DOC IT Security Manual." 2. Unclassified Sensitive Systems include those that require some degree of protection for confidentiality, integrity or availability. This includes systems and data whose improper use or disclosure could adversely affect the ability of an agency to accomplish its mission, proprietary data, records about individuals requiring protection under the Privacy Act, and data not releasable under the Freedom of Information Act. If the system is required for accomplishment of an agency mission it need not contain any sensitive data. 3. Non-Sensitive Systems are considered "trivial" as they contain only public data, which has no protection required for confidentiality or integrity, and the mission of the agency can be accomplished without the system. A security plan will be prepared in the format of Attachment 1 to this document, "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems," and submitted to the Department for all DOC application and general support systems that have been identified as sensitive or classified national security systems. All IT systems will be identified as either application systems or general support systems: 1. Application Systems - Systems that perform clearly defined functions for which there are readily identifiable security considerations and needs. Such a system might actually comprise many individual application programs and hardware, software, and telecommunications components. They can be either a major software application or a combination of hardware/software where the only purpose of the system is to support a specific mission related function. The system may process multiple individual applications, if all are related to a single mission function. 2. General Support Systems - These consist of hardware and software that provide general automated data processing or network support for a variety of users and applications. Individual applications may be less easily distinguishable than in the previous category. Single user systems, such as one or more personal computers may fit into this category if they process data related to more than one function. F. Responsibilities and Process: Operating Unit The Operating Unit Senior Information Resources Management Official will assure ownership is assigned for all IT resources within the operating unit (i.e., hardware, software, data, telecommunications, etc.) This designation of ownership will become the foundation for determining who is responsible as "system owner" to define system boundaries, determine sensitivity levels and prepare and maintain the required individual IT system security plans. The Operating Unit IT Security Officer (ITSO) shall serve as the central point of contact for IT security and coordinate security plan requirements between the DOC IT Security Manager and the system owners within the operating unit. The ITSO shall: 1. Assist the system owners in establishing logical boundaries for individual systems. 2. Assign each individual IT system a unique six digit identification number, which will identify the operating unit and the specific system. The unique identification number will remain the same for the life of the system. 3. Establish and maintain a list of all IT systems within the operating unit and provide an up-to-date list to the DOC IT Security Manager annually. 4. Ensure that an IT System Security Officer (ITSSO) has been appointed for each IT system within the operating unit and maintain up-to-date records of these assignments. 5. Ensure IT system security plans are prepared in the proper format for all sensitive and classified IT systems owned and operated by the operating unit, including contractor owned systems, operated on behalf of the operating unit. 6. Review IT system security plans as submitted, making appropriate written comments, which will be sent to the originator for corrective action. Evaluation of the plans will follow the "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems," Attachment 1, to this document. 7. Forward all corrected IT system security plans to the DOC IT Security Manager for comment or final approval and incorporation into the Department's records. 8. Maintain a tracking system concerning implementation of the required controls and accreditation status for all operating unit sensitive and classified systems. 9. Ensure that system owners review and update all plans, at least annually, to incorporate changes or completed milestone actions. Forwarded updated plans to the DOC IT Security Manager for review and comment or approval. The System Owner will: 1. Evaluate all IT resources and establish logical boundaries for individual systems. It is important that the boundaries of a system be properly identified to allow for completion of the system accreditation as required by OMB Circular A-130 and the DOC Accreditation policy contained in Chapter 10, Section 10.4 of the "DOC IT Management Handbook" and Section 4 of the "DOC IT Security Manual." A system is identified by logical boundaries being drawn around the various processing, communications, storage, and related resources. They must be under the same direct management control with essentially the same function, reside in the same environment and have the same characteristics and security needs. A separate system security plan is required if a system does not meet the criteria for a single system. If each site is not under the same "direct management control" and does not reside in the same environment, each site would be a separate system. Each physical location would have its own unique environmental considerations. Plans may be identical except for those items that are unique for the different hardware, environments and direct management controls. To be defined as a single system, all components need not be physically connected together (e.g., a group of two or more stand alone personal computers in an office may be identified as a single system if they meet all the criteria above.) 2. Appoint an individual to serve as the ITSSO for each IT system identified. The ITSSO will be responsible for developing, implementing and managing the security of the system. Ensure that the ITSSO is adequately trained to fulfill all responsibilities identified in Chapter 10, Section 10.1 of the "DOC IT Management Handbook" and Section 1 of the "DOC IT Security Manual." 3. Establish and maintain a list of all IT systems within the system owner's area of responsibility and provide a copy to the operating unit ITSO, as requested. 4. For each individual system identified, prepare an IT System Security Plan in the format outlined in Attachment 1 of this document, "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems." The guideline provides an outline of all required sections, with examples that fit into each category of control. Application systems and general support systems require different sets of control categories and it is important to follow the correct format. The IT system security plan is intended to serve as a management tool for the system owner in determining the sensitivity level and protection requirements for the system. The plan describes the control measures currently in place and any planned control that are intended to meet the protection requirements of the system and can assist in determining whether or not current security measures are adequate. Properly documented, the plan can be used as a "mini-risk assessment" which can and should be used to determine what additional action and/or resources are required to bring this system in line with operational and security requirements. The plan should be used to establish the actual milestones for completing requirements and can be an excellent internal management planning and decision-making tool. Once completed, a security plan will contain detailed technical information about the system, its security requirements and the controls implemented to provide protection against its vulnerabilities. All DOC security plans should be marked at least "FOR OFFICIAL USE ONLY" and handled and controlled as sensitive documents. Security plans for classified systems should be carefully reviewed for classified content and may require higher level security classification and markings. All security plans must be dated. This will allow ease of tracking modifications and approvals. 5. Forward the completed IT system security plan to the operating unit ITSO for review and comment. The ITSO will provide written comments about any changes required to the plan. 6. Make changes to the IT system security plan, as requested, and return the plan to the operating unit ITSO for forwarding to the DOC IT Security Manager. 7. Maintain the IT system security plan in an up-to-date manner. At least annually, the plan should be reviewed and updated to incorporate changes to the system or completed milestone actions. Updated plans should be forwarded to the operating unit ITSO for review and comment. The DOC IT Security Manager will: 1. Maintain a list of all IT systems within the Department to ensure that all sensitive and classified IT systems have been accounted for and that the required security plans have been prepared and submitted. 2. Review all IT system security plans received from the operating units, making appropriate written comments which will be sent to the operating unit ITSO for corrective action. Plans which do not require changes will be approved and a signed statement of approval will be issued for incorporation into the system owner's records. 3. Maintain a tracking system and records which will be used to monitor implementation of the required controls and accreditation status of all DOC IT systems. SECTION 3 CERTIFICATION A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy for certification of all unclassified sensitive and classified national security Information Technology (IT) systems. 1. Classified National Security Systems contain information which requires protection against unauthorized disclosure in the interest of national security at either the Top Secret, Secret or Confidential level. Procedural protection requirements for classified systems are contained in DAO 207-2, "DOC National Security Information Manual." Technical protection requirements are contained in Chapter 10, Section 10.19 of the "DOC IT Management Handbook" and Section 19 of the "DOC IT Security Manual." 2. Unclassified Sensitive Systems include those that require some degree of protection for confidentiality, integrity or availability. This includes systems and data whose improper use or disclosure could adversely affect the ability of an agency to accomplish its mission, proprietary data, records about individuals requiring protection under the Privacy Act, and data not releasable under the Freedom of Information Act. If the system is required for accomplishment of an agency mission it need not contain any sensitive data. B. Overview: Certification is based on a technical evaluation of a sensitive system to see how well it meets its security requirements, including all applicable federal policies, regulations, and standards. The results of tests should demonstrate that the installed security safeguards are adequate and appropriate for the system. The certification process is the final step leading to accreditation of the system. Accreditation policy and procedures are included in Chapter 10, Section 10.4 of the "DOC IT Management Handbook," and Section 4 of the "DOC IT Security Manual." Protection requirements for each of the individual IT systems within the Department will vary according to the unique characteristics of the system, environmental concerns, data sensitivity and mission related criticality of the system or data. Total protection against all threats may be an unrealistic goal. Appropriate levels of security must be determined by an evaluation of the threats, vulnerabilities and risk factors associated with each system. Cost-effective controls that are adequate to achieve an acceptable level of risk for the individual system must then be implemented. C. Background and Authority: Certification is a requirement of Office of Management and Budget (OMB) Circular Number A-130 and the "Computer Security Act of 1987," Public Law 100-235. D. Scope: Certification is a requirement for all sensitive and classified DOC General Support and Application systems. New IT systems or those not fully operational shall complete all certification requirements and be accredited prior to full implementation. 1. Application Systems - Systems that perform clearly defined functions for which there are readily identifiable security considerations and needs. Such a system might actually comprise many individual application programs and hardware, software, and telecommunications components. They can be either a major software application or a combination of hardware/software where the only purpose of the system is to support a specific mission related function. The system may process multiple individual applications, if all are related to a single mission function. 2. General Support Systems - These consist of hardware and software that provide general automated data processing or network support for a variety of users and applications. Individual applications may be less easily distinguishable than in the previous category, but such applications may contain sensitive information, or be critical to the mission accomplishment of the organization. Even if none of the individual applications are sensitive, the support system itself may be considered sensitive if, the aggregate of applications and support provided are critical to the mission of the operating unit. E. Policy: Initial Certification Prior to accreditation, each IT system is to undergo appropriate technical certification evaluations to ensure that it meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the protection requirements of the system. Certification of the system is based on the documented results of the design reviews, system tests, and the recommendations of the testing teams. All systems must include security controls that reflect the true importance of the information processed on the system and/or the government investment embodied in the components of the IT system. Section F., of this document, identifies the required actions in the certification process. Interim Certification The certification process must be flexible enough that it accommodates the need for operational efficiency as well as adequate protection of the system. There may be situations when the need for a system is such that it must be put into operation before a full certification is possible. In this case, the Certifying Official can provisionally certify the system for operation, possibly with some restrictions, pending specific actions to be completed in a predefined time frame. This interim certification cannot exceed one year. These actions should also be included as milestones in the security plan for the system. Recertification Systems will be recertified when substantial changes are made to the system, when changes in requirements result in the need to process data of a higher sensitivity, after the occurrence of a serious security violation which raises questions about the validity of an earlier certification, and in any case no less frequently than three years after the previous certification. Examples of major changes include: 1. Changes in the system or software applications - Substantial changes which alter the mission, operating environment or basic vulnerabilities of the system. Increase or decrease in hardware, application programs, external users, hardware upgrades, addition of telecommunications capability, dial-in lines, changes to program logic of application systems, relocation of system to new physical environment or new organization. Minor changes such as, replacement of similar hardware when capacity does not significantly change, addition of two or three workstations on a network or small modifications to an application program (e.g., table headings are changed) would not require recertification. 2. Changes in protection requirements - Changes in the sensitivity or classification level of the data being processed, increase in the mission criticality of the system or changes in federal or DOC policies. 3. Occurrence of a significant violation - A violation or incident that calls into question the adequacy of the system security controls. 4. Audit or evaluation findings - Findings from any security review that identifies significant unprotected risks. These could include the system IT security verification review, physical or information security inspection, internal control reviews, Office of the Inspector General (OIG) audits or General Accounting Office (GAO) audits. F. Responsibilities and Process: Certification evaluations are conducted by the organization that owns the system. The official certification document is signed by a senior management official in the system owning organization. Chapter 10, Section 10.1 of the "DOC IT Management Handbook" and Section 1 of the "DOC IT Security Manual" contain specific information about designation of ownership of IT systems and data. Owners of DOC IT systems will complete all required certification actions, issue a certification statement and prepare an accreditation package which will be forwarded to the Designated Approving Authority for formal accreditation of the system. A sample certification statement and request for accreditation is contained in Attachment 1 of this document. The information included in the certification documentation will contain details about the system, which may identify weaknesses or vulnerabilities which require protection against disclosure to persons without an official need to know. Certification documentation for sensitive systems will be marked at least "For Official Use Only." Classified IT system certification documentation will be marked in accordance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." Certification Review Team A Certification Review Team should be established to conduct the technical evaluation of the system. The Certification Review Team should get input from all who have involvement with the system, including: IT security staff; system owner staff; computer program development staff, if the application was developed in-house; the computer operations staff, if the application is run on a computer managed by a separate organization; and users. Representatives from as many of these organizations as possible should be included on the Certification Review Team. The Certification Review Team will be responsible for performing all actions required for the certification evaluation, evaluating the results and preparing a report with recommendations for the system owner about certification of the system. Certification Testing of Security Controls The technical certification evaluation results are the basis for the system owner's certification statement in the accreditation request. The letter should state what methods were used to perform the certification evaluation. The first step in the certification process is to determine what the protection requirements for the IT system should be, based on the sensitivity or criticality of the individual system. Once these requirements are defined, cost-effective controls can be selected and implemented that will provide adequate protection to achieve an acceptable level of risk. The goal of the technical certification evaluation is to test existing controls to determine: (1) if controls function properly; (2) if controls satisfy performance criteria and provide for availability, survivability and accuracy; and (3) if the controls can be easily broken or circumvented. The technical certification evaluation can be accomplished by two or more of the following: System Owner Evaluation and Testing Security controls installed and implemented require testing to ensure they meet the defined security requirements for the system and that they function as expected. System owners should maintain documented results of these tests, which can be used as part of the certification review. In addition to specific tests of individual controls, evaluation of the overall system may also be performed. These evaluations may take the form of checklists or other methods that ensure consideration has been given to all security requirements and controls. Copies of evaluation results should be included in the certification report included in the accreditation package. The Department has developed and approved two separate methodologies which can be used by the system owner in planning and conducting the required certification evaluation. Each of these methodologies provides a structured process that will ensure that all appropriate actions have been completed and documented. The system owner should select one of the following methodologies for the Certification Review Team's use: 1. "Methodology for Certifying Sensitive Computer Applications," contained in Attachment 2 of this document is especially suited for large complicated software applications, for applications which are in-house developed or involve extensive modifications to customize for Commerce use, applications with very high sensitivity such as major financial applications which process high dollar amounts or are subject to fraud or abuse, or for new applications without existing security documentation. 2. "Abbreviated Certification Methodology for Sensitive IT Systems," contained in Attachment 3 of this document is an abbreviated form of the above methodology. It was developed to address existing sensitive systems with extensive documentation already available. It is intended to handle the certification evaluation requirements of smaller systems and systems and applications such as those associated with personal computers or those systems with only a few users, and turn-key or commercial systems which were procured against a detailed set of security specifications. It can be used for completing the technical certification evaluation requirements for both application systems and general support systems. Other Internal Reviews The results of any security related reviews performed by evaluation teams internal to the operating unit or the system owner's organization may be used as part of the certification evaluation. These reviews may include internal control reviews, physical or information security inspections or IT security verification reviews. Corrective actions resulting from any review findings should be tested and documented. Copies of review findings and corrective actions taken should be included in the certification documentation for the accreditation package. External Reviews The results of any audits performed by independent external organizations may also be used as part of the certification evaluation. These audits or reviews may have been performed by the OIG, GAO, DOC or commercial Electronic Data Processing (EDP) audit firms. Implementation of any corrective actions taken as a result of these audit findings should be tested and documented. Copies of audit findings and corrective actions taken should be included in the certification documentation for the accreditation package. For classified IT systems, external organizations such as Department of Defense, National Security Agency, State Department, Central Intelligence Agency, etc., who have specific requirements for data under their area of responsibility, may also perform reviews and inspections. Any authorizations or approvals provided by these external organizations are important certification documentation and must be provided with the request for accreditation. Risk Analysis Risk analysis can play a dual role in the evaluation process. It can be used to help determine important security requirements for the IT system and also to evaluate the existing and planned controls for cost-effective risk reduction. Since risk analysis must be performed throughout the life cycle of the system, it provides a method for reassessing the risks against system changes and determining additional controls required to bring the system to an acceptable level of risk. ATTACHMENT 1 SAMPLE CERTIFICATION STATEMENT AND REQUEST FOR ACCREDITATION MEMORANDUM FOR: (Designated Approving Authority) FROM: (System Owner) SUBJECT: Request for Accreditation of DOC IT System Number ______, "ABC Computer Center" Attached is the required accreditation documentation for DOC Information Technology (IT) System Number ______, "ABC Computer Center." Based on the information contained in these documents, I certify (with the exceptions or clarifications noted below) that this system meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of this system. The methods used to perform the certification evaluation included testing installed controls, completing a checklist for evaluating implemented controls against defined security requirements and implementing additional controls recommended by the Office of Inspector General (OIG) audit. (exceptions or clarifications) Weighing the remaining residual risks against operational requirements, I recommend that you authorize (continued) operation of this IT system (under the following restrictions): (restrictions) ATTACHMENT 2 (Methodology published in 1988 is still usable, but being revised) U. S. DEPARTMENT OF COMMERCE ABBREVIATED CERTIFICATION METHODOLOGY GUIDELINES FOR SENSITIVE AND CLASSIFIED INFORMATION TECHNOLOGY SYSTEMS December 1, 1992 U. S. DEPARTMENT OF COMMERCE ABBREVIATED CERTIFICATION METHODOLOGY FOR SENSITIVE INFORMATION TECHNOLOGY SYSTEMS A. INTRODUCTION It is the policy of the Department of Commerce (DOC) to comply fully with all federal statutes and directives on information technology (IT) security and to provide protection commensurate with the sensitivity of the systems or data processed. Protection requirements for each of the individual IT systems within the Department will vary according to the unique characteristics of the system, environmental concerns, data sensitivity and mission related criticality of the system or data. Appropriate levels of security must be determined by an evaluation of the threats, vulnerabilities and risk factors associated with each system. Cost- effective controls that are adequate to achieve an acceptable level of risk for the individual system must then be implemented. The DOC "Information Technology Accreditation Policy" issued on July 6, 1992 established the requirement for accreditation of all unclassified sensitive and classified national security IT systems. Accreditation is the authorization and approval, granted to a sensitive or classified IT system to process, as an acceptable risk, in an operational environment. Accreditation is made on the basis of recommendations from a technical certification evaluation that the IT system meets all applicable federal and DOC policies, regulations, and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system; that they are operating correctly; or, that the system must be operated under certain specified conditions or constraints. The technical certification evaluation results are the basis for the system owner's certification statement in the accreditation request. B. PURPOSE The purpose of this document is to provide guidance on appropriate procedures to follow in performing the technical certification evaluations of all sensitive and classified national security systems within the Department. The DOC issued a "Methodology for Certifying Sensitive Computer Applications" in March 1987. The process described in that document was required for any new DOC applications or any modification of existing applications that handle sensitive information. It is especially suited for large complicated applications, for applications which are in- house developed or involve extensive modifications to customize for Commerce use, applications with very high sensitivity such as major financial applications which process high dollar amounts or are subject to fraud or abuse, or for new applications without existing security documentation. This original certification methodology should be used for systems meeting the above criteria. That methodology has proved to be far too complex for many of the Department's systems. The methodology described in this document is an abbreviated form of this process, developed to address existing sensitive systems with extensive documentation already available. It is intended to handle smaller systems and applications such as those associated with personal computers (PCs) or those systems with only a few users, and turn- key or commercial systems which were procured against a detailed set of security specifications. This abbreviated methodology stresses the use of existing documentation wherever possible. It can be used for completing the technical certification evaluation requirements for both application systems and general support systems. The term "system" used in this document is intended to mean either of the following, as appropriate: 1. Application Systems - Systems that perform clearly defined functions for which there are readily identifiable security considerations and needs. Such a system might actually comprise many individual application programs and hardware, software, and telecommunications components. They can be either a major software application or a combination of hardware/software where the only purpose of the system is to support a specific mission related function. The system may process multiple individual applications, if all are related to a single mission function. 2. General Support Systems - These consist of hardware and software that provide general automated data processing or network support for a variety of users and applications. Individual applications may be less easily distinguishable than in the previous category, but such applications may contain sensitive information, or be critical to the mission accomplishment of the organization. Even if none of the individual applications are sensitive, the support system itself may be considered sensitive if the aggregate of applications and support provided are critical to the mission of the operating unit. C. ABBREVIATED CERTIFICATION METHODOLOGY Certification is based on a technical evaluation of a sensitive system to see how well it meets its security requirements, including all applicable federal policies, regulations, and standards. The results of tests should demonstrate that the installed security safeguards are adequate and appropriate for the system. The certification process is the final step leading to accreditation of the system. Sensitive systems will be recertified and reaccredited when substantial changes are made to the system, when changes in requirements result in the need to process data of a higher sensitivity, after the occurrence of a serious security violation which raises questions about the validity of an earlier certification, and in all cases no less frequently than three years after a previous certification. Certification evaluations are conducted by the organization that owns the system. The certification team should get input from all who have involvement with the system, including:  IT security staff,  system owner staff,  computer program development staff, if the application was developed in-house, and  the computer operations staff, if the application is run on a computer managed by a separate organization.  users Representatives from as many of these organizations as possible should be included on the Certification Review Team. The certification methodology described in this document consists of the following steps, which will be described more fully in the rest of this document: Step 1. Assemble a team Step 2. Collect existing documents Step 3. Describe the system and its sensitivity Step 4. Identify protection requirements and vulnerabilities Step 5. Identify security features needed Step 6. Test the adequacy of controls Step 7. Evaluate test results Step 8. Certify the system Worksheet forms to document each step in the certification process are provided in Appendix A. Definitions Certification is a technical evaluation of a sensitive system to see how well it meets necessary security requirements, such as appropriate federal policies, regulations, and standards. The Certifying Official is a senior manager in the organization which owns the system. The system owner is the organization which has functional responsibility for the system. The Certifying Official should be a manager who was responsible for having the system developed or the functional area that the system supports, who has a need for the results produced by the system, and can allocate resources to correct deficiencies in the security controls for the system. The Certification Review Team will collect the information needed for the certification process, identify vulnerabilities, develop a list of needed security features, develop tests of the adequacy of the features, and evaluate the test results. Security features are controls that protect against the identified vulnerabilities, such as fire and water alarms, passwords and other access protection, use of removable media for data storage, data validation controls, audit trails, uninterruptable power sources to protect against electrical outages, personnel screening, IT security awareness training of users, etc. A sensitive system is one that requires some degree of protection for confidentiality, integrity or availability. This includes data whose improper use or disclosure could adversely affect the ability of an agency to accomplish its mission, proprietary data, records about individuals requiring protection under the privacy Act, and data not releasable under the Freedom of Information Act. If the system is required for accomplishment of an agency mission it need not contain any sensitive data. Test scenarios are descriptions of the tests to be performed to check the effectiveness of the security features incorporated into the system. They may include validation of password constraints such as length and composition of the password, entry of erroneous data to check data validation controls, review of audit information produced by the system, review of contingency plans and risk analyses, etc. Vulnerabilities are ways in which the system may be attacked or may fail. They include susceptibility to physical dangers such as fire or water, unauthorized access to sensitive data, entry of erroneous data, denial of timely service, fraud, etc. Methodology Approach Step 1 - Assemble a team: The first step in the abbreviated process is to assemble a team to gather the information and documentation needed to assess and demonstrate the adequacy of security measures used. The team should include representatives of IT security, application owners, software development, computer systems, and users. For very small systems the users, software programming staff, and computer systems staffs may be the same. The IT security staff provides an outside viewpoint to ensure that the best IT security practices are used in protecting sensitive systems. Where computer system staff, software programmers, and users are in separate organizations, it is important that all points of view are represented in the process, to ensure that user expectations of protection needs are addressed, and that software and computer system constraints are understood. Step 2 - Collect existing documents needed for the certification evaluation: These documents include, but are not limited to: 1. system specifications and documentation 2. system security plan 3. risk analysis 4. contingency and disaster recovery plans 5. staff records on personnel and the IT Security Officer identification, training and position sensitivity levels 6. Internal Control Reviews, security reviews, etc., if existing Step 3 - Identify and describe the system to be certified and describe why it is sensitive: It is necessary to have a written description of the purpose of the system, the hardware and software environment on which the system is operated, and a description of the sensitivity of the system, including any special applicable laws and regulations. This information is readily available in the Sensitive System Security Plan for the system being certified. If the certification is for a software application system that will be used by others, the hardware description should address the hardware needed to operate the system, but the certification should focus on the software application program. Complete the blank sections of Sensitive System Certification Worksheet 1, System Description and attach a copy of the approved Sensitive System Security Plan for the system being evaluated. The Worksheet identifies the section numbers in the security plan where detailed information can be obtained for review. Step 4 - Identify protection requirements and vulnerabilities: Review the description of the protection requirements for the system under the headings confidentiality, integrity, and availability in Section II.B. of the Sensitive System Security Plan. Enter the levels of protection required (high, medium, low) in the blanks provided on Worksheet 1. Identify vulnerabilities for the system related to these protection requirements. Most vulnerabilities will be addressed in the existing documents collected in Step 2. All sensitive systems should have a completed risk analysis. The risk analysis will identify vulnerabilities and their consequences, such as unauthorized disclosure of information, loss of data or other resources, denial of service, decisions based on erroneous information, etc. System documentation is another source of information about the vulnerabilities. The security plan for the system being evaluated contains information about specific vulnerabilities and control measures addressed. The team should also review any existing Internal Control, Inspector General (IG) or security review reports on the system, for additional information on system vulnerabilities. In addition to the documentation, the team may need to interview managers in the user organization to ascertain their concerns about the sensitivity of the system and the level of protection required. Complete the Sensitive System Certification Worksheet 2: Identified Vulnerabilities by listing the identified vulnerabilities. Step 5 - Identify security features needed: The team next needs to review existing documents to identify the controls in place to address the vulnerabilities identified above. The risk analysis, security plans, and system documentation reviewed for vulnerabilities also contain information on controls used to reduce those vulnerabilities. System specifications, if they still exist, will also provide information on the controls designed into the system. The team will also need to review the contingency and disaster recovery plans for the system. The team should interview the IT System Security Officer to review installation IT security procedures. Staff training records will show the level of IT security training given to application and computer installation staff. Staff records should also show the sensitivity designation of staff positions and any personnel investigations, required and conducted, for staff in the affected positions. Complete the Sensitive System Certification Worksheet 3: Security Features. Step 6 - Test adequacy of controls: Once vulnerabilities and controls have been identified, the team should selectively check the adequacy of the controls. Some live tests may be needed to ensure that documented controls actually work. Other controls may be reviewed through other means. Previous system reviews and system acceptance tests may contain records of tests previously performed. It is not necessary to repeat these tests, if the system has not changed since they were done. The review of vulnerabilities and controls should identify any areas not adequately addressed. Sensitive System Certification Worksheet 4: Security Tests is used to list the tests to be performed. Use Sensitive System Certification Worksheet 5: Security Test Results to record the results of the tests. Step 7 - Evaluate the test results: Once all tests are completed, a summary of the evaluation of the tests should be prepared. The team should then prepare recommendations about certification. Sensitive System Certification Worksheet 6: Evaluation and Recommendations is used to record the evaluation of test results and the team's recommendation. The recommendation section should be signed by all members of the team and dated.  If the tests results indicate that all protection requirements have been met, the team can recommend certification with no further action required.  The Certification Review Team may determine from the test results that the protection requirements were not met for the system. In that case, the evaluation discussion of test results should explain the inadequacy of the controls in place.  The team may alternatively certify that the basic protection requirements have been met, but recommend additional features be required. This latter form of certification is appropriate for certifying a software application system which must have certain operating system or hardware features in place for approved operation. This may also be used in recommending interim accreditation pending installation of some additional control not currently available. Step 8 - Certification: The official Certification document is signed by a senior management official in the system owning organization. A sample certification document is attached as Appendix B. There may be situations when the need for a system is such that it must be put into operation before a full certification is possible. In this case, the Certifying Official can provisionally certify the system for operation, possibly with some restrictions, pending specific actions to be completed in a predefined time frame. This interim certification cannot exceed one year. These actions should also be included as milestones in the security plan for the system. The certification process must be flexible enough that it accommodates the need for operational efficiency as well as adequate protection of the system. APPENDIX A SENSITIVE SYSTEM CERTIFICATION WORKSHEETS This Appendix contains a set of six worksheets to assist with documenting the certification evaluation of the system. Each worksheet is preceded by a set of instructions and definitions which will provide guidance for completing the evaluation and the worksheet. DIRECTIONS FOR COMPLETING WORKSHEET 1: SYSTEM DESCRIPTION Much of the information requested on Worksheet 1 is contained in the Security Plan for the system. To avoid having to rewrite this information and have a ready reference to the needed information, attach a copy of the Security Plan behind Worksheet 1. Each worksheet contains blank lines, where information must be entered. This step is important to avoid confusion with other system certification evaluation documentation. System Name/Title is the name of the system used in the Security Plan for a sensitive system (Section I.B of the Security Plan). To avoid confusion with other certification evaluation documentation this should be written on all worksheets. System ID is the unique six digit system identification number assigned for each sensitive system in the Department. Again, to avoid confusion with other certification evaluation documentation this should be written on all worksheets. System Owner is the name of the contact person in the owning organization who is knowledgeable about the system and protection requirements. It may be the person listed as Information Contact (Section I.G) in the Security Plan. Provide full address and phone number, including area code, for the owner. Developer is the name of the person who is responsible for developing the software. If this is a commercial application, put the name of the organization in this space. If there is no developer or the developer's name is unknown, put "none" in this space. General Description/Purpose is a description of the function and purpose of the system. This information is contained in Section I.E of the Security Plan. System Environment and Special Considerations is a description of the computer and software environment of the system. This information is contained in Section I.F of the Security Plan. Sensitivity of Information Handled describes why the system is sensitive. Applicable Laws and Regulations lists any laws and regulations that specifically apply to this system, such as the Privacy Act. This information is contained in Section II.A of the Security Plan. General Description of Information Sensitivity is a description of why the system is sensitive and the nature of that sensitivity. This information is contained in the introduction to Section II.B of the Security Plan. Description of Protection Requirements describes what makes the system sensitive. The descriptions of protection needs for confidentiality, integrity, and availability are contained in Section II.B of the Security Plan. Write in the designated level (high, medium, low) in the blanks provided. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 1 SYSTEM DESCRIPTION System Name/Title System ID: System Owner Address: _______________________________ _______________________________ _ __________________________________ _____________________________ Phone: __________________________________ _____________________________ Programmer/Developer: Address: _______________________________ _______________________________ _ __________________________________ _____________________________ Phone: __________________________________ _____________________________ General Description/Purpose (See Section I.E. of attached security plan.) System Environment and Special Consideration (See Section I.F. of attached security plan). Sensitivity of Information Handled: Applicable Laws and Regulations Affecting the System (See Section II.A. of attached security plan.) General Description of Information Sensitivity (See Section II.B. of attached security plan.) Description of Protection Requirements See Section II.B. of attached security plan and fill in the designated level (high, medium, low) in the blanks. Confidentiality ______ Integrity ______ Availability ______ DIRECTIONS FOR COMPLETING WORKSHEET 2: IDENTIFIED VULNERABILITIES System Name/Title and System ID are the same as on Worksheet 1. Description of Identified Vulnerabilities should include the vulnerabilities that the system may have prior to putting controls in place. These should have been identified in the risk analysis. They might include physical vulnerabilities such as fire or disk crashes, entry of erroneous data, denial of service, and unauthorized access to information. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 2 IDENTIFIED VULNERABILITIES System Name/Title System ID: Description of Identified Vulnerabilities (From Risk Analysis, Security Plan, system documentation, interviews and other review DIRECTIONS FOR COMPLETING WORKSHEET 3: SECURITY FEATURES System Name/Title and System ID are the same as on Worksheet 1. Description of Security Features is a list of the security features used to protect this system. They can be taken from Sections III.C of the Security Plan and include Management Controls, Development/Implementation Controls for application systems, Acquisition/Development/Installation Controls for general support systems, Operational Controls, Security Awareness and Training, Technical Controls and Complementary Controls Provided by General Support Systems for application systems or Controls Over the Security of Applications for general support systems. Although, it is not necessary to include the level of detail contained in the Security Plan, the controls should be listed to provide a foundation for selecting tests to be performed to verify if the controls are adequate and appropriate and are operating as expected. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 3 SECURITY FEATURES System Name/Title System ID: Description of Security Features: DIRECTIONS FOR COMPLETING WORKSHEET 4: SECURITY TESTS System Name/Title and System ID are the same as on Worksheet 1. Test Scenarios should contain a numbered list of the tests to be preformed to verify the controls listed on Worksheet 3. For more detail about the controls, see Section III.C. of the security plan.  If this is an existing system that has been in operation for some time, the tests may selectively test the most critical controls.  If the system is under, or just completed development, or is a turn-key system, all security controls should be tested.  If testing has been done for a another recent review, or during recent acceptance testing of the system, it may not be necessary to repeat the tests. It will be necessary to review records of the prior tests, and determine if the documentation of the tests and results are adequate. If it is determined that it is not justified to repeat the tests, a statement should be included on Worksheet 4 explaining the reason. Also, include enough information about all supporting documentation reviewed, to allow it to be located for future reference. At a minimum, include a list of tests from the documentation, that were performed. This list need not contain as much detail for each individual test as the referenced documentation. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 4 SECURITY TESTS System Name/Title System ID: Test Scenario: DIRECTIONS FOR COMPLETING WORKSHEET 5: SECURITY TEST RESULTS System Name/Title and System ID are the same as on Worksheet 1. Test Results reports the results of each of the tests described on Worksheet 4. The numbers on Worksheet 5 for each test result should agree with the numbers on Worksheet 4 for the test description. Indicate whether the was "Passed" or "Failed". SENSITIVE SYSTEM CERTIFICATION WORKSHEET 5 SECURITY TEST RESULTS System Name/Title System ID: Test Results: DIRECTIONS FOR COMPLETING WORKSHEET 6: EVALUATION AND RECOMMENDATIONS System Name/Title and System ID are the same as on Worksheet 1. Evaluation of Test Results should discuss the results of the tests and their relationship to assuring the adequacy of controls. Under Recommendations check one of the three responses.  Check Tests indicate that protection requirements were met if all tests resulted in correct results.  Check Tests indicate that protection requirements were not met if some tests failed and corrections have not been, or cannot be implemented.  Check Tests indicate that protection requirements were met; recommend certification with the following additional security features required: if there are additional security controls needed to meet the protection requirements. This category should be used when certifying software applications that require hardware or operating system features to assure adequate protection. It should also be used if an interim certification is being recommended, pending completion of specific actions. Certifying Team Signatures should included printed names of the certifying team members, a signature, and a date for each team member. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 6 EVALUATION AND RECOMMENDATIONS System Name/Title Syste m ID: Evaluation of Test Results: Recommendations: _____ Tests indicate that protection requirements were met. RECOMMEND CERTIFICATION OF THIS SYSTEM. _____ Tests indicate that protection requirements were not met. RECOMMEND THAT THIS SYSTEM NOT BE CERTIFIED. _____ Tests indicate that protection requirements were met; recommend certification with the following additional security features required: Certifying Team Signatures Name Signature Date Appendix B Sample Certification Statement I have carefully examined the certification worksheets for DOC Information Technology System Number _________, "Insert system name/title", dated ___________________ . Based on the information contained in this package and the results of tests conducted on the system, it is my judgment that satisfactory information technology controls are in place to adequately protect the system and that it is operating at an acceptable level of risk. I hereby certify DOC IT System Number ________, "Insert system name/title", for a period not to exceed three years. Should substantial changes or security incidents occur during that three year period, which bring the adequacy of the protection measures for this system into question, a reevaluation and recertification must be completed earlier. Certification Official Name/Title: _______________________________________ _______ _______________________________________ _______ Signature: __________________________________________ ___ Date: ____________ SECTION 4 ACCREDITATION A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy for accreditation of all unclassified sensitive and classified national security Information Technology (IT) systems. B. Overview: Accreditation is the authorization and approval, granted to a sensitive or classified IT system to process, as an acceptable risk, in an operational environment. Accreditation is made on the basis of recommendations from a technical certification evaluation that the IT system meets all applicable federal and DOC policies, regulations, and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system; that they are operating correctly; or, that the system must be operated under certain specified conditions or constraints. C. Background and Authority: Accreditation is a requirement of Office of Management and Budget (OMB) Circular Number A-130 and the "Computer Security Act of 1987," Public Law 100-235. D. Scope: The policy contained in this document covers all DOC IT systems, whether maintained in- house or commercially. Accreditation is required for all sensitive and classified DOC General Support and Application systems. New IT systems or those not fully operational shall complete all requirements and be accredited prior to full implementation. E. Policy: This policy defines the final step in the IT Security management process that ensures protection of the vital IT resources within the Department. Initial Accreditation All sensitive and classified DOC IT General Support or Application systems will be accredited. The term accreditation describes the process whereby information pertaining to the security of a system is developed, analyzed and submitted for approval to the appropriate senior management official identified in this document as the Designated Approving Authority (DAA). Section F, of this document, identifies the required steps in the accreditation process. The DAA will review the accreditation support documentation and either concur, thereby declaring that a satisfactory level of operational security is present or not concur, indicating that the level of risk either has not been adequately defined or reduced to an acceptable level for operational requirements. The DAA will sign a formal accreditation statement declaring that the system appears to be operating at an acceptable level of risk, or defining any conditions or constraints that are required for appropriate system protection. Sample accreditation statements are contained in Attachment 1 of this document. Security of classified IT systems operated by, or in support of DOC programs is the responsibility of the Department and these systems must be accredited in accordance with the requirements defined in this policy. Approvals granted by external agencies, i.e., Department of State, Department of Defense, Central Intelligence Agency, etc., are not valid authority to operate classified IT systems within the Department. Approvals granted to these systems by DOC, prior to this policy, are no longer in effect and new approval to operate must be granted through the DOC accreditation process. Interim Accreditation Interim authority to operate can be granted for a fixed period of time, not to exceed one year. This authority is based on an approved security plan and is contingent on certain conditions being met. The interim authority to operate, while continuing the accreditation process, permits the IT system to meet its operational mission requirements while improving its IT security posture. If the DAA is not satisfied that the IT system is protected at an acceptable level of risk, an interim accreditation can be granted to allow time for implementation of additional controls. Recommendation or request for an interim accreditation may be made by the IT system owner, the operating unit IT Security Officer (ITSO) or the DAA. Interim authority to operate is not a waiver of the requirement for accreditation. The IT system must meet all requirements and be fully accredited by the interim accreditation expiration date. No extensions of interim accreditation can be granted except by the DOC Director for Information Resources Management. Reaccreditation Systems will be reaccredited when major changes occur to the system or every three years, whichever occurs first. Examples of major changes include: 1. Changes in the system or software applications - Substantial changes which alter the mission, operating environment or basic vulnerabilities of the system. Increase or decrease in hardware, application programs, external users, hardware upgrades, addition of telecommunications capability, dial-in lines, changes to program logic of application systems, relocation of system to new physical environment or new organization. Minor changes such as, replacement of similar hardware when capacity does not significantly change, addition of two or three workstations on a network or small modifications to an application program (e.g., table headings are changed) would not require reaccreditation. 2. Changes in protection requirements - Changes in the sensitivity or classification level of the data being processed, increase in the mission criticality of the system or changes in federal or DOC policies. 3. Occurrence of a significant violation - A violation or incident that calls into question the adequacy of the system security controls. 4. Audit or evaluation findings - Findings from any security review that identifies significant unprotected risks. These could include the system security verification review, physical or information security inspection, internal control reviews, Office of the Inspector General (OIG) audits or General Accounting Office (GAO) audits. Prior to reaccreditation, an on-site IT security verification review must be conducted by an evaluation team under the direction of the DOC IT Security Manager, the operating unit ITSO or the ITSO of a subordinate organizational unit (i.e., Line Office, Regional Office, Laboratory, etc.) The IT security verification review team may not be under the direction of personnel from the subordinate organization having direct control over the IT system being evaluated. The IT System Security Officer (ITSSO) for the system under review should participate as a member of the IT security verification review team. The purpose of this review is to ensure that all controls and vulnerabilities are properly documented, and that adequate and appropriate levels of security exist for protection of the system. Requirements and guidance for conducting IT serurity verification reviews are contained in Chapter 10, Section 10.5 of the "DOC IT Management Handbook" and Section 5 of the "DOC IT Security Manual." F. Responsibilities and Process: Classified National Security IT Systems 1. The DOC Director for Information Resources Management is the DAA for all classified IT systems within the Department. This authority can not be delegated below this level. Accreditation will be granted only with the recommendations of the DOC Director, Office of Security, DOC Chief, Telecommunications Management Division and the DOC IT Security Manager. 2. The DOC IT Security Manager will act as the central point of contact for accreditation of classified IT systems and will evaluate the adequacy of all technical controls protecting these systems. The DOC IT Security Manager will review all accreditation documentation, evaluate the security controls for the IT system and conduct on-site reviews, if necessary, to ensure they meet all applicable federal and DOC policies, regulations and standards and that they appear to be adequate and appropriate for protection of the system. The DOC IT Security Manager will submit recommendations to the DAA for or against accreditation. Recommendation should include any additional controls or constraints required to meet a satisfactory level of operational security. 3. The Chief, Telecommunications Management Division will evaluate all supporting accreditation documentation and conduct on-site inspections, when necessary, to ensure compliance with all Communications Security (COMSEC) and emanations (TEMPEST) security requirements as required by the Chapter 8 of the "DOC IT Management Handbook." 4. The DOC Director, Office of Security will evaluate all supporting accreditation documentation and conduct on-site inspections, when necessary, to ensure compliance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." Unclassified Sensitive IT Systems 1. The Senior Information Resources Management official in each operating unit will be the DAA for all sensitive systems within their organization. This approval authority may only be delegated to a senior management official of a subordinate organizational unit, if that official does not have direct control over the IT system being accredited. Delegation of accreditation authority must be requested and approved in advance by the DOC Director for Information Resources Management. 2. The operating unit ITSO will act as the central point of contact for accreditation of all sensitive IT systems within the organization. The ITSO will review all accreditation documentation, evaluate the security controls for the IT system and conduct on-site reviews, if necessary, to ensure they meet all applicable federal and DOC policies, regulations and standards and that they appear to be adequate and appropriate for protection of the system. The ITSO will submit recommendations to the DAA for or against accreditation. Recommendations should include any additional controls or constraints required to meet a satisfactory level of operational security. The operating unit ITSO will submit an accreditation status report quarterly to the DOC IT Security Manager, listing accredited systems by DOC identification numbers, including interim accreditations, and the completed date. A copy of all official accreditation statements will be forwarded with this list. IT System Owners Chapter 10, Section 10.1 of the "DOC IT Management Handbook" and Section 1 of the "DOC IT Security Manual" contain specific information about designation of ownership of IT systems and data. Owners of DOC IT systems will complete all required actions and prepare an accreditation package including all documentation identified in this section. For classified IT systems, the accreditation package will be forwarded to the DOC IT Security Manager through the ITSO and the Senior Information Resources Management official for the operating unit. Sensitive IT system accreditation packages will be forwarded to the appropriate ITSO for the operating unit. The information included in the accreditation package will contain details about the system, which may identify weaknesses or vulnerabilities which require protection against disclosure to persons without an official need to know. Accreditation packages for sensitive systems will be marked at least "For Official Use Only." Classified IT system accreditation packages will be marked in accordance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." The following actions shall be completed and the appropriate documentation prepared and submitted in the accreditation package to the appropriate DAA for the IT system: Request for Accreditation The system owner will prepare a written request for approval to operate the IT system and forward the documentation listed below to the appropriate DAA. The written request will include a certification statement that the IT system has undergone adequate tests to ensure that it meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system. Approved IT System Security Plan A detailed IT system security plan will be prepared by the system owner, in the required format provided in the "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems," contained in Section 2 of the "DOC IT Security Manual." The purpose of the system security plan is to provide a basic overview of the security and privacy requirements of the subject system and the IT system owner's plan for meeting those requirements. The plan may also be viewed as documentation of the structured process of planning adequate, cost-effective security protection for the system. The IT system security plan must be forwarded through the operating unit's ITSO for review and comment, and once all corrective actions have been completed, to the DOC IT Security Manager for final approval. A statement of approval will be sent to the operating unit ITSO for forwarding to the IT system owner. Security plans must be reviewed by the system owner, at least annually, and changes submitted, as necessary, to ensure they are up- to-date. Chapter 10, Section 10.2 of the "DOC IT Management Handbook" contains the DOC policy for IT system security plans. Section 2 of the "DOC IT Security Manual" contains detailed guidance for preparation of these plans. Completed Risk Analysis IT system owners are responsible for having a risk analysis conducted for each IT system to ensure that appropriate, cost effective safeguards are incorporated into existing and new systems. A risk analysis will be conducted prior to approval of design specifications for new systems, when major changes occur to the system or every three years, whichever occurs first. Examples of major system changes are given in Section E., Reaccreditation, of this document. See Chapter 10, Section 10.7 of the "DOC IT Management Handbook" and Section 7 of the "DOC IT Security Manual" for guidance on conducting the required risk analysis. Contingency/Disaster Recovery Plans Each IT system shall develop and maintain, in an up-to-date state, a contingency and disaster recovery plan which will provide reasonable assurance that critical data processing can be continued, or resumed quickly, if normal operations are interrupted. The plan for large systems supporting essential Departmental or agency functions shall be fully documented and operationally tested at least annually. Small systems may develop a more abbreviated and less formal plan. Policy concerning contingency/disaster recovery planning is contained in Chapter 10, Section 10.8 of the "DOC IT Management Handbook" and Section 8 of the "DOC IT Security Manual." Additional guidance is contained in Section 7 of the "DOC IT Security Manual." Software Application Certification Statements Sensitive application software shall be thoroughly tested prior to implementation to verify that the user functions and the required administrative, technical, and physical safeguards are present and are effectively operating as intended. If the system to be accredited is running major applications requiring separate certification, system owners will provide copies of all software application certification and recertification statements as part of the accreditation package. General support system owners running applications belonging to other organizations are not required to provide these certification statements. Certification Testing of Security Controls Prior to accreditation, each IT system is to undergo appropriate technical evaluations to ensure that it meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system. The technical evaluation results are the basis for the system owner's certification statement in the accreditation request. The letter should state what methods were used to perform the certification evaluation. The DOC certification policy is contained in Chapter 10, Section 10.3 of the "DOC IT Management Handbook." Section 3 of the "DOC IT Security Manual contains two approved methodologies for conducting certification testing. The following certification evaluation documentation will be included in the accreditation package, as applicable: 1. System Owner Certification Reports Include a copy of the certification review report that shows: (1) that controls function properly; (2) that controls satisfy performance criteria and provide for availability, survivability and accuracy; and (3) that the controls cannot be easily broken or circumvented. Copies of evaluation results should be included. 2. Other Internal Reviews The results of any security related reviews performed by evaluation teams internal to the operating unit or the system owner's organization may be used as part of the certification evaluation. Copies of review findings and corrective actions should be included in the accreditation package. 3. External Reviews The results of any audits performed by independent external organizations may also be used as part of the certification evaluation. Copies of audit findings and corrective actions taken should be included in the accreditation package. For classified IT systems, external organizations such as Department of Defense, National Security Agency, State Department, Central Intelligence Agency, etc., who have specific requirements for data under their area of responsibility, may also perform reviews and inspections. Any authorizations or approvals provided by these external organizations are important certification documentation and must be provided with the request for accreditation. ATTACHMENT 1 SAMPLE ACCREDITATION STATEMENTS Full Accreditation: I have carefully examined the accreditation package documentation for DOC Information Technology (IT) System Number ______, "ABC Computer Center," dated ____________. Based on my authority and judgment, and weighing the remaining residual risk against operational requirements, I authorize (continued) operation of this system (under the following restrictions). (restrictions) I hereby accredit DOC IT System Number ______, "ABC Computer Center," as an unclassified sensitive system, for a period not to exceed three years. Should any major changes occur to this system during this three year period, a re- evaluation of the adequacy of its security controls must be conducted and a reaccreditation requested. _____________________________________ DAA Signature and Date Interim Accreditation: I have carefully examined the accreditation package documentation for DOC Information Technology (IT) System Number ______, "ABC Computer Center," dated __________. Based on my authority and judgment and the recommendation of the (System Owner, ITSO or DAA judgmentt) it does not appear that this system has reached a satisfactory level of operational security (or the following actions must be completed or additional controls implemented prior to full accreditation). (actions or additional controls required) I hereby grant an interim accreditation to DOC IT System Number ______, "ABC Computer Center," for a period not to exceed six months to allow time to (take action or implement additional controls required). Prior to the expiration of this interim accreditation on _______________, the accreditation package shall be resubmitted showing that a satisfactory level of operational security has been reached. ______________________________________ DAA Signature and Date SECTION 5 INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEWS A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy for conducting information technology (IT) security verification reviews of the Department's sensitive and classified national security IT systems. The purpose of the IT security verification review is to provide a level of review and evaluation independent of the system owner, that will verify that adequate and appropriate levels of protection are being provided for the individual systems, based on their unique protection requirements. B. Overview: Protection requirements for each of the individual IT systems within the Department will vary according to the unique characteristics of the system, environmental concerns, data sensitivity and mission related criticality of the system or data. Total protection against all threats may be an unrealistic goal. Appropriate levels of security must be determined by an evaluation of the threats, vulnerabilities and risk factors associated with each system. Cost-effective controls that are adequate to achieve an acceptable level of risk for the individual system must then be implemented. System owners are responsible for completing all DOC and federal requirements for identifying their sensitive and classified systems, preparing security plans that provide a basic overview of the security and privacy requirements of the subject system and the system owner's plan for meeting those requirements, conducting risk assessments, implementing controls determined to be required and cost-effective, developing contingency and disaster recovery plans that will ensure availability of the system for mission accomplishment and completing all requirements for certification and accreditation of the system. The IT security verification review process provides an independent means to ensure that the system owner has implemented adequate and appropriate levels of protection, based on the system's unique requirements. The IT security verification review process is part of the Department's oversight program. C. Background and Authority: The DOC IT security verification review process is established in compliance with the "Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems" and OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information." D. Scope: The policy contained in this document covers all DOC IT resources that have been identified as either sensitive or classified national security systems whether maintained in-house or commercially. E. Policy: An IT security verification review will be conducted on all DOC sensitive or classified national security IT systems by an evaluation team under the direction of the DOC IT Security Manager or the operating unit ITSO or the ITSO of a subordinate organizational unit every three years. The security plan for the system will be used as the foundation for the actual review. The review will be conducted in accordance with the guidance contained in the "DOC Guidelines for Conducting IT Security Verification Reviews of Sensitive and Classified Systems," Attachment 2 to this document. F. Responsibilities and Process: IT Security Verification Review Team The IT security verification review team will always be under the direction of the DOC IT Security Manager or the IT Security Officer (ITSO) at the operating unit level or a major subordinate organizational unit. This should assure the level of knowledge about the DOC IT security program requirements is adequate to make decisions about the appropriateness and adequacy of controls required for the system under review. Whenever possible, these individuals should participate in the on-site review as the team leader. When the ITSO is unable to participate in the actual review, they will appoint an individual who is judged to have sufficient knowledge about the DOC IT security program to act as the review team leader. Additional team members should include personnel knowledgeable about physical and environmental security, personnel security, information security (if system processes classified national security information), application security, hardware and software, telecommunications, technical controls, procedural security, contingency and disaster recovery planning and risk management. Personnel from the Internal Control Review area within the organization are also suggested as team members. The actual number of team members may vary and should be limited to the smallest number possible to cover all areas of concern. The average team will include two to four individuals, but should be comprised of no less than two people. Operating units may contract out for IT security verification reviews to be conducted by commercial consulting firms or other federal organizations. However, care should be taken in preparing the procurement requests or agreements to ensure that the review will be conducted in accordance with all DOC policies and standards. The operating unit ITSO will act as the COTR for the contract, provide all directions for conducting the review and set standards for written reports. The team leader will be responsible for notifying the system owner of the planned review, making specific review assignments to individual team members based on their expertise, coordinating activities of team members, conducting an in-briefing and an exit-briefing with the system owners, conducting team meetings as required, making decisions about what recommendations are appropriate for the individual system and preparation of the draft and final "IT Security Verification Review Report." The format and guidance for preparing this report is contained in Attachment 1 of this document. Conducting the Review Written notification should be sent to the system owner two to four weeks in advance of the review, providing information concerning the purpose of the review, dates of the review, list of review team members, requesting the assignment of a point of contact and that the following documentation be made available to the review team. 1. Memorandum officially designating an individual as the IT System Security Officer (ITSSO) 2. Listing of current personnel (indicate working hours for ADP personnel) 3. Hours of operation of facility 4. Organization charts for highlighting the placement of the individual facilities 5. Applicable floor plans (including building floor plans) 6. Latest risk analyses for the system 7. Reports of external and internal security (both ADP and other) evaluations completed during the 3 years 8. Hardware inventory (to include minis and micros) 9. Software inventory (include production programs, utility programs, commercially available software, operating systems, etc.) 10. List of users: a. within the Department b. at other federal agencies c. others 11. Disaster recovery plans 12. Policies, directives, guidelines, etc., pertaining to IT security issued by local authorities 13. Minutes of any management meetings that address IT security 14. Any other documentation pertaining to IT security 15. Information pertaining to IT security awareness and training including course content, type of training and number of personnel who have completed or are scheduled for training 16. Information pertaining to ADP-related position sensitivity and personnel screening for facility 17. Copies of any contracts for operation and maintenance or other service agreements related to this system 18. Reports of any internal IT security reviews that may have been conducted 19. Reports of any Internal Control Reviews or any reviews conducted by other external or internal organizations 20. Discussion of any known needs for guidance or assistance or specific areas of concern in IT security from either the operating unit, Department or federal levels 21. Sensitive System Security Plan 22. Certification documentation, if available The system owner should appoint an individual, usually the ITSSO, to act as the point of contact for the review team. This individual should participate as an observer in the review and coordinate interviews or make other arrangements as necessary to assist the review team. An entrance meeting should be arranged to allow the review team to explain its mission and review methods to the system owner and staff members. During the course of the review, the team will discuss their findings and recommendations with the point of contact or system owner and keep them advised about the progress of the review. The security plan for the system will be used as the foundation for the actual review. The security plan will provide information about the technical and physical system, its sensitivity level and its protection requirements. The security plan is intended as a basic overview and will not contain the level of detailed information that the review team will need in making decisions about its actual security requirements. However, the plan should be accurate and reflect the actual system description, protection requirements and controls in place, Verification of the accuracy of the plan is an important element of the review process. Recommendations to improve the quality of the security plan should be made during the course of the review. In many cases, the review team may find that many of their recommendations will concern changes to the security plan and not to the actual system controls. Prior to the actual on-site review of the system, all team members should be provided with a copy of the security plan for the system to be reviewed. The team should meet to discuss the scope of the review, which will be determined by the size, sensitivity level, type and complexity of the system as identified in Section I. through Section III.B. in the security plan. During the actual on-site review, it is recommended that the team leader be the evaluator to verify the information contained in these sections of the plan. The team leader should share the results of the verification with all other team members to ensure that their reviews are based on accurate requirements for the system. Although it is not necessary for all team members to be experts about what controls are appropriate for every type system, they should be given enough guidance about the system under review to avoid wasting too much time asking questions that are not relevant for the particular system. A very obvious example of this would be if the system under review is a microcomputer or local area network system, asking questions relating to a computer room would not be relevant. A less obvious example would be for a system that contains nothing but public information, asking multiple questions about confidentiality controls would be a waste of time and might lead to inappropriate recommendations. Other considerations that would have a bearing on determining adequate and appropriate protection requirements for a specific system would include the physical location, environment, category of system, telecommunication configuration, sensitivity of data, availability requirements and importance to mission accomplishment. It is important to understand that the IT security verification review is not intended to be a risk analysis. Testing of actual controls will be limited to only those necessary to verify their existence and proper operation. If documentation of prior testing of controls appears adequate (i.e., risk analysis or system certification documentation) then further testing would not be conducted. Appropriate tests might include such things as: (1) having system owner demonstrate access controls on the system (i.e., logging into the system to ensure password is blanked, attempting to establish passwords outside established password constraints, viewing SCREEN WARNING messages, attempting to access files that should be restricted, etc.); (2) attempting to access computer room outside normal working hours to ensure doors are locked or verifying that visitors are challenged. Evaluators are not to attempt penetration of the computer or to remove any system resources (i.e., equipment, media or printed output, etc.), as these actions could be considered security violations. At the conclusion of the review, the "IT Security Verification Review Report" will be prepared in the format outlined in Attachment 1 of this document. A copy of the draft report with major findings and recommendations should be provided to the system owner during the exit-briefing. Within two weeks after the conclusion of the review, the system owner should provide the review team leader written comments or questions about the draft report findings and recommendations. The review team should consider the system owner's concerns and prepare and forward the final report for the system owner's action. The information included in the "IT Security Verification Review Report" will contain details about the system, which may identify weaknesses or vulnerabilities which require protection against disclosure to persons without an official need to know. Reports for sensitive systems will be marked at least "For Official Use Only." Classified IT system reports will be marked in accordance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." Use of the "IT Security Verification Review Guideline" The guideline, contained in Attachment 2, provides a structured process for accomplishment of the required IT security verification review for DOC IT systems. It was developed following the format required for DOC IT system security plans and provides detailed questions for each section contained in the plans. Since the purpose of the IT security verification review is to determine if the individual IT system has been provided with adequate and appropriate levels of protection based on its unique protection requirements, many of the questions under specific control areas will not apply to all IT systems. An attempt has been made in developing the "IT Security Verification Review Guideline" to formulate questions that cover the majority of possible security concerns and requirements that could possibly apply to any DOC sensitive or classified IT system. The questions are not intended to be all inclusive, and answers provided may generate other questions. Additional questions may also result from the review of system documentation and records or as the result of interviews or observations by the team members. Team members will be required to rely on their judgement about what is appropriate and adequate protection requirements for the system they are evaluating. The guideline questions should be reviewed by the evaluator in advance of any interviews and those determine not be applicable, marked off. The team leader should be able to assist in determining the appropriate questions or areas to be reviewed. System Owners System owners may also find this guideline helpful in performing management control reviews and the required risk analysis or certification testing of their systems. The guideline contains extensive questions about all categories of controls and could be useful in verifying that adequate consideration of appropriate controls has been included in their risk analysis, certification methodologies or for management control review ideas. It may also serve as a useful tool in identifying additional controls that would be appropriate for their systems. ATTACHMENT 1 INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEW REPORT FORMAT Format The "Information Technology (IT) Security Verification Review Reports" should be consistent across all DOC organizations and should contain the following sections: Cover page Executive Summary Introduction Discussion Objective Method System and Sensitivity Information System Description/Purpose System Environment and Special Considerations General Description of Information Sensitivity Recommendations The following sample report was prepared in the appropriate format and contains guidance for content in each section. (ORGANIZATION CONDUCTING REVIEW) INFORMATION TECHNOLOGY SECURITY REVIEW DOC SYSTEM NUMBER (OPERATING UNIT) (SUB ORGANIZATION) (SYSTEM NAME/TITLE) (CITY, STATE WHERE SYSTEM IS LOCATED) (MONTH, YEAR) EXECUTIVE SUMMARY Introduction An Information Technology (IT) Security Verification Review, in conformance with the requirements of the Computer Security Act of 1987 and Office of Management and Budget (OMB) Bulletin 90-08, was conducted during the period at the (Operating Unit, Sub-organization, System Name/Title, in City, State.) The IT Security Review Team was lead by , (Organization and Title). (List all other team members by name, organization and title) team members. Each team member was assigned specific sections of the Sensitive System Security Plan for the system, to verify and validate the accuracy of the information contained in the plan and to ensure that the system controls were adequate and appropriate for the system. The review was conducted in accordance with guidance contained in the "DOC Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems". The IT Security Review was conducted on the DOC IT System Number , "(Name/Title of System)". The system (describe in general terms the purpose of the system. See Section I.E. in the security plan.) The overall IT security profile of this system was (excellent, very good, good, adequate, inadequate or poor). This paragraph should contain summary information about the findings, including positive actions, controls or other significant items that the system owner has implemented to protect the system. Any major problems noted during the course of the review should be described in general terms or "no major problem were noted". Recommendations primarily concerned (describe in general categories (i.e., improvements in administrative procedures, documentation, contingency planning, backup storage, personnel management and user access control).) The purpose of this review was to improve IT security specifically and IT resource management in general at (system name) and to ensure compliance with prescribed IT security policies and regulations and to identify areas where further security controls may be necessary to improve the protection of the system. At the conclusion of the on-site visit, the review team discussed its preliminary findings with the (system) management and IT security staff personnel who indicated general agreement and a willingness to implement all recommendations (or major objections). Implementation of the recommendations will provide assurance that all risks have been identified and appropriate levels of security exist for protection of the system. DISCUSSION Objective The objectives of this review were to determine the coordination and implementation of activities conducted by the (system organization) to ensure the protection and integrity of information resources such as development of security plans for sensitive and classified systems, ensuring periodic risk assessments are conducted, establishing contingency and disaster recovery plans, implementing a security awareness and training program, performing IT security reviews, and certification and accreditation of sensitive systems. Specific laws, regulations and policies used as guidelines for this review, included: OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems" Public Law 100-235, the "Computer Security Act of 1987" Department of Commerce, "Information Technology Handbook, Chapter 10, Information Technology Security" OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information" Department of Commerce, "Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems" This review was conducted to evaluate compliance with federal and Departmental IT security policies and requirements and assess the system's IT security profile. Review criteria was based on evaluation of the in-place and planned controls identified in the Sensitive System Security Plan for this system (DOC System Number ). Method The review team's approach in this evaluation was to interview (system name/title) management and staff personnel, observe operations of the system and the physical facilities and resources within the buildings and review all IT security program related documentation. The primary point-of-contact for this system review was (Name and title). Other Staff members contacted during the review included: (List names and titles). During the entrance interview with system management and staff personnel, the review team's mission and methods were explained in detail. SYSTEM AND SENSITIVITY INFORMATION SYSTEM DESCRIPTION/PURPOSE (Copy information contained in Section I.E. of the security plan or correct information after the conclusion of the review.) SYSTEM ENVIRONMENT AND SPECIAL CONSIDERATIONS (Copy information contained in Section I.F. of the security plan or correct information after the conclusion of the review.) GENERAL DESCRIPTION OF INFORMATION SENSITIVITY (Copy information contained in Section II.B. of the security plan or correct information after the conclusion of the review.) RECOMMENDATIONS The review was conducted, using the "DOC Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems" and the "Sensitive System Security Plan" for DOC System , as the basis. The review included on-site inspections of the facilities, computer room environment, hardware configuration, and interviews of management and computer center personnel The following recommendations are a result of the review findings: The security plan for this system should be updated to incorporate any changes resulting from these recommendations.  Recommendations should be numbered.  Recommendations should be listed by security plan section number. Example Section III.C.2.b. This will relate each finding and recommendation to a specific control category. There may be multiple separate recommendations under a specific section number.  Each finding and recommendation should be discussed with the system owner during the exit briefing in as much detail as possible by the review team member making the recommendation. Every effort should be made to discuss findings with the point of contact or system owner prior to the exit briefing. This will ensure that all significant facts have been taken into consideration about any unique situations or requirements affecting the individual system. Discussion about security requirements during the course of the review also provides an excellent opportunity to increase IT security awareness and training. SECTION 6.1 MALICIOUS SOFTWARE A. Purpose: The purpose or this section is to establish Department of Commerce (DOC) policy to minimize the risk of introducing malicious software into computer systems. It also provides guidelines for the detection and removal of malicious software from information technology (IT) systems. B. Overview: Malicious software presents an increasingly serious security problem for computer systems and networks. Malicious software includes viruses and other destructive programs, such as Trojan horses and network worms. This type or software is often written as independent programs that appear to provide useful functions but also contain malicious programs that can be very destructive. It can be quickly spread through software bulletin boards, shareware, and users unknowingly copying and sharing these programs in an unauthorized manner. It can also be spread by users sharing data files and software products. Networks are particularly vulnerable as they allow very rapid spread of the virus to all systems connected to the network. A program that is infected with a virus can infect any host in which the program is used. Because of the insidious nature or a virus, any user may become an unwitting propagator. Commerce's dependence on networked computer systems, personal computers (PCs), and office automation makes us susceptible to virus "attacks." Computer viruses have become a threat to virtually everyone using a computer. A virus can destroy programs and data by copying itself to other programs. It is then executed when the infected program is run. It can disable computers and entire computer networks. It can also cause lost computer time and staff resources to track and eliminate it. Most operating units within the Department have been infected with different computer viruses. In many cases, data was not lost but time and staff resources were wasted tracking and eliminating these viruses. PCs are more susceptible to viruses than other types of computers due to their widespread use. However, viruses can be created for any type of computer. Malicious programs such as Trojan horses and trap doors were originally written for mainframe computer systems. Introduction of malicious programs into these larger systems is usually caused by unauthorized users accessing a system without adequate controls or by authorized users making unauthorized use of the system. Sound IT security procedures will help detect and prevent computer viruses and other malicious programs from spreading or causing damage. The guidelines contained in this document can be adapted for any type of computer system. C. Background and Authority: Due to the widespread threat from computer viruses to all organizations, both private sector and government, it has become necessary to implement specific measures designed to reduce this threat and the potential damage caused by virus infections to DOC IT systems. The DOC malicious software policy is established in compliance with the "Computer Security Act of 1987," Office of Management and Budget (OMB) Circular A-130, and the "Computer Fraud and Abuse Act", Public Laws 98-473 and 99-474, 18 U.S.Code 1030. D. Scope: This policy covers all IT systems that are used to process Commerce data, including contractor-owned and/or contractor-operated systems. This policy applies to all employees, personnel from other organizations, contractor personnel, and vendors using Commerce systems participating in DOC sponsored software development, software demonstrations, and the operation and maintenance of IT systems. E. Policy: All DOC organizations will establish and implement a process and procedures to minimize the risk of introducing viruses and other malicious software, to ensure timely detection of viral infections, to provide procedures for eliminating viral infections from the Department's inventory of microcomputers (PCs), and to provide procedures to minimize the risk from malicious programs to larger systems, or systems where virus detection software is not yet available. F. Responsibilities and Process: Responsibilities The Director for Information Resources Management is responsible for the Department's IT security program. This includes establishing IT security policies and procedures for safeguarding Departmental IT resources. The Departmental IT Security Manager shall serve as the central point of contact for all matters relating to IT security for the Department and will be responsible for developing a process for disseminating information concerning the potential dangers from, and guidelines for control of, malicious software. Operating unit IT Security Officers (ITSO) are responsible for: 1. Developing appropriate procedures and issuing instructions for the prevention, detection, and removal or malicious software consistent with the guidelines contained herein; 2. Ensuring all personnel within the operating unit are made aware of this policy and incorporating it into IT security briefings and training programs; 3. Identifying and recommending software packages for the detection and removal of malicious software; 4. Developing a system for users to report computer viruses and other incidents and then notifying potentially affected parties of the possible threat; 5. Promptly notifying the Departmental IT Security Manager of all IT security incidents including malicious software; 6. Providing assistance in determining the source of malicious software and the extent of contamination; 7. Providing assistance for the removal of malicious software; and 8. Conducting periodic reviews to ensure that proper security procedures are followed, including those designed to protect against malicious software. Managers must ensure that employees and contractors follow operating unit procedures which comply with this policy. Employees, personnel from other organizations using DOC systems, contractor personnel, and vendors are responsible for following operating unit procedures for the protection of IT resources to which they have access. This includes reporting IT security incidents, involving viruses and other malicious software to their manager or supervisor and the ITSO for their organization. Requirements The requirements defined in this section, when implemented, will minimize the risk from introduction of viruses and other malicious software to DOC IT systems and networks. Not all requirements listed will apply to every IT system or network. Each organization must consciously evaluate the appropriateness of each of the following policies and implement those that apply to the category for their particular system. 1. Procedures. Each operating unit will establish appropriate procedures for adherence to this policy based on the criticality, sensitivity, and risks to their IT systems. Until virus detection software becomes available for all types of IT systems, the best protection against malicious software attacks is to establish good IT security procedures to control access to and actions taken on the IT system. 2. Backing up software and data. Employees should back up new software immediately, retaining the original distribution diskettes in a safe and secure location. Write-protect original diskettes prior to making back-up copies. If a virus destroys the working copy, the original software is still available. Copying copyrighted software material without the vendor's consent is illegal. If a vendor has not provided pre-approval of backup copies, employees must have vendor approval to create additional copies. Use only newly-formatted diskettes for copying software for backup storage. Used disks may already contain malicious programs which would contaminate the backup copies. Data files should be backed up frequently and stored off-site or in a secured environment. Restore damaged software programs from the original diskettes, not from regular backups. A virus may have been introduced prior to backup. 3. Outgoing software. A serious impact on the credibility of the Department would result from being identified as the source of a virus. Therefore, all software and data leaving the Department must be checked for viruses or other malicious coding. Use only new media for making copies for distribution. Where possible, use a stand-alone computer system when preparing copies for distribution. PC systems to which access is somewhat open, (i.e., training rooms or user laboratories, etc.) should never be used as a source of software or files to be transmitted and/or copied for distribution, without first taking steps to ensure that the system is free from viruses or other malicious software. 4. Software. All PC machine-readable media will be scanned for malicious software before initial use. Follow all vendor instructions carefully and write-protect virus scanning software media prior to use. Scanning software can become contaminated in the same way as other software. Although software sealed in "shrink-wrapped" plastic is usually checked by vendors, it is still advisable to scan this software since there have been reported cases in the Department of software contamination. Write- protect software prior to scanning to prevent possible contamination from system and virus scan software being used. Several reputable software packages are available to detect and/or remove viruses from machine-readable media. There are also utilities that can search text files for virus signatures. Most packages are designed for PC systems and local area networks, but may not be adequate for all PC operating systems. There are very few available for larger systems. Requirements to scan for malicious software are to be implemented as soon as the tools become available for a particular combination of hardware and software. Establish controls for local area networks that prevent anyone except the system administrator or other authorized staff from loading software on file servers. Ensure that operating system files and other executable files are read-only. If possible, disable the network mail facility from transferring executable files. This will help prevent network worm programs from spreading through the network. Trojan horses and other similar malicious software programs are most often introduced by insiders and it is not unusual for larger systems to be the target. The best protection against attacks of this type are to establish good management procedures. Effective controls include separation of duties, limiting individual access and allowed actions to what is needed and no more, formal change control and configuration management procedures, separation and testing of development versus production software and control over installation of new software versions. Frequent backups of the system and data will allow recovery should an incident occur. 5. Authorized software. It is imperative that machine-readable software and data files be obtained from reliable sources. Viruses are often spread through free or shared programs, games, demonstration programs, and programs downloaded from bulletin boards. Employees must not use privately-owned software or take software from their office without management approval. Commercial software must be obtained through appropriate procurement channels. In-house developed software must be done in accordance with established policy within the operating unit and have prior management approval. Shareware and freeware software must be obtained only with prior management approval. Software obtained electronically from bulletin boards should be downloaded to newly formatted diskettes and not directly to the computer hard disk. All newly acquired software, regardless of source, is subject to the scanning requirements in sub-paragraph 4 above. 6. Employee demonstrations. When possible, employees demonstrating DOC products must be certain that the hardware and software they are using are free of viruses. Use hardware write-protection mechanisms (i.e., read-only diskettes with write tabs; write-protect rings for tapes; knock-out rings on cassettes, etc.) to avoid any virus from infecting the media. If possible, check the hardware for viruses before loading the demonstration software. Do not allow other software to be used until the demonstration is completed. 7. Passwords. For larger systems and networks, user identification and passwords are the primary protection mechanism against malicious software. If the would-be perpetrators cannot get into the system, they cannot put malicious software on the system. When possible, all IT systems that are shared resources, including local area networks and multi-user stand-alone systems shall implement a user identification and verification system, such as a USERID and password. Conformance to the requirements of Chapter 10, Section 10.16 of the "DOC IT Management Handbook," and Section 16 of the "DOC IT Security Manual" in establishment, structure, individual accountability, periodic changing and removal are required. Log files should be reviewed periodically to detect unusual activity. Terminals, workstations and networked PCs should never be left unattended when logged in. 8. Vendor demonstrations. Vendors will demonstrate their software on stand-alone hardware, where possible. An employee must scan the stand-alone hardware before it is used by the vendor to verify that the computer does not contain any viruses. This shows the Department acted in good faith to prevent infecting the vendor's software. An employee will scan the stand-alone hardware when the demonstration is completed to determine if the vendor software contains a virus and remove it from the system. The vendor should be notified immediately to prevent further infections. In the case of network software demonstrations, the system administrator must approve and coordinate the demonstrations. Written certification from the vendor that the demonstration software has been checked and is free from viruses, should be obtained prior to loading any vendor software. 9. Hardware. PC hard disk drives, network file servers and other media which will be used to handle departmental information will be formatted between the time they are received and put into use. There have been cases of formatted hard disk drives being received that contained viruses. This requirement also applies to replacement parts resulting from repair and maintenance of equipment. This requirement may be waived only if the vendor installing the software provides a written certification that the system and software have been checked and are virus free. Never start up (boot) your computer from a diskette unless it is the original write-protected system master or a trusted copy. Portable computer systems, such as laptops, that leave Department controlled areas must be scanned for viruses before and after connecting to systems or software owned by other organizations. Never use a local area network file server as a workstation. File servers should be located in areas where access is restricted during working hours and locked after hours. When available and cost effective, virus detection software capable of continuous monitoring and reporting malicious programs, should be installed on hard disks to prevent contamination. Periodic scans of hard disks, using virus detection software, should be performed for systems without this protection installed. Lock computers and terminals or disconnect keyboards and store in a secure location, when not in use, to prevent unauthorized access. Lock doors to areas containing computers and terminals. 10. Procurement requirement. All procurements for computer software and hardware will contain a requirement that the vendor have antiviral procedures in place to ensure that the media supplied is uncontaminated by malicious software. In the case of small, off-the-shelf procurements where it is not possible to write antiviral clauses, the software will be scanned with virus detection software prior to use. Procurements for PC system maintenance should also require antiviral procedures on the part of the contractor. Vendors depend on the reputation of their products to ensure future sales. Reputable vendors are concerned about correcting any flaws in their systems or products that would make them vulnerable to attack from viruses or other malicious software, and on occasion issue recommended changes to improve security of their products. System administrators and managers are to implement any vendor recommended changes, or security fixes as soon as possible, after official receipt. Malicious Software Indicators If your IT system seems to be acting different than usual, a malicious software incident may have occurred. Below are a few signs that may indicate that a system has been infected. 1. Any unexplained messages or graphics on the screen, 2. An increase in the time required to load or execute programs, 3. An increase in the time required for disk accesses or processing from disk, 4. Unusual error messages, 5. Programs or files mysteriously disappearing, 6. Less memory available than usual, 7. Executable files changing size for no apparent reason, 8. Accesses made to non-referenced devices, 9. Data consistently out of balance, 10. File date and time stamps changing for no apparent reason, 11. Obsolete user accounts in use, 12. The presence of unexplained hidden files and/or 13. Unusual network activity. If your system demonstrates any of the above, it could indicate that malicious software is present. Elimination, Recovery and Reporting If you suspect that your IT system or network has been attacked by a virus or other malicious software program, do not attempt to fix the problems, but immediately report it to your supervisor and the ITSO for your operating unit. They will determine the appropriate action to control the damage and report the incident to the DOC IT Security Manager. It is important that the particular virus or other malicious software program, source, and potential for proliferation be identified and controlled. The initial report to the DOC IT Security Manager should be made within 24 hours of the incident. This report may be verbal and should include the following information: Date and time of incident Location Equipment type, make and model Malicious software type Method of discovery Virus name (if known) DOC system number (if known) Source of malicious software (if known) Apparent effect Within ten working days of the incident, a written report will be prepared and sent to the DOC IT Security Manager of the incident by the operating unit ITSO. This report will include the following along with all of the above information: Impact on operation Severity, including hours devoted to recovery and any additional costs incurred Proliferation, number of machines or media infected Action taken - how malicious software was cleared, who was notified, including outside organizations, and what steps were taken to identify the source If the problem has not been resolved within ten working days, mark the written report "Interim" and prepare and forward a "Final" report when the incident is resolved. In cases where resolution is not possible within 30 days, a written status report describing the actions taken and planned to resolve the incident must be sent to the DOC IT Security Manager monthly. G. Definitions: Introduction of viruses and other malicious software programs has generated a whole set of new terms. The following list of definitions is provided to familiarize personnel with some of these terms. 1. Bacterium. A late bloomer in the infectious terminology jargon is a "bacterium." It is a program that replicates itself and becomes a parasite on the host system by preempting processor and memory capacity. 2. Computer virus. A program that "infects" computer systems in much the same way as a biological virus infects humans. The typical virus "reproduces" by making copies of itself and inserting them into other programs--either in systems software or in application programs. 3. Flying Dutchman. A feature of Trojan horse malicious programs that erases all traces of the programming codes from the computer's memory and eludes any detection. 4. Logic Bomb. A computer code that is preset to cause a later malfunction when a specified set of logical conditions occur. For example, a specific social security number in a payroll system is processed and the logic bomb is activated, causing an improper amount of money to be printed on the check. 5. Machine-readable media. Media that can convey data to a given sensing device, e.g., diskettes, disks, tapes, computer memory. 6. Malicious Software. Any of a family of computer programs developed with the sole purpose of doing harm. Malicious code is usually embedded in software programs that appear to provide useful functions but, when activated by a user, cause undesirable results. 7. Scan. To examine computer coding/programs sequentially, part by part. For viruses, scans are made for virus signatures or potentially unsafe practices. (e.g., changes to an executable file, direct writes to specific disk sectors, et al.). 8. Time Bomb. Computer code that is preset to cause a later malfunction after a specific date, time or a specific number of operations. The "Friday the 13th" computer virus is an example. This virus infects the system several days or even months before and lies dormant until the date reaches Friday the 13th. 9. Trap Door. A set of instruction codes embedded in a computer operating system that permits access while bypassing security controls. 10. Trojan Horse. A program that causes unexpected (and usually undesirable) effects when willingly installed or run by an unsuspecting user. A person can either create or gain access to the source code of a common, frequently used program and then add code so that the program performs a harmful function in addition to its normal function. These programs are generally deeply buried in the code of the target program, lie dormant for a preselected period, and are triggered in the same manner as a logic bomb. A Trojan horse can alter, destroy, or disclose data or delete files. 11. Virus detection software. Software written to scan machine-readable media on computer systems. There are a growing number of reputable software packages available that are designed to detect and/or remove viruses. In addition, many utility programs can search text files for virus signatures or potentially unsafe practices. 12. Virus signature. A unique set of characters which identify a particular virus. This may also be referred to as a virus marker. 13. Worm. A worm is a complete program that propagates itself from system to system, usually through a network or other communication facility. A worm is similar to a virus--it is able to infect other systems and programs. A worm differs from a virus in that a virus replicates itself, which a worm does not. A worm copies itself to a person's workstation over a network or through a host computer and then spreads to other workstations. It can easily take over a network as the "Internet" worm did. Unlike a Trojan horse, a worm enters a system uninvited. H. References: Viruses and other malicious software appear to be a growing problem with new strains of viruses appearing continuously. Users of IT systems should become as familiar with the subject as possible, in order to protect against this threat. The following documents published by the National Institute of Standards and Technology are good sources of additional information: John Wack and Lisa Carnahan, Computer Viruses and Related Threats: A Management Guide, NIST Special Publication 500-166, August 1989. Dennis Steinauer, Security of Personal Computer Systems: A Management Guide, NBS Special Publication 500-120, January 1985. An Abbreviated Bibliography for Computer Viruses and Related Security Issues, NIST, Revised April 18, 1990. SECTION 4 ACCREDITATION A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy for accreditation of all unclassified sensitive and classified national security Information Technology (IT) systems. B. Overview: Accreditation is the authorization and approval, granted to a sensitive or classified IT system to process, as an acceptable risk, in an operational environment. Accreditation is made on the basis of recommendations from a technical certification evaluation that the IT system meets all applicable federal and DOC policies, regulations, and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system; that they are operating correctly; or, that the system must be operated under certain specified conditions or constraints. C. Background and Authority: Accreditation is a requirement of Office of Management and Budget (OMB) Circular Number A-130 and the "Computer Security Act of 1987," Public Law 100-235. D. Scope: The policy contained in this document covers all DOC IT systems, whether maintained in-house or commercially. Accreditation is required for all sensitive and classified DOC General Support and Application systems. New IT systems or those not fully operational shall complete all requirements and be accredited prior to full implementation. E. Policy: This policy defines the final step in the IT Security management process that ensures protection of the vital IT resources within the Department. Initial Accreditation All sensitive and classified DOC IT General Support or Application systems will be accredited. The term accreditation describes the process whereby information pertaining to the security of a system is developed, analyzed and submitted for approval to the appropriate senior management official identified in this document as the Designated Approving Authority (DAA). Section F, of this document, identifies the required steps in the accreditation process. The DAA will review the accreditation support documentation and either concur, thereby declaring that a satisfactory level of operational security is present or not concur, indicating that the level of risk either has not been adequately defined or reduced to an acceptable level for operational requirements. The DAA will sign a formal accreditation statement declaring that the system appears to be operating at an acceptable level of risk, or defining any conditions or constraints that are required for appropriate system protection. Sample accreditation statements are contained in Attachment 1 of this document. Security of classified IT systems operated by, or in support of DOC programs is the responsibility of the Department and these systems must be accredited in accordance with the requirements defined in this policy. Approvals granted by external agencies, i.e., Department of State, Department of Defense, Central Intelligence Agency, etc., are not valid authority to operate classified IT systems within the Department. Approvals granted to these systems by DOC, prior to this policy, are no longer in effect and new approval to operate must be granted through the DOC accreditation process. Interim Accreditation Interim authority to operate can be granted for a fixed period of time, not to exceed one year. This authority is based on an approved security plan and is contingent on certain conditions being met. The interim authority to operate, while continuing the accreditation process, permits the IT system to meet its operational mission requirements while improving its IT security posture. If the DAA is not satisfied that the IT system is protected at an acceptable level of risk, an interim accreditation can be granted to allow time for implementation of additional controls. Recommendation or request for an interim accreditation may be made by the IT system owner, the operating unit IT Security Officer (ITSO) or the DAA. Interim authority to operate is not a waiver of the requirement for accreditation. The IT system must meet all requirements and be fully accredited by the interim accreditation expiration date. No extensions of interim accreditation can be granted except by the DOC Director for Information Resources Management. Reaccreditation Systems will be reaccredited when major changes occur to the system or every three years, whichever occurs first. Examples of major changes include: 1. Changes in the system or software applications - Substantial changes which alter the mission, operating environment or basic vulnerabilities of the system. Increase or decrease in hardware, application programs, external users, hardware upgrades, addition of telecommunications capability, dial-in lines, changes to program logic of application systems, relocation of system to new physical environment or new organization. Minor changes such as, replacement of similar hardware when capacity does not significantly change, addition of two or three workstations on a network or small modifications to an application program (e.g., table headings are changed) would not require reaccreditation. 2. Changes in protection requirements - Changes in the sensitivity or classification level of the data being processed, increase in the mission criticality of the system or changes in federal or DOC policies. 3. Occurrence of a significant violation - A violation or incident that calls into question the adequacy of the system security controls. 4. Audit or evaluation findings - Findings from any security review that identifies significant unprotected risks. These could include the system security verification review, physical or information security inspection, internal control reviews, Office of the Inspector General (OIG) audits or General Accounting Office (GAO) audits. Prior to reaccreditation, an on-site IT security verification review must be conducted by an evaluation team under the direction of the DOC IT Security Manager, the operating unit ITSO or the ITSO of a subordinate organizational unit (i.e., Line Office, Regional Office, Laboratory, etc.) The IT security verification review team may not be under the direction of personnel from the subordinate organization having direct control over the IT system being evaluated. The IT System Security Officer (ITSSO) for the system under review should participate as a member of the IT security verification review team. The purpose of this review is to ensure that all controls and vulnerabilities are properly documented, and that adequate and appropriate levels of security exist for protection of the system. Requirements and guidance for conducting IT serurity verification reviews are contained in Chapter 10, Section 10.5 of the "DOC IT Management Handbook" and Section 5 of the "DOC IT Security Manual." F. Responsibilities and Process: Classified National Security IT Systems 1. The DOC Director for Information Resources Management is the DAA for all classified IT systems within the Department. This authority can not be delegated below this level. Accreditation will be granted only with the recommendations of the DOC Director, Office of Security, DOC Chief, Telecommunications Management Division and the DOC IT Security Manager. 2. The DOC IT Security Manager will act as the central point of contact for accreditation of classified IT systems and will evaluate the adequacy of all technical controls protecting these systems. The DOC IT Security Manager will review all accreditation documentation, evaluate the security controls for the IT system and conduct on-site reviews, if necessary, to ensure they meet all applicable federal and DOC policies, regulations and standards and that they appear to be adequate and appropriate for protection of the system. The DOC IT Security Manager will submit recommendations to the DAA for or against accreditation. Recommendation should include any additional controls or constraints required to meet a satisfactory level of operational security. 3. The Chief, Telecommunications Management Division will evaluate all supporting accreditation documentation and conduct on-site inspections, when necessary, to ensure compliance with all Communications Security (COMSEC) and emanations (TEMPEST) security requirements as required by the Chapter 8 of the "DOC IT Management Handbook." 4. The DOC Director, Office of Security will evaluate all supporting accreditation documentation and conduct on-site inspections, when necessary, to ensure compliance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." Unclassified Sensitive IT Systems 1. The Senior Information Resources Management official in each operating unit will be the DAA for all sensitive systems within their organization. This approval authority may only be delegated to a senior management official of a subordinate organizational unit, if that official does not have direct control over the IT system being accredited. Delegation of accreditation authority must be requested and approved in advance by the DOC Director for Information Resources Management. 2. The operating unit ITSO will act as the central point of contact for accreditation of all sensitive IT systems within the organization. The ITSO will review all accreditation documentation, evaluate the security controls for the IT system and conduct on-site reviews, if necessary, to ensure they meet all applicable federal and DOC policies, regulations and standards and that they appear to be adequate and appropriate for protection of the system. The ITSO will submit recommendations to the DAA for or against accreditation. Recommendations should include any additional controls or constraints required to meet a satisfactory level of operational security. The operating unit ITSO will submit an accreditation status report quarterly to the DOC IT Security Manager, listing accredited systems by DOC identification numbers, including interim accreditations, and the completed date. A copy of all official accreditation statements will be forwarded with this list. IT System Owners Chapter 10, Section 10.1 of the "DOC IT Management Handbook" and Section 1 of the "DOC IT Security Manual" contain specific information about designation of ownership of IT systems and data. Owners of DOC IT systems will complete all required actions and prepare an accreditation package including all documentation identified in this section. For classified IT systems, the accreditation package will be forwarded to the DOC IT Security Manager through the ITSO and the Senior Information Resources Management official for the operating unit. Sensitive IT system accreditation packages will be forwarded to the appropriate ITSO for the operating unit. The information included in the accreditation package will contain details about the system, which may identify weaknesses or vulnerabilities which require protection against disclosure to persons without an official need to know. Accreditation packages for sensitive systems will be marked at least "For Official Use Only." Classified IT system accreditation packages will be marked in accordance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." The following actions shall be completed and the appropriate documentation prepared and submitted in the accreditation package to the appropriate DAA for the IT system: Request for Accreditation The system owner will prepare a written request for approval to operate the IT system and forward the documentation listed below to the appropriate DAA. The written request will include a certification statement that the IT system has undergone adequate tests to ensure that it meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system. Approved IT System Security Plan A detailed IT system security plan will be prepared by the system owner, in the required format provided in the "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems," contained in Section 2 of the "DOC IT Security Manual." The purpose of the system security plan is to provide a basic overview of the security and privacy requirements of the subject system and the IT system owner's plan for meeting those requirements. The plan may also be viewed as documentation of the structured process of planning adequate, cost-effective security protection for the system. The IT system security plan must be forwarded through the operating unit's ITSO for review and comment, and once all corrective actions have been completed, to the DOC IT Security Manager for final approval. A statement of approval will be sent to the operating unit ITSO for forwarding to the IT system owner. Security plans must be reviewed by the system owner, at least annually, and changes submitted, as necessary, to ensure they are up-to-date. Chapter 10, Section 10.2 of the "DOC IT Management Handbook" contains the DOC policy for IT system security plans. Section 2 of the "DOC IT Security Manual" contains detailed guidance for preparation of these plans. Completed Risk Analysis IT system owners are responsible for having a risk analysis conducted for each IT system to ensure that appropriate, cost effective safeguards are incorporated into existing and new systems. A risk analysis will be conducted prior to approval of design specifications for new systems, when major changes occur to the system or every three years, whichever occurs first. Examples of major system changes are given in Section E., Reaccreditation, of this document. See Chapter 10, Section 10.7 of the "DOC IT Management Handbook" and Section 7 of the "DOC IT Security Manual" for guidance on conducting the required risk analysis. Contingency/Disaster Recovery Plans Each IT system shall develop and maintain, in an up-to-date state, a contingency and disaster recovery plan which will provide reasonable assurance that critical data processing can be continued, or resumed quickly, if normal operations are interrupted. The plan for large systems supporting essential Departmental or agency functions shall be fully documented and operationally tested at least annually. Small systems may develop a more abbreviated and less formal plan. Policy concerning contingency/disaster recovery planning is contained in Chapter 10, Section 10.8 of the "DOC IT Management Handbook" and Section 8 of the "DOC IT Security Manual." Additional guidance is contained in Section 7 of the "DOC IT Security Manual." Software Application Certification Statements Sensitive application software shall be thoroughly tested prior to implementation to verify that the user functions and the required administrative, technical, and physical safeguards are present and are effectively operating as intended. If the system to be accredited is running major applications requiring separate certification, system owners will provide copies of all software application certification and recertification statements as part of the accreditation package. General support system owners running applications belonging to other organizations are not required to provide these certification statements. Certification Testing of Security Controls Prior to accreditation, each IT system is to undergo appropriate technical evaluations to ensure that it meets all federal and DOC policies, regulations and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system. The technical evaluation results are the basis for the system owner's certification statement in the accreditation request. The letter should state what methods were used to perform the certification evaluation. The DOC certification policy is contained in Chapter 10, Section 10.3 of the "DOC IT Management Handbook." Section 3 of the "DOC IT Security Manual contains two approved methodologies for conducting certification testing. The following certification evaluation documentation will be included in the accreditation package, as applicable: 1. System Owner Certification Reports Include a copy of the certification review report that shows: (1) that controls function properly; (2) that controls satisfy performance criteria and provide for availability, survivability and accuracy; and (3) that the controls cannot be easily broken or circumvented. Copies of evaluation results should be included. 2. Other Internal Reviews The results of any security related reviews performed by evaluation teams internal to the operating unit or the system owner's organization may be used as part of the certification evaluation. Copies of review findings and corrective actions should be included in the accreditation package. 3. External Reviews The results of any audits performed by independent external organizations may also be used as part of the certification evaluation. Copies of audit findings and corrective actions taken should be included in the accreditation package. For classified IT systems, external organizations such as Department of Defense, National Security Agency, State Department, Central Intelligence Agency, etc., who have specific requirements for data under their area of responsibility, may also perform reviews and inspections. Any authorizations or approvals provided by these external organizations are important certification documentation and must be provided with the request for accreditation. ATTACHMENT 1 SAMPLE ACCREDITATION STATEMENTS Full Accreditation: I have carefully examined the accreditation package documentation for DOC Information Technology (IT) System Number ______, "ABC Computer Center," dated ____________. Based on my authority and judgment, and weighing the remaining residual risk against operational requirements, I authorize (continued) operation of this system (under the following restrictions). (restrictions) I hereby accredit DOC IT System Number ______, "ABC Computer Center," as an unclassified sensitive system, for a period not to exceed three years. Should any major changes occur to this system during this three year period, a re-evaluation of the adequacy of its security controls must be conducted and a reaccreditation requested. _____________________________________ DAA Signature and Date Interim Accreditation: I have carefully examined the accreditation package documentation for DOC Information Technology (IT) System Number ______, "ABC Computer Center," dated __________. Based on my authority and judgment and the recommendation of the (System Owner, ITSO or DAA judgmentt) it does not appear that this system has reached a satisfactory level of operational security (or the following actions must be completed or additional controls implemented prior to full accreditation). (actions or additional controls required) I hereby grant an interim accreditation to DOC IT System Number ______, "ABC Computer Center," for a period not to exceed six months to allow time to (take action or implement additional controls required). Prior to the expiration of this interim accreditation on _______________, the accreditation package shall be resubmitted showing that a satisfactory level of operational security has been reached. ______________________________________ DAA Signature and Date SECTION 5 INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEWS A. Purpose: The purpose of this section is to establish Department of Commerce (DOC) policy for conducting information technology (IT) security verification reviews of the Department's sensitive and classified national security IT systems. The purpose of the IT security verification review is to provide a level of review and evaluation independent of the system owner, that will verify that adequate and appropriate levels of protection are being provided for the individual systems, based on their unique protection requirements. B. Overview: Protection requirements for each of the individual IT systems within the Department will vary according to the unique characteristics of the system, environmental concerns, data sensitivity and mission related criticality of the system or data. Total protection against all threats may be an unrealistic goal. Appropriate levels of security must be determined by an evaluation of the threats, vulnerabilities and risk factors associated with each system. Cost-effective controls that are adequate to achieve an acceptable level of risk for the individual system must then be implemented. System owners are responsible for completing all DOC and federal requirements for identifying their sensitive and classified systems, preparing security plans that provide a basic overview of the security and privacy requirements of the subject system and the system owner's plan for meeting those requirements, conducting risk assessments, implementing controls determined to be required and cost-effective, developing contingency and disaster recovery plans that will ensure availability of the system for mission accomplishment and completing all requirements for certification and accreditation of the system. The IT security verification review process provides an independent means to ensure that the system owner has implemented adequate and appropriate levels of protection, based on the system's unique requirements. The IT security verification review process is part of the Department's oversight program. C. Background and Authority: The DOC IT security verification review process is established in compliance with the "Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems" and OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information." D. Scope: The policy contained in this document covers all DOC IT resources that have been identified as either sensitive or classified national security systems whether maintained in-house or commercially. E. Policy: An IT security verification review will be conducted on all DOC sensitive or classified national security IT systems by an evaluation team under the direction of the DOC IT Security Manager or the operating unit ITSO or the ITSO of a subordinate organizational unit every three years. The security plan for the system will be used as the foundation for the actual review. The review will be conducted in accordance with the guidance contained in the "DOC Guidelines for Conducting IT Security Verification Reviews of Sensitive and Classified Systems," Attachment 2 to this document. F. Responsibilities and Process: IT Security Verification Review Team The IT security verification review team will always be under the direction of the DOC IT Security Manager or the IT Security Officer (ITSO) at the operating unit level or a major subordinate organizational unit. This should assure the level of knowledge about the DOC IT security program requirements is adequate to make decisions about the appropriateness and adequacy of controls required for the system under review. Whenever possible, these individuals should participate in the on-site review as the team leader. When the ITSO is unable to participate in the actual review, they will appoint an individual who is judged to have sufficient knowledge about the DOC IT security program to act as the review team leader. Additional team members should include personnel knowledgeable about physical and environmental security, personnel security, information security (if system processes classified national security information), application security, hardware and software, telecommunications, technical controls, procedural security, contingency and disaster recovery planning and risk management. Personnel from the Internal Control Review area within the organization are also suggested as team members. The actual number of team members may vary and should be limited to the smallest number possible to cover all areas of concern. The average team will include two to four individuals, but should be comprised of no less than two people. Operating units may contract out for IT security verification reviews to be conducted by commercial consulting firms or other federal organizations. However, care should be taken in preparing the procurement requests or agreements to ensure that the review will be conducted in accordance with all DOC policies and standards. The operating unit ITSO will act as the COTR for the contract, provide all directions for conducting the review and set standards for written reports. The team leader will be responsible for notifying the system owner of the planned review, making specific review assignments to individual team members based on their expertise, coordinating activities of team members, conducting an in-briefing and an exit-briefing with the system owners, conducting team meetings as required, making decisions about what recommendations are appropriate for the individual system and preparation of the draft and final "IT Security Verification Review Report." The format and guidance for preparing this report is contained in Attachment 1 of this document. Conducting the Review Written notification should be sent to the system owner two to four weeks in advance of the review, providing information concerning the purpose of the review, dates of the review, list of review team members, requesting the assignment of a point of contact and that the following documentation be made available to the review team. 1. Memorandum officially designating an individual as the IT System Security Officer (ITSSO) 2. Listing of current personnel (indicate working hours for ADP personnel) 3. Hours of operation of facility 4. Organization charts for highlighting the placement of the individual facilities 5. Applicable floor plans (including building floor plans) 6. Latest risk analyses for the system 7. Reports of external and internal security (both ADP and other) evaluations completed during the 3 years 8. Hardware inventory (to include minis and micros) 9. Software inventory (include production programs, utility programs, commercially available software, operating systems, etc.) 10. List of users: a.within the Department b.at other federal agencies c.others 11. Disaster recovery plans 12. Policies, directives, guidelines, etc., pertaining to IT security issued by local authorities 13. Minutes of any management meetings that address IT security 14. Any other documentation pertaining to IT security 15. Information pertaining to IT security awareness and training including course content, type of training and number of personnel who have completed or are scheduled for training 16. Information pertaining to ADP-related position sensitivity and personnel screening for facility 17. Copies of any contracts for operation and maintenance or other service agreements related to this system 18. Reports of any internal IT security reviews that may have been conducted 19. Reports of any Internal Control Reviews or any reviews conducted by other external or internal organizations 20. Discussion of any known needs for guidance or assistance or specific areas of concern in IT security from either the operating unit, Department or federal levels 21. Sensitive System Security Plan 22. Certification documentation, if available The system owner should appoint an individual, usually the ITSSO, to act as the point of contact for the review team. This individual should participate as an observer in the review and coordinate interviews or make other arrangements as necessary to assist the review team. An entrance meeting should be arranged to allow the review team to explain its mission and review methods to the system owner and staff members. During the course of the review, the team will discuss their findings and recommendations with the point of contact or system owner and keep them advised about the progress of the review. The security plan for the system will be used as the foundation for the actual review. The security plan will provide information about the technical and physical system, its sensitivity level and its protection requirements. The security plan is intended as a basic overview and will not contain the level of detailed information that the review team will need in making decisions about its actual security requirements. However, the plan should be accurate and reflect the actual system description, protection requirements and controls in place, Verification of the accuracy of the plan is an important element of the review process. Recommendations to improve the quality of the security plan should be made during the course of the review. In many cases, the review team may find that many of their recommendations will concern changes to the security plan and not to the actual system controls. Prior to the actual on-site review of the system, all team members should be provided with a copy of the security plan for the system to be reviewed. The team should meet to discuss the scope of the review, which will be determined by the size, sensitivity level, type and complexity of the system as identified in Section I. through Section III.B. in the security plan. During the actual on-site review, it is recommended that the team leader be the evaluator to verify the information contained in these sections of the plan. The team leader should share the results of the verification with all other team members to ensure that their reviews are based on accurate requirements for the system. Although it is not necessary for all team members to be experts about what controls are appropriate for every type system, they should be given enough guidance about the system under review to avoid wasting too much time asking questions that are not relevant for the particular system. A very obvious example of this would be if the system under review is a microcomputer or local area network system, asking questions relating to a computer room would not be relevant. A less obvious example would be for a system that contains nothing but public information, asking multiple questions about confidentiality controls would be a waste of time and might lead to inappropriate recommendations. Other considerations that would have a bearing on determining adequate and appropriate protection requirements for a specific system would include the physical location, environment, category of system, telecommunication configuration, sensitivity of data, availability requirements and importance to mission accomplishment. It is important to understand that the IT security verification review is not intended to be a risk analysis. Testing of actual controls will be limited to only those necessary to verify their existence and proper operation. If documentation of prior testing of controls appears adequate (i.e., risk analysis or system certification documentation) then further testing would not be conducted. Appropriate tests might include such things as: (1) having system owner demonstrate access controls on the system (i.e., logging into the system to ensure password is blanked, attempting to establish passwords outside established password constraints, viewing SCREEN WARNING messages, attempting to access files that should be restricted, etc.); (2) attempting to access computer room outside normal working hours to ensure doors are locked or verifying that visitors are challenged. Evaluators are not to attempt penetration of the computer or to remove any system resources (i.e., equipment, media or printed output, etc.), as these actions could be considered security violations. At the conclusion of the review, the "IT Security Verification Review Report" will be prepared in the format outlined in Attachment 1 of this document. A copy of the draft report with major findings and recommendations should be provided to the system owner during the exit-briefing. Within two weeks after the conclusion of the review, the system owner should provide the review team leader written comments or questions about the draft report findings and recommendations. The review team should consider the system owner's concerns and prepare and forward the final report for the system owner's action. The information included in the "IT Security Verification Review Report" will contain details about the system, which may identify weaknesses or vulnerabilities which require protection against disclosure to persons without an official need to know. Reports for sensitive systems will be marked at least "For Official Use Only." Classified IT system reports will be marked in accordance with appropriate national security directives and DAO 207-2, "DOC National Security Information Manual." Use of the "IT Security Verification Review Guideline" The guideline, contained in Attachment 2, provides a structured process for accomplishment of the required IT security verification review for DOC IT systems. It was developed following the format required for DOC IT system security plans and provides detailed questions for each section contained in the plans. Since the purpose of the IT security verification review is to determine if the individual IT system has been provided with adequate and appropriate levels of protection based on its unique protection requirements, many of the questions under specific control areas will not apply to all IT systems. An attempt has been made in developing the "IT Security Verification Review Guideline" to formulate questions that cover the majority of possible security concerns and requirements that could possibly apply to any DOC sensitive or classified IT system. The questions are not intended to be all inclusive, and answers provided may generate other questions. Additional questions may also result from the review of system documentation and records or as the result of interviews or observations by the team members. Team members will be required to rely on their judgement about what is appropriate and adequate protection requirements for the system they are evaluating. The guideline questions should be reviewed by the evaluator in advance of any interviews and those determine not be applicable, marked off. The team leader should be able to assist in determining the appropriate questions or areas to be reviewed. System Owners System owners may also find this guideline helpful in performing management control reviews and the required risk analysis or certification testing of their systems. The guideline contains extensive questions about all categories of controls and could be useful in verifying that adequate consideration of appropriate controls has been included in their risk analysis, certification methodologies or for management control review ideas. It may also serve as a useful tool in identifying additional controls that would be appropriate for their systems. ATTACHMENT 1 INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEW REPORT FORMAT Format The "Information Technology (IT) Security Verification Review Reports" should be consistent across all DOC organizations and should contain the following sections: Cover page Executive Summary Introduction Discussion Objective Method System and Sensitivity Information System Description/Purpose System Environment and Special Considerations General Description of Information Sensitivity Recommendations The following sample report was prepared in the appropriate format and contains guidance for content in each section. (ORGANIZATION CONDUCTING REVIEW) INFORMATION TECHNOLOGY SECURITY REVIEW DOC SYSTEM NUMBER (OPERATING UNIT) (SUB ORGANIZATION) (SYSTEM NAME/TITLE) (CITY, STATE WHERE SYSTEM IS LOCATED) (MONTH, YEAR) EXECUTIVE SUMMARY Introduction An Information Technology (IT) Security Verification Review, in conformance with the requirements of the Computer Security Act of 1987 and Office of Management and Budget (OMB) Bulletin 90-08, was conducted during the period at the (Operating Unit, Sub- organization, System Name/Title, in City, State.) The IT Security Review Team was lead by , (Organization and Title). (List all other team members by name, organization and title) team members. Each team member was assigned specific sections of the Sensitive System Security Plan for the system, to verify and validate the accuracy of the information contained in the plan and to ensure that the system controls were adequate and appropriate for the system. The review was conducted in accordance with guidance contained in the "DOC Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems". The IT Security Review was conducted on the DOC IT System Number , "(Name/Title of System)". The system (describe in general terms the purpose of the system. See Section I.E. in the security plan.) The overall IT security profile of this system was (excellent, very good, good, adequate, inadequate or poor). This paragraph should contain summary information about the findings, including positive actions, controls or other significant items that the system owner has implemented to protect the system. Any major problems noted during the course of the review should be described in general terms or "no major problem were noted". Recommendations primarily concerned (describe in general categories (i.e., improvements in administrative procedures, documentation, contingency planning, backup storage, personnel management and user access control).) The purpose of this review was to improve IT security specifically and IT resource management in general at (system name) and to ensure compliance with prescribed IT security policies and regulations and to identify areas where further security controls may be necessary to improve the protection of the system. At the conclusion of the on-site visit, the review team discussed its preliminary findings with the (system) management and IT security staff personnel who indicated general agreement and a willingness to implement all recommendations (or major objections). Implementation of the recommendations will provide assurance that all risks have been identified and appropriate levels of security exist for protection of the system. DISCUSSION Objective The objectives of this review were to determine the coordination and implementation of activities conducted by the (system organization) to ensure the protection and integrity of information resources such as development of security plans for sensitive and classified systems, ensuring periodic risk assessments are conducted, establishing contingency and disaster recovery plans, implementing a security awareness and training program, performing IT security reviews, and certification and accreditation of sensitive systems. Specific laws, regulations and policies used as guidelines for this review, included: OMB Circular A-130, Appendix III, "Security of Federal Automated Information Systems" Public Law 100-235, the "Computer Security Act of 1987" Department of Commerce, "Information Technology Handbook, Chapter 10, Information Technology Security" OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information" Department of Commerce, "Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems" This review was conducted to evaluate compliance with federal and Departmental IT security policies and requirements and assess the system's IT security profile. Review criteria was based on evaluation of the in-place and planned controls identified in the Sensitive System Security Plan for this system (DOC System Number ). Method The review team's approach in this evaluation was to interview (system name/title) management and staff personnel, observe operations of the system and the physical facilities and resources within the buildings and review all IT security program related documentation. The primary point-of-contact for this system review was (Name and title). Other Staff members contacted during the review included: (List names and titles). During the entrance interview with system management and staff personnel, the review team's mission and methods were explained in detail. SYSTEM AND SENSITIVITY INFORMATION SYSTEM DESCRIPTION/PURPOSE (Copy information contained in Section I.E. of the security plan or correct information after the conclusion of the review.) SYSTEM ENVIRONMENT AND SPECIAL CONSIDERATIONS (Copy information contained in Section I.F. of the security plan or correct information after the conclusion of the review.) GENERAL DESCRIPTION OF INFORMATION SENSITIVITY (Copy information contained in Section II.B. of the security plan or correct information after the conclusion of the review.) RECOMMENDATIONS The review was conducted, using the "DOC Guidelines for Conducting Information Technology Security Verification Reviews of Sensitive and Classified Systems" and the "Sensitive System Security Plan" for DOC System , as the basis. The review included on-site inspections of the facilities, computer room environment, hardware configuration, and interviews of management and computer center personnel The following recommendations are a result of the review findings: The security plan for this system should be updated to incorporate any changes resulting from these recommendations.  Recommendations should be numbered.  Recommendations should be listed by security plan section number. Example Section III.C.2.b. This will relate each finding and recommendation to a specific control category. There may be multiple separate recommendations under a specific section number.  Each finding and recommendation should be discussed with the system owner during the exit briefing in as much detail as possible by the review team member making the recommendation. Every effort should be made to discuss findings with the point of contact or system owner prior to the exit briefing. This will ensure that all significant facts have been taken into consideration about any unique situations or requirements affecting the individual system. Discussion about security requirements during the course of the review also provides an excellent opportunity to increase IT security awareness and training. SECTION 6.1 MALICIOUS SOFTWARE A. Purpose: The purpose or this section is to establish Department of Commerce (DOC) policy to minimize the risk of introducing malicious software into computer systems. It also provides guidelines for the detection and removal of malicious software from information technology (IT) systems. B. Overview: Malicious software presents an increasingly serious security problem for computer systems and networks. Malicious software includes viruses and other destructive programs, such as Trojan horses and network worms. This type or software is often written as independent programs that appear to provide useful functions but also contain malicious programs that can be very destructive. It can be quickly spread through software bulletin boards, shareware, and users unknowingly copying and sharing these programs in an unauthorized manner. It can also be spread by users sharing data files and software products. Networks are particularly vulnerable as they allow very rapid spread of the virus to all systems connected to the network. A program that is infected with a virus can infect any host in which the program is used. Because of the insidious nature or a virus, any user may become an unwitting propagator. Commerce's dependence on networked computer systems, personal computers (PCs), and office automation makes us susceptible to virus "attacks." Computer viruses have become a threat to virtually everyone using a computer. A virus can destroy programs and data by copying itself to other programs. It is then executed when the infected program is run. It can disable computers and entire computer networks. It can also cause lost computer time and staff resources to track and eliminate it. Most operating units within the Department have been infected with different computer viruses. In many cases, data was not lost but time and staff resources were wasted tracking and eliminating these viruses. PCs are more susceptible to viruses than other types of computers due to their widespread use. However, viruses can be created for any type of computer. Malicious programs such as Trojan horses and trap doors were originally written for mainframe computer systems. Introduction of malicious programs into these larger systems is usually caused by unauthorized users accessing a system without adequate controls or by authorized users making unauthorized use of the system. Sound IT security procedures will help detect and prevent computer viruses and other malicious programs from spreading or causing damage. The guidelines contained in this document can be adapted for any type of computer system. C. Background and Authority: Due to the widespread threat from computer viruses to all organizations, both private sector and government, it has become necessary to implement specific measures designed to reduce this threat and the potential damage caused by virus infections to DOC IT systems. The DOC malicious software policy is established in compliance with the "Computer Security Act of 1987," Office of Management and Budget (OMB) Circular A-130, and the "Computer Fraud and Abuse Act", Public Laws 98-473 and 99-474, 18 U.S.Code 1030. D. Scope: This policy covers all IT systems that are used to process Commerce data, including contractor-owned and/or contractor-operated systems. This policy applies to all employees, personnel from other organizations, contractor personnel, and vendors using Commerce systems participating in DOC sponsored software development, software demonstrations, and the operation and maintenance of IT systems. E. Policy: All DOC organizations will establish and implement a process and procedures to minimize the risk of introducing viruses and other malicious software, to ensure timely detection of viral infections, to provide procedures for eliminating viral infections from the Department's inventory of microcomputers (PCs), and to provide procedures to minimize the risk from malicious programs to larger systems, or systems where virus detection software is not yet available. F. Responsibilities and Process: Responsibilities The Director for Information Resources Management is responsible for the Department's IT security program. This includes establishing IT security policies and procedures for safeguarding Departmental IT resources. The Departmental IT Security Manager shall serve as the central point of contact for all matters relating to IT security for the Department and will be responsible for developing a process for disseminating information concerning the potential dangers from, and guidelines for control of, malicious software. Operating unit IT Security Officers (ITSO) are responsible for: 1. Developing appropriate procedures and issuing instructions for the prevention, detection, and removal or malicious software consistent with the guidelines contained herein; 2. Ensuring all personnel within the operating unit are made aware of this policy and incorporating it into IT security briefings and training programs; 3. Identifying and recommending software packages for the detection and removal of malicious software; 4. Developing a system for users to report computer viruses and other incidents and then notifying potentially affected parties of the possible threat; 5. Promptly notifying the Departmental IT Security Manager of all IT security incidents including malicious software; 6. Providing assistance in determining the source of malicious software and the extent of contamination; 7. Providing assistance for the removal of malicious software; and 8. Conducting periodic reviews to ensure that proper security procedures are followed, including those designed to protect against malicious software. Managers must ensure that employees and contractors follow operating unit procedures which comply with this policy. Employees, personnel from other organizations using DOC systems, contractor personnel, and vendors are responsible for following operating unit procedures for the protection of IT resources to which they have access. This includes reporting IT security incidents, involving viruses and other malicious software to their manager or supervisor and the ITSO for their organization. Requirements The requirements defined in this section, when implemented, will minimize the risk from introduction of viruses and other malicious software to DOC IT systems and networks. Not all requirements listed will apply to every IT system or network. Each organization must consciously evaluate the appropriateness of each of the following policies and implement those that apply to the category for their particular system. 1. Procedures. Each operating unit will establish appropriate procedures for adherence to this policy based on the criticality, sensitivity, and risks to their IT systems. Until virus detection software becomes available for all types of IT systems, the best protection against malicious software attacks is to establish good IT security procedures to control access to and actions taken on the IT system. 2. Backing up software and data. Employees should back up new software immediately, retaining the original distribution diskettes in a safe and secure location. Write-protect original diskettes prior to making back-up copies. If a virus destroys the working copy, the original software is still available. Copying copyrighted software material without the vendor's consent is illegal. If a vendor has not provided pre-approval of backup copies, employees must have vendor approval to create additional copies. Use only newly-formatted diskettes for copying software for backup storage. Used disks may already contain malicious programs which would contaminate the backup copies. Data files should be backed up frequently and stored off-site or in a secured environment. Restore damaged software programs from the original diskettes, not from regular backups. A virus may have been introduced prior to backup. 3. Outgoing software. A serious impact on the credibility of the Department would result from being identified as the source of a virus. Therefore, all software and data leaving the Department must be checked for viruses or other malicious coding. Use only new media for making copies for distribution. Where possible, use a stand-alone computer system when preparing copies for distribution. PC systems to which access is somewhat open, (i.e., training rooms or user laboratories, etc.) should never be used as a source of software or files to be transmitted and/or copied for distribution, without first taking steps to ensure that the system is free from viruses or other malicious software. 4. Software. All PC machine-readable media will be scanned for malicious software before initial use. Follow all vendor instructions carefully and write-protect virus scanning software media prior to use. Scanning software can become contaminated in the same way as other software. Although software sealed in "shrink-wrapped" plastic is usually checked by vendors, it is still advisable to scan this software since there have been reported cases in the Department of software contamination. Write-protect software prior to scanning to prevent possible contamination from system and virus scan software being used. Several reputable software packages are available to detect and/or remove viruses from machine-readable media. There are also utilities that can search text files for virus signatures. Most packages are designed for PC systems and local area networks, but may not be adequate for all PC operating systems. There are very few available for larger systems. Requirements to scan for malicious software are to be implemented as soon as the tools become available for a particular combination of hardware and software. Establish controls for local area networks that prevent anyone except the system administrator or other authorized staff from loading software on file servers. Ensure that operating system files and other executable files are read-only. If possible, disable the network mail facility from transferring executable files. This will help prevent network worm programs from spreading through the network. Trojan horses and other similar malicious software programs are most often introduced by insiders and it is not unusual for larger systems to be the target. The best protection against attacks of this type are to establish good management procedures. Effective controls include separation of duties, limiting individual access and allowed actions to what is needed and no more, formal change control and configuration management procedures, separation and testing of development versus production software and control over installation of new software versions. Frequent backups of the system and data will allow recovery should an incident occur. 5. Authorized software. It is imperative that machine-readable software and data files be obtained from reliable sources. Viruses are often spread through free or shared programs, games, demonstration programs, and programs downloaded from bulletin boards. Employees must not use privately-owned software or take software from their office without management approval. Commercial software must be obtained through appropriate procurement channels. In-house developed software must be done in accordance with established policy within the operating unit and have prior management approval. Shareware and freeware software must be obtained only with prior management approval. Software obtained electronically from bulletin boards should be downloaded to newly formatted diskettes and not directly to the computer hard disk. All newly acquired software, regardless of source, is subject to the scanning requirements in sub-paragraph 4 above. 6. Employee demonstrations. When possible, employees demonstrating DOC products must be certain that the hardware and software they are using are free of viruses. Use hardware write-protection mechanisms (i.e., read-only diskettes with write tabs; write-protect rings for tapes; knock-out rings on cassettes, etc.) to avoid any virus from infecting the media. If possible, check the hardware for viruses before loading the demonstration software. Do not allow other software to be used until the demonstration is completed. 7. Passwords. For larger systems and networks, user identification and passwords are the primary protection mechanism against malicious software. If the would-be perpetrators cannot get into the system, they cannot put malicious software on the system. When possible, all IT systems that are shared resources, including local area networks and multi-user stand-alone systems shall implement a user identification and verification system, such as a USERID and password. Conformance to the requirements of Chapter 10, Section 10.16 of the "DOC IT Management Handbook," and Section 16 of the "DOC IT Security Manual" in establishment, structure, individual accountability, periodic changing and removal are required. Log files should be reviewed periodically to detect unusual activity. Terminals, workstations and networked PCs should never be left unattended when logged in. 8. Vendor demonstrations. Vendors will demonstrate their software on stand-alone hardware, where possible. An employee must scan the stand-alone hardware before it is used by the vendor to verify that the computer does not contain any viruses. This shows the Department acted in good faith to prevent infecting the vendor's software. An employee will scan the stand-alone hardware when the demonstration is completed to determine if the vendor software contains a virus and remove it from the system. The vendor should be notified immediately to prevent further infections. In the case of network software demonstrations, the system administrator must approve and coordinate the demonstrations. Written certification from the vendor that the demonstration software has been checked and is free from viruses, should be obtained prior to loading any vendor software. 9. Hardware. PC hard disk drives, network file servers and other media which will be used to handle departmental information will be formatted between the time they are received and put into use. There have been cases of formatted hard disk drives being received that contained viruses. This requirement also applies to replacement parts resulting from repair and maintenance of equipment. This requirement may be waived only if the vendor installing the software provides a written certification that the system and software have been checked and are virus free. Never start up (boot) your computer from a diskette unless it is the original write-protected system master or a trusted copy. Portable computer systems, such as laptops, that leave Department controlled areas must be scanned for viruses before and after connecting to systems or software owned by other organizations. Never use a local area network file server as a workstation. File servers should be located in areas where access is restricted during working hours and locked after hours. When available and cost effective, virus detection software capable of continuous monitoring and reporting malicious programs, should be installed on hard disks to prevent contamination. Periodic scans of hard disks, using virus detection software, should be performed for systems without this protection installed. Lock computers and terminals or disconnect keyboards and store in a secure location, when not in use, to prevent unauthorized access. Lock doors to areas containing computers and terminals. 10. Procurement requirement. All procurements for computer software and hardware will contain a requirement that the vendor have antiviral procedures in place to ensure that the media supplied is uncontaminated by malicious software. In the case of small, off-the-shelf procurements where it is not possible to write antiviral clauses, the software will be scanned with virus detection software prior to use. Procurements for PC system maintenance should also require antiviral procedures on the part of the contractor. Vendors depend on the reputation of their products to ensure future sales. Reputable vendors are concerned about correcting any flaws in their systems or products that would make them vulnerable to attack from viruses or other malicious software, and on occasion issue recommended changes to improve security of their products. System administrators and managers are to implement any vendor recommended changes, or security fixes as soon as possible, after official receipt. Malicious Software Indicators If your IT system seems to be acting different than usual, a malicious software incident may have occurred. Below are a few signs that may indicate that a system has been infected. 1. Any unexplained messages or graphics on the screen, 2. An increase in the time required to load or execute programs, 3. An increase in the time required for disk accesses or processing from disk, 4. Unusual error messages, 5. Programs or files mysteriously disappearing, 6. Less memory available than usual, 7. Executable files changing size for no apparent reason, 8. Accesses made to non-referenced devices, 9. Data consistently out of balance, 10. File date and time stamps changing for no apparent reason, 11. Obsolete user accounts in use, 12. The presence of unexplained hidden files and/or 13. Unusual network activity. If your system demonstrates any of the above, it could indicate that malicious software is present. Elimination, Recovery and Reporting If you suspect that your IT system or network has been attacked by a virus or other malicious software program, do not attempt to fix the problems, but immediately report it to your supervisor and the ITSO for your operating unit. They will determine the appropriate action to control the damage and report the incident to the DOC IT Security Manager. It is important that the particular virus or other malicious software program, source, and potential for proliferation be identified and controlled. The initial report to the DOC IT Security Manager should be made within 24 hours of the incident. This report may be verbal and should include the following information: Date and time of incident Location Equipment type, make and model Malicious software type Method of discovery Virus name (if known) DOC system number (if known) Source of malicious software (if known) Apparent effect Within ten working days of the incident, a written report will be prepared and sent to the DOC IT Security Manager of the incident by the operating unit ITSO. This report will include the following along with all of the above information: Impact on operation Severity, including hours devoted to recovery and any additional costs incurred Proliferation, number of machines or media infected Action taken - how malicious software was cleared, who was notified, including outside organizations, and what steps were taken to identify the source If the problem has not been resolved within ten working days, mark the written report "Interim" and prepare and forward a "Final" report when the incident is resolved. In cases where resolution is not possible within 30 days, a written status report describing the actions taken and planned to resolve the incident must be sent to the DOC IT Security Manager monthly. G. Definitions: Introduction of viruses and other malicious software programs has generated a whole set of new terms. The following list of definitions is provided to familiarize personnel with some of these terms. 1. Bacterium. A late bloomer in the infectious terminology jargon is a "bacterium." It is a program that replicates itself and becomes a parasite on the host system by preempting processor and memory capacity. 2. Computer virus. A program that "infects" computer systems in much the same way as a biological virus infects humans. The typical virus "reproduces" by making copies of itself and inserting them into other programs--either in systems software or in application programs. 3. Flying Dutchman. A feature of Trojan horse malicious programs that erases all traces of the programming codes from the computer's memory and eludes any detection. 4. Logic Bomb. A computer code that is preset to cause a later malfunction when a specified set of logical conditions occur. For example, a specific social security number in a payroll system is processed and the logic bomb is activated, causing an improper amount of money to be printed on the check. 5. Machine-readable media. Media that can convey data to a given sensing device, e.g., diskettes, disks, tapes, computer memory. 6. Malicious Software. Any of a family of computer programs developed with the sole purpose of doing harm. Malicious code is usually embedded in software programs that appear to provide useful functions but, when activated by a user, cause undesirable results. 7. Scan. To examine computer coding/programs sequentially, part by part. For viruses, scans are made for virus signatures or potentially unsafe practices. (e.g., changes to an executable file, direct writes to specific disk sectors, et al.). 8. Time Bomb. Computer code that is preset to cause a later malfunction after a specific date, time or a specific number of operations. The "Friday the 13th" computer virus is an example. This virus infects the system several days or even months before and lies dormant until the date reaches Friday the 13th. 9. Trap Door. A set of instruction codes embedded in a computer operating system that permits access while bypassing security controls. 10. Trojan Horse. A program that causes unexpected (and usually undesirable) effects when willingly installed or run by an unsuspecting user. A person can either create or gain access to the source code of a common, frequently used program and then add code so that the program performs a harmful function in addition to its normal function. These programs are generally deeply buried in the code of the target program, lie dormant for a preselected period, and are triggered in the same manner as a logic bomb. A Trojan horse can alter, destroy, or disclose data or delete files. 11. Virus detection software. Software written to scan machine- readable media on computer systems. There are a growing number of reputable software packages available that are designed to detect and/or remove viruses. In addition, many utility programs can search text files for virus signatures or potentially unsafe practices. 12. Virus signature. A unique set of characters which identify a particular virus. This may also be referred to as a virus marker. 13. Worm. A worm is a complete program that propagates itself from system to system, usually through a network or other communication facility. A worm is similar to a virus--it is able to infect other systems and programs. A worm differs from a virus in that a virus replicates itself, which a worm does not. A worm copies itself to a person's workstation over a network or through a host computer and then spreads to other workstations. It can easily take over a network as the "Internet" worm did. Unlike a Trojan horse, a worm enters a system uninvited. H. References: Viruses and other malicious software appear to be a growing problem with new strains of viruses appearing continuously. Users of IT systems should become as familiar with the subject as possible, in order to protect against this threat. The following documents published by the National Institute of Standards and Technology are good sources of additional information: John Wack and Lisa Carnahan, Computer Viruses and Related Threats: A Management Guide, NIST Special Publication 500-166, August 1989. Dennis Steinauer, Security of Personal Computer Systems: A Management Guide, NBS Special Publication 500-120, January 1985. An Abbreviated Bibliography for Computer Viruses and Related Security Issues, NIST, Revised April 18, 1990.