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. W