Chapter 10. Information Technology Security INTRODUCTION 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 establishes 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) 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 this chapter represent management's commitment to assuring confidentiality, integrity, availability and control of the Department's IT resources. Due to the complexity of the IT Security program requirements, the policy section of this chapter is divided into subsections that present policies by specific subjects, as appropriate. The "DOC IT Security Manual," Attachment 1 to this chapter, is being published as a separate document, which combines all policies, procedures, current detailed guidance and methodologies for accomplishing the Department's IT security program. It is intended to provide individuals assigned IT security responsibilities and individual 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. A. Purpose The DOC IT Security program 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. The purpose of this chapter is to define all 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 might 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 IT security program and are included in this document. E. Policy 10.1 Program Requirements All DOC organizations will 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 that support IT systems, 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. 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. 10.2 Information Technology System Identification and Planning 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 Section 10.18 of the "DOC IT Management Handbook" and Section 18 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 the "DOC Guidelines for Developing and Evaluating Security Plans for Sensitive and Classified Systems," contained in Section 2 of the "DOC IT Security Manual," 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. 10.3 Certification 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. 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 3 of the "DOC IT Security Manual," identifies the required actions in the certification process. 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 frequent than three years after the previous certification. Examples of major changes are contained in Sections 3 and 4 of the "DOC IT Security Manual." 10.4 Accreditation 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. 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 4 of the "DOC IT Security Manual," 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 Section 4 of the "DOC IT Security Manual." 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 are contained in Section 4 of the "DOC IT Security Manual." 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.). Procedures for conducting IT security verification reviews are contained in Section 5 of the "DOC IT Security Manual." 10.5 Verification Reviews 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 every three years. 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. At the operating unit level, responsibility for conducting IT security verification reviews may be delegated to subordinate organizations as long as those subordinate organizations do not come under the direct control of the system owner. Detailed guidelines for conducting IT security verification reviews are contained in Section 5 of the "DOC IT Security Manual." 10.6 Incidents and Violations All DOC organizations will establish and implement a process and procedures to minimize the risk associated with violations of IT security, to ensure timely detection and reporting of actual or suspected incidents or violations. An IT security incident is any event, suspected event, or vulnerability that could pose a threat to the integrity, availability, or confidentiality of DOC's systems, applications or data. Incidents may result in the possession of unauthorized knowledge, the wrongful disclosure of information, the unauthorized alteration or destruction of data or systems and violation of federal or state laws. If such violations are detected or suspected, they are to be reported immediately to the DOC IT Security Manager through the operating unit ITSO. Section 6 of the "DOC IT Security Manual contains specific information concerning the reporting requirements for IT security violations. 10.6.1 Malicious Software All DOC organizations will establish and implement a process and procedures to minimize the risk of introducing viruses and other malicious software, to ensure timely detection of viral infections, to provide procedures for eliminating viral infections from the Department's inventory of microcomputers (PCs), and to provide procedures to minimize the risk from malicious programs to larger systems, or systems where virus detection software is not yet available. If such violations are detected or suspected, they are to be reported immediately to the DOC IT Security Manager through the operating unit ITSO. Information concerning the malicious software protection procedures and reporting requirements are contained in Section 6.1 of the "DOC IT Security Manual." 10.7 Risk Management All DOC organizations will establish and implement a risk management process for all IT resources, to ensure that the balance of risks, vulnerabilities, threats and countermeasures achieves a residual level of risk that is acceptable based on the sensitivity or criticality of the individual systems. System owners shall conduct a periodic risk analysis of each IT system to insure that appropriate, cost effective safeguards are incorporated into existing and new systems. The objective of the risk analysis is to provide a measure of the relative vulnerabilities and threats to an installation so that security resources can be effectively distributed to minimize the potential for future losses. The risk analysis may vary from an informal, but documented, review of a microcomputer or terminal installation to a formal, fully quantified risk analysis for a large mainframe computer system. A risk analysis will be performed: 1. Prior to the approval of design specifications for new systems; 2. Whenever a significant change occurs to the system (examples of major changes are contained in Sections 3 and 4 of the "DOC IT Security Manual";) or 3. At least every three years. Section 7 of the "DOC IT Security Manual" contains specific information and guidance concerning the risk management and risk analysis requirements. 10.8 Contingency and Disaster Recovery Planning Management officials who are dependent upon IT systems for the support of essential functions are responsible for the development and maintenance of contingency plans for these functions. The contingency planning process will address the following activities: 1. Backup and retention of data and software; 2. Selection of a backup or alternate operations strategy; 3. Emergency response actions to be taken to protect life and property and minimize the impact of the emergency; 4. Actions to be accomplished to initiate and effect backup or alternate site; and 5. Resumption of normal operations in the most efficient and cost-effective manner. Each DOC IT system shall develop and maintain in a current state, a contingency plan for disaster recovery which will provide reasonable assurance that critical data processing support can be continued, or resumed quickly, if normal operations of the system are interrupted. These plans will include adequate coverage of: 1. Emergency response procedures appropriate to fire, flood, civil disorder, natural disaster, bomb threat or any other incident or activity which may endanger lives, property or the capability to perform essential functions. These emergency procedures will be prominently displayed in the areas to which they apply; 2. Arrangements, procedures and responsibilities will be defined and documented to ensure that essential (critical) operations can be continued if normal processing or data communications are interrupted for any reason for an unacceptable period of time; 3. Recovery procedures and responsibilities to facilitate the rapid restoration of normal operations at the primary site, or if necessary, at a new facility, following the destruction, major damage or other interruptions at the primary site; and 4. The minimally acceptable level of degraded operation of the essential (critical) systems or functions will be identified and prioritized to guide implementation at the backup operational site. The contingency plan must accommodate these priorities. The plan for large systems supporting essential Departmental or agency functions shall be fully documented. Small systems, such as those located in office environments, may develop a more abbreviated and less formal plan. All plans must be operationally tested at a frequency commensurate with the risk and magnitude of loss or harm that could result from disruption of information processing support, but not to exceed one year. Section 8 of the "DOC IT Security Manual" contains specific information and guidance concerning contingency and disaster recovery planning. 10.9 Personnel Security All DOC operating units shall comply with personnel security policies and procedures established by the "DOC Personnel Security Manual," DAO 207-2 and Section 9 of the "DOC IT Security Manual." These policies pertain to both federal and contractor personnel. At a minimum: 1. All IT related positions will be evaluated and assigned a sensitivity level and appropriate background investigations will be completed for individuals filling these positions; 2. Procedures will be established to ensure the screening of all individuals before they are allowed to participate in the design, operation or maintenance of sensitive IT systems, or are granted access to sensitive data. The level of screening required should vary from minimal checks to full background investigations, depending upon the sensitivity of the information to be handled and/or the risk and magnitude of loss or harm that could be caused by the individual; 3. Establish a process to grant access privileges based on a legitimate need to have system access. Individuals will be granted only the least possible privileges necessary for job performance. Privileges which have not been specifically granted will be specifically denied; 4. Where feasible, sensitive positions will be separated to preclude any one individual from gaining the opportunity to adversely affect the system. Procedural checks and balances must be defined and enforced so that accountability is established and security violations are detectable. 5. Establish a process for individual accountability for the proper use and security of the IT system(s) being accessed and ensure that all users are provided with periodic security awareness briefings, copies of system rules and are trained to fulfil their IT security responsibilities; 6. Establish a process to revoke access privileges in a timely manner when the requirement for access ceases (e.g., transfer, resignation, retirement, change of job description, etc.); and 7. Establish a process to immediately revoke access privileges to individuals being separated for adverse reasons on or just prior to notifying them of the pending action. 10.10 Hardware Security DOC operating units shall assure that appropriate technical security requirements are included in specifications for the acquisition or operation of new IT equipment intended to process sensitive information. These specifications shall be reviewed and approved by the appropriate ITSO or IT System Security Officer (ITSSO) prior to the acquisition. It may not be feasible or cost effective to retrofit existing, older computer hardware. However, the features below should be considered when acquiring new systems, to ensure that they are incorporated either within the hardware or operating system software: 1. User Isolation a. Users will be allowed to access only the memory locations, files, and peripheral devices which have been allocated to the user by the operating system. b. Computers, other than stand-alone PCs, should have the capability to effectively isolate users from each other and from the operating system. c. Physical isolation of the hardware is described in Section 10.11 of this document and Section 11 of the "DOC IT Security Manual." 2. System Execution a. Any attempt to execute an illegal instruction should result in a hardware interrupt permitting the operating system to interrupt and abort the program containing the instruction. b. Error detection and memory boundary checking should be performed on transfers of data between memory, peripherals, and external devices. c. Automatic programmed interrupts must control system malfunctions and operator errors. For systems that process very sensitive or national security information the use of equipment that meets the requirements of either the "Department of Defense (DOD) Trusted Computer System Evaluation Criteria," DOD 5200.28-STD ("Orange Book") or the "Federal Criteria for IT Security," developed jointly by the National Institute of Standards and Technology and the National Security Agency is encouraged. Government owned equipment is for official use only and is not to be used for personal business or other non-government activities. Individual employees should be discouraged from bringing their personally owned hardware into DOC space for processing government data. If it is in the best interest of the DOC organization to allow the use of personally owned hardware on DOC premises, authorization must be granted in writing by the immediate supervisor, showing the justification. The written authorization must show that the DOC is not responsible for any damage or loss of personally owned equipment and will not pay for maintenance or repair. See Section 10.12.1 of this document and Section 12.1 of the "DOC IT Security Manual" for additional policies and guidance on copyrighted software. 10.11 IT Facility Access to IT resources will be based upon demonstrated need and level of security clearance, if appropriate. Individuals shall be granted only the access authority and/or system privileges necessary to accomplish their assigned duties. 10.11.1 Physical Security Adequate physical security measures must be provided for the protection of human resources, physical and logical assets and sensitive applications and data. Physical security measures must be selected and implemented in consideration of the sensitivity of the IT resources and their criticality to the supported functions. The physical security policies stated herein are intended to be complementary to the "DOC Physical Security Manual," DAO 207-1 and apply to the protection of IT resources. For the purposes of these policies, controlled areas are those which encompass or allow access to potentially sensitive information resources, resources which are essential for the processing of sensitive data, or resources essential to accomplishment of organizational missions. These areas include, but are not limited to: any spaces housing computer equipment, including terminals, PCs and file servers; data storage libraries; input/output areas; data conversion areas; programmer areas and files; documentation libraries; communication equipment areas; computer maintenance areas; mechanical equipment areas; telephone closets; environmental controls and power systems; and supply storage areas. The physical security requirements of controlled areas will be determined by the results of a risk analysis and/or a DOC Office of Security physical security survey. When automation or data communications equipment are located within user areas, the user management officials will assess the sensitivity of the data, automated resources and functions performed and, if warranted, designate the area as a controlled area. The operational areas of major computer installations, including local area network file servers, will be designated restricted areas in which access will not be permitted unless specifically authorized or required for job performance. Controlled and restricted areas will be protected by physical security and other means which are deemed appropriate for the sensitivity or criticality of the system as determined by the results of a risk analysis and as defined in the Sensitive System Security Plan for the system. At a minimum, access to controlled areas will be limited to those individuals having an official need to be in the area. IT devices which are easily moved, have non-removable hard drives and are used for sensitive information will not be allowed outside of the controlled area. If the sensitive data remaining on the media has been completely erased or obliterated, the removal of these devices from the work area may be approved by the ITSO or ITSSO. Contract maintenance personnel, and others not authorized unrestricted access but who are required to be in the controlled area, will be escorted by an authorized person at all times that they are within the controlled area. Media used to record and store sensitive software or data will be externally identified, protected, controlled and secured when not in actual use. 10.11.2 Environmental Safeguards Adequate environmental safeguards must be installed and implemented to protect IT system resources as deemed appropriate for the sensitivity or criticality of the system as determined by the results of a risk analysis and as defined in the Sensitive System Security Plan for the system. At a minimum, the following environmental safeguards must be considered: 1. Fire prevention, detection, suppression and protection 2. Water hazard prevention, detection and correction 3. Electric power supply protection 4. Temperature control 5. Humidity control 6. Natural disaster protection from earthquake, lightning, windstorm, etc. 7. Magnetism protection 8. Good housekeeping procedures for protection against dust and dirt 10.12 Software Security Prior to placing a sensitive application into operation, DOC operating units will verify that the required user functions are being performed completely and correctly, and that the specified administrative, technical and physical safeguards are operationally adequate and fully satisfy the applicable federal policies, regulations and standards relating to the protection of the information. Application Software - An application which processes sensitive data, or requires protection because of the risk and magnitude of loss or harm that could result from improper operation, manipulation or disclosure must be provided protection appropriate to its sensitivity. The following will be considered as the minimum controls to be applied to sensitive applications, with additional controls or safeguards to be imposed if appropriate: 1. Security requirements will be defined, and security specifications approved by the user prior to acquiring or starting development of applications, or prior to making a substantial change in existing applications; 2. Design reviews will be conducted at periodic intervals during the developmental process to assure that the proposed design will satisfy the functional and security requirements specified by the user; 3. New or substantially modified sensitive applications 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 operationally adequate. This is normally accomplished as part of the certification process described in Section 10.3 of this document and Section 3 of the "DOC IT Security Manual"; 4. Live sensitive data or files will not be used to test applications software until software integrity has been reasonably assured by testing with non-sensitive data or files; 5. Sensitive application software will not be placed in a production status until the system tests have been successfully completed and the application has been properly certified and accredited. Accreditation requirements are described in Section 10.4 of this document and Section 4 of the "DOC IT Security Manual"; 6. Current copies of critical application software, documentation, data bases and other resources required for its operation, will be maintained at a secure off- site location to be readily available for use following an emergency; 7. Sensitive applications will be re-tested and recertified every three years or following major changes; and 8. Sensitive software documentation should be provided the same degree of protection as that provided for the software. Operating System Software - The operating system software employed to process data by multiple users, including local area networks, should control user access to resources and capabilities which are required and have been authorized. It should also have the capability to identify, journal, report and assign accountability for the functions performed or attempted by a user, and to deny user access to capabilities or resources which have not been authorized. Since the operating system has the capability to perform certain functions which are forbidden to users, it should allow the user to have access to the authorized resources only, and nothing more. As a minimum, the operating system: 1. Should control all transfers between memory and on-line storage devices, between a central computer and remote devices and between on-line storage devices; 2. Should control all operations associated with allocating IT system resources (e.g. memory, peripheral devices, etc.), memory protection, system interrupts and changes between the privileged and non-privileged states; 3. Should control programs or utilities which may be used to maintain and/or modify the operating system, access control systems, sensitive databases and other software modules which could effect or compromise the integrity of the general purpose software or sensitive applications; 4. Should prevent a user program from executing privileged instructions; 5. Should isolate the programs and data areas of one user from those of other users and the operating system software; 6. Should assure error detection, when accessing memory, memory bounds, parity, and hardware register checking; 7. Should cause the following screen warning message to be displayed before the log on message, if the system is capable of being accessed by communication connection: **WARNING**WARNING**WARNING**WARNING**WARNING** YOU HAVE ACCESSED A UNITED STATES GOVERNMENT COMPUTER. USE OF THIS COMPUTER WITHOUT AUTHORIZATION OR FOR PURPOSES FOR WHICH AUTHORIZATION HAS NOT BEEN EXTENDED IS A VIOLATION OF FEDERAL LAW AND CAN BE PUNISHED WITH FINES OR IMPRISONMENT (PUBLIC LAW 99-474). REPORT SUSPECTED VIOLATIONS TO THE SYSTEM SECURITY OFFICER. **WARNING**WARNING**WARNING**WARNING**WARNING** If equipment or software, capable of monitoring keystrokes, is used on the system for any reason, the warning screen must be modified to read as follows: **WARNING**WARNING**WARNING**WARNING**WARNING** THIS SYSTEM IS FOR THE USE OF AUTHORIZED USERS ONLY. INDIVIDUALS USING THIS COMPUTER SYSTEM WITHOUT AUTHORITY, OR IN EXCESS OF THEIR AUTHORITY, ARE SUBJECT TO HAVING ALL OF THEIR ACTIVITIES ON THIS SYSTEM MONITORED AND RECORDED BY SYSTEM PERSONNEL. IN THE COURSE OF MONITORING INDIVIDUALS IMPROPERLY USING THIS SYSTEM, OR IN THE COURSE OF SYSTEM MAINTENANCE, THE ACTIVITIES OF AUTHORIZED USERS MAY ALSO BE MONITORED. ANYONE USING THIS SYSTEM EXPRESSLY CONSENTS TO SUCH MONITORING AND IS ADVISED THAT IF SUCH MONITORING REVEALS POSSIBLE EVIDENCE OF CRIMINAL ACTIVITY, SYSTEM PERSONNEL MAY PROVIDE THE EVIDENCE OF SUCH MONITORING TO LAW ENFORCEMENT OFFICIALS. REPORT SUSPECTED VIOLATIONS TO THE SYSTEM SECURITY OFFICER. **WARNING**WARNING**WARNING**WARNING**WARNING** The user should then be prompted for a specific response to continue or exit the system; 8. Should be maintained by the minimum number of authorized persons; and 9. Should be copied after each modification with the copy to be immediately stored at a secure off-site location for emergency use. Other General Purpose Software - Other general purpose or utility software may be executed by both users and the operating system. Many of these perform routine, but important functions for the users. Others have the capability to by-pass controls, access databases without approval, duplicate files, change or reveal passwords and similar actions which, if used improperly, can compromise the protection of system resources. These latter programs and utilities should be safeguarded by: 1. Password protecting those which are only required by, or should be reserved for, the exclusive use of system programmers; 2. Password protecting and restricting access to utilities required to maintain security files; 3. Limiting the utility instructions to operators and others not having need for these capabilities; 4. Limiting user privileges for utility and general purpose programs to "execute only" (except for systems programmers who need additional privileges); 5. Maintaining a current copy of utilities, general purpose programs and documentation at a properly secured off-site location for emergency use; and 6. Protecting proprietary software in accordance with the terms and conditions of the contract or license. 10.12.1 Copyrighted Software Title 17, United States Code, Section 106 gives copyright owners exclusive rights to reproduce and distribute their material, and Section 504 states that copyright infringers can be held liable for damages to the copyright owner. Title 18, United States Code provides felony penalties for software copyright infringement. It is the responsibility of each DOC employee and supervisor to protect the government's interests as they perform their duties. This includes responsibility for assuring that commercial software, acquired by the government, is used only in accordance with licensing agreements. Likewise, it is also their responsibility to assure that any proprietary software is properly licensed before being installed on DOC equipment. This policy does not apply to software developed by or for a federal agency and no restrictions apply to its use or distribution within the federal government. Supervisors will ensure that the following requirements are made known to all employees and will be held accountable for conducting periodic audits to ensure that these policies are being followed: 1. Install only commercial software, including shareware, that has been purchased through the government procurement process on DOC systems; 2. Follow all provisions of the license agreements issued with the software and register organizational ownership; 3. Do not make any illegal copies of copyrighted software. Normally the license will allow a single copy to be made for archival purposes. If the license is for multiple users, do not exceed the authorized number of copies; 4. At least annually, an inventory of all software on each individual PC will be audited against the organization's license agreement records to ensure that no illegal copies of commercial software are installed on any equipment. 5. Maintain written records of software installed on each machine and ensure that a license or other proof of ownership is on file for each piece of software; 6. Store licenses, software manuals and procurement documentation in a secure location (i.e., closed file cabinet, etc.); 7. When upgrades to software are purchased, the old version should be disposed of in accordance with the licensing agreement to avoid a potential violation. Upgraded software is considered a continuation of the original license, not an additional license; 8. Some government owned software licenses do allow employees to take copies home for use on their personally owned computers under specific circumstances (e.g., for government work but not personal business). Unless the license specifically states that employees may take copies of software home for installation on home computers, doing so is a violation of the copyright law and the individual will be liable. 9. All illegal copies of software will be deleted immediately. All organizations must acquire special purpose software to inventory and document all software on all PCs belonging to the organization. This special purpose software may be a commercial product or the organization may acquire free software produced by the Software Publishers Association for this purpose from their operating unit ITSO. Individual employees should be discouraged from installing their personally owned software on government equipment. If it is in the best interest of the DOC organization to allow personally owned software, authorization must be granted in writing by the immediate supervisor, showing the justification. Prior to authorization, the employee must provide the software license and give assurance that copyright infringement will not occur from installation on government equipment. Employees not following these procedures shall be held personally liable for any violations of the copyright laws and subject to the penalties contained in Title 17 and Title 18 of the United States Code. 10.13 Production Input/Output Controls Policies and procedures will be established to protect sensitive information from either accidental, unauthorized or intentional modification, destruction or disclosure during input, processing or output operations. The handling of sensitive input data will be limited to properly screened persons, and will be controlled by formal procedures which will provide an audit trail of the data as it passes from person to person or point to point in the process. The audit trail must assure personal accountability from initial receipt to distribution or destruction of the final products. Procedures must be established to ensure that only authorized users pick up or deliver sensitive input and output data and media. Procedures for sensitive information should include such controls as signed receipts, registered mail and locked or monitored user "boxes". Printouts, containers, tape reels, disk packs, floppy disks and similar data storage media should be clearly identified as to contents and sensitivity. The purpose of this is to prevent accidental release for reuse, inadvertent disclosure of sensitive information and to notify the users of the need for continuous protection. Classified information should be labeled and protected as specified in the "DOC National Security Information Manual." Subject to the capabilities of the system, inadvertent destruction (e.g., overwriting) should be prevented by the use of "write protect" rings, internal labels, floppy disk tabs or similar safeguards. Operator instructions for each application should clearly specify the actions to be taken in the event of inadvertent damage or destruction, as well as incidents which cause physical damages to the media. All sensitive and/or critical data stored on media such as magnetic tape, disk, and similar devices, should be stored and controlled in the media library when not required for processing. Only authorized and properly screened individuals will be allowed entry to the library. Controls should be in place to assure that these individuals can be held accountable for data resources under their control. In addition to the library, sensitive data may only be stored in an authorized, secure off-site location or temporarily in the computer area during processing. Procedural instructions, inventories and audit trails will be implemented to assure that these controls are in place and are effective. If a media library is not justified, as in the case of a PC, the sensitive diskettes and tapes should be stored in a locked safe or cabinet with all other controls in place. Section 10.19 of this document and Section 19 of the "DOC IT Security Manual" describe the approved methods of clearing and/or declassifying storage media which has been used for classified national security information. Sensitive, but unclassified data will be handled as follows: 1. Using "delete" or "erase" features usually do not remove the data from the media, and does not assure that the data cannot be retrieved by more sophisticated devices. This process can be used when the media is to remain under control of the original data owner, and will be subsequently used to store or process information of the same or lower sensitivity. It is important to note that "delete" routines that only remove pointers and leave the data intact are not acceptable methods for clearing sensitive data if the media is to be released outside of the original data owner's control. 2. If the media containing sensitive information is to be released outside the original owner's control or is to be used for non-sensitive data and will not be in a controlled environment, it should be cleared by overwriting each memory location, register and other circuity used for storing sensitive information before it is reused. Afterwards, verify that all appropriate memory locations have been cleared. Section 13 of the "DOC IT Security Manual" contains specific guidance for clearing and overwriting sensitive data. 10.14 Acquisition and External Processing Requirements The federal IT security policies are applicable for IT systems regardless of whether the services are performed within DOC, by another Government agency, or by a non- Government agency. However, in the latter two situations, the agency would not be under the operational management control of DOC and must be treated somewhat differently. Procurement or other documents used to acquire or operate IT installations, equipment, software, and related resources or services shall contain specifications to assure that appropriate technical, administrative, personnel and physical security requirements are included. The specified security requirements will be reviewed and approved by the appropriate ITSSO who must certify that the specified security requirements are reasonably sufficient for the intended use, and that they satisfy current federal, DOC laws, regulations and policies. Processing by Another Government Agency - All Government agencies are required to adhere to the IT security policies contained in the "Computer Security Act," P.L. 100-235 and OMB Circular A-130, unless more stringent policies or regulations apply. Other federal agencies may implement these requirements somewhat differently than Commerce, but they must adhere to the policy that sensitive applications will only be processed on IT systems having appropriate security protection, after the systems have been certified and accredited by senior officials of the organization. When DOC processing is done by another agency, the sensitivity of the data and application will be determined by a DOC official. The certification of the application is the responsibility of the agency owning the application. If the application is not a DOC application, the owning agency must provide a copy of the certification to the Department. In such a case, compliance with the federal IT security policies will be accomplished as follows: 1. The DOC data or application owner is responsible for determining the sensitivity of the data and/or application and making this known to the servicing agency. 2. The servicing agency personnel who will have access to the sensitive DOC resources must be screened in accordance with the Federal Personnel Manual and the servicing agency equivalent to the "DOC Personnel Security Manual." Servicing agreements will specify that personnel will be screened and appropriate clearances granted before allowing access to DOC sensitive resources. 3. The DOC senior official empowered to certify the sensitive application, if it belonges to DOC, will request the servicing agency to provide the certification and backup documentation. Based on the information provided, the official may choose to certify, not certify, or certify for operation under certain specified conditions. 4. The servicing agreement must state clearly that the application or system has been certified and that the servicing organization has achieved, and will maintain, a level of security commensurate with the sensitivity of the data being processed for the DOC. 5. The agreement must state that the application or system must be recertified every three years or earlier if substantial modifications have been made to the application or system. A copy of the recertification will be provided to the DOC data or application owner. 6. The agreement must specify that the servicing organization will develop and maintain a Disaster Recovery Plan which includes sensitive DOC applications and data. Processing by a Non-Government Agency - When a contractor or other non-Government organization is processing DOC work, the contract must specify adherence to DOC IT security policies and the National Industrial Security Program as outlined in Executive Order 12829 for classified processing. In addition: 1. Before entering into an agreement to process sensitive data or applications at a contractor facility, a risk analysis must be performed, and approved by DOC personnel. A new risk analysis must be performed whenever significant changes to the system occur or every three years, whichever occurs first. 2. DOC sensitive applications must be certified and recertified, as specified in Section 3 above, for operation at the contractor facility. Section 3 of the "DOC IT Security Manual" identifies the required actions in the certification process. 3. The servicing contract should specify that DOC reserves the right to perform unannounced on-site inspections to insure that an adequate level of security is being maintained. 4. Monitoring contractor compliance will be the responsibility of the DOC Contracting Officer's Technical Representative (COTR), in coordination with the appropriate procurement and IT security officers, and the DOC owner of the data or application. Section 14 of the "DOC IT Security Manual" contains specific information and guidance concerning IT acquisition security requirements and external IT processing services. Section 10.15 Telecommunications Security (Policy is being developed) Section 10.16 Technical Controls (Policy is being developed) 10.17 Security Awareness and Training Operating units shall establish IT security awareness and training programs to assure that federal and contractor personnel involved in the management, operation, programming, maintenance or use of IT are aware of their security responsibilities and know how to fulfill them. All new employees will receive an IT security awareness briefing as part of their orientation within 60 days of their appointment and all employees will be provided with refresher awareness material or briefings at least annually. IT security training above the awareness level shall be provided to personnel who design, implement or maintain systems regarding the types of security and internal control techniques that should be incorporated into system development, operations and maintenance. Individuals assigned responsibilities for IT security shall be provided with in-depth training regarding security techniques, methodologies for evaluating threats and vulnerabilities that affect specific IT systems and applications and selection and implementation of controls and safeguards. 10.18 Procedural Security To reduce the potential for compromise, loss or the unauthorized modification of critical or sensitive IT resources or data, procedures should be established to formalize the work flow process and provide the procedural protection determined by the data owner to be appropriate. Such procedures are particularly important for office environments, since a relatively new and powerful processing capability has been placed into the hands of persons who frequently have had little experience or training in IT security matters. Standard procedures define the authorized actions to be performed in different circumstances and are invaluable for training new employees, to avoid unintentional problems or to recover from these problems if they should occur. They also allow the manager to detect procedural deviations which could signal the need for corrective actions ranging from additional training to disciplinary action. Formal procedures should be developed with these objectives in mind. Section 10.19 Classified National Security Systems (Policy is being developed) 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 by 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 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 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 Section 10.2 of this document 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 Section 10.7 of this document 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 Section 10.8 of this document 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 Section 10.3 of this document 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 Section 10.4 of this document 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 Section 10.5 of this document 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 Section 10.17 of this document 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 Section 10.5 of this document and Section 5 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 Section 10.6.1 of this document 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 Section 10.12.1 of this document and Section 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 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.2 of this document 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. Some general support system owners are suppliers of data processing services 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 the 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.3 of this document 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 Section 10.12.1 of this document and Section 12.1 of the "DOC IT Security Manual." (f) Ensure that each automated data processing position (including contract positions) are properly designated in accordance with position sensitivity criteria and receive appropriate investigative processing. Refer to 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 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.2 of this document 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.7 of this document 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.8 of this document 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 or cause to be investigated known or suspected security incidents or violations and prepare reports of findings as required in Chapter 10.6 of this document 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.6.1 of this document 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 Section 10.12.1 of this document 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. 16. Coordinate with the operating unit Security Office or local Security Office on security matters of mutual interest. 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 and for abiding by all DOC IT security policies. G. Relationship with 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.