Download  

Effective Date: 4/15/02

Series: Information Resources Management

Part 375: IRM Program Management

Chapter 19: Information Technology Security Program

Originating Office: Office of the Chief Information Officer

19.1 Purpose. This chapter establishes policies, assigns organizational and management roles and responsibilities, and establishes minimum requirements for the development, implementation, maintenance, and oversight of an information technology (IT) security program for protecting Department of the Interior (DOI) information and IT systems that store, process, or transmit unclassified information.

19.2 Definitions. Definitions and key terms applicable to the Departmental IT Security program are attached as Appendix 1. A list of acronyms and their definitions is attached as Appendix 2. The generic term Asystem@ is used in this document to mean either a major application (MA) and/or a general support system (GSS).

19.3 Scope.

A. Compliance with the provisions of this policy is mandatory for all DOI bureaus and offices, IT systems, and facilities. This policy also applies to any outside organizations, or their representatives (including contractors), who are granted access to Departmental IT resources, such as other Federal, state, and local agencies.

B. This policy also applies to other technical systems, such as supervisory process control systems (except those identified in the Department of Defense Authorization Act of 1982). Systems that process, store, transmit, or receive National Security Information (NSI) are governed by separate directives and guidance. For security issues concerning these IT systems, contact the Departmental IT Security Manager and/or the Department=s Chief Information Officer (CIO).

C. This policy applies to all IT systems processing Sensitive-But-Unclassified (SBU) [all unclassified DOI systems are considered SBU] data currently in existence and to any new IT systems that process SBU data acquired after the effective date of this policy. Personnel involved in any phase of the life cycle (i.e., initiation, development and acquisition, implementation, operation/maintenance, and disposal) of an IT system are required to comply with requirements in this policy. The IT security program is not intended to be an additional level of control, but rather a management tool to safeguard IT processes and information integrity. This policy assigns responsibilities and accountability for providing reasonable assurance that IT system resources are protected against fraud, waste, abuse, disaster, mismanagement, or compromise.

19.4 Authority. This policy=s basis of authority includes public laws, Executive branch directives, federal standards, and other DOI policies that provide direction and guidance concerning security planning. It establishes the DOI IT security program in compliance with the Privacy Act of 1974; the Freedom of Information Act, as amended; the Paperwork Reduction Act; the Computer Fraud and Abuse Act of 1986; the Computer Security Act of 1987 (Public Law (P.L.) 100-235); the Information Technology Management Reform Act (ITMRA) of 1996; the Government Information Security Reform Act (GISRA) of 2000; OMB Circular No. A-130, Appendix III, Security of Federal Information Resources; National Institute of Standards and Technology (NIST) Special Publications addressing IT security; Federal Information Processing Standards Publications (FIPS PUBS); National Archives and Records Administration's regulations on records management; the Office of Personnel Management's (OPM) guidance on personnel security as they relate to IT resources; and DOI IT security policy guidance. References to various laws, regulations, directives, and other policy and procedure guidance applicable to IT security in DOI are located in Appendix 3.

19.5 Directives and Guidance. DOI has implemented and documented its IT security program utilizing a three-tier model.

A. Tier 1 - The Departmental Manual 375 DM 19 (this document), contains high-level policies; security standards, requirements, and procedures; and the roles and responsibilities of Departmental employees and other personnel having access to DOI IT systems.

B. Tier 2 - The DOI IT Security Plan (ITSP) and the DOI IT Security Reference Handbook form the Tier 2. The ITSP contains the implementation plan for the IT security program. The DOI IT Security Reference Handbook details procedures and processes to implement the IT security policy, and includes best practices based upon Federal IT security requirements and NIST guidance.

C. Tier 3 - Technical security guidelines constitute the Tier 3. Technical security guidelines are developed and published on an as needed basis. They contain Department-wide technical standards for the implementation and execution of various portions of the IT security program and are distributed through CIO Technical Bulletins. CIO Technical Bulletins (formerly IRM Bulletins) are used to issue short-term, interim, and/or emergency policy, guidance, and/or instructions on IT security issues of immediate concern.

19.6 Policy. DOI will protect its information and IT systems from threats to confidentiality, integrity, availability, accountability, and authenticity. DOI will implement and maintain an IT security program that ensures adequate protection for all information and IT systems that collect, process, transmit, store, and/or disseminate information. The IT security 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. Violations of Federal and Departmental security regulations will result in appropriate administrative, disciplinary, or legal action.

19.7 Objectives. DOI will safeguard its IT systems through the implementation of the DOI IT Security Program, which will accomplish the following:

A. Establish a level of IT security for all unclassified IT systems and information commensurate with the sensitivity of the information and with the risk and magnitude of loss or harm resulting from improper operation or losses resulting from fraud, waste, abuse, disasters, or mismanagement.

B. Maintain a central listing of systems that process, store, transmit, or contain SBU information.

C. Define, manage, and support the security planning process for all DOI systems.

D. Ensure that only authorized personnel have access to information.

E. Establish a program to formally certify and authorize processing of SBU data on all systems within DOI.

F. Define and manage the contingency planning process, including training and testing, to provide IT systems with adequate continuity of operations upon disruption of normal operations.

G. Understanding, by all levels of DOI, the critical role of IT security to achieve DOI=s missions and be appropriately and periodically trained through an IT security awareness and training program.

H. Define and manage the computer security incident response capability program for all DOI employees.

I. Use the procedures outlined in Federal Information Processing Standards (FIPS) and other Federal government guidance except where the costs of using such standards exceed the benefits or where use of the standards will impede DOI in accomplishing its mission.

J. Ensure that IT security efforts will have adequate resources to meet statutory requirements for the protection of IT systems and hosted data.

K. Understanding that IT security requires collaboration and Aknowledge sharing@ by all levels of DOI to understand the threats, vulnerabilities and countermeasures.

19.8 Responsibilities. The specific responsibilities for IT security assigned to DOI organizations and employees are as follows:

A. The Secretary of the Interior is responsible for regulatory guidance promulgated by the Government Information Security Reform Act (GISRA), which includes but is not limited to:

(1) Ensuring the integrity, confidentiality, accountability, availability, and non-repudiation (authenticity) of information and information systems supporting DOI operations and assets; and

(2) Ensuring that information security policies, procedures, and control techniques are developed and implemented sufficient to afford security protections commensurate with the risk and magnitude of the harm resulting from unauthorized disclosure, disruption, modification, or destruction of information collected or maintained by or for DOI.

The Secretary may delegate responsibilities to the Chief Information Officer and other senior agency officials as warranted.

B. The Chief Information Officer (CIO) is the Designated Accreditation Authority (DAA) for all DOI systems and is responsible for reviewing, and issuing management approval to operate these systems. The CIO may delegate this responsibility to the bureaus and offices. The CIO is responsible for overall management of IT resources and IT security programs of DOI. This includes developing and maintaining a Department-wide IT security program as outlined in Section 3534, paragraph (b) of the GISRA, that includes:

(1) Ensuring that DOI effectively implements and maintains information security policies, procedures, and control techniques;

(2) Ensuring, in coordination with senior DOI officials, the implementation of the requirements of a DOI-wide IT security program specified in Section 3534, paragraph (3) of the GISRA;

(3) Ensuring that DOI annually performs an independent evaluation of the IT Security Program and its practices, as specified in Section 3535 of the GISRA;

(4) Ensuring that DOI includes, as part of the annual performance plan, a description of the time periods and resources, including budget, staffing, and training, necessary to implement the DOI-wide information security program as described in Section 3534, paragraph (b)(1) of the GISRA;

(5) Training and oversight of DOI officials with significant responsibilities for information security;

(6) Ensuring DOI has sufficiently trained personnel to assist the agency in complying with the requirements of the GISRA, as well as related policies, procedures, standards, and guidelines;

(7) Ensuring sufficient resources are available to implement the DOI IT security program and that the bureaus have adequate resources for the implementation of their IT security programs;

(8) Ensuring that DOI IT security planning and execution is practiced throughout the life cycle of each DOI system; and

(9) Ensuring that appropriate senior agency officials are responsible for:

(a) Assessing the information security risks associated with the operations and assets for programs and systems over which they have control;

(b) Determining the levels of information security appropriate to protect such operations and assets;

(c) Periodically testing and evaluating information security controls and techniques;

(d) Developing job descriptions and employee performance standards, containing appropriate references to their IT security responsibilities; and

(e) Ensuring that appropriate language is included in DOI contracts that require contractor compliance with DOI IT security requirements.

The CIO may delegate responsibilities to a bureau CIO and other senior agency officials as warranted.

C. The Office of the Chief Information Officer (OCIO) is responsible for development, coordination, and interpretation of IT security policy. OCIO also oversees bureau compliance with Federal and Departmental policies, guidelines, and regulations governing IT security.

D. The DITSM and IT Security Program Office (ITSPO) are responsible for assisting the CIO with managing the Department=s IT security program. The DITSM reports directly to the CIO and is the Chief of the ITSPO. Specific functions of the DITSM/ ITSPO include:

(1) Serves as principal IT security consultant to DOI senior management and the principal IT security architecture consultant to the CIO;

(2) Serves as head of the DOI IT Security Team and coordinates activities for the DOI IT security program throughout DOI;

(3) Manages the DOI IT Security Program consistent with public laws, Federal regulations, Executive orders, and DOI policies;

(4) Develops, coordinates, interprets, and maintains IT security policies and implementation guidance for the protection of information and information systems supporting DOI assets;

(5) Develops, coordinates, interprets, and maintains the DOI ITSP, that specifies the minimum risk mitigation requirements of DOI IT systems;

(6) Prepares and submits reports to DOI management, OIG, OMB, GAO, NIST, and other oversight organizations in compliance with Federal and Departmental security policies;

(7) Establishes criteria for security certification and accreditation of systems to meet the requirements of Appendix III, OMB Circular A-130;

(8) Coordinates certification and accreditation activities for Departmental systems;

(9) Establishes criteria for oversight and compliance and ensuring that periodic reviews are conducted to meet the requirements of Appendix III, OMB Circular A-130 and the GISRA;

(10) Oversees bureau compliance with Federal and Departmental policies, guidelines, and regulations governing IT security;

(11) Establishes criteria for computer security awareness training and ensures that a training program is implemented to meet the requirements of the Computer Security Act of 1987 and Appendix III, OMB Circular A-130.

(12) Establishes criteria for computer incident handling and intrusion detection to meet the requirements of Appendix III, OMB Circular A-130 and the GISRA;

(13) Coordinates DOI reporting of computer security incidents to Federal agencies responsible for national incident response;

(14) Ensures sufficient resources are available to each system to support the implementation and maintenance of the System Security Plans (SSP);

(15) Develops and issues control evaluation guidelines for conducting reviews of systems as related to system and computer security, as required by 340 DM 1.4B(5); and

(16) Acts as the senior IT security liaison to other Federal government organizations and specialized groups on IT security activities;

E. The Office of Inspector General (OIG) conducts periodic reviews of DOI and bureau IT security programs, including GISRA, in conjunction with its ongoing audits of DOI operations. Also, the OIG is responsible for evaluating reported IT security incidents for determination of investigative merit and follow-up action. Normally, these types of IT security incidents involve waste, fraud, abuse, and/or all serious computer hacker and virus incidents that significantly impact on organizational IT systems.

F. Heads of Bureaus are responsible for:

(1) Preparing, updating, and submitting written bureau Security Program Plans (SPP) on an annual basis (December 31) to the DITSM, detailing how they plan to implement the requirements of the Departmental IT security program;

(2) Developing, maintaining, and implementing within the Bureau SPP a process that provides for mandatory periodic training in computer security awareness and in accepted computer security practices of all employees who are involved with the management, use, or operation of each Federal computer system within or under the supervision of the bureau;

(3) Ensuring system owners identify and assess risk, explore controls and countermeasures, and implement approved IT security policies and procedures;

(4) Ensuring the implementation and maintenance of SSPs as required by OMB A-130, Appendix III for all systems;

(5) Ensuring sufficient resources are available to implement the bureau=s IT security program;

(6) Ensuring that bureau IT security programs comply with Federal laws and regulations and DOI regulations, and have adequate resources to function properly;

(7) Designating a full-time Bureau IT Security Manager (BITSM) and an alternate who are knowledgeable in IT security matters;

(8) Developing, conducting, reviewing, submitting, and approving the technical certification documentation for systems under their control as part of the certification and accreditation process; and

(9) Identifying, prioritizing, and reporting to the Departmental CIO, the relative priority of all sensitive systems under their purview.

G. The Bureau CIO and Deputy CIO are responsible for performing all IT program coordination functions for their respective bureau and are the primary liaisons with OCIO. Additionally, the Bureau CIO and Deputy CIO are responsible for implementing all IT security related activities.

H. The BITSM is responsible for managing the bureau IT security program in accordance with public laws, Executive branch directives, Federal standards, and other DOI policies; coordinating all bureau activities designed to protect IT resources, coordinating bureau IT security training programs, and reporting on the effectiveness of these activities to bureau and Departmental management. The responsibilities of the BITSM do not supersede or replace the physical and personnel security responsibilities assigned to other bureau officials. The BITSM must be at an organizational level commensurate with the responsibilities assigned and must be delegated sufficient authority to exercise the following responsibilities.

(1) Consulting with all bureau officials having IT security responsibilities ensuring that bureau IT resources are adequately safeguarded;

(2) Coordinating all pertinent IT security matters pertaining to physical and personnel security with these bureau officials;

(3) Maintaining a current inventory of systems, including system certification and accreditation status, and a schedule for testing system contingency plans and conducting periodic reviews;

(4) Maintaining a current listing of names, security position title, locations, telephone numbers, facsimile numbers, e-mail addresses, and description of responsibilities of all organization employees that have computer security duties within the organization;

(5) Maintaining an appropriate segregation of duties from other IT operations and business of the bureau so as to not have a conflict of interest;

(6) Reporting directly to the bureau CIO and/or the Deputy CIO; and

(7) Certifying and documenting system interconnections and information sharing arrangements at the installation that have been approved and configured securely;

I. An Installation IT Security Manager (IITSM)/Regional IT Security Officer and an alternate will be designated for each information technology installation and/or system. Bureaus and offices have discretion in assigning these roles as long as appropriate separation of duties and accountability is maintained. IITSM are responsible for:

(1) Serving as primary point of contact for security related issues within their region or installation and reporting security incidents to the BITSM;

(2) Developing procedures and guidance necessary for the implementation of an appropriate security program;

(3) Investigating, documenting, and reporting any actual or perceived violation of security and alerting the BITSM of violations with potential impact beyond the IITSM=s area of control;

(4) Approving the IT security safeguards included in contract specifications for the acquisition or operation of hardware, software development, or equipment maintenance services for the installation;

(5) Identifying security related training requirements for all system users and recommending appropriate techniques or programs to management;

(6) Documenting and tracking users who have taken mandatory security training with reports to the BITSM;

(7) Conducting risk assessments, identifying physical vulnerabilities, and recommending cost effective countermeasures appropriate for the site=s facility, including computer rooms and other environments hosting data processing equipment;

(8) Coordinating with servicing personnel officers to ensure that positions with IT duties have the appropriate risk/sensitivity level assigned and that appropriate screening is conducted;

(9) Ensuring end users are trained on IT systems and sign a statement that they understand their responsibilities;

(10) Ensuring user account management activities are performed including ensuring that user identifications are removed from the IT system after users have left, managing changes in user job status, and access control lists are up-to-date;

(11) Coordinating all security activities designed to protect an IT system and/or installation;

(12) Providing technical assistance to installation management on IT security requirements; and

(13) Developing, preparing, reviewing, submitting, and performing formal sign-off on the certification and accreditation documentation for the systems under their control.

J. Program Managers (PM) are responsible for:

(1) Identifying all IT systems containing sensitive information;

(2) Implementing appropriate operational procedures and safeguards for acquiring, accessing, using, maintaining, or disposing of information and technological resources under their control;

(3) Ensuring that IT security policies and procedures are adhered to for the resources they control;

(4) Ensuring that employees receive security clearances and IT access certifications appropriate to the job they will perform;

(5) Ensuring employees receive computer security training as required by the Computer Security Act of 1987 and OMB Circular A-130, Appendix III;

(6) Developing, reviewing, submitting, and performing formal sign-off on the certification and accreditation documentation for the systems under their control; and

(7) Ensuring that adequate IT security funding is planned.

K. Information System Owners are responsible for the overall security and proper use of the IT system, assigning a system security manager who is responsible for all aspects of the system=s security, and reviewing, submitting, and performing formal sign-off on the certification and accreditation documentation for the systems under their control.

L. System Security Managers are responsible for:

(1) Ensuring that all media storing information and data is labeled according to sensitivity;

(2) Ensuring that adequate security requirements are identified and incorporated into system or contract specifications prior to the acquisition;

(3) Identifying applications as Amajor@ in accordance with NIST Special Publication 800-18;

(4) Preparing and maintaining System Security Plans;

(5) Providing for the continuity of operations in the event of system disruption; and

M. System Managers are responsible for:

(1) Ensuring that adequate physical and administrative safeguards are operational within their areas of responsibility;

(2) Ensuring that access to information and data is restricted to authorized personnel on a need-to-know basis;

(3) Developing, training, and testing the IT installation contingency plan and assisting system owners with sensitive SSPs; and

(4) Completing, reviewing, and signing-off on the certification and accreditation documentation for the systems under their control.

N. Users of IT resources are accountable for all activity performed under their unique User ID. Additionally, they are responsible for:

(1) Complying with all security requirements pertaining to the IT resources they utilize;

(2) Keeping current on IT security policies and guidelines;

(3) Keeping their password to themselves;

(4) Protecting IT systems and information from hazards;

(5) Restricting access to information to authorized users;

(6) Ensuring that information is backed-up and securely stored, preferably by using appropriate LAN servers.

(7) Protecting themselves and others from computer viruses;

(8) Using only authorized software;

(9) Logging off and locking up;

(10) Knowing the cost (risk) of compromised or lost information;

(11) Reporting security incidents immediately; and

(12) Reporting to their supervisor or IITSM any condition or event that might represent a possible breach of system security.

19.9 Standards, Requirements, and Procedures. Standards and requirements for IT security of DOI systems are listed below by category. The categories are management controls, operational controls, and technical controls. For details on implementing these standards, see NIST Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook; NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems; NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems; and OMB Circular A-130, Appendix III.

A. Management Controls. Management controls are techniques and concerns that are normally addressed by management in an organization=s computer security program.

(1) Program/Organization-Level Security Policy. Bureaus and offices will develop and implement a written IT security policy meeting the minimum security requirements set forth in this chapter. The policy should be tailored to the unique mission, operational requirements, and environment of each organization and must be reviewed and approved by the DITSM.

(2) IT Security Program Management. Bureaus and offices will develop, prepare, and implement a written Security Program Plan (SPP) for each of their unique mission and operational environments. The SPP will be updated and resubmitted annually to the DOI CIO for review and approval. Also, bureaus and offices will ensure that each system has adequate and individually documented funding requirements needed to support the implementation and maintenance of the System Security Plan (SSP).

(3) Risk Management. Risk assessments will be conducted on all systems and computer installations at least once every three years or when a significant change has occurred to the configuration of the system. Risk assessments will be reviewed on an annual basis to ensure they reflect the current configuration of the system or installation. Risk assessments will be in writing and include, at a minimum: sensitivity of data, threats, vulnerabilities, and effectiveness of current/ proposed safeguards. A sensitivity assessment, which is part of a risk assessment, will be conducted during the initiation phase of the system=s development life cycle.

(4) Review of Security Controls. Bureaus and offices will review a system=s security controls at least every three years, or when significant changes are made to the system, using the checklist contained in the ITSP or any successor guidance distributed by the DOI OCIO.

(5) Life Cycle Management (LCM). Security and funding for IT security will be an integral part of each phase of LCM development of each system. The LCM process will include, but not be limited to, a determination of data sensitivity, system security requirements, system boundaries and interconnections; risk assessments; and provisions for the disposal of data when the system is replaced or retired.

(6) Authorized Processing - Certification and Accreditation (C&A). Certification is the evaluation of an IT system=s security controls to ensure they are implemented and to determine the residual risk. Accreditation is the acceptance by the Designated Accreditation Authority (DAA) of the residual risk by senior management, based on threats to the system and the implemented security controls. [The DAA may grant interim authority to operate on a case-by-case basis]. Systems will undergo C&A before they process any data. Additionally, systems will be re-accredited at least every three years, or when a significant change is made to the configuration of the system

(7) System Security Plan (SSP). An SSP will be developed during the initiation phase for each system in accordance with NIST Special Publication 800-18 or DOI guidance and updated every three years or if a significant change is made to its configuration. Each SSP will include system categorization, asset valuation, and rules of behavior tailored to the security requirements of the particular system. The SSP will be reviewed and certified by the DITSM or his/her designee.

B. Operational Controls. Operational controls are typically implemented and executed for people as opposed to systems.

(1) Personnel Security. All IT-related positions will be designated at a sensitivity or public trust level, in accordance with applicable Departmental policy, based on the degree of harm that an individual, by virtue of their position, could inflict on DOI=s resources or operations. Persons that access, maintain, or are responsible for an IT system must have a favorable background check before being given access required to accomplish their task, and no more. Interim credit checks or local investigations are appropriate while waiting for pending background investigation results. Roles and responsibilities will be reviewed and divided in such a manner that a single individual cannot subvert a critical process. Also, all users are required to understand the sensitivity of the computerized data they are working with and understand their responsibilities regarding this data. Also, user lists and privileges will be periodically reviewed. The review will be the basis for modifying access levels, including denying access to individuals, as a result of task changes or changes in employment status. Further, this section applies to contractors or others working on behalf of the DOI where government information assets are being used regardless of whether they are working on-site or off-site.

(2) Physical Security. DOI IT systems will be physically protected commensurate with the sensitivity and criticality of data processed. Offices and rooms or buildings, such as data centers, will use appropriate devices to enforce physical access control. Wiring closets and areas that contain network cabling and electric power service cables will be secured at the same level as the areas housing the systems hardware. Access control lists will be reviewed and updated on a periodic basis. A procedure will be implemented to immediately deny access to individuals that were terminated or, at the discretion of management, are the subject of adverse personnel actions. Encryption, fiber optic cable, or (in the case of copper wire) a protected distribution system composed of sealed conduit, will be used when the risk of interception of sensitive data is great. Laptop computers, personal data assistants, other portable computing devices, and magnetic or optical media that contain DOI SBU information, will not be left unattended, in plain view, in unattended vehicles, hotel rooms, or uncontrolled offices.

(3) Environmental Protection. DOI IT systems will be environmentally protected commensurate with the sensitivity and criticality of data processed. Environmental protection includes heating, ventilation, and air-conditioning systems (HVAC); water supplies; uninterruptible power supplies (UPS); and fire detection and suppression systems. Environmental protection planning will address these areas and written procedures will be developed that address the impact of the loss these environmental systems will have on supported IT systems and mitigation actions prior to implementing the contingency plan. These written procedures will address fire safety factors, failure of supporting utilities, and structural collapse.

(4) Computer Support and Operations. Bureaus and offices will establish computer support and operations as a part of their security program. Computer support and operations planning will address loading and executing new software; use of system utility software; authorizations required for system changes; software license management; configuration management; file backups; media controls; and documenting security support sufficiently to ensure consistency and continuity. Computer support and operations also includes establishing a help-desk to assist users in identifying security problems, issuing the proper response, and informing the appropriate individuals; and to ensure that passwords are checked on a periodic basis to meet DOI requirements.

(5) Production, Input/Output Controls. Bureaus and offices, based upon information security guidance issued by the OMRPS, will develop and implement procedures to ensure sensitive printed or magnetic media is not lost, stolen, misplaced, or accessed by unauthorized persons. The procedures will address the control of output, use of receipts, access to printers, and marking and disposing of media.

(6) Contingency Planning. Each system will have an appropriate IT contingency plan that addresses applicable response, recovery, and restoration activities based on current vulnerability assessments. At a minimum, the contingency plan will address: the priorities for system restoration; the maximum amount of elapsed time for an adverse event before implementing the contingency plan; the interdependencies with other systems that could affect contingency operations; the frequency of backups for the systems and storage of the backup media; and the roles and responsibilities of individuals involved with the IT contingency implementation. Individuals involved with contingency plan implementation will be trained in their roles and the plans will be tested, reviewed, and revised annually. IT contingency plans must be coordinated with business continuity of operations plans (COOP).

(7) Hardware/Software Maintenance. Bureaus and offices will establish procedures for the maintenance, service, and repair of system hardware and software. The procedures for hardware maintenance should address background checks for unsupervised and unescorted contractor maintenance personnel; procedures for escorting uncleared maintenance personnel on DOI premises; and sanitization of storage media prior to removal for off-site repair. Bureaus and offices will also establish and document a change control process for each system. The change control process will include documenting and testing all changes before modifying the IT system so that new vulnerabilities are not introduced; and updating system configuration documents, such as the SSP, risk assessment, and contingency plan. Bureaus and offices will establish procedures to ensure software installed on IT systems is in compliance with applicable copyright laws and is incorporated into the system=s LCM process.

(8) Data Integrity. DOI IT systems that employ routable protocol devices will contain intrusion detection systems (IDS). The IDS will be installed on boundary protection devices, such as routers or firewalls, to detect network intrusions and potential breaches in progress. Additionally, IDS will be installed on multi-user systems to detect intrusion on hosts, including servers that are located on wireless local area network segments and servers that are directly accessible from a network outside DOI security administration boundaries.

(a) Anti-Viral Protection. Virus protection software will be installed and enabled on workstations, personal computers, selected servers (such as application, web, e-mail, database, etc.), and simple mail transfer protocol gateways and will employ resident scanning at startup to detect and eliminate viruses. Virus signature files on servers will be updated as soon as possible with each new release and pushed to individual workstations.

(b) Penetration Testing. Penetration Testing will be conducted periodically on selected systems and networks and should involve program managers and information owners responsible for the mission activities supported by the subjected system. Isolated systems (those not connected to external networks through routable protocol features or supporting dial-in capability) do not require penetration testing. A testing plan will be developed, reviewed, and approved by the bureau CIO prior to testing. The penetration testing team will complete non-disclosure agreements prior to the testing and all test data, including logs, files, and passwords will be returned. No copies will be made of information. The team will take measures, such as formal rules of engagement, to ensure any successful penetrations during the test do not create a vulnerability to the system.

(9) Documentation. Sufficient documentation will be developed and stored in a secure place to support changes, enable problem solving, and ensure that a system can be reestablished in the event of a system crash or other catastrophic event. The documentation will include, but not be limited to SSPs; other security documentation; operating instructions/ manuals for the operating system and applications; system architecture diagrams; and the configuration of technical security devices.

(10) Security Awareness, Training, and Education. Each bureau or office will implement a security awareness, training, and education program. The program will include provisions for initial training, periodic refresher training, application specific training, and role-based training. All users of IT systems will be provided a description of the sensitivity of the data and security requirements for protecting information processed by any system for which they have access to and the associated rules of behavior. DOI contractors will also comply with the training requirements outlined in this subparagraph. Training is to be provided for all levels of people involved with IT systems. This includes but is not limited to: end-users, system managers, system owners, operators, IT security staff, executives, etc.

(11) Computer Security Incident Response Capability (CSIRC). Each bureau or office will develop and implement a CSIRC as outlined in DOI guidance. This CSIRC will coordinate with the DOI CSIRC and include a process for alerting DOI components of an incident, reporting the incident to the DOI CIO, CSIRC, and FedCIRC, and for responding to the incident. DOI CSIRC will share this information with other DOI components, Federal agencies, and organizations.

C. Technical Controls. Technical controls are executed by systems.

(1) Identification and Authentication. Each user will have a unique user identification. User transactions must be traceable by the system, so individual accountability can be established. Network passwords will be changed at least every ninety days, be a minimum of 8 characters in length, comprised of alphanumeric characters, and will not be dictionary words. The use of a combination of letters, numbers, and special characters is highly recommended, as well as the periodic use of password cracking software. System administrators will immediately disable any accounts reported as compromised. Attempts to enter the network using compromised passwords will be reported immediately to the IITSM. In the event of a lost password, system administrators will not issue a temporary password until verification of the requestor=s identity and the user=s need to access the system has been confirmed. Issuing a password for emergency or temporary access will be granted only after coordination with the IITSM and the system owner. Additionally, the password will be aged to expire after there is no longer a need to access the system. Administrator passwords will be strictly controlled and managed by the appropriate IT security manager, will not be used for daily access by users, and will be limited to the absolute least number of personnel. Digital or electronic signatures, used as a means of identification and authentication, will comply with current FIPS Publication standards.

(2) Logical Access Controls. Logical access controls will be in place and operational for all DOI IT systems. Access controls will enable the use of only the resources, such as data programs, necessary to fulfill an individual=s job responsibilities and will enforce separation of duties based on roles and responsibilities. The access controls will ensure only authorized personnel can access, add, change, or remove component devices, dial-up connections, network addresses and protocols, and remove or alter programs. The use of file level access controls is encouraged for the management of critical files or data. Each system will have a process in place that ensures individuals are denied access to the system when employment is terminated, at the discretion of management, or are the subject of adverse personnel actions. The access termination process will include procedures to ensure individuals are also denied physical access to IT resources, such as disabling a proximity card used to enter a data center.

(a) Encryption. Encryption use will be implemented in compliance with applicable FIPS and NIST guidance. Encryption should be considered for all transmissions of sensitive information outside of DOI trusted zones, such as sending data over the Internet. Additionally, encryption will be used to secure sensitive data transmitted on a network that uses wireless technology and on sensitive data, such as investigation or arbitration information that is stored or processed on a laptop computer.

(b) Firewalls. Firewalls will be installed at interfaces between DOI and un-trusted networks, such as the Internet and be configured to deny Internet traffic unless specifically authorized by the organization=s BITSM. They will block all services not required, disable unused ports, hide and prevent direct access to DOI trusted network addresses from un-trusted networks, maintain comprehensive audit trails, and fail into a closed state. Firewalls will be configured to log all events in real-time so that the network activity can be analyzed and evaluated.

(c) All DOI IT systems will implement a system banner that provides warnings to employees that accessing the system constitutes consent to system monitoring for law enforcement and other purposes, and to unauthorized users that their use of the system may subject them to criminal prosecution and/or criminal, civil, or administrative penalties.

(d) IT systems that are used for Atelework@ or Atelecommuting,@ either personally owned or the property of DOI, will have sufficient security controls to protect government equipment, software, and data from being accessed or modified by unauthorized individuals. All connections to DOI systems by dial-in or remote access, including those used for telework, have the same security requirements as a connection to an un-trusted network.

(3) Audit trails. The use of DOI IT systems will be conducted in accordance with the appropriate Departmental use policy. IT systems, in accordance with applicable Departmental guidance, will maintain an audit trail of activity sufficient to reconstruct security relevant events. The audit trail will include the identity of each entity accessing the system; time and date of access (including activities performed using a system administrator=s identification); and activities that could modify, bypass, or negate the system=s security controls. Audit logs will be reviewed on a regular, periodic basis and any suspected attempts of unauthorized access or scanning of the system will be reported to the IITSM. Audit logs will be retained for 90 days, the minimum period specified by the bureau or office, or the period specified in the SSP, whichever is longer. Keystroke monitoring is prohibited unless approved by the DOI Solicitor=s Office and the BITSM.

(4) Public Access Controls. As stated in paragraph 2(b) above, firewalls will be installed at interfaces between DOI and the Internet, and be configured to deny Internet traffic unless specifically authorized by the organization=s BITSM. Bureaus and offices will ensure that new vulnerabilities are not introduced into the network by conducting risk assessments and mitigating any new risks to an acceptable level prior to implementation of system modifications. Additionally, security controls will be implemented that preclude public access to network servers through the Internet. Servers and other nodes accessible to the public through the website will not contain or process other types of DOI information. Security controls will be implemented that will ensure publicly accessible DOI information is not modified and remains available.

D. Waivers. Waivers being sought for policies set forth in this chapter require a written request explaining the compelling need for the waiver. Waivers will be sent to the Departmental CIO and co-signed by the bureau/office CIO and Director.

19.10 Reports and Forms. Since OMB Circular A-130, Appendix III was codified into law, DOI has been required to submit periodic status reports on the program management and evaluation aspects of IT security. The DOI CIO is responsible for coordinating these reports and does so with heavy reliance from the bureaus and offices. Instructions and specific areas of interest for the reports are established by OMB, or other external agencies, based on specific laws and are not expected to vary in general, but are expected to take different focus depending on perceived weaknesses in the overall Federal government IT security area. The following IT security areas are typical of these data calls: IT security program management, IT security funding and resource management, program reviews/independent evaluations, material weaknesses, risk management, IT security training, IT security incidents, security in system lifecycle, critical asset protection, etc.

This Appendix provides a list of key terms and definitions. It includes those used in this document as well as other items that concerned personnel might need to understand.

Accreditation is synonymous with the term authorize processing. Accreditation is the authorization and approval granted to a major application or general support system to process in an operational environment. Accreditation is the formal authorization to process granted by the Principal Accrediting Authority. It is made on the basis of a certification by designated technical personnel that the system meets pre-specified technical requirements for achieving adequate system security. See also Authorization Processing, Certification, and Designated Approval Authority.

Adequate Security is security commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that systems and applications used by the Department operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost effective management, personnel, operational, and technical controls.

Asset means a broad term used to define any information resource or information technology component. Assets in the context of IT security would be an AIS, IT hardware and software, data files, processes and procedures, networks, computer installations, and human resources.

Asset Valuation is a process by which an automated asset is assessed to determine its value and the underlying business components it supports should a disruption occur. Asset valuation categorizes systems by overall Federal government importance (national critical infrastructure information systems, national security information systems, Interior mission critical systems, and all other sensitive systems).

Assurance means a measure of confidence that the security features and architecture of an automated information system accurately mediate and enforce the security policy.

Authorize Processing occurs when management authorizes a system based on an assessment of management, operational and technical controls. By authorizing processing in a system the management official accepts the risk associated with it. See also Accreditation, Certification, and Designated Approval Authority.

Availability means the property of being accessible and usable upon demand by an authorized entity to complete a function. The IT system or installation contains information or provides services that must be available on a timely basis to meet mission requirements or to avoid substantial losses. Controls to protect the availability of information are required if the information is critical to DOI's functions. Public access to some information requires DOI to ensure the availability of that information within a short period of time.

Chief Information Officer (CIO) is responsible for overall management of IT resources and IT security programs of the Department of the Interior.

Computer Center/Installation means a location, generally one or more contiguous rooms, dedicated to computer operations and containing the components of a computer system. These components include but are not limited to computer hardware, software, and telecommunications equipment and are typically augmented by environmental safeguards (locks, fire detection, etc.) and standard operating procedures. A computer center or installation supports general computing requirements of more than one program or bureau/office and includes a multi-user computer. It does not include general purpose areas such as offices that contain personal computers, network components, or other items of automation where the primary function is other than operation of the computer system.

Contingency plan means a plan for emergency response, back-up operations, and post-disaster recovery for IT systems and installations in the event normal operations are interrupted. The contingency plan should ensure minimal impact upon data processing operations in the event the IT system or facility is damaged or destroyed.

Continuity of Operations Plan (COOP) means a set of contingency procedures established to ensure business continues in the event of emergency conditions. For information technology, the contingency planning addresses: backup operations; disaster recovery of information, hardware, and software; alternate processing locations; electricity; environmental; personnel issues; etc.

Countermeasure are the action(s) taken to mitigate an identified risk.

Department of the Interior (ADOI@) is a cabinet-level organization with overall responsibility and accountability for all agency bureaus, offices, services, and other internal organizations.

Designated Approving Authority (DAA) is the senior management official who has the authority to authorize processing (accredit) an automated information (major application) or (general support system) and accept the risk associated with the system.

Due Diligence is the standard established by the courts designed to reflect the organizational good faith effort to comply with the federal computer IT security standards as defined by the federal legislation such as The Computer Security Act of 1987, Information Technology Management Reform Act (ITMRA(Clinger-Cohen Act)), and the Government Information Security Reform Act (GISRA); Office of Management and Budget (OMB) memoranda and directives such as A-130 appendix III; and the National Institute of Standards and Technology (NIST) guidance documents.

General Support System (GSS) means an interconnected set of information resources, under the same direct management control, which shares common functionality. A GSS normally includes hardware, software, information, data, applications, communications, and people. A GSS normally provides support for a variety of users and/or applications. Individual applications support different mission-related functions. Users may be from the same or different organizations. A GSS can be a local area network (LAN), including smart terminals that supports a branch office; a DOI wide backbone; a communications network; a Departmental data processing center, including its operating system and utilities; a radio network; or a shared Information Processing Service Organization (IPSO).

Information Resources Management (IRM) is the planning, budgeting, organizing, directing, training, and control of information and the underlying technical infrastructure. These resources include personnel, equipment, funds, information, and technology.

Information technology facility is an organized grouping of personnel, hardware, software, and physical facilities, a primary function of which is the operation of information technology.

Information technology installation means one or more computer or office automation systems including related telecommunications, peripheral or storage units, central processing units, and operating and support system software. Information technology installations may range from information technology facilities, such as large centralized computer centers, to individual stand-alone microcomputers such as personal computers, or workstations.

Information technology resources means any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the Department. The term "information technology resources" includes computers, telecommunications equipment, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.

Information technology security means the management controls and safeguards designed to protect IT resources and safeguard Federal governmental assets and individual privacy. The combination of physical, administrative, and technical measures applied to protect the AIS and information technology assets from loss, destruction, misuse, alteration, unauthorized disclosure, or access.

Information technology system means an information system that is automated or is an assembly of computer hardware, software, and established methods and procedures designed and configured to classify, sort, calculate, compute, summarize, transmit, and receive, store and retrieve data with a minimum of human intervention for the purpose of supporting specific administrative, mission, or program requirements. This includes the areas of application systems, databases, and management information systems, as well as single application programs, which operate independently of other program applications. An IT system that is composed of one or more units of software and supported by computer and/or communications equipment.

Internet is a network of networks, linking computers to computers. Each runs software to provide or "serve" information and/or to access and view information. The Internet is the transport vehicle for the information stored in files or documents on another computer.

Major Application (MA) means an application that requires special attention to security due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to, or modification of, the information in the application. All Federal applications require some level of protection. Certain applications, because of the information in them require special management oversight and should be treated as an MA. Adequate security for other applications should be provided by the security of the systems in which they operate. A breach in a major application might compromise many individual application programs and hardware, software, and telecommunications components. Major applications can be either a major software application or a combination of hardware/software where the only purpose of the systems is to support a specific mission-related function. Adequate security for other applications should be provided by security of the systems in which they operate.

Management Control Review (MCR) is a control review is a systematic examination of a component to determine whether adequate management controls exist and are effective. The purpose of a management control review is to determine if controls are in place and are adequate enough to provide reasonable assurance of meeting component objectives efficiently and effectively and to safeguard Government resources.

Network is a communications medium consisting of hardware such as servers, routers, hubs, wiring, etc that are used in the transferring of electronic information from one point to another.

NIST is the National Institutes of Standards and Technology. NIST is responsible for interpreting laws and regulations and developing guidance to federal agencies for activities such as IT security.

Non-repudiation means the origin or the receipt of a specific message must be verifiable by a third party. The information must be able to provide proof of the integrity and origin of data that can be verified by a third party such as legally preventing the originator of a message from denying authorship at a later date or the sender of a message later denying transmission.

Password is a word, phrase, or combination of letters, numbers, and symbols that is used to authenticate the identity of a user to access a specific automated system or process. The password is kept secret by the user and changed often to ensure confidentiality and limit risk.

Risk means a combination of the likelihood that a threat will occur, the likelihood that a threat occurrence will result in an adverse impact, and the severity of the resulting adverse impact. The potential for exposure to loss. Risks, either man-made or natural, are constant throughout our daily lives. The potential is usually measured by its probability in years. Risk is the possibility of harm or loss to any software, information, hardware, administrative, physical, communications, or personnel resource within an automated information system or activity.

Risk analysis means a formal systematic approach to assessing the vulnerability of an IT system or installation. Risk analysis is the process of analyzing threats to and vulnerabilities of an information system to determine the risks (potential for losses). Risk factors are quantified using estimates of probability and based on potential occurrence of: loss of life, loss of money, loss of property, litigation, embarrassment and impairment of business functions. The resulting data is then analyzed. The analysis is used as a basis for identifying appropriate and cost-effective measures to counter the identified threats and vulnerabilities. The risk analysis identifies threats, quantifies the potential losses from threat realization, examines the cost benefit of applying alternative measures to counter the identified threats and reduces potential loss, and defines or documents the degree of acceptable risk.

Risk assessment means an evaluation of IT assets and vulnerabilities to establish an expected loss from certain events based on estimated probabilities of the occurrence of those events. A risk assessment identifies potential threats and their probability of occurrence and proposes safeguards to combat these threats and provides management with information on which to base decisions, e.g., whether it is best to prevent the occurrence of a situation, to contain the effect it may have, or simply to recognize that a potential for loss exists.

Risk management means the process of the identification, measurement, control, and minimization of security risk in information systems. Also, it means to assess risk, take actions to reduce risk to an acceptable level, and maintain risk at that level. Inherent in this definition is the concepts that risk cannot be completely eliminated and the most secure computer system is the one that no one uses.

Security policy means the set of laws, rules and practices that regulate how an organization manages, protects, and distributes sensitive information.

Security specifications means a detailed description of the safeguards required to protect a sensitive system/application.

Sensitive system means a system containing information that requires protection due to the risk and magnitude of loss or harm that could result from inadvertent or deliberate disclosure, alteration, or destruction of the information. The term includes information whose improper use or disclosure could adversely affect the ability of the Department of the Interior to accomplish its mission, e.g., proprietary information, information about individuals requiring protection under the Privacy Act, and information not releasable under the Freedom of Information Act. (For more information, refer to 383 DM 1-15.) OMB Circular A-130, Appendix III, does not distinguish between sensitive and non-sensitive systems. Rather, consistent with the Computer Security Act of 1987, the Circular recognizes that federal IT systems have varied levels of sensitivity and criticality. All Federal systems have some level of sensitivity and require protection as part of good management practice. Therefore all of the Department=s systems and electronic information requires an analysis to determine the risks associated with potential loss or unauthorized disclosure/modification and the safeguards necessary to implement to mitigate the risks.

Sensitivity in an IT environment consists of the system, data, and applications, which must be examined individually and in total. All systems and applications require some level of protection for confidentiality, integrity, availability, non-repudiation, and accountability, which is determined by an evaluation of the sensitivity and criticality of the information processed, the relationship of the system to organizations mission, and the economic value of the system components.

System means a generic term used for its brevity to mean either a major application or a general support system. A system is identified by logical boundaries drawn around the various processing communications, storage, and related resources. They must be under same direct management control (not responsibility), perform essentially the same function, reside in the same environment, and have the same characteristics and security needs. A system does not have to be physically connected.

System Security Plan means a plan developed by DOI in accordance with OMB and NIST guidelines implementing the Computer Security Act of 1987 to safeguard the security of its IT systems and installations.

Test scenarios are descriptions of the tests to be performed to check the effectiveness of the security features incorporated into a GSS or MA. 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.

Vulnerability means a weakness in an information system or component (e.g., security procedures, hardware design, internal controls) that could be exploited, attacked or fail. Vulnerabilities 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.

----------------------------------------------------------------------------------------------------------------------

Acronyms and associated explanations used throughout 375 DM 19.

----------------------------------------------------------------------------------------------------------------------

This Appendix provides a list of relevant statutes, regulations, directives, and other guidance applicable to the DOI IT security program. It includes those cited in this document as well as other items that concerned personnel might need to understand. Although it is not a comprehensive collection of IT security-related references and authorities, it is sufficiently detailed to facilitate the reader=s use of this document and to understand other IT security-related documentation.

- Copyright Act of 1980.

- Computer Crime Act of 1984.

- Computer Fraud and Abuse Act of 1986, Public Law 99-474, 18 U.S.C 1030.

- Computer Matching and Privacy Protection Act of 1986, P.L. 101-56.

- Computer Security Act of 1987, Public Law 100-235, 40 U.S.C 759.

- Confidentiality of Social Security Numbers Act.

- Confidentiality of Child Abuse Information Act.

- Counterfeit Access Device and Computer Fraud and Abuse Act of 1984, 18 U.S.C. 1030 (1984).

- Digital Signature Law.

- Disclosure of Confidential Information Generally, 18 U.S.C. 1905 (1948).

- Electronic Accessibility Act.

- Electronic Communications Privacy Act of 1986, PL 99-508.

- Electronic Funds Transfer Act.

- Electronic Records Act.

- Embezzlement and Theft Prohibition Act.

- Federal Manager's Financial Integrity Act of 1982, P.L. 97-255, 31 U.S.C. 1352.

- Freedom of Information Act, Public Law 93-502, 5 U.S.C. 552.

- Government Information Security Reform Act, Title X, P.L. 106-398.

- Government Paperwork Reduction Act/Authorization.

- Government Performance Reform Act (GPRA).

- Information Technology Management Reform Act of 1996 (Clinger-Cohen Act), Division E of Public Law 104-106, 40 U.S.C. 1401.

- Interception and Disclosure of Wire or Oral Communications Prohibited, 18 U.S.C. 2511 (1968).

- Malicious Mischief, 18 U.S.C. 1361 (1967).

- National Security Act, as amended, P.L. 102-485.

- Paperwork Reduction Act of 1978, as amended, PL 104-13, 109 Stat 163, 44 U.S.C. Ch 35.

- Patent and Trademark Laws

- Privacy Act of 1974, P.L. 93-579, 5 U.S.C. 552a (1974)

- Public Information Agency Rules, Opinions, Records, and Proceedings (Freedom of Information Act), 5 U.S.C. 552 (1967).

- Public Money, Property, or Records, 18 U.S.C. 641 (1948).

- Right to Financial Privacy Act.

- Wire Fraud Prohibition Act.

- Office of Management and Budget (OMB) Circular A-11, "Preparation and Submission of Budget Estimates," June 17, 1988.

- OMB Circular No. A-109, "Major Systems Acquisitions," April 5, 1976.

- OMB Circular No. A-123 Revised, AManagement Accountability and Control,@ June 1995.

- OMB Circular No. A-127, AFinancial Management Systems,@ July 23, 1993.

- OMB Circular No. A-130 Revised, AManagement of Federal Information Resources,@ February 8, 1996.

- OMB Memorandum 99-18, Privacy Policies on Federal Web Sites, June 2, 1999.

- OMB Memorandum 99-05, Instructions on Complying with President's Memorandum of May 14, 1998, Privacy and Personal Information in Federal Records, July 1, 1999.

- OMB Memorandum 99-20, Security of Federal Automated Information Resources, June 23, 1999.

- OMB Memorandum 00-07, Incorporating and Funding Security in Information Systems Investments, February 28, 2000.

- OMB Memorandum 00-13, Policies and Data Collection on Federal Web Sites, June 22, 2000.

- OMB Memorandum 00-15, OMB Guidance on Implementing the Electronic Signatures in Global and National Commerce Act, September 25, 2000.

- OMB Memorandum 01-05, Guidance on Inter-Agency Sharing of Personal Data-Protecting Personal Privacy, December 20, 2000.

- OMB Memorandum 01-08, Guidance on Implementing the Government Information Security Reform Act, January 16, 2001.

- OMB Memorandum 01-17, Confidentiality of Pre-decisional Budget Information, April 25, 2001.

- OMB Memorandum 01-24, Reporting Instructions for the Government Information Security Reform Act, June 22, 2001.

- Special Publication (SPEC PUB) 500-2, Accessing Individual Records from Personal Data Filed Using Non-unique Identifiers.

- SPEC PUB 500-9, The Use of Passwords for Controlled Access to Computer Resources.

- SPEC PUB 500-10, A Database Management Approach to Privacy Act Compliance.

- SPEC PUB 500-19, Audit and Evaluation of Computer Security.

- SPEC PUB 500-21 (Volume 2), The Network Security Center: A System Level Approach to Computer Network Security.

- SPEC PUB 500-24, Performance Assurance and Data Integrity Practice.

- SPEC PUB 500-25, An Analysis of Computer Security Safeguards for Detecting and Preventing Intentional Computer Misuse.

- SPEC PUB 500-27, Computer Security and DES.

- SPEC PUB 500-33, Considerations in the Selection of Security Measures of Automatic Data Processing Systems.

- SPEC PUB 500-57, Audit and Evaluation of Computer Security II, System Vulnerabilities and Controls.

- SPEC PUB 500-67, The SRI Hierarchical Development Methodology (HDM) and its Application to the Development of Secure Software.

- SPEC PUB 500-85, Executive Guide to ADP Contingency Planning.

- SPEC PUB 500-109, Overview of Computer Security Certification and Accreditation, April 1984.

- SPEC PUB 500-120, Security of Personal Computer Systems: A Management Guide, January 1985.

- SPEC PUB 500-123, Technology Assessment: Methods for Measuring the Level of Computer Security.

- NBS SPEC PUB 500-133, Technology Assessment: Methods for Measuring the Level of Computer Security, October 1985.

- SPEC PUB 500-136, An Overview of Computer Software Acceptance Testing, February 1986.

- SPEC PUB 500-137, Security for Dial-Up Lines, May 1986.

- NBS SPEC PUB 500-153, Guide to Auditing for Controls and Security: A System Development Life Cycle Approach, April 1988.

- SPEC PUB 500-157, Smart Card Technology: New Methods for Computer Access Control, September 1988.

- NBS SPEC PUB 500-158, Accuracy, Integrity, and Security in Computerized Vote-Tallying.

- SPEC PUB 500-161, Software Configuration Management: An Overview, March 1989.

- SPEC PUB 500-166, Computer Viruses and Related Threats: A Management Guide, August 1989.

- SPEC PUB 500-169, Executive Guide to the Protection of Information Resources, October 1989.

- SPEC PUB 500-170, Management Guide to the Protection of Information Resources, October 1989.

- SPEC PUB 500-171, Computer User's Guide to the Protection of Information Resources, October 1989.

- SPEC PUB 500-174, Guide to Selecting Automated Risk Analysis Tools, October 1989.

- SPEC PUB 500-180, Guide to Software Acceptance, April 1990.

- SPEC PUB 800-2, Public-Key Cryptography, April 1991.

- SPEC PUB 800-3, Establishing a Computer Security Incident Response Capability (CSIRC), November 1991.

- SPEC PUB 800-4, Computer Security Considerations in Federal Procurement: A Guide for Procurement Initiators, Contracting Officers, and Computer Security Officials, March 1992.

- SPEC PUB 800-9, Good Security Practices For Electronic Commerce, Including Electronic Data Interchange, December 1993.

- SPEC PUB 800-10, Keeping Your Site Comfortably Secure: An Introduction To Internet Firewalls, December 1994.

- SPEC PUB 800-11, The Impact Of The FCC's Open Network Architecture On NS/EP Telecommunications Security, February 1995.

- SPEC PUB 800-12, An Introduction To Computer Security: The NIST Handbook, October 1995.

- SPEC PUB 800-13, Telecommunications Security Guidelines For Telecommunications Management Network, October 1995.

- SPEC PUB 800-14, Generally Accepted Principles And Practices For Securing Information Technology Systems, June 1996

- SPEC PUB 800-15, Minimum Interoperability Specification For PKI Components (MISPC), Version 1, January 1998

- SPEC PUB 800-16, Information Technology Security Training Requirements: A Role- And Performance-Based Model (Supersedes NIST Spec Pub 500-172), March 1998.

- SPEC PUB 800-17, Modes Of Operation Validation System (MOVS): Requirements And Procedures, February 1998

- SPEC PUB 800-18, Guide For Developing Security Plans For Information Technology Systems, December 1998.

- SPEC PUB 300-19, Mobile Agent Security, October 1999.

- SPEC PUB 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures, November 1999.

- SPEC PUB 800-21, Guideline for Implementing Cryptography in the Federal Government, November 1999.

- SPEC PUB 800-22, A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications, October 2000

- SPEC PUB 800-23, Guideline to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products, August 2000.

- SPEC PUB 800-24, PBX Vulnerability Analysis: Finding Holes in Your PBX Before Someone Else Does, August 2000.

- SPEC PUB 800-25, Federal Agency Use of Public Key Technology For Digital Signature and Authentication, October 2000.

- SPEC PUB 800-26, Security Self-Assessment Guide for Information Technology Systems, November 2001.

- SPECI PUB 800-27, Engineering Principles for IT Security (A Baseline for Achieving Security), June 2001.

- SPEC PUB 800-28, Guidelines on Active Content and Mobile Code, October 2001.

- SPEC PUB 800-29, A Comparison of the Security Requirements For Cryptographic Modules and FIPS 140-1 and FIPS 140-2, June 2001.

- SPEC PUB 800-30, Risk Management Guide For IT Systems, January 2002.

- SPEC PUB 800-31, Intrusion Detection Systems, November 2001.

- SPEC PUB 800-32, Introduction to Public Key Technology and Federal PKI Infrastructure, February 2001.

- SPEC PUB 800-33, Underlying Technical Models For IT Security, December 2001.

- SPEC PUB 800-38A, Recommendation For Block Cipher Modes of Operation-Methods and Techniques, December 2001.

- SPEC PUB 800-41, Guidelines on Firewalls and Firewall Policy, January 2002.

- SPEC PUB 800-42, Guideline on Network Security Testing (Draft), February 4, 2002.

- SPEC PUB 800-XX, Guideline on Securing Public Web Servers (DRAFT, February 28, 2002.

- NIST DRAFT Publication of System Administration Guidance for Windows 2000 Professional, January 28, 2002.

- NISTIR 4659, Glossary of Computer Security Terminology, September 1991.

- NISTIR 4846, Computer Security Training & Awareness Course Compendium, May 1992.

- NISTIR 4939, Threat Assessment of Malicious Code and External Attacks, October 1992.

- NISTIR 4976, Assessing Federal and Commercial Information Security Needs, November 1992.

- NISTIR 5153, Minimum Security Requirements for Multi-User Operating Systems, March 1993.

- NISTIR 5540, Multi-agency Certification and Accreditation (C&A) Process: A Worked Example, December 1994.

- NISTIR 6192, A Revised Model Role Based Access Control, July 1998.

- NISTIR 6416, Applying Mobile Agents to Intrusion Detection and Response, October 1999.

- NISTIR 6462, CSPP-Guidance for COTS Security Protection Profiles, December 1999.

- NIST GCR 94-654, Federal Certification Authority Liability And Policy, June 1994.

- FIPS PUB 31, Guidelines for Automated Data Processing Physical Security and Risk Management, June 1974.

- FIPS PUB 39, Glossary for Computer Systems Security.

- FIPS PUB 41, Computer Security Guidelines for Implementing the Privacy Act of 1974, May 1975.

- FIPS PUB 46-3, Data Encryption Standard, October 1999.

- FIPS PUB 73, Guidelines for Security of Computer Applications, June 1980.

- FIPS PUB 83, Guideline on User Authentication Techniques for Computer Network Access Control, September 1980.

- FIPS PUB 87, Guidelines for ADP Contingency Planning, March 1981.

- FIPS PUB 88, Guideline on Integrity Assurance and Control in Database Administration, August 1981.

- FIPS PUB 101, Guideline for Lifecycle Validation, Verification, and Testing of Computer Software, June 1983.

- FIPS PUB 102, Guideline for Computer Security Certification and Accreditation, September 1983.

- FIPS PUB 132, Guideline for Software Verification and Validation Plans, November 1987.

- FIPS PUB 139, Inter-operability and Security Requirements for Use of the Data Encryption Standard in the Physical Layer of Data Communications, August 1983.

- FIPS PUB 140, General Security Requirements for Equipment Using the Data Encryption Standard, April 1982.

- FIPS PUB 141, Inter-operability and Security Requirements for Use of the Data Encryption Standard with CCITT Group 3 Facsimile Equipment, April 1985.

- FIPS PUB 146-1, Government Open Systems Interconnection Profile (GOSIP), April 1991.

- FIPS PUB 186-1, Digital Signature Standard (DSS), January 2000.

- FIPS PUB 188, Standard Security Label For Information Transfer, September 1994.

- FIPS PUB 191, Guideline for the Analysis of LAN Security, November 1994.

- FIPS PUB 196, Entity Authentication Using PKI Cryptography, February 1997.

DOI Publications (Personnel responsible for IT security must be knowledgeable of, and conform to, the Departmental Manual Parts listed below to ensure proper adherence to security program components.)

- DOI Departmental Manual 375, Chapter 19, Information Technology Security Program.

- DOI Departmental Manual 376, Telecommunications.

- DOI Departmental Manual 377, Automated Data Processing.

- DOI Departmental Manual 383, Policies and Procedures for Implementing the Privacy Act of 1974

- DOI Departmental Manual 384, Records Disposition.

- DOI Departmental Manual 436, Vital Records.

- DOI Departmental Manual 441, Personnel Security.

- DOI Departmental Manual 444, Physical Security.

- DOI Departmental Manual 446, Law Enforcement.

- DOI Information Technology Security Plan (ITSP), Draft.

- DOI Information Technology Security Handbook, September 2001.

- DOI Guidelines for Preventing, Detecting, and Removing Malicious Software, January 1992.

- DOI Interim Network Perimeter Security Standard, December 13, 2000.

- Executive Order (EO) 12958, Classified National Security Information. April 16, 1995

- EO 13231, Critical Infrastructure in the Information Age, October 16, 2001.

- Director of Central Intelligence Directive (DCID) 6/3.

- Joint Security Board (JSB), Directive on Safeguarding Classified National Security Information.

- National Security Telecommunications and Information Systems Security Committee (NSTISSC), National Security Telecommunications and Information Systems Security Issuances (NSTISSI).

- Presidential Decision Directive (PDD) 63, Protecting America's Critical Infrastructures, May 22,1998.

- Presidential Directive implementing the recommendations in the Department of Justice Vulnerability Assessment of Federal Facilities, 1995.

- Federal Sector Critical Infrastructure Planning Guide, 1998.

- Vulnerability Assessment Framework, October 1998

- Memorandum From Federal CIO Council, Federal Information Technology Security Assessment (FITSA) Framework, December 4, 2000

4/15/02 #3397

Replaces 7/22/97 #3165